Support of Klimalogg Pro Sensor

[riegelbrau]

Current Situation

In the current version the sensor [150]* Klimalogg from merbanan's rtl_433 project is not listed as supported. In the source code I see, that it has OOK_PULSE_NRZS modulation. From my running instance of rtl_433 I get these MQTT messages:

There I see MOD = ASK. Is this supported by rtl_433_ESP?

Proposed Change

Support the Klimalogg sensor like in rtl_433. The advantage is to get data from the following sensors:

• TFA Dostmann 30.3080.IT
• TFA Dostmann 30.3081.IT

In my home brewing environment I could then replace one instance of rtl_443 (for 868 MHz) by a LilyGo Lora 32 board for 868 MHz.

Additional Context

No response

[NorthernMan54]

ASK is similar to FSK so it is supported

The decoder is included within the source code, but it is listed as disabled here -

rtl_433_ESP/src/rtl_433/devices/klimalogg.c

Line 112 in 276bc2c

.disabled = 1,

The disabled flag was copied from the rtl_433 package - https://github.com/merbanan/rtl_433/blob/f23b80f7975ebb49242e4017aafed870c35e30d0/src/devices/klimalogg.c#L112

You could try flipping disabled to 0, and rebuilding. As it was disabled during the build process, and is the only device leveraging OOK_PULSE_NRZS I'm not 100% confident it will work, as the code would not have been exercised during testing. But give it a try, worst case is that you would need to undo it.

[riegelbrau]

How can I get a verbose log from rtl_433_ESP in the OMG console like this?

*WM: [1] AutoConnect
*WM: [2] ESP32 event handler enabled
*WM: [1] AutoConnect: ESP Already Connected
*WM: [1] STA static IP:
*WM: [2] setSTAConfig static ip not set
*WM: [1] AutoConnect: SUCCESS
*WM: [1] STA IP Address: 10.0.0.245
Registering protocol [1] "Akhan 100F14 remote keyless entry"
Registering protocol [2] "EMOS E6016 weatherstation with DCF77"
Registering protocol [3] "Nexus, FreeTec NC-7345, NX-3980, Solight TE82S, TFA 30.3209 temperature/humidity sensor"
Registering protocol [4] "Generic Remote SC226x EV1527"
Registering protocol [5] "Wireless Smoke and Heat Detector GS 558"

I tried several compiler directives without success. Help appreciated!

Regards, Christoph

[NorthernMan54]

It’s not wired to do that

the omg serial console uses a different logging library to achieve the web console

[riegelbrau]

I now understand, that the rtl log is going to the serial console, but where can I find a description of the compiler directives to trace the rtl_433_ESP activities inside OMG on my LilyGo 868 MHz board.

Regarding my issue I checked the source code and figured out, that the klimalogg protocol is in the copy sequence for OOK modulation, so it cannot be activated with FSK.
Next point ist, that the klimalogg.c file contains a OOK_PULSE_NRZS. If the statement above, that it might be a FSK modulation, is correct, would the code process it in an appropriate manner.

For debugging with my sensors I need some hints for tracing and debugging.

[riegelbrau]

Found the compiler directives in the ReadMe!👍

[NorthernMan54]

As I’m using the chipset signal demodulator for FSK and OOK, it is not feasible to receive both at the same time.

[riegelbrau]

I know that and I tried to create a binary with klimalogg being activated while FSK is activated, too.
What I mean is that you wrote

ASK is similar to FSK so it is supported
but from the code in signalDecoder.cpp the klimalogg device is in the memcpy sequence for OOK:

if (rtl_433_ESP::ookModulation) {
  ...
  memcpy(&cfg->devices[79], &kerui, sizeof(r_device));
  memcpy(&cfg->devices[80], &klimalogg, sizeof(r_device));
  memcpy(&cfg->devices[81], &lacrossetx, sizeof(r_device));
  ... }

So if I compile with OOK_MODULATION=false to get the OMG image compiled with FSK, because "ASK is similar to FSK", then the klimalogg device is not copied at all and cannot work.

May be I don't understand you right. Should I compile with OOK and the modulation code for ASK will nevertheless be activated?

I did so and I've got these results:

rtl_433_ESP(7): Average RSSI Signal -93 dbm, adjusted RSSI Threshold -84, samples 50000
rtl_433_ESP(7): Average RSSI Signal -93 dbm, adjusted RSSI Threshold -84, samples 50000
pulse_slicer_nrzs: Klimalogg codes [{740}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6]
pulse_slicer_nrzs: Klimalogg codes [{1083}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6db6db6dbedbdb6f6ffb7f6fbdeffb7bfedffffffffffffffffbfffedeffbfff7f7f6fffdfffffffeffbffc]
pulse_slicer_nrzs: Klimalogg codes [{1086}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6db6db6dbedbdb6f6ffb7f6fbdeffb7bfedffffffffffffffffbfffedeffbfff7f7f6fffdfffffffeffbffd8]
pulse_slicer_nrzs: Klimalogg codes [{1092}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6db6db6dbedbdb6f6ffb7f6fbdeffb7bfedffffffffffffffffbfffedeffbfff7f7f6fffdfffffffeffbffdb6]
pulse_slicer_nrzs: Klimalogg codes [{1110}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6db6db6dbedbdb6f6ffb7f6fbdeffb7bfedffffffffffffffffbfffedeffbfff7f7f6fffdfffffffeffbffdb6db6d8]
pulse_slicer_nrzs: Klimalogg codes [{1175}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6db6db6dbedbdb6f6ffb7f6fbdeffb7bfedffffffffffffffffbfffedeffbfff7f7f6fffdfffffffeffbffdb6db6dbdb7b6db7b6fb7f6c]
pulse_slicer_nrzs: Klimalogg codes [{1522}edb6dbfbfb6f6def6f6db6db7b7b7f7b6dbfb7f7b6f7f6dbedb6dedb6f6defb7f6dbdb7b6ffbfb6f7b6db6f7b7ffb7fedb6dbdb7f6db6fedbdfdb7ffb6dbfb7bfbdfdb6dfdb6db7f7bdfdb6db6dedbdb7b6fffdff6dfdbedbdbdb6db6db6db6dbedbdb6f6ffb7f6fbdeffb7bfedffffffffffffffffbfffedeffbfff7f7f6fffdfffffffeffbffdb6db6dbdb7b6db7b6fb7f6dbdfdedfffbfbdfdff6ffffb7b6dedfffb6db6f7bfb6db6df6db6dedbdbdb6db6dedb6fff6db6f7db7b6dff0]
Analyzing pulses...
Total count:  324,  width: 107.92 ms		(107925 S)
Pulse width distribution:
 [ 0] count:  215,  width:   63 us [57;84]	(  63 S)
 [ 1] count:   26,  width:  192 us [186;196]	( 192 S)
 [ 2] count:   59,  width:  127 us [120;133]	( 127 S)
 [ 3] count:   13,  width:  271 us [252;321]	( 271 S)
 [ 4] count:    8,  width:  392 us [320;451]	( 392 S)
 [ 5] count:    1,  width: 1724 us [1724;1724]	(1724 S)
 [ 6] count:    1,  width:  832 us [832;832]	( 832 S)
 [ 7] count:    1,  width:    0 us [0;0]	(   0 S)
Gap width distribution:
 [ 0] count:   26,  width:  256 us [256;261]	( 256 S)
 [ 1] count:    9,  width:  763 us [640;837]	( 763 S)
 [ 2] count:  115,  width:   63 us [59;73]	(  63 S)
 [ 3] count:   67,  width:  128 us [124;133]	( 128 S)
 [ 4] count:   38,  width:  192 us [190;196]	( 192 S)
 [ 5] count:   37,  width:  350 us [320;388]	( 350 S)
 [ 6] count:   25,  width:  497 us [444;579]	( 497 S)
 [ 7] count:    3,  width: 1154 us [1028;1284]	(1154 S)
 [ 8] count:    2,  width: 2468 us [2308;2628]	(2468 S)
 [ 9] count:    1,  width: 1924 us [1924;1924]	(1924 S)
Pulse period distribution:
 [ 0] count:   62,  width:  350 us [316;388]	( 350 S)
 [ 1] count:   10,  width:  839 us [708;899]	( 839 S)
 [ 2] count:   74,  width:  127 us [121;132]	( 127 S)
 [ 3] count:   66,  width:  192 us [187;200]	( 192 S)
 [ 4] count:   44,  width:  255 us [248;260]	( 255 S)
 [ 5] count:   48,  width:  498 us [444;580]	( 498 S)
 [ 6] count:   12,  width:  639 us [636;643]	( 639 S)
 [ 7] count:    3,  width: 1216 us [1090;1348]	(1216 S)
 [ 8] count:    2,  width: 1920 us [1853;1988]	(1920 S)
 [ 9] count:    2,  width: 2656 us [2624;2688]	(2656 S)
