Hi Guys,
> Could there be a timing issue when waiting for Acks?
> It might be that the telos responds a little slower
> and the iris gives up waiting too soon -- if I have
> the order of execution right anyway...
Yes, I think that is it. From Urs data the first big number is the
time stamp of the SFD (start frame delimiter) of the packet, the
second smaller number is the current time when the packet was
downloaded, both in roughly microseconds. We see the following:
TelosB -> TelosB: approx 1.65 millisecond delay
TelosB -> IRIS: approx 0.77 millisecond delay
IRIS -> TelosB: approx 1.63 millisecond delay
IRIS -> IRIS: approx 0.77 millisecond delay
These are delays between the SFD of the data packet and the SFD of the
ack packet, so the actual gap between the two packets is smaller (by
14 data bytes + 5 preamble bytes, which is around 19*32=608, i.e. 0.6
milliseconds. So the actual delay between the end of the data packet
and start of the ack packet for the IRIS is 0.17 milliseconds.
Anyways, the problem is the timing, the IRIS does not wait long enough
for the ACK. In RF230ActiveMessageP.nc it is said that
async command uint16_t SoftwareAckConfig.getAckTimeout()
{
return (uint16_t)(800 * RADIO_ALARM_MICROSEC);
}
So it waits up to 0.8 milliseconds, which is less than the CC2420 1.6
millisecond delay. By the way, the IEEE 802.15.4 standard requires
acknowledgements within 192 microseconds, so the IRIS is compliant and
the TelosB is not (with its software ACK implementation).
You can solve the problem in two ways: 1) increase the 800 microsecond
wait period for the ISIS for example to 1600 (probably 1100 is enough)
microseconds, or 2) use hardware ACK for the TelosB.
Miklos
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
