Replies: 2 comments 2 replies
-
State of things is to analyze and document as much as possible about a signal, then open an issue to request hints and tips. Some place to collect samples in volume and take a stab at decoding would be great. We have most of the tools for that too. But storage and bandwidth might be considerable cost factor, I guess. Your example is TPMS for sure. PWM only looks at pulses and I'd guess there is gap length of 50 and 100 too. Grab with FSK_PCM flex decoder and likely the data will be Manchester coded. A short comparison is at https://triq.org/rtl_433/PULSE_FORMATS.html As seen in that example there is no reliable way to go from an arbitrary signal to "bits". I would record with -S for a short time, pick out a promising signal, devise a good flex decoder, then repeat. Log the flex decoder output over a longer time and see what payload data shows up. One way to condense data might be to only process OOK format (that also covers FSK) files. There is not too much loss and a community driven recording and analysis might be easier. Try the OOK format with |
Beta Was this translation helpful? Give feedback.
-
There is now an example script to show sample file contents in the pulse data viewer at #2158 |
Beta Was this translation helpful? Give feedback.
-
Like to have a repository where unknown signals could be submitted to community intelligence.
Something like this (Signal identification Guide) but applied to 433 and 868 IoT devices as well as rtl_433 of course.
It's relatively easy to demodulate provided the modulation is not an alien one.
But once you have demodulated you're facing to bits and what do these bits mean?
That's the question.
I live in town and, of course, I have many 433 and 868 MHz signals around me.
Most of them are demodulated by rtl_433 but some are not.
Amongst these, some are regular, occurring every x minutes which indicates a weather station, a presence system, some are not which car indicates they are emitted by a car fob, a security trigger or even a TPMS on the street 30 m away.
That's relatively easy for me to know where the signal comes from since I have several Yagi antennas here and can play with the RSSI.
But once it's done ... what else?
For example I have the following recurrent signal that have been set unknown by the -S option.
It's maybe not so unknown because sometimes -S is lurred by noise or is puzzled by another signal.
But whatever, take this as an exercise.
Given the RSSI and the irregularity it is likely to come from a car passing by. But what is it?
The modulation seems to be FSK_PWM, short is 52, long is 104 and r is 208.
The demodulated value is 56 bits and here are some values I was able to catch: 0x2f69d9779ff3e0, 0x2f69d977bfeb9e, 0x2f69d977bfeb9c, 0x2f67f8addffbba, 0x2f7af75af7fdf7c, 0x2f69d9779ff3e0.
That's maybe something rtl_433 already decodes but I'm not able, for the moment, to run 2 rtl_433 at the same time, one being in auto mode and the other in -S mode.
My point is rather to try to establish, if not any, a common methodology to find what could be unknown signals given the environment in which it was recorded, its frequency (of occurrence), its demodulated value (if any), given what other signals it looks like, etc.
Thanks,
db
Beta Was this translation helpful? Give feedback.
All reactions