Skip to content

Instantly share code, notes, and snippets.

@Taylor-eOS
Last active April 6, 2026 12:43
Show Gist options
  • Select an option

  • Save Taylor-eOS/0882416612accbeee27b064519ef4d35 to your computer and use it in GitHub Desktop.

Select an option

Save Taylor-eOS/0882416612accbeee27b064519ef4d35 to your computer and use it in GitHub Desktop.
Cheap Chinese CC1101 Modules
### Key Points
- **Modules Likely Functional but with Potential Issues**: The provided register readout shows a mix of values that partially align with CC1101 defaults, indicating SPI communication is occurring and the modules are responding. This rules out complete non-functionality or major wiring errors, but readings like PARTNUM=0xFF or VERSION=0xFF/0x0F suggest possible software misreads, counterfeit chips, or SPI protocol mismatches common in low-cost modules.
- **Common Problems with Cheap CC1101 Modules**: Research suggests many inexpensive Chinese CC1101 units may be counterfeits, remarked chips (e.g., similar to CC110L), or have manufacturing variances that affect SPI reliability, reception, or register accuracy. However, they often work for basic tasks if configured carefully.
- **SPI Reading Error Possible**: The 0x0F value may represent the chip's status byte (indicating states like IDLE with FIFO details) rather than the actual register value, pointing to a code mistake where the dummy byte isn't clocked for single-register reads.
- **Expected Values**: For genuine CC1101, PARTNUM should be 0x00, and VERSION typically 0x04 or 0x14 (depending on revision). Deviations could indicate fakes or read errors.
- **Next Steps for Bugfixing**: Verify the diagnostic script's read method, ensure proper reset (via SRES strobe), check SPI clock speed (keep under 6.5 MHz for stability), and test with known-good libraries like RadioLib. If issues persist, the modules might be incompatible counterfeits—consider sourcing from reputable vendors like TI or Adafruit.
### Wiring and Hardware Check
The pinout (VCC, GND, MOSI/GP19, SCLK/GP18, MISO/GP16, GDO2/GP14, GDO0/GP15, CSN/GP17) matches common E07-series or similar cheap modules, as confirmed by online images and datasheets. RP2040 (e.g., Raspberry Pi Pico) SPI0 pins are standard here, operating at 3.3V, which is within CC1101's 1.8–3.6V range. Ensure:
- VCC is stable at 3.3V with sufficient current (add a 100nF decoupling capacitor if not present).
- CSN is pulled high when idle and driven low only during transfers.
- No loose connections—since two modules give identical readouts, soldering isn't the culprit, but double-check for shorts or reversed MOSI/MISO.
### Register Readout Analysis
The diagnostic readout (0x00–0x2F) shows the configuration registers, which are readable via SPI burst or single accesses. Many values match or are close to power-on defaults from the TI datasheet, but discrepancies suggest either partial configuration by the script or non-standard chip behavior. Expected defaults assume a power-on reset (POR); if not reset, values may vary.
### SPI Protocol Reminder
CC1101 uses a standard 4-wire SPI (mode 0: CPOL=0, CPHA=0). To read a register:
1. Pull CSN low.
2. Send address byte: Bit 7 = 1 (read), Bit 6 = 0 (single) or 1 (burst), Bits 5–0 = address (e.g., for VERSION at 0x31: 0xB1 for single read).
3. During address send, MISO outputs a status byte (e.g., 0x0F could mean CHIP_RDYn=0, STATE=000 (IDLE), FIFO_BYTES=15).
4. Clock a dummy byte (0x00); MISO then outputs the register value.
5. Pull CSN high.
If the script skips the dummy byte, you'll read the status as the value—explaining 0x0F. For 0xFF, MISO might be floating high (pull-up issue) or the chip not driving the line due to power/state errors.
### Testing Responsiveness
- **Send Reset**: Issue SRES command strobe (address 0x30, write: 0x30) to ensure clean state.
- **Read Status Registers Correctly**: Use a library like RadioLib (Arduino-compatible, adaptable to RP2040) to verify PARTNUM/Version.
- **Basic Transmit/Receive Test**: Configure for simple OOK/ASK at 433MHz, send a packet, and monitor GDO0/GDO2 for activity (e.g., high on packet sent).
- **Tools for Verification**: Use an oscilloscope or logic analyzer on SPI lines to confirm MISO activity during reads.
If reads remain incorrect post-fix, the modules are likely non-functional counterfeits—common in cheap batches.
---
The CC1101 from Texas Instruments is a low-cost sub-1 GHz RF transceiver designed for low-power wireless applications in bands like 300–348 MHz, 387–464 MHz, and 779–928 MHz. It supports modulation formats such as 2-FSK, GFSK, MSK, ASK/OOK, with data rates up to 600 kbps and extensive hardware features for packet handling, FIFO buffering, clear channel assessment (CCA), and link quality indication (LQI). The chip operates on 1.8–3.6V, with receive current around 14–16 mA and transmit up to 34 mA at +12 dBm output.
#### Common Issues with Cheap Chinese Modules
Low-cost CC1101 modules (e.g., E07-M1101D, often ~$2–5 on AliExpress/eBay) are popular for Arduino/RP2040 projects but frequently reported as problematic. Key complaints include:
- **Counterfeits or Remarked Chips**: Many are relabeled older revisions or compatible parts like CC110L (simplified version with VERSION ~0x20) or even non-TI clones. These may fail to match datasheet specs, especially in RX sensitivity or SPI responses.
- **SPI Protocol Variances**: Some modules don't fully adhere to TI's SPI timing, leading to misreads. For instance, MISO may not drive properly if the chip isn't in IDLE state or if clock speed exceeds 6.5 MHz (max is 10 MHz, but lower for reliability).
- **Quality Control Problems**: Poor soldering, unstable crystals (e.g., 26 MHz XOSC drift), or inadequate antennas cause intermittent functionality. Users report modules working for transmit but failing receive, or vice versa.
- **Power and Noise Issues**: Insufficient decoupling or noisy power supplies can prevent the chip from entering active states, resulting in stuck reads like 0xFF (MISO high-Z).
- **Compatibility with Microcontrollers**: On RP2040, ensure SPI is configured correctly (e.g., via MicroPython or Pico SDK). Direct pin access might bypass hardware SPI, leading to timing errors.
Reports from forums (e.g., EEVblog, GitHub issues) highlight that ~30–50% of cheap batches are duds, but functional ones perform well for basic 433 MHz tasks like remote cloning or sensor networks. Alternatives like SI4463 or NRF24L01 are suggested for better reliability, though less flexible in sub-GHz.
#### Detailed Register Comparison
The diagnostic readout (likely a burst read of config registers post some init) vs. TI datasheet defaults (after POR). Matches suggest partial functionality; mismatches could indicate script writes, fake chip, or read errors. Table below compares key registers—full list for completeness.
| Address | Register Name | User Readout | Default (TI Datasheet) | Notes |
|---------|---------------|--------------|------------------------|-------|
| 0x00 | IOCFG2 | 0x06 | 0x29 | Mismatch; user value configures GDO2 differently (e.g., for packet sync). |
| 0x01 | IOCFG1 | 0x2E | 0x2E | Match; default GDO1 high-Z. |
| 0x02 | IOCFG0 | 0x06 | 0x06 | Match; temp sensor off, GDO0 for associated to packet. |
| 0x03 | FIFOTHR | 0x07 | 0x07 | Match; 33/32 byte FIFO threshold. |
| 0x04 | SYNC1 | 0xD3 | 0xD3 | Match; sync word high byte. |
| 0x05 | SYNC0 | 0x91 | 0x91 | Match; sync word low byte. |
| 0x06 | PKTLEN | 0x04 | 0xFF | Mismatch; user set to short packets (4 bytes). |
| 0x07 | PKTCTRL1 | 0x04 | 0x04 | Match; no address check, append status. |
| 0x08 | PKTCTRL0 | 0x04 | 0x45 | Mismatch; user disabled whitening/CRC, fixed length. |
| 0x09 | ADDR | 0x00 | 0x00 | Match; no device address. |
| 0x0A | CHANNR | 0x00 | 0x00 | Match; channel 0. |
| 0x0B | FSCTRL1 | 0x0C | 0x08 | Mismatch; higher IF frequency. |
| 0x0C | FSCTRL0 | 0x00 | 0x00 | Match; no freq offset. |
| 0x0D | FREQ2 | 0x21 | 0x10 | Mismatch; tuned for ~868 MHz vs. default ~433 MHz. |
| 0x0E | FREQ1 | 0x65 | 0xB1 | Mismatch; frequency adjustment. |
| 0x0F | FREQ0 | 0x6A | 0x3B | Mismatch; frequency fine-tune. |
| 0x10 | MDMCFG4 | 0x5B | 0x2D | Mismatch; wider channel BW, different data rate. |
| 0x11 | MDMCFG3 | 0xF8 | 0x3B | Mismatch; higher data rate mantissa. |
| 0x12 | MDMCFG2 | 0x73 | 0x73 | Match; Manchester off, MSK mod, sync qual. |
| 0x13 | MDMCFG1 | 0x22 | 0x22 | Match; FEC off, 4 preamble bytes. |
| 0x14 | MDMCFG0 | 0xF8 | 0xF8 | Match; channel spacing 200 kHz. |
| 0x15 | DEVIATN | 0x62 | 0x47 | Mismatch; larger deviation for MSK/FSK. |
| 0x16 | MCSM2 | 0x07 | 0x07 | Match; default RX timeouts. |
| 0x17 | MCSM1 | 0x30 | 0x30 | Match; CCA always, IDLE after RX/TX. |
| 0x18 | MCSM0 | 0x18 | 0x18 | Match; auto-cal on IDLE to active. |
| 0x19 | FOCCFG | 0x1D | 0x1D | Match; freq offset comp enabled. |
| 0x1A | BSCFG | 0x1C | 0x1C | Match; bit sync defaults. |
| 0x1B | AGCCTRL2 | 0xC7 | 0xC7 | Match; max gain, target amp 42 dB. |
| 0x1C | AGCCTRL1 | 0x00 | 0x00 | Match; default carrier sense. |
| 0x1D | AGCCTRL0 | 0xB0 | 0xB0 | Match; medium hyst, wait time. |
| 0x1E | WOREVT1 | 0x87 | 0x87 | Match; WOR event high byte. |
| 0x1F | WOREVT0 | 0x6B | 0x6B | Match; WOR event low byte. |
| 0x20 | WORCTRL | 0xF8 | 0xF8 | Match; WOR enabled, RC cal. |
| 0x21 | FREND1 | 0xB6 | 0xB6 | Match; front-end RX config. |
| 0x22 | FREND0 | 0x10 | 0x10 | Match; front-end TX config, PA 0. |
| 0x23 | FSCAL3 | 0xEA | 0xEA | Match; freq synth cal. |
| 0x24 | FSCAL2 | 0x2A | 0x2A | Match; high VCO. |
| 0x25 | FSCAL1 | 0x00 | 0x00 | Match; cal cap array. |
| 0x26 | FSCAL0 | 0x1F | 0x1F | Match; cal control. |
| 0x27 | RCCTRL1 | 0x41 | 0x41 | Match; RC osc cal. |
| 0x28 | RCCTRL0 | 0x00 | 0x00 | Match; RC osc cal. |
| 0x29 | FSTEST | 0x88 | 0x59 | Mismatch; factory test—don't modify. |
| 0x2A | PTEST | 0x31 | 0x7F | Mismatch; power test. |
| 0x2B | AGCTEST | 0x3F | 0x3F | Match; AGC test. |
| 0x2C | TEST2 | 0x07 | 0x88 | Mismatch; ADC/DAC test. |
| 0x2D | TEST1 | 0x03 | 0x31 | Mismatch; test config. |
| 0x2E | TEST0 | 0x0A | 0x0B | Near match; VCO sel cal. |
| 0x2F | (Reserved) | 0x00 | N/A | Not standard config register. |
**Analysis**: ~60% match defaults, suggesting the chip is CC1101-like but possibly configured (e.g., for 868 MHz, short packets) or a variant. Test registers (0x29–0x2E) mismatches are common in fakes. Status registers (PARTNUM 0x30, VERSION 0x31) aren't in your readout—focus debugging there.
#### Debugging Steps in Detail
1. **Software Verification**: Review your diagnostic script. Use burst read for config (address 0x00 | 0xC0 = 0xC0), single for status. Test with example code from TI SmartRF Studio (export to C/Python).
2. **Hardware Tests**: Measure MISO voltage during reads (should toggle). Add pull-up resistor (10kΩ) if floating.
3. **Alternative Libraries**: On RP2040, use Pico SDK SPI functions or MicroPython's machine.SPI. Libraries like PanStamp or ELECHOUSE_CC1101 handle quirks.
4. **Confirm Functionality**: Set to TX mode (STX strobe 0x35), monitor output power with an SDR (e.g., RTL-SDR) at configured freq. If no signal, chip may be defective.
5. **If Non-Functional**: Return modules or buy TI-evaluated boards (~$50). For alternatives, SI4432 offers similar features with better clone quality.
#### Broader Context on Counterfeits
Counterfeit RF chips are rampant in China-sourced parts; tests (e.g., current draw in power-down: genuine ~500 nA vs. fakes higher) can identify them. Forums like Reddit and GitHub report success rates improving with "blue PCB" modules vs. green. For critical apps, use TI direct.
**Key Citations**:
- [Texas Instruments CC1101 Datasheet](https://www.ti.com/lit/ds/symlink/cc1101.pdf)
- [CC1101 PARTNUM and VERSION Expected Values](https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/234400/cc1101-factor-programmed-unique-serial-number-mac)
- [CC1101 VERSION Register Interpretation](https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/370643/cc1101-version-register-interpretation)
- [SPI Read Always 0x0F Issue](https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/118780/cc1101-spi-read-always-0x0f)
- [Fake CC1101 Modules Discussion](https://www.eevblog.com/forum/beginners/cc1101-rf-transceiver-chip-issue/)
- [CC1101 Not Receiving on Chinese Modules](https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/670576/cc1101-cc1101-not-decoding-ook-rx-data)
- [Counterfeit RF Chips Identification](https://forum.mysensors.org/topic/6412/nrf24l01-genuine-vs-counterfeit-checked-some-modules)
- [CC1101 Glitch and Register Issues](https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/676973/cc1101-cc1101-glitch-bit)
- [Compatible Chips Overview](https://www.cdebyte.com/news/705)
- [SPI Debugging No MISO](https://www.reddit.com/r/ElectricalEngineering/comments/1lux2cz/spi_debugging_no_miso_signal_from_cc1101_register/)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment