Rn171 interface problems

Archive
1

Hi there,

I posted my problems with the cerbuinobee and the rn171 wifi-module in another thread:
https://www.ghielectronics.com/community/forum/topic?id=16549
However I found out that the problems are most likely related to the rn171 module, and not the serial driver and/of the cerbuino.
I still recieve corrupted data via a serial interface (using a usb serial adapter). I did a factory reset, reinstalled the firmware, but no succes, i still recieve corrupted data when i execute the ping command.
The electrical levels seems to be OK, on line Tx and Rx i measure 3.25 volt… I tested this issue on 2 PC’s and 2 rn171 modules.
Any suggestion to ge me out of this misery is welcome…

2

Are you using a GHI-RN171-Module or an RN-VX module on the GHI-XBee-Adapter Module?
As can be seen from the responses of the Module you are using the latest Firmware(4.41)
Did you try it with my driver modification from Code Share?

3

I had come to the conclusion that is has nothing to do with the driver. the response of the 171 on the xbee socket, the gadgeteer socket ( connected only tx and rx) , and on the RN-XV usb-xbee interface is in error. The 171 spits out unespected characters…when pinging…
I also modified baudrate, updated firmware, factory reset, but no succes.
Mind you, the error is spurious…so if you try, do more than 1 retries…

4

I don’t want to say that your conclusions are not right. But I know, with conclusions it’s difficult. It can happen so easily that they are wrong. Always worth a try to test practically. Why not test with my setup, it will not last long to download ist. I see no data corruption.

5

I am more than happy to try your driver, but I think I have isolated the problem , i.e. The corrupted output, which I also detected using the GHI driver…

But as You are an fast and enthousiastic responder I will test your software asap :slight_smile:️

6

@ RoSchmi - i have tested your library. I add a ping command in the programme. at first glance it worked OK, no corrupted response, but after some attemps I got the same corrupted output from the 171 as I reported earlier.
To make it even stranger, I again tried pinging with the usb-xbee module , and to my surprise no errors…but also after a while the response was corrupted…???

I could not find any clous on the internet, so I have to rethink how to trace this:

  • power supply
  • accumalitive software bug in the 171
  • temperature issues
  • router (is it possible timing issues may disturb the pinging process)
  • ?

My question to you: try this experiment for a longer period…

7

Interesting!
I assume you left the code of my application as it is and only used the #define settings to adapt to the proper RN171 module and the Join Network function. Can you please post your code of program.cs that we can be sure to use exactly the same code.
Cheers
Roland

Edit: Better only the relevant parts of the code

8

@ freeck - Just to be sure … Have you setup rn171 serial as software handshake and it’s not in hardware hshake mode… there’s a cmd for that.

9

@ RoSchmi -

[quote]Interesting!
I assume you left the code of my application as it is and only used the #define settings to adapt to the proper RN171 module and the Join Network function.[/quote]
Yep…

   public partial class Program
    {

                mySerialBuffer = new SerialBuffer(256);
                usbSerial.Port.DataReceived += Port_DataReceived;
            // added lines 
                wifi_RN171._Command_Mode_Start();
                wifi_RN171._Command_Execute("ping 192.168.0.1 5");
      }
10

@ dobova - Software handshake

11

One step further!!

In case I ping the router, the response from the 171 is often corrupted, however when pinging my PC, there is never corrupted data !!! So somehow the 171 is disturbed by the pinging process to the router !!!???

12

Funny,
I think we should look directly in the driver in the _Serial_Listen thread, whether the data are corrupted. May be they get pseudo corrupted by the further processing in the driver.

13

No no,
nothing to do with the driver, the image shown is data coming from the 171 module without cerbuino…its a roving-issue…or microchip-issue

14

Yes, when I looked directly in the driver I saw that expected data were missing sometimes. But I think that your example with pinging is not sufficient to say the the RN171 is not reliable in other aspects. We should test in an example with data transmission. There was one post that reported of missing Bytes when large files were transmitted.

