What does HackerNews think of rtl_433?
Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
Less fun because nothing can be build, although the transmitted data conforms to standards and can be processed with for example https://github.com/merbanan/rtl_433. So one can gather all data with a simple dongle and process that with a RPi.
Those fancy weather stations often transmit to the indoor LCD display using fairly simply messages sent in the 433 MHz band or the 915 MHz band. For many those message formats have been reverse engineered and decoders for them added to open source SDR software such as rtl_433 [1].
With a $30 USB RTL-SDR and rtl_433 you can then use the sensor units from many of those fancy units as inputs to your own display and analysis software. And you can often use your neighbors' sensors too. One of my neighbors--I still haven't figured out which--has an AcuRite 5-in-1 system and I can see its readings using my RTL-SDR and rtl_433.
If you build your own sensors it is cheap and easy to add a 433 MHz transmitter and define your own message format. Rtl_433 can be extended to cover new message formats by giving it a config file that describes the formats.
There's a driver for Weewx to let it use rtl_433 [3].
You can get an RTL-SDR and rtl_433 now, and start playing around with whatever sensors others in your neighborhood happen to have.
[1] https://github.com/merbanan/rtl_433
[2] https://www.acurite.com/shop-all/weather-instruments/weather...
Yep, that technology is called ANPR - automatic number plate recognition. Outputs a license plate, state, date/time, and gps coord of scanner.
> They also pick up the unique IDs from the wireless air pressure monitor chips in your tires.
That's called TPMS, tire pressure monitoring system. There is 1 device per tire, which emits temp, pressure, serial#, and other data. You can decode this for yourself with https://github.com/merbanan/rtl_433 and a RTL-SDR.
https://github.com/merbanan/rtl_433
It works okay: it drops around 10% of the data due to reception issues, but I think it might be related the parameters I have set for the gain on the software defined radio.
{"time":"2022-08-03 08:25:13","model":"Schrader","type":"TPMS","flags":"ab","id":"555551E","pressure_kPa":267.5,"temperature_C":57.0,"mic":"CRC"}
{"time":"2022-08-06 04:53:23","model":"Schrader","type":"TPMS","flags":"d5","id":"2F656AA","pressure_kPa":585.0,"temperature_C":120.0,"mic":"CRC"}
{"time":"2022-08-06 06:15:29","model":"Schrader","type":"TPMS","flags":"af","id":"4BAAC5B","pressure_kPa":227.5,"temperature_C":35.0,"mic":"CRC"}
{"time":"2022-08-08 10:24:43","model":"Schrader","type":"TPMS","flags":"af","id":"553AAD5","pressure_kPa":232.5,"temperature_C":120.0,"mic":"CRC"}
{"time":"2022-08-08 10:35:39","model":"Schrader","type":"TPMS","flags":"5a","id":"AAB8576","pressure_kPa":452.5,"temperature_C":43.0,"mic":"CRC"}
{"time":"2022-08-08 10:58:22","model":"Schrader","type":"TPMS","flags":"ad","id":"6FF5667","pressure_kPa":427.5,"temperature_C":56.0,"mic":"CRC"}
{"time":"2022-08-09 21:34:49","model":"Schrader","type":"TPMS","flags":"6a","id":"BAD22B2","pressure_kPa":212.5,"temperature_C":132.0,"mic":"CRC"}
{"time":"2022-08-09 23:31:35","model":"Schrader","type":"TPMS","flags":"6a","id":"AB5E5B6","pressure_kPa":545.0,"temperature_C":163.0,"mic":"CRC"}
{"time":"2022-08-10 16:49:55","model":"Schrader","type":"TPMS","flags":"57","id":"B56AED6","pressure_kPa":427.5,"temperature_C":36.0,"mic":"CRC"}
{"time":"2022-08-11 00:58:24","model":"Schrader","type":"TPMS","flags":"ab","id":"DF44AAB","pressure_kPa":452.5,"temperature_C":187.0,"mic":"CRC"}
{"time":"2022-08-11 01:36:15","model":"Schrader","type":"TPMS","flags":"aa","id":"AB55552","pressure_kPa":432.5,"temperature_C":35.0,"mic":"CRC"}
{"time":"2022-08-13 08:27:24","model":"Schrader","type":"TPMS","flags":"54","id":"5555553","pressure_kPa":425.0,"temperature_C":120.0,"mic":"CRC"}
{"time":"2022-08-16 10:48:29","model":"Schrader","type":"TPMS","flags":"aa","id":"B552AAA","pressure_kPa":425.0,"temperature_C":123.0,"mic":"CRC"}
Even aside from the obvious things like carrying around and using apps on a cell phone, it's amazing to realize how much information everyone leaks just going about their day. I've not investigated anything about how frequently or reliably these signals are sent, but it does seem feasible this could get used for vehicle presence detection or even short-range tracking.
[0] https://github.com/merbanan/rtl_433
[1] https://github.com/merbanan/rtl_433/blob/master/src/devices/...
https://github.com/merbanan/rtl_433
I now have my electric, gas, and water readings going into Home Assistant - the hardest part of setting this up was figuring out which meter serial numbers were mine, and which belonged to my neighbors.
Most wireless weather stations use ISM bands, I used RTL_433[1] to pull the raw data and quite a few popular stations already have the format documented.
Combine with InfluxDB+Grafana+simple polling script/program and you can do a bunch of fun stuff with it. Have the whole thing wrapped with docker compose and just runs in the backgound.
Side effect is that it also logs the tire serial numbers of most (but not all) cars pulling into my driveway.
The transmit side is pretty easy. Here's the xmit.ino file from my rain gauge project [1].
The receive side using one of those typical 433 MHz receive modules looks like a complete pain in the ass. I spent a while with the transmitter and receiver both on a breadboard hooked up to my oscilloscope, one channel on the transmit data in signal, one channel on the receiver data out signal, and one channel on the receiver receiver linear out signal.
Triggering on transmit and looking at the receiver output it didn't look too bad. But triggering on receiver output it was terrible. It was almost always outputting a mostly random looking stream of 1s and 0s of variable lengths. You have to watch that and look for things you recognize embedded in it.
Triggering on the linear output was more promising. My understanding is that the way these cheap receivers work is that they automatically adjust the gain until they are seeing something, so when you aren't actually receiving a signal they are just amplifying noise. When you actually are receiving a decent transmission the gain turns down. When that transmission ends the gain goes back up. (This, I've read, is one of the reasons most transmissions start with a long intro pulse before going into the actual bits. It gives the receiver a chance to turn down the gain so that it won't be including a lot of noise in the output).
The linear out signal is analog. It is higher when receiving a strong signal, and lower when receiving a weak signal or ambient noise. So it looks like using the linear out signal to decide when it is worth looking at the digital out to check if your device is being received could considerably cut down the processing needed at the receiver. By adjusting the trigger level on the scope I could get it to usually only trigger when an actual device that I can get a decent signal from was transmitting.
The good news is that you can say "to heck with all that" and cheat like I did. Forget the 433 MHz receive modules. Cheap SDR dongle on the receiving computer, rtl_433 [2] to do all the work of finding and decoding the signals among the noise, and you are all set plus as a bonus you can also see other 433 MHz sensors that happen to be in your area.
PS: if anyone looks at that transmit code and wonders why there is no checksum that is because I haven't gotten around to adding one. It is a tipping rain gauge and according to models I found for my area at my state's department of transportation site at the highest short term (5 minute) intensity that I would expect to see on average once per 100 years it would be tipping at 10 tips a minute. Thus the tip count should be an increasing sequence that when it changes mostly should change by 1, and rarely by more. It is easy to spot when the data is corrupt and so I've not found much need to add a checksum. I'll do that when I add my wind speed and direction sensors).
(Departments of transportation are good places to look for rainfall models for an area because their engineers need them to figure out how much runoff they have to deal with when designing drainage for road projects).
I use this wireless fridge/freezer thermometer [1]. The units that go in the fridge and freezer communicate with the display unit via 433 MHz RF.
I have an RTL-SDR [2] on the RPi.
I run rtl_433 [3] on the RPi. rtl_433 understands the protocols of a large number of wireless sensors, including the ones used by those AcuRite sensors.
I've got it configured to output whatever sensor data it decodes in JSON format to a file, and a script that periodically parses new entries from that file and records in an sqlite DB the readings from the sensors I'm interested in.
Rtl_433 is a fun program. It recognizes and decodes the transmissions of a lot of things. It is getting several neighbor's wireless thermometers and humidity sensors, a soil moisture sensor, several different car tire pressure sensors, a smoke detector, some kind of keypad (wireless lock?), a car remote, some kind of energy monitor, a rain gauge, and a wind speed/direction sensor.
[1] https://www.amazon.com/gp/product/B004QJVU78/
The transmit module uses a few mA when transmitting. I don't know what it uses when just sitting idle--probably very low but if not just don't give it power except when transmitting. Its maximum current draw is below is below what a GPIO pin can supply on an Arduino, RPi, and microcontrollers such as the ATtiny, so you could probably just hook its Vcc pin directly to a GPIO, hook its DATA IN to another GPIO, hook up ground and (optionally) add an antenna, and you are all set.
Lets say you can send at a rate of 2400 bits/second, and you need to send 400 bits every minute. That's 10 seconds of transmit time per hour. If it draws 10 mA while transmitting, that's 0.028 mAh or 0.14 mWh if you are using a 5 V system. A rechargable NiMH battery has about 2000 mWh capacity, which should power the transmitter for around 600 days.
For receiving you could use the corresponding module, but that is a bit of a pain. The way the transmit side works is that it has an oscillator running at 433.92ish MHz, and a transistor controlling whether or not the output of that oscillator is fed to the antenna. The DATA IN data controls that transistor.
If DATA IN is 1, the module transmits. If DATA IN is 0, the module does not transmit. The typical way this is used is to use this to send a series of pulses. You might encode a 1 message bit as pulse of T usec followed by no transmission for T usec, and a 0 message bit as a T usec pulse followed by 2T usec of silence. Or you might do a 1 as a pulse of 2T followed by silence of T, and a 0 as a pulse of T followed by 2T of silence. There are other ways, but those two are pretty common. (And you might use longer pulses to mark starts of messages or ends of messages).
The receiver module just monitors 433ish MHz and outputs a 1 on its DATA OUT when it thinks someone is transmitting and a 0 when it thinks no one is transmitting. The thing is it automatically adjusts the gain to where it almost always sees something even though it is usually noise. So what you see from the receiver's DATA OUT is an almost constant stream of 1 and 0. You need to look at that, and try to find in that sections that match what your transmitter sends.
If where you want to actually deal with the received data is an RPi or a desktop computer or similar, a simpler approach is to get an RTL-SDR dongle and the program rtl_433 [5]. From the description:
> rtl_433 (despite the name) is a generic data receiver, mainly for the 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands.
...
> It works with RTL-SDR and/or SoapySDR. Actively tested and supported are Realtek RTL2832 based DVB dongles (using RTL-SDR) and LimeSDR (LimeSDR USB and LimeSDR mini engineering samples kindly provided by MyriadRf), PlutoSDR, HackRF One (using SoapySDR drivers), as well as SoapyRemote
It already knows about nearly 200 sensors and devices. Find a device it already supports that is similar to what you are doing, and use that as a model to add a decoder for your device.
[1] https://www.sparkfun.com/products/10534
[2] https://www.sparkfun.com/products/10532
[3] It is a very popular band for a ton of consumer devices. In my fairly low density neighborhood, I can pick up at least 5 temperature or temperature/humidity sensors from various home weather stations, the sensors from someone's AcuRite 5-in-1 weather station [4], the tire pressure sensors from several cars, someone's power use monitor, a soil moisture sensor, and some sort of remote button or keypad.
[4] https://www.weathershack.com/product/acurite-06004m.html
On RPi side I only had to get an RTL-SDR receiver and run https://github.com/merbanan/rtl_433 on the RPi itself to decode the data.
It was significantly cheaper than going with BLE or WiFi sensors.
[1] https://www.banggood.com/USB2_0-FM-DAB-DVB-T-RTL2832U-R820T2... [2] https://github.com/merbanan/rtl_433
https://github.com/antirez/dump1090
[1] https://github.com/shaunhey/ea_receiver [2] https://github.com/bemasher/rtlamr [3] https://github.com/merbanan/rtl_433
[1] ##rtlsdr [3]
[2] https://github.com/merbanan/rtl_433
[3] Which I'm running a small fundraiser for, http://igg.me/at/rtlsdr