[Tinyos-help] 802.15.4

Jan Hauer hauer at tkn.tu-berlin.de
Tue Nov 23 02:09:56 PST 2010


On Mon, Nov 22, 2010 at 8:47 PM, Aitor Hernandez <aitorhh at kth.se> wrote:
>
> Hi,
> @Jan: thanks for the update! I haven't tested yet, but I am sure that it
> will be better.

It is better, but it seems that sometimes there are still problems - I
will take another look.

Jan

> @Pablo: One solution could be replace all the dbg_serial() for dbg() and
> then they won't be shown on the serial port. But it is not nice :P If you
> find another way please let us know.
> For the energy consumption, the best way is to measure the current of the
> mote (I've seen one paper which talks about that, but I don't have the
> reference at the moment). We have measured it and we realized that the mote,
> during the Inactive period does not go to the LPM3 mode because the radio is
> still on during this time. For this reason we have a modification of the
> implementation in order to turn off the radio during the inactive period.
> We are planning to publish the GTS implementation and the energy improvement
> within one week.
> Best regards,
> Aitor
> On 22 November 2010 18:50, 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? 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
>>
>
>
>
> --
> Aitor Hernandez
> KTH | Automatic Control
> Research engineer
> Stockholm
> Phone:  +46 (0)704 26 87 99
>



More information about the Tinyos-help mailing list