[Tinyos-devel] FTSP testing result

[Razvan Musaloiu-E.]

Hi!

On Wed, 25 Feb 2009, vijay kumar wrote:

> Hello everybody,
>
>           This is vijay from india. iam working in a private college in
> india. we have our research lab in wiresless sensor networks. iam using
> mib600 ethernet gateway to program the nodes.i found problem in lantronix
> device installer.after conecting my mib600 to LAN iam trying to set the IP
> address for mib600 gateway.when iam clicking search icon in device installer
> it showing "*no devices where found*" how to rectify this problem.
>

A good start would be to post the question on the proper place which is 
tinyos-help and not tinyos-devel. You should also write a new message and 
don't simply reply to existing one. You can find a lengthy explanation why 
to do this here:
 	http://willnorris.com/2008/12/email-etiquette-replying-to-mailing-lists

--
Razvan ME

> On 2/24/09, Thomas Schmid <thomas.schmid at gmail.com> wrote:
>>
>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "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)
>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
>