New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help with values for short_limit, long_limit and reset_limit #23
Comments
I believe the following to be true, others may correct me:
|
Look in issue #5 for some details. If you post a debug output it will be easy to tell for sure. |
Hi Benjamin and Guo-Rong, Thank you for your comments. I have added the debug output for both the Holman iWeather and the Oregon devices. Sorry about the length, but I don't think I can attach files here. I have snipped a lot of lines in the middle of each output. I'll go now and have a read of Issue #5 and also try Guo-Rong's suggestion. Thanks, Cheers, Barrie
Holman iWeather Debug Output
Oregon Debug Output
|
Hi Benjamin, These are the values I have come up with. I have had some success, but the output from my &iweather_callback function is not decoding the same as the output of rtl_433 -a. If you have any suggestions, I'd appreciate it. Thanks. Cheers, Barrie
output of rtl_433 (I've modified the code a bit to get this output from my &iweather_callback function)
Output of rtl_433 -a
|
Did you have any success adding Oregon support for the THN132N? Although it was easy for me to add X10-Security support, I failed to add Oregon. Both OOK_PWM_P and OOK_PWM_D seem not to fit for Oregon. See http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf for a detailed analysis of the Oregon protocol. Looks like a new pwm_decode routine is necessary which is beyond my capabilities. |
Hi, I had similar problems. Unfortunately, it is beyond my capabilities Good luck. Cheers, Barrie
|
My fork adds support for the WH3081 Fine Offset weather stations, which appears similar to Oregon stations.
|
@gkoh Thx! I will try to test your changes with Oregon. I have seen the support for the sync bit in the code. I did not see the demod output swapped (maybe I have overlooked this). |
Yes, the key changes are only in rtl_433.c, my other changes were just I'm not 100% sure about the demod output swap, but changing it made it make sense for me. |
I'm also looking for decode logic for Oregon Scientific weather sensors. The OS sensor from the dump above seems to use the v2.1 protocol. At the stream level, the bits are encoded using manchester encoding (http://en.wikipedia.org/wiki/Manchester_code), which involves a variable pulse width and a variable distance between pulses. Data bits are 'clocked' at fixed intervals from the start of the first pulse of the message. This is neither pcm_d or pcm_p, so a new decode routine will be needed. Below is a hand drawn timing diagram from the Oregon Scientific THN132N data dump above. Based on the OS decode pdf posted above, v2.1 puts 2 bits in the stream for each real data bit. First, the complement of the data bit is sent, then the actual data bit is sent. So 0xFFFF will appear in the stream as 5555 5555. In the diagram above, I crossed out the extra bits (the complement bits) to leave just the real bits. Also, the Oregon sensors send the bits in each nibble backwards, so to reassemble the nibbles, you have to read each nibble right to left. Decoding the dump above, the message has the preamble of FFFF, the sync nibble of A, then the Sensor ID, which decodes as EC40. That's all the data in the dump, but it seems to make sense at least. I started coding the new decode routine and it's actually pretty simple (I think). I'll post that soon. |
I took a stab at the code for the new manchester decoder, but I don't have a USB dongle yet to test it. I'm a little torn about how much of the v2.1 decoding should happen in the decode routine vs in the higher layer packet decoder. So far, I did a straight manchester decoder that (hopefully) will return the full bit sequence exactly as it appeared in the stream. The resulting bit stream will need to get post processed for v2.1 to strip out every other bit, and to reverse the bits in each nibble. This may not even compile, but I think it has a good shot of working, especially with some minor debug, which I'll probably get to in the next couple/few weeks after my hardware arrives. ...See issue #34 for working code |
Thanks for the efforts. I have added your new manchester_decode() to my code. Before I tryied Using the same timing with the new manchester decoding procuces just zeros: [00] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : |
I messed up and was calling demod_next_bits_packet() after both calls to demod_add_bit() above. I edited the code above. I don't really understand when next-bits-packet() needs to get called. Obviously at the end of a message, but is that it? |
Also, from the analyze output above, I think short limit should be 120 or 125. Long isn't used. |
I have done the changes you proposed. [00] 55 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : [00] 55 55 55 55 55 55 55 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : [00] 55 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : |
I still have more bugs to fix. Sorry about that! The message should start with 5555 5555 9995 A5A6 AAA? ... Then, that raw bit stream data will need to get further processed by stripping every other bit and flipping bits in each nibble to get the actual message data of FFFF A EC40. Once I have hardware, I planned on debugging the code above and writing a OS parser, which I think can handle the three different protocol versions. |
I edited the code above to hopefully fix the extra zeros bug. I was calling the callback even when there was no data received. You should still only see data in the first packet of the bit array [00]. |
Thx. I have tried the last changes. Now I do not receive any packets at all. Even no zeros.... |
I made another fix to the code above. If you're not tired of trying this, it will hopefully fix the no-data ever problem. There's still something else going wrong with the decoder right after the preamble that I haven't figured out yet. I'm sure it's something dumb. |
Looks like the targes is nea. [00] aa aa aa ed 55 aa d5 75 5b 5a da ab aa f5 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 : All other packets look like the following. [00] 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 40 00 00 00 00 00 00 00 : [00] 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 40 00 00 00 00 00 00 00 : |
I just realized that you're not the original poster, so my comment about the expected data sequence won't apply to you, since you probably have a different sensor. What's the model number of the sensor you're using? Also, could there be multiple things within range sending data at 433mhz |
If I understand the program options, I can play back previously recorded data samples from a file instead of using a USB dongle. If that's true and anyone has or could create a data file with some saved Oregon Scientific weather sensor data, it would be much appreciated. I'll use the data to get a jump on the debug while waiting for my USB dongle. |
I tested my Oregon Scientific manchester decoder and wrote a parser for a handful of v2.1 sensors. I have a WMR968 weather station and tested this on the following sensors: The code isn't completely polished, but it does v2.1 bit-level error detection and overall seems pretty robust. With my particular combination of sensors and USB dongle, tuning the frequency down a tad and lowering the detection level using "./rtl_433 -f 433810000 -l 7000" gave me the best results. ... See issue #34 for working code |
@magellannh Very nice work. I have lots of OS 2.1 and 3.0 Oregon sensors. For me it works better, to just user ./rtl:433: Rain Gauge RGR968 Rain Rate: 0mm/hr Total Rain 9790mm It even works well without having a real 433 Mhz antenna. Have to get an adapter..... Just can't wait for v3 decode. Is there anything I can do to test it? |
I'm glad it works for you! Could you post the model number for a basic temp/humidity v3 sensor so I can order one? As far as adding v3 support, the low-level manchester decode logic should already handle v3. The callback needs v3 parsing logic that will be analogous to the v2.1 code that's there, but also a little different. v3 is probably less complicated than v2.1 overall, except I'm not sure how tough validating the checksum will be. v2.1 has bit-level redundancy coded into the messages, so I didn't bother trying to figure out the checksum algorithm. I thought rtl_433 had a way to record and play back data to/from a file that could be fed back into my parsing logic, but I couldn't figure out how to get that to work. If you're up for it, you can uncomment the "Unrecognized Msg" fprintf toward the bottom of the callback function, and send a printout with a few messages to me (should start with FFFF for v3). A few raw v3 messages should be enough to get me started on the v3 parser. Do you code in C? If so, I'd be happy to rough in a basic parser and let you take it from there. Also, my THGR268 has a sensor ID of 1d20, so some IDs must get reused by multiple sensor models. |
You need to use -m 0 and -m 1. It is possible to record the raw radio samples and the demodulated signal. |
According to http://www.oregonscientific.com/wcsstore/IDTStorefrontAssetStore/File/sensorchart.pdf I do have at least the following V3 sensors: WGR800, PCR800 These are some of the messages I receive (deleted the 00 00 00 messages): Unrecognized Msg: 28 05 4d 4c ab 52 d5 2c b2 cc b4 aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 What I also get is the following other OS V 2.1 sensors: |
I have noticed that with your code, my X10 security does no longer work. |
Hmmm. I didn't change the default sample rate. I grabbed the code from the tip version I think. In any case, my decoder should still work with a different sample rate as long as you adjust the short limit and reset limit to compensate (I think you can multiply the values by 4, but I'm not sure). Also, the DECODE ERROR on bit 89 looks like a corrupt message from a BHTR968 (indoor sensor 5d60). I usually get some decode errors right after start up, but then things settle down after 5 minutes or so. I have one sensor that isn't far away that was giving me a bunch of trouble until I adjusted the frequency down to 433810000. With that change I got reliable data from that sensor and all the others. I figured that was from normal clock inaccuracy from using a cheap USB dongle. Also, I got the file save/load stuff to work (thanks merbanan!). Use "./rtl_433 -m 1 tst" to create the file then "./rtl_433 -r tst" to read and process it. There's no output while the file is writing, so you need to let the program run for a minute or two and hope you get what you're looking for. Then stop the program and restart it using the -r to read the file and process the data so you can see what you got. If you email a file with some v3 packets (probably start with 7f ff or ff ff or something similar) to , I'll take a crack at the v3 parser. |
Actually you can run in auto mode and it will save and split the signal files automatically for you. Run with -t -a or something like that. It should split out .gcode files or so. |
Hmm. My RF environment is very noisy as I have lots of sensors. What I am thinking is to take the OS 3 Oregon PCR800 sensor and my notebook to a place where there is no RF noise. I just thinking what this place would be the best as this can not be near to my house. At this place I will do a ./rtl_433 -m 1 RF_PCR800" and will let you know. |
Hi all, I'm new here.. but I've read all your posts and I'm interested into get Oregon protocol running with rtl_433. In my case, I want to read energy meter sensor (owl CM160), which I've read that uses this protocol. At this point, I want to take a look on your code, magellannh , but I can't recover it from pastelink (web says it is under maintenance tasks)... so, is there any other way to check the source? Thank you very much every body! |
I'm new to github and still learning. For now, you can find my changes to rtl_433.c through a pull request that I created: |
thank you very magellannh, I will take a look... and if I can add something, I will share it. |
Hi again, my owl CM160 energy sensor is giving me this kind of data: after some searching in google... I've add this code inside the oregon_Scientific_v3_parser:
and this is the output: Registering protocol[01] Rubicson Temperature Sensor Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle anyway, I don't know exactly what means every niblle.... Thank you very much to everybody... |
We changed the demodulator structure to more understandable names and limits. Closing. |
Hi Benjamin,
I am trying to add decoding of data for the Oregon Scientific RMR382 (Sender THN132N) to rtl_433. I am having difficulty understanding how to work out the values for short_limit, long_limit and reset_limit. I have had a go, but I don't think I have the correct values set. I have detailed my values below.
I have also included rtl_433 -a output for an Oregon Scientific THN132N sender and rtl_433 -a output for a Holman Industries iWeather WS5029 sender.
Any assistance in working out these values would be appreciated.
Thanks.
Cheers, Barrie
rtl_433 -a output for an Oregon Scientific THN132N sender
rtl_433 -a output for a Holman Industries iWeather WS5029 sender
The text was updated successfully, but these errors were encountered: