Re: [Tinyos-help] 802.15.4 on Iris nodes
Hi Quentin, > Is it possible to put the TinyOS tkn154 apps on the iris nodes At the moment not, because TKN154 has not been ported to the RF230 radio (at least I'm not aware of it). Jan On Sat, Feb 9, 2013 at 8:15 PM, Quentin Strydom wrote: > Hi, > > Is it possible to put the TinyOS tkn154 apps on the iris nodes and how > if it is? > > Thanks > ___ > 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
[Tinyos-help] 802.15.4 on Iris nodes
Hi, Is it possible to put the TinyOS tkn154 apps on the iris nodes and how if it is? Thanks ___ 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 stack on Iris mote (RF230)
Did you manage to make it work? I should do the same thing. Janos Sallai wrote: > >> I am currently working on a project where I have to make communicate >> different kind of motes together: Iris motes based on TinyOS 2.x in one >> side >> and a device with an Xbee component (from Digi) on the other side. They >> are >> both 802.15.4 compliant but I have problems to make them communicate. >> Iris motes can hear packet from Xbee but Xbee cannot see packets from >> Iris. >> I think it's because the Xbee component keeps only packets from devices >> which are in his 802.15.4 network. > > Use the Ieee154Packet interface, provided by Rf230RadioC, to set the > network field of the outgoing packets. I would try using the network > ID the Xbee modules do. You will need to do it on a per packet basis. > To send a message, use the Ieee154Send interface. > >> So, I want to implement the 802.15.4 protocol stack on my Iris motes to >> create a network with both devices. The problem is that I find a 802.15.4 >> protocol stack only for micaz and TelosB motes, so with a CC2420 radio >> (stack developed by open-zb) and not for my RF230 radio. >> First, I'm surprised that there is no stack for Iris motes already >> developed, is it that or did I miss something? > As far as I know, 802.15.4 defines PHY and MAC only. That _is_ > supported on the iris. > > Are you refering to zigbee? I think none of the zigbee code under > tos/lib/net works on the iris. I can't comment on how much of an > effort porting would require. > > Janos > ___ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > -- View this message in context: http://old.nabble.com/802.15.4-stack-on-Iris-mote-%28RF230%29-tp28312006p33938912.html Sent from the TinyOS - Help mailing list archive at Nabble.com. ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 testbed setup?
Hi all, I'm wondering if anyone here has got any interesting (900MHz) 802.15.4 testbed setups? What I would like to do here is to connect up a bunch of nodes via an RF matrix switch/mixer/attenuator, so I can run deterministic tests on the meshing functionality. The ability to control the strength of the signal received at each node on a per-source basis is the key feature I'm after. For now something on the order of 4-6 nodes would be quite sufficient. I haven't had any success finding any commercial equipment (or even DIY) available to enable this type of setup. Has anyone here done anything similar and can provide some recommendations? My fall-back position will be to do this in a software layer above the radio driver, but I would very much prefer to be able to do it in hardware if possible. Simply distributing nodes around the place will not be sufficient for the testing I want to do, and it would also be a pain to firmware upgrades since we haven't got over-the-air upgrades going (yet). Thanks in advance, /Johny -- Johny Mattsson Senior Software Engineer DiUS Computing Pty. Ltd. *where ideas are engineered * ___ 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 and ZigBee
CTP is a custom protocol implemented on top of 801.15.4. It is also implemented on top of a custom encapsulation called AM (active messaging). On Sat, Apr 23, 2011 at 12:47 PM, wrote: > Hi! > I've a question about IEEE 802.15.4 and ZigBee standars. I know IEEE8 > 802.15.4 is only the physical and MAC (link) layers (OSI model) and ZigBee > implements more layers (network, app). > When I use Collection (CTP), Dissemination protocols (over radio), which > standar am I using? IEEE or ZigBee? > > Thanks!! > > > ╔══╗ > ║José A. Tarifa Galisteo > ║ > ║ Estudiante Ingeniería de Telecomunicación > ║ Escuela Superior de Ingenieros - U. Sevilla > ║ http://alumno.us.es/j/jostargal/ > ╚══╝ > ___ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 and ZigBee
Hi! I've a question about IEEE 802.15.4 and ZigBee standars. I know IEEE8 802.15.4 is only the physical and MAC (link) layers (OSI model) and ZigBee implements more layers (network, app). When I use Collection (CTP), Dissemination protocols (over radio), which standar am I using? IEEE or ZigBee? Thanks!! ╔══╗ ║José A. Tarifa Galisteo ║ ║ Estudiante Ingeniería de Telecomunicación ║ Escuela Superior de Ingenieros - U. Sevilla ║ http://alumno.us.es/j/jostargal/ ╚══╝ ___ 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
Thanks a million Jan. Excellent work like always. Regards, Pablo ___ 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
It seems like the ScanP component was calling Radio.off() at a time,
when it didn't own the radio token (anymore). Looking at the code,
this is likely because the ScanTimer is not stopped after the
realignment frame was received. I committed a fix to SVN, please
retry.
Thanks,
Jan
On Fri, Nov 26, 2010 at 3:47 PM, Pablo Marcos
wrote:
> HI all again,
> I have been adding functionality to my application, and apart of other
> things, I have tried to resynchronize the devices with the MLME_ORPHAN. I
> noticed that after sending with the coordinator the realignment, the device
> wasn't re-synchronizing at all, and was still lost. So, apart from my own
> printf's, I compiled in TKN154_DEBUG mode, and I got this (take note that my
> own printf's appear always before the TKN154_DEBUG ones):
> Coordinator:
> BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
> BeaconTransmitP:502:Beacon Tx scheduled for 162567148
> BeaconTransmitP:518:Beacon Tx (bsn: 61) success at 162567146
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 7711
> DispatchSlottedCsmaP:382:Handing over to CFP.
> BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
> Device 847425747 Orphaned. It is on my assocList, so I send a response
> Orphan Response succesfully sent to 0
> BeaconTransmitP:502:Beacon Tx scheduled for 162597866
> BeaconTransmitP:518:Beacon Tx (bsn: 62) success at 162597866
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 776677711
> Device:
> BeaconSynchronizeP:210:Got token (transferred).
> BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364 symbols.
> BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278 symbols.
> BeaconSynchronizeP:421:Got beacon - bsn: 61, offset to last: 30718
> BeaconSynchronizeP:447:Handing over to CAP.
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30116
> Device 0 SYNC LOST for 1 time with aMaxLostBeacons 1 because of E0. Telling
> coordinator that I am Orphan
> Orphan Request succesfully
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 81
> DispatchSlottedCsmaP:382:Handing over to CFP.
> BeaconSynchronizeP:210:Got token (transferred).
> BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364 symbols.
> BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278 symbols.
> BeaconSynchronizeP:385:Missed a beacon (total missed: 1).
> BeaconSynchronizeP:395:MLME_SYNC_LOSS!
> ScanP:176:MLME_SCAN.request -> result: 0
> BeaconSynchronizeP:228:Stop tracking.
> ScanP:255:Scanning channel 20...
> ScanP:363:Received coordinator realignment frame.
> ScanP:302:MLME_SCAN.confirm()
> Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
> line: 198, function: RadioControlImplP__MacRadioOff__off.
> Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
> line: 198, function: RadioControlImplP__MacRadioOff__off.
> ...
> I thought that although the coordinator was sending the re-alignment command
> successfully, the device wasn't getting it, but after seeing this, it seems
> that after getting it, it gets some error. It seems the MLME_SCAN.confirm()
> is not completed, and so, the device is not re-aligning with the
> coordinator.
> I have checked the error lines un RadioControlImp as well:
> async command error_t MacRadioOff.off[uint8_t client]()
> {
> if (client == call ArbiterInfo.userId())
> return call PhyRadioOff.off();
> else {
> ASSERT(0);
> return EBUSY;
> }
> }
> but I have no idea why is getting an error in the ASSERT.
> Does anyone have an idea of why this is happening?
> Thanks in advance.
> Regards,
> Pablo
>
> 2010/11/23 Pablo Marcos
>>
>> Thanks a lot Jan.
>> The problem is that each time I try to use the default printf in the
>> coordinator, my application loses sync. So right now, the only way I know
>> about getting results is using another node as sniffer (using
>> TestPromiscuous), which seems to work fine and cannot lose sync cause it is
>> not associated and is just listening packets. The problem is that for
>> instante, if you want to know how much packets the coordinator has rx, you
>> cannot guarantee that using another node, obviously.
>> For what Aitor said, it seems the dbg_serial is a lot better than the
>> default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
>> dbg_serial, but do with the default printf), so I was wondering if it would
>> be any way to make the dbg_serial work without having all the TKN154
>> dbg_serial's by default, just the ones that I write "by hand" in my own app.
>> Regards,
>> Pablo
>> 2010/11/23 Jan Hauer
>>>
>>> On Mon, Nov 22, 2010 at 6:50 PM, Pablo Marcos
>>> wrote:
>>> > Hi,
>>> > About the TKN154_DEBU
Re: [Tinyos-help] 802.15.4
Hi ppl,
i'm read in TKN papers, and i'm a little confused. in tinyOs the unslotted
csma/ca is implemented?
Bye
On Fri, Nov 26, 2010 at 12:47 PM, Pablo Marcos wrote:
> HI all again,
>
> I have been adding functionality to my application, and apart of other
> things, I have tried to resynchronize the devices with the MLME_ORPHAN. I
> noticed that after sending with the coordinator the realignment, the device
> wasn't re-synchronizing at all, and was still lost. So, apart from my own
> printf's, I compiled in TKN154_DEBUG mode, and I got this (take note that my
> own printf's appear always before the TKN154_DEBUG ones):
>
> *Coordinator:*
>
> BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
> BeaconTransmitP:502:Beacon Tx scheduled for 162567148
> BeaconTransmitP:518:Beacon Tx (bsn: 61) success at 162567146
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 7711
> DispatchSlottedCsmaP:382:Handing over to CFP.
> BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
>
> Device 847425747 Orphaned. It is on my assocList, so I send a response
> Orphan Response succesfully sent to 0
> BeaconTransmitP:502:Beacon Tx scheduled for 162597866
> BeaconTransmitP:518:Beacon Tx (bsn: 62) success at 162597866
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 776677711
>
> *Device:*
>
> BeaconSynchronizeP:210:Got token (transferred).
> BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364
> symbols.
> BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278
> symbols.
> BeaconSynchronizeP:421:Got beacon - bsn: 61, offset to last: 30718
> BeaconSynchronizeP:447:Handing over to CAP.
> DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30116
>
> Device 0 SYNC LOST for 1 time with aMaxLostBeacons 1 because of E0. Telling
> coordinator that I am Orphan
> Orphan Request succesfully
> DispatchSlottedCsmaP:542:CapEndAlarm.fired()
> DispatchSlottedCsmaP:168:updateState() transitions: 81
> DispatchSlottedCsmaP:382:Handing over to CFP.
> BeaconSynchronizeP:210:Got token (transferred).
> BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364
> symbols.
> BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278
> symbols.
> BeaconSynchronizeP:385:Missed a beacon (total missed: 1).
> BeaconSynchronizeP:395:MLME_SYNC_LOSS!
> ScanP:176:MLME_SCAN.request -> result: 0
> BeaconSynchronizeP:228:Stop tracking.
> ScanP:255:Scanning channel 20...
> ScanP:363:Received coordinator realignment frame.
> ScanP:302:MLME_SCAN.confirm()
> Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
> line: 198, function: RadioControlImplP__MacRadioOff__off.
> Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
> line: 198, function: RadioControlImplP__MacRadioOff__off.
> ...
>
> I thought that although the coordinator was sending the re-alignment
> command successfully, the device wasn't getting it, but after seeing this,
> it seems that after getting it, it gets some error. It seems the
> MLME_SCAN.confirm() is not completed, and so, the device is not re-aligning
> with the coordinator.
>
> I have checked the error lines un RadioControlImp as well:
>
>async command error_t MacRadioOff.off[uint8_t client]()
> {
> if (client == call ArbiterInfo.userId())
> return call PhyRadioOff.off();
> else {
> ASSERT(0);
> return EBUSY;
> }
> }
>
> but I have no idea why is getting an error in the ASSERT.
>
> Does anyone have an idea of why this is happening?
>
> Thanks in advance.
>
> Regards,
> Pablo
>
>
> 2010/11/23 Pablo Marcos
>
> Thanks a lot Jan.
>>
>> The problem is that each time I try to use the default printf in the
>> coordinator, my application loses sync. So right now, the only way I know
>> about getting results is using another node as sniffer (using
>> TestPromiscuous), which seems to work fine and cannot lose sync cause it is
>> not associated and is just listening packets. The problem is that for
>> instante, if you want to know how much packets the coordinator has rx, you
>> cannot guarantee that using another node, obviously.
>>
>> For what Aitor said, it seems the dbg_serial is a lot better than the
>> default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
>> dbg_serial, but do with the default printf), so I was wondering if it would
>> be any way to make the dbg_serial work without having all the TKN154
>> dbg_serial's by default, just the ones that I write "by hand" in my own app.
>>
>> Regards,
>> Pablo
>>
>> 2010/11/23 Jan Hauer
>>
>> On Mon, Nov 22, 2010 at 6:50 PM, 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
Re: [Tinyos-help] 802.15.4
HI all again,
I have been adding functionality to my application, and apart of other
things, I have tried to resynchronize the devices with the MLME_ORPHAN. I
noticed that after sending with the coordinator the realignment, the device
wasn't re-synchronizing at all, and was still lost. So, apart from my own
printf's, I compiled in TKN154_DEBUG mode, and I got this (take note that my
own printf's appear always before the TKN154_DEBUG ones):
*Coordinator:*
BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
BeaconTransmitP:502:Beacon Tx scheduled for 162567148
BeaconTransmitP:518:Beacon Tx (bsn: 61) success at 162567146
DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
DispatchSlottedCsmaP:542:CapEndAlarm.fired()
DispatchSlottedCsmaP:168:updateState() transitions: 7711
DispatchSlottedCsmaP:382:Handing over to CFP.
BeaconSynchronizeP:409:Token transferred, will Tx beacon in 322
Device 847425747 Orphaned. It is on my assocList, so I send a response
Orphan Response succesfully sent to 0
BeaconTransmitP:502:Beacon Tx scheduled for 162597866
BeaconTransmitP:518:Beacon Tx (bsn: 62) success at 162597866
DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30222
DispatchSlottedCsmaP:542:CapEndAlarm.fired()
DispatchSlottedCsmaP:168:updateState() transitions: 776677711
*Device:*
BeaconSynchronizeP:210:Got token (transferred).
BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364 symbols.
BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278 symbols.
BeaconSynchronizeP:421:Got beacon - bsn: 61, offset to last: 30718
BeaconSynchronizeP:447:Handing over to CAP.
DispatchSlottedCsmaP:217:Got token, remaining CAP time: 30116
Device 0 SYNC LOST for 1 time with aMaxLostBeacons 1 because of E0. Telling
coordinator that I am Orphan
Orphan Request succesfully
DispatchSlottedCsmaP:542:CapEndAlarm.fired()
DispatchSlottedCsmaP:168:updateState() transitions: 81
DispatchSlottedCsmaP:382:Handing over to CFP.
BeaconSynchronizeP:210:Got token (transferred).
BeaconSynchronizeP:236:Token.transferred(), expecting beacon in 364 symbols.
BeaconSynchronizeP:312:Rx enabled, expecting beacon within next 278 symbols.
BeaconSynchronizeP:385:Missed a beacon (total missed: 1).
BeaconSynchronizeP:395:MLME_SYNC_LOSS!
ScanP:176:MLME_SCAN.request -> result: 0
BeaconSynchronizeP:228:Stop tracking.
ScanP:255:Scanning channel 20...
ScanP:363:Received coordinator realignment frame.
ScanP:302:MLME_SCAN.confirm()
Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
line: 198, function: RadioControlImplP__MacRadioOff__off.
Assert failed: File: /home/pablo/tinyos-2.1.1/tos/lib/mac/tkn154/RadioC,
line: 198, function: RadioControlImplP__MacRadioOff__off.
...
I thought that although the coordinator was sending the re-alignment command
successfully, the device wasn't getting it, but after seeing this, it seems
that after getting it, it gets some error. It seems the MLME_SCAN.confirm()
is not completed, and so, the device is not re-aligning with the
coordinator.
I have checked the error lines un RadioControlImp as well:
async command error_t MacRadioOff.off[uint8_t client]()
{
if (client == call ArbiterInfo.userId())
return call PhyRadioOff.off();
else {
ASSERT(0);
return EBUSY;
}
}
but I have no idea why is getting an error in the ASSERT.
Does anyone have an idea of why this is happening?
Thanks in advance.
Regards,
Pablo
2010/11/23 Pablo Marcos
> Thanks a lot Jan.
>
> The problem is that each time I try to use the default printf in the
> coordinator, my application loses sync. So right now, the only way I know
> about getting results is using another node as sniffer (using
> TestPromiscuous), which seems to work fine and cannot lose sync cause it is
> not associated and is just listening packets. The problem is that for
> instante, if you want to know how much packets the coordinator has rx, you
> cannot guarantee that using another node, obviously.
>
> For what Aitor said, it seems the dbg_serial is a lot better than the
> default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
> dbg_serial, but do with the default printf), so I was wondering if it would
> be any way to make the dbg_serial work without having all the TKN154
> dbg_serial's by default, just the ones that I write "by hand" in my own app.
>
> Regards,
> Pablo
>
> 2010/11/23 Jan Hauer
>
> On Mon, Nov 22, 2010 at 6:50 PM, 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
Re: [Tinyos-help] 802.15.4
Thanks a lot Jan.
The problem is that each time I try to use the default printf in the
coordinator, my application loses sync. So right now, the only way I know
about getting results is using another node as sniffer (using
TestPromiscuous), which seems to work fine and cannot lose sync cause it is
not associated and is just listening packets. The problem is that for
instante, if you want to know how much packets the coordinator has rx, you
cannot guarantee that using another node, obviously.
For what Aitor said, it seems the dbg_serial is a lot better than the
default one (my nodes doesn't lose sync with TKN154_DEBUG and all their
dbg_serial, but do with the default printf), so I was wondering if it would
be any way to make the dbg_serial work without having all the TKN154
dbg_serial's by default, just the ones that I write "by hand" in my own app.
Regards,
Pablo
2010/11/23 Jan Hauer
> On Mon, Nov 22, 2010 at 6:50 PM, 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?
>
> When TKN154_DEBUG is defined you can also use printf("...") to output
> your debug info over serial, but keep in mind that you should be in
> sync context (in async command/event handlers you can use
> tkn154_dbg_serial(), see tos/lib/mac/tkn154/TKN154_MAC.h line 289). If
> you only want your own debug messages, then don't define TKN154_DEBUG,
> instead use printf library as described in the tutorial
> (http://docs.tinyos.net/index.php/The_TinyOS_printf_Library). To
> disable / remove all your debug printf-statements later you can do
> something like this:
>
> #define printf(...)
>
> > 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
> >> 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 applicatio
Re: [Tinyos-help] 802.15.4
On Mon, Nov 22, 2010 at 8:47 PM, Aitor Hernandez 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
> 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
>>> 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 th
Re: [Tinyos-help] 802.15.4
On Mon, Nov 22, 2010 at 6:50 PM, 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?
When TKN154_DEBUG is defined you can also use printf("...") to output
your debug info over serial, but keep in mind that you should be in
sync context (in async command/event handlers you can use
tkn154_dbg_serial(), see tos/lib/mac/tkn154/TKN154_MAC.h line 289). If
you only want your own debug messages, then don't define TKN154_DEBUG,
instead use printf library as described in the tutorial
(http://docs.tinyos.net/index.php/The_TinyOS_printf_Library). To
disable / remove all your debug printf-statements later you can do
something like this:
#define printf(...)
> 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
>> 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 sh
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.
>>>
>>> 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 wher
Re: [Tinyos-help] 802.15.4
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.
>>
>> 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
Re: [Tinyos-help] 802.15.4
CAP (slotted CSMA-CA) is implemented. CFP (=GTS) is not yet implemented, but I guess it will be in near future, because different people seem to be implementing it. Jan On Fri, Nov 19, 2010 at 3: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 > 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 >>> 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 > 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. >> Yo
Re: [Tinyos-help] 802.15.4
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 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=10 -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 > 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 >> 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 syn
Re: [Tinyos-help] 802.15.4
I've checked in a fix that makes the time-stamping more reliable (but also more "conservative" -> in case there are problems the entire queue is flushed). Please update from svn (http://code.google.com/p/tinyos-main/source/checkout) and retry. Thanks, Jan On Thu, Nov 18, 2010 at 10:46 AM, Jan Hauer wrote: > 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
Re: [Tinyos-help] 802.15.4/ZigBee
I solved it =D. Now i'm trying to undertand the GTS example, but now i dont understand nothing...anyone know about this application? Thanks for all On Fri, Nov 19, 2010 at 11:59 AM, Daniel Schnit wrote: > Sorry, but i create a new thread because this subject is different > > Anyone can help me? if i make telosb everything is ok, but micaz > Please help me :) > > desktop:/opt/tinyos-2.x/tos/lib/net/zigbee/apps/AssociationExample$ make > micazmkdir -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=10 -DIDENT_APPNAME=\"AssociationExam\" > -DIDENT_USERNAME=\"marcelo\" -DIDENT_HOSTNAME=\"marcelo-desktop\" > -DIDENT_USERHASH=0xf714c009L -DIDENT_TIMESTAMP=0x4ce681eaL > -DIDENT_UIDHASH=0x51ec9e8dL -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' > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h:238: > warning: declaration of 'sprintf' shadows a built-in function > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function > 'MacP__T_ScanDuration__fired': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3467: warning: > pointer targets in passing argument 1 of 'sprintf' differ in signedness > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3467: warning: > pointer targets in passing argument 2 of 'sprintf' differ in signedness > AssociationExampleP.nc: In function > 'AssociationExampleP__MLME_BEACON_NOTIFY__indication': > AssociationExampleP.nc:346: warning: pointer targets in passing argument 1 > of 'sprintf' differ in signedness > AssociationExampleP.nc:346: warning: pointer targets in passing argument 2 > of 'sprintf' differ in signedness > AssociationExampleP.nc:350: warning: pointer targets in passing argument 1 > of 'sprintf' differ in signedness > AssociationExampleP.nc:350: warning: pointer targets in passing argument 2 > of 'sprintf' differ in signedness > AssociationExampleP.nc: In function > 'AssociationExampleP__MLME_ORPHAN__indication': > AssociationExampleP.nc:266: warning: pointer targets in passing argument 1 > of 'sprintf' differ in signedness > AssociationExampleP.nc:266: warning: pointer targets in passing argument 2 > of 'sprintf' differ in signedness > AssociationExampleP.nc: In function > 'AssociationExampleP__MLME_ASSOCIATE__indication': > AssociationExampleP.nc:398: warning: pointer targets in passing argument 1 > of 'sprintf' differ in signedness > AssociationExampleP.nc:398: warning: pointer targets in passing argument 2 > of 'sprintf' differ in signedness > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function > 'MacP__data_channel_scan_indication__runTask': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3410: warning: > pointer targets in passing argument 1 of 'sprintf' differ in signedness > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3410: warning: > pointer targets in passing argument 2 of 'sprintf' differ in signedness > AssociationExampleP.nc: In function > 'AssociationExampleP__MLME_SYNC_LOSS__indication': > AssociationExampleP.nc:310: warning: pointer targets in passing argument 1 > of 'sprintf' differ in signedness > AssociationExampleP.nc:310: warning: pointer targets in passing argument 2 > of 'sprintf' differ in signedness > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function > 'MacP__MLME_ASSOCIATE__request': > /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3789: warning: > pointer targets in passing argument 1 of 'sprintf' differ in signedness > /opt
[Tinyos-help] 802.15.4/ZigBee
Sorry, but i create a new thread because this subject is different Anyone can help me? if i make telosb everything is ok, but micaz Please help me :) desktop:/opt/tinyos-2.x/tos/lib/net/zigbee/apps/AssociationExample$ make micazmkdir -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=10 -DIDENT_APPNAME=\"AssociationExam\" -DIDENT_USERNAME=\"marcelo\" -DIDENT_HOSTNAME=\"marcelo-desktop\" -DIDENT_USERHASH=0xf714c009L -DIDENT_TIMESTAMP=0x4ce681eaL -DIDENT_UIDHASH=0x51ec9e8dL -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' /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h:238: warning: declaration of 'sprintf' shadows a built-in function /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function 'MacP__T_ScanDuration__fired': /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3467: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3467: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness AssociationExampleP.nc: In function 'AssociationExampleP__MLME_BEACON_NOTIFY__indication': AssociationExampleP.nc:346: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness AssociationExampleP.nc:346: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness AssociationExampleP.nc:350: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness AssociationExampleP.nc:350: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness AssociationExampleP.nc: In function 'AssociationExampleP__MLME_ORPHAN__indication': AssociationExampleP.nc:266: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness AssociationExampleP.nc:266: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness AssociationExampleP.nc: In function 'AssociationExampleP__MLME_ASSOCIATE__indication': AssociationExampleP.nc:398: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness AssociationExampleP.nc:398: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function 'MacP__data_channel_scan_indication__runTask': /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3410: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3410: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness AssociationExampleP.nc: In function 'AssociationExampleP__MLME_SYNC_LOSS__indication': AssociationExampleP.nc:310: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness AssociationExampleP.nc:310: warning: pointer targets in passing argument 2 of 'sprintf' differ in signedness /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc: In function 'MacP__MLME_ASSOCIATE__request': /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3789: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/mac/MacP.nc:3789: 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 'sprintf': /opt/tinyos-2.x/tos/lib/net/zigbee/ieee802154/includes/printfUART.h:265: warning: pointer targets in assignment differ in signedness /opt/tin
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 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 synch
Re: [Tinyos-help] 802.15.4
Hi, About the GTS mechanism and transmission in CFP. I've developed the GTS implementation based on TKN15.4 but the code is not published yet. As soon as we publish the first release and documentation I will post them in this mailist. Best, On 19 November 2010 08:08, Daniel Schnit wrote: > 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 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=10 -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: I
Re: [Tinyos-help] 802.15.4
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 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=10 -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/zigb
Re: [Tinyos-help] 802.15.4
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=10 -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 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
Re: [Tinyos-help] 802.15.4
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 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 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
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 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 ma
Re: [Tinyos-help] 802.15.4
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 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
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
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 > ___ 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
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
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
but Promiscuos are better to use for 802.15.4 and the examples? the problem is one device cant syncro and the promiscuos print this code, but if i reset promiscuos he starts print correct and after just Frametype: Data SrcAddrMode On Wed, Nov 17, 2010 at 9:21 AM, Jan Hauer wrote: > >> i'm testing TestData with one coordinator and two devices. > >> Problem: > >> ->the prosmicuos print this > >> Frametype: Data > >> SrcAddrMode > > is the problem TestData (do the LEDs toggle as described?) or only > TestPromiscuous? (also check with latest SVN version, > http://code.google.com/p/tinyos-main/) > > > I have other question... > > Whats the difference BaseStation15.4 and TestPromiscuos? > > apps/tests/tkn154/nonbeacon-enabled/TestPromiscuous uses the TKN15.4 > MAC (tos/lib/mac/tkn154); apps/BaseStation15.4 uses ActiveMessageC, > which wires the platform's default MAC (e.g. tos/chips/cc2420). > > Jan > > > Thanks for all > > > > On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit > > > wrote: > >> > >> Hi all, > >> i'm testing TestData with one coordinator and two devices. > >> Problem: > >> ->the prosmicuos print this > >> Frametype: Data > >> SrcAddrMode > >> Frametype: Data > >> SrcAddrMode > >> Frametype: Data > >> SrcAddrMode > >> Frametype: Data > >> SrcAddrMode > >> > >> -> i can't syncronize two devices...just one syncronize! > >> Thks, > > > > ___ > > 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
Re: [Tinyos-help] 802.15.4
I have tried TestData with two devices (compiling with TKN154_DEBUG=1) and I have noticed the same problem. Only one device at a time is sync, cause the other one loses the beacon frame and hence, sync. This could be cause the Test is thought to have just one device sync, and so this one is sending packets all the time. If you try to set up a timer so that the devices send just 1packet/second, you will have no problems in this aspect. Nevertheless, I have had some problems using timers and the tkn154, cause it makes lose sync after a while (could be 2mins or 2hours, depends on the BO and the time between packets). Regards, Pablo 2010/11/17 Jan Hauer > >> i'm testing TestData with one coordinator and two devices. > >> Problem: > >> ->the prosmicuos print this > >> Frametype: Data > >> SrcAddrMode > > is the problem TestData (do the LEDs toggle as described?) or only > TestPromiscuous? (also check with latest SVN version, > http://code.google.com/p/tinyos-main/) > > > I have other question... > > Whats the difference BaseStation15.4 and TestPromiscuos? > > apps/tests/tkn154/nonbeacon-enabled/TestPromiscuous uses the TKN15.4 > MAC (tos/lib/mac/tkn154); apps/BaseStation15.4 uses ActiveMessageC, > which wires the platform's default MAC (e.g. tos/chips/cc2420). > > Jan > > > Thanks for all > > > > On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit > > > wrote: > >> > >> Hi all, > >> i'm testing TestData with one coordinator and two devices. > >> Problem: > >> ->the prosmicuos print this > >> Frametype: Data > >> SrcAddrMode > >> Frametype: Data > >> SrcAddrMode > >> Frametype: Data > >> SrcAddrMode > >> Frametype: Data > >> SrcAddrMode > >> > >> -> i can't syncronize two devices...just one syncronize! > >> Thks, > > > > ___ > > 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 > ___ 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
>> i'm testing TestData with one coordinator and two devices. >> Problem: >> ->the prosmicuos print this >> Frametype: Data >> SrcAddrMode is the problem TestData (do the LEDs toggle as described?) or only TestPromiscuous? (also check with latest SVN version, http://code.google.com/p/tinyos-main/) > I have other question... > Whats the difference BaseStation15.4 and TestPromiscuos? apps/tests/tkn154/nonbeacon-enabled/TestPromiscuous uses the TKN15.4 MAC (tos/lib/mac/tkn154); apps/BaseStation15.4 uses ActiveMessageC, which wires the platform's default MAC (e.g. tos/chips/cc2420). Jan > Thanks for all > > On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit > wrote: >> >> Hi all, >> i'm testing TestData with one coordinator and two devices. >> Problem: >> ->the prosmicuos print this >> Frametype: Data >> SrcAddrMode >> Frametype: Data >> SrcAddrMode >> Frametype: Data >> SrcAddrMode >> Frametype: Data >> SrcAddrMode >> >> -> i can't syncronize two devices...just one syncronize! >> Thks, > > ___ > 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
Re: [Tinyos-help] 802.15.4
I have other question... Whats the difference BaseStation15.4 and TestPromiscuos? Thanks for all On Tue, Nov 16, 2010 at 10:59 PM, Daniel Schnit wrote: > Hi all, > > i'm testing TestData with one coordinator and two devices. > Problem: > ->the prosmicuos print this > > Frametype: Data > SrcAddrMode > Frametype: Data > SrcAddrMode > Frametype: Data > SrcAddrMode > Frametype: Data > SrcAddrMode > > > -> i can't syncronize two devices...just one syncronize! > > Thks, > ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4
Hi all, i'm testing TestData with one coordinator and two devices. Problem: ->the prosmicuos print this Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode Frametype: Data SrcAddrMode -> i can't syncronize two devices...just one syncronize! Thks, ___ 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
There is a 802.15.4 MAC implementation in the core, but it is not the default MAC protocol (i.e. unless you explicitly wire your app / protocol to the MAC it will not be used). Here is a description how to use it: tos/lib/mac/tkn154/README.txt On Sun, Oct 24, 2010 at 4:11 AM, Daniel Schnit wrote: > Hi all, > i need to use 802.15.4/ZigBee Protocol...my question is the default protocol > in TinyOs is 802.15.4. > thanks for all > ___ > 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
Re: [Tinyos-help] 802.15.4
Well default in tinyos is an interesting concept. But one of the predominant protocols is Active Messaging which is a simple protocol. It works. The other major protocol is 802.15.4 but I wouldn't exactly call it the default. Most of the tutorials and simple things all use AM. It really depends on how you wire things up. eric On Sat, Oct 23, 2010 at 7:11 PM, Daniel Schnit wrote: > Hi all, > > i need to use 802.15.4/ZigBee Protocol...my question is the default > protocol in TinyOs is 802.15.4. > > thanks for all > > ___ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4
Hi all, i need to use 802.15.4/ZigBee Protocol...my question is the default protocol in TinyOs is 802.15.4. thanks for all ___ 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 stack on Iris mote (RF230)
> I am currently working on a project where I have to make communicate > different kind of motes together: Iris motes based on TinyOS 2.x in one side > and a device with an Xbee component (from Digi) on the other side. They are > both 802.15.4 compliant but I have problems to make them communicate. > Iris motes can hear packet from Xbee but Xbee cannot see packets from Iris. > I think it's because the Xbee component keeps only packets from devices > which are in his 802.15.4 network. Use the Ieee154Packet interface, provided by Rf230RadioC, to set the network field of the outgoing packets. I would try using the network ID the Xbee modules do. You will need to do it on a per packet basis. To send a message, use the Ieee154Send interface. > So, I want to implement the 802.15.4 protocol stack on my Iris motes to > create a network with both devices. The problem is that I find a 802.15.4 > protocol stack only for micaz and TelosB motes, so with a CC2420 radio > (stack developed by open-zb) and not for my RF230 radio. > First, I'm surprised that there is no stack for Iris motes already > developed, is it that or did I miss something? As far as I know, 802.15.4 defines PHY and MAC only. That _is_ supported on the iris. Are you refering to zigbee? I think none of the zigbee code under tos/lib/net works on the iris. I can't comment on how much of an effort porting would require. Janos ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 stack on Iris mote (RF230)
Hello, I am currently working on a project where I have to make communicate different kind of motes together: Iris motes based on TinyOS 2.x in one side and a device with an Xbee component (from Digi) on the other side. They are both 802.15.4 compliant but I have problems to make them communicate. Iris motes can hear packet from Xbee but Xbee cannot see packets from Iris. I think it's because the Xbee component keeps only packets from devices which are in his 802.15.4 network. So, I want to implement the 802.15.4 protocol stack on my Iris motes to create a network with both devices. The problem is that I find a 802.15.4 protocol stack only for micaz and TelosB motes, so with a CC2420 radio (stack developed by open-zb) and not for my RF230 radio. First, I'm surprised that there is no stack for Iris motes already developed, is it that or did I miss something? Then, I'm trying to translate the open-zb stack to make it work on my motes, but it seems a really big work, is there something to help me to do this, or do I have to do the whole thing? Thanks in advance, Lionel Croix ___ 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: Indirect transmissions in beacon-enabled mode
On Wed, Feb 17, 2010 at 11:50 PM, Jonathan ROY wrote:
> I did a CVS update, but I've still some troubles with the Frame Pending
> flag: in case the coordinator has 2 data frames pending for a device, the
> first one to be requested will have its Pending Flag set (this is OK) but
> the second frame will also have it whereas the coordinator doesn't have
> another pending frame for the device...Is this normal ?
No, but since "our" devices are not using this information it wasn't
noticed / didn't matter so far. I will take a look.
Jan
On Wed, Feb 17, 2010 at 11:50 PM, Jonathan ROY wrote:
> I did a CVS update, but I've still some troubles with the Frame Pending
> flag: in case the coordinator has 2 data frames pending for a device, the
> first one to be requested will have its Pending Flag set (this is OK) but
> the second frame will also have it whereas the coordinator doesn't have
> another pending frame for the device...Is this normal ?
>
> In IndirectTxP.nc I did the following test (added lines are prefixed by
> '>>'):
>
> event message_t* DataRequestRx.received(message_t* frame)
> {
> uint8_t i, j, srcAddressMode, dstAddressMode, *src;
> uint8_t *mhr = MHR(frame);
> uint8_t destMode = (mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_MASK);
> ieee154_txframe_t *dataResponseFrame = NULL;
>
> // received a data request frame from a device
> // have we got some pending data for it ?
> srcAddressMode = (mhr[MHR_INDEX_FC2] & FC2_SRC_MODE_MASK);
> if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
> return frame; // no source address
> src = mhr + MHR_INDEX_ADDRESS;
> if (destMode == FC2_DEST_MODE_SHORT)
> src += 4;
> else if (destMode == FC2_DEST_MODE_EXTENDED)
> src += 10;
> if (!((mhr[MHR_INDEX_FC1] & FC1_PAN_ID_COMPRESSION) &&
> (mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_SHORT)))
> src += 2;
> for (i=0; i if (m_txFrameTable[i] == NULL)
> continue;
> else {
> dstAddressMode = (m_txFrameTable[i]->header->mhr[MHR_INDEX_FC2] &
> FC2_DEST_MODE_MASK);
> if ((dstAddressMode << 4) != srcAddressMode)
> continue;
> else {
> // we know: dstAddressMode IN [2,3]
> uint8_t *dst =
> &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2;
> uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
> for (j=0; j if (dst[j] != src[j])
> break; // no match!
> if (j==len) { // match!
> if (dataResponseFrame == NULL) {
> dataResponseFrame = m_txFrameTable[i];
>>> if ( dataResponseFrame->header->mhr[ MHR_INDEX_FC1 ] &
> FC1_FRAME_PENDING )
>>> Leds.led0Toggle();
> }
> else // got even more than one frame for this device: set
> pending flag
> dataResponseFrame->header->mhr[MHR_INDEX_FC1] |=
> FC1_FRAME_PENDING;
> }
> }
> }
> }
> if (dataResponseFrame != NULL) {
> // found a matching frame, mark it for transmission
> dbg_serial("IndirectTxP", "We have data for this device, trying to
> transmit...\n");
> dataResponseFrame->client |= SEND_THIS_FRAME;
> post tryCoordCapTxTask();
> } else {
> dbg_serial("IndirectTxP", "We don't have data for this device, sending
> an empty frame...\n");
> transmitEmptyDataFrame(frame);
> }
> return frame;
> }
>
> And LED 0 is toggled when the second data request is received from the
> device, how can this be possible ?
> Thank you very much for your help...
>
> Jonathan
>
>
> -Message d'origine-
> De : jan.ha...@gmail.com [mailto:jan.ha...@gmail.com] De la part de Jan
> Hauer
> Envoyé : lundi 15 février 2010 17:45
> À : Jonathan ROY
> Cc : tinyos-help@millennium.berkeley.edu
> Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled
> mode
>
>
> The code you posted is from an old version of IndirectTxP.nc, do a CVS
> update and take a look at line 232. Anyway, what is still missing is
> the device-side. It is on my todo list, but I will definitely not
> manage to do this within the next two weeks. Since it is probably not
> so complex you might want to take a look whether you can add the
> functionality yourself, you would have to edit PollP.nc (there is a
> comment in line 202, this is where you'd start). If you succeed, I'd
> be happy to integrate your code.
>
> Jan
>
> On Sat, Feb 13, 2010 at 11:12 PM, Jonathan ROY
> wrote:
>> Thank you for y
Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled mode
Spam detection software, running on the system "mail.Millennium.Berkeley.EDU",
has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: I did a CVS update, but I've still some troubles with the
Frame Pending flag: in case the coordinator has 2 data frames pending for
a device, the first one to be requested will have its Pending Flag set (this
is OK) but the second frame will also have it whereas the coordinator doesn't
have another pending frame for the device...Is this normal ? [...]
Content analysis details: (4.6 points, 3.3 required)
pts rule name description
-- --
1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.4873]
0.0 AWLAWL: From: address is in the auto white-list
--- Begin Message ---
I did a CVS update, but I've still some troubles with the Frame Pending
flag: in case the coordinator has 2 data frames pending for a device, the
first one to be requested will have its Pending Flag set (this is OK) but
the second frame will also have it whereas the coordinator doesn't have
another pending frame for the device...Is this normal ?
In IndirectTxP.nc I did the following test (added lines are prefixed by
'>>'):
event message_t* DataRequestRx.received(message_t* frame)
{
uint8_t i, j, srcAddressMode, dstAddressMode, *src;
uint8_t *mhr = MHR(frame);
uint8_t destMode = (mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_MASK);
ieee154_txframe_t *dataResponseFrame = NULL;
// received a data request frame from a device
// have we got some pending data for it ?
srcAddressMode = (mhr[MHR_INDEX_FC2] & FC2_SRC_MODE_MASK);
if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
return frame; // no source address
src = mhr + MHR_INDEX_ADDRESS;
if (destMode == FC2_DEST_MODE_SHORT)
src += 4;
else if (destMode == FC2_DEST_MODE_EXTENDED)
src += 10;
if (!((mhr[MHR_INDEX_FC1] & FC1_PAN_ID_COMPRESSION) &&
(mhr[MHR_INDEX_FC2] & FC2_DEST_MODE_SHORT)))
src += 2;
for (i=0; iheader->mhr[MHR_INDEX_FC2] &
FC2_DEST_MODE_MASK);
if ((dstAddressMode << 4) != srcAddressMode)
continue;
else {
// we know: dstAddressMode IN [2,3]
uint8_t *dst &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2;
uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
for (j=0; j>if ( dataResponseFrame->header->mhr[ MHR_INDEX_FC1 ] &
FC1_FRAME_PENDING )
>> Leds.led0Toggle();
}
else // got even more than one frame for this device: set
pending flag
dataResponseFrame->header->mhr[MHR_INDEX_FC1] |FC1_FRAME_PENDING;
}
}
}
}
if (dataResponseFrame != NULL) {
// found a matching frame, mark it for transmission
dbg_serial("IndirectTxP", "We have data for this device, trying to
transmit...\n");
dataResponseFrame->client |= SEND_THIS_FRAME;
post tryCoordCapTxTask();
} else {
dbg_serial("IndirectTxP", "We don't have data for this device, sending
an empty frame...\n");
transmitEmptyDataFrame(frame);
}
return frame;
}
And LED 0 is toggled when the second data request is received from the
device, how can this be possible ?
Thank you very much for your help...
Jonathan
-Message d'origine-----
De : jan.ha...@gmail.com [mailto:jan.ha...@gmail.com] De la part de Jan
Hauer
Envoyé : lundi 15 février 2010 17:45
À : Jonathan ROY
Cc : tinyos-help@millennium.berkeley.edu
Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled
mode
The code you posted is from an old version of IndirectTxP.nc, do a CVS
update and take a look at line 232. Anyway, what is still missing is
the device-side. It is on my todo list, but I will definitely not
manage to do this within the next two weeks. Since it is probably not
so complex you might want to take a look whether you can add the
functionality yourself, you would have to edit PollP.nc (there is a
comment in line 202, this is where you'd start). If you succeed, I'd
be happy to integrate your code.
Jan
On Sat, Feb 13, 2010 at 11:12 PM, Jonathan ROY
wrote:
> Thank you for your answer Jan, but when I look to
> tos/lib/mac/tkn154/IndirectTxP.nc it seems that the coordinator doesn't
set
> the Frame Pending
Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled mode
matching frame, mark it for transmission
> txFrame->client |= SEND_THIS_FRAME;
> post tryCoordCapTxTask();
> }
> else
> {
> // TODO: send an empty data frame to the device
> }
> return frame;
> }
>
>
> Is there something else to do ? I really need this functionality to work...
> Thanks,
>
> Jonathan
>
>
> -Message d'origine-
> De : Jan Hauer [mailto:jan.ha...@gmail.com]
> Envoyé : jeudi 11 février 2010 18:16
> À : Jonathan ROY
> Cc : tinyos-help@millennium.berkeley.edu
> Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled
> mode
>
>
>> Content preview: Hi, I would like to do some tests using the 802.15.4
> implementation
>> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple
> indirect
>> transmissions to the same destination" functionality is missing, can
> someone
>> explain me in details what is the problem and its consequences please ?
> [...]
>
>
> Sect. 7.5.6.3 of IEEE 802.15.4-2006:
> "If the Frame Pending subfield of the Frame Control field of the data
> frame received from the coordinator is set to one, the device still
> has more data pending with the coordinator. In this case it may
> extract the data by sending a new data request command to the
> coordinator."
>
> In the current implementation the coordinator sets the Frame Pending
> flag in a DATA frame if it has more DATA frames for the same device,
> but the device will not immediately poll for the DATA frame - instead,
> it will wait for the next beacon and poll afterwards.
>
> Jan
>
>
> On Thu, Feb 11, 2010 at 5:34 PM, Jonathan ROY
> wrote:
>> Spam detection software, running on the system
> "mail.Millennium.Berkeley.EDU", has
>> identified this incoming email as possible spam. The original message
>> has been attached to this so you can view it (if it isn't spam) or label
>> similar future email. If you have any questions, see
>> the administrator of that system for details.
>>
>> Content preview: Hi, I would like to do some tests using the 802.15.4
> implementation
>> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple
> indirect
>> transmissions to the same destination" functionality is missing, can
> someone
>> explain me in details what is the problem and its consequences please ?
> [...]
>>
>>
>> Content analysis details: (4.6 points, 3.3 required)
>>
>> pts rule name description
>> --
> --
>> 1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters
>> 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
>> 0.0 HTML_MESSAGE BODY: HTML included in message
>> 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
>> [score: 0.5000]
>>
>> The original message was not completely plain text, and may be unsafe to
>> open with some email clients; in particular, it may contain a virus,
>> or confirm that your address can receive spam. If you wish to view
>> it, it may be safer to save it to a file and open it with an editor.
>>
>>
>> ___
>> 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
Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled mode
Spam detection software, running on the system "mail.Millennium.Berkeley.EDU",
has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Thank you for your answer Jan, but when I look to
tos/lib/mac/tkn154/IndirectTxP.nc
it seems that the coordinator doesn't set the Frame Pending flag in a DATA
frame if it has more DATA frames for the same device: [...]
Content analysis details: (4.6 points, 3.3 required)
pts rule name description
-- --
1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.5000]
0.0 AWLAWL: From: address is in the auto white-list
--- Begin Message ---
Thank you for your answer Jan, but when I look to
tos/lib/mac/tkn154/IndirectTxP.nc it seems that the coordinator doesn't set
the Frame Pending flag in a DATA frame if it has more DATA frames for the
same device:
event message_t* DataRequestRx.received(message_t* frame)
{
uint8_t i, j, srcAddressMode, dstAddressMode, *src;
uint8_t *mhr = MHR(frame);
uint8_t destMode = (mhr[1] & FC2_DEST_MODE_MASK);
// received a data request frame from a device
// have we got some pending data for it ?
if (!m_numTableEntries)
return frame;
srcAddressMode = (mhr[1] & FC2_SRC_MODE_MASK);
if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
return frame; // no source address
src = mhr + MHR_INDEX_ADDRESS;
if (destMode == FC2_DEST_MODE_SHORT)
src += 4;
else if (destMode == FC2_DEST_MODE_EXTENDED)
src += 10;
if (!((mhr[0] & FC1_PAN_ID_COMPRESSION) && (mhr[1] &
FC2_DEST_MODE_SHORT)))
src += 2;
for (i=0; iheader->mhr[1] &
FC2_DEST_MODE_MASK);
if ((dstAddressMode << 4) != srcAddressMode)
continue;
else {
// we know: dstAddressMode IN [2,3]
uint8_t *dst &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2;
uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
for (j=0; jclient |= SEND_THIS_FRAME;
post tryCoordCapTxTask();
} else {
// TODO: send an empty data frame to the device
}
return frame;
}
I've tried to fix this issue but it doesn't seem to work better:
event message_t* DataRequestRx.received(message_t* frame)
{
uint8_t i, j, srcAddressMode, dstAddressMode, *src;
uint8_t *mhr = MHR(frame);
uint8_t destMode = (mhr[1] & FC2_DEST_MODE_MASK);
ieee154_txframe_t *txFrame = NULL;
// received a data request frame from a device
// have we got some pending data for it ?
if (!m_numTableEntries)
return frame;
srcAddressMode = (mhr[1] & FC2_SRC_MODE_MASK);
if (!(srcAddressMode & FC2_SRC_MODE_SHORT))
return frame; // no source address
src = mhr + MHR_INDEX_ADDRESS;
if (destMode == FC2_DEST_MODE_SHORT)
src += 4;
else if (destMode == FC2_DEST_MODE_EXTENDED)
src += 10;
if (!((mhr[0] & FC1_PAN_ID_COMPRESSION) && (mhr[1] &
FC2_DEST_MODE_SHORT)))
src += 2;
for (i=0; iheader->mhr[1] &
FC2_DEST_MODE_MASK);
if ((dstAddressMode << 4) != srcAddressMode)
continue;
else {
// we know: dstAddressMode IN [2,3]
uint8_t *dst &(m_txFrameTable[i]->header->mhr[MHR_INDEX_ADDRESS]) + 2;
uint8_t len = ((srcAddressMode == FC2_SRC_MODE_SHORT) ? 2 : 8);
for (j=0; jheader->mhr[ 0 ] |= FC1_FRAME_PENDING;
break; // break from outer loop
}
}
}
}
}
call Debug.log(LEVEL_INFO, IndirectTxP_REQUESTED,
NUM_MAX_PENDING-i,i,*src);
if ( txFrame != NULL )
{
// found a matching frame, mark it for transmission
txFrame->client |= SEND_THIS_FRAME;
post tryCoordCapTxTask();
}
else
{
// TODO: send an empty data frame to the device
}
return frame;
}
Is there something else to do ? I really need this functionality to work...
Thanks,
Jonathan
-Message d'origine-
De : Jan Hauer [mailto:jan.ha...@gmail.com]
Envoyé : jeudi 11 février 2010 18:16
À : Jonathan ROY
Cc : tinyos-help@millennium.berkeley.edu
Objet : Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled
mode
> Content preview: Hi, I would like to do some tests using the 802.15.4
implementation
> (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple
indirect
> transmissions to th
Re: [Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled mode
> Content preview: Hi, I would like to do some tests using the 802.15.4 > implementation > (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple > indirect > transmissions to the same destination" functionality is missing, can someone > explain me in details what is the problem and its consequences please ? > [...] Sect. 7.5.6.3 of IEEE 802.15.4-2006: "If the Frame Pending subfield of the Frame Control field of the data frame received from the coordinator is set to one, the device still has more data pending with the coordinator. In this case it may extract the data by sending a new data request command to the coordinator." In the current implementation the coordinator sets the Frame Pending flag in a DATA frame if it has more DATA frames for the same device, but the device will not immediately poll for the DATA frame - instead, it will wait for the next beacon and poll afterwards. Jan On Thu, Feb 11, 2010 at 5:34 PM, Jonathan ROY wrote: > Spam detection software, running on the system > "mail.Millennium.Berkeley.EDU", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > the administrator of that system for details. > > Content preview: Hi, I would like to do some tests using the 802.15.4 > implementation > (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple > indirect > transmissions to the same destination" functionality is missing, can someone > explain me in details what is the problem and its consequences please ? > [...] > > > Content analysis details: (4.6 points, 3.3 required) > > pts rule name description > -- -- > 1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters > 3.2 FH_DATE_PAST_20XX The date is grossly in the future. > 0.0 HTML_MESSAGE BODY: HTML included in message > 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% > [score: 0.5000] > > The original message was not completely plain text, and may be unsafe to > open with some email clients; in particular, it may contain a virus, > or confirm that your address can receive spam. If you wish to view > it, it may be safer to save it to a file and open it with an editor. > > > ___ > 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
[Tinyos-help] 802.15.4: Indirect transmissions in beacon-enabled mode
Spam detection software, running on the system "mail.Millennium.Berkeley.EDU", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, I would like to do some tests using the 802.15.4 implementation (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple indirect transmissions to the same destination" functionality is missing, can someone explain me in details what is the problem and its consequences please ? [...] Content analysis details: (4.6 points, 3.3 required) pts rule name description -- -- 1.4 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 3.2 FH_DATE_PAST_20XX The date is grossly in the future. 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. --- Begin Message --- Hi, I would like to do some tests using the 802.15.4 implementation (TKN15.4) but it's said in tos/lib/mac/tkn154/README.txt that "multiple indirect transmissions to the same destination" functionality is missing, can someone explain me in details what is the problem and its consequences please ? Thank you ! Jonathan --- End Message --- ___ 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 security measures
Hi Raunak, I am not sure about TinySec but as for other security mechanisims, the git tree for TinyOS 2 with CC2420 in-line security features can be found at http://hinrg.cs.jhu.edu/git/?p=jgko/tinyos-2.x.git;a=summary It is currently using a 802.15.4 compatible header format. Let me know if you have any issues in using the tree :) -John Raunak Roongta wrote: > Hi All, > I am working on a project to implement securities measures in the IP > based Wireless Sensor network and it uses 802.15.4 as the data link > layer. There are securities features implemented in 802.15.4 such as > confidentiality, freshness and data integrity. I searched online for > any help, but only found about tinysec, which is there in tinyos 1.0. > We are using Tinyos 2.0. Is there any followup regarding tinysec in > 2.x versions? > > Any help regarding the implementing the security measures of 802.15.4 > in tinyos will be of great help. > > Thanks > > Raunak Rungta > ___ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > -- JeongGil (John) Ko Ph.D. Student Department of Computer Science Johns Hopkins University http://cs.jhu.edu/~jgko ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 security measures
Hi All, I am working on a project to implement securities measures in the IP based Wireless Sensor network and it uses 802.15.4 as the data link layer. There are securities features implemented in 802.15.4 such as confidentiality, freshness and data integrity. I searched online for any help, but only found about tinysec, which is there in tinyos 1.0. We are using Tinyos 2.0. Is there any followup regarding tinysec in 2.x versions? Any help regarding the implementing the security measures of 802.15.4 in tinyos will be of great help. Thanks Raunak Rungta ___ 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 TinyOS Qs
On Sep 5, 2008, at 12:56 PM, Eric Decker wrote: > A suggestion: > > Can someone with write access to the tree add some comments to this > effect to the source code? > > eric > > > On Fri, Sep 5, 2008 at 8:55 AM, David Moss <[EMAIL PROTECTED]> wrote: > Length = length of the header + payload of the packet, minus the > size of the length byte itself (1). This is what allows for > variable length packets. > Well, this is the 802.15.4 specification, so... Phil ___ 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 TinyOS Qs
A suggestion:
Can someone with write access to the tree add some comments to this effect
to the source code?
eric
On Fri, Sep 5, 2008 at 8:55 AM, David Moss <[EMAIL PROTECTED]> wrote:
> Length = length of the header + payload of the packet, minus the size of
> the length byte itself (1). This is what allows for variable length
> packets.
>
>
>
> DSN = Data Sequence Number, a number incremented for each packet sent by a
> particular node. This is used in acknowledging that packet, and also
> filtering out duplicate packets.
>
>
>
> Type = TinyOS AM type. When you create a new AMSenderC(AM_WHATEVER), the
> AM_WHATEVER definition is the type of packet.
>
>
>
> TOSH_DATA_LENGTH defaults to 28, it represents the maximum size of the
> payload portion of the packet, and is specified in the tos/types/message.h
> file.
>
>
>
> All of these fields will be filled in automatically by the radio stack when
> you attempt to send a message.
>
>
>
> -David
>
>
>
>
>
>
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Jim Fell
> *Sent:* Friday, September 05, 2008 8:45 AM
> *To:* tinyos-help@millennium.berkeley.edu
> *Cc:* Jim Fell
> *Subject:* [Tinyos-help] 802.15.4 TinyOS Qs
>
>
>
> Hello. On lines 45 through 59 of …/tinyos-2.x/tos/chips/cc2420/CC2420.h
> the CC2420 header is specified:
>
>
>
> typedef nx_struct cc2420_header_t {
>
> nxle_uint8_t length;
>
> nxle_uint16_t fcf; // Frame Control (Field)
>
> nxle_uint8_t dsn;
>
> nxle_uint16_t destpan; // Destination PAN ID
>
> nxle_uint16_t dest; // Destination address
>
> nxle_uint16_t src; // Source address
>
>
>
> /** I-Frame 6LowPAN interoperability byte */
>
> #ifdef CC2420_IFRAME_TYPE
>
> nxle_uint8_t network; // I-frame (interoperability frame) byte
>
> #endif
>
>
>
> nxle_uint8_t type; // Packet type
>
> } cc2420_header_t;
>
>
>
> Can someone please clarify for me what the length and dsn fields are? Is
> dsn Device Sequence Number? How is length used?
>
>
>
> Can the type field be anything? For example, if I wanted to add additional
> RF commands to the stack, could I make my own definitions using this type
> field to specify each, or is it a static field?
>
>
>
> Where is the maximum payload size specified? Is it TOSH_DATA_LENGTH (line
> 96 of CC2420.h)?
>
>
>
> Thanks,
>
>
>
> -Jim
>
>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
___
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 TinyOS Qs
Length = length of the header + payload of the packet, minus the size of the
length byte itself (1). This is what allows for variable length packets.
DSN = Data Sequence Number, a number incremented for each packet sent by a
particular node. This is used in acknowledging that packet, and also
filtering out duplicate packets.
Type = TinyOS AM type. When you create a new AMSenderC(AM_WHATEVER), the
AM_WHATEVER definition is the type of packet.
TOSH_DATA_LENGTH defaults to 28, it represents the maximum size of the
payload portion of the packet, and is specified in the tos/types/message.h
file.
All of these fields will be filled in automatically by the radio stack when
you attempt to send a message.
-David
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Fell
Sent: Friday, September 05, 2008 8:45 AM
To: tinyos-help@millennium.berkeley.edu
Cc: Jim Fell
Subject: [Tinyos-help] 802.15.4 TinyOS Qs
Hello. On lines 45 through 59 of ./tinyos-2.x/tos/chips/cc2420/CC2420.h the
CC2420 header is specified:
typedef nx_struct cc2420_header_t {
nxle_uint8_t length;
nxle_uint16_t fcf; // Frame Control (Field)
nxle_uint8_t dsn;
nxle_uint16_t destpan; // Destination PAN ID
nxle_uint16_t dest; // Destination address
nxle_uint16_t src; // Source address
/** I-Frame 6LowPAN interoperability byte */
#ifdef CC2420_IFRAME_TYPE
nxle_uint8_t network; // I-frame (interoperability frame) byte
#endif
nxle_uint8_t type; // Packet type
} cc2420_header_t;
Can someone please clarify for me what the length and dsn fields are? Is
dsn Device Sequence Number? How is length used?
Can the type field be anything? For example, if I wanted to add additional
RF commands to the stack, could I make my own definitions using this type
field to specify each, or is it a static field?
Where is the maximum payload size specified? Is it TOSH_DATA_LENGTH (line
96 of CC2420.h)?
Thanks,
-Jim
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 TinyOS Qs
Hello. On lines 45 through 59 of
.../tinyos-2.x/tos/chips/cc2420/CC2420.h the CC2420 header is specified:
typedef nx_struct cc2420_header_t {
nxle_uint8_t length;
nxle_uint16_t fcf; // Frame Control (Field)
nxle_uint8_t dsn;
nxle_uint16_t destpan; // Destination PAN ID
nxle_uint16_t dest; // Destination address
nxle_uint16_t src; // Source address
/** I-Frame 6LowPAN interoperability byte */
#ifdef CC2420_IFRAME_TYPE
nxle_uint8_t network; // I-frame (interoperability frame) byte
#endif
nxle_uint8_t type; // Packet type
} cc2420_header_t;
Can someone please clarify for me what the length and dsn fields are?
Is dsn Device Sequence Number? How is length used?
Can the type field be anything? For example, if I wanted to add
additional RF commands to the stack, could I make my own definitions
using this type field to specify each, or is it a static field?
Where is the maximum payload size specified? Is it TOSH_DATA_LENGTH
(line 96 of CC2420.h)?
Thanks,
-Jim
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 stack feedback
Hi all, Is there anyone that have work with a 802.15.4 stack over tinyos 1.x or 2.x like Meshnetics OpenMAC or Tiny15Four? I'm just curious to hear from your experience good or bad. Do you know other project that I should check also? Thanks in advance, .:Fred ___ 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
take a look at this thread: http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg19751.html Jan On Tue, Apr 15, 2008 at 12:50 AM, Funofnet funofnet <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > Please, are there any implementation of slotted-csma corresponding to this > norm 802.15.4 > > > > Thank you, > > Fun > ___ > 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
[Tinyos-help] 802.15.4
Hi, Please, are there any implementation of slotted-csma corresponding to this norm 802.15.4 Thank you, Fun ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4
Greetings, Within the projects has been used the TinyOS, programming in NesC and simulating in TOSSIM, and in the moment we has manipulated the libraries of the CC2420 but we have the interest to manipulate the level MAC of protocol 802.15.4. This is reason by which, we asked for documentation or examples of the use of the level MAC programming the TinyOS. ATT CARLOS GIRALDO___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 Question
Just wanted to post this question to the academic minded people. 802.15.4 is using DSSS, with a code that is fixed for a particular network that you want to deploy. This makes sense if you are in the industry since it will allow non-interfering sensor networks in your home from different vendors. But other than that, and the obviously higher data rate, what are the benefits of shifting towards a packet oriented (less hacking possible!), DSSS system? Also is it really many orders of magnitude better than CC1000 in terms of multipath resistance and reliability (as it should theoretically)? i.e. has this been borne out in real experiments? Thank you. Regards, Affan Syed. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 MAC Beacon mode
Martin Gercke wrote: If a coordinator is sending out beacon frames and children (FFD, possible routers) associate to him, how and when are they sending THEIR beacons for THEIR children. There can be even more "layers" so that the children are parents for their own children and these children are again partents ... and so on until the restrictions of the PAN are reached (max. depth) Yeah, we were confused by that question too. It looks like there's no explicit answer in the 802.15.4 specification. We found some additional information in the ZigBee specification (pages 245-247: Scheduling beacon transmissions). We figured out that a routing device deals with two superframes. The first is the parent's one, and the second is its own one. So there can be several superframes around a device (its two + neighbors'), but they should not overlap. If the children send their beacons at the same time as their parents there will be interference. So either they - send their beacon in the CAP of their parent (small amont of time and if this is done for their children as well the beacon periode will shrink every time) - send their beacon in the time after CFP and the start of the next beacon (again, the beacon period will decrease ...) There is a possibility to place several superframes in one beacon interval if the latter is long enough. Superframe duration and the beacon interval are controlled by MacSuperframeOrder and MacBeaconOrder attributes. Am I missing something or is beacon mode only working for 1 parent and the associated children? Martin Timofei. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 MAC Beacon mode
Hi Timofei, I just read about this in the specification :-) If you are working on the beacon mode, maybe you can clarify something for me what I never understood about the whole system: If a coordinator is sending out beacon frames and children (FFD, possible routers) associate to him, how and when are they sending THEIR beacons for THEIR children. There can be even more "layers" so that the children are parents for their own children and these children are again partents ... and so on until the restrictions of the PAN are reached (max. depth) If the children send their beacons at the same time as their parents there will be interference. So either they - send their beacon in the CAP of their parent (small amont of time and if this is done for their children as well the beacon periode will shrink every time) - send their beacon in the time after CFP and the start of the next beacon (again, the beacon period will decrease ...) Am I missing something or is beacon mode only working for 1 parent and the associated children? Martin Timofei Istomin wrote: Hi! Martin Gercke wrote: Else my NWK Layer will never know who's around. It can use the Active scan mode, i.e. broadcast the beacon request command before channel listening. All coordinators from the neighborhood should reply with a single beacon. To my mind the most serious problem with the beaconless mode is the need of being always online, or care about synchronization somewhere above NWK. We are trying to implement the beacon mode, but it's quite difficult. There are very strict time requirements. Timofei. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 MAC Beacon mode
Hi! Martin Gercke wrote: Else my NWK Layer will never know who's around. It can use the Active scan mode, i.e. broadcast the beacon request command before channel listening. All coordinators from the neighborhood should reply with a single beacon. To my mind the most serious problem with the beaconless mode is the need of being always online, or care about synchronization somewhere above NWK. We are trying to implement the beacon mode, but it's quite difficult. There are very strict time requirements. Timofei. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 MAC Beacon mode
Hi Riccardo, I _am_ working on a 802.15.4 MAC Layer implementation, yes. :-) I've just done the Polling and Association/Disassociation so far. But I decided not to use beacon mode. Although since a few days I am not sure anymore. The MAC Layer should be used with an implementation of the Zigbee NWK Layer. And I'm not sure if there is any other way to let this work than to implement beacon mode. Else my NWK Layer will never know who's around. What do you think? Martin Riccardo Sala wrote: Is someone (Gercke?) working on the 802.15.4 MAC layer? In particular I'm interested in beacon mode. What was done? Can I help? Thanks. Regards Riccardo S. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 MAC Beacon mode
Hi, Is someone (Gercke?) working on the 802.15.4 MAC layer? In particular I'm interested in beacon mode. What was done? Can I help? Thanks. Regards Riccardo S. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 ACKs
Hi Martin, I am not really an expert in 802.15.4 but I have thought about your question. I suppose you are assuming a mesh topology, where nodes are allowed to transmit and receive information between them, not only with the PAN coordinator. In this kind of peer-to-peer topologies, the standard does not specifies anything about ACK's, as it says un section 5.4.2.3. >From my point of view, there would be no problem in confusing the ACK's. In P2P topoplogy, without using a synchronization mechanism, nodes should "listen" constantly to the channel, and send frames using unslotted CSMA-CA. These means that if A is sending a message to B, and C wants to transmit at the same time, C would perform a channel sensing. When it detects the ongoing transmission (A<-->B) it should backoff and try again later on. The backoff perdid should be long enough to allow A and B to finish their communication (including ACK's and other messages). Then, if C uses the same DSN, there would no problem of confused ACK's, because A and B would have ended their transmissions. An ACK frame is only "correct" in the context of the communication established between two nodes. However, this can be a problem when using differents PAN's. In this case a node could confuse ACK frames, but I think this is covered also in the standard. A - B | | | | C --- D PAN1 = A and B PAN2 = B and C PAN3 = C and D In this case there could be some problems. Let's suppose B sends a message to A and waits for the ACK, and at the same time D sends a message to C and also waits for ACK. This can happen because when D performs channel sensing, it does not "hear" the transmission from B. If the ACK form A is lost, B could still receive an ACK from C, (destined to D) because it is in his coverage area. If DSN field is the same, a confusion can happen. I am not an expert of 802.15.4 and I think this aspect is taken on account on the standard, but now I can not remember exactly. Maybe I am not right, so any remarks, comments or further explanations would be welcomed. I hope this can help you. Regards, Arnau Quintana On 12/15/05, Martin Gercke <[EMAIL PROTECTED]> wrote: Hi,I have a small question about acknowledgments in 802.15.4.According to the standard they don't hold any address information.Neither source nor destination.So, in a PAN with many devices all in radio reach of each other it could happen that 2 messages are send with the same DSN from 2 different motes(e.g. A->B and C->D),messages from A-B gets acknowledged but message from C->D is lost. Sinceboth messages have the same DSN C could confuse ACK send from B->A with the one he's waiting for, right?Martin___Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 ACKs
Hi, I have a small question about acknowledgments in 802.15.4. According to the standard they don't hold any address information. Neither source nor destination. So, in a PAN with many devices all in radio reach of each other it could happen that 2 messages are send with the same DSN from 2 different motes (e.g. A->B and C->D), messages from A-B gets acknowledged but message from C->D is lost. Since both messages have the same DSN C could confuse ACK send from B->A with the one he's waiting for, right? Martin ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 and ZigBee support
http://www.tinyos.net/faq.html#SEC-78 On 11/10/05, saradellaluna <[EMAIL PROTECTED]> wrote: > Hi All, > We are interested in buying MOTEIV TMOTE SKY motes and I read that they > support TinyOS. > Does TinyOS implement 802.15.4 MAC procedures and/or ZigBee routing > mechanisms? And what about TOSSIM? > > Thanks in advance. > Bye Sara. > > > ___ > Tinyos-help mailing list > Tinyos-help@Millennium.Berkeley.EDU > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 and ZigBee support
Hi All, We are interested in buying MOTEIV TMOTE SKY motes and I read that they support TinyOS. Does TinyOS implement 802.15.4 MAC procedures and/or ZigBee routing mechanisms? And what about TOSSIM? Thanks in advance. Bye Sara. ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 ACK
According to my understanding, it has been implemented in CC2420 hardware, even though you could disable it and write the ACK mechanism in your own module (or existing MAC code). Hongwei Martin Gercke wrote: Hi, small question about Acknoledgments. >From the IEEE 802.15.4 specification I understand the use and framing of ACKs but I wonder what layer should be responsible for this? MAC? Or is this up to the implementation and should just be _above_ MAC? Martin P.S.: concerning such protocol related questions concerning zigbee or 802.15.4 is there any better place to ask such questions? ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] 802.15.4 ACK
Hi, small question about Acknoledgments. From the IEEE 802.15.4 specification I understand the use and framing of ACKs but I wonder what layer should be responsible for this? MAC? Or is this up to the implementation and should just be _above_ MAC? Martin P.S.: concerning such protocol related questions concerning zigbee or 802.15.4 is there any better place to ask such questions? ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 in TinyOS
Joe, Thanks for the reply. The newest Microchip code (released 9/9/2005) seems changed a lot. It supports Zigbee/802.15.4 for two to three RF chips now. I will read those tinyos docs. JinJiu On 10/25/05, Joe Polastre <[EMAIL PROTECTED]> wrote: > On 10/25/05, Jin Jiu <[EMAIL PROTECTED]> wrote: > > Microchip seems to be the only one providing a free NWK/MAC solution, > > I'm thinking about switching from tinyos/msp430 to microchip now. > > Microchip's code does not have an OS though, i'm still investigating > > that. > > Microchip's code is not 802.15.4 compatible NOR zigbee compatible. > The first page in the document about their zigbee stack says: > > LIMITATIONS > Version 1.0 of the Microchip Stack contains the > following limitations. Please note that MIcrochip is > planning to add new features as time progresses. Refer > to the source code version log file (version.log) for > current limitations. > • Not ZigBee protocol-compliant > • No cluster and peer-to-peer network support > • No security and access control capabilities > • No router functionality > • Does not provide standard profiles; however, it > contains all necessary primitive functions to > create profiles > • Does not support one-to-many bindings > > > if tinyos/zigbee is a do-able project, i can do the MAC portion > > though. i feel tinyos is really not 802.15.4 friendly at this point > > considering the existing AM/TOS_Msg frame is used in the source > > dominantly, also, as you know, the network layer is totally different > > from NWK. > > TinyOS is an operating system. 802.15.4/zigbee are protocols. The > two are orthogonal. Since Luxoft implemented 802.15.4 and zigbee in > TinyOS, obviously it is possible! There is another group in Europe > that has done a TinyOS implementation too. Furthermore, the messages > sent out by the CC2420 radio stack in TinyOS are *valid* 802.15.4 > packets with correct framing, frame control fields, acknowledgment > request and response, etc. You only need to implement the MAC > protocol logic above those packets. > > TinyOS is a composible operating system. TOS_Msg is simply a > container for a packet; the structure of the packet may be defined by > YOU or 802.15.4 or the MAC protocol. Since TinyOS is composible, you > can replace one network layer with a new network layer of your choice, > and this is very easy. I highly recommend reading the following > document, as well as any of the other documents on this page. It may > enlighten you as to the structure and implementation of TinyOS. > > http://www.tinyos.net/papers/tinyos-nsdi04.pdf > > http://www.tinyos.net/media.html > > -Joe > ___ Tinyos-help mailing list [EMAIL PROTECTED] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 in TinyOS
On 10/25/05, Jin Jiu <[EMAIL PROTECTED]> wrote: > Microchip seems to be the only one providing a free NWK/MAC solution, > I'm thinking about switching from tinyos/msp430 to microchip now. > Microchip's code does not have an OS though, i'm still investigating > that. Microchip's code is not 802.15.4 compatible NOR zigbee compatible. The first page in the document about their zigbee stack says: LIMITATIONS Version 1.0 of the Microchip Stack contains the following limitations. Please note that MIcrochip is planning to add new features as time progresses. Refer to the source code version log file (version.log) for current limitations. • Not ZigBee protocol-compliant • No cluster and peer-to-peer network support • No security and access control capabilities • No router functionality • Does not provide standard profiles; however, it contains all necessary primitive functions to create profiles • Does not support one-to-many bindings > if tinyos/zigbee is a do-able project, i can do the MAC portion > though. i feel tinyos is really not 802.15.4 friendly at this point > considering the existing AM/TOS_Msg frame is used in the source > dominantly, also, as you know, the network layer is totally different > from NWK. TinyOS is an operating system. 802.15.4/zigbee are protocols. The two are orthogonal. Since Luxoft implemented 802.15.4 and zigbee in TinyOS, obviously it is possible! There is another group in Europe that has done a TinyOS implementation too. Furthermore, the messages sent out by the CC2420 radio stack in TinyOS are *valid* 802.15.4 packets with correct framing, frame control fields, acknowledgment request and response, etc. You only need to implement the MAC protocol logic above those packets. TinyOS is a composible operating system. TOS_Msg is simply a container for a packet; the structure of the packet may be defined by YOU or 802.15.4 or the MAC protocol. Since TinyOS is composible, you can replace one network layer with a new network layer of your choice, and this is very easy. I highly recommend reading the following document, as well as any of the other documents on this page. It may enlighten you as to the structure and implementation of TinyOS. http://www.tinyos.net/papers/tinyos-nsdi04.pdf http://www.tinyos.net/media.html -Joe ___ Tinyos-help mailing list [EMAIL PROTECTED] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] 802.15.4 in TinyOS
Luoxft claimed they have 802.15.4MAC and Zigbee on top of tinyos, those code are not in tinyos and just like you, I could not even get a binary from them. i don't believe they will open-source it. Microchip seems to be the only one providing a free NWK/MAC solution, I'm thinking about switching from tinyos/msp430 to microchip now. Microchip's code does not have an OS though, i'm still investigating that. if tinyos/zigbee is a do-able project, i can do the MAC portion though. i feel tinyos is really not 802.15.4 friendly at this point considering the existing AM/TOS_Msg frame is used in the source dominantly, also, as you know, the network layer is totally different from NWK. JinJiu On 10/25/05, Martin Gercke <[EMAIL PROTECTED]> wrote: > Hi, > > I only found the header/interface description in /beta/lib/802.15.4 > You could build your own MAC layer from here. > I think I am going to do this and build the networking layer on top. > For my routing mechanisms I don't need things like ED (energy detection) > and CCA (clear channel assessment) > For a basic implementation I will need ACK frames and will have to build > address assignment and routing mechanisms on top. > Since nobody seems to have implemented the BEACON mode (right?) I will > not use this in my implementation. > So if you are thinking about using TinyOS further on and would like to > split work on the MAC/NWK layer ... > > >> zigbee/802.15.4 over tinyos(no interest in luxoft's closed code) > > How is Luxoft's code closed? I didn't look into it but there seems to be > some code in contrib/luxoft and I don't see how they could have "closed" it. > Is see no binarys there. > Did you also try to get a running zigbee implementation from luxoft? > Because I tried to get ANY implementation and didn't hear a word. > So if you have any running zigbee implementation I could at least test > my implementation and see if a zigbee compliant version works with my motes. > > Martin > > ___ Tinyos-help mailing list [EMAIL PROTECTED] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
