[Tinyos-devel] again about the baudrate issue for telos
pal at cs.stanford.edu
Wed Feb 18 13:48:13 PST 2009
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>
> 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.
> 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
> 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.
More information about the Tinyos-devel