[Tinyos-devel] again about the baudrate issue for telos
Chieh-Jan (Mike) Liang
cliang4 at cs.jhu.edu
Mon Mar 2 15:06:37 PST 2009
In my case, when the mote->pc packet rate is high, I get a a lot of
"write fail" from the C serial forwarder, even at 57600. Here are my
changes to the C serial forwarder:
1.) I have byte spacing to wait a little bit after sending each byte.
Currently, this is 50 micro-sec, but I think it can be lower. Byte
spacing was also recently added to the python T2 serial stack, tos.py.
The hope is that the mote has some more time to handle the interrupt.
2.) Byte spacing helps a lot, but there were still some "write fail".
So, I retry sending a packet if such case happens. I believe the Cpp
serial forwarder already does this, but not the C version.
I attached a patch. Please let me know if you see something weird.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1797 bytes
Desc: not available
Url : https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090302/c5dc53ff/attachment.obj
-------------- next part --------------
On Mar 2, 2009, at 3:36 PM, Eric Decker wrote:
> 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.
>> 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>
>>>> 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
>>>> 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
>>>> 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
>>>> 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,
>>> This is different. Mote->PC packets were being corrupted? That is
>>> strange. The mote rate-limits itself. This sounds more like the
>>> that David Moss raised on the FTDI driver or USB hubs. Were they
>>> corrupted at the serial forwarder? This could be something like a
>>> 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
>>>> 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
>>> 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.
>>> Tinyos-devel mailing list
>>> Tinyos-devel at millennium.berkeley.edu
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
More information about the Tinyos-devel