Hi Janos,
I haven't compiled your test application yet but I have developed a sample
application and I have only used your msp430 library /tinyos-2.x-
contrib/vu/tos/chips/msp430 for my application.
Let me explain how the application works:
I have used 3 nodes. One of the nodes (reference node) broadcast a packet
using *TimeSyncAMSend *interface at every 0x500000 microseconds and the
other nodes which are in the broadcast range of the sender receive this
message and queries the corresponding local time transformation of the send
time at the reference node using "*call TimeSyncPacket.eventTime(msg);*".
The 6 consecutive eventTime values that I have measured is as listed as
follows:
(node 0x2 is the reference node)
Packet #1
[nodeid=0x0] [clock=0x41f0ab]
[nodeid=0x1] [clock=0x13e7c6]
*[nodeid=0x2] [clock=0x500877] *
Packet #2
[nodeid=0x0] [clock=0x91f434]
[nodeid=0x1] [clock=0x62ed83]
*[nodeid=0x2] [clock=0xa00877] *
Packet #3
[nodeid=0x0] [clock=0xe1f3d0]
[nodeid=0x1] [clock=0xb2eed7]
*[nodeid=0x2] [clock=0xf00877] *
Packet #4
[nodeid=0x0] [clock=0x130f2e8]
[nodeid=0x1] [clock=0x102f024]
*[nodeid=0x2] [clock=0x1400877] *
Packet #5
[nodeid=0x0] [clock=0x181f2c6]
[nodeid=0x1] [clock=0x153f16a]
*[nodeid=0x2] [clock=0x1900877] *
Packet #6
[nodeid=0x0] [clock=0x1d1f19e]
[nodeid=0x1] [clock=0x1a2f2bf]
*[nodeid=0x2] [clock=0x1e00877] *
If we calculate the difference between each consecutive event times for the
nodes 0x0 and 0x1 we get:
Packet #2 - Packet #1
[nodeid=0x0] [clock=0x91f434] - [clock=0x41f0ab] = 0x500389
[nodeid=0x1] [clock=0x62ed83] - [clock=0x13e7c6] = 0x4F05BD
Packet #3 - Packet #2
[nodeid=0x0] [clock=0xe1f3d0] - [clock=0x91f434] = 0x4FFF9C
[nodeid=0x1] [clock=0xb2eed7] - [clock=0x62ed83] = 0x500154
Packet #4 - Packet #3
[nodeid=0x0] [clock=0x130f2e8] - [clock=0xe1f3d0] = 0x4EFF18
[nodeid=0x1] [clock=0x102f024] - [clock=0xb2eed7] = 0x50014D
Packet #5 - Packet #4
[nodeid=0x0] [clock=0x181f2c6] - [clock=0x130f2e8] = 0x50FFDE
[nodeid=0x1] [clock=0x153f16a] - [clock=0x102f024] = 0x510146
**
Packet #6 - Packet #5
[nodeid=0x0] [clock=0x1d1f19e] - [clock=0x181f2c6] = 0x4FFED8
[nodeid=0x1] [clock=0x1a2f2bf] - [clock=0x153f16a] = 0x4F0155
As seen, this difference changes a lot every time. For example for node 0x1
we measure 0x4F05BD for the event_time(packet2) -event_time(packet1).
However, again for the node 0x1 we measure 0x500154 for the
event_time(packet3) -event_time(packet2). This is my problem. As a result I
cannot estimate the relative hardware clock rate of the reference node 0x2
for the node 0x1 and 0x0. My platform is not Telos, it is Genetlab
Sensenode. But it is similar to Telos. Why do you think the relative period
of the reference node changes a lot?? When I use the standart MPS430 timer
library which is 32 KHZ I dont get such values. They are all consistent. But
when I switch to your library, I get values that change everytime.
The output of the compilation of my application is below:
mkdir -p build/sensenode
compiling TSyncAppC to a sensenode binary
ncc -o build/sensenode/main.exe -Os -O -I../../tos/chips/cc2420/transmit/
-I../../tos/chips/msp430/timer/ -I../../tos/platforms/sensenode/
-I../../tos/lib/LCSP/ -mdisable-hwmul -fnesc-separator=__ -Wall -Wshadow
-Wnesc-all -target=sensenode -fnesc-cfile=build/sensenode/app.c -board=
-DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME=\"TSyncAppC\"
-DIDENT_USERNAME=\"sinanyil\" -DIDENT_HOSTNAME=\"sinanyil-deskto\"
-DIDENT_USERHASH=0xec7641acL -DIDENT_TIMESTAMP=0x4c61820aL
-DIDENT_UIDHASH=0x73bcafaeL TSyncAppC.nc -lm
/opt/tinyos-2.1.0/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning
"*** LOW POWER COMMUNICATIONS DISABLED ***"
../../tos/lib/LCSP/TSyncModuleP.nc: In function
`TSyncModuleP__Receive__receive':
../../tos/lib/LCSP/TSyncModuleP.nc:192: warning: unused variable `id'
compiled TSyncAppC to build/sensenode/main.exe
14708 bytes in ROM
501 bytes in RAM
msp430-objcopy --output-target=ihex build/sensenode/main.exe
build/sensenode/main.ihex
writing TOS image
Janos, If the output of my application is not enough for you, I will try to
compile your application and will send the outputs if you want. I could not
find enough time for it.
Thanks for your valuable helps...
Sinan
09 Ağustos 2010 22:24 tarihinde Janos Sallai <[email protected]>yazdı:
> 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 <[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
