ACU>RITE Temp Sensor # 606TX

Any One Decode The Format Of The Binary RF Stream ?
I Have Some Samples....

101 100 1111 100 1100 1 111 1001 100 1111 100 1100 1 111 1001 100 1111 100 1100 1111 1001 100 1111 100 1100 1111 1001 {24°C-75°F}
| | | |
101 100 1011 010 1100 1 011 0101 100 1011 010 1100 1 011 0101 100 1011 010 1100 1011 0101 100 1011 010 1100 1011 0101 {23°C-74°F}
| | | |
101 100 0011 000 1100 0 011 0001 100 0011 000 1100 0 011 0001 100 0011 000 1100 0011 0001 100 0011 000 1100 0011 0001 {0°C-32°F}
| | | |
It Is Repeating, 4 Times....

8 times, 11 bit repeat, could be a serial char with 2 stop bits even, but the value doesn't make sense - some more examples at intermediate temperatures would be good to help work it out.

Here is One More Colder....

101 100 1111 100 1100 1 111 1001 100 1111 100 1100 1 111 1001 100 1111 100 1100 1 111 1001 100 1111 100 1100 1111 1001 24°C-75°F
| | | |
101 100 1011 010 1100 1 011 0101 100 1011 010 1100 1 011 0101 100 1011 010 1100 1 011 0101 100 1011 010 1100 1011 0101 23°C-74°F
| | | |
101 100 0011 000 1100 0 011 0001 100 0011 000 1100 0 011 0001 100 0011 000 1100 0 011 0001 100 0011 000 1100 0011 0001 0°C-32°F
| | | |
101 101 0001 100 1101 0 001 1001 101 0001 100 1101 0 001 1001 101 0001 100 1101 0 001 1001 101 0001 100 1101 0001 1001 -15°C-5°F
| | | |

This is Received Using an 433 MHz Receiver Transmitter Pair From E-Bay. 8)
Its Just a 1's & 0's Data Stream.

mxcpm1yxdmSJNuM3fKtDCN7JdsQ.jpg

Do you know what the modulation type is for sure?

They are "binary palindromes", for want of a better term. The {0°C-32°F} sequence for example contains a series of 38 bits, the second 19 bits of which is a mirror image of the first 19 bits. I haven't figured out the encoding but I might guess some sort of NRZ. IR remotes use something similar to this.

I Hope I (we) Can Get This Going....
You Can Get A Sensor For $5.00 # 606TX. This one is Temperature Only...
The Temperature & Humidity Sensor Is $5.00 Also, # 593TXR.

Is There Sketch For Measuring a Digital Pin In Microseconds, High & Low, Mine Might Be In Error.....

The Display and Sensor Looks Like This....

00380

The Timing is :
Digital Pin High No Data Received. When Receiving Data, The Highs Is About 500 Microseconds And The Lows Are 2,000 Microseconds (Shorts) &
4,000 Microseconds (Longs). VPWM ? (Variable Pulse Width Modulation ?)

So I Say 500 Microseconds = Nothing (High)
2,000 Microseconds = 0 (Binary) (Low)
4,000 Microseconds = 1 (Binary) (Low)

mxcp00380_av-display-300dpi-hi-res_1.jpg

It would probably help if you posted the sketch you are using.

Here Is 1 Of My Sketch's : 8)

/*

  • Read Pulse in MicroSeconds
  • Using Digital Pin # 47
  • Pin # 47 High When NOT Reciving Data
  • Pin # 47 Goes Low When Reciving Data
    */

int Pin = 47; // Reciver is connected to pin # 47
unsigned long Duration;
int Count = 0;
int EndCount = 0;
int PulseLow[500];
int PulseHigh[500];
int a;

void setup() {
pinMode(Pin, INPUT); // Set the switch pin as input

Serial.begin(9600); // Set up serial communication at 9600bps
Serial.println("Reading Pin(47) MicroSeconds:");
Serial.println("Count High Low");
}

void loop() {

do {
Duration = pulseIn(Pin, HIGH); // Wait For Data
} while (Duration < 1);

PulseHigh[Count] = Duration;

do {
Duration = pulseIn(Pin, LOW);
PulseLow[Count] = Duration;

Duration = pulseIn(Pin, HIGH); // Reciving Data, Short & Long Pulse's
PulseHigh[Count] = Duration;
Count++;
} while (Duration > 10);

EndCount = Count;
Count = 0;

for(Count; Count < EndCount; Count=Count+1) { // Print Out Data To Serial Terminal
Serial.print(Count);
Serial.print(" ");
Serial.print(PulseHigh[Count]);
Serial.print(" ");
Serial.println(PulseLow[Count]);
}

do { // Loop Forerver
a = 0;
} while (a = 1);

}


And The Data Dump... In Microseconds...

