Hi Sinan,
I have just run the test app
(tinyos-2.x-contrib/vu/apps/TestPacketTimeSync), but didn't see any
extreme inconsistencies apart from some clock drift. Would you mind
running this app and sharing the output with me? Also, can you send me
the compilation output (output of "PFLAGS=-v make telosb 2>&1
make_output.txt")?
> 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.
What values do you compare?
> 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?
Probably, with some work. Use all files from
/tinyos-cvs/tinyos-2.x-contrib/vu/tos/chips/msp430, except the timer
map. Take the timer map from
/tinyos-cvs/tinyos-2.x-contrib/vu/tos/platforms/telosa.
Make sure that the MCU doesn't go below LPM0 (maybe it's LPM1 --
you'll need to take a look at the datasheet), because the microsecond
timer would pause otherwise.
> 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?
The cc2420 stack has a notorious bug with timestamping. If the message
load is high, the timestamps might get assigned to the wrong packet.
There's a timestamp queue in the code, but it doesn't appear to
help... Basically, that's the reason I wrote this alternative
implementation.
>
> 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 <sal...@isis.vanderbilt.edu>
> 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
>> > <sal...@isis.vanderbilt.edu>
>> > 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 <sinanyi...@gmail.com>:
>> >> > 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
>> >> > <sal...@isis.vanderbilt.edu>
>> >> > 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 <sinanyi...@gmail.com>:
>> >> >> > 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
>> >> >> > <sinanyi...@gmail.com>
>> >> >> > 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 <thomas.sch...@gmail.com>
>> >> >> >>>
>> >> >> >>> 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 <sinanyi...@gmail.com>:
>> >> >> >>> > 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
>> >> >> >>> > Tinyos-help@millennium.berkeley.edu
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>> >> >> >>> >
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Tinyos-help mailing list
>> >> >> > Tinyos-help@millennium.berkeley.edu
>> >> >> >
>> >> >> >
>> >> >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
