Hello, I try to receive wireless MBUS Telegrams e.g. from Smoke Detectors, Water Meters and Heat Cost Allocators. I war able to configure the CC1101 in the Examples according to the wMBUS specifications (see code below). I receive Telegrams successfully, but the Telegrams seem to be repeated within the Serial-Print?!

Is it not possible to receive longer Telegrams than xx Bytes? (32? 61? 64?) How can I adapt the library in order to receive longer telegrams?

Here is the code: `

include

const uint8_t WMBUS_T_CC1101_CONFIG_LEN = 47; const uint8_t WMBUS_T_CC1101_CONFIG_BYTES[] = { CC1101_IOCFG2,0x06, // GDO2 output pin configuration CC1101_IOCFG1,0x2E, // GDO1 output pin configuration CC1101_IOCFG0,0x00, // GDO0 output pin configuration //IOCFG0=0x02 (TX) or 0x00 (RX) CC1101_FIFOTHR,0x7, // RX FIFO and TX FIFO thresholds CC1101_SYNC1,0x3D, // Sync word, high INT8U // ACHTUNG! In anderen Skripts falsch herum! 0x3D CC1101_SYNC0,0x54, // Sync word, low INT8U // ACHTUNG! In anderen Skripts falsch herum! 0x54 CC1101_PKTLEN,0xFF, // Packet length CC1101_PKTCTRL1,0x0, // Packet automation control // original: 0x4, disable APPEND_STATUS //PKTCTRL1=0x4 !!!!!!! CC1101_PKTCTRL0,0x0, // Packet automation control CC1101_ADDR,0x0, // Device address CC1101_CHANNR,0x0, // Channel number CC1101_FSCTRL1,0x8, // Frequency synthesizer control CC1101_FSCTRL0,0x0, // Frequency synthesizer control CC1101_FREQ2,0x21, // Frequency control word, high INT8U CC1101_FREQ1,0x6B, // Frequency control word, middle INT8U CC1101_FREQ0,0xD0, // Frequency control word, low INT8U CC1101_MDMCFG4,0x5C, // Modem configuration // MDMCFG4=0x5C (RX:103 kbaud) or 0x5B (TX:100 kbaud) CC1101_MDMCFG3,0x4, // Modem configuration // MDMCFG3=0x4 (RX:103 kbaud) or 0xF8 (TX:100 kbaud) CC1101_MDMCFG2,0x5, // Modem configuration CC1101_MDMCFG1,0x22, // Modem configuration CC1101_MDMCFG0,0xF8, // Modem configuration CC1101_DEVIATN, 0x44, // Modem deviation setting // DEVIATN= 0x44 (RX: 38 kHz) or 0x50 (TX: 50 kHz) CC1101_MCSM2,0x7, // Main Radio Control State Machine configuration CC1101_MCSM1,0x00, // Main Radio Control State Machine configuration CC1101_MCSM0,0x18, // Main Radio Control State Machine configuration CC1101_FOCCFG,0x2E, // Frequency Offset Compensation configuration CC1101_BSCFG,0xBF, // Bit Synchronization configuration CC1101_AGCCTRL2,0x43, // AGC control CC1101_AGCCTRL1,0x9, // AGC control CC1101_AGCCTRL0,0xB5, // AGC control CC1101_WOREVT1,0x87, // High INT8U Event 0 timeout CC1101_WOREVT0,0x6B, // Low INT8U Event 0 timeout CC1101_WORCTRL,0xFB, // Wake On Radio control CC1101_FREND1,0xB6, // Front end RX configuration CC1101_FREND0,0x10, // Front end TX configuration CC1101_FSCAL3,0xEA, // Frequency synthesizer calibration CC1101_FSCAL2,0x2A, // Frequency synthesizer calibration CC1101_FSCAL1,0x0, // Frequency synthesizer calibration CC1101_FSCAL0,0x1F, // Frequency synthesizer calibration CC1101_RCCTRL1,0x41, // RC oscillator configuration CC1101_RCCTRL0,0x0, // RC oscillator configuration CC1101_FSTEST,0x59, // Frequency synthesizer calibration control CC1101_PTEST,0x7F, // Production test CC1101_AGCTEST,0x3F, // AGC test CC1101_TEST2,0x81, // Various test settings CC1101_TEST1,0x35, // Various test settings CC1101_TEST0,0x9 // Various test settings };

void setup(){

Serial.begin(115200);
Serial.println();
Serial.println("Start");

ELECHOUSE_cc1101.setSpiPin(14, 12, 13, 15);
if (ELECHOUSE_cc1101.getCC1101()) {
    Serial.println("Connection OK");
} else {
    Serial.println("Connection Error");
}
ELECHOUSE_cc1101.Init();
for (uint8_t i = 0; i < WMBUS_T_CC1101_CONFIG_LEN; i++) {
    ELECHOUSE_cc1101.SpiWriteReg(WMBUS_T_CC1101_CONFIG_BYTES[i << 1],
                                 WMBUS_T_CC1101_CONFIG_BYTES[(i << 1) + 1]);
}
ELECHOUSE_cc1101.SpiStrobe(CC1101_SCAL);
if (ELECHOUSE_cc1101.SpiReadStatus(CC1101_VERSION) != 4) {
    Serial.println(
        "WARNING! CC1101_VERSION should be equal 4! Is there any "
        "connection issue?");
}
ELECHOUSE_cc1101.SetRx();
Serial.println("device initialized");

ELECHOUSE_cc1101.setCrc(0);

Serial.println("Rx Mode"); }

int len = 0; String txt = ""; byte buffer[500] = {0};

void loop(){ //Checks whether something has been received. //When something is received we give some time to receive the message in full.(time in millis) if (ELECHOUSE_cc1101.CheckRxFifo(100)){

//CRC Check. If "setCrc(false)" crc returns always OK! if (ELECHOUSE_cc1101.CheckCRC()){

//Get received Data and calculate length len = ELECHOUSE_cc1101.ReceiveData(buffer); txt = "[" + String(len) + "]"; buffer[len] = '\0';

//Print received in bytes format. for (int i = 0; i<len; i++){ if ((String(buffer[i], HEX)).length() == 2) { txt += String(buffer[i], HEX); } else { txt += "0" + String(buffer[i], HEX); } } Serial.println(txt); memset(buffer, 0, sizeof(buffer)); txt = "";

} } } `

