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.

CC1101 Direct Sync Serial Question

Other Parts Discussed in Thread: CC1101

I am working on determining the format of an OOK transmitted sensor.  I have captured the transmission on an oscilloscope and now need to convert it to binary to determine the format of the packet. 

I want to make sure I am doing this right.  I have captured 10 transmissions, and none of them are identical.  I don't expect them to be identical, but they should be close. 

The picture below I read as : 11001111110110

 

My thinking is that for each cycle of the clock would be one bit. 

 

I think this puts me pretty close.  The FCC documents state that the transmission is roughly 9ms and 76 bits long.  The 10 packets I have "decoded" are very close to that, 72-78 bits long.  They should all be the same length, but I am thinking that maybe the CC1101 might have some wakeup lag on the preamble part.  Here are the 10 decoded binary packets using the above method. (Non-inverted, so when data goes high, = binary 1)

1111 1001 0101 0000 0101 0100 1000 1000 0001 0001 0100 0001 1001 1110 0000 0010 0100 0100 01
1100 0000 0000 1100 0010 1010 0100 0100 0000 0000 0000 0000 0010 0100 1010 1000 0000 1000 0011
1110 0001 0101 0000 0101 0100 1100 1100 0011 0010 0000 0011 0101 1000 1011 1110 1100 1001 00
1100 0001 0101 0011 1101 0110 1100 1100 0011 1110 0110 1101 1011 1110 1100 1101 0110 1101 101
1100 1111 0101 1011 1101 0110 1100 1100 1111 1110 1100 1101 1011 0101 0110 1101 0110 1010 11
1100 0011 1010 1101 1110 1011 0110 0110 0011 1110 1101 0111 1011 0100 0111 1111 1010 1110 001
1111 1001 1011 0011 1101 0110 1101 1101 1111 1111 1110 0001 1011 0110 0101 0111 1101 0110 11101
1111 1111 0101 1011 0101 1001 1011 1010 0000 1011 1111 1101 1011 1101 1111 1101 0110 1101 1
1111 1111 1010 1101 1110 1011 0110 1100 1111 1110 1011 1111 1101 0110 1101 1111 1101 0101 1111
1111 1111 0101 1011 1101 0110 1101 1100 1111 1101 0111 1111 0111 1011 1111 0110 1101 1101 11

So, Any ideas on why I am seeing this much variance in the Serial Output? Am I decoding it right?

  • Hi

     

    I am uncertain if we should help you decode this package format. If you are the rightful owner to this information you should know these details. I suggest you contact the manufacturer of the sensor to see if he/she willingly will share this information.

     

    Tor-Inge

  • Well, the manf of the chip for the sensor says it's no longer in production and the engineer who was in charge of it has left the company.   This is a typical situation with legacy hardware, and sometimes the only way to work with it is to reverse engineer like this.  I do appreciate your ethical concerns though. 

  • Hi Jerome

     

    Since this is OOK signal and IF the transmitter is the dominant current consumer within the sensor you might be able to trace the transmitted data monitoring the sensor battery current/voltage. If data is detectable on battery, you can use one of the first edges as a trigger allowing you to log data from the same time instant in each package.

     

    If you are unable to trace the transmitted data on sensor battery current/voltage there is an alternative approach.

    CC1101 can generate a trigger signal based on received signal strength.

    First secure a high quality communication link (Short distance between CC1101 and sensor). Define a high Carrier Sense (CS) threshold and route the CS signal to a GDO pin (CC1101, datasheet ch. 14.4, p44). Using this GDO signal as oscilloscope trigger allow logging data from the same time instant in each received package.

    Remember that CS will hold some delay

     

    Tor-Inge

     

     

     

     

  • I am using the CC1101 in Synchronous Serial operation (27.2 in the Datasheet).  which should give me direct access to the data.  Why would you suggest that I *NOT* use that mode? 

     

    Anyway, there is no way to access the power source on the sensor.  It's encased in epoxy.

  • Jerome, 

    When I did this it was for a GFSK signal and I used a third output from the CC1101 at the same time to provide an indication of RSSI above threshold. I used this signal to trigger the scope to and it also provided a good reference for the beginning and end of of the signal. 

    /TA