Pulse timing distribution:
 [ 0] count:  330,  width:   63 us [57;84]	(  63 S)
 [ 1] count:   64,  width:  192 us [186;196]	( 192 S)
 [ 2] count:  126,  width:  128 us [120;133]	( 128 S)
 [ 3] count:   59,  width:  281 us [252;327]	( 281 S)
 [ 4] count:   35,  width:  404 us [320;452]	( 404 S)
 [ 5] count:    2,  width: 1824 us [1724;1924]	(1824 S)
 [ 6] count:   17,  width:  543 us [451;644]	( 543 S)
 [ 7] count:    8,  width:  802 us [707;837]	( 802 S)
 [ 8] count:    1,  width:    0 us [0;0]	(   0 S)
 [ 9] count:    3,  width: 1154 us [1028;1284]	(1154 S)
 [10] count:    2,  width: 2468 us [2308;2628]	(2468 S)
 [11] count:    1,  width:    0 us [0;0]	(   0 S)
Guessing modulation: Non Return to Zero coding (Pulse Code)
Attempting demodulation... short_width: 63, long_width: 63, reset_limit: 64512, sync_width: 0
Unsupported

[riegelbrau]

I'm not sure if it's the right way to comment to a closed issue...
I have 6 of these sensors and their messages are well processed by the rtl_433 package since several years. With the actual version of RTL_433_ESP I made again many attempts to get them processed, but still without success.
The latest runs I made from my fork by compiling the OOK_Receiver program for my IilyGo board with the compiler option OOK_MODULATION=false and some debug settings. In addition I uncommented some existing log statements. I don't get any successful demods.
One thing I cannot find is the setting of the sample rate, like with the parameter -s in the RTL_433 package. The Klimalogg sensors need at minimum -s 1536K or even -s 2M to get all sensors transmissions. How can I change the sample rate?

[NorthernMan54]

Looking at the klimalogg.c file, it is OOK Modulation, so you need to use OOK_MODULATION=true. And as this library uses the lilygo board for signal demodulation, the sample rate is not an available setting. But there are other settings for OOK available here -

rtl_433_ESP/src/rtl_433_ESP.cpp

Line 240 in 91bd22a

