MC13234, 802.15.4 RF Performance Drops Unexpectedly

[matt_iwamura20]

I've been working with the MC13234 MCU + wireless transceiver, and have encountered seemingly random drops in radio connectivity. I've been running experiments with roughly 100 boards running simultaneously, reporting in roughly once every 10 seconds. Over the course of a night I will fail to see a few of these boards report in for 30+ minutes, until they inexplicably start reporting again. After running several permutations of this experiment, I no longer suspect this is a software bug for the following reasons: 

1. If I have another wireless receiver running, not involved in acknowledgements but simply acting as a "sniffer", I will often see the "failed" boards' reports on the "sniffer" but not on the output from the main receiver.

2. In the time where a board may be failing to get its reports in, the other hundred or so boards report in fine, so it does not appear to be a software bug that keeps all reports from coming in, and also not a result of external interference, which I would expect to affect all boards equally.

3. In one experiment, the boards were programmed to power cycle in the event a board failed to get any report in for 5 minutes. Upon power cycling, the board would fail to reconnect to the receiver for possibly 10s of minutes up to a couple hours, though the requests to join may be seen by the "sniffer" in that timeframe.

4. The dropouts in reporting are sometimes correlated with a drastic drop in LQI immediately preceding or following a "no signal" event.

It's my suspicion that something is happening internal to the RF transceiver of the MC13234 that is causing the radio to go temporarily "out-of-whack". Perhaps the output power is dropping, or the frequency is shifting slightly, such that the main receiver is no longer hearing reports, but the "sniffer" still can.

I'm wondering if this is potentially an issue with the part known internally to Freescale/NXP, and if there is a potential workaround. I know there are several indirectly addressed registers that manage some of the radio specifics (e.g. shifts in frequency, configuring output power), but I haven't been able to find any official documentation about them, only references in the comments of Freescale-provided code used to configure the radio.

Any help or insight into what could be going on would be greatly appreciated.

Thanks,

Matt

[estephania_mart]

Hello, 

Which stack are you using? Also, please consider that this product is not recommended for new designs.

Please visit Wireless Connectivity Microcontrollers (MCUs) for information on the latest products. 

Sorry for the inconvenience this might cause you. 

Regards, 

Estephania

[matt_iwamura20]

Hi Estephania,

Just to add to this, I believe the Freescale code for our radio drivers were generated from BeeKit examples, likely from around 2012. Is there any documentation available that might shed some light on the functionality of those Indirect Access Registers that are being manipulated in the radio drivers that Freescale BeeKit produces? I haven't been able to find any documentation on them

Thanks,

Matt

[matt_iwamura20]

Hi Estephania,

It is a proprietary stack, though I believe the basic radio functions were provided by a freescale codebase at some point. Looking at the comments in our basic radio functions, they definitely appear to be from Freescale and modify registers that we don't have documentation for as far as I know. An example excerpt:

IoIndirectWrite(0x18, 0x48); //"cg_md_bw=1, cg_ct_force=8 (Project Sync 8875)"
IoIndirectWrite(0x06, 0x06); //"lo1_vco_buff_en=1, lo1_vco_buff_boost=1"
IoIndirectWrite(0x14, 0x75); //"ampmixer_iref=7,ampmixer_lobuf1_ibias=1, ampmixer_lobuf1_vbias=1"
IoIndirectWrite(0x1A, 0x49); //mixpad_sel=9
IoIndirectWrite(0x3D, 0x07); //Increase RxACK Turnaround Time by 14 nS (Project Sync 8949)
IoIndirectWrite(0x1D, 0x40); //mic_early (enable VREGM simul with VREGA)
IoIndirectWrite(0x0F, 0x15); // VREGM trim

IoIndirectWrite(0x61, 0x01); // set vrega_en_ovrd_en
IoIndirectWrite(0x60, 0x01); // set vrega_en_ovrd

And in another spot:

PP_PHY_LO1INT = (uint8_t)(temp >> 8) + 74; // 2400/32-1 = 74
PP_PHY_LO1FRACH = (uint8_t)(temp & 0xFF);
PP_PHY_LO1FRACL = 1; // add 1 (channel will have 500Hz offset) to avoid spurs

It's some of these comments that make me think there are parameters of the radio that can be configured that we don't really have a good handle/documentation on that could affect radio performance in unexpected ways...

Thanks,

Matt