Re: [Tinyos-help] 802.15.4
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@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4
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 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 > > 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 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@millennium.berkeley.edu >> > >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > >> >> ___ >> Tinyos-help mailing list >> Tinyos-help@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 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4
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 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 > > 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.ol...@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 >>> >>> 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 >>>> 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 d
Re: [Tinyos-help] 802.15.4
gt; declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function >> `MLME_SCAN.request': >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3551: implicit >> declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function >> `MLME_START.request': >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3738: implicit >> declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3745: implicit >> declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function >> `perform_csma_ca_slotted.runTask': >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:4458: implicit >> declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function >> `perform_csma_ca_unslotted.runTask': >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:4573: implicit >> declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function >> `perform_csma_ca': >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:4604: implicit >> declaration of function `powf' >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function >> `calculate_gts_expiration': >> /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:4698: implicit >> declaration of function `powf' >> make: *** [exe0] Error 1 >> >> >> >> On Fri, Nov 19, 2010 at 12:54 AM, Daniel Schnit >> wrote: >> >>> Hi all, >>> >>> Thanks for help! But i have one more question, in tinyOs CAP, CFP and GTS >>> are implement? if are, how can i use? >>> >>> Thanks, >>> >>> Best regards. >>> >>> On Thu, Nov 18, 2010 at 7:48 PM, Pablo Marcos Oltra < >>> pablo.marcos.ol...@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 >>>> >>>>> 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 b
Re: [Tinyos-help] 802.15.4
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
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
>
>> 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.ol...@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
>>>
>>> In my case, I just program all the motes at the same time by using "&"
>>>> function on the
Re: [Tinyos-help] 802.15.4
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 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
>
> 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.ol...@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.
>&
Re: [Tinyos-help] Network Protocols
Hi,
I've never tried with the protocol you reference before {CTP, TYMO} and I
don't know theris characteristics, but we've applied the IEEE 802.15.4 standard
protocol for similar applications. I think in your case is quite suitable.
There are two implementation on the TinyOS tree but I recommend you to
use *tkn154.
*You could find it in *tos/lib/mac/tkn154* and example applications in *
apps/test/tkn154.*
*
*
*TKN154: http://www.tkn.tu-berlin.de/publications/papers/TKN154.pdf*
IEEE 802.15.4:
http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf
Summary IEEE 802.15.4: http://www.sinemergen.com/zigbee.pdf
Best,
On 26 November 2010 13:23, "José A. Tarifa" wrote:
> Hi to all!
> I'm working on a project with Tmote Sky (with Cygwin) and TinyOS 2.1
> I want to collect data from several motes (which get ADC readings and
> process these) to a base-node. I've seen that CTP protocol would be suitable
> --> http://docs.tinyos.net/index.php/Network_Protocols#Collection
> But I also want to send individual messages (and diffusion messages
> sometimes) from the base to a particular node (or to all nodes). Which
> network protocol can I use for this? Maybe the TYMO protocol -->
> http://docs.tinyos.net/index.php/Tymo ? Is it compatible with CTP ?
> I've though of use Dissemination protocol -->
> http://docs.tinyos.net/index.php/Network_Protocols#Dissemination, but the
> messages are received by all nodes... :(
>
> Thanks!
>
> --
> Jose A.
> Seville, Spain
>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@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
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] IEEE 802.15.4 with GTS (TKN15.4)
Dear all, We are glad to inform that our GTS implementation for the TKN15.4 has been released and you can find it on the TinyOS Contribution. *Documentation*: http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/kth/tkn154-gts/doc/pdf/GTS_implementation.pdf *Code*: http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/kth/tkn154-gts/ Best regards, -- Aitor Hernandez KTH | Automatic Control Research engineer Stockholm ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Tr : IEEE 802.15.4 with GTS (TKN15.4)
Hi Luis,
Thanks a lot for the feedback.
Now I need to update the code because Jan has updated his code, so I will
not recommend to update the TinyOS tree until I update ours. Otherwise, the
GTS implementation will not work.
I'll let you know when I update the code.
Best,
On 19 January 2011 13:00, luis_size wrote:
> Hello Again Aitor,
>
> I succeded to compile and run you GTS application (I just updated my tinyos
> tree).
>
> I found only one error in the device part.
> (tinyos-2.x-contrib/kth/tkn154-gts/apps/beacon-enabled/TestGts/device/TestDeviceSenderC.nc).
> If the node id is different from 2, the device will never send data to the
> coordinator. just a small error in if imbrication.
>
> // when to start transmitting packets
> if (TOS_NODE_ID == 0x02)
> if (m_conf_steps > 1) post packetSendTask();
> else if (m_conf_steps > 0) post packetSendTask();
> printfflush();
>
> must be :
>
> // when to start transmitting packets
> if (TOS_NODE_ID == 0x02)
> {if (m_conf_steps > 1) post packetSendTask();}
> else if (m_conf_steps > 0) post packetSendTask();
>
> printfflush();
>
> I'll try to test the application with several nodes and give you feedback.
>
> Regards.
>
>
>
> - Message transféré
> *De :* luis_size
> *À :* aito...@kth.se; tinyos help
> *Envoyé le :* Mar 18 janvier 2011, 14h 18min 08s
> *Objet :* [Tinyos-help] IEEE 802.15.4 with GTS (TKN15.4)
>
> Hello Aitor,
>
>
> First of all thank you for this good news :)
>
> I'm interested in your GTS mechanism for 802.15.4 MAC. I tried to install the
> TestGts application and I got the error bellow:
>
> Can you help me on this ?
>
> Thanks in advance.
> Luis.
>
> The error:
> make telosb instal,0
> mkdir -p build/telosb
> compiling TestGtsAppC to a telosb binary
> ncc -o
> build/telosb/main.exe -Os -O -DPRINTF_BUFFER_SIZE=1000 -mdisable-hwmul
> -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=telosb
> -fnesc-cfile=build/telosb/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/apps/beacon-enabled/TestGts/coordinator/..
> -I/home/tiny2/tinyos-main/tos/lib/printf
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154/dummies
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154/interfaces/MCPS
>
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154/interfaces/MLME
>
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154/interfaces/private
>
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154/interfaces/public
> -I/home/tiny2/tinyos-main/tos/lib/mac/tkn154
> -I/home/tiny2/tinyos-main/tos/lib/mac/tkn154/dummies
> -I/home/tiny2/tinyos-main/tos/lib/mac/tkn154/interfaces/MCPS
> -I/home/tiny2/tinyos-main/tos/lib/mac/tkn154/interfaces/MLME
> -I/home/tiny2/tinyos-main/tos/lib/mac/tkn154/interfaces/private
> -I/home/tiny2/tinyos-main/tos/lib/mac/tkn154/interfaces/public
> -DIDENT_APPNAME=\"TestGtsAppC\" -DIDENT_USERNAME=\"tiny2\"
> -DIDENT_HOSTNAME=\"tinyVM\"
> -DIDENT_USERHASH=0x0550d87fL -DIDENT_TIMESTAMP=0x4d358bc8L
> -DIDENT_UIDHASH=0xae1e93bdL
> -I/home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/platforms/telosb/mac/tkn154
> -I/home/tiny2/tinyos-main/tos/platforms/telosb/mac/tkn154
> -I/home/tiny2/tinyos-main/tos/platforms/telosb/mac/tkn154/timer
> -I/home/tiny2/tinyos-main/tos/chips/cc2420_tkn154 TestGtsAppC.nc -lm
> In component `CoordCfpP':
> /home/tiny2/tinyos-2.x-contrib/kth/tkn154-gts/tos/lib/mac/tkn154/CoordCfpP.nc:79:
> `GtsInfoWrite.getLength' not implemented
> /home/tiny2/tinyos-main/tos/platforms/telosb/mac/tkn154/timer/Alarm32khzTo62500hzTransformC.nc:53:2:
> warning: #warning "Warning: MAC timing is not standard compliant!"
> make: *** [exe0] Error
> 1
>
>
> -
> Thanks and congratz! I hope to try it soon.
>
> Best regards,
>
> /AntonioL
>
>
> >* Dear all,
> *>*
> *>* We are glad to inform that our GTS
> implementation for the TKN15.4 has been
> *>* released and you can find it on the TinyOS Contribution.
> *>*
> *>* *Documentation*:
> *>*
> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/kth/tkn154-gts/doc/pdf/GTS_implementation.pdf
> *>* *Code*:
> *>*
> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/kth/tkn154-gts/
> *>*
>
> *>* Best regards,
> *>*
> *>* --
> *>* Aitor Hernandez
> *>* KTH | Automatic Control
> *>* Research eng
Re: [Tinyos-help] TinyOS vs 802.15.4 packet format
Hi Luis,
The packet format is the one described in the IEEE 802.15.4. You can find it
in the documentation
http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf.
Best,
On 20 January 2011 16:43, luis_size wrote:
> Hello everyone,
>
> I'm trying to understand the packet format used by TinyOS when 802.15.4 MAC
> TKN MAC layer is used.
>
> 1- Before, I know that TinyOS message format is : AMPacket | link source
> addr | msg len | groupID | handlerID | source addr |
> payload
>
> 2- I found also that The CC2420 Packet structure is defined in CC2420.h.
> The default I-Frame CC2420 header takes on the following format:::
> typedef nx_struct cc2420_header_t {
>nxle_uint8_t length;
>nxle_uint16_t fcf;
>nxle_uint8_t dsn;
>nxle_uint16_t destpan;
>nxle_uint16_t dest;
>nxle_uint16_t src;
>nxle_uint8_t network; // optionally included with 6LowPAN layer
>nxle_uint8_t type;
> } cc2420_header_t;
>
> In which format packets are when I use TinyOS with TKN 802.15.4 ? is the
> first one encapsulated in the second one ? or maybe one is used for data and
> the second for 802.15.4 control messages (request, confirm ) ?
>
> I'll be very thankful if someone can lighten my mind :)
>
> Regards,
> Luis.
>
>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
--
Aitor Hernandez
Stockholm
Phone: +46 (0)704 26 87 99
+34 687 70 07 63
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
