rtl_watch: Real-time monitor and display of devices seen by rtl_433 #2409
Replies: 11 comments 23 replies
-
|
Thanks! Be sure to update the wiki ;) Also it could be interesting to calculate a "usual" transmit interval (the regular minimum when it's not immediate repeats) and then divide the count by that to show reliability. Maybe even with a trend? |
Beta Was this translation helpful? Give feedback.
-
|
OK, I'll go back and edit the README's to match your terminology. No, I wasn't suggesting that the transmission intervals depend on distance. I was suggesting that the reliability of receiving transmissions might. It was the standard deviation in gap times that I was looking at. Low (7-8 sec) for devices that I know are close, and 2-3 times that for things I don't think are close (judging from SNR). But that dependence of reliability on distance is just a conjecture. I'm trying to figure out what factors are indicative of distance from the receiver based just on the information collected by rtl_433. The only things I can think of to look at, over a sampling of many transmissions, are SNR and its standard deviation, record count, and inter-transmission gap timings and their standard deviation. For example, the oil-gauge sensors in my sampling above have very few transmission records, and I know them to be at least 300m away. The inter-transmission gap timing (for the one that has multiple readings) has a very high average AND a high standard deviation. And the SNR is is the single digits. If I didn't know that those gauges were far away, the data would suggest that. And maybe the answer is that you have to look at all three factors to judge relative distance.
Would_ that accomplish what you're suggesting? I've done some additional analysis of the data coming from that TX141THBv2 (the 845 transmissions described above). Most of the devices I've looked at in the past issue 3-6 packets for each transmission, to increase reliability. That TX141THBv2 consistently issued only one packet per transmission. The inter-transmission timings were consistently multiples of 50 sec (to within the second). But about 1/4 of the transmissions that might have been expected to have been sent were received. I'll need to do a similar analysis on other devices to figure out what number of multiples of basic transmission timings would be a reasonable threshold for issuing an alert and then warning, but it looks from this like a multiple of 5 might be reasonable. For this device, that would be about a 5 minute gap with no transmissions received. That seems pretty reasonable to me. But I have just a limited set of data to analyze. Does 5*basic rate seem reasonable to you? |
Beta Was this translation helpful? Give feedback.
-
|
I should have noted that I probably chose the worst device to do this analysis on! Most devices seem to issue several redundant packets per transmission to improve the chance that one of them would be broadcast without interference. I chose a device that issues just one packet per transmission (I was looking for a small record count). I wouldn't think the "missing" transmissions (100 or more sec gaps) would indicate unreliability of the device. Rather, I think it would indicate either poor signal quality (which the mean SNR would say is not the case) or a packet collision. So I think the TX141THBv2 is probably perfectly reliable as a device, but its transmission of just one packet per transmission interval makes it unreliable as a data source. So I'm thinking that the problem is not that the device didn't transmit but that the receiver didn't receive an ungarbled message. Are there other reasons for missing a transmission window that I'm not thinking of? It would be more typical for the device to issue multiple packets per transmission interval, and that might give a different threshold for number of intervals with no transmission received before deciding that the device has a problem. I'll try to do that with some data from that log file. |
Beta Was this translation helpful? Give feedback.
-
I created a "production" version of that Python SNR code that also computes statistics for the Inter-Transmission Gap Times. I've uploaded it to the rtl_snr github site along with updated SNR.py code and README. I have to say that I find the ITGT statistics not to be all that helpful. After some detailed analysis of the packets received from a couple of individual devices, then looking at the ITGT analysis of a 2-month JSON log file, I concluded that monitoring the ITGT finds a large number of spurious devices that have high gap times and high standard deviations for them, so the report is largely useless. And even for the devices that are close and reliable, the standard deviations of gap times are quite high. The best thing it does is give you a mean time for inter-transmission gaps, but the standard deviations are so high that I'm not sure you could monitor based on them. I've got some other experiments in mind to try to mine useful information out of the JSON logs that might convince me that there's a way to do this so that it might really be useful. But the ITGT analysis was pretty discouraging. If anyone else is interested in this issue, it would help me if you could run that SNR-ITGT.py code against some of your log files -- something with a week or month of data -- and let me know if anything useful pop out of the data for you. David |
Beta Was this translation helpful? Give feedback.
-
Have to stop for tonight, but wanted to share this from one of my rtl_433 logs, there is a bit of interesting stuff in here for me: |
Beta Was this translation helpful? Give feedback.
-
|
The added per-device pkt vs transmission info might be even more interesting. I found it curious that some Acurite devices send 1 packet per transmission and others appear to send 6. I keep being reminded not to make assumptions. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone who downloads and runs rtl_watch, I have a request: could you let it run for a while, then do a screen capture and post what your rtl_433 has seen? I live in a fairly compact and isolated neighborhood. So I have about 6 neighbors whose thermometers I see routinely. I occasionally see tire pressure gauges from delivery trucks. I even see a couple of fuel-oil gauges from homes that must be at least 300m from my home, since our neighborhood uses gas for heating and the nearest other neighbors are at least 300m away. I had originally intended to design that display window to be scollable, anticipating that the list of devices would be fairly long. It looks like the list might not be that long under regular use, and it looks like implementing a scrollable window with tkinter might be difficult -- and I'm not sure I can test it. So I could use some feedback as to whether a scrollable window is needed. Thanks in advance if anyone can help with that. |
Beta Was this translation helpful? Give feedback.
-
|
@hdtodd - This all looks very potentially very useful . I own a lot of RF devices in two different places and have spent a bit of time trying to track down loss of reception or interference over the years. Two thoughts of the top of my head: First, you might want to consider combining rtl_watch and rtl_snr (at least the python version) into one repo and possibly code base. Second, (for me) the GUI app isn't that practical for running for longer periods -- laptops go to sleep. I'd need to run it on a remote virtual X desktop that I'd access with VNC. A quick hack might be just writing the output to an HTML or JSON file which also contains some JavaScript to refresh the page or refetch the JSON. What would be most interesting (to me) In the long run with rtl_433 is no GUI, but just republishing this data to MQTT so I can use what ever I want to track and graph it over time. |
Beta Was this translation helpful? Give feedback.
-
I don't have much experience with these, so I appreciate feedback from someone who does. As I noted, I live in a compact community of 46 homes isolated from neighbors by at least 300m, so my scope is pretty limited. And I don't know how others use these devices, so I'm just developing code that I think might be interesting in my context. It's helpful to know other contexts. rtl_watch is a synthesis of code from rtl_snr (which I wrote first) and DNT, so much of the code is in common. I'm reluctant to combine rtl_watch and rtl_snr, but I'll give it some more thought as I deal with ongoing development and maintenance issues [ :-) ]. From the perspective of potential users and use cases, I think the two programs serve slightly different purposes. rtl_watch gives a quick snapshot of what's going on in your neighborhood ... likely to let it run for just a few hours to a day, I'd think. rtl_snr gives a summary of devices seen over days, months, or even years. I just ran rtl_snr on a 421MB, 2-month rtl_433 JSON log file with 622K de-duplicated records to see the range of devices my rtl-sdr/rtl_33 system has seen (many more than I thought!!!), but I wouldn't have run rtl_watch that long. But from the perspective of potential users of those two programs, rtl_snr has minimal requirements -- just basic Python libraries and an rtl_433 system running on the network somewhere, publishing packet information in JSON through mqtt. rtl_watch requires both tkinter and paho-mqtt be installed on the system, and while those are easy enough to install, it's another hurdle to getting the basic information a user might want. And possible library version skews and potential difficulty installing on non-Linux systems (all of which I've had) would seem to make a combined system less useful. And I admit that have always appreciated the Unix philosophy of providing a set simple tools that do one job and do it reliably. ;-) Yes, my Mac goes to sleep at night, so running rtl_watch on it overnight doesn't work. But I have a Pi that doesn't go to sleep at night, and I leave rtl_watch running on it to get a day's worth of data But I think I'm misunderstanding the point you've made. rtl_snr does the analysis of the JSON log files that can be kept on the rtl_433/mqtt-broker system. I've set that system up with logrotate to close the rtl_433 log file daily and zip it. If I want to analyze the log file over a longer period of time, I sftp the log file(s) for the period I want from the rtl_433 system to another system (generally my Mac) and do the analysis there with rtl_snr. What did I misunderstand about the way you would like to work? OK, I think you want rtl_snr for that. The README includes steps to set up systemctl and logrotate procedures for managing the rtl_433 logs so that rtl_snr analysis is pretty straightforward. If you don't want to tinker with your rtl_433 system, an easy alternative would be to set up, on a system that doesn't go to sleep, a process that subscribes to the rtl_433 mqtt publisher and saves the JSON packet information to a local log file. I hope that helps. Please explain the points I didn't understand correctly. David |
Beta Was this translation helpful? Give feedback.
-
|
About reliability: What I do in home assistant is to send an offline notification when I haven't heard for about 3.5x the normal interval. That doesn't measure reliability so much as disappearing (battery or weather usually). I don't think standard deviation is going to be the right measure. I would try to histogram the intervals and find the shortest interval that has a good peak and then basically after 1.2x that declare/count a missing transmission. To tune this I would just record the arrival times over a few days and then look at the histogram (perhaps binned to the second) and see what it looks like. Then, try to find a repeat interval and see if t0 + k * R fits the arrival times to see what the rate variation is. But that's just me being excessive perhaps. So more concretely, take the 100 most recent times, histogram the gaps within bins at maybe 1s granularity maybe 1.25x factors, and then the hard part find the shortest significant peak and call that the expected interval. Then it's no report after expected*1.2 that is meaningful. |
Beta Was this translation helpful? Give feedback.
-
|
Greg, The histogram a few messages back was my first attempt at this, but I think I need to pick a different device and run the analysis again with a device that issues 3-6 packets per transmission. In my prior notes I confused device reliability with data reliability: these discussions have helped clarify that distinction for me, and I'll try to be more careful in future notes. But looking at that histogram, 3.5x base inter-transmission gap timing would be 175sec. If I had implemented an alert system in rtl_watch, it would have issued 9 warnings for that device over the 15 hours of that log file. For that device, under those circumstances (not failing device; single packet per transmission; likely packet collisions preventing reception), a 5x factor might be more reasonable if you're trying to monitor for devices that have low batteries or are failing. But I need to go back and do the analysis for one of the other devices that broadcasts 3-6 packets per transmission. That'll help me understand better the characteristics of different devices and help me understand how the observed pattern of timings of transmissions as received can be used to identify failing devices vs indicating signal interference. David |
Beta Was this translation helpful? Give feedback.
-
|
I analyzed that same JSON log file for the data for "Acurite-609TXC 51" since it's my own thermometer, about 15m from the receiver, has a high SNR, and should represent a near-optimum case for analyzing device reliability vs data reliability and learning of any other anomalies in what would seem to be a standard manufactured device. It' relatively new, I think: about 18 months old. I The device JSON log file contained 8180 packets for that sensor: 2334 were unique transmissions (in which the time of reception was exactly the same, to the second) and 5846 were duplicate packets sent to increase the probability that the data represented in the transmission would be received ungarbled. The distribution of number of packets per transmission looks like this: I had been assuming that the transmitter always transmitted the same same number of packets per transmission, which would seem to be 6 in this case. But the actual distribution of packet count per transmission is so broad that I'm not sure that assumption is correct. It's not important for the analysis that rtl_snr or rtl_watch do, since they ignore duplicates anyway, but it's a surprising (to me) result. If it does always transmit 6 packets, then the reception in this near-optimum situation is pretty poor -- only 25% of those attempts were completely successful. Now, that 2334 number isn't precisely the number of de-duplicated packets. Since the JSON log reports time only to the integer second, some number of those non-duplicated packets are actually duplicates within rounding error of the time precision. For example, there were two records at time 00:01:42 followed by two records at 00:01:43 that contained the same temperature and humidity values. The de-duplicating algorithm in rtl_snr and rtl_watch would report those four records as one transmission, at time 00:01:42. Here is the distribution of number of transmissions vs inter-transmission time gap: Filtering out the packets with a 1- or 2-second time gap from the previous transmission yields 1660 de-duplicated records, close to the 1682 reported by rtl_snr and with SNR mean and standard deviations that match rtl_snr. I ascribe the 22-record discrepancy to similar issues in time-rounding and de-duplicating algorithm, but close enough to make more sense of the data. It seems clear that the sensor is intended to transmit at about a 33-second frequency, and 90% occur within 1 second of that target (plus or minus). But the inter-transmission isn't as precise as I would have expected ... there's some randomization. I went back to the original logs to confirm, for example, that there really was a spurious transmission -- single packet -- 4 seconds after a a prior one. I need to think about this a bit more, but I'm not sure how to determine device reliability based on inter-transmission gap timings given the variability I see in a device that is close and has a high SNR and low SNR standard deviation. But it is certainly the case that in this situation, a gap of more than 2x the target time of 33 seconds would be a good indicator -- for this device and proximity -- that something's wrong with the device. Maybe that's good enough for others who want that kind of alert. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
Very interesting read. We have never seen anything but 6-repeats transmissions from the Acurite 609. But see the 003 and lowbatt file here https://github.com/merbanan/rtl_433_tests/tree/master/tests/acurite/Acurite_609A1TX for common reception problems -- devices will regularly "shadow" each other. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for that reference. If I understood correctly, it looks like low-battery is signaled by a 1–>0 transition in the battery field and 2–>10 transition in the status field. On that Acurite, at least. It occurred to me overnight that if I modify rtl_watch to monitor for devices that seem to have disappeared — or at least to be failing to transmit according to their apparent frequency — then I might also monitor for transitions in battery and, with your example here, monitor for transitions in status. Transitions in either of those might be cause for warning or alarm, as would transmissions that seem to have been dropped. Does that seem right? Anything else that might serve as warning in the generic case? I haven’t looked carefully at battery and status fields across many devices, but my sense from casual observation more than a year ago was that there’s no “standard” for either of those fields across the variety of devices that broadcast on ISM. I think that the best I can do, as a remote observer possibly seeing many different devices, is to assume that a CHANGE in battery or status field would be a reason to raise a warning. I’d simply assume that the first value received is “normal” and any change should be warned about. Does that seem like a reasonable approach? David |
Beta Was this translation helpful? Give feedback.
-
|
Also, are “battery_ok” and “status” field values always integer in the JSON file, or are they sometimes text values (anything in “”)? The JSON unpacking module I’m using hiccups if the data type changes. |
Beta Was this translation helpful? Give feedback.
-
|
My example was to look at the spectrogram for those two transmissions (use https://triq.org/pdv/ ) -- both have overlapping other transmissions. We have these fields that should be regular: https://triq.org/rtl_433/DATA_FORMAT.html |
Beta Was this translation helpful? Give feedback.
-
|
Christian, Thanks for the field information ... that will help as I try to figure out other fields to monitor. And thanks for the demonstration of overlapping transmissions. I had seen things like this when I was first looking at the spectrograms a year ago or so. But I'm trying to figure out how those manifest in the rtl_433 JSON records, since those are what I'm processing with rtl_snr and rtl_watch. But your comment suggested that perhaps a couple of devices were walking all over each other, and I wondered how that might appear in the log file. So I went back to look at the details of the packets recorded by rtl_433 over a 2-minute period around the time of that 4-second inter-transmission gap time for my Acurite 609. There's some useful information there, but I'm having trouble making sense of it. Here's the log of transmissions in that period, summarized: The 4-sec Acurite 609 ITGT comes at 00:41:59. It coincides with the LaCrosse, which issued a transmission in the same second. So I looked back at 00:40:47-00:40:57, where there seem to be four packets at 00:40:47-48, and then an isolated one at 00:40:57 that also coincides with the LaCrosse transmission. The LaCrosse v3 has a transmission period of 31 sec. So there's a LaCrosse v3 transmission at 00:41:59 and again at 00:42:30: the one at 00:42:06 is an anomaly ... like the Acurite 609 at 00:41:59. Now, there's no Acurite 609 transmission at that 00:42:06 marker, but there is an Acurite Tower transmission of 3 packets at 00:42:07. I might have thought that the anomalous 00:42:06 LaCrosse v3 packet was a garbled Tower packet, but the Tower consistently sends 3 packets, and all 3 were received and recorded at that time. From your suggestion, I thought what I had seen was one device interfering with another. But it looks instead that devices occasionally send packets outside of their normal expected periodicity. I'm not completely convinced of that, since the anomalous transmissions were individual packets. But I don't think those anomalous packets are rtl_433 mistakenly interpreting noise or collisions as valid packets: the temp/humidity/id data are all consistent with prior and succeeding transmissions. I can only conclude that devices sometimes issue packets outside their expected regular period. I don't think that complicates monitoring ... receiving an extra transmission occasionally wouldn't be reason for an alert or warning. All this just reminds me that interpreting these is as much an experienced art as it is a science -- and reminds me not to assume too much without looking at the data. |
Beta Was this translation helpful? Give feedback.
-
|
Be careful not to assume that probability of reception is about SNR only. There are lots of things going on in ISM spectrum, and all components are far from ideal. The idea that "device reliability" and "reception reliability" are different is a good one. |
Beta Was this translation helpful? Give feedback.
-
|
If one has poor reception, then 3.5x nominal may alert more than you want. Note that battery status and stopping reporting are really not the same thing. I have devices that I use NiMH in and they always report low battery. |
Beta Was this translation helpful? Give feedback.
-
|
I'm thinking that 2x is an alert and 5x is a warning, based on my detailed Acurite 609 analysis. That device is close to the receiver (about 10m) and seems to blast 6 packets per transmission that are received pretty consistently. A 2x/5x threshold setting would have resulted in just two alerts and one warning over a 24-hour period. That 2x/5x setting would have resulted in a bunch of alerts and one warning for the LaCrosse-TX141THBv2 over the same period. I think that LaCrosse is no closer than 30m. So those 2x/5x thresholds for alert/warning plus monitoring "battery_ok" status changes would seem to be a reasonable starting point for trying this idea out. I'm thinking that alert would turn the text orange and warning would turn it red. Adjust the thresholds if they're too low. I think adding those as a command-line option to override defaults would give the most flexibility for individual situations. |
Beta Was this translation helpful? Give feedback.
-
|
Greg, ... and I'm thinking that I'd use a substantial change in battery status as the threshold for an alert or warning. Read as real, more than 0.nn change as basis for warning. Need to see if anything really reports that at a float, though, as I've only seen integers. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, Naming a device is a problem a number of rtl_433 consumers have. It looks like rtl_watch chooses to use Note: for some devices rtl_433 and the Home Assistant auto discovery script concatenate the fields For scripting and correlating across utilities, it would be good to have some consistency where possible. |
Beta Was this translation helpful? Give feedback.
-
|
And, of course, there are the devices for which the function code is reported in the id field ... I want that descriptor to be sufficient for someone to identify what it is and distinguish it from others, but not so long that it requires close attention to recognize it. So I'll go process a 2-month log file to see what those descriptors look like to consider alternative descriptor constructions. I can concatenate into one key the combination of fields present in the packet in the sequence type+model+subtype+channel+id, if that key doesn't get to be too long. What is a good separator for those fields in a concatenated string? Do you have some examples? |
Beta Was this translation helpful? Give feedback.
-
|
A slash or dot are safe separators, they are used in MQTT or TSDB (Influx). |
Beta Was this translation helpful? Give feedback.
-
Rob, Christian, I'm working through a list of issues with my rtl_snr and rtl_watch Python code. One of the issues is the identifier string I create to tag an individual device. My intention is to identify and consolidate information associated with an individual device and de-duplicate packets before recording statistics. The identifier is key to that. The identifier should be short enough to be quickly recognized but long enough to distinguish from similar devices in the neighborhood. I did a little research on Rob's suggestion of possible fields (type, model, subtype, channel, id) to see which ones I might meaningfully use. Only "model" is required out of that list, so I'll use it as the lead substring. Looking at both src/devices and at the records in my 2-month JSON log and a 2-day log from Rob, it looks like "type" is used for TPMS devices and Intertechno, and "subtype" is rarely used. I noted in both my data and Rob's that car/truck traffic tends to be transient -- one or two transmissions over a long collection period -- and don't contribute meaningfully to the data about neighboring devices. I intend to ignore TPMS transmissions by default but allow override by command line. So I plan to ignore "type" in creating the identifier. Similarly, "subtype" is rarely used, so I'm inclined to drop it. According to the FORMAT document Christian linked to, "id" seems to be the primary next identifying string with "channel" being the secondary. Looking at the data summarized from the JSON files, they seem to be used about equally. "id" seems frequently to be a function code or security check rather than device identifier. When present, "channel" seems to be a 1- or 2-character code whereas "id" is frequently a 4-, 6- or even 8-digit code. I'm planning to revise my Python code to use as the key device identifier: "model"/"channel"/"id" . "channel" and "id" can each be empty but the "/" separator will still be there (e.g., I'm afraid that this scheme doesn't do a good job of consolidating data about an individual device. I think it's likely that It's unfortunate that "id" is frequently a function code (apparently) since it causes what is likely one device to appear in my summaries as many devices, each with a different "id". But I can't see a way to avoid differentiating them. Thoughts? Am I missing any simple way of consolidating data for an individual device while correctly differentiating different devices? |
Beta Was this translation helpful? Give feedback.
-
|
Rob,
Thanks for sending this. v1.3.0 includes the per-device packet and
transmission counts, too.
A couple of interesting things in the (for me, anyway):
* Your SNR standard deviations are much lower than mine, and my three
primary remote sensors are about 10-15m away. Maybe my receiving
antenna is not well placed. I'll move it and see.
* You collect a LOT of data over 4 days!
* in your column header, the Greek letter "sigma" comes out as a
4-byte unicode. I had thought that Python's text code were
standardized across platforms. My apologies to all, but I don't
know how to fix that other than to replace the Greek "sigma" single
character with "Std Dev". or maybe just "SD". Did I misunderstand
what's going on here?
David
…On 3/7/23 8:08 PM, rct wrote:
I have to say that I find the ITGT statistics not to be all that
helpful. After some detailed analysis of the packets received from
a couple of
If anyone else is interested in this issue, it would help me if
you could run that SNR-ITGT.py code against some of your log files
-- something with a week or month of data -- and let me know if
anything useful pop out of the data for you.
Have to stop for tonight, but wanted to share this from one of my
rtl_433 logs, there is a bit of interesting stuff in here for me:
|Processed 161618 de-duplicated records Dated from Thu 2023-03-02
11:44:17 to Mon 2023-03-06 12:22:32 Signal-to-Noise Inter-Tranmssion
Gap Time _________________________________
______________________________________ Device #Recs Mean ± \U0001d70e
Min Max #Recs Mean ± \U0001d70e Min Max Acurite-01185M 0 19 5.8 ± 2.9
3.2 12.6 18 15317.4s ± 26243.9 279.0 104349.0 Acurite-515 1783 5401
12.3 ± 0.9 6.5 32.0 5400 64.4s ± 15.4 60.0 243.0 Acurite-515 5514 230
5.0 ± 1.3 2.7 13.4 229 795.1s ± 1715.6 61.0 15776.0 Acurite-5n1 130 1
6.9 ± 0.0 6.9 6.9 Acurite-986 4995 1 9.4 ± 0.0 9.4 9.4 Acurite-Atlas
924 3689 6.7 ± 1.8 1.8 30.5 3688 93.8s ± 969.7 10.0 49417.0
Acurite-Tower 12053 19951 12.2 ± 0.9 5.2 38.5 19950 17.4s ± 4.2 11.0
165.0 Acurite-Tower 14322 20464 12.3 ± 0.9 4.5 37.8 20463 17.0s ± 4.0
10.0 162.0 Acurite-Tower 2633 20094 12.2 ± 0.9 5.7 36.8 20093 17.3s ±
4.2 13.0 178.0 Acurite-Tower 8 1 11.9 ± 0.0 11.9 11.9 Acurite-Tower
9884 20278 12.3 ± 0.9 5.0 37.4 20277 17.2s ± 4.2 13.0 178.0
Ambientweather-F007TH 109 1 11.6 ± 0.0 11.6 11.6 Ambientweather-F007TH
115 4243 12.3 ± 0.8 7.4 32.4 4242 82.0s ± 15.9 78.0 316.0
Ambientweather-F007TH 139 4544 12.3 ± 0.9 5.1 35.6 4543 76.6s ± 16.3
0.0 219.0 Ambientweather-F007TH 155 6287 12.3 ± 0.9 5.6 36.4 6286
55.3s ± 11.6 45.0 211.0 Ambientweather-F007TH 166 4251 12.2 ± 0.9 3.8
34.4 4250 81.8s ± 15.0 78.0 237.0 Ambientweather-F007TH 192 5425 12.3
± 0.9 6.2 34.8 5424 64.1s ± 14.5 60.0 244.0 Ambientweather-F007TH 2 17
11.6 ± 0.2 11.3 11.9 16 71.2s ± 25.5 57.0 114.0 Ambientweather-F007TH
218 4664 12.2 ± 0.9 6.5 34.7 4663 74.6s ± 17.0 70.0 355.0
Ambientweather-F007TH 241 5590 11.6 ± 1.5 4.8 32.8 5589 62.2s ± 14.5
58.0 236.0 Ambientweather-F007TH 42 4713 12.3 ± 0.9 7.8 35.4 4712
73.8s ± 14.4 70.0 213.0 Ambientweather-F007TH 64 5811 12.2 ± 0.9 6.0
38.9 5810 59.9s ± 14.2 56.0 456.0 DSC-Security 2795104 58 7.6 ± 1.8
2.8 12.6 57 3247.8s ± 2893.3 0.0 18873.0 Ford-CarRemote 0 3 10.9 ± 1.7
8.9 12.0 2 80750.0s ± 35486.9 55657.0 105843.0 Markisol 256 1 12.4 ±
0.0 12.4 12.4 Schrader 1F1DE39 1 5.9 ± 0.0 5.9 5.9 Schrader 1F1E02C 1
5.8 ± 0.0 5.8 5.8 Schrader AEABAAA 1 11.6 ± 0.0 11.6 11.6 Schrader
DDAAB5A 1 12.0 ± 0.0 12.0 12.0 Secplus-v1 37188652 1 4.2 ± 0.0 4.2 4.2
Thermopro-TP11 1080 25875 12.2 ± 0.7 5.8 14.0 25874 13.4s ± 4.8 11.0
312.0 Waveman-Switch A 1 12.9 ± 0.0 12.9 12.9 |
—
Reply to this email directly, view it on GitHub
<#2409 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJWBXC2XQ7TFGCFFLFXSZTW27LZHANCNFSM6AAAAAAVPTOEPQ>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I had an idea for analysis that might be interesting (or completely off the wall) that seems (to me) well suited to both rtl_snr and to a lesser degree rtl_watch: Add tracking for each device's frequency, so we can see variation and whether a device is close to the limits. Frequency drift is one of the potential factors impacting reception reliability. Temperature (and maybe voltage?) change can affect the oscillators in the small inexpensive sensors. So over time devices could drift either out of the rtl_433's pass band, or into the center "DC spike". With the default sampling rate of 250k, there is a 125khz range on both sides. How much of that is usable? How much does sensitivity drop as you get close to the edges? I know there is now some compensation for removing that center spike, but how much does the ability to recover the signal is lost as the device's frequency gets near that area? SNR tracking should show some (most?). But understanding if any frequency drift occurred could yield some clues as to why that might not otherwise be obvious. Ok, let me know if I'm way out there. |
Beta Was this translation helpful? Give feedback.
-
|
Rob,
This is a good idea (you're just full of them, aren't you! 😉) I had
noticed frequency drift between some of the individual packets but
hadn't thought about that as a data-reliability factor -- and obviously,
it is.
I could (easily?) add mean, std dev, min, & max freq to the basic stats
in SNR and see if there's anything meaningful in the log data. If there
is, it would be pretty straightforward to add freq drift to the set of
things that might trigger alarms or warnings in rtl_watch (along with
battery, status, SNR changes, and missed transmission window.
Added to my task list. This will be an interesting analysis
Thanks for the idea.
David
…On 3/9/23 10:21 AM, rct wrote:
I had an idea for analysis that might be interesting (or completely
off the wall) that seems (to me) well suited to both rtl_snr and to a
lesser degree rtl_watch:
Add tracking for each device's frequency, so we can see variation and
whether a device is close to the limits.
Frequency drift is one of the potential factors impacting reception
reliability. Temperature (and maybe voltage?) change can affect the
oscillators in the small inexpensive sensors. So over time devices
could drift either out of the rtl_433's pass band, or into the center
"DC spike".
With the default sampling rate of 250k, there is a 125khz range on
both sides. How much of that is usable? How much does sensitivity drop
as you get close to the edges?
I know there is now some compensation for removing that center spike,
but how much does the ability to recover the signal is lost as the
device's frequency gets near that area?
SNR tracking should show some (most?). But understanding if any
frequency drift occurred could yield some clues as to why that might
not otherwise be obvious.
Ok, let me know if I'm way out there.
—
Reply to this email directly, view it on GitHub
<#2409 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJWBXDUV7OSW3NSPHGGFALW3HYQHANCNFSM6AAAAAAVPTOEPQ>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Sometimes it's informative to see what ISM-band devices are broadcasting in your neighborhood. While rtl_snr can do that by analyzing the JSON logs generated by
rtl_433, you may just want a quick snapshot of ISM activity in your neighborhood.rtl_watch monitors the devices seen by
rtl_433to generate and update a display window that shows the devicesrtl_433has seen and the characteristics of those devices. It is a Python3 program that functions on Mac OSX and Raspbian (Debian) Linux, at least.Beta Was this translation helpful? Give feedback.
All reactions