[Tinyos-help] 802.15.4

Pablo Marcos pablo.marcos.oltra at gmail.com
Tue Nov 23 02:17:07 PST 2010


Thanks a lot Jan.

The problem is that each time I try to use the default printf in the
coordinator, my application loses sync. So right now, the only way I know
about getting results is using another node as sniffer (using
TestPromiscuous), which seems to work fine and cannot lose sync cause it is
not associated and is just listening packets. The problem is that for
instante, if you want to know how much packets the coordinator has rx, you
cannot guarantee that using another node, obviously.

For what Aitor said, it seems the dbg_serial is a lot better than the
default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
dbg_serial, but do with the default printf), so I was wondering if it would
be any way to make the dbg_serial work without having all the TKN154
dbg_serial's by default, just the ones that I write "by hand" in my own app.

Regards,
  Pablo

2010/11/23 Jan Hauer <hauer at tkn.tu-berlin.de>

> On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
> <pablo.marcos.oltra at gmail.com> wrote:
> > Hi,
> > About the TKN154_DEBUG mode, I couldn't get the coordinator compiled
> > correctly because of the lack of memory in some tests. I someone faces
> the
> > same problem, should try the -Os option to optimize the code and add as
> well
> > these few lines to disable in the coordinator some functionalities:
> > CFLAGS += -I$(shell pwd)/.. \
> > -DIEEE154_SCAN_DISABLED \
> > -DIEEE154_BEACON_SYNC_DISABLED \
> > -DIEEE154_PROMISCUOUS_MODE_DISABLED \
> > This way, there is no error compiling in debug mode. Anyway, does anyone
> > know how to print using the dbg_serial the TKN has implemented without
> > having the default printfs the TKN is showing?
>
> When TKN154_DEBUG is defined you can also use printf("...") to output
> your debug info over serial, but keep in mind that you should be in
> sync context (in async command/event handlers you can use
> tkn154_dbg_serial(), see tos/lib/mac/tkn154/TKN154_MAC.h line 289). If
> you only want your own debug messages, then don't define TKN154_DEBUG,
> instead use printf library as described in the tutorial
> (http://docs.tinyos.net/index.php/The_TinyOS_printf_Library). To
> disable / remove all your debug printf-statements later you can do
> something like this:
>
> #define printf(...)
>
> > And what about how to know
> > how much energy the CC2420 is consuming? It has to be some way to measure
> > how much time the radio is in each mode, and using the datasheet, know
> how
> > much energ is consuming.
> > Thanks in advance.
> > Regards,
> >   Pablo
> > 2010/11/19 Aitor Hernandez <aitorhh at kth.se>
> >>
> >> Hi,
> >> I've tried your app, and it is working with 6 motes + coordinator during
> >> ~15min. I don't understand which could be the problem in your case. You
> >> could try to change the mote that plays the coordinator role. If your
> motes
> >> are old, it could be a problem.
> >> A temporaly solution, coudl be start the MLME_SCAN (startApp();) again
> >> after the MLME_SYNC_LOSS but it is not a good idea, because then you
> won't
> >> see this kind of problems.
> >> I want to remark what you said about the printf and debug. The printf
> >> introduces a lot of delay, around 9x{backoff period}, but if is possible
> to
> >> use TKN154_4, the dbg_serial takes around one backoff period (20
> symbols).
> >> Hence, it is really important to disable them if they are not completely
> >> necessary. These values are approximations :P
> >> Best regards,
> >> Aitor
> >>
> >> On 18 November 2010 22:48, Pablo Marcos Oltra
> >> <pablo.marcos.oltra at gmail.com> wrote:
> >>>
> >>> Hi,
> >>> Thank you very much for your response Aitor. I had two motes running
> for
> >>> 3 days with BO=14 and I had no problems of sync using the TestSync
> >>> application. Not even one beacon was missed. This was the first test I
> ran
> >>> to check if I was about to have clock drift problems in later
> experiments.
> >>> I'm currently using channels 19 and 20 because in my building there are
> just
> >>> a few spare channels to use (20  are mainly being used right now).
> Besides,
> >>> I always set up BO and SO < 7, using usually 5, but not even that way
> works
> >>> properly.
> >>> Anyway, I don't really know if it has something to do with using
> timers,
> >>> but I have noticed that the losing of the sync is kind of periodically.
> I
> >>> have noticed today as well that both devices lose sync even if they
> don't
> >>> even start at the same time (I was hoping a different periodicity for
> each
> >>> one), but they both were losing the same beacons. Hence, I'm thinking
> right
> >>> now about the possibility that it has something to do with the
> coordinator,
> >>> cause the other two devices are not even tx packets, just trying to me
> sync
> >>> with the coordinator.
> >>> I sent another mail a few days ago to the tinyos-help list cause I
> >>> thought that maybe the problems were cause because I was using printf
> to
> >>> debug the application, but without using it is losing sync as well,
> so...
> >>> now I'm the one that is lost :S.
> >>> Could you please check if the application attached is working for you?
> It
> >>> is just the original TestData but with a Timer that once is fired sends
> the
> >>> packets. When I try that, the device loses sync after a while.
> >>> Thank you very much in advance.
> >>> Regards,
> >>>   Pablo
> >>> 2010/11/18 Aitor Hernandez <aitorhh at kth.se>
> >>>>
> >>>> Hi,
> >>>> We have been using this implementation for several wireless process
> and
> >>>> we made a performance evaluation of it. We haven't found any problem
> with
> >>>> the timers (used to start a transmission, or something else). The idea
> that
> >>>> comes up is that maybe there are some interferences on the same
> channel that
> >>>> you are using or you have a high beacon order.
> >>>> As we have seen, if we receive packets on the period where we are
> >>>> waiting the beacon, we could miss them. Moreover I've just realized
> that by
> >>>> using a high beacon order (> 10) some motes could have problems to
> >>>> synchronize with the beacon. I guess that I could be due to the clock
> drift,
> >>>> but Jan can clarify this point.
> >>>> What I recommend you, is to use a BO=6 and a SO =5,6 with this values
> >>>> you shouldn't have any problems.... Furthermore, try to change the
> channel
> >>>> and see if the problem persists. Channels between 22 and 26 don't have
> any
> >>>> overlapping with WiFi channels.
> >>>> At the moment, there is nothing else in my mind. I hope it will work
> for
> >>>> you.
> >>>> Good luck!
> >>>>
> >>>> On 18 November 2010 16:27, Pablo Marcos Oltra
> >>>> <pablo.marcos.oltra at gmail.com> wrote:
> >>>>>
> >>>>> I found the error and the UserButton is now working in my test
> >>>>> application. So, I wait for 3 nodes to have synchronization and then
> I push
> >>>>> all of their buttons and they start tx data. However, after a while,
> they
> >>>>> lose sync, as always, and I don't know why.
> >>>>> Aitor, have you ever used timers that once they're fired they send
> the
> >>>>> data (for example, to send data every minute or so)? Cause I'm having
> >>>>> trouble with that (even with just one device), and don't if that
> could be
> >>>>> something related with the problem you told us a few mails ago.
> >>>>> Regards,
> >>>>>   Pablo
> >>>>> 2010/11/18 Aitor Hernandez <aitorhh at kth.se>
> >>>>>>
> >>>>>> In my case, I just program all the motes at the same time by using
> "&"
> >>>>>> function on the shell, something like:
> >>>>>> $ make tmote
> >>>>>> $ make tmote reinstall,1 bsl,/dev/ttyUSB1 & make tmote
> >>>>>> reinstall,2 bsl,/dev/ttyUSB2
> >>>>>> By the way, I've been using the UserButton for some time, and I've
> >>>>>> never noticed the behaviour you explain, with or without
> TKN154_DEBUG
> >>>>>> enabled.
> >>>>>> Best,
> >>>>>> Aitor
> >>>>>>
> >>>>>> On 18 November 2010 13:28, Pablo Marcos Oltra
> >>>>>> <pablo.marcos.oltra at gmail.com> wrote:
> >>>>>>>
> >>>>>>> May I add other option to the Aitor ones?
> >>>>>>> I thought about letting the motes synchronize first, and then start
> >>>>>>> sending packets once they're all synchronized. How could you do
> this? I have
> >>>>>>> tried doing that with the telosb user button, hence once you
> pressed it you
> >>>>>>> change a flag that starts sending packets. The problem is that I
> have just
> >>>>>>> been able to do that with the TKN154_DEBUG enabled, otherwise, the
> event
> >>>>>>> void Notify.notify( button_state_t state ) is not working.
> >>>>>>> You can see an example of how to use the telosb user button in
> >>>>>>> $TOSROOT/apps/tests/telosb.
> >>>>>>> Regards,
> >>>>>>>   Pablo
> >>>>>>> 2010/11/18 Jan Hauer <hauer at tkn.tu-berlin.de>
> >>>>>>>>
> >>>>>>>> yes - I can reproduce the problem and also believe that it is due
> to
> >>>>>>>> wrong (beacon) timestamps. will look into it and try to fix it
> asap.
> >>>>>>>>
> >>>>>>>> thanks,
> >>>>>>>> jan
> >>>>>>>>
> >>>>>>>> On Thu, Nov 18, 2010 at 10:02 AM, Aitor Hernandez <aitorhh at kth.se
> >
> >>>>>>>> wrote:
> >>>>>>>> > Hi guys,
> >>>>>>>> > I've seen this problem with TKN15.4. It is possible to
> synchronize
> >>>>>>>> > N nodes
> >>>>>>>> > with TKN15.4 the problem is that they need to start the app at
> the
> >>>>>>>> > same
> >>>>>>>> > time. From my experience I've realized that the problem comes
> from
> >>>>>>>> > the
> >>>>>>>> > cc2420_tkn154 (maybe it happens with the default cc2420
> >>>>>>>> > implementation as
> >>>>>>>> > well).
> >>>>>>>> > If we have a network with N nodes running and transmitting data
> >>>>>>>> > between
> >>>>>>>> > them, when we try to add another node we could have this
> problem.
> >>>>>>>> > As far as
> >>>>>>>> > we have the radio enabled for reception for a long period (Scan
> >>>>>>>> > period), the
> >>>>>>>> > cc2420 receives the beacons but data packets as well. Once it
> >>>>>>>> > detects that
> >>>>>>>> > the received packet is a beacon, it sets the timestamp, but
> >>>>>>>> > sometimes the
> >>>>>>>> > timestamp is wrong, due to the data packets, and then we lost
> the
> >>>>>>>> > next
> >>>>>>>> > beacons.
> >>>>>>>> > Possible solutions:
> >>>>>>>> >
> >>>>>>>> > Check the CC2420ReceiveP.nc and the m_timestamp_queue. I guess
> >>>>>>>> > that the
> >>>>>>>> > problem should be there. I did some modifications on
> >>>>>>>> > the CC2420ReceiveP.nc to solve this problem, but I haven't test
> it
> >>>>>>>> > properly.
> >>>>>>>> > If we lost the synchronization, scan again
> >>>>>>>> > with MLME_SCAN.request(). It is a
> >>>>>>>> > "fake" solution, because the problem is still there, but for
> some
> >>>>>>>> > app it
> >>>>>>>> > will work.
> >>>>>>>> > Start the nodes at the same time. It is not possible in a real
> >>>>>>>> > deployment.
> >>>>>>>> >
> >>>>>>>> >
> >>>>>>>> > --
> >>>>>>>> > Aitor Hernandez
> >>>>>>>> > KTH | Automatic Control
> >>>>>>>> > Research engineer
> >>>>>>>> > Stockholm
> >>>>>>>> > Phone:  +46 (0)704 26 87 99
> >>>>>>>> >
> >>>>>>>> > _______________________________________________
> >>>>>>>> > Tinyos-help mailing list
> >>>>>>>> > Tinyos-help at millennium.berkeley.edu
> >>>>>>>> >
> >>>>>>>> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >>>>>>>> >
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Tinyos-help mailing list
> >>>>>>>> Tinyos-help at millennium.berkeley.edu
> >>>>>>>>
> >>>>>>>>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Aitor Hernandez
> >>>>>> KTH | Automatic Control
> >>>>>> Research engineer
> >>>>>> Stockholm
> >>>>>> Phone:  +46 (0)704 26 87 99
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Aitor Hernandez
> >>>> KTH | Automatic Control
> >>>> Research engineer
> >>>> Stockholm
> >>>> Phone:  +46 (0)704 26 87 99
> >>>
> >>
> >>
> >>
> >> --
> >> Aitor Hernandez
> >> KTH | Automatic Control
> >> Research engineer
> >> Stockholm
> >> Phone:  +46 (0)704 26 87 99
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101123/3deb5436/attachment-0001.htm 


More information about the Tinyos-help mailing list