TX/RX switching time of MMAC

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

TX/RX switching time of MMAC

Jump to solution
4,746 Views
Johnny9
Contributor II

Hi

I am developing with JN5189 and Micro MAC library.

I have one problem.
When I try to send and receive packets using the MMAC functions(vMMAC_StartPhyTransmit() and vMMAC_StartPhyReceive()), TX/RX switching time is more than 3.5(ms). This causes the problem that the ACK packet cannot be received.
TX/RX switching time of about 3.5(ms) is the maximum performance of Micro MAC? Can I shorten this time to less than 1.5 ms?

0 Kudos
Reply
1 Solution
4,690 Views
EduardoZamora
NXP TechSupport
NXP TechSupport

Hi,

I apologize for any inconvenience this might cause you, these time constraints are due to the MicroMAC Library implementation.

Regards,
Eduardo.

View solution in original post

0 Kudos
Reply
5 Replies
4,733 Views
EduardoZamora
NXP TechSupport
NXP TechSupport

Hello @Johnny9,

Hope you are doing well.

Could you please confirm that you are following the ZigBee Green Power (for ZigBee 3.0) User Guide [JN-UG-3134]? This guide can be found inside the JN5189 SDK folder > docs > wireless > Zigbee. Please, take a look at Chapter 3: MicroMAC Stack for Green Power.

Also, please consider that one of the disadvantages of PHY mode is that automatic acknowledgement is not available. In order to enable this option, it is preferable to use MAC mode instead. MAC and PHY Transceiver Modes are described in Chapter 3.6.

Regards,
Eduardo.

0 Kudos
Reply
4,722 Views
Johnny9
Contributor II

Hello @EduardoZamora,

 

I didn't find the answer I was looking for in the User Guide [JN-UG-3134].

(Also, I'm well aware that autoack is not supported in PHY mode.)

 

The problem is that after sending a packet I cannot receive another packet for 3.5ms.

Any ideas on how to receive an incoming ACK packet immediately after sending a packet?

Or is there no way due to the limitations of the MMAC library?

 

The example I referenced is JN-AN-1261, and I tested it like this:

APP_RADIO_vTx(FALSE);
if (APP_RADIO_bRx(TRUE, 40))
{
        /* Process Received frame */
}
else
{
        PRINT("No Packet\n");
}

Thank you.

0 Kudos
Reply
4,691 Views
EduardoZamora
NXP TechSupport
NXP TechSupport

Hi,

I apologize for any inconvenience this might cause you, these time constraints are due to the MicroMAC Library implementation.

Regards,
Eduardo.

0 Kudos
Reply
4,633 Views
Johnny9
Contributor II
If so, isn't the MicroMAC library backwards compatible with IEEE802.15.4 MAC?
That is the time exceeding IEEE802.15.4's macAckWaitDuration(0.864ms).
0 Kudos
Reply
4,664 Views
Johnny9
Contributor II

Hi,

 

What I was wondering about has been solved.

(Maybe I'll have to find another way.)

Thanks for your reply.

 

Regards,

Johnny9

0 Kudos
Reply