[Tinyos-help] 802.15.4

Aitor Hernandez aitorhh at kth.se
Mon Nov 22 11:47:42 PST 2010


Hi,

@Jan: thanks for the update! I haven't tested yet, but I am sure that it
will be better.

@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101122/8b5a07d5/attachment.htm 


More information about the Tinyos-help mailing list