I am transmitting, but the chip does not receive anything. What should I do?
First, make sure that you are indeed transmitting, and it is the right packet that is being sent. Outputting TX_STATE, TX_DATA, TX_DATA_CLK to the GPIOs will confirm that the chip goes to TX State, and also, the data being transmitted is what you would expect. If that is all correct, go to the RX side, output RX_STATE, RX_DATA, RX_DATA_CLK signals and compare them against TX_DATA_TX_DATA_CLK. The waveforms should match.
If they do not, check the radio configuration, there might be a mismatch; take a closer look at center frequency, deviation, modulation type, data rate, etc. Also, you might need to adjust the cap bank value to fine tune the frequency. Measuring the current consumption on the TX side may give you an idea that it is indeed in TX State and it is transmitting with high output power (of course, you can measure the output power with a spectrum analyzer directly). Likewise, measuring around 10/13mA indicates that the device is indeed in RX State.
If TX/RX_DATA waveforms do match however, it means that the device received the data correctly, but for some reason it is not getting through the packet handler. In such a case make sure that the PREAMBLE and SYNC word detection signals arrive correctly (you can configure these to the GPIOs, as well). Also, you may want to confirm that the PACKET_RX interrupt is configured, the packet length has been entered correctly (via START_RX command / PKT_FIELD_x_LENGTH properties).
If none of these helped, check whether there has been a CRC error, or Command Error event. Note that if there is a CRC error, you need to leave RX state, reset the RX FIFO by a FIFO_INFO command, and then you can go back to RX state.
Lastly, you may want to check the next states for the START_RX command (i.e. RX_TIMEOUT_STATE, RXVALID_STATE, RX_INVALID_STATE). In most cases, for invalid preamble (i.e. RX_TIMEOUT_STATE) you may want to use ‘0 – No change’ in order to have the receiver staying in RX state without any interruption while searching for preamble (if it was ‘8 – RX state’, there would be a short interruption in the received data due to the RX->RX state transition whenever the invalid preamble timeout occurs). For valid packet (i.e. RXVALID_STATE), however, you may want to avoid ‘0 – No change’, and use RX State instead. The packet handler needs to be re-armed after a packet is successfully received, and in order to that the chip has to re-enter RX state; this can be performed by selecting RX State for RXVALID_STATE. A ‘No change’ would not initiate restarting the packet handler; it would stay in receive mode, and although still outputting the received data, no longer searching for preamble and sync word, and therefore not putting the data into the RX FIFO.