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?