Thanks for the answer. But you did not not get the question
Probably I should have not used the word "random". I just meant that the
delay was unpredictable.
I had already significanly removed that randomness due to CSMA backoffs in
the BaseStation app.
Max initial backoff was reduced for 0.9ms from 10ms and for messages of type
AM_SYNCHMSG, there is a fixed backoff of 3/32ms
I had modified the requestInitialBackoff( event handler of CC2420CsmaP.nc
as:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
async event void SubBackoff.requestInitialBackoff(message_t *msg) {
am_id_t type=((cc2420_header_t*)(msg->data -
sizeof(cc2420_header_t)))->type;
if(type==AM_SYNCHMSG)
{
// call Leds.led2Toggle();
call SubBackoff.setInitialBackoff (3);
}
else
call SubBackoff.setInitialBackoff ( call Random.rand16() % (0x3 *
CC2420_BACKOFF_PERIOD)); // so max backoff is 0.9 ms
signal RadioBackoff.requestInitialBackoff[type](msg);
}
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
And i had removed congestion-retrial by changing the attemptsend()
ofCC2420TransmitP.nc as:
(in case a congestion, the packet is dropped- no retrial! and sendDone is
signalled by signalDone( ECONGESTION ))
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
void attemptSend() {
uint8_t status;
bool congestion = TRUE;
atomic {
if (m_state == S_TX_CANCEL) {
call SFLUSHTX.strobe();
releaseSpiResource();
call CSN.set();
m_state = S_STARTED;
return;
}
call CSN.clr();
status = m_cca ? call STXONCCA.strobe() : call STXON.strobe();
if ( !( status & CC2420_STATUS_TX_ACTIVE ) ) {
status = call SNOP.strobe();
if ( status & CC2420_STATUS_TX_ACTIVE ) {
congestion = FALSE;
}
}
m_state = congestion ? S_SAMPLE_CCA : S_SFD;
call CSN.set();
}
if ( congestion ) {
// no congestion reattempt
atomic
{
call SFLUSHTX.strobe();
releaseSpiResource();
call CSN.set();
m_state = S_STARTED;
signalDone( ECONGESTION );
return;
}
} else {
call BackoffTimer.start(CC2420_ABORT_PERIOD);
}
}
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Moreover, the call to MoteIF.send returns as soon as the BaseStation app
acknownedges the receipt at the serial link (i.e before sending thru radio)
so the random delay of 5 to 25 ms is before the instant of posting a radio
send tack
the delay is at the serial link
Here is a log of the output. the difference b/w the number just after "Query
scheduled " and "Successfully sent query at nwTime" denotes the time gap in
millis bw call and return of MoteIF.send method
Query scheduled at: 103992 Successfully sent query at nwTime=104004
Query scheduled at: 104382 Successfully sent query at nwTime=104404
Query scheduled at: 106332 Successfully sent query at nwTime=106339
Query scheduled at: 106566 Successfully sent query at nwTime=106579
Query scheduled at: 106722 Successfully sent query at nwTime=106739
Query scheduled at: 106956 Successfully sent query at nwTime=106963
Query scheduled at: 107112 Successfully sent query at nwTime=107123
"log_15_5_2008_18_27" 869L, 34759C
(although i have thought of implementing the accurate time management in the
BaseStation app but i wd be glad if someone saves me this pain)
Please help!
Regards,
Abhishek Anand
IIT Guwahati
On Mon, Jun 16, 2008 at 10:13 PM, Michael Schippling <[EMAIL PROTECTED]>
wrote:
> "Randomness" of time taken to broadcast is a feature rather than a bug.
> Most of the indeterminate delay is due to MAC backoff and free channel
> testing. If someone else is transmitting you have to wait until they're
> done. Search this list for a lot of discussion on radio timing.
>
> A workaround would be to use some kind of time sync and stamping
> in your messages.
>
> MS
>
> Abhishek Anand wrote:
>
>> Hi,
>> I'm facing a similar problem!
>> My protocol requires a strict time control on when the the packets are
>> actually transmitted from the base station.
>> I have programmed by base-station-mote with the BaseStation app in
>> /$TOSROOT/apps/ folder.
>> On the PC, my java program uses a the MoteIF class to send the packets
>> But unfortunately, it takes randomly a value b/w 8 to 25ms for the packets
>> to be ultimately broadcasted thru radio.
>> I mean the call to
>> MoteIF.send(MoteIF.TOS_BCAST_ADDR, smsg);
>> in java takes anything b/w 8-25ms to return.
>> This is causing a lot of problem for me because my application requires
>> fine timing control
>> I'm okay with a delay of 20ms but is there any way to remove the
>> randomness of the time taken?
>> In other words, is it possible to do something so that there is a FIXED
>> gap of few ms b/w call to MoteIF.send
>> and the the commencement of the radio transmission of the packet at the
>> Base-station mote?
>> Regards,
>> Abhishek Anand
>> IIT Guwahati
>>
>> On Mon, Jun 16, 2008 at 9:00 PM, Andrey Gursky <[EMAIL PROTECTED]<mailto:
>> [EMAIL PROTECTED]>> wrote:
>>
>> Hi!
>>
>> Thanks Janos for your advices!
>>
>> I've changed the serial speed to 230400 (because of serial speed
>> declarations in GNU/Linux). It works :)
>> After simple test with printf() there is about 1 Kbyte/s :(
>> Than I've changed printf() test application. I supply printf() a
>> string with about 250 characters, then flush(). I could read about
>> 8.5 Kbyte/s. It's really more than standard for IRIS 57600 Kbit/s,
>> but it is still less than standard for other platforms. I've used
>> PrintfClient to get the data.
>>
>> What do you think, is there a bottleneck easy to reprogram? I
>> haven't tested yet how much traffic I can transmit throw ZigBee. If
>> this will not more than 8.5 Kbyte/s then there is no sense to work
>> around serial communication.
>>
>> Best regards,
>> Andrey
>>
>>
>> > Andrey:
>> >
>> > I think the code change you're proposing should work.
>> >
>> > >So atm128 doesn't have speed enough to guarantee 256 KBit/s
>> > >data connection pc<->mote? If one want this, one should
>> > >implement a different platform with another microcontroller?
>> >
>> > There's a good chance that it works. Just give it a try. BTW, I
>> bet you'll never
>> > be getting 250kbps worth of zigbee payload in through the radio...
>> >
>> > >By the way, MIB520 has also a microcontroller on board.
>> > >Is USART of Mote directly connected to FTDI chip or
>> > >throw this microcontroller?
>> >
>> > It's hooked up directly to the FTDI chip.
>> >
>> > >It seems to be not so easy even at the standard serial speed :(
>> > Obviously, 57600bps might not be sufficient to push through all
>> the incoming
>> > radio traffic...
>> >
>> > Janos
>> >
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>
>> [mailto:[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>]
>> > On Behalf Of Andrey Gursky
>> > Sent: Thursday, June 12, 2008 6:00 AM
>> > To: [email protected]
>> <mailto:[email protected]>
>> > Subject: Re: [Tinyos-help] Mote-PC serial speed increasing
>> >
>> > Thanks Janos!
>> >
>> > > On the iris, the ubrr0 register is set, at initialization time,
>> to a calibrated
>> > > value for 57600bps. You can change the baud rate by writing
>> this register.
>> > >
>> >
>> > I've found in $TOSROOT/tos/chips/atm128 this code:
>> >
>> > command error_t Init.init() {
>> > if (PLATFORM_BAUDRATE == 19200UL)
>> > m_byte_time = 200; // 1 TMicor ~= 2.12 us, one byte = 417us
>> ~= 200
>> > else if (PLATFORM_BAUDRATE == 57600UL)
>> > m_byte_time = 68; // 1 TMicor ~= 2.12 us, one byte = 138us
>> ~= 65
>> > return SUCCESS;
>> > }
>> >
>> > I could add the line like this (or I should seek on to find ubrr0?)
>> > ..
>> > else if (PLATFORM_BAUDRATE == 256000UL)
>> > m_byte_time = ----->15<-----; // 1 TMicor ~= 2.12 us, one
>> byte
>> > = ----->31us<----- ~= ----->15<-----
>> > ..
>> >
>> > >
>> > > This should work with a MIB520, but it is problematic with a
>> MIB510. Should
>> > > you have the former programming board, the bottleneck will
>> probably be the
>> > > interrupt load on the mote in the pc->mote direction. Note
>> that the serial
>> > > stack doesn't buffer outgoing packets (mote->pc), so the app
>> must assume
>> > > a lossy mote->pc link.
>> > >
>> >
>> > I have MIB520 (with usb) :)
>> > So atm128 doesn't have speed enough to guarantee 256 KBit/s data
>> connection
>> > pc<->mote? If one want this, one should implement a different
>> platform
>> > with another microcontroller?
>> >
>> > By the way, MIB520 has also a microcontroller on board. Is USART
>> of Mote directly
>> > connected to FTDI chip or throw this microcontroller?
>> >
>> > There is one post seems to achieve similar goal: the highest speed
>> :)
>> >
>>
>> https://www.millennium.berkeley.edu/pipermail/tinyos-help/2008-June/034218.html
>> >
>> > It seems to be not so easy even at the standard serial speed :(
>> >
>> > Could someone point me to reference where I can read about what
>> the atm128x
>> > has yet free to use as quick and reliable communication with PC
>> (SPI, I2C)?
>> > Or the best idea were to use other small design to exchange
>> messages between
>> > PC and ZigBee motes?
>> >
>> >
>> >
>> > >
>> > > -----Original Message-----
>> > > From: [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>
>> [mailto:[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>]
>> > > On Behalf Of Andrey Gursky
>> > > Sent: Tuesday, June 03, 2008 6:16 AM
>> > > To: [email protected]
>> <mailto:[email protected]>
>> > > Subject: [Tinyos-help] Mote-PC serial speed increasing
>> > >
>> > > Hi tinyOS-community!
>> > >
>> > > It seems possible (according datasheet) to use USART of
>> ATmega128x in >57600
>> > > speed mode. Thus ZigBee functions of 250 Kbit/s it would be
>> nice to have this
>> > > speed also between basestation and PC.
>> > > Does somebody know exactly, whether it would be as of some
>> other reasons not
>> > > possible? Or have I to alter configuration in .../chip/atm1281
>> to get this
>>
>> > > working?
>> > >
>> > >
>> > > Best regards,
>> > > Andrey
>> > >
>> > > P.S. Particularly I'm interesting in iris-motes.
>> > > _______________________________________________
>> > > Tinyos-help mailing list
>> > > [email protected]
>> <mailto:[email protected]>
>> > >
>>
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>> > >
>> > _______________________________________________
>> > Tinyos-help mailing list
>> > [email protected]
>> <mailto:[email protected]>
>> >
>>
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>> >
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
