11 replies to this topic

[metRo_]

As part of a bigger project i use RN-171 to connect CC to GCS.

The module have a little issue. When an application create an socket it get a random port for future income packets. Per example when GCS connect to a UDP "server" it will send the packet to a IP and a SERVER_PORT and get a its own port for where the server should send the messages. The problem is that the RN171 can't identify this port (it can....) so i write a little application that does a port forward between the CGS and module WiFi(RN171) because it only can list in one fix port and send data to another fix port. Problem resolved but need to run a little application.

Talked with the guys at Roving Networks (and they are really nice people) and they compile a firmware with the option to get the PORT from the first packet it receive so i don't need to run the little application anymore but now it get another problem. The RN171 save the first PORT and just reset it after reboot or it receive a specific command, so if you disconnect the GCS and connect again it could send data to CC but the data come from CC by RN171 will go to the first PORT reserve by GCS.

It is working but you need to choose if you prefer a little application running or if you prefer reset the board always you want to connect GCS to it.

A video of it working:



PS: If someone want to use this just tell me and I can post the code, commands needed, etc.

[peabody124]

Nice.  Also what is the carrier board you are using?

[D-Lite]

metRo_, on 29 November 2011 - 12:15 AM, said:

Talked with the guys at Roving Networks (and they are really nice people) and they compile a firmware with the option to get the PORT from the first packet it receive so i don't need to run the little application anymore but now it get another problem. The RN171 save the first PORT and just reset it after reboot or it receive a specific command, so if you disconnect the GCS and connect again it could send data to CC but the data come from CC by RN171 will go to the first PORT reserve by GCS.

There are two possible solutions for that:

- make the UDP source port configurable in GCS so that it's fixed and not choosen randomly
- make RN171's firmware always respond to the same port the packet came from, not only look at the first packet.

[metRo_]

peabody124, on 29 November 2011 - 02:54 AM, said:

Nice.  Also what is the carrier board you are using?

RN174

D-Lite, on 29 November 2011 - 08:08 AM, said:

There are two possible solutions for that:

- make the UDP source port configurable in GCS so that it's fixed and not choosen randomly
- make RN171's firmware always respond to the same port the packet came from, not only look at the first packet.

For what i read in internet and some tests using Qt framework fix the source packet it is not possible. What i create is a socket that connect to host and another socket that act as "host" and listen in a fix port.
I can't change the firmware but i can ask them for it.
Supposedly it work with TCP where are a real connection and the module knows when the connection start and end but i just did few tests with it and it doesn't but i'll try again. I'm using UDP because in future i want to control the quad with mobile phone and using UDP it will respond fast.

[metRo_]

Tested with TCP and it worked out of the box. I expected it to be slower but didn't think that this is noticed in a serial communication with baudrate at 57600 :s maybe because the module is only set to 1 or 2mbps.

Definitely for the control i will need to use UDP.

[D-Lite]

metRo_, on 29 November 2011 - 10:03 PM, said:

Tested with TCP and it worked out of the box. I expected it to be slower but didn't think that this is noticed in a serial communication with baudrate at 57600 :s maybe because the module is only set to 1 or 2mbps.

I wouldn't care too much about speed. As long as you have a reliable connection, there shouldn't be much difference. But I agree that when it comes to send control messages, UDP is superior. No timeouts, no retransmissions, no disconnect/reconnect problems.

[fchouza]

Hello, i'm usign a RN171 and i have some problems with the serial connection. The sent is corrupted, for example, send the sequence 18576, 18577, 18578 and arrive to computer only 1857, 185 or 185718576 for example. The module is set to 9600 baud with flow control (also tested without flow control). When increase the baud rate, errors are more frequent. ¿Any suggestions?

Thank you!

[metRo_]

What are you connecting to RN171? Did you read this http://www.g2microsy...ining2010v7.pdf ? If you contact support at roving networks they will help you quickly.

[fchouza]

metRo_, on 23 December 2011 - 02:05 PM, said:

What are you connecting to RN171? Did you read this http://www.g2microsy...ining2010v7.pdf ? If you contact support at roving networks they will help you quickly.

Thank you for the response and the document!!

The module is connected to a LPCxpresso 1768 via UART.

I contacted the Roving support, but technical support have some delay because one of the engineers are in bussines travel in Asia.

[metRo_]

Usually they are quick.

If you connect your LPCxpresso to PC do you receive the data in good sequence?

[fchouza]

metRo_, on 23 December 2011 - 04:28 PM, said:

Usually they are quick.

If you connect your LPCxpresso to PC do you receive the data in good sequence?

Yes, connected to PC serial port works good. I will try connect the module to PC serial port.

[fchouza]

fchouza, on 23 December 2011 - 04:33 PM, said:

Yes, connected to PC serial port works good. I will try connect the module to PC serial port.

The problem was solved making a factory RESET! Thank you for the help!