[Tinyos-devel] FTSP testing result

[Thomas Schmid]

I just realized that I left a call to Leds.led0Toggle() in the patch,
which of course should be removed. sorry about that.

Thomas

On Mon, Feb 23, 2009 at 11:14 AM, Thomas Schmid <thomas.schmid at gmail.com> wrote:
> I attached a patch for the first problem described earlier. This
> should fix problems with the receive timestamp.
>
> Thomas
>
> On Mon, Feb 23, 2009 at 10:25 AM, Branislav Kusy <kusy at stanford.edu> wrote:
>> hi thomas,
>>
>> yes, i suggested to drop the timestamp queue a while ago but nobody got
>> around to actually do it. miklos suggested some code in august'08 on tinyos
>> devel list, but it didn't work, so i didn't commit it. i'll send you a link
>> later because the berkeley server is down right now.
>>
>> if you send me a patch, i can stress test the code to see if it works and
>> then we can commit it.
>>
>> as for the magic 10 ticks - we were wondering about it as well and never got
>> an explanation. i think the conclusion was that this was for ack timestamps
>> to fall through. but i'm not even sure who wrote it.
>>
>> brano
>>
>>
>> Thomas Schmid wrote:
>>>
>>> Has anybody tried to fix this? The timestamp queue is very ugly right
>>> now! Especially, we basically invalidate the timestamp every time we
>>> have more than one timestamp in that queue anyway!
>>>
>>> Next, I think the problem for the invalidated timestamps in the
>>> ReceiveP is in line number 324 in CC2420Transmit P. Code here
>>> duplicated:
>>> if ( time - m_prev_time < 10 ) {
>>>  call CC2420Receive.sfd_dropped();
>>>  if (m_msg)
>>>    call PacketTimeStamp.clear(m_msg);
>>> }
>>>
>>> I don't really understand what this check is for, but this will always
>>> trigger a clear on the timestamp if we fall through in the SFD. I
>>> think this is wrong. We should only invalidate the timestamp if
>>> SFD.get() was 0 at the time of reading the timer, not if the time
>>> between the two interrupts was smaller than some magic 10 tics.
>>>
>>> If no one is working on this already, please let me know and I will
>>> clean this timestamping mess up.
>>>
>>> Cheers,
>>>
>>> Thomas
>>>
>>> On Mon, Feb 9, 2009 at 3:13 AM, Omprakash Gnawali <gnawali at usc.edu> wrote:
>>>>
>>>> On Mon, Feb 9, 2009 at 2:09 AM, Andreas Köpke <koepke at tkn.tu-berlin.de>
>>>> wrote:
>>>>>>
>>>>>> Branislav Kusy wrote:
>>>>>>>
>>>>>>> so it seems the problem fixed?
>>>>>>>
>>>>> Ok -- I did some more measurements with the code, so the patch in
>>>>> CC2420TransmitP works well: now all timesync packets are transmitted
>>>>> with a
>>>>> correct timesync field.
>>>>>
>>>>> But on the CC2420ReceiveP side, all timestamps are cleared again. The
>>>>> CVS
>>>>> version 1.17 works fine for me, but the 1.18 does not.
>>>>>
>>>>> And while we are at it: can we remove this time stamp queue stuff? I can
>>>>> not
>>>>> imagine how this should work with LPL.
>>>>>
>>>> In one experiment, getGlobalTime call returned a success but the time
>>>> was all over the place; it should have been roughly linear over time.
>>>> This happened for a significant fraction of the experiment duration.
>>>> In another run, this was not the case.
>>>>
>>>> - om_p
>>>>
>>>> _______________________________________________
>>>> Tinyos-devel mailing list
>>>> Tinyos-devel at millennium.berkeley.edu
>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> "Don't complain; Just work harder" - Randy Pausch
>
> Thomas Schmid, Ph.D. Candidate
> Networked & Embedded Systems Laboratory (NESL)
> University of California, Los Angeles (UCLA)
>



-- 
"Don't complain; Just work harder" - Randy Pausch

Thomas Schmid, Ph.D. Candidate
Networked & Embedded Systems Laboratory (NESL)
University of California, Los Angeles (UCLA)