CC1121: Loosing communication for few minutes

Hi,

Frequency offset was my first guess and I did already check with 200kHz RX filter BW. Did not help, but at the time IQIC was 0x46 and AGC_REF was 0x20. Do you think the presence of image compensation made my test irrelevant and I should perform it again?

Unfortunately I am not able to measure the frequency offset of the problematic systems, because they are all over the world and so far I haven't been able to reproduce this in the office.

We use 10ppm crystal and according to my caluclation the RX filter bandwidth should be at least 118kHz at 915MHz. Is this correct?

What baffles me is that the device go "dark" for 5-10 consecutive packets and then back to normal for some time (30-90 minutes in most cases). Do you think frequency offset could explain this?

The devices are calibrated with a SCAL strobe once after reset. For the rest of the time FS_AUTOCAL is set to 1 (When going from IDLE to RX or TX (or FSTXON)).

Thank you,

Borislav

For me, offset does not explain what you are observing. 

Are you sure this is not due to interference/ a blocker occurring at given times? Since it happens more on some parts of the day than others it could be other radio traffic that block your node. 

Our systems usually comprise of at least 5 end units, and when one of the devices goes offline, the rest are ok.

Without knowledge of the network or the software running it's difficult for us to advice exactly what could be causing what you see.

Is it given that all 5 end nodes see the same interference/ blocker? Is it random which end node that goes offline or is it random?  

Hi,

No, when one device is offline, the rest are ok. It is not random, the problem is always with the same device or devices within a system. 

The system works as follows:

Every end unit sends a 15byte payload packet once every 60 seconds. The hub replies to each of the received packets. The network topology is a star. The hub is always in RX. Upon a received packet, the hub makes a context switch to the thread that handles radio communication. I've ruled out missed interrupts, because the radio is configured to go to IDLE after good packet is recieved and RX would not be restarted if the interrupt is missed.

This is a typical example of the problem:

In a system with 9 end units, one is problematic and frequently goes offline. No other devices in the system go offline. The average RSSI of the problematic device is -93 (max is -88, min is -99). Below is a 24 hour export:

Is it possible to move the problematic node to a different location for debug purposes? Alternative/ in addition swap the problematic node with a different one to see if it's the location or the physical node that causes an issue. 

Unfortunately I can't play with these systems. They are in cutomer properties.

We did this awhile ago during a beta test and if I recall correctly after the swap, both device were ok. After swapping them a second time, the problematic device behaved the same as before the first swap.

Just to rule out frequency drift - is enabling FS_AUTOCAL enough, or should an SCAL strobe be issued from time to time? Also is 100kHz ok for 10ppm crystal, or should I increase it to 118kHz?

Thank you,

Borislav

If your recollection of the swap is correct, it sounds like the two nodes are not equal. Could the problematic node have poorer sensitivity for some reason?

The minimum RX BW is given as: RX BW = Signal Bandwidth + 4*ppm Crystal * RF Frequency of Operation.

SCAL vs AUTOCAL: It depends. For the collector, do you run calibration just once, when it enter RX or do you recalibrate from time to time? In theory it should not be required with a recalibration if supply and temp is constant but to ensure a reliable link recalibration every x time unit should be done. The x difficult to be sure about, depends on the system. 

Are you able to debug on the installed system at all or change some of the sensors and take them back to the lab? I don't see how frequency offset could explain what you are seeing but to be on the safe side it could be interesting to measure the center frequency for this node. 

All our devices that leave the factory go through an automatic radio test during production. The test is sending of 100 packets and receiving 100 responses against a device fixed inside the testing jig. PER and Min/max/mean RSSI data is collected for both the sent and received packets and compared against predefined limits. I will review the test results for few of the problematic devices and compare against average.

So RX BW = 38400 + 2*21500 + 4*10*915 = 118000, correct?

On the collector, SCAL is issued only once after reset. For the rest of the time I rely on AUTOCAL, which is set to be when going from IDLE to RX or TX. Since devices communicate every 60 seconds, the recalibration should be often enough I think. Is there a difference between SCAL and AUTOCAL?

I will have to find a problematic device in one of our beta sites.

The difference between SCAL and AUTOCAL is just when the calibration is done. (manual vs automatically) Every 60 seconds should be sufficient. Does that mean that the collector is calibrated every 60 seconds too? 

So RX BW = 38400 + 2*21500 + 4*10*915 = 118000, correct?: Yes, but if you use GFSK the signal bandwidth is lower. Your calculation gives worst case.