Acurite 3 in 1 not receiving any data.

[jason begley]

I just picked up a Acurite 3 in 1, and setup rtl_433. I can not get any output from the program from the 3 in 1. Is the 3 in 1 not capable of being decoded, or am I doing something wrong (probably). I  used sdrsharp to scan for the freq since rtl's are historically off freq a bit, but even with corrected freq no output. I just get very short blips from the 3 in 1. The receiver has no issued decoding the output.

[Robert Terzi]

On 3/20/2017 11:25 PM, jason begley wrote:
> I just picked up a Acurite 3 in 1, and setup rtl_433. I can not get any output from the program from the 3 in 1. Is the 3 in 1 not capable of being decoded, or am I doing something wrong (probably). I used sdrsharp to scan for the freq since rtl's are historically off freq a bit, but even with corrected freq no output. I just get very short blips from the 3 in 1. The receiver has no issued decoding the output.

You did the right first steps, however, I'm pretty sure there is no (explicit) support for the 3-n-1 currently. (Quite a few people have been using the 5-n-1.) It's possible the message format is somewhat close to existing devices.

A couple of things to try:

First step is to record some messages with rtl_433 -a -t. When doing this, take notes about what the encoded values should be. It is most helpful if you have one of the acurite displays to write down the values from that when you capture the data files (gfileNNN.data). Then add your test files along with a README to the rtl_433_tests github repo under Acurite. Create a new numbered directory for the 3-n-1.

Try decoding your test files with the "Pulse Analyzer" (-A). The pulse characteristics for your recorded (and live) signals should be pretty consistent if you are receiving it correctly. Probably 80% of the time, the pulse analyzer will handle the demodulation correctly and let you see the raw bytes. It can sometimes be thrown off by different types of preamble/start pulses.

You might also try running rtl_433 with debugging turned up to 1 or 2, to see if any of the existing acurite call backs fire, but then reject the signal.

Let me/us know what you find,
--Rob

[Robert Terzi]

forgot one obvious thing - make sure when you attempt to decode to use -G to enable all decoders.

Decoders that don't output structured data (JSON, CSV) are not enabled by default.

On 3/20/2017 11:25 PM, jason begley wrote:

[jason begley]

I don't know if I'm on the right freq. I'm not getting consistent RX. The 3 in 1 sends every 18 seconds, and minutes may go by before I get decodes with -A. Does anyone kn ow what the 3 frequencies are that acurite uses? Also which freq do I used for rtl433, the one from the sdrsharp frequency, or from the CLI of rtl_tcp (connecting over lan)

[Robert Terzi]

Not sure what you mean by the 3 frequencies that Acurite uses.   If you are referring to channel number, that just changes 2 "ID" bits in the message to differentiate sensors, it doesn't change frequencies.

As far as what frequency to tune rtl_433 to:

With the default sampling rate of 250 Khz, the tuned bandwidth is approximately half of that (125 khz) on each side of the tuned frequency.  Doing the math, If you are using the default of 433.920 Mhz,  the part of the spectrum received would be from 433.795 Mhz to 434.045 Mhz.

SDR# by default uses a sample rate for RTL-SDR that is 2 - 2.4 Mhz.   This shows 8-10x more spectrum than what rtl_433 is seeing and the expense of much more CPU time.  To see what rtl_433 is receiving, change SDR#'s sample rate down to 250 Khz.

Note that there is a "dead spot" right in the middle at the tuned frequency.  On FFT plots without additional filtering, this will show as a center spike that stays in the center even as you change the tuned frequency.  This is referred to as the "DC Spike".   It is very difficult to receive signals that occur too close to that spike, they are obscured by it.   Some SDR software, like SDR#, use "offset tuning" to avoid this problem.  Implicitly the tuner will be set to a frequency far enough away from the target frequency to avoid the spike, but still within the sampled bandwidth.   IIRC, when you look at the output of rtl_tcp, you will see the actual frequencies that SDR# is tuning to.

