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.

Bug in all RF SoC solved!

While working in a red of low power SoC ccxx10 connecting dozen and dozen units for transmit/ retransmit signals all together in the same band/freq in radio settings classical: 15-16 bits detected ...no adress check double the sync word as 8 bytes so on We did the mistake of mechanically(as robots) assign every unit a sync word byte like :unit#1 bytes sync0=0x01 sync1=0x01,unit#2 sync0=0x02 sync1=0x02,unit#3 sync0=0x03 sync1=0x03,unit#4 sync0=0x04 sync1=0x04..... unit#20 byte sync0=0x20 sync1=0x20 so on And we never faced a problem all units connected great and never a problem...but eventuallysomething happened,something was wrong,unpredictable,crazy,working retransmitting/not working ....a bug was there ,but where? After a week investigating we discovered that a sync bytes 0x02 and 0x04 created a bug!!!(in bit looks like 01 for 0x02 and 001 for 0x04) The SoC detected sync bytes 0x02 and 0x04 similar creating a bug,( after reading the preamble bytes 0101010 happened that SoC crazy confuse 0x02 and 0x04 sync bytes reading 01 and 001 as ok !) -after changing the sync bytes to something like 0xA4 instead of 0x04 everything was working well again and the bug was solved Is important for us to post this issue because a lot of people may read it and save a week long searching for a bug somewhere else like us!!
  • Thanks for sharing. You are correct. As an example, when you account for the 0xAA preamble in front of the sync words you will find that a sync word equal to 0x04 04 can be found just as easily as a 0x02 02 sync word when transmitting a 0x02 02 sync word.

    Please note that if you use 15/16 sync word there is a significant probability that you will find a valid sync word even in noise. Suggestion is to use 16/16 sync word, or even better 30/32. This results in less time processing false packets (maybe the "real packet" is being transmitted while processing the false packet..?)