you are using a different implementation - the implementation we have been talking about in this thread is here: tos/lib/mac/tkn154 and its test apps are here: apps/tests/tkn154
Jan On Fri, Nov 19, 2010 at 7:51 AM, Daniel Schnit <[email protected]> wrote: > Hi..i found an example! but have this problem, anyone know what is the > problem? > > /apps/AssociationExample$ make micaz > mkdir -p build/micaz > compiling AssociationExampleC to a micaz binary > ncc -o build/micaz/main.exe -Os > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/phy > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/timerasync > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/interfaces > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/interfaces/mac > -I/opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/interfaces/phy > -I/opt/tinyos-2.x/tos/lib/net/zigbee/cc2420 -fnesc-separator=__ -Wall > -Wshadow -Wnesc-all -target=micaz -fnesc-cfile=build/micaz/app.c > -board=micasb -DDEFINED_TOS_AM_GROUP=0x22 --param > max-inline-insns-single=100000 -DIDENT_APPNAME=\"AssociationExam\" > -DIDENT_USERNAME=\"marcelo\" -DIDENT_HOSTNAME=\"marcelo-desktop\" > -DIDENT_USERHASH=0xf714c009L -DIDENT_TIMESTAMP=0x4ce61ddfL > -DIDENT_UIDHASH=0xcaf9dca5L -fnesc-dump=wiring > -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, > components)' -fnesc-dumpfile=build/micaz/wiring-check.xml > AssociationExampleC.nc -lm > In file included from AssociationExampleP.nc:7, > from AssociationExampleC.nc:22: > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h: In > function `printfUART_init_private': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h:123: > warning: implicit declaration of function `outp' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h:127: > warning: implicit declaration of function `inp' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h: In > function `UARTPutChar': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h:213: > warning: implicit declaration of function `outb' > In file included from > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacC.nc:43, > from AssociationExampleC.nc:26: > In component `MacP': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function > `Init.init': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:540: implicit > declaration of function `powf' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function > `TimerAsync.backoff_fired': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:924: implicit > declaration of function `powf' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function > `process_beacon': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:1322: implicit > declaration of function `powf' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:1331: implicit > declaration of function `powf' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:1402: implicit > 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 <[email protected]> > 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 >> <[email protected]> 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 <[email protected]> >>>> >>>> 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 >>>> <[email protected]> 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 <[email protected]> >>>>>> >>>>>> 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 >>>>>> <[email protected]> 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 <[email protected]> >>>>>>>> >>>>>>>> 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 <[email protected]> >>>>>>>> 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 >>>>>>>> > [email protected] >>>>>>>> > >>>>>>>> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>>>>> > >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Tinyos-help mailing list >>>>>>>> [email protected] >>>>>>>> >>>>>>>> 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 >>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> [email protected] >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
