CC112x manchester decoder

Please see last post from Siri in the post you were refering to (http://e2e.ti.com/support/low_power_rf/f/155/t/126101.aspx)

OK, so I assume Jim Noxon's answer was incorrect then?

How would you suggest that I solve the following problem:

* The target system implements Manchester encoding for all bits, including preamble and sync word (the transceiver is CC1020).
* The preamble pattern is 0x55 and the sync word is 3 bytes long.
* By expanding 0x55 to NRZ I get 0x6666
* Similarly the 3 byte sync word is expanded to 6 bytes

What preamble should I set in CC112x?
Is there some way for me to still use the built-in packet handling? At the moment all I can do is catch the first 4 NRZ bytes of the sync word which makes the rest of the word end up in the RX fifo (which CC112x interprets as the length byte).

EDIT: TX from CC112x should not be a problem since I can put the entire packet in the TX fifo and set preamble and sync lengths to zero. It is only RX that I am worried about.

It should be possible to still use the package handling but I have to play a bit in the lab before giving a spesific answer on this. I hope I will be able to do that on Monday.

My answer was not incorrect with regard to the CC1101.  See the results of an experiment in this post. http://e2e.ti.com/support/low_power_rf/f/155/p/126101/463898.aspx#463898

I do not have any information regarding the CC1120 at this time.

Jim Noxon

Thank you for providing experimental results Jim.

As I am targeting an existing system I do not have the luxury of being able to choose preamble and sync word. The existing preamble is 0x55 which translates to 0x66 in NRZ (right?). This is not a valid option in PREAMBLE_CFG1.preamble_word, what do you suggest?

As for the sync word, it is three bytes in Manchester, expanding to 6 bytes in NRZ. I have set the sync word in CC1120 to the first 4 bytes of the NRZ equivalent and it seems to work. However, the last Manchester byte is inserted into the RX fifo meaning that the variable length feature cannot be used. Is there some workaround for this?

Regards,
Per

Yes, the preamble of 0x55 should translate to 0x6666.  Although that is not a valid option, you should be able to use either preamble 0x33 or 0xCC and turn off the preamble qualification requirement.  Because the matched filter is used for detection of the sync word, I would set the 32 bits of the CC1120 sync word to that of the last 16 bits of the unencoded 24 bit sync word.  This way, the preamble and first byt of sync will still manage the AGC of the system.  Note that the matched filter detection on the sync word does both bit boundary and byte boundary detection simultaneously so you don't need to worry that the first sync word will invalidate the bit boundary detection.  Doing this should preserve your length byte for proper packet handling.

Jim Noxon

This actually seems to work. However, since our CRC algorithm differs from the one in the packet handler I need two additional bytes in the RX fifo (the length byte does not account for the CRC). Is this possible? If not, is it possible to access the CRC from some register?

I am also having difficulties finding the right combination of RX termination settings for my application. I need to wake up every X millisecond, wait for sync word and go back to sleep when no preamble is present or if the sync word is not found within X milliseconds. Using preamble 0x33 and a PQT of 8, PQT_REACHED is asserted ~700us / ~5ms after PQT_VALID on incoming packets depending on pqt_valid_timeout. However, if I enable RX termination based on PQT the chip goes back to IDLE (PQT_VALID still asserts) after 9us. How is RX termination based on PQT supposed to be used? 

Regards,
Per

According to page 36-37 in the CC1120 user guide CRC information is processed and removed in RX. The CRC is calculated from the received data. You write that your CRC algorithm is different but where do you have to take care of those data?

As far as I could see you haven't written something about which datarate, deviation, modulation format and frequency band you are using so it's difficult to know what happens after 700us/9us. I have attached a piece of code that set up the chip to terminate on PQT.

static void worPqtInit(void)
{  
  // Turning off autocal    
  writeByte = 0x03;
  cc112xSpiWriteReg(CC112X_SETTLING_CFG,&writeByte,1);

  // Setting WOR mode to NORMAL_MODE & WOR timer resolution to HIGH_RESOLUTION
  writeByte = 0x08;
  cc112xSpiWriteReg(CC112X_WOR_CFG1,&writeByte,1);

  //Setting Event0 timeout
  //writeByte = 0x02; //20 ms 22 ms 23 ms
  writeByte = 0x03; //30 ms 25 ms 24 ms 37 ms
  //writeByte = 0x03; //31 ms, 30.5 ms
  //writeByte = 0x04; // 32 ms
  cc112xSpiWriteReg(CC112X_WOR_EVENT0_MSB,&writeByte,1);
  //writeByte = 0x80; //20 ms
  writeByte = 0x20; // 25 ms
  //writeByte = 0x40; //26 ms
  //writeByte = 0x60; // 27 ms
  //writeByte = 0xC0; //30 ms 22 ms
  //writeByte = 0xD0; //30.5 ms
  //writeByte = 0xE0; //31 ms 23 ms
  writeByte = 0x00; // 32 ms 24 ms
  cc112xSpiWriteReg(CC112X_WOR_EVENT0_LSB,&writeByte,1);

  //Event1 timeout set to 0.5 ms to allow XOSC anddigital regulator to startup and settle
  writeByte = 0x0C;
  cc112xSpiWriteReg(CC112X_WOR_CFG1,&writeByte,1);

  //Disable Event2 configuration. RC_OSC calibraton interval disabled.
  writeByte = 0x21;
  cc112xSpiWriteReg(CC112X_WOR_CFG0,&writeByte,1);

  //Setting preamble qualifier to 16 symbols
  writeByte = 0x2A;
  cc112xSpiWriteReg(CC112X_PREAMBLE_CFG0,&writeByte,1);  
  
  //Setting RC osc enable
  writeByte = 0x20;
  cc112xSpiWriteReg(CC112X_WOR_CFG0,&writeByte,1);

  //Setting RC calibration mode to continuous calibration
  writeByte = 0x24;
  cc112xSpiWriteReg(CC112X_WOR_CFG0,&writeByte,1);

  // Strobe idle to calibrate
  trxSpiCmdStrobe(CC112X_SIDLE);
       
  //disable RC osc callibration
  writeByte = 0x20;
  cc112xSpiWriteReg(CC112X_WOR_CFG0,&writeByte,1);

  //Setting RX timeout to never
  writeByte = 0x0E;
  cc112xSpiWriteReg(CC112X_RFEND_CFG1,&writeByte,1);

  //Setting RX_TERMINATE_ON_PQT
  writeByte = 0x0C;
  cc112xSpiWriteReg(CC112X_RFEND_CFG0,&writeByte,1);

  //TURN_OFF_XOSC_AND_VREG_IN_PD.
  writeByte = 0x04;
  cc112xSpiWriteReg(CC112X_XOSC2,&writeByte,1);  
}

I cannot just discard the CRC, that would remove the point of having it in the first place. The CRC check is performed in software in the existing system.

When applying your settings I get the same behavior: PQT_VALID is never asserted (IOC_WOR_EVENT0 toggles as expected) in eWOR mode like it does if I manually strobe SRX.

Sorry, I misunderstood your CRC question.

It is some different ways to do this:

- You should turn off CRC in receive on CC1120

- If you use fixed package length you can add 2 to the PKT_LEN register

- With variable package length it should be possible to use what is described on in 7.1.4, page 38 in the user guide

PREAMBLE_CFG0.pqt_valid_timeout sets the timeout to either 16 or 43 symbols. If this bit is set to 0 PQT_VALID asserts after a minimum of 11 symbols if preamble is present and after 16 symbols if a preamble is not present. If it never asserts, do you have long enough preamble?

OK, I'll go for the manual procedure regarding the packet length.

Regarding the pqt_valid_timeout, I understand how it works. The problem is that PQT_VALID never asserts in eWOR mode (I cannot even see that the chip goes into RX state). When strobing SRX from IDLE, the behavior is correct (PQT_REACHED asserts shortly after PQT_VALID and the message is received). It must be something that I am doing wrong related to the eWOR function. As I stated before, IOC_WOR_EVENT0 asserts as expected. The preamble is hundreds of symbols long and should not be of any concern...

Update: I just realized that GPIO settings less than 0x30 are not functional in SLEEP state. However, according to Figure 17 (page 48) the device should enter IDLE mode on EVENT0. I suspect this might be why I cannot get the eWOR function to work.