CC1200: Mistakes found in datasheet register descriptions

Hi Jamie

Please see my comments below:

Recently I've been working on coding a driver for the CC1200 for my application.  I have things mostly working now, but I ran into a few issues along the way, and I think that some of them were due to issues in the CC1200 User Guide and I wanted to share what I've found here. 

Since I wanted my driver to be as configurable as possible, I coded logic for calculating all the register values (e.g. frequency and deviation) from raw parameters instead of just using register data generated from SmartRF.  When I tested it though, I was getting some very weird behavior out of the chip, so I tried generating a full set of registers from SmartRF, and using those fixed the issues.  I then narrowed it down by removing SmartRF registers until things broke, then figuring out why my driver was calculating different values from SmartRF and fixing them.  Eventually, I had things working with my driver calculating all the registers.  However, some of the reasons that it wasn't working were due to things that are either undocumented or just plain wrong in the user guide.

First of all, SmartRF generates settings for a large amount of registers (the FS_* registers and some other ones) where some or all bits are marked as "For testing purposes, only use values from SmartRF".  One would then assume that these registers are not required for normal operation.  However, this doesn't seem to be the case -- removing the writes to the testing registers caused my radio link to stop functioning.  I narrowed it down to two specific registers: FS_SPARE and FS_REG_DIV_CML.  If FS_REG_DIV_CML is left at its default value (0x11) instead of the SmartRF value (0x1C), then output power is decreased by about 5 dB below normal.  FS_SPARE is even worse: leaving it at its default value (0) instead of the SmartRF value (0xAC) prevents the frequency synthesizer from ever locking on to the correct frequency; in my testing it was consistently about 14% too low, generating 760MHz instead of 915MHz. 

I have never even though that this could be misunderstood, as the user guide clearly states that you should use the values given to you by SmartRF Studio. There are many registers that you cannot use a simple equation to calculate what the register should be. Different values for these registers has been tested during our characterization of the devices, and we have found the values that gives the best performance, and these are the values you should use.

At minimum, it would be nice if you guys could add a note into the datasheet mentioning that these two settings are required for correct operation of the chip.  It would also be great if we could have some more info on what these FS_* registers actually do  -- I thought testing meant testing, but it seems like at least some of them are required during normal operation.  Are there any others that I should be setting?  What do they actually control?

Again, I have never thought of that sentence not been clear enough, and I have never seen issues related to this. It says “only use values from SmartRF”, so that is what you need to do :-)

I also ran into some issues with calculating the symbol rate.  Looking at user guide section 5.4, it seems pretty clear that Rsymbol in the equation is supposed to be in ksps.  It also says this in the SYMBOL_RATE2 register description.  However, this is not actually the case: plugging register values generated from SmartRF into the datasheet equations gives numbers that are off by a factor of 1000 exactly -- Rsymbol in those equations seems to be in sps.  Additionally, I worked it out on paper to better understand the calculation process, and unless I'm missing something, Equation 9 seems incomplete: it doesn't handle the case where SRATE_E is 0.  In this case, a different, more accurate equation is used to calculate SRATE from SRATE_M, and this requires a different equation to calculate SRATE_M.  I worked it out as SRATE_M = (Rsymbol * 2^38) / fxo [but I haven't tested this yet].

I agree that there is a typo and that the Eq. 6 and 7 gives the symbol rate in sps and not ksps

For what data rate have you gotten that SRATE_E is 0?

Clearly SmartRF understands the correct calculation method for the SRATE registers -- it would be cool if this could be propagated to the user guide as well.

Lastly, there's another register field that has me really stumped: MDMCFG2.UPSAMPLER_P.  The user guide gives a formula to calculate this, but it just plain doesn't seem to work.  For 100kbps it would seem like 0x3 would be the right value, but with this setting the radio doesn't seem to transmit valid data.  Only MDMCFG2.UPSAMPLER_P = 0x2 (the value used by SmartRF) allows data to be transmitted.  Looking at the SmartRF configs, it looks like this register is just hardcoded to different values for different radio configs.  So it's not really clear how to actually determine the correct value for a given symbol rate, and heck knows what you're supposed to do if you need a symbol rate that is not one of the provided configs in SmartRF.

It would be really nice if you could provide a method to calculate this value, or at least some kind of rule for what to use.  Also, out of all the key settings to set, this field isn't mentioned anywhere in the user guide at all other than the register description, so there is no way you can know to set it other than by reading through every single register description.  It would be great if we could add a small note to the symbol rate section telling people to program UPSAMPLER_P.  

Again, it is not the case that all registers can be calculated.

For the UPSAMPLER_P I do not see any issues.

From the data sheet: Symbol Rate * 16 * P < fxosc/4

For 100 ksps:         P < (40000000/4)/(100000*16) < 3.124

P can only be 2 and 4 (see MDMCFG2), hence you need to select 2, and set UPSAMPLER_P to 001b

Anyway, I hope this information is helpful.  The CC1200 is a cool chip, and I'm excited to use it on this project -- I just hope we can improve the user guide a bit so that manual analysis of SmartRF settings isn't needed anymore!

I do not understand at all why you think that it should be a goal to not use SmartRF Studio. This is one of our most important tools when it comes to program our devices. I have not seen many application that have the need to change a bunch of settings in an application. Studio is the recommended tool to find the best register settings. The recommended settings from Studio are the settings that are characterized and are the settings our data sheet numbers are based on. As you have noted, there are several registers that cannot be calculated, but you need to change them from default, and the values to use, comes from bench test.

P.S. If and when I can get it working, I plan to publish my CC1200 driver (for MBed OS) as open source, so hopefully not too many other people will need to go through the process of calculating this.

I agree that if there are errors in the user guide, it should be fixed, but we do not have any plans on updating information regarding the registers that are not explained by are simply telling you to use the values from SmartRF Studio.

BR

Siri