https://www.ghielectronics.com/community/forum/topic?id=14819&page=1

What are you going to do with the RN171?

15

I agree. This was not the only anomaly or functional issue I encountered:

  • using the ftp-client was not very succesfull as well, sometimes the data is not transfered without gettting any notification. The client protocol is very loosly coupled, so to say…
  • had problems with http-requests…hanging communication
  • only one socket available

I realy wonder wether its worthwile to put more energy in this module, I think I quit

16

which code did you use for ftp and http requests?
Only one socket is a known feature.
The alternatives are much more expensive. Of what do you think?

17

For ftp I used the library netmf.tools , adding a few lines of code:

  • opening the remote file server
  • then sending line by line the file to the server ( i have the source not available here…)

For the webserver I used the ghi libray. I composed a string with a javascript and was able to send real time data to the client, but sometimes the communication hung…

I intended to port the ftp code to the ghi library until I encountred the problem I reported…

Alternatives: perhaps the latest TI cc3200 module? Or:
https://www.ghielectronics.com/community/forum/topic?id=16276&page=2

18

Hi,
can you try this code. With this code I see no data corruption:

in ProgramStarted()

 
wifi_RN171.HttpRequestReceived +=wifi_RN171_HttpRequestReceived;
Thread pingHim = new Thread(_pingHim);
pingHim.Start();

…
…

 
void _pingHim()
        {
             
             while (true)
             {
                 wifi_RN171._Command_Mode_Start();
                 wifi_RN171._Command_Execute("ping 192.168.1.1 5");
                 wifi_RN171._Command_Mode_Exit();
                 Thread.Sleep(1000);
                 wifi_RN171._Command_Mode_Start();
                 wifi_RN171._Command_Execute("ping 192.168.1.140 5");
                 wifi_RN171._Command_Mode_Exit();
                 Thread.Sleep(1000);
             }

        }

in WiFi_RN171_Ro_43.cs

 
public class WiFi_RN171 : GTM.Module
{
        RN171_RoSchmi_Utility.SerialBuffer mySerialBuffer;
..
..
//in the constructor:
mySerialBuffer = new RN171_RoSchmi_Utility.SerialBuffer(256);
..
..
..

       Private void _Serial_Listen()
       { 
            _Serial_Byte_Buffer = new byte[1024];
            string dataLine = string.Empty;
            while (true)
            {
            ..
            ..
            if (_wifly.BytesToRead > 0)
            {
                    int i = _wifly.Read(_Serial_Byte_Buffer, 0, 1024);
                    //Debug.Print(RN171_RoSchmi_Utility.ByteExtensions.ToHexString    (_Serial_Byte_Buffer, "-"));
                    //RTS.Write(true);
                   
                    _Serial_Data_Received(_Serial_Byte_Buffer, i);
                   
                   mySerialBuffer.LoadSerial(_Serial_Byte_Buffer, 0, i);
                   while ((dataLine = mySerialBuffer.ReadLine()) != null)
                   {
                       Debug.Print(dataLine);
                   }
                   
                    //RTS.Write(false);
                }

..
..
                //Print message to the standard debug output
                case DebugMode.StandardDebug:
                    //Debug.Print(message);
                    break;
19

Unfortunately I did see the same corrupted data.
again: I can reproduce the results easily with a stand alone device, so no driver issue.

In the mean time I did an experiment with ftp, and again encountered strange behaviour, i.e. Auto-reset like events. So i am totally fed up with this device.
My advise is: Use it for standalone simple monitoring purposes, but don’t use the host interface because it is not robust.

20

Interesting,
I tried the code with two different RN171 devices (1. GHI RN171 module, 2. RN-VX on GHI-XBee-Adapter module). No data corruption.
When you look on your last picture you can see that the string from line 3 is interrupted by the line 4 and is then continued in line 5. Line 7 is continued in Line 10.
It looks as if two different sources would write to the serial port.
Since I do not see this behavior here, there might be different configuration of the RN171 module. Can you please post what you get from the get everything command?