The error in your RTL-SDR stick's crystal oscillator changes what (range of) frequencies you are actually receiving vs. think you are tuned to. This will change slightly as the stick warms up in actual use.  Most of the time, depending on the size of the error, it isn't a big factor.  The highest error I've seen on RTL-SDR's I've used is 77 ppm, which is about 33 Khz off.    So that's roughly a 13% error at 433.920 Mhz.  As long as your target signal doesn't wind up too close to the edge of your received spectrum the error shouldn't matter that much.  Of course the oscillators used in your devices that transmit will have a certain amount of error and will likely be somewhat temperature dependent.

So what all of the above comes down to, the center frequency for your RTL-SDR, should be one that has your desired signal appearing somewhat in the center of the received bandwidth (125 khz) on either side of the center.   In other words, not to close to the center spike to be obscured, and not close enough to the edges to fall outside of the received range.

There are a bunch of other factors for good reception that are probably more important than frequency.   What are you using as an antenna?  Is is the right electrical length for 433.92 Mhz or what ever your target frequency is?    It is also usually helpful to get both your RTL-SDR and it's antenna away from sources of noise, such as the computer/RPI it is plugged into by using a USB extension cable.    Take a look in SDR# to see how the "noise floor" changes as you move your antenna and RTL-SDR around.

Hope this helps,
--Rob

[jason begley]

I have it sorted somewhat. It was an antenna issue. I have created a new folder with the text, but I do not have access to upload files. I have a few gfiles to go with the data posted. Let me know if I should attach them here, or wait for access.

[Benjamin Larsson]

Fork rtl_433_tests and then add the files and then send a PR.

MvH
Benjamin Larsson

[jason begley]

Let me know if it uploaded. 

Thanks

[jason begley]

I have added the files and a pull request.
Thanks.

[RDK]

I realize this thread is a bit old, but I'm new to the use of RTL_433 and I have an AcuRite 3-in-1 which is not displaying correctly in the RTL_433 output.  The system see the device, but seems to classify it as a 5-in-1.

I get this error message:

2018-03-10 21:04:26 Acurite 5n1 sensor 0x011E Ch C, Status E2, Unknown message type 0x20

Am I doing something wrong?  Is there a work-around?.....RDK

[Benjamin Larsson]

On 03/11/2018 11:07 AM, RDK wrote:
> I realize this thread is a bit old, but I'm new to the use of RTL_433
> and I have an AcuRite 3-in-1 which is not displaying correctly in the
> RTL_433 output.  The system see the device, but seems to classify it as
> a 5-in-1.
>
> I get this error message:
>
> 2018-03-10 21:04:26 Acurite 5n1 sensor 0x011E Ch C, Status E2, Unknown
> message type 0x20
>
>
> Am I doing something wrong?  Is there a work-around?.....RDK
>

I guess that someone needs to add support for message type 0x20. Most
likely the AcuRite 3-in-1 has different payload format compared to the
AcuRite 5-in-1.

So to help out you need to send us some signal samples.

https://github.com/merbanan/rtl_433#how-to-add-support-for-unsupported-sensors

MvH
Benjamin Larsson

[Christian Zuckschwerdt]

You can get the data with e.g.

    rtl_433 -q -F json -X 3in1:OOK_PWM:184:428:700:500 -r g001_433.92M_250k.cu8

Some syncs and then 64 bits, repeated two times:

    "{1}0", "{1}0", "{1}0", "{1}0", "{65}20c79fd47288f8520", "{1}0", "{1}0", "{1}0", "{64}20c79fd47288f852"

You need to correlate that with readings and find out what the bits mean, you most likely can compare to the existing 5-n-1 decoder.

[canada...@gmail.com]

This code here decodes the 3 in 1 Sensor data.

wind_speed_mph = acurite_getHumidity(bb[6]);
tempf = acurite_getTemp(bb[4], bb[5]) - 108;
tempc = fahrenheit2celsius(tempf);
humidity = acurite_getHumidity(bb[3]);

