Go Down

Topic: Problem with YunClient and long strings [solved] (Read 12188 times) previous topic - next topic

arduinoCoder

Oct 29, 2013, 01:43 pm Last Edit: Jan 06, 2014, 09:38 am by arduinoCoder Reason: 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.

federicofissore

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

arduinoCoder

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?

Code: [Select]
#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());
  } 
}

AlexandreB

Hello,
Maybe the problem is in available(). I use nightly builds on Mac Os.
Code: [Select]
 
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

arduinoCoder

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.

shoelessone

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 :)

federicofissore

Thank you guys, I was able to reproduce the issue using arduinoCoder's code and opened an issue on github
https://github.com/arduino/Arduino/issues/1753

federicofissore

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


GinVan

#8
Dec 26, 2013, 03:22 pm Last Edit: Dec 26, 2013, 03:57 pm by GinVan Reason: 1
I have been posting on this thread with a bridge/wifi issue: http://forum.arduino.cc/index.php?topic=190769.0
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.

GinVan

#9
Dec 27, 2013, 02:25 pm Last Edit: Dec 28, 2013, 03:28 am by GinVan Reason: 1
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?

arduinoCoder

Quote
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.

OttoF

hello Federico

Quote

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


when will, the update released ?

federicofissore

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

mamu


Jantje



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

Has it to do with the issue discribed here: http://forum.arduino.cc/index.php?topic=193540.msg1532112#msg1532112


I was wondering that as well.
Best regards
Jantje
Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

Go Up