Reading Pin(47) MicroSeconds:
Count High Low
0 529 481
1 533 2047
2 529 4145
3 519 4174
4 523 2055
5 514 2057
6 514 4155
7 520 4183
8 520 2060
9 515 4159
10 514 4161
11 523 2061
12 515 2057
13 516 4159
14 518 4182
15 520 2059
16 510 2062
17 518 4159
18 519 4190
19 514 2061
20 514 4151
21 523 4157
22 522 2060
23 514 2060
24 523 4155
25 520 4182
26 514 2056
27 515 2061
28 519 4159
29 515 4183
30 514 2060
31 522 4157
32 523 4153
33 518 2061
34 523 2056
35 524 4156
36 516 4182
37 514 2052
38 518 2061
39 512 4160
40 516 4178
41 520 2061
42 520 4156
43 520 4155
44 516 2060
45 526 2057
46 518 4155
47 514 4181
48 520 2060
49 511 2059
50 514 4157
51 522 4186
52 522 2060
53 514 4157
54 518 4155
55 526 2057
56 518 2056
57 516 4155
58 522 4181
59 520 2060
60 514 2060
61 519 4160
62 520 4186
63 516 2059
64 516 4149
65 523 4156
66 523 2059
67 518 2057
68 524 4156
69 522 4182
70 514 2060
71 520 2061
72 516 4159
73 514 4183
74 515 2060
75 522 4157
76 524 4156
77 518 2060
78 520 2057
79 522 4155
80 518 4181
81 515 2056
82 519 2060
83 514 4159
84 514 4176
85 520 2060
86 522 4156
87 516 4157
88 13418 2060
89 7230 39
90 0 0

That's a clever scheme for capturing the data. I tend to believe your theory about the modulation is correct. I haven't had an aha! moment about the encoding yet. Have you exhausted the web for hints from other users of the sensors?

The weather station software WxShield has added support for acu-rite as of version 1.7.

Some time ago I decoded the transmission of an ACURITE W091 Temperature Sensor, also 433 MHz and it seems to use a similar protocol. The bit coding certainly seems to be the same. I used a 433 MHz receiver, the line audio in jack and Audacity on a laptop to capture the signal. My notes indicate the following:

9 milliseconds start bit
4 milliseconds RF off = 1 bit
2 milliseconds RF off = 0 bit

Transmissions: 9 ms start bit, followed by 24 bits repeated 11 times
each 24 bit packet consists of 10 bit sensor ID, 12 bits temperature in degrees C*10, then two bits of unknown function. Negative temperature is stored as 2's complement.
The sensor ID is a rolling code and changes every time you disconnect and reconnect the battery.

The WxShield software mentioned in a previous post doesn't appear to decode this particular sensor. I spent some time looking at your data but am stumped. I like a challenge, so more examples with different values would help! Please let us know how you finally decode your transmissions.

Here's what I did:
copied the binary data.
removed the repeated codes in each transmission.
Used the -15 value to locate the polarity bit (one of these is not like the other method), also realizing that most
languages mimic our own (specifically computer languages). It's better to put the negative symbol before the number,
it's prettier.
Separated what appeared to be headers and end of transmission stuff.
Converted the numbers in the middle to base ten, and paired them with the associated Celsius and Fahrenheit values.
Here's what I ended up with:
HDR, PolSymbT/F, Numb, EndTrans Numb Base 10 Coordinates
1011, 00, 111110, 01, => 62 24C,75F ==> (62, 24) or (62,75)
1011, 00, 101101, 01, => 45 23C,74F ==> (45, 23) or (45, 74)
1011, 00, 001100, 01, => 12 0C,32F ==> (12, 0) or (12, 32)
1011, 01, 000110, 01, => -6 -15C,-5F ==> (-6, -15) or (-6, -5)

Because I don't think it would make very much sense to have some kind of other system like NEC, DirecTV, Sony, as in Infrared protocols, since we're not controlling a function but going straight to a display. It should be transmit, receive, and immediately post to the display. => I ran it through a linear regression program. ASCII didn't work out very well. Here's what I got

C(x) = 0.598232x - 8.90006 F(x) = 1.19786x + 10.1603

C(a) Error Offset | F(a) Error Offset
C(62) = 28.190324, 4.19 | F(62) = 84.42762, 9.43
C(45) = 18.02038, -4.98 | F(45) = 64.064, -9.936
C(12) = -1.721276, -1.72 | F(12) = 24.53462, -7.47
C(-6) = -12.489452, 2.51 | F(-6) = 2.97314, 7.97
r^2 = 0.951936

Looking at the error offsets, I'd say that it looks a bit quadratic or parabolic, and we'd like r^2 to be closer to 1 ==> More regression,
but Quadratic instead.

C(x) = 0.00751x^2 - 1.019085x - 9.431543 F(x) = "Screw Fahrenheit"
Better to just do everything in Celsius, until it's time to display
C(a) Error Offset | something, for accuracies sake.
C(62) = 24.88174..., 0.8817... |
C(45) = 21.21871..., -1.7813... |
C(12) = -1.71598..., 1.7160... |
C(-6) = -15.81642..., -0.8164... |
r^2 = 0.992959

Now that r^2 value is much prettier, with much prettier error offsets to match. My recommendation would be to use the quadratic function above, with the x value being the stripped-down converted binary number, and the function C(x) output being an uncalibrated Celsius value.
That should get you close. Because there isn't a perfect linear temperature sensor, and I didn't see any place to store calibration values on my remote sensor, most likely those values are stored on the base station.

And ..... I need to make more coffee.... as if I hadn't enough

Ok here's a better update to my last.

I used Kenneth Shirriff's Infrared Libraries, with my own definitions to recognize this protocol, which correlates well. I think Mr. Shirriff had this kind of stuff right on!
Here's what I did:

I found that multiple different hexadecimal or binary values represent the same displayed temperature value, which means to me that there's some decimal places in this temperature value. The m_neg, and m_pos variables I came up with through some more linear regression. It's not perfect but it's "dialed in" pretty close. I've been stuck on regression lately. Lets' use regression for everything!!!!! Okay never mind.

Watching the hexadecimal values, I found that the "F" hexadecimal place, just after the sensor ID value indicates a Negative temperature value in Celsius, based on my output.

LAN_Temp.ino (4.51 KB)

IRremote.zip (41.4 KB)

If you need regression to get an approximate relationship between the binary code and the temperature, you have not completely solved the code. The transmissions of all remote sensors like these encode exact digital data, not approximations.

Yes, regression does give you an approximation. AANNnnnndddd, the indication on the indicator is also an approximation. If the system were linear, then a linear regression test would find a line that fit the data. Based on what I've seen, you could, maybe even should, subtract 0.5&degC from the calculated value. Regression will find how much change in a binary/hexadecimal/whatever kind of number is needed to make the indicated number change.

In the case of my device. It appears that my system for the most part linear. Linear Regression, in this case, as long as I use the correct pulses and spaces, proves to be quite accurate and precise. Why???? The calculated and floored offset remains parallel throughout time, change in temperature, and temperature. Accuracy could be considered questionable, but even then " I know it's offset".

Regression can be used for accuracy and precision. I don't think one should be so closed minded.

I don't like being an asshole, but you shouldn't have been a closed minded idiot. I may get banned from this site, so what! I only brought an idea that works, with a little bit of hacker spirit. If my idea sucks, bring a better one. You sound like a damn kid, "You did it wrong!" or maybe an old person "Right tool for the right job". And I hope you realize that if you're on the upper end of the age issue, those are typically the people that have to have everything like it used to be, and we may as well be using Wash Boards instead of Washing Machines. If you don't try anything different, regardless of "what The Professor said", or "Dad said", you will never grow. And you become a sheep an ant?, or a bee? ... whatever. Your method of thinking isn't why Hard-drives, CDs, .......

Maybe you already get my point
:roll_eyes: :roll_eyes: :roll_eyes: :roll_eyes: :roll_eyes: :roll_eyes: :roll_eyes: :roll_eyes: :roll_eyes:

Old topic, but there aren't any others containing data for the Acurite 606TX. I tried one yesterday but it went bad within a few hours. In that time, I was able to record some data from RTL_433. It's a different format so I don't know for sure that it's valid, but I figured it might help someone. Note that the first 3 readings were recorded after the battery was removed and reinstalled. From what I've read, the unit ID may roll automatically every time the battery is removed/installed so the ID bit(s) may not match.

                                                                         degC        degF
[01] {32} b6 8f 55 44 00 : 10110110 10001111 01010101 01000100 00000000 -17.22222222 1
[01] {32} b6 8f 73 c2 00 : 10110110 10001111 01110011 11000010 00000000 -13.88888889 7
[01] {32} b6 8f b4 c6 00 : 10110110 10001111 10110100 11000110 00000000 -7.777777778 18
[01] {32} b6 80 cc 7b 00 : 10110110 10000000 11001100 01111011 00000000 15           59
[01] {32} b6 80 c9 0c 00 : 10110110 10000000 11001001 00001100 00000000 20           68
[01] {32} b6 80 d0 a1 00 : 10110110 10000000 11010000 10100001 00000000 20.55555556  69
[01] {32} b6 80 d5 d6 00 : 10110110 10000000 11010101 11010110 00000000 21.11111111  70
[01] {32} b6 80 db bb 00 : 10110110 10000000 11011011 10111011 00000000 21.66666667  71
[01] {32} b6 8f e7 0c 00 : 10110110 10001111 11100111 00001100 00000000 21.66666667  71
[01] {32} b6 80 e6 49 00 : 10110110 10000000 11100110 01001001 00000000 22.77777778  73
[01] {32} b6 80 ea fd 00 : 10110110 10000000 11101010 11111101 00000000 23.33333333  74
[01] {32} b6 81 07 8d 00 : 10110110 10000001 00000111 10001101 00000000 26.11111111  79

If this turns out to be of no use, no problem. Enjoy!

Did anyone make get a working solution to this that would kindly share their code?