CC1101: Modifying Working Code for Different Modulation

No luck!.

Starting with settings from studio for GFSK 345 mHz that worked, i changed the modulation to ASK. This only changed one register:

   0x36,  // MDMCFG2             Modem Configuration

Then from the note made several changes for a 100 kHz filter bandwidth:

   0x04,  // AGCCTRL2            AGC Control

   0x00,  // AGCCTRL1            AGC Control

   0x92,  // AGCCTRL0            AGC Control

   0x56,  // FREND1              Front End RX Configuration

   0x81,  // TEST2               Various Test Settings

   0x35,  // TEST1               Various Test Settings

   0x47,  // FIFOTHR             RX FIFO and TX FIFO Thresholds

I wasn't sure what bandwidth to use. Since both the transmitter and receiver are using the same setting, was sure if this mattered.

The transmitter and receiver were about 20 feet apart. The range probably drops with the lower frequency, though GFSK 345 mHz worked. Moving them to about 4 feet did not help.

It's a plain vanilla CC1101:

It has to be the patable or register settings. Do you have any settings for 345 mHz ASK known to work?

You can ignore the three last registers. I did the code export after running a test in SmartRF Studio, and since these are status registers and did change during the test, they were part of the export.

You can use the same settings for both RX and TX.

For the settings I gave you, address filtering is not enabled (PKTCTRL1_ADR_CHK = 0) so the ADDR register is don’t care.

If you enable address filtering, the ADDR register will only be used in RX, and the radio will only receive packets containing the address given by ADDR.

In TX, the ADDR must then manually be written to the TX FIFO:

Example:

PKTCTRL1_ADR_CHK = 1

PKTCTRL0_LENGHT_CONFIG = 1

ADDR = 3

PKTLEN = 7

With the above configuration, the receiver will expect a length byte and an address byte. The ADDR must be 0x03 and max length can be 0x07:

Valid packet

5, 3, 1, 2, 3, 4

Invalid packet

8, 3, 1, 2, 3, 4, 5, 6, 7 // Length byte greater than 8

Invalid packet

5, 2, 1, 2, 3, 4 // Invalid address

Do you have the chance to monitor the GDO2 pin with a scope to make sure that you do not miss anything when reading the pin in the code?

You should also read the TXBYTES register after writing to the TX FIFO, and after strobing STX. When the packet is sent, the TXBYTES should be 0 and MARCSTATE should show IDLE

I created a git project with working GFSK. Then updated the above ASK values which does not work.

The git diff is attached. Working GFSK is '-'. Not working ASK is '+'.

There are many differences. Is there a way to change the settings in small groups so that it is always near a working state? 

Would the original packet registers work? The address 0x00 might be better than 0xFF, but it is a don't care. The length 3E should be sufficient.

- 0x3E, // PKTLEN Packet Length
- 0x0E, // PKTCTRL1 Packet Automation Control
- 0x45, // PKTCTRL0 Packet Automation Control
- 0xFF, // ADDR Device Address

pi@raspberrypi:~/Documents/dev/ask2 $ git diff -w cc1100_raspi.cpp
diff --git a/cc1100_raspi.cpp b/cc1100_raspi.cpp
index eeb1b90..30e2c65 100644
--- a/cc1100_raspi.cpp
+++ b/cc1100_raspi.cpp
@@ -17,56 +17,56 @@
 
 extern uint8_t cc1100_debug;
 
