• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 17 subscribers
  • Views 5286 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 RX Manchester

sfloydtn
Intellectual 340 points
Other Parts Discussed in Thread: CC1101, CC1120

I have a receive-only CC1101 application and have complete control over the format of the packet that is transmitted... I'm currently using 32-bits (0xAAAAAAAA)) for the preamble and the sync word is 0xD391. There is 1 byte that gets manchester-encoded to 2 bytes (no CRC for now). This gives me an 8 byte transmit packet.

Q1) How does manchester decoding work on the CC1101  (I have bit 0x08 set in MDMCFG2 (manchester encode enabled))? For example, are the preamble and sync bytes manchester decoded? or are just 2 bytes following the sync word  manchester decoded into a single byte?

Q2) I want to use fixed-length packet (set configuration register PKTLEN (0x06) to a fixed number; Lower-2 bits cleared in the PKTCTRL0 (0x08) register [fixed packet length mode]). Do I specify the size of the manchester decoded packet (7 bytes) or the size of the packet that is transmitted (8-bytes)? Are the Preamble & Sync bytes included in the packet length?

 

  • 0
    TI__Genius 14940 points

    Manchester encoding encodes all data including the preamble and sync bytes.  The decode process works similarly, all data received including the sync and preamble are decoded assuming it was Manchester encoded on transmit.

    Packet lengths, both fixed and variable, work on user data counts, not Manchester encoded bit counts.

    Packet length does not include the preamble or sync word.

    You cannot change the Manchester encoding while the radio is transmitting or receiving.  The radio must be in the IDLE state for this change.  The results of changing encoding during transmit or receive are undefined.

    In your case, your 1 byte payload is just 1 byte of packet data and you will set the packet length to 1 for fixed packet length operation.

    If you were transmitting the data using a CC1101, you would set the preamble to 2 bytes and the sync word to 0xD391.  Note that 0xD391 is not a valid Manchester encoded result so there is no valid one byte sync word that can be used to encode to result in a Manchester encoded 0xD391.  Then place your 1 byte of payload into the TX FIFO and strobe the radio into TX mode.

    To receive the above information, you would set the radio to Manchester encoding, set the sync word to 0xD391, and the packet length to 1.  Also since you have no CRC information being appended, you would turn off this feature in the CC1101.

    From your description of what you are transmitting, I don't think the CC1101 will receive it using Manchester encoding if the 0xD391 sync word is intended to be part of the encoded transmitted data stream because it is not a valid Manchester encoding.  If you want to receive this data stream on the CC1101, you will need to turn off Manchester encoding and set the data rate to twice the Manchester encoded rate.  Then you can read in the data in a raw form and decode it yourself.  Note that without Manchester encoding on, you will have a packet length of 2 bytes, the sync word will still be 0xD391, and the preamble will be the alternating 10 pattern you have currently.  In this case, you will only need to decode in software the 2 bytes of payload to get the 1 byte of information.

    Jim Noxon

  • 0 in reply to Jim Noxon
    Intellectual 340 points

    Jim, thanks for the clarification.

    It sounds like I just need to manchester encode the preamble and sync bytes on my transmit side & set my packet size to 1.

    Q1) Is there a reference a document where I can find the information that you provided (I don't see some of it in SWRS061F.) A detailed data flow diagram of how receive works would be very useful.

  • 0 in reply to sfloydtn
    TI__Genius 14940 points

    Yes and no.  You're correct that there isn't a complete data flow diagram in the spec sheet for the radio but the information is in there, it's just spread around a bit.  The section on demodulation describes the overall demodulation process.  Then read section 15.5 on packet handling in receive mode.  This should give you a reasonable picture of the key blocks in the process.

    The key thing is that Manchester encoding is part of the modulation process as described in section 16.  Since modulation in general is applied not only to the data but to the preamble and sync word too, the added Manchester encoding is simply assumed to apply globally just as FSK, ASK, OOK, etc would be applied to these parts of a data packet.

    Jim Noxon

  • 0 in reply to Jim Noxon
    TI__Guru* 86101 points

    Hi

    Manchester encoding is not performed on either the preamble or the sync word. This is the case for both the CC1101 and the CC1120.

    BR

    Siri

  • 0 in reply to Siri
    Intellectual 340 points

    I assume that manchester encoding/decoding is also not performed on the CRC, if one is used?

  • 0 in reply to sfloydtn
    TI__Genius 14940 points

    When I saw Siri's post I was a bit concerned as I have been using the CC1101 for around 4 years now and some of my code expects the manchester encoding to be applied to the entire packet.  To validate I didn't need to go back and correct assumptions I had made in previous code I set up a little experiment to validate which way is actually correct.  I setup a CC1101 on a SmartRF04 board and connected the radio output directly to a scope.  I used OOK modulation as this was both easy to run through an envelope detector and also easy to see the modulation on the scope.  An FSK or MSK signal would have taken more effort but I assume the outcome would be the same.

    The results:  Manchester encoding is done on the entire packet for the CC1101.  This includes the preamble, sync word, and CRC.  I have not done the same experiment with the CC1120 and since I have not had the opportunity to work with that part yet, I'm reluctant to guess at the correct answer.  If I have time, I'll try to run the same experiment with the CC1120 and see what I get.

    =================================================================================
               Experiment Documentation
    =================================================================================

    This file shows the setup for the SmartRF Studio.  The only difference between the two sets of data generated is that manchester encoding was enabled.

    This image shows the non-manchester OOK output of the CC1101 at 868MHz.  The picture is my scope reading the output directly and sampled at 5GHz.

    This image is with the exact same settings as before except with the manchester encoding enabled.  Note that the period on the scope is the same but the period of the packet is twice as long as expected since manchester encoding effectively is at 1/2 rate of the specified baud rate.

    Finally, here is a file that was generated from the raw data taken from the scope.  It is effectively the envelope of both packet formats normalized to the same bit lengths and superimposed for reference.  This image file clearly shows that manchester encoding is implemented on the entirety of the packet.

    0842.envelope.pdf

    Here is the raw data of the two packets from the scope if anyone is interested.  Note the file is 16MB in size.

    1854.manch.zip

    Jim Noxon

  • 0 in reply to Jim Noxon
    Intellectual 340 points

    Jim,

    Your findings are consistent with what I was seeing: RXBYTES status register always showed 0 bytes in RX FIFO, which is expected if Preamble Quality Threshold (PQT) never reached, which would be the case since I'm not encoding them on the transmit side. If I only clear MANCHESTER_EN in MDMCFG2, I can read all manchester-encoded bytes of my packet... The transmitted packet has 3 byte preamble & 2 byte sync word (not manchester-encoded), 1 byte in my payload and 2 bytes of CRC (these 3 bytes manchester-encoded expand to 6 bytes).

    Our energy budget on both transmit & receive is exceedingly tight, so I'll just leave my transmit packet format alone. Reading the 6 encoded bytes and decoding myself in code (see decode routine below) at 8MHz will take microamps whereas extending the transmit packet by encoding preamble & sync will increase receive times by over 33 mS (5 additional bytes * 8 bits = 40 bit times and at 1200 baud).

    char Manchester_Decode (unsigned short manchesterCode, char *decodedByteP)
    {
      unsigned short oneEncoding = 0x8000;
      unsigned short bitField = 0xC000;
      unsigned short bitsSet;
     
      *decodedByteP = 0x00;

      // Loop once per bit
      for (char bit = 0x80; bit != 0; bit >>= 1)
      {
        // Make sure don't have consecutive ones or zeros
        bitsSet = (bitField & manchesterCode);
       
        // See if not a valid Manchester encoding
        if ((bitsSet == bitField) || (bitsSet == 0))
          return 0; // Failure

        // See if the coded bit is a 1   
        if (manchesterCode & oneEncoding)
          *decodedByteP |= bit;
       
        oneEncoding >>= 2;
        bitField >>= 2;
      }
     
      return 1; // Success
    }

    Steve Floyd

  • 0 in reply to Jim Noxon
    TI__Genius 14940 points

    The results of the CC1120 experiments can be found in this thread.

    http://e2e.ti.com/support/low_power_rf/f/156/p/129101/464335.aspx#464335

    Jim Noxon

  • 0 in reply to Jim Noxon
    TI__Guru* 86101 points

    Hi

    I just wanted to say that I was wrong with respect to CC1101. CC1101 does Manchester encoding on preamble, sync, payload, and CRC, while CCCC1120 only does it on payload and CRC.

    I am sorry about my mistake :-(

    Siri