Not sure how to integrate it, currently I have it under this section of code.

 } else {
            fprintf(stderr, "%s Acurite 5n1 sensor 0x%04X Ch %c, Status %02X, Unknown message type 0x%02x\n",
                time_str, sensor_id, channel, bb[3], message_type);

[Christian Zuckschwerdt]

Sounds good. I'll add support for this in the next days.

[Christian Zuckschwerdt]

Try this branch https://github.com/zuckschwerdt/rtl_433/tree/feat-3n1
And improve on the decoding. Is -108 really the correct value? I.e. (raw-400) / 10 - 108 thus (raw - 1480) / 10 -- that's an unlikely offset.
And the windspeed is wrong. Either find the correct decoding or table some values (codes vs readings from a wall unit. With codes as e.g. {65}20c79fd47288f8520 or {64}20c79fd47209fad5).

[canada...@gmail.com]

Nice work.  That does look like an unlikely offset, though it matches the display perfectly.  The wind speed also seems to match, though is often 1 to 2 points off.

[Christian Zuckschwerdt]

The wind speed here is 7bit (0-127) with no decimals. Is that a valid / expected range? (Isn't a hurricane only half of that?) What is the range/resolution claimed on the device and shown on the wall unit?

[canada...@gmail.com]

The wall unit only goes up to 99mph.

[Christian Zuckschwerdt]

Well, the AcuRite 06045 uses a temperature offset of 1500. Is it really 1480? Is maybe the existing decoding wrong? I'd like to know!
Also the 5-n-1 uses the raw number as cup rotations per 4 seconds with a calculation of (raw * 0.8278 + 1.0) / 1.609344 mph. Could that explain the slight difference?
Best to table a number of values (very high and very low would be great) and compare.

[RDK]

 

On Tuesday, March 21, 2017 at 4:25:01 AM UTC+1, jason begley wrote:

I just picked up a Acurite 3 in 1, and setup rtl_433. I can not get any output from the program from the 3 in 1. Is the 3 in 1 not capable of being decoded, or am I doing something wrong (probably). I  used sdrsharp to scan for the freq since rtl's are historically off freq a bit, but even with corrected freq no output. I just get very short blips from the 3 in 1. The receiver has no issued decoding the output.

 

Folks.....I've been away from this issue as I got other springtime house and yard chores done and now the rest of my sensors working in my Python system.  It would appear from the following  posts that the problem with decoding the 3n1 data has been addressed by Christian Zuckschwerdt in his March 26 posting.  However, I'm a total NOOBS with this stuff.

1. I tried modifying my current acurite.c file ( /usr/pgms/rtl_433-master/src/devices/acurite.c) as per a suggestion by Jason on the Acrutie Forum, but my changes do not seem to be applied when I ran the test command (sudo rtl_433 -R 40 -F json > TestDevice3n1.txt).  So obviously I'm doing something wrong.  Do I need to update/compile/?? my current installation?
   
   
2. From Christian's posting I'm not 100% sure what my next steps should be?  Do I uninstall rtl_433 as it exists now and reinstall from Christian's site? 

Any assistance would be GREATLY appreciated......RDK

[Christian Zuckschwerdt]

I'm still waiting on tests and confirmation. The proposed change is found here: https://github.com/zuckschwerdt/rtl_433/commit/d399e8054b447fcc1a00299e1f713a969610c49a

Apply that, then `mkdir build ; cd build ; cmake .. ; make` and run with `./build/src/rtl_433`, i.e. not the globally installed (old) version.

[RDK]

On Tuesday, March 21, 2017 at 4:25:01 AM UTC+1, jason begley wrote:

I just picked up a Acurite 3 in 1, and setup rtl_433. I can not get any output from the program from the 3 in 1. Is the 3 in 1 not capable of being decoded, or am I doing something wrong (probably). I  used sdrsharp to scan for the freq since rtl's are historically off freq a bit, but even with corrected freq no output. I just get very short blips from the 3 in 1. The receiver has no issued decoding the output.

Christian... Many thanks for the prompt reply.  I have looked at the proposed changes and question whether this line is correct:

            wind_speed_mph = acurite_getHumidity(bb[6]); // ???

 I seems that maybe it should be something with windspeed and not  "acurite_getHumidity(bb[6]); "

Thanks....RDK

[Christian Zuckschwerdt]

That's the main issue, it can't reasonably be correct. John had good results with this, and `getHumidity` just retrieves a byte but the subsequent cast to double is not a sane operation.

It would be great if someone could table values or sample files with readings from a official wall unit.

[RDK]

On Tuesday, March 21, 2017 at 4:25:01 AM UTC+1, jason begley wrote:

I just picked up a Acurite 3 in 1, and setup rtl_433. I can not get any output from the program from the 3 in 1. Is the 3 in 1 not capable of being decoded, or am I doing something wrong (probably). I  used sdrsharp to scan for the freq since rtl's are historically off freq a bit, but even with corrected freq no output. I just get very short blips from the 3 in 1. The receiver has no issued decoding the output.

Christian....If I had any idea what it is you need and how to get it I would be willing to help.  But, understand, I'm a real NOOBS with things like this.....RDK 

[Christian Zuckschwerdt]

No problem. Run rtl_433 with -D flag for debug output, e.g. rtl_433 -q -F json -D

This will give you the raw message for each packet:

Acurite 5n1 raw msg: DF 38 60 2B 8D 77 07 AD

Copy those lines and annotate them with the values from your display (wind_speed, temperature, humidity).

Post a good variety of those values and I'll take a stab at decoding them.

If you can, remove the rtl-sdr antenna an place the 3-n-1 sender at 10cm to the rtl-sdr receiver, that way you will only receive the interesting transmissions.

[RDK]

Christian....Hmmm, this will not be simple!   I have 5 sensors which are being monitored by my rtl_433 system.   The 3-in-1 is outside on top of a 12 ft pole.  If I move it inside there will not be any wind to measure. Give me a couple days to think about this....RDK

 

[RDK]

Christian....After reflection, I think the best is for me to order a new 3n1 and use it for the experiment.  I'll let you know when I receive the new unit....RDK 

[RDK]

Christian....More questions.  How critical is the distance between my Raspberry Pi with the SDR dongle and the 3n1?  I'm trying to figure out how and where to place the units so we get real outside data (temp, humidity, and wind speed). Unless I do something weather proof, my Pi needs to be inside or weather protected...RDK

[Christian Zuckschwerdt]

Don't worry, the setup without antenna is just to reduce reception from other devices (the 433 band is crowded). You can use the normal setup as well. There will be more output to filter through.

(i.e. without antenna and a somewhat short distance the reception can be made mostly exclusive to one sender if needed)

[RDK]

Hmmm, I've been replying on the Gmail thread for this subject but it does not seem to show here.  Here are my posts/questions/comments:

1. Christian....Just thinking, I have a spare Acurite Tower sensor (reported as #40 unit by the RTL_433 functions).  I can have it next to the 3in1 so you can have real time data from a sensor you know how to decode. Would that be useful?.....RDK 
2. Christian....I'm back  from Italy and have the new 3en1 unit.  How should I setup the Pi?  I noted earlier when I ran this command "rtl_433 -q -F json -D" and piped it to a file, that I also got output on the Pi's consol.  Is there a way to pipe all the output to a file?
   
   
   I'll set up this experiment in my basement and fiddle with the antenna until I get only the 3en1 and the tower.  Temperatures will not vary much and I will use a fan to simulate wind.
   
   
   If I read your earlier message correctly, I'm only looking for line that look like this "Acurite 5n1 raw msg: DF 38 60 2B 8D 77 07 AD"?  What will the line for the tower look like?
   
   
   Any other instructions or comments?....RDK

OK, I'm ready to do the experiments.  I have figured out how to get all of the command output piped to a file and I've been experimenting with my existing system.  During these experiments I have observed output like

•  "Acurite 5n1 raw msg: 11 1E 60 42 11 50 02 34"
•  and "2018-06-01 17:51:11 Acurite 5n1 sensor 0x011E Ch C, Status 42, Unknown message type 0x20"

which convinces me that they are associated with the 3en1, which has an id of 4382 (ie 111e in hex).  I have an Excel macro which will help eliminate all of the other non-useful messages.

Any comments?....RDK

[Christian Zuckschwerdt]

Those "Acurite 5n1 raw msg" lines are what we need. They are reported for all devices and the 3in1 will then have the unknoen message note. Annotate the raw data with your reading and so we can make deductions and tests.

[RDK]

Christian....OK, I have about 45 minutes of data for the 3en1 and a tower. I did 5 "wind" settings: 0, low (5-9 KPH), medium (10-14 KPH), high (16-19 KPH) and very high (33-37 KPH).  I used a fan with three settings and for the  very high I used my wife's hairdryer (so there may also be a 3en1 temperature effect).

The Acurite display is not instantaneous/real time so the wind values I quote are whatever it was displaying and really can not attach a number to any specific "raw data" line.

How can I get the data to you?  It is in an Excel sheet.  The data are grouped in the sheet, by the wind simulation setting.  Each data group is separated by a yellow highlighted line with observation details, ie wind range....RDK

[kevtheskin]

On Wednesday, 22 March 2017 14:53:31 UTC, Robert Terzi wrote:

Not sure what you mean by the 3 frequencies that Acurite uses.   If you are referring to channel number, that just changes 2 "ID" bits in the message to differentiate sensors, it doesn't change frequencies.

As far as what frequency to tune rtl_433 to:

With the default sampling rate of 250 Khz, the tuned bandwidth is approximately half of that (125 khz) on each side of the tuned frequency.  Doing the math, If you are using the default of 433.920 Mhz,  the part of the spectrum received would be from 433.795 Mhz to 434.045 Mhz.

SDR# by default uses a sample rate for RTL-SDR that is 2 - 2.4 Mhz.   This shows 8-10x more spectrum than what rtl_433 is seeing and the expense of much more CPU time.  To see what rtl_433 is receiving, change SDR#'s sample rate down to 250 Khz.

Note that there is a "dead spot" right in the middle at the tuned frequency.  On FFT plots without additional filtering, this will show as a center spike that stays in the center even as you change the tuned frequency.  This is referred to as the "DC Spike".   It is very difficult to receive signals that occur too close to that spike, they are obscured by it.   Some SDR software, like SDR#, use "offset tuning" to avoid this problem.  Implicitly the tuner will be set to a frequency far enough away from the target frequency to avoid the spike, but still within the sampled bandwidth.   IIRC, when you look at the output of rtl_tcp, you will see the actual frequencies that SDR# is tuning to.

The error in your RTL-SDR stick's crystal oscillator changes what (range of) frequencies you are actually receiving vs. think you are tuned to. This will change slightly as the stick warms up in actual use.  Most of the time, depending on the size of the error, it isn't a big factor.  The highest error I've seen on RTL-SDR's I've used is 77 ppm, which is about 33 Khz off.    So that's roughly a 13% error at 433.920 Mhz.  As long as your target signal doesn't wind up too close to the edge of your received spectrum the error shouldn't matter that much.  Of course the oscillators used in your devices that transmit will have a certain amount of error and will likely be somewhat temperature dependent.

So what all of the above comes down to, the center frequency for your RTL-SDR, should be one that has your desired signal appearing somewhat in the center of the received bandwidth (125 khz) on either side of the center.   In other words, not to close to the center spike to be obscured, and not close enough to the edges to fall outside of the received range.

There are a bunch of other factors for good reception that are probably more important than frequency.   What are you using as an antenna?  Is is the right electrical length for 433.92 Mhz or what ever your target frequency is?    It is also usually helpful to get both your RTL-SDR and it's antenna away from sources of noise, such as the computer/RPI it is plugged into by using a USB extension cable.    Take a look in SDR# to see how the "noise floor" changes as you move your antenna and RTL-SDR around.

Hope this helps,
--Rob
 


On 3/22/2017 2:31 AM, jason begley wrote:

I don't know if I'm on the right freq. I'm not getting consistent RX. The 3 in 1 sends every 18 seconds, and minutes may go by before I get decodes with -A. Does anyone kn ow what the 3 frequencies are that acurite uses? Also which freq do I used for rtl433, the one from the sdrsharp frequency, or from the CLI of rtl_tcp (connecting over lan)

On Tuesday, March 21, 2017 at 10:42:19 AM UTC-4, Robert Terzi wrote:

forgot one obvious thing - make sure when you attempt to decode to use -G to enable all decoders.

Decoders that don't output structured data (JSON, CSV) are not enabled by default.

On 3/20/2017 11:25 PM, jason begley wrote:
> I just picked up a Acurite 3 in 1, and setup rtl_433. I can not get any output from the program from the 3 in 1. Is the 3 in 1 not capable of being decoded, or am I doing something wrong (probably). I  used sdrsharp to scan for the freq since rtl's are historically off freq a bit, but even with corrected freq no output. I just get very short blips from the 3 in 1. The receiver has no issued decoding the output.

Hello there, How do you set sample rate to be 250khz please.

Thanks Kev