I’m wanting a small, interesting, wireless project. I thought I’d look into creating an RF temperature transmitter that can connect to an existing Acu Rite 00522-RX receiver (I lost the original transmitter, so this project may not be cost effective, but it is practical).
I’ve uploaded pictures of the receiver board. I’m guessing there’s not enough info in those pictures to actually build a transmitter - right? Thought I’d ask in case some RF wiz can actually suggest a course of action.
Also, is that round black blob on the board the processor? Do people typically obscure stuff that way to hide their trade secrets?
Thanks,
Bob
The black blob probably is the processor, if not it’s a display driver. They aren’t trying to hide anything, the chip is glued directly to the board and there’s tiny bonding wires that attach the chip to the traces on the board. The blob is there to protect the bare silicon chip and the bonding wires.
Google “COB” or “chip on board” for information on how these are made.
The transmitter has to use the exact method of data encoding expected by the receiver, or the receiver will ignore the transmission. Many proprietary RF weather sensor protocols have been decoded (reverse engineered), including AcuRite, so check whether yours has been. Here is an old list: https://www.osengr.org/WxShield/Downloa … tocols.pdf
If yours hasn’t been decoded, one general approach to protocol decoding is described in the following link, but you would need a functional transmitter to use the method: https://rayshobby.net/wordpress/reverse … rs-part-1/
YellowDog:
The black blob probably is the processor, if not it’s a display driver. They aren’t trying to hide anything, the chip is glued directly to the board and there’s tiny bonding wires that attach the chip to the traces on the board. The blob is there to protect the bare silicon chip and the bonding wires.
Google “COB” or “chip on board” for information on how these are made.
Thank you. COB makes sense. I’ll look into it some more.
jremington:
The transmitter has to use the exact method of data encoding expected by the receiver, or the receiver will ignore the transmission. Many proprietary RF weather sensor protocols have been decoded (reverse engineered), including AcuRite, so check whether yours has been. Here is an old list: https://www.osengr.org/WxShield/Downloa … tocols.pdf
If yours hasn’t been decoded, one general approach to protocol decoding is described in the following link, but you would need a functional transmitter to use the method: https://rayshobby.net/wordpress/reverse … rs-part-1/
Thank you very much for this info, it’s exactly what I was hoping to get. I have started studying it all. I think the AcuRite 00592TXR might work, that’s the path I’ll start down. So much well written detail.
I’m the OP, and I’m back after buying a 433MHz transmitter and receiver, and hooking each up to separate Leonardo’s and getting them working together.
Now, I’ve been studying the “434MHz RF Protocol Descriptions for Wireless Weather Sensors” doc that @jremington provided. The doc doesn’t mention my AcuRite 00522TX that I am trying to emulate, to see if my AcuRite 00522RX will pickup the signal. I am going to try coding up by following the 00606TX information. I think it’d be wise to start off by having my TX send a zero deg C value, with a battery status value of 1 (good battery). This way I can verify that the 00522RX reads the send, and displays 0C and indicates the transmitter battery is good.
My problem is I’m not clever enough to know how to code this test string, so I’m hoping that it makes sense to post a request for help here in this topic? Let me know if I should start a separate topic for this.
My coding attempt is the following:
// Create 32 bit test string of battery status 0x001 plus 0C plus 8 bit hash code for msg integrity
uint32_t hex_string = 0x001 + 0x00000000 + 0x000;
Serial.println(hex_string, HEX);
driver.send((uint8_t *)hex_string, strlen(hex_string));
So you don’t have to wade through the original 40 page doc, I’ve assembled a JPG marked up with the relevant points and attached it.
Thanks for your help!
Bob
I’ve made further progress in constructing a data string to transmit:
// Create a string having first bit 01 (Battery OK) and all other bits zero (0 deg C and appended message integrity value of zero)
String sendStr = "01";
for (int i=0; i<MaxByteArraySize; i++) //const byte MaxByteArraySize = 32;
{
sendStr += "00";
}
Serial.print("sendStr: ");
Serial.println(sendStr);
// 18:03:58.926 -> sendStr: 010000000000000000000000000000000000000000000000000000000000000000 THIS VALUE IS SENT
uint8_t byteArray[MaxByteArraySize];
sendStr.toCharArray(byteArray, sizeof(byteArray));
// Send data multiple times
for (int i=0; i<4; i++)
{
driver.send((uint8_t *)byteArray, strlen(byteArray));
driver.waitPacketSent();
delay(100);
}
Based on the requirements of the LSRF sequence, I construct a 32 bit sendStr, convert that to a byte array and transmit that four times. The LSRF statement that it repeats every 127 values is confusing to me, so I transmit it four time in a row. 4 * 32 = 128, so that’s why I did it four times.
The 00522RX, sitting right next to my 433MHz Arduino transmitter, doesn’t indicate that it’s receiving the data. The Arduino receiver does pickup the data, so I know it’s being transmitted.
I imagine my algorithm for creating sendStr is wrong. I’d appreciate it if someone would review my work and suggest changes.
Thanks,
Bob
The data might be correct, but if the bit timing, polarity and spacing are not within specifications, the receiver will ignore the transmission. What have you done to verify the timing, polarity and spacing?
Unfortunately, if a single bit is out of place, the receiver may also ignore the transmission. Without a functional transmitter to study, this is quite a challenge.
jremington:
The data might be correct, but if the bit timing, polarity and spacing are not within specifications, the receiver will ignore the transmission. What have you done to verify the timing, polarity and spacing?
Unfortunately, if a single bit is out of place, the receiver may also ignore the transmission. Without a functional transmitter to study, this is quite a challenge.
I have achieved my original goal of learning RF 433 TX/RX, so getting my TX to work with the AcuRite RX is simply extra. I don’t know anything about the timing, polarity, and spacing. But I will research that because learning that would be valuable as well. Thanks very much for your help!
Bob
