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

[Miklos Maroti]

Can someone test the following completely untested patch with 115200? Miklos

On Mon, Mar 2, 2009 at 9:36 PM, Eric Decker <cire831 at gmail.com> 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?
>
> eric
>
> 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
> UCSC
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HplMsp430Usart1P.nc
Type: application/x-netcdf
Size: 11787 bytes
Desc: not available
Url : https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090302/7da553b0/attachment-0001.nc