Replies: 19 comments 30 replies
-
|
Yes, this will work. These should be the same kind of transmissions rtl_433 usually processes. Upload some samples (as zip) here and we'll take a look. You only need the decoder, everything from framing, demod to bit slicers is automatic. If you know the bitrate you can start with a flex decoder: try |
Beta Was this translation helpful? Give feedback.
-
|
I have a scoreboard controller with me to test. It is generating a signal at 433.517MHz with a deviation frequency of +/-45kHz. For this model, the data is being transmitted in bursts (there is RF silence between messages) and the data rate is 4800baud. I'm trying to decode using the command: % rtl_433 -f 433517000 -A -s 1000000 After a few seconds it starts to spit some decoded messages. The -X suggestion is: -X 'n=name,m=FSK_PCM,s=208,l=208,r=212992' The decoded data is showing some constant data followed by what seams random data. The s=208 and l=208 make sense (bit duration 208us is consistent with 4800baud). I don't know what the r parameter means. What I can add is that I know that there is some sort of preamble = [1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,0] that is working fine for me in my python decoder. The decoded message shows messages like this one:
Which is consistent with the preamble I just mentioned. May I ask what command should I use to generate the recordings? |
Beta Was this translation helpful? Give feedback.
-
|
-S unknown. |
Beta Was this translation helpful? Give feedback.
-
|
I was able to record samples at 500ksps. Time is running (around 02:00 or so and counting) and score is 01-02. |
Beta Was this translation helpful? Give feedback.
-
|
Note that |
Beta Was this translation helpful? Give feedback.
-
|
src/rtl_433 -s 500k -r ../signals/scoreboard/g004_433.517M_500k.cu8 -X 'n=name,m=FSK_PCM,s=840,l=840,r=21200' The sample signals are a little clipped. |
Beta Was this translation helpful? Give feedback.
-
|
And I dont really see any pattern. |
Beta Was this translation helpful? Give feedback.
-
|
Same output that I got, with changing values at the end of the data. In gnuradio I am able to read data with the devices next to each other and default RTL gain. |
Beta Was this translation helpful? Give feedback.
-
|
The decoder might be taking a couple of extra bits prior to the preamble. 2aaaaaaaa (0010 1010 1010....) should be aaaaaaaa (1010 1010...). The way I coded it was:
Can we force the preamble in the rtl_433 call? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, add |
Beta Was this translation helpful? Give feedback.
-
|
I'm definitely getting closer. There is a part of the data that is never changing, like a very large preamble. After that, the next digit might be an indication of which kind of value is being delivered. So: rtl_433 -f 433517000 -s 1M -R 0 -X 'n=name,m=FSK_PCM,s=208,l=208,r=212992,preamble={120}aaaaaaaaa5ba8c2dae8ca126480828' The result is still not readable, but it is changing every second (and stops if I stop the time), which is an indication that there is time data being transmitted. This is exciting. |
Beta Was this translation helpful? Give feedback.
-
|
I got the time. -s 1M -R 0 -X 'n=name,m=FSK_PCM,s=208,l=208,r=212992,preamble={20}04143' Result: {58}313730333377160 there is always a "3" as padding between data. In this example time is 17 minutes 03 seconds. Last part is checksum, and I'm afraid it will be hard to reverse engineer that part. I was able to decode the time in a couple of hours, while it took me literally a dozen of hours to find out manually. This looks so promising! Edit: the problem in the first data with the "aaaa" preamble is that there is a couple of extra bits that are shifted and it affects the whole decoded message. Choosing the right preamble seems to fix it. Edit 2: the right preamble seems to be some sort of 555 instead of aaa Edit 3: I was able to get the score too. |
Beta Was this translation helpful? Give feedback.
-
|
You can use bit bench to figure out the meaning of bits. Can you pin point where you found the score ? |
Beta Was this translation helpful? Give feedback.
-
|
MH, ML local 01 - 02 |
Beta Was this translation helpful? Give feedback.
-
|
The preamble I chose is just a way to trim the data and be able to read values, but it is not a preamble, which can be problematic. For instance, I realized there is a button in the controller to turn on the "horn" and it affects the 0->1 in this chosen preamble. I find hard to understand why there is so much static data generated by this controller... I guess there has to be some serial number and sport type or something like that. This specific controller is one of the simplest examples. It only works for football, so data is small and being transmitted at a low rate. Tried to run rtl_433 with all the decoders and this one and it is great to see how it is able to pick temperature sensors and the score board at the same time. I chose 1Msps. |
Beta Was this translation helpful? Give feedback.
-
|
There is in fact this sync word in the message. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's CRC-16, poly 0x1021, init=0. |
Beta Was this translation helpful? Give feedback.
-
|
Can you highlight the score also ? If we get that we can write a decoder. |
Beta Was this translation helpful? Give feedback.
-
|
{130}616d74650932404154303230323380f60 Highlighted: |
Beta Was this translation helpful? Give feedback.
-
I am trying to calculate it using different parts of the payload but I can't get the right result. |
Beta Was this translation helpful? Give feedback.
-
|
Use the whole payload. I.e. pseudo-code |
Beta Was this translation helpful? Give feedback.
-
|
I understood why there is so much invariable data in the messages. It is coded in ASCII.
AC means Time. If AT is sent, it means Score. This protocol was built by the scoreboard engineer, so it is highly non-standard stuff. Every brand, every model, every country will have different signal modulation, encoding, and it is highly possible that even the same manufacturer and model have protocol variations. By now I was able to decode a bunch of brands/models that are working near my city. For each new sport I try to build the decoder, so now I have been able to work with 10 different models or so. |
Beta Was this translation helpful? Give feedback.
-
|
https://crccalc.com/?crc=616d746509324041543032303233&method=crc16&datatype=hex&outtype=0 The XMODEM version is the correct CRC-16 of 616d746509324041543032303233 [80f6] |
Beta Was this translation helpful? Give feedback.
-
In BitBench? There is no CRC check or calculation in BitBench right now. It's planned ;) And given the preamble, sync, and CRC I'd say the controller uses a CC1101 or similar. That explains the "dumb" ASCII encoding. Radio bridges like the CC1101 make it too easy, "designers" without radio knowledge use them (poorly). |
Beta Was this translation helpful? Give feedback.
-
I might be able to open it and look for the radio transmitter (or transceiver). |
Beta Was this translation helpful? Give feedback.
-
|
If you a curious ;) Not really needed, but would be interesting to confirm. |
Beta Was this translation helpful? Give feedback.
-
|
It is this one: https://i.postimg.cc/RhGwhLrp/Whats-App-Image-2023-02-23-at-14-14-57.jpg https://www.sparkfun.com/datasheets/Wireless/General/RFM22.PDF |
Beta Was this translation helpful? Give feedback.
-
|
FYI, this is this particular scoreboard controller: https://i.postimg.cc/hh4MZYrr/Whats-App-Image-2023-02-23-at-13-27-33.jpg |
Beta Was this translation helpful? Give feedback.
-
|
That's a HopeRF RF22 as RFM22 module. It's even easier than a CC1101. @merbanan we had a request about RFM22 support (simple UART bridge) recently IIRC? |
Beta Was this translation helpful? Give feedback.
-
|
That was a HC-12 device IIRC. |
Beta Was this translation helpful? Give feedback.
-
|
Or this issue Somfy io-homecontrol |
Beta Was this translation helpful? Give feedback.
-
|
Ty. Oh, and looking at the RFM22 manual, we expect 0-4 bytes header and 0-1 byte length. This matches the packet, e.g. So there is the fixed prefix explained :) |
Beta Was this translation helpful? Give feedback.
-
|
To add more data: This BitBench shows AT (score), AC (time) and AL (brightness). Also, horn is always on, so instead of 2@ we can see 2A. The AL (brightness) message includes: If I have a decoder example to use as a starting point, I will be able to code some application level program in order to, for example, generate json data to feed the streaming software (vMix, OBS, or even ffmpeg). |
Beta Was this translation helpful? Give feedback.
-
|
The link has old data. You need to enter data, then click "Link to this data and format" to get the fresh data as link. |
Beta Was this translation helpful? Give feedback.
-
|
you are right, now it is fixed |
Beta Was this translation helpful? Give feedback.
-
|
One question: will it work with a continuous signal? This particular controller has TDD transceiver (hence the rf silences between samples), but most of them use constant transmission. Is the demodulator/decoder ready for this kind of signals? |
Beta Was this translation helpful? Give feedback.
-
|
First that is misuse of the SRD bands. Then we have rtl_433 that will segment the signal to a max length and then process it. So it will most likely work but some messages will be missed. But if there are constant repeats of the information then it will probably work in practice. |
Beta Was this translation helpful? Give feedback.
-
|
OK, we will try and see. I see some potential problems:
I have some recordings using gnuradio file sinks. Is there a way to read them in rtl_433? |
Beta Was this translation helpful? Give feedback.
-
|
I've been able to record a different scoreboard controller, from a different brand. 433.075MHz FSK 4800baud, continuous TX (EDIT: Frequency is 434.075MHz) The -X guess is: Which is consistent with the 4800baud. However, it seems like the demodulator waits for the whole buffer (very big) to be full before trying to decode bits. Was able to decode 1 big data packet. Right now I have no info about possible preambles or data, but what worries me is the ability or not to decode continuous transmissions... |
Beta Was this translation helpful? Give feedback.
-
|
Regarding legality: This is not 433.92 MHz (ISM / SRD) but LPD433 channel 41, which is legal in Spain for voice applications. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, edited the frequency, it is actually 434.075MHz. These frequencies are abundant in Spain when looking for RF scoreboard signals. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sitting next to this controller (in a pavilion during a game, I can't take it home) and the rtl_433 demodulator can't seem to find any signal. It is a FSK centered on 434.075, 4800baud, deviation frequency of about +/-6.5kHz.
The preamble has to be some sort of groups of 10000000001000000000... or very similar if IIRC. I'm trying rtl_433 -f 434075000 -A -R 0 Should I try anything different? |
Beta Was this translation helpful? Give feedback.
-
|
rtl_433 can work well with continuous signals. We might support that some day, but currently it won't give good results. |
Beta Was this translation helpful? Give feedback.
-
|
I understand. It was a coincidence that the controller that I had with me was using time division multiplexing and gave good results right away. Almost 100% of the controllers use continuous tx. |
Beta Was this translation helpful? Give feedback.
-
Hello!
I'd like to ask the community if this would be possible to do using the rtl_433 framework:
I successfully built a simple scoreboard decoder to read data from several scoreboard controllers for sports from different brands. I used gnuradio to build the demodulator and the decoder. The signals are typically 2FSK located around 433MHz or 868MHz, with baudrates of 4800 or 9600. The data is sent continuously or in bursts using packets of different lengths and payload depending on the data that is being transmitted.
As the protocols are not published, normally I take samples of the signals, use inspectrum to find patterns (like preambles), and build the decoder in gnuradio to capture raw data. Then I look for changes between what should be data (changes in the time, score, etcetera), and I build a decoder to get time, scores, faults... I did not program any of the checksums and the result is not robust.
This way I built a decoder for some brands that are common in my country (Spain). This is being used for live streaming purposes, basically connecting the device (currently a raspberry pi and an rtlsdr) via socket to a server that has the ability to overlay graphics to the video feed.
A scoreboard controller is not a sensor by any means. However, could rtl_433 be adapted easily to decode these types of signals?
What I would like to achieve by moving to rtl_433 would be:
What I can provide:
My knowledge of C is limited and I am not able to find where to start looking in the rtl_433 sources. For instance, I am able to find where the different decoders are written, but I can't find the demodulators. For me, it always starts with a preamble! But I can't find any in the sources.
If anyone finds this could be interesting or doable, please let me know.
Beta Was this translation helpful? Give feedback.
All reactions