-static uint8_t PATABLE_POWER[8] = {0x6C,0x1C,0x06,0x3A,0x51,0x85,0xC8,0xC0};
+static uint8_t PATABLE_POWER[8] = {0x00,0x51,0x00,0x00,0x00,0x00,0x00,0x00};
 
 static uint8_t STUDIO_REGISTERS[CFG_REGISTER] = {
-                    0x07,  // IOCFG2        GDO2 Output Pin Configuration
+    0x29,  // IOCFG2              GDO2 Output Pin Configuration
     0x2E,  // IOCFG1              GDO1 Output Pin Configuration
-                    0x80,  // IOCFG0        GDO0 Output Pin Configuration
-                    0x07,  // FIFOTHR       RX FIFO and TX FIFO Thresholds
-                    0x57,  // SYNC1         Sync Word, High Byte
-                    0x43,  // SYNC0         Sync Word, Low Byte
-                    0x3E,  // PKTLEN        Packet Length
-                    0x0E,  // PKTCTRL1      Packet Automation Control
-                    0x45,  // PKTCTRL0      Packet Automation Control
-                    0xFF,  // ADDR          Device Address
+    0x06,  // IOCFG0              GDO0 Output Pin Configuration
+    0x47,  // FIFOTHR             RX FIFO and TX FIFO Thresholds
+    0xD3,  // SYNC1               Sync Word, High Byte
+    0x91,  // SYNC0               Sync Word, Low Byte
+    0xFF,  // PKTLEN              Packet Length
+    0x04,  // PKTCTRL1            Packet Automation Control
+    0x05,  // PKTCTRL0            Packet Automation Control
+    0x00,  // ADDR                Device Address
     0x00,  // CHANNR              Channel Number
-                    0x08,  // FSCTRL1       Frequency Synthesizer Control
+    0x06,  // FSCTRL1             Frequency Synthesizer Control
     0x00,  // FSCTRL0             Frequency Synthesizer Control
     0x0D,  // FREQ2               Frequency Control Word, High Byte
     0x44,  // FREQ1               Frequency Control Word, Middle Byte
     0xEC,  // FREQ0               Frequency Control Word, Low Byte
-                    0x5B,  // MDMCFG4       Modem Configuration
-                    0xF8,  // MDMCFG3       Modem Configuration
-                    0x13,  // MDMCFG2       Modem Configuration
-                    0xA0,  // MDMCFG1       Modem Configuration
+    0xF5,  // MDMCFG4             Modem Configuration
+    0x83,  // MDMCFG3             Modem Configuration
+    0x33,  // MDMCFG2             Modem Configuration
+    0x22,  // MDMCFG1             Modem Configuration
     0xF8,  // MDMCFG0             Modem Configuration
-                    0x47,  // DEVIATN       Modem Deviation Setting
+    0x15,  // DEVIATN             Modem Deviation Setting
     0x07,  // MCSM2               Main Radio Control State Machine Configuration
-                    0x0C,  // MCSM1         Main Radio Control State Machine Configuration
+    0x30,  // MCSM1               Main Radio Control State Machine Configuration
     0x18,  // MCSM0               Main Radio Control State Machine Configuration
-                    0x1D,  // FOCCFG        Frequency Offset Compensation Configuration
-                    0x1C,  // BSCFG         Bit Synchronization Configuration
-                    0xC7,  // AGCCTRL2      AGC Control
-                    0x00,  // AGCCTRL1      AGC Control
-                    0xB2,  // AGCCTRL0      AGC Control
-                    0x02,  // WOREVT1       High Byte Event0 Timeout
-                    0x26,  // WOREVT0       Low Byte Event0 Timeout
-                    0x09,  // WORCTRL       Wake On Radio Control
-                    0xB6,  // FREND1        Front End RX Configuration
-                    0x17,  // FREND0        Front End TX Configuration
-                    0xEA,  // FSCAL3        Frequency Synthesizer Calibration
-                    0x0A,  // FSCAL2        Frequency Synthesizer Calibration
+    0x14,  // FOCCFG              Frequency Offset Compensation Configuration
+    0x6C,  // BSCFG               Bit Synchronization Configuration
+    0x03,  // AGCCTRL2            AGC Control
+    0x40,  // AGCCTRL1            AGC Control
+    0x92,  // AGCCTRL0            AGC Control
+    0x87,  // WOREVT1             High Byte Event0 Timeout
+    0x6B,  // WOREVT0             Low Byte Event0 Timeout
+    0xFB,  // WORCTRL             Wake On Radio Control
+    0x56,  // FREND1              Front End RX Configuration
+    0x11,  // FREND0              Front End TX Configuration
+    0xE9,  // FSCAL3              Frequency Synthesizer Calibration
+    0x2A,  // FSCAL2              Frequency Synthesizer Calibration
     0x00,  // FSCAL1              Frequency Synthesizer Calibration
-                    0x11,  // FSCAL0        Frequency Synthesizer Calibration
+    0x1F,  // FSCAL0              Frequency Synthesizer Calibration
     0x41,  // RCCTRL1             RC Oscillator Configuration
     0x00,  // RCCTRL0             RC Oscillator Configuration
-                    0x59,  // FSTEST        Frequency Synthesizer Calibration Control,
+    0x59,  // FSTEST              Frequency Synthesizer Calibration Control
     0x7F,  // PTEST               Production Test
     0x3F,  // AGCTEST             AGC Test
     0x81,  // TEST2               Various Test Settings
-                    0x3F,  // TEST1         Various Test Settings
-                    0x0B   // TEST0         Various Test Settings
+    0x35,  // TEST1               Various Test Settings
+    0x09,  // TEST0               Various Test Settings
 };
 
 //----------------------------------[END]---------------------------------------

