Update on serial I/O considerations with Sun SPOT and TrackBot
3 views
Skip to first unread message
Bruce Boyes
Jan 7, 2009, 6:51:56 PM1/7/09
to Trac...@googlegroups.com
Please see, and if interested join, this project:
https://swarm-of-brian.dev.java.net/
I am also BCC-ing the mail list for this project.
Brian and I had a lengthy Skype call today and will have a regular call at 11 AM MST going forward, starting Jan 09.
Today we went over some possible explanations for the loss of serial communication with TrackBot from SunSPOT. I ran a short test from a PC serial port to TrackBot with queries and 1000 msec beeps, repeated every 2 seconds and every 500 msec. Beeping at a higher rate than the length of the beep just reloads the beep counter and the beep goes on, as designed and as you would expect. No problem. TrackBot source code confirms this. So the beeping is not causing the problem.
On the SPOT app however there is an outgoing message buffer which can, and is, becoming over-full. When this happens due to too many beeps (say when a bump is detected in the SPOT accelerometer) then other messages such as sensor reading get discarded. The code which issued the message then may interpret that as lost comms after some timeout. So "too many" beeps appears to be the problem. "Too many" serial messages from SPOT to TrackBot can also cause the same problem.
Brian will look into this and ping Shawn if needed.
There may be changes to the code which will help. Just making the buffer (64 bytes currently) larger in this case will only add more latency to messages, and it can still fill up. At 19.2 kbaud and 10 bits/character, and an average of 10 bytes/message, 64 bytes will queue up 6+ messages (20 simple ones like "?S<cr>") and takes 33 msec to completely fill or empty. TrackBot can accept 19.2 kbaud chars non stop, but you should throttle sending more messages by waiting for the ACK ('+' char) for each. If you do, then TrackBot can never get overwhelmed with messages.
The buffer is emptied at a 19.2 kbaud rate by TrackBot's serial input. We can't easily increase that baud rate due to using a somewhat imprecise RC oscillator in the Cortex AVR (the SPOT eDemo AVR also uses the built-in RC oscillator). So neither SPOT or TrackBot can do reliable faster serial I/O without some redesign (quartz oscillator as the main crystal).
Thinking about this a bit, it becomes clear that the SPOT app should not be buffering up an unlimited number of messages, without waiting for the ACK from each. The issue is that there are several threads on the SPOT app which can independently issue messages. Apparently those threads are not waiting for an ACK from a previous message before sending a new one. If there are 'n' threads and each waits for an ACK from each message, then if the outgoing buffer can hold 'n' messages it should never overflow. This is not how the SPOT app serial IO code works at the moment but we should possibly change to this approach. This gets a bit sticky since once messages are enqueued by various threads the queue doesn't know which thread issued which message, and therefore can't know to whom it should send ACKs.
At the very least the LEDs could flash blue if the buffer is full and red only if there really is no comm with the TrackBot (how is this determined?), or if serial errors occur (such as no ACK to a message). Then we can
So join us Friday if you are interested. Skype can do conference calls but the call leader needs to add participants. My Skype ID is just bbo...@systronix.com - contact me via Skype chat and tell me you want to be on the call list.
best regards
Bruce Boyes
https://swarm-of-brian.dev.java.net/
I am also BCC-ing the mail list for this project.
Brian and I had a lengthy Skype call today and will have a regular call at 11 AM MST going forward, starting Jan 09.
Today we went over some possible explanations for the loss of serial communication with TrackBot from SunSPOT. I ran a short test from a PC serial port to TrackBot with queries and 1000 msec beeps, repeated every 2 seconds and every 500 msec. Beeping at a higher rate than the length of the beep just reloads the beep counter and the beep goes on, as designed and as you would expect. No problem. TrackBot source code confirms this. So the beeping is not causing the problem.
On the SPOT app however there is an outgoing message buffer which can, and is, becoming over-full. When this happens due to too many beeps (say when a bump is detected in the SPOT accelerometer) then other messages such as sensor reading get discarded. The code which issued the message then may interpret that as lost comms after some timeout. So "too many" beeps appears to be the problem. "Too many" serial messages from SPOT to TrackBot can also cause the same problem.
Brian will look into this and ping Shawn if needed.
There may be changes to the code which will help. Just making the buffer (64 bytes currently) larger in this case will only add more latency to messages, and it can still fill up. At 19.2 kbaud and 10 bits/character, and an average of 10 bytes/message, 64 bytes will queue up 6+ messages (20 simple ones like "?S<cr>") and takes 33 msec to completely fill or empty. TrackBot can accept 19.2 kbaud chars non stop, but you should throttle sending more messages by waiting for the ACK ('+' char) for each. If you do, then TrackBot can never get overwhelmed with messages.
The buffer is emptied at a 19.2 kbaud rate by TrackBot's serial input. We can't easily increase that baud rate due to using a somewhat imprecise RC oscillator in the Cortex AVR (the SPOT eDemo AVR also uses the built-in RC oscillator). So neither SPOT or TrackBot can do reliable faster serial I/O without some redesign (quartz oscillator as the main crystal).
Thinking about this a bit, it becomes clear that the SPOT app should not be buffering up an unlimited number of messages, without waiting for the ACK from each. The issue is that there are several threads on the SPOT app which can independently issue messages. Apparently those threads are not waiting for an ACK from a previous message before sending a new one. If there are 'n' threads and each waits for an ACK from each message, then if the outgoing buffer can hold 'n' messages it should never overflow. This is not how the SPOT app serial IO code works at the moment but we should possibly change to this approach. This gets a bit sticky since once messages are enqueued by various threads the queue doesn't know which thread issued which message, and therefore can't know to whom it should send ACKs.
At the very least the LEDs could flash blue if the buffer is full and red only if there really is no comm with the TrackBot (how is this determined?), or if serial errors occur (such as no ACK to a message). Then we can
So join us Friday if you are interested. Skype can do conference calls but the call leader needs to add participants. My Skype ID is just bbo...@systronix.com - contact me via Skype chat and tell me you want to be on the call list.
best regards
Bruce Boyes
-------
WWW.SYSTRONIX.COM
----------
Real embedded Java and much more
+1-801-534-1017 Salt Lake City, USA
Reply all
Reply to author
Forward
0 new messages