# Decoding RF help

Hi im working on a RF project, and im trying to decode a RF singnal, iv googled it but i cant seem to decode mine, they all say watch for short on, long off and so on, but i have no short on on my signal?

edit: i think i posted this in the wrong place, sorry!

edit2: i found this http://svn.telldus.com/svn/rf_ctrl/nexa_2_6_driver/trunk/NexaProtocol.txt . im trying to decode the signal from my nexa dimmer,

Looks like good highs & lows to me.
From left to right:
1000010100101001001010100100101001010100100101 etc.
Have to estimate how many 0’s there are in the longer low spots.

Looks like

S1010011001011001011001100101100110011001100110100110100101100110
or it's inverse
S0101100110100110100110011010011001100110011001011001011010011001
where the starting S is the sync pulse, 8 bytes of data and maybe 1 stop bit

Does not seem to match up with the link you supplied to this

Looks like good highs & lows to me.

Unlikely. I believe the inter-pulse timing encodes the bits. The transmit pulses are all the same width. The long space at the beginning is a sync indicator. Then short gaps are 0 and medium gaps 1 -- or vice versa.

This interpretation gives 010110011010...

There are several writeups of folks decoding these sorts of things.

Here's one with Arduino code attached:
http://1474orchard.ca/projects/?x=entry:entry130102-153246

Thanks for all the answers! :D, sorry but im having a hard time getting this to work, im new to RF,

using the info you all gave me iv come this far.

#include <RCSwitch.h>
#define Low 250
#define High 250

RCSwitch mySwitch = RCSwitch();

void setup() {
Serial.begin(9600);
mySwitch.enableTransmit(10);  // Using Pin #10
// mySwitch.setPulseLength(250);// pulse length
mySwitch.setRepeatTransmit(5);//repeat

mySwitch.send('0101100110100110100110011010011001100110011001011001011010011001',8);

Serial.print("Sent!");
}

void loop() {

}

//250 Short on
//250 Short off
//1250 Long off

iv measured the length of each “pulse”
250us Short on
250us Short off
1250us Long off

Decoding RF signals requires some knowledge of what is being used to generate the signal in the first place.
You need to know what type of data coding is being used, but Manchester coding is fairly common, but there are others.
In this type of coding , 1s and 0s are transmitted as positive to negative , or negative to positive transitions, which means the
data is self clocking and has no DC component.
Whilst not universal, a common approach is send a sequence of flag bits , which usually are represented as a sequence of 10101010 data pulses which last for 10 - 20 ms , followed by a unique and constant sync byte or nibble, which will be in some way always differant and easy to detect than the flag bits.
The purpose of the flag bits is to provide time for the receivers AGC loop to adjust to the incoming level of the RF signal
and the 1010101010 transitions allow the receivers data slicer to adjust to the 50% point of the incoming data.
Many common transmitters use one of the family of SC2262 / SC 2272 encoder , decoder chips , so if you can determine whether your transmitting device has one of these, then it makes the process a lot easier, otherwise you will have a difficult task.
The SC2262 encoder sends data as a sequence of short pulses or long pulses, with the data being conveyed by the pulse length.
Usually a logic 1 is a short pulse followed by a long pulse, a logic 0 is the reverse, ie a long pulse followed by a short.

ok, so basicly its veary hard? the info iv got now isnt enaugh? i could just open the dimmer and remove the reciver, put in a arduino nano and a custom reciver, maybe its easier?

That Nexa article does suggest its using some variant of the Sc2262 encoder, so all is not lost.
It will help you understand whats being sent, but you will still have to figure out what the data being sent actually does.
A CRO is very useful for figuring this sort of stuff out.
Heres the datasheet for a SC2262 Encoder.
http://www.escol.com.my/Datasheets_specs/pt2262_1.pdf

The data encoding format is described about 1/2 way in the article.
You may be able to spot the data patterns in your transmission.
Note, there is no timing standard as to how long the short bit or the long bit is , as both are set by a RC oscillator on the chip which can be changed by the user.
Note that the encoder is a trinary encoder, in that it can send 3 states, 0 , 1 and floating.
Quite often though the floating state is not used.

To me the signal looks like a simple OOK code.
Maybe if you tell us the make & model of the thing and possibly supply some more samples that also document the button number/name presses at the time we can work out the codes.

mauried:
That Nexa article does suggest its using some variant of the Sc2262 encoder, so all is not lost.
It will help you understand whats being sent, but you will still have to figure out what the data being sent actually does.
A CRO is very useful for figuring this sort of stuff out.
Heres the datasheet for a SC2262 Encoder.
http://www.escol.com.my/Datasheets_specs/pt2262_1.pdf

The data encoding format is described about 1/2 way in the article.
You may be able to spot the data patterns in your transmission.
Note, there is no timing standard as to how long the short bit or the long bit is , as both are set by a RC oscillator on the chip which can be changed by the user.
Note that the encoder is a trinary encoder, in that it can send 3 states, 0 , 1 and floating.
Quite often though the floating state is not used.

Hi! im going to read upp on this, thanks!

Riva:
To me the signal looks like a simple OOK code.
Maybe if you tell us the make & model of the thing and possibly supply some more samples that also document the button number/name presses at the time we can work out the codes.

il post all i can find

this is the dimmer domacaautomatizacia.eu
this is the Transmitter domacaautomatizacia.eu

This is all pure speculation but from the links and sample you supplied it looks like the entire data packet is 65 bits long and probably consists of 8 payload bytes (64 bits) and 1 stop bit. Of the 64 payload bits 26 are reserved for the transmitter address (26 bits = 67108863) and the rest will probably be button codes and maybe status bits.
As the wall switch only needs the ‘on’ button pressing to pair with a receiver the on/off buttons will follow a fixed sequence so knowing one (on or off) allows you to derive the others value. This may also be true of hand-held remote’s but I have never seen/used one to know if a button toggles on/off or if you have separate on/off buttons.
Do you need to pair with receivers again if the transmitter battery is removed for some time? If yes then probably the 26 bit address is randomly generated on initial power up. If no then it could be programmed in firmware or stored in EEPROM. If it stays the same after battery is replaced then maybe just capturing the remote codes will be enough to build your own arduino receiver.

Riva:
This is all pure speculation but from the links and sample you supplied it looks like the entire data packet is 65 bits long and probably consists of 8 payload bytes (64 bits) and 1 stop bit. Of the 64 payload bits 26 are reserved for the transmitter address (26 bits = 67108863) and the rest will probably be button codes and maybe status bits.
As the wall switch only needs the ‘on’ button pressing to pair with a receiver the on/off buttons will follow a fixed sequence so knowing one (on or off) allows you to derive the others value. This may also be true of hand-held remote’s but I have never seen/used one to know if a button toggles on/off or if you have separate on/off buttons.
Do you need to pair with receivers again if the transmitter battery is removed for some time? If yes then probably the 26 bit address is randomly generated on initial power up. If no then it could be programmed in firmware or stored in EEPROM. If it stays the same after battery is replaced then maybe just capturing the remote codes will be enough to build your own arduino receiver.

The Transmitter (Button) stays the same if i take out the battery and putt it inn again, i want to build a arduino transmitter and keep the reciver

it looks like the button come with pre programmed static code, and the reciver learns from it, there is no two way communication.

iv recorded the signals i sent with arduino, and they dont look the same, if you look at the pic the button is at the top, only short “on’s” and at the bottom is the code i send with arduino, both “long” and “short on’s”?? :~

Mongoballe1:
The Transmitter (Button) stays the same if i take out the battery and putt it inn again, i want to build a arduino transmitter and keep the reciver
Looks like the transmitter address is somehow hard coded then. Building a transmitter is a lot easier than building the receiver as you only need to replicated the signals sent for each button when presses. How many buttons are we talking about here?

it looks like the button come with pre programmed static code, and the reciver learns from it, there is no two way communication.
That’s how it looks. I did not expect the remote to be able to receive.

iv recorded the signals i sent with arduino, and they dont look the same, if you look at the pic the button is at the top, only short “on’s” and at the bottom is the code i send with arduino, both “long” and “short on’s”?? :~
It’s time to abandon trying to use the RCSwitch library unless you can send different codes to what you show. The transmitter/receiver probably uses microcontrollers now and not SC2262 so any references you have posted are not relevant.

As I said above it’s easier to replicate a transmitter (as long as it does not use rolling codes) because you don’t need to work out what the message says, just replicate it. To do this you need to know the length of the on/off pulses and then just play them back.
I built a spare remote for a gate entry system by recording the original transmitter signal and writing a program to play it back through my own transmitter.

// High/Low microsecond timings, first value is high timing, the rest alternate low/high
const int hlUsTimings[] = {
380,440,700,800,360,440,720,780,380,440,700,800,360,460,700,780,380,440,700,800,360,800,360,460,720,13000};
const int hlUsSize = sizeof(hlUsTimings) / sizeof(hlUsTimings[0]);

const int pinChangeDelay = 0;                     // Value to subtract from numbers to compensate for instruction timings
const int outPin = 3;                             // Transmitter output pin
const int ledPin = 4;                             // LED output pin

void setup() {
pinMode(ledPin,OUTPUT);
pinMode(outPin,OUTPUT);
digitalWrite(outPin,LOW);
delayMicroseconds(13000);
}

void loop() {
byte pinState = 0;
noInterrupts();
for (int y = 0; y < hlUsSize; y++){
pinState = !pinState;
digitalWrite(outPin,pinState);
// if (pinState == 0){
// delayMicroseconds(20);
// }
int z = hlUsTimings[y] - pinChangeDelay;
delayMicroseconds(z);
}
interrupts();
}

Below is part of the transmitter code where I have worked out the times to enter into the hlUsTimings array in the code above. You need to work out the times for your transmitter and do the same thing. Your code may be easier to do as all look to be fixed lengths apart from the start and stop bits. My transmitter did some strange phase change part way through so I just captured and played back the entire sequence instead of working out the timings for 0/1 bits.

Riva:

Mongoballe1:
The Transmitter (Button) stays the same if i take out the battery and putt it inn again, i want to build a arduino transmitter and keep the reciver
Looks like the transmitter address is somehow hard coded then. Building a transmitter is a lot easier than building the receiver as you only need to replicated the signals sent for each button when presses. How many buttons are we talking about here?

it looks like the button come with pre programmed static code, and the reciver learns from it, there is no two way communication.
That’s how it looks. I did not expect the remote to be able to receive.

iv recorded the signals i sent with arduino, and they dont look the same, if you look at the pic the button is at the top, only short “on’s” and at the bottom is the code i send with arduino, both “long” and “short on’s”?? :~
It’s time to abandon trying to use the RCSwitch library unless you can send different codes to what you show. The transmitter/receiver probably uses microcontrollers now and not SC2262 so any references you have posted are not relevant.

As I said above it’s easier to replicate a transmitter (as long as it does not use rolling codes) because you don’t need to work out what the message says, just replicate it. To do this you need to know the length of the on/off pulses and then just play them back.
I built a spare remote for a gate entry system by recording the original transmitter signal and writing a program to play it back through my own transmitter.

// High/Low microsecond timings, first value is high timing, the rest alternate low/high

const int hlUsTimings = {
380,440,700,800,360,440,720,780,380,440,700,800,360,460,700,780,380,440,700,800,360,800,360,460,720,13000};
const int hlUsSize = sizeof(hlUsTimings) / sizeof(hlUsTimings[0]);

const int pinChangeDelay = 0;                    // Value to subtract from numbers to compensate for instruction timings
const int outPin = 3;                            // Transmitter output pin
const int ledPin = 4;                            // LED output pin

void setup() {
pinMode(ledPin,OUTPUT);
pinMode(outPin,OUTPUT);
digitalWrite(outPin,LOW);
delayMicroseconds(13000);
}

void loop() {
byte pinState = 0;
noInterrupts();
for (int y = 0; y < hlUsSize; y++){
pinState = !pinState;
digitalWrite(outPin,pinState);
// if (pinState == 0){
// delayMicroseconds(20);
// }
int z = hlUsTimings[y] - pinChangeDelay;
delayMicroseconds(z);
}
interrupts();
}

Below is part of the transmitter code where I have worked out the times to enter into the hlUsTimings array in the code above. You need to work out the times for your transmitter and do the same thing. Your code may be easier to do as all look to be fixed lengths apart from the start and stop bits. My transmitter did some strange phase change part way through so I just captured and played back the entire sequence instead of working out the timings for 0/1 bits.

Hi, this helped alot, i finaly got it to work using your code! and yes it is fixed lengths, it was alot of work, setting all the timing manualy, but it worked, thankyou!

Mongoballe1:
Hi, this helped alot, i finaly got it to work using your code! and yes it is fixed lengths, it was alot of work, setting all the timing manualy, but it worked, thankyou!

Glad you got it working okay.
It would have been a lot easier to do with your fixed length because you could just program in the duration of a 0 & 1 bit and then call a routine with 0b0101100110100110100110011010011001100110011001011001011010011001 or it’s hex equivalent 0x59A699A666659699 and let the code work out all the timings. That is what I was originally trying to do but because of the phase change it seemed easier to just work out the entire message and send.