RF output format
2 November, 2011 - 20:38
Having scratched my head looking at the RF helper page I've decided to see if someone else can give me some idea of how to achieve an RF string for a specialised output.
I'm trying to see if the HAH will directly control my central heating boiler.
I know that the transmitter/receiver works on 433 Mhz so I figure that it should be possible I just can't work out how to do it.
The following is an arduino code fragment for what I want to do:
//******************************************************************************************
// boiler_control()
// Outputs a wireless packet (2000 baud) to control a Drayton Digistat wireles thermostat receiver
// Boiler Off packet AA AC 59 99 59 55 59 56 AA
// Boiler On packet AA AC 59 99 59 55 95 65 AA
// read MSB first from left to right
// Uses function RF_tx to put 8 bit serial on digital output pin 2 (no start or stop bits)
// If boilerstate == HIGH then boiler on
// If boilerstate == LOW then boiler off
//********************************************************************************************
int Tx_bytes[] = {170,172,89,153,89,85}; // An array of 6 bytes that are sent to the Tx
int _bitPeriod = 1000000 / 2000; // define the RF Tx serial baudrate in microseconds
void boiler_control() {
int i;
for (i=0; i<6; i++) { // Output the common part of the packet 6 bytes
RF_tx(Tx_bytes[i]);
}
if(boilerstate==HIGH) {
RF_tx(149); // Turn the boiler on
RF_tx(101);
RF_tx(170);
}
else {
RF_tx(89); // Turn the boiler off
RF_tx(86);
RF_tx(170);
}
} // end of boiler_control()
//**************************************************************************************************
// RF_tx - sends the serial packet to the transmitPin
void RF_tx(uint8_t b)
{
int bitDelay = _bitPeriod - clockCyclesToMicroseconds(50); // a digitalWrite is about 50 cycles
byte mask;
for (mask = B10000000; mask; mask >>= 1) {
if (b & mask){ // choose bit
digitalWrite(_transmitPin,HIGH); // send 1
}
else{
digitalWrite(_transmitPin,LOW); // send 0
}
delayMicroseconds(bitDelay);
}
} // End of RF_tx
//***********************************************************************************************
Any help in converting this to HAH format would be greatly appreciated.
2 November, 2011 - 23:27
#2
How this is done
From the code we know that AA AC 59 99 59 55 95 65 AA is equates to ON - I'm not going to do OFF as this process is the same. I may have made some transcription mistakes so please double check my work - what I am showing you thou is the PROCESS of how you go about solving this problem.
Lets break this ON pulse encoding from the code into a BINARY pulse stream.
AA AC 59 99 95 65 AA
10 10 10 10 | 10 10 11 00 | 10 01 10 01 | 10 01 10 01| 10 01 01 01 | 01 10 01 01 | 10 10 10 10
URF only models 1->0 transitions and in a moment you'll see that is all we need.
First we Normalizing the pulse stream into state changes, which means breaking on 1->0 or 0->1 change boundary.
I've simply packed the above binary sequence and then inserted spaces to highlight the boundaries.
10101010101011001001100110011001100101010110010110101010
10 10 10 10 10 10 1100 100 1100 1100 1100 1100 10 10 10 1100 10 110 10 10 10
Now we assign a unique index to each binary grouping
10 10 10 10 10 10 1100 100 1100 1100 1100 1100 10 10 10 1100 10 110 10 10 10
0 0 0 0 0 0 1 2 1 1 1 1 0 0 0 1 0 3 0 0 0
Our stream definition is 0,0,0,0,0,0,1,2,1,1,1,1,0,0,0,1,0,3,0,0,0
Packing using the HELPER we get.
frames=21
stream=000655013000
So we can see we need 2 bit encoding as we have 4 states (0,1,2,3)
From the C code we know each state is held for 50us so we can compute the timings from our grouping.
This gives the pulse encoding table.
IDX HI LOW
0 50 50 (10)
1 100 100 (1100)
2 50 100 (100)
3 100 50 (110)
Again using the HELPER we pack the following pulse definition
pulsedef=0200320032006400640032006400640032
However the code you've supplied has
- NO interburst delay
- NO transmission burst count
So I can't tell you want the final string will be.
Using a BURST of 1 and no interburst we would get (this) but I doubt this is right as a RF pulse very rarely transmits once. Supply the entire program please or you can probably figure the rest out for yourself.
ON=0102003200320064006400320064006400320101000015000655013000
As Derek points out you can do this with a scope but you can also do it by hand if you have some sample code to work from that you know is correct and you happen to have designed the URF encoding. :)
Brett
3 November, 2011 - 12:54
#4
Amendment
Most RF encoding is manchester so really this is a mute point .... in actual fact (11 and 00) are not a manchester encodings (per se) so its not obvious. Manchester encoding will only allow a 1->0 or 0->1 state change. In your bitstream you have 1->1 and 0->0 this is simply a by-product of the way the code handles the output and technically this is NOT manchester. URF enforces this by only allowing you to specify state changes and the pulse widths.
Did you spot my bug?
int bitDelay = _bitPeriod - clockCyclesToMicroseconds(50); // a digitalWrite is about 50 cycles
int _bitPeriod = 1000000 / 2000;
So the the bitperiod is 500us - (50 clock cycles @ 7.3728Mhz ~= 7us)
The lookup table should have been (I'd double check this again!)
IDX HI LOW
0 493 493 (10)
1 986 986 (1100)
2 493 986 (100)
3 986 493 (110)
As I said these results where rough and you'd really want to measure the output pulse from the URF and tweak the pulse settings to adjust for additional code delays.
Brett
The way that I work out the URF strings for a 'new' device generally involves hooking up a cheap 'scope to the output pin of the transmitter.
The single most important value is the 'inter burst gap' time. Once you have this, look to see how many different pulse definitions you have to cater for.
The writeup on the Wiki might take some reading & thinking about .. but it IS comprehensive.
Also note that devices such as the Drayton work on a 'pairing' basis. Your Drayton receiver will probably be paired with your existing thermostat transmitter. This means that a generic Tx approach might not work. Further, if you pair your HAH RF Tx with your heating receiver, you may find that your existing thermostat transmitter might no longer be recognised (SWMBOS generally dislike this sort of thing).
Derek.