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

[Whopper500]

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 <ELECHOUSE_CC1101_SRC_DRV.h>

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

[ebuyusufkaratas]

Hi, Have you made any progress?