CC1101 - hybrid packet length mode

[cherowley]

Hi!

I'm trying to reverse engineer a two way protocol between my shower controller and the remote wall control.

I've get all the params sorted for receiving (433.2mhz, 10k bit rate 20knz deviation, 2-fsk) but I'm having a problem decoding the data.
The data sent/received has variable packet lengths. HOWEVER, the packet length is NOT sent in the packet after the sync...
I presume the shower considers a packet finished when no more data has been received for a time...

I'm not sure how to handle this with radiolib?

As an aside, I'm using variable length mode but this then sends the code into a loop thinking its received a packet after the first packet. even though it hasn't. It simply keeps "receiving" the first packet for ever... I presume this is a buffer underrun problem as the first byte of data in the packet is 0x91 - but the packet isn't that long so assume its trying to read too much lol...

Anyone got any ideas?

Also, the shower sends d391 sync word twice - I can't see a way in radiolib to tell it the sync word is repeated (30/32 sync word bits detected accoding to ti docs) ?

Cheers!

[jgromes]

I think this could be possible with direct reception - essentially that allows you to bypass the packet handler inside the radio and implement packet handling in your application code. There's no dedicated example for it on CC1101, but you can take a look at the one for SX127x, the interface on for CC1101 is the same.

If the sync word is sent twice, you can try radio.setDirectSyncWord(0xD391D391, 32); and then check whether radio.available() is more than some threshold (probably the shortest packet you expect). Then you will have to implement some logic to decide when the packet has actually ended - maybe you could use radio.getRSSI() to see if the signal level has dropped.

[cherowley]

Ah many thanks for quick response!

Dumb question, that example mentions DI02 pin - what is the equivalent on the CC1101 - is it the GDO2 ?

[jgromes]

On CC1101, in synchronous direct mode, GDO0 will output clock while GDO2 will output data. The idea is that on each clock signal, you will sample the data from GDO2, so yes, you will be calling radio.readBit on GDO2.

[cherowley]

I'm struggling with this ha! I'm trying to distinguish packets by the gap inbetween. I added a time out to say start a new packet after so long but this isn't working. Am i correct in assuming that bytes purely from noise will trigger the intterupt so meaning that a timeout never occurs? Also re the d391 x2 sync word - what is the correct way to set that, is it: radio.setDirectSyncWord(0xD391D391, 32) ?

Should i use carrier sense option in radio.setDirectSyncWord - if so what would be the format for that? :)

[cherowley]

Anyone got any ideas on how to do this - still stuck!

If i try

void loop() {
while(radio.available()) {
byte b = radio.read(false);
Serial.print(b, HEX);
Serial.print(' ');
Serial.print(r);
Serial.println();
}
}

Then once its received the first sync word it just keeps receiving random bytes (mostly 0). It doesn't seem to receive the actual data though..

if i try

void loop() {
while(radio.available()) {
byte b = radio.read(true);
Serial.print(b, HEX);
Serial.print(' ');
Serial.print(r);
Serial.println();
}
}

then it only receives the first byte from each packet as after reading the first byte it needs another sync yes? :(

[jgromes]

If you call read(true) then the PhysicalLayer class will drop the synchronization - this way you are essentially telling it that the packet has ended and you want to wait for another one.

Is there some encoding on the payload data? Maybe some Manchester or something else - by default the radio expects unencoded bytes.