[Tinyos-devel] again about the baudrate issue for telos

Eric Decker cire831 at gmail.com
Mon Mar 2 12:36:34 PST 2009

My expericence is that 57600 is reliable.  But I haven't analyzed the failure
modes for higher speed so don't know what the exact failure path is so can't
explain why it works.

The conjecture and it is conjecture is that the interrupt level path
is too long so
bytes get missed.  Also the interrupt path is potentially variable
which exacerbates
the analysis.

Could you post your code so we can take a look at what you did to fix things?


On Mon, Mar 2, 2009 at 6:41 AM, Chieh-Jan (Mike) Liang
<cliang4 at cs.jhu.edu> wrote:
> One question for people who are using 57600 with C serial forwarder.
> Is it always reliable for you? Or, just "more" reliable than 115200?
> In my case, 57600 didn't solve the "write fail" problem, and I had to
> add some code to make it reliable for me.
> Thanks
> Mike
> On Feb 18, 2009, at 4:48 PM, Philip Levis wrote:
>> On Feb 17, 2009, at 9:14 PM, Jorge Ortiz wrote:
>>> On Tue, Feb 17, 2009 at 5:42 PM, Philip Levis <pal at cs.stanford.edu>
>>> wrote:
>>> On Feb 17, 2009, at 8:42 AM, Jorge Ortiz wrote:
>>> If we're taking a poll, I vote to slow it down to 57600.  I've had
>>> trouble with the higher speed with and without the serial
>>> forwarder.  At 57600 all my serial-related reliability problems went
>>> away and the code I was working with was significantly more stable.
>>> Jorge
>>> Can you be more specific than "I've had trouble?" Which direction?
>>> What motes? What operating system? Which serial forwarder?
>>> I was actually using the b6lowpan stack on telosb and epic in Ubuntu
>>> 8.04 and 7.10 and the mote->pc had corrupted packets and random
>>> drops that caused several things to happen:
>>> 1)  The ip-driver code was timing out because the mote was not
>>> successfully acking control packets sent from the driver to the
>>> mote  (Stephen will can fill in the details here)
>> Right -- this makes sense given the prior comments on failure cases.
>> When the mote is sending as quickly as possible, it's hard to get it
>> to receive packets.
>>> 2)  When/if the ip-driver was successfully started, packets that
>>> came in on from the mote were getting corrupted or dropped when they
>>> were being forwarded from the mote to the PC, so none of the motes
>>> were able to associate with the base mote and get IP addresses, etc.
>> This is different. Mote->PC packets were being corrupted? That is very
>> strange. The mote rate-limits itself. This sounds more like the issue
>> that David Moss raised on the FTDI driver or USB hubs. Were they
>> corrupted at the serial forwarder? This could be something like a DCO
>> calibration issue...
>>> Any decision that's made it more or less fine with me, except i
>>> think it should be noted that the fast rate does cause reliability
>>> problems with serial communication on telosb.  Generally I'd rather
>>> have something work at a slower rate (and have those who know the
>>> details of the stack make their own adjustments to speed up the
>>> communication) than to have the unreliable serial communication make
>>> the application not work at all.
>> From an "I need to get this working" standpoint, you're completely
>> right. 57600 is the right thing for you to do. From a system design
>> and implementation standpoint, though, you want to figure out what the
>> actual problem is and fix it. If the answer is that the only way to
>> fix it is to switch to 57600, that's one thing; if it turns out
>> there's a bug in the stack or toolchain, we should fix it.
>> Phil
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering

More information about the Tinyos-devel mailing list