I should also mention under testing we found RBW values of 12 kHz, 15 kHz, and 20 kHz all resulted in poorer sensitivity performance, hence we have selected 10 kHz to be close to the OBW.  We are performing our tests at 434.1 MHz and at 4800 baud with a BER tester and RF Signal Generator directly into the radio antenna port.

Hi David, 

I have assigned a expert to get back to you on.

Important note: Transparent mode just output the raw data without any processing. When using packet mode (FIFO) mode this signal is post processed in the modem. If you want to get the same performance in transparent mode as in FIFO mode you most likely have to do some post processing. We have not looked into this part since the radio is designed to use FIFO mode and transparent is added later to enable backwards compatibility.  I would assume that you have a protocol where you can't use FIFO mode (no preamble/ sync).  

1) Using FIFO mode the frequency offset estimate could be locked when sync found. Before that the radio doesn't know when you receive noise or a actual signal. Receiving noise will most likely get the frequency estimate to "jump" around and when you actually receive useful data it will take some time for the estimate to output the correct value. If you don't have a preamble the estimate will most likely be off at the beginning and cause errors.  

2) Yes and no. The datarate you set is not used directly but it sets the internal sample rate and increasing the datarate will give less jitter.

3) Not sure here. The phase noise should not be dependent on the modulation format. Or are you actually looking at the modulation shape since FSK is a lot wider than GFSK. 

4) For the reasons listed under 1) it could be that the FB2PLL does not give the wanted result since it typically needs 4 byte preamble to settle the FB2PLL. Meaning that the loop will most likely be too slow. But note that we haven't tested FB2PLL and transparent meaning that you have to do testing your self to see what works and not. 

Unfortunately, we need to use transparent operation due to integration requirements with existing hardware.  We have strict timing requirements that prevent us being able to buffer and re-send the data, and our existing hardware are all using directly modulated serial data.  We do use a preamble and sync though, albeit less then ideal.

TER said:

3) Not sure here. The phase noise should not be dependent on the modulation format. Or are you actually looking at the modulation shape since FSK is a lot wider than GFSK. 

I am talking about the modulation shape.  You can see what I mean in the attached image.  The yellow trace is the CC1200 in FSK mode.  The purple trace is our old ("other") radio.  If we change CC1200 to GFSK, it is very similar in modulation shape to our old radio.  In FSK, the CC1200 has a lot of spurs.

TER said:

4) For the reasons listed under 1) it could be that the FB2PLL does not give the wanted result since it typically needs 4 byte preamble to settle the FB2PLL. Meaning that the loop will most likely be too slow. But note that we haven't tested FB2PLL and transparent meaning that you have to do testing your self to see what works and not. 

Does FB2PLL operate when FOC is disabled?  It seems like FB2PLL is using the FOC feedback for the PLL.  As I noted we got 10dB better performance with FOC disabled, I doubt the 1-2 dB we might get from FB2PLL will be worth enabling FOC again.

Could you elaborate a bit more on the system requirements? When using transparent mode he MCU has to process and store the data before resending. If you use the FIFO the chip does the processing with a few bits latency and they you can read out the processed packet from he FIFO. Have you compared the timing? (transparent vs FIFO). You will get better performance using FIFO (even with a not too ideal sync word)

3) If you plot FSK using Matlab this is how it will look like. In other words, the shape is modulation dependent and not chip dependent. 

4) You have to enable FOC for FB2PLL

The CC1200 is used in a pluggable radio module designed to be a backward compatible replacement for our old radio module.  The over-the-air RF data is not generated by the MCU controlling the CC1200 on the module (the RF MCU), but by the MCU of our host system.  The host system only provides UART for direct-modulated data and some GPIO to configure the mode (off, tx, rx) and the operating frequency.  The new RF MCU contained in the interprets the legacy configuration data and configures the CC1200 accordingly, but the OTA data is generated by the UART of the Host MCU, and this is why we cannot use the FIFO mode.

If we wanted to read/buffer the OTA data in the RF MCU (basically, bridge UART-to-SPI), we would have at least 3x the data latency (1 Tx Host to RF MCU, 1 OTA, 1 RF MCU to Rx Host).  Unfortunately our old products are designed to handle a half-duplex feedback cycle within 50-100ms and use 4800 baud, so the 3x data latency would exceed 100ms, not giving enough time for the Rx Host to switch tx/rx modes and service the data in sync.

So because of the timing requirement for half-duplex comms in our old system, we are not doing any intermediate processing on the OTA data...the host UARTs are connected directly to the CC1200 and the CC1200 is directly modulating the UART data stream to achieve a similar OTA data latency to our old systems.

After further testing, we've determined we can further reduce our RxBW and our CC1200 module now performs on par with our old radio.

While reading the user manual, I noticed the DCFILT_CFG register.  We have just taken the values from SmartRF Studio for this and the associated I and Q registers.  I've noticed the CC1200 module tends to take longer to work out the preamble than our old radio.

1) Could we see any benefit in changing the DC Filter configuration in transparent serial mode?

2) Does the DC Filter configuration have any affect on transmission, or only reception?

3) What are the pros/cons of using the manual compensation (I/Q registers) vs. the filter algorithm (DCFILT_FREEZE_COEFF)?

4) Do you have any recommendations on how to tune the DC Filter configuration for this use case?

We have never looked at the DC filter in the context of transparent mode. 

The DC filter removes the DC component in RX and is critical when using zero IF. In your case it should be less important but use the setting from SmartRF Studio. This filter should have the same function in FIFO mode and in transparent mode. In FIFO mode only 4 bits of preamble is needed (to settle the AGC) so we have not seen any limitations with the DC filter with the settings given. In transparent mode you may have a benefit of adjusting settings but we would not be able to give you any guidance here and I would recommend doing a trial and error approach to see if you are able to get faster response without affecting performance.