if (ookModulation) {

You could try tweaking the various settings to see if it changes raw signal reception.

[riegelbrau]

I read the complete thread of this issue in https://github.com/merbanan/rtl_433/issues/965#issuecomment-587336700, where they are discussing back and forth, if it is OOK or ASK or FSK. While the project https://github.com/baycom/tfrec, where the input for the decoder came from, says it is FSK with NRZ(S).
I tested both variants and used the compiler directive MY_DEVICES to only have the Klimalogg decoder active. See my platformio.ini file:

[env:esp32_lilygo]
board = ttgo-lora32-v21 ; ~/.platformio/packages/framework-arduinoespressif32/variants/.../pins_arduino.h
build_flags = 
  '-DLOG_LEVEL=LOG_LEVEL_TRACE'
  '-DONBOARD_LED=LED_BUILTIN'          ; Onboard LED is GPIO 25 on the Heltec Board
; *** rtl_433_ESP Options ***
  '-DRF_MODULE_FREQUENCY=868.33'
  '-DRTL_DEBUG=4'           ; rtl_433 verbose mode
  '-DRTL_VERBOSE=0'          ; LaCrosse TX141-Bv2, TX141TH-Bv2, TX141-Bv3, TX141W, TX145wsdth sensor
;  '-DRTL_ANALYZER=true'
  '-DRTL_ANALYZE=0'
;  '-DRAW_SIGNAL_DEBUG=true'   ; display raw received messages
  '-DMEMORY_DEBUG=true'   ; display memory usage information
;  '-DSTACK_DEBUG=true'   ; display stack usage information
  '-DDEMOD_DEBUG=true'  ; display signal debug info
	'-DMY_DEVICES=true'		; subset of devices
;  '-DPUBLISH_UNPARSED=true'   ; publish unparsed signal details
;  '-DRSSI_THRESHOLD=12'         ; Apply a delta of 12
;  '-DMINRSSI=70'
;  '-DOOK_FIXED_THRESHOLD=0x50'  ; Inital OOK Threhold - Only for SX127X
  '-DAVERAGE_RSSI=5000'     ; Display RSSI floor ( Average of 5000 samples )
  '-DSIGNAL_RSSI=true'             ; Display during signal receive
  '-DOOK_MODULATION=false'       ; False is FSK, True is OOK
; *** RF Module Options ***
;  '-DRF_SX1278="SX1278"'   ; Heltec ESP 32 Module - module settings come from heltec_wifi_lora_32_V2/pins_arduino.h
;  '-DRF_MODULE_DIO0=26'    ; SX1276 pin DIO0
;  '-DRF_MODULE_DIO1=35'    ; SX1276 pin DIO1
;  '-DRF_MODULE_DIO2=34'    ; SX1276 pin DIO2
;  '-DRF_MODULE_RST=14'     ; pin to be used as hardware reset
  '-DRF_MODULE_INIT_STATUS=false'    ; Display transceiver config during startup
; *** Heltec module requires non-standard SPI Config ***
;  '-DRF_MODULE_CS=18'      ; pin to be used as chip select
;  '-DRF_MODULE_MOSI=27'
;  '-DRF_MODULE_MISO=19'
;  '-DRF_MODULE_SCK=5'
; *** RadioLib Options ***
 ; '-DRADIOLIB_DEBUG=true'
;  '-DRADIOLIB_VERBOSE=true'
  ; *** FSK Setting Testing ***
  ;-DsetBitrate'
  ;-DsetFrequencyDeviation'
  ;-DsetRxBW'
monitor_filters = default, log2file
monitor_port = COM6
monitor_speed = 921600
upload_port = COM6
upload_speed = 921600

When I ran OOK, I could see these lines in the logs:
pulse_slicer_nrzs: Klimalogg codes [{226}f6f6dedb7bfb6fedff6db7bdef6f6db7b6db6db6f7f6dfdefef6db6d8]
Uploading device-monitor-868.33-OOK-KL-241212-114749.zip…

While running FSK, these lines did not appear. So I added these lines in r_api.c:

But again I get no signal decoded.
device-monitor-868.33-FSK-KL-241212-141811.zip

I thought the sample rate of 2 Mhz might be mandatory, but you say this cannot be set on the Lilygo board...
Can I do anything more?

Regards, Christoph
PS: Can you re-open this issue, please?

[NorthernMan54]

With this project we are relying on the sx127x chip to do signal demodulation, where as rtl_433 does signal demodulation in software.

We then pass the demodulated signal to the device decoder, to decode the signal.

So when you set the OOK_Modulation define, you are telling the SX127x chip to run in that mode.

and this is where the sampling rates etc apply.

To take this further, it would need someone with access to the actual device, and they would then need to fine tune the sx127x settings for the device. The fine tuning would include adjusting the register settings in the code, to identify the correct settings.

The actual receiver logic in the code base is pretty simple, it watches a pin for changes in signal level and records the gap between signal level changes. This data is then sent to the device decoder.

Personally I can’t take this any further.

[riegelbrau]

Thanks for this background info!

I'd like to share my findings from some web resources and some further tests.

In the tfrec project I found this comments in the code for Klimalogg sensor 30.3180.IT: https://github.com/baycom/tfrec/blob/master/tfa1.cpp:

// Protocol for IT+ Sensors 30.3180.IT, 30.3181.IT, 30.3199
// "KlimaLogg Pro"
//
// FSK - modulation
// NRZS (*not* NRZ!)
// 0: toggle frequency  (deviation > some limit)
// 1: do not toggle frequency
// Bitrate ~38400bit/s -> @ 1.535MHz -> 40 samples/bit, @ 4x decimation -> 10 samples/bit
// Training sequence >150 '0'-edges
// Bytes transfered with LSB first
// Ten bytes total (inkl. sync)
//
// Telegram format
// 0x2d 0xd4 ID ID sT TT HH BB SS 0x56 CC
// 2d d4: Sync bytes
// ID(14:0): 15 bit ID of sensor (printed on the back and displayed after powerup)
// ID(15) is either 1 or 0 (fixed, depends on the sensor)
// s(3:0): Learning sequence 0...f, after learning fixed 8
// TTT: Temperatur in BCD in .1degC steps, offset +40degC (-> -40...+60)
// HH(6:0): rel. Humidity in % (binary coded, no BCD!)
// BB(7): Low battery if =1
// BB(6:4): 110 or 111 (for 3199)
// SS(7:4): sequence number (0...f)
// SS(3:0): 0000 (fixed)
// 56: Type?
// CC: CRC8 from ID to 0x56 (polynome x^8 + x^5 + x^4  + 1)

// real samplerate 1536kHz, after 4x-decimation 384kHz

This shows a bitrate of 38.400 kbit/s, while the actual code of rtl_433_ESP.cpp has 17.24 kbit/s. I changed it in my fork to 38.4:

and ran some tests. Unfortunately nothing changed, I get no succesful decodings.

As I don't have any knowledge of radio frequencies, I tried to find some hints regarding sample rate and found this picture in the SIEMENS community https://community.sw.siemens.com/s/article/digital-signal-processing-sampling-rates-bandwidth-spectral-lines-and-more:

If the bandwidth in the frequency domain is half the size of the sample rate, the Klimalogg sensor would need a bandwidth of at minimum 750 kHz corresponding to a sample rate of 1.5 MHz or better 1 MHz for a 2 MHz sample rate.

This table in SEMTECH's datasheet of the SX127x module shows a mximum bandwidth of 500 kHz:

If my conclusion is correct, it looks as if the receiver module cannot read the Klimalogg sensor. May be, someone can check that and tell me, if I am right.