The telegram in the buffer for a smoke detector looks like: 5e442515180658010c1a48537a7500502584d6aa51170c6ba75ea2ee35949fd99dfc94ad8cad40cf07040121b2f92cda17e27549e869bb2da1345b9c2c5866b4b45e442515180658010c1a48537a7500502584d6aa51170c6ba75ea2ee35949fd99dfc94ad8cad40cf07040121b2f92cda17e27549e869bb2da1345b9c2c5866b45e442515180658010c1a48537a7500502584d6aa51170c6ba75ea2ee35949fd99dfc94ad8cad40cf07040121b2f92cda17e27549e869bb2da1345b9c2c586666b45e442515180658010c1a48

As you can see, the telegram repeats itself: 5e442515180658010c1a48537a7500502584d6aa51170c6ba75ea2ee35949fd99dfc94ad8cad40cf07040121b2f92cda17e27549e869bb2da1345b9c2c5866b4b4 5e442515180658010c1a48537a7500502584d6aa51170c6ba75ea2ee35949fd99dfc94ad8cad40cf07040121b2f92cda17e27549e869bb2da1345b9c2c5866b4 5e442515180658010c1a48537a7500502584d6aa51170c6ba75ea2ee35949fd99dfc94ad8cad40cf07040121b2f92cda17e27549e869bb2da1345b9c2c586666b4 5e442515180658010c1a48

A correct telegram looks like this: 5e442515485001000c1a7a23005025568aed71e43af834900bec738e08c4fa2637b8915fb401fd6296f19c3aeeceebc3164b967cd5445e6aafe90f416314191cb1839210b7cd2efe168911fd465dab56ccda9c82862b90f29353ab57532b49

I don´t understand the reason for this behavior. What I could find out by myself in the last couple of days is:

The CC1101 has an internal buffer with 64 bytes
If the buffer is full, it sets in an "overflow" mode and the buffer needs to be flushed
There are other librarys that mention a alimit in their sepcifications (send/receive of 64 Bytes only)
I tried different configurations e.g. infinite packet length which seems to have no effect on the above behavior

I would appreciate any help! Thanks in advance

LSatan / SmartRC-CC1101-Driver-Lib

Receive long(er) telegrams e.g. wMBUS - possible? (ESP32 + CC1101) #147

include