[Tinyos-help] 802.15.4

Daniel Schnit daniel.schnit at gmail.com
Thu Nov 18 23:08:40 PST 2010


Sorry..but this problem i found a solution! and know my problem is


AssociationExampleP.nc:413: warning: pointer targets in passing argument 2
of 'sprintf' differ in signedness
/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'
/tmp/ccn1OOJb.o: In function `printfUART_init_private':
app.c:(.text+0x11b6): undefined reference to `outp'
app.c:(.text+0x11c2): undefined reference to `outp'
app.c:(.text+0x11ce): undefined reference to `outp'
app.c:(.text+0x11dc): undefined reference to `outp'
app.c:(.text+0x11e4): undefined reference to `inp'
app.c:(.text+0x11f0): undefined reference to `outp'
/tmp/ccn1OOJb.o: In function `UARTPutChar':
app.c:(.text+0x142c): undefined reference to `outb'
make: *** [exe0] Error 1


On Fri, Nov 19, 2010 at 4:51 AM, Daniel Schnit <daniel.schnit at gmail.com>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 <daniel.schnit at gmail.com>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.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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Tinyos-help mailing list
>>> Tinyos-help at millennium.berkeley.edu
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101119/f0c849bd/attachment-0001.htm 


More information about the Tinyos-help mailing list