Hi Janos, I have downloaded tinyos-2.x from repository as well as tinyos-2.x-contrib. I have applied the steps you have written previously to use your stack.
I have a transmitter node which transmits a message every 5 seconds. The nodes which receive this message get timestamps of the received packets via PacketTimestamp. Then each node gives these timestamps to my clock synchronization protocol and it calculates estimated global time. There is a refernce node in my clock synchronization protocol. When its hardware clock reaches a multiple of the broadcast period, it broadcasts messages using TimeSyncAMSend interface including the fire time of the hardware clock. The TimeSyncAMSend automatically converts this fire time to the local time of the nodes which receives these messages. The problem is, there is a big difference on the converted times of the same event originated by the reference node. When I do not use your stack and use only 32 Khz interfaces in tinyos-2.x/ , neighboring nodes have at most 1 tick difference (32 microsecond difference) for the converted event times. However, when I use your stack I get much more difference on the converted times of the same event originated by the reference node. My coclusion is, may be there can be some incostincies. Can I use only */tinyos-cvs/tinyos-2.x-contrib/vu/tos/chips/msp430 *codes and apply it on tinyos-2.x repository? By doing this, I can eliminate your codes for cc2420. Do you think will it work stable without your cc2420 stack? Is it a standart way to get microsecond precision on systems with cc2420 and msp420? Thanks Janos... >> 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. >> 06 Ağustos 2010 20:56 tarihinde Janos Sallai <[email protected]>yazdı: > Sinan: > > > I am doing the same steps. I am still searching what did I do wrong... I > am > > using system which has been newly checked out from tinyos-2.x development > > repository. > Which setup do you use out of the two I described? Can you please send > me the numbers you get? > > Janos > > > 06 Ağustos 2010 17:27 tarihinde Janos Sallai <[email protected] > > > > yazdı: > >> > >> 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