I have tested your register settings and they are OK. They are just the same as you get when you do a code export of the ASK settings in Studio.

I tested the settings with the CC1101 code found here:

The only change I did was that I replaced the settings with the once you had, and then I set IOCFG2 to be 0x06 instead of IOCFG0, since the code uses GDO2 as interrupt.

I tested the TX code, and then I used SmartRF Studio as the receiver. All packets were received OK.

Can you please try an example were you only use ASK and not change between two different sets of settings? I think you should focus on getting ASK up and running alone, before you do the next step which is switching between the two formats.

Are you writing to the PATABLE in the correct way? The PATABLE must be accesses in burst mode. If not, you are just writing to the same location in the table over and over again. Since the first item in the table is 0x00, this could explain why it does not work.

Siri

The last response helped. It is partly working.

I tested with the default ASK settings and the following GDO settings:

0x07, // IOCFG2 GDO2 Output Pin Configuration

0x2E, // IOCFG1 GDO1 Output Pin Configuration

0x80, // IOCFG0 GDO0 Output Pin Configuration

The first packet is received, but no subsequent packets are received. If the receiver is bounced, one more packet is received.

Here is the loop checking for GDO2:

uint8_t CC1100::packet_available()
{
    if(digitalRead(GDO2) == TRUE)                           //if RF package received
    {
        if(spi_read_register(IOCFG2) == 0x06)               //if sync word detect mode is used
        {
            while(digitalRead(GDO2) == TRUE){               //wait till sync word is fully received
                printf("!\r\n");
            }                                                  //for sync word receive
        }

        if(debug_level > 0){
             printf("Pkt->:\r\n");
        }

        return TRUE;
    }
    return FALSE;
}

IOCFG2 0x07 logs:

Pkt->:

RX_FIFO:0x06 0x03 0x01 0x00 0x00 0x0B 0xB8 | 0x4A 0x80 |

RSSI:-41 LQI:0x00 CRC:0x00 

