Add Klimalogg/30.3180.IT Support #965
Comments
|
Sure, I'll take a look. |
zuckschwerdt
added
the
todo
|
i would rename the issue title of baycom/tfrec#7 to better reflect the intention |
|
I've added NRZ-S decoding (cce293c) so support should be simple. Can you grab some (3-5) signals and add them along with a readme describing the sensor and the approx. grabbed values. S.a. https://github.com/merbanan/rtl_433_tests#contributing |
|
great. how to submit? should i fork into my own repo and then add that files and create a pull request - or better send via email to you ? (unsure, because seeing unmerged pull requests at https://github.com/merbanan/rtl_433_tests/pulls ) |
|
PR to rtl_433_tests is prefered. Some PRs there are pending on various updates and changes, but generally we always merge directly. |
|
devZer0 writes:
is there somebody willing on supporting adding support for these sensors?
I do have a working gnuradio receiver for this sensor:
https://github.com/anse1/klimalogg/
I tried getting it into rtl_433 but got frustrated when the ad-hoc
manual decoder was extremely sensitive to manual level adjustment for it
to keep synchronization. I might give it another try now that there's
more than one person interested…
regards,
Andreas
$ for f in *cu8; do ./rtl_433 -r $f -l 773 -X name=klimalogg,modulation=OOK_PCM,short=48,long=49,reset=65,match=0x55df755dd; done
Test mode active. Reading samples from file: g001_868.3M_1000k.cu8
time : @0.267816s
model : klimalogg count : 1 num_rows : 1 rows :
len : 553 data : fdd555555555555555555555555555555555555555555555555555555555555555555555555555555555df755ddff755fddf7d5775f555f5557d55557ddd5ddf55555555550
codes : {553}fdd555555555555555555555555555555555555555555555555555555555555555555555555555555555df755ddff755fddf7d5775f555f5557d55557ddd5ddf55555555550
Test mode active. Reading samples from file: g002_868.3M_1000k.cu8
time : @0.075392s
model : klimalogg count : 1 num_rows : 1 rows :
len : 553 data : fdd555555555555555555555555555555555555555555555555555555555555555555555555555555555df755ddfd755fddf7d5775f555f5557d55d57ddd77f755555555550
codes : {553}fdd555555555555555555555555555555555555555555555555555555555555555555555555555555555df755ddfd755fddf7d5775f555f5557d55d57ddd77f755555555550
Test mode active. Reading samples from file: g003_868.3M_1000k.cu8
time : @0.325256s
model : klimalogg count : 1 num_rows : 1 rows :
len : 553 data : fdd555555555555555555555555555555555555555555555555555555555555555555555555555555555df755ddff755fddf7d57fdf555f5557d55757dddf7df55555555550
codes : {553}fdd555555555555555555555555555555555555555555555555555555555555555555555555555555555df755ddff755fddf7d57fdf555f5557d55757dddf7df55555555550
|
|
For OOK_PCM with NRZ(S) short and long should equal, otherwise it's RZ-code. Also reset=65 says "if there is a 65 µs gap then end the packet" you rather want something like 480 there (for bursts of up to 10 equal bits). |
|
i collected testdata for klimalogg and have done a pull-request. isn't that a little bit too large binary repo? checking out >1gig for adding some megabytes is rather inefficient and afair, git is not made for storing large amounts of binary data |
|
Nearly 5000 files, each around 200KB. Git is still well suited for that (large files wouldn't be too good, many files are ok). Ideas anyone? |
|
We could rebuild the git. That should help getting rid of some history. But other then that the only way is to thin out the sample archive. One could try to check out a subset. But I'm not sure how that would work. |
|
I just tested recreating the repo and it isn't any smaller. We are mostly only ever adding stuff so that sounds about right. Even the over stuffed sample collections (the last lines there) don't weigh too heavy. Perhaps we could set up a mostly empty branch to pull (shallow clone) and commit to? Not sure how much hassle it would be to move the new commits. |
|
Note that for this signal the |
|
As far as I understood the code logic the demodulated signal is low pass filtered. Then 2 estimators of the low and high level needs to converge (the symbol threshold is then just the mid point between these levels). I think that is the hardest demand of this generic demodulator. These level estimators are just set by some initial heuristics that might not be optimal for this type of signal. How to make it better is not really clear to me but in theory because we have the complete signal we can analyse the complete signal in one pass to recover optimal parameters that we use in a second bit recovery pass. Maybe we need to move the problem to the the frequency domain. There was someone who did an OOK demod via fftw. |
|
I guess FFT would be really expensive. I made a note to look into wavelets for cheaper FSK, but so far I havn't delved into that. Also someday I want to try a FIR lowpass filter instead of the PD_MIN_PULSE_SAMPLES counter. For the estimators we can perhaps use a proper mean+variance band and better see where transitions are. That would apply to (non-gaussian) OOK only. For GFSK we probably need another detector -- measuring the direction/slope of the frequency shift looks more reliable than looking at the level. I'll try to finish the modularization soon, so people can mess around with (many) different detectors easily. |
|
Is there any news here? I would like to use the KlimaLOGG too. Apparently rtl_433 does not know the sensor yet. |
|
I am slowly working on a new FSK capable demodulator. If/when that is in place we will be able to better support more types of FSK signals. |
|
Thanks for this info, good to know. And thank you for writing such an useful application! |
|
Try with changing PD_MIN_PULSE_SAMPLES to 5. If that works we can start figuring out the payload structure. And try to record a clear set of sample signals. |
|
I gave up. Regardless of the gain settings, a lot of crap was received, sometimes with only one bit - even with a dummyload instead of an antenna. And even worse: Even with tfrec, which actually supports this device, no decode was possible. |
|
I am also interested in getting support for this sensor in rtl_433. I changed the PD_MIN_PULSE_SAMPLES to 5 but I could not see any noticeable difference in the output. I have six different sensors of which tfrec finds 4 continuously, one only occasionally (very rarely) and one not at all. However, they are all detected and displayed correctly by the KlimaLogg main unit. I can try to record some clean samples with different settings if there is still a need for that? |
|
Well adding a few signals (from each sensor) should be a fair contribution. |
|
Well, that motivated me to keep looking for it. I found the sensor 100kHz higher than expected. I collect the data soon. |
|
The samples in the samples repository are distorted. We now have a wip fsk demod that might work with this sensor. https://github.com/merbanan/rtl_433/tree/feat-fsk_demod_new |
|
How can I test this? (Sorry, if this is a dumb question. I am just getting started with rtl_433...) |
|
This signal is ASK modulated, not a FSK based one. Looks like a demodulator rework is needed to be able to decode this signal. |
|
@tophee nothing to test yet. |
|
This is highly suspicious. The tfrec project uses a FSK demod for this. The samples are all distorted, I need better samples before I do any further work. |
|
@zuckschwerdt I mainly prototype things in Octave. Anyway the tfrec code has this: ar = I[n] I'm not sure if it makes sense to do any further work. At least without the real sensor. And currently I'd rather work on enabling 2 fsk demods and some other parts that I need so I'm not sure sending a sensor to me is the best use of resources. The signal could be dual tone modulated. But this puzzles me much. We might have to look at the transceiver chip or ask an expert. |
|
That's a very fast phase difference estimator. But it's amplitude sensitive. So they are looking at the FSK. I can't seem to get anything from that. At least with the DC hitting samples. I wouldn't expect a OOK to be visible? Maybe an artifact of DC correction or such. We do need samples at lower gain and with a frequency offset. |
|
Ah, wait, with that crude estimation they (unintentionally?) do look at the OOK… |
|
The calling code calculates how many 1-bit duration's fit between the "OOK" pulses. I do the same in my code but this is unfiltered whole rtl_433 uses and IIR filter. cr=arbr+ajbj; -> i[n]*i[n-1] + q[n]*q[n-1] -> ~ I^2 + Q^2 That is the same as rtl_433 uses to demodulate OOK. For some reason that works, but looking at a frequency spectrum one can see 2 frequencies present. But looking at the waveform both frequencies are present at the same time at least when one of the bits are transmitted. |
|
If you use x[n] and x[n-1] then you are looking at (FSK) phase differences. If you want a (OOK) amplitude that's xr[n]^2+xj[n]^2, and for the magnitude it's sqrt(xr[n]^2+xj[n]^2). |
|
I know I just thought that at 1.5Ms that n~=n-1. But the difference might be 4. Anyway I figured out the signal. Octave code follows: This matches what is seen when looking at the signal visually. And it makes sense for this type of device. There is a carrier always transmitted at Y Hz when a one symbol is transmitted and 3*YHz+YHz (actually modulated 2 times) when a zero symbol is transmitted (with a slowly drifting phase). What can this be called, maybe OOK added with a carrier. From the Audacity frequency analyzer I get 555Hz on the lower frequency and 1670Hz on the high frequency. This confirms the frequency difference of 3 times. So what to do from here? |
|
The Hz values are from defauls of 44100Hz with working with Audacity. The times 3 factor should still be valid. And a PSK demodulator might work. Or high-pass filter and then a envelope detector. |
|
The plot is time vs. amplitude in the I (or Q) signal? I don't grasp how changing the carrier frequency affects the amplitude. Are the 0-amplitude parts the edges of the data or are they one of the bits? |
|
Well I only figured out how the signal was generated on the transmitter side. There is no amplitude changes in reality just this addition of a sine wave with a times 3 frequency. When you do an envelope estimation it doesnt match how we expect a transmission would look. A sin(x) is the modell we assume. The estimation recovers the A. And we have sin(x)+sin(3x). |
|
Ok, the above description might be wrong but not so far away, by looking at the signal there are parts that look like a pure sine wave and others that looks like a sine wave + sine wave at an offset. |
|
If you apply a band-pass filter to the offset signal (ie get rid of the carrier) it becomes very clear that the offset signal turns on and off (OOK). But how to do generic pulse recovery is highly unclear to me. Anyway gives almost the same pulse output. |
|
In the hope that this will be helpful, here are some more samples taken with varying gain settings via Setup and conditions where as follows. This was a place where no or minimal interference with other sensors should occur. There might be interference from other strong radio sources due to an airport nearby.
04c9 has no humidity sensor, only an external temp sensor. The Dostmann base station has reliable reception of all sensors except 0642, that is located in a very unsuitable place and is planned to be replaced with 04c9. Tests with 'tfrec' had serious trouble picking up the sensors which came as a surprise, as in another setup it produced quite good results . As 04c9 was so close, reception was only possible with -g 20. 081a could only be received in auto gain mode. I still wonder why there was no reception of 0cde at all. 0706 should technically be not that hard to receive, but there were no signs of it whatsoever. Terminal output for measurements was |
|
Can you redo it with -s 2560k? and also some samples with -s 1536k? |
|
I will not be in this place for some time. What I can do is take as many samples as needed here at my flat with only 2 sensors and a much noisier environment with some other sensors around. Will this help? What are useful gain values (3dB steps might possibly make more sense)? |
|
If you look at the samples we just don't want them to clip. To look at the samples use sigrok or audacity. And 2-3 samples will be enough but it would be nice with a high samplerate. |
|
Is this capture something useful? Not quite sure how to verify it Audacity and sigrok but the latter showed some binary signal...
New defaults active, use "-Y classic -s 250k" for the old defaults! Registered 122 out of 149 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 ] |
|
Great! The gain is good and the (time)resolution is enough to make out the actual sine of the carrier. It's really looks like the "second" frequency is a harmonic only. |
|
@zuckschwerdt what every it is, when I run the code on this sample it actually works because of the sample rate. So I'm guessing this will work with the current code if you use 2Ms/s as sample rate. As such I am inclined to add the decoder disabled with the note that you need a high sample rate for it to work. Later on when some one reworks the pulse recovery flow so it will be possible for several FSK algorithms we could also add other algorithms and the Klimalogg_demod.pdf is basically the output of unfiltered I^2+Q^2. Then it would be possible to run at 1Ms/s, it almost works right now. Is that an acceptable solution? |
|
Sorry to inform but my last sample may have been contamination from another, unknown device (may of course also be the sensor but now I'm not sure). I had a hunch when these samples came in at good quality, first try, that there is something going on. Sure enough, a quick nightly drive to the place where I usually collect samples (remote place, just one house close by) with sdr# and I got something on the same frequency as these sensors... But now that I have the mobile setup ready to go again, I can try to collect more samples if time permits. Is there something I should consider (in addition to check for contamination first this time)? I use the main version of the program, is that ok? Once again, sorry for the inconvenience... |
|
Well the samples we have now are enough to analyze the signal. The current suggestion will make it work in the near time and better in the future. Just need consensus to move forward. |
|
So wait with more samples for the time being. |
|
Sure, add the decoder disabled. I will look into why the carrier deviates and possibly the reason, might be interesting but will take time. The I^2+Q^2 is what we do already. But that amplitude emphasizes strong signals. Note that for CS16 (SoapySDR) the more refined magnitude is used (also to scale to a U16 range). Note that in any case both work: |
|
@zuckschwerdt if you look at the signal in some parts it looks like a sine wave that instead of going towards period max or min it changes direction. Klimalogg_signal.pdf is a synthetic period of it. I think it is quite clear that there is a constant carrier and an added OOK signal at an offset. If you run a high pass filter in between the frequencies you should see the OOK signal quite clearly. Anyway, I'll work on the PR. |
|
And here it is: Some one with real signals can check what samples rates are needed. |
|
Benjamin Larsson writes:
And here it is:
#1319
Thanks!
Some one with real signals can check what samples rates are needed.
I do have a sensor close by and it works reliably with 2.5MS/s. No
decodes at all with lower sample rates though.
,----[ rtl_433/src$ ./rtl_433 -s 2.5e6 -f 868.5e6 -H 30 -M hires -M level -d rtl_tcp:192.168.0.253:1234 -R 150 -v ]
| Registered 1 out of 150 device decoding protocols
| rtl_tcp connected to 192.168.0.253:1234 (Tuner: E4000)
| Sample rate set to 0 S/s.
| Bit detection level set to 0 (Auto).
| WARNING: Failed to enable automatic gain.
| Reading samples in async mode...
| Tuned to 0.000000.
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| time : 2020-02-28 19:53:52.221959
| model : Klimalogg Pro Id : 09d7
| Battery : 1 Temperature: 21.2 C Humidity : 48 Sequence Number: 10 Integrity : CRC
| Modulation: ASK Freq : 868.4 MHz
| RSSI : -0.1 dB SNR : 30.9 dB Noise : -31.0 dB
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| time : 2020-02-28 19:54:02.659226
| model : Klimalogg Pro Id : 09d7
| Battery : 1 Temperature: 21.2 C Humidity : 48 Sequence Number: 11 Integrity : CRC
| Modulation: ASK Freq : 868.4 MHz
| RSSI : -0.1 dB SNR : 23.5 dB Noise : -23.6 dB
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| time : 2020-02-28 19:54:13.096839
| model : Klimalogg Pro Id : 09d7
| Battery : 1 Temperature: 21.2 C Humidity : 48 Sequence Number: 12 Integrity : CRC
| Modulation: ASK Freq : 868.4 MHz
| RSSI : -0.1 dB SNR : 30.9 dB Noise : -31.0 dB
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
`----
|
|
Ok, I'll revise relevant comments and suggest the max sample rate for now. |
|
Ok, a working decoder has been merged. A high sample rate is needed. This is as good as it gets for the time being. |
|
Thank you for your time. |
is there somebody willing on supporting adding support for these sensors?
i have them running with tfrec but would like to see support in rtl_433 because it is a more capable tool.
rtl_433 does not seem to decoce anything...
i can provide any input... i have access to 5 sensors. could need some help. could also donate a sensor to the project if somebody likes...
The text was updated successfully, but these errors were encountered: