next topic »

[on:]

I bought a wireless (433MHz) receiver and transmitter the other day to interact with remote controls I have to turn lamps on and off. I try to reverse engineer the signals being transmitted when a button is pressed. I get a predictable signal when I interpret the receiver's signal as a 4800 baud serial RX, and I try to mimic that signal. All seems ok up to here. However, I find it hard to transmit the same bytes. What I did first, was to read the signal from the receiver and print to to the serial monitor using this code:

int incomingByte = 0;

void setup() {
  Serial.begin(4800);
}

void loop() {
  // read the incoming byte:
  incomingByte = Serial.read();

  // say what you got:
  Serial.println(incomingByte, HEX);
}

This gives me the hex for every byte received. I logged those, and try to send them using the transmitter using this code:

void setup() {
  Serial.begin(4800);
}

void loop() {
  ...
   Serial.write(0x84);
   Serial.write(0x84);
   Serial.write(0x84);
   Serial.write(0xbc);
   ...
}

I now connect the TX to the serial monitor instead of the transmitter hardware, and compare that result with the original receiver's RX signal. They are not the same. I think it may be something silly like hex vs decimal or data type bit length or anything like that. Is there any reason to suspect that Serial.read and Serial.write are not totally symmetric, ie Serial.write(Serial.read) is not an exact copy? What else could be wrong?

[Reply #1 on:]

Code:

void loop() {
  // read the incoming byte:
  incomingByte = Serial.read();

  // say what you got:
  Serial.println(incomingByte, HEX);
}

What numbers are you getting? You need to check Serial.available before trying to read it.

[Reply #2 on:]

I did in fact wrap the reading code within a

  if (Serial.available()) {
    ..
  }

I removed it just before posting to check if there were ever no bytes available, and there aren't.

I get a small set of unique numbers, which are (hexadecimal, in descending order of occurrence): 84, 27, BC, 21, 37, 31. Different buttons give different numbers, but I find it hard to find a pattern in the order in which these numbers occur. But the real problem I wanted to ask help with here is this: when I write out these numbers again, the pattern I see in the Serial Monitor does not vaguely resemble the direct output from the wireless receiver. So apparently I make a conversion error somewhere with the bytes read. I expected that a Serial.write() of the bytes that an earlier Serial.read() gave me would give the same pattern.

[Reply #3 on:]

Can you tell us (with links) what remote control your using? Maybe the data transmitted is not serial and your lucky the bit patterns come through consistently at 4800 baud. When you Serial transmit the received data again your data will have start & stop bit(s) added so may/will never match what you received. Ideally you should try and grab what you receive with a logic analyser or scope. Maybe you could use Adafruit IR decoder http://learn.adafruit.com/ir-sensor to grab patterns if you have no other means or audio record it using audacity. Once you have the pattern then you may (assuming no encryption using rolling key) be able to decode and re-transmit it properly.

[Reply #4 on:]

I can't find any links about the RC, but the senders use an chip called HS2262A-R4 and the receivers have a HS2272C-L4. The only datasheets I found of them are in Chinese, which I don't understand.

I hoped that the Serial library would take care of things like parity bits. And then I still don't understand when I unwrap and rewrap a byte, using the same Serial settings, why it isn't the same.

I have no oscilloscope available, but this Adafruit IR decoder sounds interesting.

[Reply #5 on:]

I hoped that the Serial library would take care of things like parity bits. And then I still don't understand when I unwrap and rewrap a byte, using the same Serial settings, why it isn't the same.

Are you sure it's sending serial data? If it's not serial then your lucky it reads anything using serial library and it will be missing bits.
If you have some electronics parts (and skill) then maybe build a audio interface http://davehouston.net/learn.htm and capture the signal using audacity.

[Reply #6 on:]

These are the receiver and transmitter that I have:

http://www.ebay.com/itm/433Mhz-WL-RF-transmitter-and-receiver-link-kit-for-Arduino-ARM-MCU-good-/330863610587

Apparently it is modulated as ASK / OOK. Maybe I need to sample it at 9600 baud and skip every second bit. Then when sending I may need to add an inverted bit after every bit.

The RC's model is Ranex RX 2585. I found little information about it, but someone states that it has a Laipac RLP434 with OOK inside, even though I only found the chip that I mentioned. I found a datasheet of it, and this also states that it operates on 4800 baud, again mentioning OOK. Does this mean that there are no parity bits, and that I need a different setup for my serial connection, or even that I can't use serial at all? In parallel I am also trying to get it working on a Raspberry Pi connected to its serial interface, also with little success.

[Reply #7 on:]

I removed it just before posting to check if there were ever no bytes available, and there aren't.

That is pretty-much impossible. Especially for a remote that sends things only when you push a button.

But the real problem I wanted to ask help with here is this: when I write out these numbers again, the pattern I see in the Serial Monitor does not vaguely resemble the direct output from the wireless receiver.

Give a real example of what you actually receive, and what is actually sent.

If you have (say) the wrong baud rate, then you will appear to receive random garbage, and if you try to resend it the resulting bit patterns will not be the same.

[Reply #8 on:]

Do your radio modules have auto mute?
if not you may be missing the start byte or decoding radio static

when i have used radios without automute the device on the other end usually looks for a preamble to tell it here comes data and a checksum byte at the end.

but thats just from my experience with them, now i use nfr2401 or xrf modules

[Reply #9 on:]

The RC's model is Ranex RX 2585. I found little information about it, but someone states that it has a Laipac RLP434 with OOK inside, even though I only found the chip that I mentioned. I found a datasheet of it, and this also states that it operates on 4800 baud, again mentioning OOK. Does this mean that there are no parity bits, and that I need a different setup for my serial connection, or even that I can't use serial at all? In parallel I am also trying to get it working on a Raspberry Pi connected to its serial interface, also with little success.

The datasheet says the device operates at 4800bps but does not say it's serial data. I suggest you abandon trying to decode using Serial and instead capture the signal using Audacity with help from this circuit. This may also be of interest but is probably not relevant to your remote control but will give you an idea of what's involved. Capture some samples and post them here if you get stuck and your likely to get help.

[Reply #10 on:]

If one device has one chip and the other has a different chip,   that suggests to me,  it is not a bi-directional device.   Not all short-range communication devices are inherently bi-directional.