IOCFG2 0x06 logs (with many exclamation marks:

!

!

!

!

Pkt->:

RX_FIFO:0x06 0x03 0x01 0x00 0x00 0x0B 0xB8 | 0x4A 0x80 |

RSSI:-41 LQI:0x00 CRC:0x00 

I have a couple of qustions about IOCFG even though it may not be part of the problem.

Do IOCFG0 and IOCFG1 matter?

Is IOCFG2 Ox07 also in sync mode? 

Here is the code for the reading a packet:

uint8_t CC1100::get_payload(uint8_t rxbuffer[], uint8_t &pktlen, uint8_t &my_addr,
                            uint8_t &sender, int8_t &rssi_dbm, uint8_t &lqi)
{
    uint8_t crc;

    rx_fifo_erase(rxbuffer);                               //delete rx_fifo bufffer

    if(rx_payload_burst(rxbuffer, pktlen) == FALSE)        //read package in buffer
    {
        rx_fifo_erase(rxbuffer);                           //delete rx_fifo bufffer
        return FALSE;                                    //exit
    }
    else
    {
        my_addr = rxbuffer[1];                             //set receiver address to my_addr
        sender = rxbuffer[2];

        rssi_dbm = rssi_convert(rxbuffer[pktlen + 1]); //converts receiver strength to dBm
        lqi = lqi_convert(rxbuffer[pktlen + 2]);       //get rf quialtiy indicator
        crc = check_crc(lqi);                          //get packet CRC

        if(debug_level > 0){                           //debug output messages

            printf("RX_FIFO:");
            for(uint8_t i = 0 ; i < pktlen + 1; i++)   //showes rx_buffer for debug
            {
                printf("0x%02X ", rxbuffer[i]);
            }
            printf("| 0x%02X 0x%02X |", rxbuffer[pktlen+1], rxbuffer[pktlen+2]);
            printf("\r\n");

            printf("RSSI:%d ", rssi_dbm);
            printf("LQI:");printf("0x%02X ", lqi);
            printf("CRC:");printf("0x%02X ", crc);
            printf("\r\n");
        }

    return TRUE;
    }
}

The logs indicate that after reading first packet, GDO2 is never true again. Is this a register setting or should the software be doing something to reset this line?

Using default studio settings except IOCFG2 = 0x06, receiver gets only the first transmitted packet. If receiver is bounced, it gets one more. Transmitter sends packet every few seconds without intervention. This implies transmitter is fine, because it does not require bouncing.

I don't have a scope. If we are transmitting fine, how would it help?

The method rx_fifo_erase only erases the buffer. I was trying to avoid including all code, so that I would learn more. But I see it is better to include code:

I did not want to use interrupts because in future will decode signal manually, i.e. poll GDO2, and convert poll data to logical 0s and 1s. Are interupts compatible with manual decoding, i.e. processor would sleep until it receives an interrupt when it would then poll GDO2? Since transmissions are every few seconds with test transmitter, did not think a message would be missed. Processor is Raspberry Pi running LINUX. Based on 'top' with receiver running, processor is 95% idle. I am new to this, so let me know if might still be an issue.

The receiver calls: packet_available() to detect if packet has been received, and get_payload() to read the packet. After the packet is received, is some kind of reset required? It does not appear that the buffer needs to be erased, as it is erased before a new packet is read.

Siri, You are too modest. Setting RXOFF_MODE=RX (MCSM1 = 0x0C) fixed it. Packet based ASK is working. Thank you so much!

The signal to be captured is an older 345 mHz 64 bit signal after manchester decoding. Here is a sample of the signal captured with RTL-SDR and displayed in Audacity:

You can see the manchester encoding in the above, i.e never more the two highs or lows in a row.

To decode this, should the CC1101 be placed in asynchronous mode (PKTCTRL0.PKT_FORMAT to 3) and the control software continuously listen on GDO2?

Reading Section 27.1, Asynchronous Serial Operation , the registers were set as follows:

PKTCTR1 0X00

PKTCTR0 0X30

All other registers were not be changed. It is assumed features like packet length can be ignored in this mode.

The code logs when GDO2 is TRUE:

		for (;;) 
		{
			if(digitalRead(GDO2) == TRUE)                           // High?
			{
				printf("X");
			}
			else
			{
				//printf(".");
			}
		}

The result is nothing is logged, i.e. the signal is not picked up.

Does above sound right?

Setting IOCFG2 to 0x0D, and GDO2 returns values.

I have the receiver logging 0s and 1s. Without a signal, screen looks like all 1s, i.e 1s are filling the screen. When signal is sent, some 0s flash by. So receiver is picking up something.

I'll have to graph output to see how well the signal was captured.

The asynchronous receiver runs an infinite loop that logs GDO2 and the iteration. Here are three iterations running from 0 to 1:

0,485794

0,485795

1,485796

Here is the graph:

The transmitted message contains 64 manchester encoded bits. The above does not look like manchester encoding.

Here is a description of the signal from the FCC application:

Recording and printing in a loop could have delays when buffered output is saved to a file.  There a number of ways it might be improved:

Create a large memory buffer, and dump the buffer to a file at the end.

Reduce the oversampling. It is probably 10x more than needed.

Record the actual time rather than the iteration.

It might well be a radio setting. Any thoughts on radio setting changes?

By normal mode, do you mean packet mode? It has a start bits. There are couple of extra long bits before the start bits. Is "normal" mode still possible?

Let's start over. Here is the signal captured at 345 mHz using RTL-SDR:

As it is manchester encoded, the message consists of 8 bytes. The first arrow is after 2 bytes. The second arrow is 1 byte later. 

The signal contains:

• 3 bytes start/preamble
• 4 bytes payload
• 1 byte crc

The first 3 bytes don't change. What is the difference between start and preamble? What is the minimum length required for packet mode?

As it is manchester encoded, how does it know if the first bit is zero or one?

The crc is CRC-16/BUYPASS. Can the CC1101 compute this? At least initially, would it be simpler to consider the CRC as part of the payload? 

Can this be handled in packet mode? 

Here are all register settings:

static uint8_t STUDIO_REGISTERS[CFG_REGISTER] = {

                   0x06,  // IOCFG2        GDO2 Output Pin Configuration

                   0x2E,  // IOCFG1        GDO1 Output Pin Configuration

                   0x06,  // IOCFG0        GDO0 Output Pin Configuration

   0x47,  // FIFOTHR             RX FIFO and TX FIFO Thresholds

   0xCD,  // SYNC1               Sync Word, High Byte

   0x4D,  // SYNC0               Sync Word, Low Byte

   0x0B,  // PKTLEN              Packet Length

   0x00,  // PKTCTRL1            Packet Automation Control

   0x00,  // PKTCTRL0            Packet Automation Control

   0x00,  // ADDR                Device Address

   0x00,  // CHANNR              Channel Number

   0x06,  // FSCTRL1             Frequency Synthesizer Control

   0x00,  // FSCTRL0             Frequency Synthesizer Control

   0x0D,  // FREQ2               Frequency Control Word, High Byte

   0x44,  // FREQ1               Frequency Control Word, Middle Byte

   0xEC,  // FREQ0               Frequency Control Word, Low Byte

   0xF5,  // MDMCFG4             Modem Configuration

   0x83,  // MDMCFG3             Modem Configuration

   0x31,  // MDMCFG2             Modem Configuration

   0x12,  // MDMCFG1             Modem Configuration

   0xF8,  // MDMCFG0             Modem Configuration

   0x15,  // DEVIATN             Modem Deviation Setting

   0x07,  // MCSM2               Main Radio Control State Machine Configuration

   0x0C,  // MCSM1               Main Radio Control State Machine Configuration

   0x18,  // MCSM0               Main Radio Control State Machine Configuration

   0x14,  // FOCCFG              Frequency Offset Compensation Configuration

   0x6C,  // BSCFG               Bit Synchronization Configuration

   0x03,  // AGCCTRL2            AGC Control

   0x40,  // AGCCTRL1            AGC Control

   0x92,  // AGCCTRL0            AGC Control

   0x87,  // WOREVT1             High Byte Event0 Timeout

   0x6B,  // WOREVT0             Low Byte Event0 Timeout

   0xFB,  // WORCTRL             Wake On Radio Control

   0x56,  // FREND1              Front End RX Configuration

   0x11,  // FREND0              Front End TX Configuration

   0xE9,  // FSCAL3              Frequency Synthesizer Calibration

   0x2A,  // FSCAL2              Frequency Synthesizer Calibration

   0x00,  // FSCAL1              Frequency Synthesizer Calibration

   0x1F,  // FSCAL0              Frequency Synthesizer Calibration

   0x41,  // RCCTRL1             RC Oscillator Configuration

   0x00,  // RCCTRL0             RC Oscillator Configuration

   0x59,  // FSTEST              Frequency Synthesizer Calibration Control

   0x7F,  // PTEST               Production Test

   0x3F,  // AGCTEST             AGC Test

   0x81,  // TEST2               Various Test Settings

   0x35,  // TEST1               Various Test Settings

   0x09,  // TEST0               Various Test Settings

};

Here are the changed registers:

+    0xCD,  // SYNC1               Sync Word, High Byte

+    0x4D,  // SYNC0               Sync Word, Low Byte

+    0x0B,  // PKTLEN              Packet Length

+    0x00,  // PKTCTRL1            Packet Automation Control

+    0x00,  // PKTCTRL0            Packet Automation Control

+    0x31,  // MDMCFG2             Modem Configuration

+    0x12,  // MDMCFG1             Modem Configuration

Here are details of register changes:

SYNC is set to 0xCD4D.

PKTLEN is set to 0x0B, which is 11 bytes.

PKTCTRL is Normal mode, CRC disabled, Fixed packet length mode, whitening off, No address check, no preamble quality estimator threshold.

MDMCFG2 is:

DEM_DCFLILT_OFF 0 = Enable (better sensitivity)

MOD_FORMAT 3 = ASK/OOK

MANCHESTER_EN 0 = Disable

SYNC_MODE 1 = 15/16 sync word bits detected

MDMCFG1:

FEC_EN 0 = Disable

NUM_PREAMBLE 0 = 2 preamble bytes

CHANSPC_E 1 = 2 bit exponent of channel spacing

When running the software, GDO2 never goes TRUE signifying a packet is a available.

Do these settings sound right? Does anything else need setting?

Should PQT be at least 1 to prevent matching any sync word? Should PQT = 0 cause CC1101 to return noise? (Which does not make sense since nothing is returned.)