Problem with YunClient and long strings [solved]

Official Hardware Classic Yún
1

Hi All

I have a problem where the YunClient or Bridge stops working. I am using the YunClient to connect to a PC which send out NMEA type strings and the shorter strings seems to work, but as soon as one of the longer strings (about 140 characters) is sent, it falls flat and nothing more is received. The only way to get it back online is to do a reset.

Thinking it might be a baud rate issue between linino and 32u4, I tested it by running the YunSerialTerminal example and doing a telnet to the PC and this works 100%, which makes me believe it is an issue with the Bridge. I changed the buffer size in YunClient.h, but this does not solve the problem. I am not sure how to verify that it is a Linino or 32u4 side problem.

I have looked in the forums for an solution, but could not find any. I have however seen there is a known issue with the bridge and SD card and this might be a related problem.

Any advice/help will be appreciated.

2

There is a known and fixed bug with Bridge. Can you download a nightly and check if the problem still occurs? http://arduino.cc/en/Main/Software#toc4

3

I tried it with nightly and the result is the same. The sketch I used to obtain the result is included below.

The strings being sent by the PC (roughly every 2 seconds) are the following:

$PSSH,DSS,192117,0,876,,5*6D
$PSSR,QST,ALL*15
$PSSH,STA,ALL,ON,BOTH,LOW,50,CONTINUOUS,10,40,MANUAL,50,1000x512,NONE,0,LEFT,78,91,95,95,95,95,95,95,RIGHT,74,91,98,98,98,99,99,99,0.0*68

It is the longer $PSSH,STA string that causes the Yun to malfunction. The shorter strings comes through OK, but after the long string, nothing is received anymore. I tried it with console instead of Serial, but then the console also dies, which makes me believe it is the Bridge software that fails.

I have used Arduinos quite a bit and can do some programming, but on the Linux/python side I am still very much a newbie. Is there some pointers on how to try and determine where the problem is (32u4 of linino side) and to rectify it?

#include <YunClient.h>

YunClient client;
IPAddress server(192,168,0,10); 

void setup() {
  Serial.begin(9600);  
  Bridge.begin();
  while (!Serial);

  Serial.print("Connecting...");
  if (client.connect(server, 5555)){
    Serial.println("Done!");
  } else {
    Serial.println("Fail");
    while (1);
  }
}

void loop() {
  if (client.available() > 0){
    Serial.write(client.read());
  }  
}
4

Hello,
Maybe the problem is in available(). I use nightly builds on Mac Os.

int dispo = client.available(); 
  while (dispo)
  {
    char c = client.read();
    Console.print(dispo);
    Console.print(".");
    dispo = client.available();
    Console.print(" ");
  }

Gives as output :
64. 63. 62. 61. 60. 59. 58. 57. 56. 55. 54. 53. 52. 51. 50. 49. 48. 47. 46. 45. 44. 43. 42. 41. 40. 39. 38. 37. 36. 35. 34. 33. 32. 31. 30. 29. 28. 27. 26. 25. 24. 23. 22. 21. 20. 19. 18. 17. 16. 15. 14. 13. 12. 11. 10. 9. 8. 7. 6. 5. 4. 3. 2. 1. 64. 63. 62. 61. 60. 59. 58. 57. 56. 55. 54. 53. 52. 51. 50. 49. 48. 47. 46. 45. 44. 43. 42. 41. 40. 39. 38. 37. 36. 35. 34. 33. 32. 31. 30. 29. 28. 27. 26. 25. 24. 23. 22. 21. 20. 19. 18. 17. 16. 15. 14. 13. 12. 11. 10. 9. 8. 7. 6. 5. 4. 3. 2. 1.<- freeze here just after the dot

I think that the last client.available() freeze the Yun because the space after the dot is not shown. The returned value count two times from 64 to 1. Quite strange.
Hope this help.
Thanks

5

Thanks for the reply. I was a bit pushed for time and eventually implemented it using an Arduino Ethernet. I will hopefully have some time early in the new year to have a look at that again and find a solution.

6

FYI, I'm not sure if your problem is the same, but I ended up having to implement as simple "buffer", where if i had a string over a certain length then I split it up into smaller parts, say 100 characters each, and write them to different "keys" using the Bridge client. Then on the other side (either linux or arduino) I rebuild them, check the next index and adding to the string until there is an empty buffer index.

I'm using the word "buffer" a bit liberally probably, it's nothing fancy :slight_smile:

7

Thank you guys, I was able to reproduce the issue using arduinoCoder's code and opened an issue on github

8

I'm happy to say we have solved this. Details here

Until we release an updated package, here is what you need to do.

  • Using SSH or YunSerialTerminal, connect to the linux side of the yun.
  • Edit file /usr/bin/run-bridge, changing "python bridge.py" with "python -u bridge.py" (ie: add a "-u" to the command line)
  • Edit file /usr/bin/kill-bridge, again changing "python bridge.py" with "python -u bridge.py" (ie: add a "-u" to the command line)
  • Type kill-bridge and re-run your sketch
9

I have been posting on this thread with a bridge/wifi issue: HttpClient sketch, crashing after about three cycles. <possible solution> - Arduino Yún - Arduino Forum
I am downloading very small files (two small integers). The yun hangs eventually - almost every time.

Will the solution suggested here work to resolve this problem?
I am not at my computer now to test. Please give some input... As the yun just has not been stable... Failing most of the time.

10

I have have edited the files listed above... Though on a quick read here I am not sure that this thread is 100% related to the issue I am having with the HttpClient.

After edit:
Using client.get on a cycle of with a delay(10000)... Downloading either blank pages or pages with two int numbers... The program hangs at aprox 76 cycles (give or take)... Each time.
The last run - I was testing on downloading blank pages.
My Internet is not the issue. Even if there is a slight interruption of service (which I doubt in my case) there should be a recovery process (for stalled scripts or latent Internet services) in place. Yes/No?
Is there a solution I have missed?

11

I'm happy to say we have solved this.

I have tried the solution in my real world setup and it works!

Thanks so much.

12

hello Federico

Until we release an updated package, here is what you need to do.

when will, the update released ?

13

We are having some hard to solve technical difficulties. I'll keep you posted

14

Has it to do with the issue discribed here: ttyACM0 unstable - #7 by sonnyyu - Arduino Yún - Arduino Forum

15

mamu:

[quote author=Federico Fissore link=topic=196091.msg1534885#msg1534885 date=1389003802]
We are having some hard to solve technical difficulties. I'll keep you posted

Has it to do with the issue discribed here: ttyACM0 unstable - #7 by sonnyyu - Arduino Yún - Arduino Forum

[/quote]
I was wondering that as well.
Best regards
Jantje

16

Hello,
The -u option to run the Bridge solve the problem for me. XD Thank you very much.
myYunClient.available() still give a list of not strictly decreasing numbers. Maybe it is the right behavior. But it is not a problem because the important thing is that the null return is correct.
So I can now correctly parse the response of the IoT server I use.
Regards
Alexandre

17

I would just like to confirm that this problem has been solved with the latest Yun image "out of the box".