[Tinyos-devel] again about the baudrate issue for telos
Eric Decker
cire831 at gmail.com
Thu Sep 4 08:12:12 PDT 2008
On Thu, Sep 4, 2008 at 6:39 AM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>wrote:
> Hi!
>
> On Thu, 4 Sep 2008, Eric Decker wrote:
>
> On Thu, Sep 4, 2008 at 12:16 AM, Andreas Köpke <koepke at tkn.tu-berlin.de
>> >wrote:
>>
>> Am Donnerstag, den 04.09.2008, 00:13 -0700 schrieb Eric Decker:
>>>
>>>>
>>>>
>>>> On Wed, Sep 3, 2008 at 11:40 PM, Andreas Köpke <koepke at tkn.tu-berlin.de>
>>>> wrote:
>>>> You try to send 115200 at the same time in _both_ directions.
>>>> That is
>>>> indeed a problem.
>>>>
>>>>
>>>> Why do you say this? It is full duplex. And if the interrupt service
>>>> time wasn't so long it should work.
>>>>
>>>>
>>>> So what are you hinting at?
>>>>
>>>>
>>>> eric
>>>>
>>>
>>> The ISR time is short enough for half-duplex, but too long for
>>> full-duplex.
>>>
>>
>>
>> The outgoing code I've looked at is pretty short so I don't think that
>> would
>> be a problem.
>>
>> However the incoming receive code definitely takes too long.
>>
>
> The receive code is too long only when the mote is also sending a lot of
> data, right? Does this mean that we could still keep the 115200 baudrate by
> adding some sort of resource control between sending and receiving? Or we
> should just switch to 57600?
>
What I've observed is the receive code is too long period. So that bytes
get missed in the incoming stream. This
depends somewhat on what else is going on in the system but can be
replicated fairly easily. I found 57600 was
pretty solid and didn't have time to futher dig into it. Keep in mind I'm
using threads and so have thread checks on
the end of the lowest level of interrupt code too.
It doesn't seem to depend on outgoing traffic. In my test case there is
none.
The easy thing to do is to just make the default 57600 so other folks have a
reasonably quick but stable starting
point.
eric
>
> --
> Razvan ME
>
> So I'd say we are agreeing.
>>
>> eric
>>
>>
>>
>>>
>>
>>
>>>> Am Mittwoch, den 03.09.2008, 18:40 -0400 schrieb Razvan
>>>> Musaloiu-E.:
>>>>
>>>> > Hi!
>>>> >
>>>> > I attached a small application and a Python testing script that
>>>> shows that
>>>> > 115200 doesn't work reliably for telos. The nesC application is
>>>> sending
>>>> > packets back to back while the script will accept all the
>>>> incoming packets
>>>> > and tried from time to time to send some (one at a time). Using
>>>> the 57600
>>>> > (enabled by default in the application) the acks work properly.
>>>> When the
>>>> > 115200 is enabled the acks stop working (or they come very
>>>> infrequently).
>>>> >
>>>> > This issue was discussed before [1] but no solution surface from
>>>> that. In
>>>> > this context I think it would be good to switch to safer 57600
>>>> rate for
>>>> > now. Is anybody against this? :P
>>>> >
>>>> > Note: I don't have a Windows TinyOS installation so I only
>>>> tested on Linux
>>>> > on real machines and VMWare.
>>>> >
>>>> > [1]
>>>> http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-April/thread.html#2651
>>>> >
>>>> > --
>>>> > Razvan ME
>>>>
>>>>
>>>> --
>>>> Eric B. Decker
>>>> Senior (over 50 :-) Researcher
>>>> Autonomous Systems Lab
>>>> Jack Baskin School of Engineering
>>>> UCSC
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Eric B. Decker
>> Senior (over 50 :-) Researcher
>> Autonomous Systems Lab
>> Jack Baskin School of Engineering
>> UCSC
>>
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080904/2070a03d/attachment.htm
More information about the Tinyos-devel
mailing list