This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1200 in MSK mode ????

Other Parts Discussed in Thread: CC1101, CC1100, CC1200

Our current system is based on the CC1100 / CC1101 in MSK mode (250000 + FEC, MSK).

The task - to use the same system transceivers CC1200.

I tried to use a 2-FSK modes, 2-GMSK a deviation of 62.5 kHz, 127 kHz - CC1101 does not accept packages from the CC1200.

When I tried to pass on to the CC1200 CC1101 in any combination 2FSK & 2GFSK - packets are transmitted normally, therefore, the other settings are correct transceiver.

However, to send a packet to CC1101 mode MSK I still can not.

1. The problem generally solved in principle?
2. If yes - then how do I configure the CC1200 configuration for such a mode?

  • In MSK mode CC1101 inverts the data. Thus, if you transmit from CC1101 to CC1200 you need to invert the sync word programmed into CC1200 for the sync word to be detected. The data coming into CC1200 will also be inverted.
  • While I'm trying to deal with the transfer of CC1200 -> CC1101

    About inverted synchronization sequence I read earlier and tried to do this (setting up registers SYNC3 :: SYNC0 a $4C, $6E, $4C, $6E) - but it does not work (on the receiving side, CC1101, not even sync detector is triggered).
  • CC1101 sync word is 0xD3 91. Inverted this is 0x2C 6E 2C 6E.

    In Studio enter the above sync word for CC1200. Use fixed packet length and not variable packet length in Studio.
  • Wow! I'm madly in shame - I managed to (twice!) "Invert" the $D3 a $4C! :( Of course, $2C! Yes, now the packet is accepted. And what better to set the amount of deviation for such a regime (250000 bps)? Who packets are received and 62.5, and at 127 kHz. The picture of the spectrum at 62500 is very different from the spectrogram CC1101 transmission mode "the MSK" - from CC1101 is very flat rectangular, in CC1200 - a characteristic "hump" in the middle, although the occupied bandwidth is almost the same Intuitively it seems that is not very good - how to make the most correct ?


    P.S. However, despite the positive reception of packets, the problem is still there!

    I give $$ 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF

    The receiver (CC1101) decodes this as $$ 88 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77, and at the same time gives the error CRC?

    Acceptance of such a sequence (I would expect $$ FF EE DD ... 00) - the result of using FEC or reason in something else?

    How to fix it ? And how to fix incorrect CRC control problem?
  • Did some more thinking and by setting the sync word to 0x2C 6E 2C 6E and MDMCFG1[4]=1 you will receive the transmitted data with correct CRC and no need to do any inversion in SW. MDMCFG1[4]=1 inverts the transmitted payload (not sync word). I did a quick test and it works just fine with CC1200 in TX and CC1101 in RX.

    For MSK you need a modulation index of 0.5 so the CC1200 deviation should be 62.5 kHz. Attached is a plot of the spectrum I measured.

    CC1200_250kbps_62p5kHz_dev.WMF

  • Yes ! Setting MDMCFG1.4 = 1 really solved the problem - the packets on the receiving side look exactly the same as in the administration and the checksum is successful.
    Thank you, thank you so much!

    With regard to the spectrum - I transfer CC1200 looks similar, but significantly different from the CC1101 transmission (I do not know how to attach a picture to a message).
  • According to the results of experiments failed to find a way to make CC1200 accept parcels from CC110x in MSK mode, if a FEC option!

    When setting PKT_CFG1.FEC_EN = 1 A bit INVERT_DATA_EN (MDMCFG1) provides invert the TRANSMITTED data (and CC110x mode MSK + FEC successfully receives packets), but does not affect the RECEIVED data! And regardless of INVERT_DATA_EN received data look the same (usually as XOR with $ 88), and CRC corrupted packet.

    It's all very sad ...
  • Not sure I fully understand please confirm the following

    CC1200 TX, inverted data, no FEC -> CC1101 RX. OK ???
    CC1101 TX, no FEC -> CC1200 RX, inverted data. OK ???
    CC1200 TX, inverted data, with FEC -> CC1101 RX. OK ???
    CC1101 TX, with FEC -> CC1200 RX, inverted data. Not OK ???
  • All right, these are the results turned out at me. In the latter case, bit manipulation INVERT_DATA_EN absolutely does not affect the result.
  • Did a test at 250 kbps and see the same as you. The first three cases work, but in the last case the received data is XOR'ed with 0x88. Don't understand how that happens.

    What value do you have for CC1101 register DEVIATN? This register value had a significant impact on the reception in cases 2 and 4 (CC1101 in TX, CC1200 in RX, no FEC).
  • DEVIANT in all cases is 00 (according to SmartRF MSK).