CC1101: CC1101 Preamble Question.

Hi

Both the CC1101 and the CC113L can receive packets even if the preamble is not a 101010 sequence.

For CC1101, the requirement then is to NOT use the PQT, as this requires that the preamble is 101010110

The preamble is used for bit synchronizations and AGC settling etc, and a 0x55 or 0xAA preamble is a better preamble than 0xCC, but both will work.

If the preamble is 0xCCCC and the sync word is 0xCCCS, I guess your biggest problem should be that you can only use a 2 bytes sync word instead of 4, and that the preamble and sync is so alike, so the probability of finding sync in the wrong place is pretty bit.

siri

Hi Siri, thank you for getting back to me.

The CC113L datasheet says several times that the preamble needs to be a sequence of alternating bits.

If the preamble is 0xCCCC (0b110011001100...) how the chip would do the bit sync?

I don't know if you actually used the chip with this preamble, but I tested it at length last week and I just can't receive any packet with the 0xCCCC preamble. Even if I keep everything else the same.

The sync being similar to the preamble is not a problem at all. I have products on the field with preamble as 0xAAAA and sync with 0xAAAS and works with a great packet receive rate.

My hope is that using the CC1101 with PQT disabled, the chip wouldn't care so much about the preamble.

Can you please clarify if you actually used the chip with such preamble?

Thank you!

Thank you again.

I agree with all your statements, including the false packets with the short preamble. All OK.

However, I did the very same test as you, with the different that the preamble from the transmitter is 0xCCCC (while the sync is 0xCCCD). And I get exactly 0 packets. Tested for hours.

But I appreciate you taking the time to sort this out. Based on your answer it seems that the chip "can" receive it, but so poorly that it not useful.

Thanks.

Thanks, Siri.

Is it possible for you to change your preamble to 2 bytes? 0xCCCC?

I can't increase mine to 4 bytes. So I cannot test the same as you, but with a 2-byte preamble, I can't seem to work.

If I put the chip to decode only based on CS, I get the data in and I can find the preamble and sync manually, but I would love to use packet handling.

Hi Siri,

Just for your info, I tried now with a 4-byte preamble (0xCCCCCCCC) and it works much better.

However, my application doesn't support such a long preamble - the transmitter is not done by me and I can't modify it.

Is there any other solution in the Texas portfolio that would help me with this?

Thank you!

Hi.

One additional info: I went back to the 2-byte preamble, and it does work when I change the AGCTRL2 settings to 0xFB. Why? I don't know. The AGCCTRL1 are set to 0x08 and CS detection is disabled.

I haven't done a full RF test, but I can get a decent amount of packets now.

Any reasoning behind this?

I will let someone from our RF group answer the question regarding the AGC, but I guess that since the preamble period is used to settle the AGC, changing AGC parameters might affect performance.

The recommended settings in Studio are based on having a 4 byte long preamble. When you only have 2 bytes, and not as many 0->1->0 transactions, there might be other settings that will give better results.

BR

Siri

Hi Felipe,

For me, this suggests that the AGC is not working properly and sets the gain too high. This is expected with the preamble and sync word that you are using. Did you also change AGCCTRL0 in your last test?

Just for test purposes, could you use the default AGC settings and set the preamble to 0x5555 and sync word to 0xD391, and then update us on how it went?

Regards,

HG

Hello.

Doing further tests today, the "best" configuration I found was:

AGCCTRL2 = 0xF7,      
AGCCTRL1 = 0x08,      
AGCCTRL0 = 0x11

Two notes: the baud-rate is 19.2kbps and I'm not using carrier sense.

There aren't default settings for this baud-rate in the SmartRF, but if I use the 38.4kbps settings, I can't get any frames in.

I haven't seen a lot of change on performance when changing AGCCTRL0.

But anything other than 0b11 in AGCCTRL2_MAX_DVGA_GAIN kills the signal.

The maximum gain I can add on AGCCTRL2_MAX_LNA_GAIN is 5. Any lower value (higher gain) starts to show a rapidly decrease in performance. Although the value 7 yield still better results here.

There are too many combinations here to try, I was hoping you could guide me on some settings you would expect to work best, so I would have a starting point.

I haven't run the test you requested because I have been using Manchester preambles (0xAAAA and 0x5555) with the default settings and they are working fine. It's really with the 0xCCCC preamble that things started to go wrong.

Side note: I'm reading between the lines here that a shorter preamble would possibly require different AGC settings, as Siri mentioned the default settings were build for a 4-byte preamble. Therefore, I was wondering if you can recommend me specific AGC settings since I wouldn't mind decreasing our packet error rate. All my projects uses 2-byte preamble and 2-byte sync. Most of them are Manchester (0xAAAA), but some are Biphase (0xCCCC). And baud-rates 19200, 38400 and 76800.

I appreciate the help.

I would assume that CC1120/ CC1200 would work better here since they only require 4 bit preamble.

For me it looks like you are restricting the number of gain steps the AGC can use and hence it seems to settle faster. But I would run PER vs level and blocking test if you go for this solution since playing with the AGC settings most likely have some side effects. 

Sure thing.

But I'd like TI to propose at least some initial settings for me to try out. There are just too many combinations between all three registers for me to run this.

Thank you!

Hi Felipe,

When I run a packet test with the standard 38.4 kbps PHY and your sync word and preamble, it receives about 90% of the packets.

Have you measured the frequency error of the transmitter and receiver?

What frequency deviation and RX bandwidth do you use?

Regards,

HG 

Hi.

Thanks for sharing.

Once I reduced the AGC settings, I'm getting a good amount of data as well. Thank you!

Hi Felipe,

This is a very interesting conversation and I would be interested to know how well this works for you.

We have been using the CC1200 to receive bi-phase encoded data starting with FFFE for many years, but have used the CC1200 just as an 'RF receiver' and fed the raw bit stream in to an external state machine to detect and extract the actual data. This works very well and we can extract 99%+ of messages at -100dBm on our test setup, but it has always frustrated me that we were not using the CC1200 to decode the actual data. 

It is a shame the CC1200 only supports Manchester encoding/decoding natively and does not support bi-phase directly (especially considering there is a common use in a large market segment that uses bi-phase :-), however I like your approach (if I understand what you are doing correctly) of looking for raw bi-phase bit stream for a preamble/sync patten. (I assume you then do the bi-phase decoding in software later?.

I will have to make some time to dig our our CC1200 dev boards and do a comparison between this method and our external state machine :-)

Regards,

Mark Leman