CC1101: CRC errors with higher data rates (125K and 250K)

Use of interrupts is the recommend way to use the radio. Why are you wanting to use polling code?

What do you mean by "no sooner than 50 ms..."?

I cannot use interrupts. Why will moving to interrupt solve the problem?

There is a 50ms delay put between polls because as per CC1101 errata some registers may have problems due to high speed polling. 50ms delay between polls makes it relatively low speed poll and is introduced to avoid all issues in the errata.

By the way, in my test code, the TX side sends a few bytes once a second.

The RX side has the below observations

1) Very few successful receptions.

2) Few pkts received but have CRC errors.

3) Most of the pkts are completely missed without any indication

Polling create a bit more noise due to the SPI traffic and require the MCU to be on which in many cases it's not wanted.

First, test with a board controlled by SmartRF Studio as receiver to check if you then are able to receive the packets. This is to ensure that your TX side behave as wanted.

Second, it's not possible to guess what goes wrong without knowing anything about your code.

Is this a hobby project since it looks like you are using Arduino or is it a prototype for a later volume project?

Its for an actual system in production. CC1101 is being used on arduino as a prototype while the final product would use ESP32. The library already works on both systems at 74.8 kbaud in production. After facing this problem, a longer test was performed to measure pkt loss at 74.8Kbaud.
4% pkt drop was measured at 74.8KBaud irrespective of channel being used.
In most of the products using CC1101 we use 'always on MCU' so polling is not an issue.

The devices are being tested within a distance of 1 M with sufficient TX power. Is SPI noise known to manifest in high data rate reception in CC1101?

With 1 m distance, what is the RSSI you measure for the received packets in this test? I would believe that you need to be a bit closer to see this issue, but have you checked that you are not in saturation?

All the sensitivity tests we have done is interrupt based meaning that we don't have any sensitivity numbers for polling. We have just seen indications that pin activity during receive will reduce sensitivity some.

From what you write it sounds like the problem start for 74.8 kbps and get worse for higher datarates. I would suspect timing issues.

I looked at the github code you linked to but could not find how the polling in RX is done. Do you have more details here?

Are you able to use a known good receiver (board controlled by SmartRF Studio) to check that the tx side works as wanted?

If it was a saturation issue then it should also occur at lower data rates where the receiver sensitivity is better. But this issue only occurs at higher datarate only.
As mentioned in my 1st post, the github library has been modified to support non interrupt polling mode and some more data rates that the original library does not support. Is there a way I can pass the code via a personal message?

I will check pkt loss % at a lower 4.8kbaud, if it happens less then its a timing issue and needs exploring interrupt mode.

A board controlled by SmartRF Studio will take time to get up and running.