I'm new the Arduino scene and I was really hoping id be able to clone the remote for our electric gates and incorporate it into some automation by adding it to SmartThings.
I've stumbled at the first block though. Its an old BFT gate and the remote is no longer made, but its listed as being 315mhz. i've bought 3 different 315mhz sensor modules and none pick it up. Upon testing with a HackRF we can see the remote is actually transmitting at exactly 314mhz - I presume this is why none of the receivers pick it up.
I've got a CC1100 chip a PT2272 chip and a standard 315mhz receiver. Is there anyway they can programmed to listen on 314mhz? And even if they could to record and decode the library how would I transmit it back at 314mhz? Is this even possible?
If not I suppose the only other option would be use one of the remotes, attempt to affix an aerial to it and have the arduino wired to the button-switch on it to turn it on/off by making a contact. The only problem is the remotes have awful distance on them (it could well be the dire aerial they have) so I plan to try and solder on an RP-SMA for testing purposes but I still don't hold much hope they'll work where they'd need to be placed to join our zigbee network.
You need to "clone" the data protocol that the remote transmitter is using, as well as the frequency determining components of the transmitter and receiver.
It would probably be easier to replace both the transmitter and receiver with 315 or 433 MHz modules, and figure out your own data protocol. That is pretty easy to do with VirtualWire or RadioHead.
Using an Arduino to operate the remote seems the best solution.
There is probably a way to connect something directly to the gate as well.
The RF signal can be read with SDR and a USB dongle of 10 dollars.
If the signal uses encryption with a rolling code, it might not be possible to use it.
If you have already a zigbee network, that is a good solution to connect the Arduino to.
When you use simple transmitters, the VirtualWire/RadioHead can be combined with encryption. It can be XTEA or even SHA. I use VirtualWire with XTEA. In the data packet is a counter and I use the analog inputs for a random number. That means that when a module transmits the same temperature, the RF data is totally different.
Koepel:
If the signal uses encryption with a rolling code, it might not be possible to use it.
It doesn't its fixed code (the gate setup is probably 15+ years old) the remotes are labeled as 315mhz but they're actually transmitting at exactly 314mhz which is why i'm presuming none of the 315mhz receivers are picking up the signal.
I was wondering if i could make a 315 receiver tune to 314? But I'm assuming thats impossible. Perhaps going for 314mhz was their primitive security measure.
It does seem like hacking into one of the original remotes might be the best method. There was actually a button attached to the box which broke long ago, but that would indicate you could in theory wire in a relay, problem is last time I tried to open the box it was impossible and its messy it foliage etc around there.
About 15+ years old, mostly the 2272 / 2262 protocol was used. But there were already chips with a different protocol. Sometimes extra hardware was added to create an 'own' 2272/2262 protocol.
The very cheap receivers have a coil to tune the frequency. Often that is green plastic with a coil and a red lacker dot on top. You can tune them to 314MHz. Perhaps they receive a wide band and already receive 314 and 315MHz.
Could you open the receiver and transmitter ? Are there crystals inside ? Perhaps they also use a coil for the frequency and it has been shifted to 314MHz over the years while it should be 315MHz
There must be chips inside for the protocol. You don't have to share that with us, but they are probably online. Allthough I had to search for days to find a datasheet of protocol chip in the wireless alarm system of my house. It was 20 years old and it uses special chips. On top of that, also extra hardware to change the timing of the pulses.
The 314MHz instead of 315MHz is a big deal today, with strict regulations and rules for every band. But 15 years ago that was not so. I think it should be 315MHz and it is not deliberately 314MHz. To me, the 315MHz and 314MHz for an 15 year old device are the same.
Koepel:
About 15+ years old, mostly the 2272 / 2262 protocol was used. But there were already chips with a different protocol. Sometimes extra hardware was added to create an 'own' 2272/2262 protocol.
The very cheap receivers have a coil to tune the frequency. Often that is green plastic with a coil and a red lacker dot on top. You can tune them to 314MHz. Perhaps they receive a wide band and already receive 314 and 315MHz.
Could you open the receiver and transmitter ? Are there crystals inside ? Perhaps they also use a coil for the frequency and it has been shifted to 314MHz over the years while it should be 315MHz
There must be chips inside for the protocol. You don't have to share that with us, but they are probably online. Allthough I had to search for days to find a datasheet of protocol chip in the wireless alarm system of my house. It was 20 years old and it uses special chips. On top of that, also extra hardware to change the timing of the pulses.
The 314MHz instead of 315MHz is a big deal today, with strict regulations and rules for every band. But 15 years ago that was not so. I think it should be 315MHz and it is not deliberately 314MHz. To me, the 315MHz and 314MHz for an 15 year old device are the same.
Yeah it could have been 315 original, except every remote is doing 314 not just one and its not like its drifted somewhere away from 315 its EXACTLY on 314, so it seems deliberate. All i'm trying to do for a start off is make an LED flash when the receiver sees ANY signal, but the 315mhz one are not responding at all to the remotes.
i have opened up the remotes, they look like this...
On the circuit board is 'BFT', and there are still remotes on Ebay for BFT gates.
The UM86409 is an encoder/decoder. Datasheets are hard to find. The compatible MM53200 does have datasheets online.
Your circuit board is from 1997, but the design of such a board is a lot older. Maybe 10 or 15 years older than 1997.
It uses a printed pcb coil/antenna, and the variable capacitor tunes the frequency.
Koepel:
On the circuit board is 'BFT', and there are still remotes on Ebay for BFT gates.
The UM86409 is an encoder/decoder. Datasheets are hard to find. The compatible MM53200 does have datasheets online.
Your circuit board is from 1997, but the design of such a board is a lot older. Maybe 10 or 15 years older than 1997.
It uses a printed pcb coil/antenna, and the variable capacitor tunes the frequency.
Yes indeed there are BFT remotes out there still, the company is very much in business. They don't sell the 315mhz one in the UK anymore as technically its not a legal frequency to use (it may have been 20 years ago when they set us up with it mind) - You can buy clone remotes mind that will clone it. Although its the not the remove i've got an issue with as such i'm just wanting my Arduino to fire the code so i can control it with the smarthome.
In theory using the HT12E protocol, i should be able to record and transmit the signal with a basic 315mhz reciever and transmitter? Or would they still need to be tuned to 314mhz?
After all those years, they could be tuned to 330MHz. I think it is obvious that they were originally tuned to 315MHz. 314 or 315 is only 0.3% ! that is peanuts.
Have you measured the input band of the receiver ? Is the receiver with a crystal, or also with a variable capacitor.
Koepel:
After all those years, they could be tuned to 330MHz. I think it is obvious that they were originally tuned to 315MHz. 314 or 315 is only 0.3% ! that is peanuts.
Have you measured the input band of the receiver ? Is the receiver with a crystal, or also with a variable capacitor.
All the receivers seem to have the capacitors. I don't know how to measure the input band. Bear in mind not every remote is that old, there is a newer replacement - and they're all at 314mhz...not a bit over or above, HackRF shows exactly 314.
But if you think the 315 receiver should pick it up anyway then maybe I just need to try this other library. A start would be at least getting the onboard Arduino LED to flash when I press the remote button. Then I can look at recording it and transmitting it after that. I was hoping it'd be a bit easier than this (the 435mhz remote was a doddle)
Those cheap receivers have an automatic gain. If nothing is transmitted they receive noise. Therefor a chip for the protocol or software like the VirtualWire/RadioHead library which can detect the data out of the noise.
You have to make a decision what it the easiest and fastest way to make this work. I think that is to connect an Arduino to an existing transmitter. Perhaps directly, or with optocouplers, or as a last resort with reed relais.
Koepel:
I think that is to connect an Arduino to an existing transmitter. Perhaps directly, or with optocouplers, or as a last resort with reed relais.
I think its looking that way, I'll try the library you lined to with all the receivers i've got an RF1100SE (c1101 chip) a 4 channel R02A RF (PT2272 chip) and a basic 315mhz receiver the sort that work with RadioHead libraries (and the 435mhz worked fine for cloning a basic 435mhz remote) - but I don't think the library is suddenly going to make an LED flash or any feedback in the serial.
The RCswitch has a sketch to detect the timings for the 2262/2272 protocol.
For the 2262/2272 protocol, I don't use the RCswitch anymore, I use the fuzzillogic, because I like that code more. It can receive a few protocols, and other protocols can be added. It probably does not receive the HT12E protocol. I did not look well at the code for the HT21E protocol in the link, so I don't know if it any good.
Koepel:
The RF signal can be read with SDR and a USB dongle of 10 dollars.
1 for this suggestion.
We have a gated entry to our coastal place that uses a fixed code (set using DIPs) like you describe. The frequency is 433 and not 315 but using the SDR or a logic analyser to grab the code and then replicate it with Arduino was possible to make a spare.
We have a gated entry to our coastal place that uses a fixed code (set using DIPs) like you describe. The frequency is 433 and not 315 but using the SDR or a logic analyser to grab the code and then replicate it with Arduino was possible to make a spare.
Could you explain this process Riva? I have a HackRF here, I can record the signal, but I don't know what to do with it - I can't seem to make the HackRF transmit it either, but I presume just playing the wav file back on that frequency doesn't' do this.
I only mentioned that, because the 10 dollar (maybe 15 dollars) cheap usb rtl dongles have the 315 or 433MHz nice in the middle of the their capabilities. You didn't have to spent 300 dollars for a sophisticated HackRF. Although it is a big plus that the HackRF can transmit as well.
Most SDR software is capable to record the demodulated signal, which can be viewed/filtered/examined with Audacity.
I'm using both the Airspy SDR# in Windows and Gqrx in linux.
realdannys:
Could you explain this process Riva? I have a HackRF here, I can record the signal, but I don't know what to do with it
Don't know anything about HackRF but using one of these and the SDRSharp/Airspy software (see image 0) I record the transmitted signal load the WAV into Audacity (image 1) and trim to just the repeating pattern.
After this I zoom in and highlight each on/off period and calculate the time (image 2). In the example it shows the highlight area is 9 samples long so ((1/24000) * 9) is 0.000375 or 375uS. Once I have the fall sequence including the long gap at the end I put the values into the code I wrote below and have a cloned 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() {
digitalWrite(ledPin,!digitalRead(ledPin));
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();
}
The 24000 is the sample rate (samples per second) and the 9 is the number of samples highlighted.
Measure the gaps in the same way.
If all else fails then upload the wav sample for us to look at.
