802.15.4 Direct Data Transmission

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

802.15.4 Direct Data Transmission

Jump to solution
1,410 Views
erwinbeck
Contributor II

I have created a New Project in BeeKit, using HCS08 MAC Codebase 2.6.1,

and MyWirelessApp Demo Non Beacon template.

In this template, coordinator sends indirect data to device:

mpPacket->msgData.dataReq.txOptions = gTxOptsAck_c | gTxOptsIndirect_c; 

and device polls coordinator for data:

mTimer_c = TMR_AllocateTimer();

TMR_StartSingleShotTimer(mTimer_c, mPollInterval, AppPollWaitTimeout);

/* Send the Poll Request to the MLME. */

if(MSG_Send(NWK_MLME, pMlmeMsg) == gSuccess_c)

Indirect Data transmission works just fine.

Since in my case the device is AC powered and can therefore always listen, if properly programmed, I have modified my project to allow Direct Data transmission,

by commenting out the indirect option gTxOptsIndirect_c in the coordinator,

and by commenting out the above three instructions in the device.

Obviously I am still missing something, Direct Data transmission doesn't work yet. But maybe HCS08 MAC Codebase 2.6.1 doesn't allow Direct Data transmission in Non Beacon mode.

Thank you for your advice

Labels (1)
1 Solution
980 Views
jc_pacheco
NXP Employee
NXP Employee

Hello Erwin, 

With that modification on the coordinator, you should be able to send direct data but it's likely your End Device is not receiving it, you can verify that with an sniffer.

If that's the case, you still need to tell the End Device to keep the Radio On when the device is in Idle state. That's done modifying the pib attribute "RxOnWhenIdle".

You could do it during initialization (ie. after MApp_init(); is called).

void SetReceiverOn(void)
{
 mlmeMessage_t msg; 
 bool_t value = TRUE;
 
 msg.msgType = gMlmeSetReq_c;
 msg.msgData.setReq.pibAttribute = gMPibRxOnWhenIdle_c;
 msg.msgData.setReq.pibAttributeValue = &value;
 (void)MSG_Send(NWK_MLME, &msg);
}‍‍‍‍‍‍‍‍‍

As a good practice, you should indicate this capability to the Coordinator when joining the network at "App_SendAssociateRequest(void)"

/* We want the coordinator to assign a short address to us. */
 pAssocReq->capabilityInfo = gCapInfoAllocAddr_c | gCapInfoPowerMains_c | gCapInfoRxWhenIdle_c;
‍‍

Hope this helps.

-JC

View solution in original post

3 Replies
981 Views
jc_pacheco
NXP Employee
NXP Employee

Hello Erwin, 

With that modification on the coordinator, you should be able to send direct data but it's likely your End Device is not receiving it, you can verify that with an sniffer.

If that's the case, you still need to tell the End Device to keep the Radio On when the device is in Idle state. That's done modifying the pib attribute "RxOnWhenIdle".

You could do it during initialization (ie. after MApp_init(); is called).

void SetReceiverOn(void)
{
 mlmeMessage_t msg; 
 bool_t value = TRUE;
 
 msg.msgType = gMlmeSetReq_c;
 msg.msgData.setReq.pibAttribute = gMPibRxOnWhenIdle_c;
 msg.msgData.setReq.pibAttributeValue = &value;
 (void)MSG_Send(NWK_MLME, &msg);
}‍‍‍‍‍‍‍‍‍

As a good practice, you should indicate this capability to the Coordinator when joining the network at "App_SendAssociateRequest(void)"

/* We want the coordinator to assign a short address to us. */
 pAssocReq->capabilityInfo = gCapInfoAllocAddr_c | gCapInfoPowerMains_c | gCapInfoRxWhenIdle_c;
‍‍

Hope this helps.

-JC

980 Views
erwinbeck
Contributor II

Hello Juan Carlos

Thank you for your quick response. And you were absolutely right, the End Device hadn't the Radio On. In the MyWiressApp Non Beacon demo, the default for the PIB attribute "RxOnWhenIdle" is FALSE, both for Coordinator and End Device.

I verified this in MApp_init.c for Coordinator and End Device, by sending GetReq messages to the MLME port.

Then out of curiosity I started sending out GetReg messages at strategic locations in my program

What I observed was pretty interesting. First of all I was surprised that the Coordinator starts out with Radio Off. What surprised me even more, how long the Coordinator stays in that condition as it steps through its state machine. At the beginning of the StartCoordinator state the Radio is still Off, and then all of sudden, at the beginning of the next state, the StartCoordinatorWaitConfirm state, the Radio is On, without any intervention on my part with a SetReq message! There seems to be quite a bit going on under the hood of the MAC/PHY layer, invisible to the C programmer.

After that experimentation, an with your piece of code, it was a piece of cake to resolve my problem, everything works now.

Thank you for your help

Erwin

980 Views
jc_pacheco
NXP Employee
NXP Employee

Glad to help!