CC1101DK868-915: CC1000 vs CC1101/CC1111 communication issue

The CC1101 settings look ok. Not sure about the CC1000 settings as I do not know the crystal frequency.

Suggest you test CC1101 and CC1000 separately before you set up a link. Use a spectrum analyzer to demodulate the transmitted signal. Is the symbol rate 38.4 ksps? Is the deviation (=separation/2) 32 kHz? Your CC1000 settings suggest a different deviation.

Hi Sverre,

thanks for your help. We currently don't have any spectum analyzer available but seems like we definitely would need one in order to understand what is going on in more detail. Any help or pointers in the meanwhile is greatly appreciated.

The crystal frequency is 14.745600 MHz Internal (+/- 20 ppm). From my calculations of the register settings it seems this should come out to 64 kHz freq separation unless I am missing something. This is also the specification of this device which is an existing legacy product we are trying to communicate with.

TX REFDIV = 6
FSEP = 0x1AB = 427

Fref = 147456000/6 = 2.457 MHz
Fsep = 2457600 * 427 / 16384 => 64.050 kHz

As for the rate I presume the symbol rate across RF is in fact twice the baudrate due to manchester encoding but the encoding is done transparently in HW so from host side the rate should be 38400 at the CC1111/CC1101 side right ?  Have also tried 76.8 baudrate on CC1111 side without any difference in result. 

When CC1000 is configured for baudrate is seems 19.2, 38.4, 76.8 all share the same register setting which maps the configured MODEM0 register value of 0X54. Is there any other setting I need to check in order to verify this ?

MODEM0[6:4] BAUDRATE[2:0] 

...
101 : 19.2, 38.4 and 76.8 kBaud
110 : Not used
111 : Not used

We have tried playing around a lot on the CC1101/CC1111 side to disable preamble checks and syncword checks in order to detect something (although not properly decoded) but still not able to find any ping frame occuring every 4 secs. 

Brgds

Mattias

You are using a symbol rate of 38.4 ksps (aka kBaud). This corresponds to a bit rate of 19.2 kbps due to the MC encoding.

For CC1000 the MC encoding is a "0" is a low-to-high transition and a "1" is a high-to-low transition. Unfortunately I do not remember how the MC encoding is done on the CC1101, but if it is opposite to CC1000 you need a different set-up (I can help if this is the case). As a simple check: Use Studio and set up CC1101 with 0x55 55 as sync word and a packet length long enough to capture the sync word and (at least part of ) the data payload. Since 0x55 55 is the sync word in this test this will be found at different bit locations within the transmitted preamble, but you should then be able to find the real transmitted sync word in the TX FIFO (you might need to do some bit shifts....).

Just to rule out frequency error as a root cause you can increase the CC1101 RX filter BW. If you do this you also need to increase the IF filter in register FSCTRL1. Set it to 0x12 for this test for instance.

CC1101 manchester: e2e.ti.com/.../295777

Thanks Sverre,

it turns out that the remote CC1000 host transmits data on DIO inverted due to channel being setup as high side LO. This effectively changes the manchester encoded bitstream to be IEEE variant instead of the G.E Thomas variant that CC11xx is able to decode. Due to this the CC11xx is not able to sync on neither preamble nor syncword or parsing variable length field correctly when manchester coding is enabled. 

By setting up CC11xx to disable manchester coding, fixed length packets and setting up syncword to be the IEEE encoded variant of the preamble I am now consistently able to receive the ping frames every 4 seconds.  Thanks so much for your pointers on this!

The drawback of this operation mode is that we now have to handle all manchester decoding/encoding on the host as well as other packet handling features in CC11xx chipset.  

I tried to find options of configuring the type of manchester encoding on CC11xx but was unable to do so. Is there a way ? Basically, what is the recommended config option for CC11xx devices when CC1000 uses a high side LO channel ?

Also, as noted in other threads Manchester coding type is not mentioned in CC1000/CC11xx datasheets. Would it be possible that this can be updated to minimise confusion ? Also perhaps a mention of the potential CC1000 compatibility issue when high side LO channels are used may be useful.

brgds
Mattias

 

Update :

After some more configuration adjustments I was able to consistently receive the frames also when manchester coding was on by using the inverse syncword 0xCB50=>0x34AF  combined with fixed length option. This allowed the HW to sync on the frame and trigger a frame interrupt.Then host could read the length byte (inverted) followed by assembly and inverting back the frame to its original format. Still curious whether there are any way to avoid the above compatibility workarounds between CC11xx and a remote CC1000 device using manchester encoding with high side LO channel.

brgds
Mattias