Sinan, The problem is that it's not possible to tell the radio stack to transmit a message at time t. The time delay between TimeSyncAMSend.send() being called and the message actually going out has a significant jitter (clear channel assessment, collision avoidance mechanism is going on in between).
However, there are couple of ways to figure out if timestamping works well. 1. Keep your transmitter as it is, transmitting a message approximately every 5 seconds. Set up two receivers with the receiver code you currently have. The time delay between receiving messages i and j should be the same on both receivers. 2. Modify your transmitter to report the transmit timestamps of each message sent (use the PacketTimestamp interface in TimeSyncAMSend.sendDone() ). The difference between the transmit timestamps of messages i and j should be the same as the delay between receiving those messages at the receiver. Janos 2010/8/6 Sinan Yildirim <[email protected]>: > Hi Janos, > > thanks for your reccomendations. I have tried it but however I think that > there are inconsistencies between the timestamps I receive. > > One of the nodes periodically sends a beacon in every 5 seconds using a > AlarmMilli and TimeSyncAMSend. When the other nodes receive and timestamp > these messages, I notice that there is a big error on the difference of > timestamps of two consecutive beacon receivals. For example, I get 5261323 > and 5189177 values at the same node for the difference. > > Is it because DCO calibration? Or any other thins to consider? > > Thanks for your valuable comments and helps... > > 05 Ağustos 2010 18:47 tarihinde Janos Sallai <[email protected]> > yazdı: >> >> Sinan, >> >> I actually have an alternative cc2420 radio stack implementation under >> tinyos-2.x-contrib/vu that does what you want. That is, the msp430 >> timer subsystem is reprogrammed such that timer A is the 32kHz timer >> and timer B is the micro timer. The radio stack uses the micro timer >> for timestamping, gets rid of the timestamp queue (historically a >> source of lots of bugs), eliminates spurious acks (no ack is sent out >> unless received packet is accepted by higher layers of the radio >> stack), and much more. It doesn't do security, though.This stack uses >> the same driver infrastructure as the rf2xx stack for the iris. >> >> To use my cc2420 stack, follow the steps below: >> 1. Make sure you have the latest tinyos sources (google code SVN or >> sourceforge CVS are both fine). >> 2. Check out tinyos-2.x-contrib/vu from the CVS at sourceforge. >> 3. Do a cd to the local directory where tinyos-2.x-contrib/vu is >> checked out, and type "source setenv" (without the double quotes) to >> set up some environment variables. >> 4. Change "include $(MAKERULES)" to "include $(VUMAKERULES)" in the >> applications makefile. This will make sure that the code in the >> tinyos-2.x-contrib/vu tree takes precedence over the ones in the main >> tinyos tree. >> 5. Compile the application with make telosb as usual. >> >> Janos >> >> 2010/8/5 Sinan Yildirim <[email protected]>: >> > Hi again, >> > >> > I wanted to add some comments to my last reply. >> > >> > When I connect Timer A to SFD, I could get time= 0 from async event void >> > CaptureSFD.captured( uint16_t time ) and it means all timestamps are >> > invalid. Also, I could not get time values LocalTimeMicroC component and >> > it >> > always returns 0. >> > >> > However, when I remove my modifications and connect SFD to Timer B >> > again, I >> > can get time values LocalTimeMicroC component which uses timer A. >> > >> > So should I do something to time subsystem when I connect timer A to >> > SFD? >> > >> > >> > 05 Ağustos 2010 12:35 tarihinde Sinan Yildirim <[email protected]> >> > yazdı: >> >> >> >> Hi Thomas, >> >> >> >> I am working on a similar platform to Telos I think... (It is Genetlab >> >> Sensenode platform). I have connected TimerA to the SFD line as you >> >> said. I >> >> have modified the file HplCC2420InterruptsC. >> >> >> >> configuration HplCC2420InterruptsC { >> >> >> >> provides interface GpioCapture as CaptureSFD; >> >> provides interface GpioInterrupt as InterruptCCA; >> >> provides interface GpioInterrupt as InterruptFIFOP; >> >> >> >> } >> >> >> >> implementation { >> >> >> >> components HplMsp430GeneralIOC as GeneralIOC; >> >> components Msp430TimerC; >> >> components new GpioCaptureC() as CaptureSFDC; >> >> CaptureSFDC.Msp430TimerControl -> Msp430TimerC.ControlA0; >> >> CaptureSFDC.Msp430Capture -> Msp430TimerC.CaptureA0; >> >> // CaptureSFDC.Msp430TimerControl -> Msp430TimerC.ControlB1; >> >> // CaptureSFDC.Msp430Capture -> Msp430TimerC.CaptureB1; >> >> CaptureSFDC.GeneralIO -> GeneralIOC.Port41; >> >> >> >> components HplMsp430InterruptC; >> >> components new Msp430InterruptC() as InterruptCCAC; >> >> components new Msp430InterruptC() as InterruptFIFOPC; >> >> InterruptCCAC.HplInterrupt -> HplMsp430InterruptC.Port14; >> >> InterruptFIFOPC.HplInterrupt -> HplMsp430InterruptC.Port10; >> >> >> >> CaptureSFD = CaptureSFDC.Capture; >> >> InterruptCCA = InterruptCCAC.Interrupt; >> >> InterruptFIFOP = InterruptFIFOPC.Interrupt; >> >> >> >> } >> >> >> >> However, the node that I have programmed stopped sending and receiving >> >> packets after this modification... Any ideas? Do I need to make any >> >> other >> >> modifications? >> >> >> >> Thanks for your suggestions... >> >> >> >> K. Sinan YILDIRIM >> >> >> >> Ege University >> >> Computer Engineering Department >> >> Izmir, TURKEY >> >> >> >> >> >> >> >> 2010/8/4 Thomas Schmid <[email protected]> >> >>> >> >>> Hi Sinan, >> >>> >> >>> The problem is not in the TinyOS code. The hardware you use (I assume >> >>> TelosB or Sky?) does not support these timestamps by default. The >> >>> timestamps are taken when the SFD line toggles. This line is connected >> >>> to the TimerB, which is sourced from the 32kHz signal. Thus, you can >> >>> not get microsecond timestamps with it. >> >>> >> >>> You have two choices: >> >>> - Change TimerB to use a high-speed clock (note, DCO is not stable >> >>> enough, so your hardware has to have an external high-speed crystal or >> >>> clock) and rewire TinyOS to use TimerA for the virtual timer >> >>> subsystem. >> >>> - connect the SFD line to a TimerA input line. Then, use this to >> >>> capture the timestamps. >> >>> >> >>> Cheers, >> >>> >> >>> - Thomas >> >>> >> >>> >> >>> >> >>> 2010/8/4 Sinan Yildirim <[email protected]>: >> >>> > Hello all, >> >>> > >> >>> > I have a problem on microsecond precision timestamps. I am using >> >>> > CC24 >> >>> > radio >> >>> > chip and MSP430 microcontroller. As far as I understood, the packets >> >>> > are >> >>> > timestamped at CC2420ReceiveP and CC2420TransmitP files. >> >>> > >> >>> > /***************** CC2420Receive Commands ****************/ >> >>> > /** >> >>> > * Start frame delimiter signifies the beginning/end of a packet >> >>> > * See the CC2420 datasheet for details. >> >>> > */ >> >>> > async command void CC2420Receive.sfd( uint32_t time ) { >> >>> > if ( m_timestamp_size < TIMESTAMP_QUEUE_SIZE ) { >> >>> > uint8_t tail = ( ( m_timestamp_head + m_timestamp_size ) % >> >>> > TIMESTAMP_QUEUE_SIZE ); >> >>> > m_timestamp_queue[ tail ] = time; >> >>> > m_timestamp_size++; >> >>> > } >> >>> > } >> >>> > >> >>> > >> >>> > async event void CaptureSFD.captured( uint16_t time ) { >> >>> > uint32_t time32; >> >>> > uint8_t sfd_state = 0; >> >>> > atomic { >> >>> > >> >>> > time32 = getTime32(time); >> >>> > switch( m_state ) { >> >>> > >> >>> > case S_SFD: >> >>> > m_state = S_EFD; >> >>> > sfdHigh = TRUE; >> >>> > // in case we got stuck in the receive SFD interrupts, we >> >>> > can >> >>> > reset >> >>> > // the state here since we know that we are not receiving >> >>> > anymore >> >>> > m_receiving = FALSE; >> >>> > call CaptureSFD.captureFallingEdge(); >> >>> > call PacketTimeStamp.set(m_msg, time32); >> >>> > if (call PacketTimeSyncOffset.isSet(m_msg)) { >> >>> > uint8_t absOffset = >> >>> > sizeof(message_header_t)-sizeof(cc2420_header_t)+call >> >>> > PacketTimeSyncOffset.get(m_msg); >> >>> > timesync_radio_t *timesync = (timesync_radio_t >> >>> > *)((nx_uint8_t*)m_msg+absOffset); >> >>> > // set timesync event time as the offset between the >> >>> > event >> >>> > time >> >>> > and the SFD interrupt time (TEP 133) >> >>> > *timesync -= time32; >> >>> > call CSN.clr(); >> >>> > call TXFIFO_RAM.write( absOffset, (uint8_t*)timesync, >> >>> > sizeof(timesync_radio_t) ); >> >>> > call CSN.set(); >> >>> > //restoring the event time to the original value >> >>> > *timesync += time32; >> >>> > } >> >>> > >> >>> > >> >>> > My problem is, as far as I understood, the "time" parameter of these >> >>> > functions are all in 32 KHz. I am currently implementing a time >> >>> > synchronization protocol and I need microsecond precision. Current >> >>> > version >> >>> > of TinyOs does not have interfaces that serves microsecond >> >>> > timestamps >> >>> > in my >> >>> > platform. >> >>> > >> >>> > What are your suggestions? Is there a way to get microsecond >> >>> > precision? >> >>> > >> >>> > Thanks for your helps and thanks a lot... >> >>> > >> >>> > K. Sinan YILDIRIM >> >>> > >> >>> > Ege University >> >>> > Computer Engineering Department >> >>> > İzmir, TURKEY >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > 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 >> > > > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
