Hi Janos,
I achieved 0x500000 microsecond periodicity by such a way:
- I set a milli timer of (of 0x1400 milliseconds)
- I store the local time at the first fire ıf the timer at a variable called
"pulse"
- At each timeout of the timer, I add 0x500000 to the "pulse" variable
- And I give "pulse" as a parameter to TimeSyncAMSend.send(...)
I didn't use any AlarmMicro16C. I was using LocalTimeMicroC for getting
local time. But as you said, I have changed it with AlarmHybridMicro32C for
getting local time by calling Alarm.getNow(). In fact, this seemed more
stable as you have said, but not so much stability... Still big errors on
the differences..
For the timestamping issue, as I said before I was not using your cc2420
stack. I am using the stack at the current tinyos-2.x repository. I have
made there a minor change at the CC2420TransmitC and CC2420TransmitP files:
configuration *CC2420TransmitC* {
...
...
}
implementation {
...
...*
* components AlarmHybridMicro32C;
CC2420TransmitP.LTime -> AlarmHybridMicro32C;
}
module *CC2420TransmitP* @safe() {
...
uses interface Alarm<TMicro, uint32_t> as LTime;
}
implementation {
...
// this method converts a 16-bit timestamp into a 32-bit one*
* inline uint32_t getTime32(uint16_t captured_time)
{
uint32_t now = call LTime.getNow();
// the captured_time is always in the past
return now - (uint16_t)(now - captured_time);
}
async event void LTime.fired() {
}*
*
}
Do you think there may be some problem here? Since the captured timestamp is
16 bits, the conversion to 32 bits is needed. Am I doing something wrong?
Thanks!
2010/8/10 Janos Sallai <[email protected]>
> Hi Sinan,
>
> > 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);".
> I'm still missing a couple of details:
> - How do you achieve 0x500000 microsecond periodicity? Is it some kind
> of a 32-bit alarm built on top of AlarmMicro16C?
> - When calling TimeSyncAMSend.send(). what is the event time you
> supply there? Is it simply a call to LocalTime.get()? Do you use
> LocalTimeMicroC as a source of microsecond precision local time.
>
> > 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.
> My guess is that the event time with which TimeSyncAMSend.send() is
> the culprit. If you're using a time source that's driven by the DCO,
> you'll going to see huge clock drifts. (This does not happen with the
> external 32kHz crystal, since that's much more stable.) To check if
> this is the case, do the following. Change the reference node's code
> such that a led is toggled when TimeSyncAMSend.send() is called.
> Program two nodes as reference nodes, place them right next to each
> other, reset them at the same time, and see if they keep blinking
> together. My guess is that they get desynchronized very soon.
>
> If this is the case, would you mind trying to use
> vu/tos/chips/msp430/timer/AlarmHybridMicro32C.nc as your triggering
> alarm? This one should have a much better stability, but still
> providing microsecond precision.
>
> Janos
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
