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.
Hello,
I´ve read in this forum that the syncword detection on the CC1125 is crucial for the byte synchronization as well as for the bit synchronization.
Post:
Can you confirm this?
As the syncword in our protocol is not compatible with the CC1125, we set it to 0x55 (2 Bytes).
The CC1125 starts to clock out the data as soon as it detects these 2 Bytes in the preamble.
Still, there are bit errors showing sometimes:
(Yellow and Green: Outputs from CC1125, Purple: CC1020 Data Output)
The right part of the green data output shows errors while the CC1020 outputs the preamble on the air without errors.
Setting the syncword detection threshold from 0x1F to 0x0B helped a lot, but the errors still appear.
Is there a way to optimize the synchronization?
Thank you
If I understand correctly, what you have is a packet that consist of 0x55 0x55, data1, data2, ............., correct?
The CC112x, require a preamble (most often a 0x55 or 0xAA) sequence followed by a sync word.
The preamble is used for the radio to allow the AGC to settle etc, and the sync word is used for byte sync, so that the radio know when the packet comes along.
Recommended packet format would be: 0x55, 0x55, 0x55, SYNC1, SYNC2, SYNC3, SYNC4, data1, data2, data2...............
In this case, the RX will look for a 4 byte sync word, and there is only one place that could be.
With your format, you can choose to set the sync word to be 11 or 16 bit:
With 16 bits sync, you do not have any preamble before the sync, and the AGC will not have time to settle before the sync comes a long. There is a bit chance that you will not find sync.
Setting the sync to 11 bits, means that you have in theory 5 bits preamble before the sync. However, since the preamble will be 01010 and the sync 10101010101, there is a big chance that it will find sync the wrong place.
Your best option is to use blind mode, and let your application look for your data. However, it will be hard to determine where the last bit in the sync word stop and the data starts.
siri
Thank you Siri for your detailed answer.
Our legacy packets consist of 82 bytes preamble (0x55) and a 5 byte syncword (0xFF, 0xFF, 0xFF, 0xFF, 0x01).
As the syncword has such bad auto-correlation and consists of 5 bytes, we do the syncword searching by ourselves.
Thus, we set the syncword for the CC1125 to 2 bytes 0x55.
When these bit errors occur, the CC1125 already outputs the signal so the syncword 0x55 0x55 is already detected.
It seems that the synchronization failed.
As I mentioned, setting the threshold to 0x0B really helped a lot. So I assume that these bit errors are related to the sync searching process.
Is there something wrong with our approach?
I do not have a CC1020 available and at the moment no CC1125 either, but I used the CC1200 to do some testing, as this should behave the same way as the CC1125 when it comes to detecting this “bad” packet format. I can repeat the test with a CC1125 later this week.
On the TX side, I used a CC1310, and had it send the following packet:
(0x55 x 82) + 0xFFFFFFFF01 + 0x0102030405
The receiver was set up in normal FIFO mode, and the sync word was set to 0x55555555 (4 bytes)
Since 0x55 is repeated 82 times, we do not know exactly where in the preamble the radio will find sync.
This causes several different packets to be received in the RXFIFO, depending on where it finds sync.
The figure below shows the different bytes to be put in the RX FIFO, depending on where the byte sync is done:
I transmitter 100 packets and received 100 packets. All packets received was one of the above, and I did not see any bit errors in the received 0x55 sequence:
That means that it should be possible to use normal FIFO mode and set the sync word to 4 x 0x55, and then search through the FIFO to look for 0x7F, 0x5F, 0x57 or 0xFF. Based on what byte you find as the first byte after all the 0x55's, you know where your payload is and how to bit shift it to get it correct.
BR
Siri
Thank you for your testing Siri!
It would be very kind, if you could test this with a CC1125 as well and share your register settings.
Is it possible that the bit errors occur because we are using synchronous serial mode instead of FIFO mode?
Is a syncword detection of 4 bytes any better than only 2 bytes in terms of synchronization? (Besides from reducing the risk of detecting false syncwords).
Normally you would achieve better RF performance with using packet mode rather than sync. serial mode, so I would strongly recommend that.
Since you have 82 bytes of preamble, I there are no reasons why you would only look for 2, and risk having false sync detects.
I tested with the CC1125 and did not have any problems.
However, I have no idea as to what RF parameters you would need for your system.
I tested with the 1.2 kbps settings from Studio, and have highlighted my changes below:
I also tested the same settings but using serial mode, and the data looked correct there as well:
PS!
naming of data and clock are swapped
Siri