[Tinyos-devel] Testing FTSP

[Branislav Kusy]

good news, but new problems - see bellow:

> In CC2420ReceiveP line 284:
> 
> 284      if ( m_timestamp_size ) {
> 285        if ( rxFrameLength > 10 ) {
> 286          call PacketTimeStamp.set(m_p_rx_buf, m_timestamp_queue[
> m_timestamp_head ]);
> 287          m_timestamp_head = ( m_timestamp_head + 1 ) % TIMESTAMP_QUEUE_SIZE;
> 288          m_timestamp_size--;
> 289        }
> 290      } else {
> 291        call PacketTimeStamp.clear(m_p_rx_buf);
> 292      }
> 
> why is the else separated from the embedded if? If you receive a short
> frame then you completely screw up the timestamping queue! I think the
> two ifs should be combined into a single one: if( m_timestamp_size !=
> 0 && rxFrameLength > 10 ).
fixed...

> By the way, I think the timestamping logic of acknowledgement frames
> is broken (if they are not automatically handled by the CC2420, i.e.
> software ACK is enabled). First, timestamps for received
> acknowledgement frames are entered into the timestamp queue. However,
> on line 285 you check for short packets and will not remove that
> timestamp from the queue. Why is the "rxFrameLength > 10" check is
> there? If to catch ack frames, then the proper bit should be checked
> like on line 296 (again, you want to use the same logic to keep
> everything in sync). Certainly when you enter timestamps into the
> queue you do not check for length!!!
didn't fix for now...

> First of all, we have to realize that you can miss SFD interrupts one
> way or the other since the CaptureSFD.captureXxxxEdge methods disable
> and reset that interrupt line. Of course in the CaptureSFD.captured()
> there are the fallthrough checks of "if( call SFD.get() ) break" calls
> which catch these, but not all direction change is protected by these.
> For example the one on line 327 is not and that could potentially kill
> a rising edge SFD interrupt (causing missing packets if I see it
> correctly). If you miss a rising edge interrupt then line 314 is
> completely wrong! I think that need to be changed to "if (
> !m_receiving && sfdHigh == FALSE )". Also, I would protect lines 326
> through 334 with an "if( sfdHigh == TRUE )" just to be safe.
fixed...

> I am not saying that these are causing the problem, just that these
> are problem areas. But even if the code does not mess up the time
> stamps, there is still a race that you cannot circumvent and actually
> this could be the cause of all problems. Ok, suppose that you are
> receiving three messages: A, B, C. You timestamp A and start to
> download it from the RXFIFO. Then the radio chip receives the SFD for
> message B and makes a timestamp, an error happens (e.g. CRC) and the
> message is dropped. Then the radio chip receives message C correctly
> which is again time stamped. After all this A is properly downloaded
> from the RXFIFO. Now you have 2 timestamps (for B and C) and 1 message
> in the RXFIFO (could be either B or C). How do you decide which
> timestamp is correct? I think the timestamp should be set only if
> there is a single timestamp in the timestamp queue AND a the RXFIFO is
> empty (that is this was the only message timestamped).
i only timestamp message if the timestamp queue size is 1, otherwise i 
clear the timestamp and reset the queue. take a look at CC2420ReceiverP 
and CC2420TransmitP in contrib/stanford-lgl/apps/tests/TestPacketTimeStamp

the first two fixes didn't help (though i observed decreased frequency 
of errors). after adding the last fix, i wasn't able to see these errors 
on micaZ. so i increased the setup size and let it run overnight (though 
my notebook turned of after 2 hours): i had 9 TestPacketTimeStampC 
motes, so motes are trying to push 324 packets per second. each mote is 
busy-looped 1/6-th of the time (with 5ms long tasks).

i put up two new error logs:
http://docs.tinyos.net/index.php/PacketTimeStamp_CC2420_bug_log2_txrx_errors 
(showing all RXTX errors above 10 jiffies)
http://docs.tinyos.net/index.php/PacketTimeStamp_CC2420_bug_log2_txrx_errors_above20
(RXTX errors above 20 jiffies)

32 jiffies is 1ms.

clearly, there is a problem in how the timestamp is converted from 16 to 
32 bits. this is done in CC2420TransmitP.nc (the modified file in 
TestPacketTimeStamp dir):

239  inline uint32_t time16to32(uint16_t time, uint32_t recent_time)
240  {
241    if ((recent_time&0xFFFF)<time)
242      return ((recent_time-0x10000UL)&0xFFFF0000UL)|time;
243    else
244      return (recent_time&0xFFFF0000UL)|time;
245  }

which is called from
260  async event void CaptureSFD.captured( uint16_t time ) {
261    uint32_t time32 = time16to32(time, call BackoffTimer.getNow());


clearly CaptureSFD.captured() is async, so line 261 should be atomic. do 
you see any other problems?

brano