[Tinyos-devel] FTSP testing result

[vijay kumar]

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.

regards
vijay


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
> >>>>
> >>>> _______________________________________________
> >>>> 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)
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090225/0093e424/attachment.htm