It's a remote controllable light switch that comes with an RF remote. The only light switch is across the room from my PC and it's a pretty large room. (The building's basically a 1-room apartment) so this works out great with the remote. Of course since I'm using the remote to cut the lights when I go to bed I'm basically using the remote from two places which brings with it the unavoidable annoyance of the remote being in the wrong place all the time. Which means I have to get up and look for it which is effectively as much of an annoyance as it was meant to solve. So I wanted a second controller that would basically be a stationary switch by my bed so I could leave the portable remote around the desk.
Call me lazy I won't even deny it.
I popped the original remote open to see what I was dealing with.
After some research I concluded that LP801B is a PT2262 clone which is a remote control encoder chip. Has a few address and data pins and generates a signal on the output pin based on the configuration of those at the time the enable pin is connected to ground.
At first I didn't think much of it and ordered some PT2262s and made a PCB which is basically a clone of the original remote adapted for components I had lying around (or just stupidly large pads where I had no idea what I was going to use when I made the board)
Not being patient enough however I started looking around to see if anyone's emulated this chip on a microcontroller before. Turns out, several people did.
So I took the code at http://www.mikroe.com/forum/viewtopic.php?f=13&t=10832 and ported it over to BASCOM for the ATTINY13.
I think that code has a bug though as the logic low component of the syncbit should be 31 times the short-pulse duration according to the datasheet not 7. (He's basically divided the datasheet units by 4 in case anyone actually looks into this) The decoders may not care as It seems to have worked for him. When I got mine to work I was using the datasheet-correct count so I didn't test with that. It took several modifications to my original board to get it working with the attiny. Had to put in 3 zeners as the PT2262 operates directly from 12v which the attiny can't do. I actually fried an ATTINY2313 the first time around because I forgot the two selector/power buttons that were still at 12v. If I knew in advance that I'd be able to do this I would've designed a much smaller board..
I was trying random numbers for the pulse duration and randomly tuning the white variable capacitor but with none of the parameters actually being correct this method was never going to work. After some wasted time I caved and connected the original remote's encoder chip data output pin to the microphone input of my netbook.Then with the cool Soundcard Oscilloscope from http://www.zeitnitz.de/Christian/scope_en got this:
To which I could adapt my pulse duration.At this point I tested my board and while tuning the variable cap it suddenly became dark in the room :) It took a few more iterations to get the delay "just right" but now it works perfectly.
I put it in a small electrical box with 2 push-buttons and installed it in an easy to reach location from the bed.
Some component leg that I forgot to cut (probably a resistor) must have punctured the battery wire though as it drained to 10v by that night and since the circuit is basically open when none of the buttons are pressed that shouldn't happen at all. I did find a puncture mark on the positive lead so that must have been it.. damn. After reseating the board in the box and making sure the battery wires don't pass under any component legs it hasn't happened again.Project files:
Board
Very large. But the (somewhat smaller, by about 20%, still fairly large) version is on the browsing/printing PC upstairs and I'm too lazy to get it :) Note below on the jumper blocks:
[1] [2] [3]
No connection: FLOAT bit
1+3: Bit 0
2+3: Bit 1
1+2: Short out the battery
And that this PCB is for the PT2262 (and clones) so it needs modifications to be used with an AVR. At least 1 5.1V zener for the CHIPPWR and 1 per button.
The board runs off a 23A (12 volt) stack battery. Running from lower voltages may be possible but the RF circuit definitely needs to be retuned.
Schematic
Messy. The seemingly unconnected wires from the diodes on the data pins are actually connected to CHIPPWR.
PT2262 emulation code in BASCOM
Hello, I am struggling to reproduce this signal from a rapberry pi, I have very minimum knowledge of electronics. A know the signal but it won't work. I suppos there is a sync signal first can you tell me what it is please if you remember?
ReplyDeleteProbably won't be able to help but a few pointers:
DeleteWhat's required is:
* Microsecond-level precise timing (which may or may not be feasible with a RasPi running Linux?)
* RF circuit from the schematics tuned to the appropriate frequency
* Proper encoding
* Encoding's "alpha" time period set for the system you're trying to control (varies from product to product)
* Correct code for the device
There's no sync signal per se that you need to bother with. Unless you mean the sync "bit" at the end but that's simply holding the GPIO high for 1 alpha and low for 30 alphas as you can see in the bascom code.
ps.
If for some reason the RF transistor shorts out or you connect the 12V to the RasPi some other way it'll most likely kill it. You should probably add some overvoltage protection or use an optocoupler.
I have exactly the same product as you have in your topic. But it seems my environment does not match your first requirement which is "microsecond-level pricise timing" as when I send 215 micro second delay using RCSwitch library I get 290 microseconds on my sound card captured with SDR and analysed with audacity...
ReplyDeleteAfter adjustments, I have succeeded to obtain a signal very close to the one I have recorded directly from the remote. In the screenhot below the capture on the top is the one from the remote and the one below is the one I was able to send (pulse length=195, wait = 40*195 using http://www.amazon.fr/gp/product/B00NIBI7IK?psc=1&redirect=true&ref_=oh_aui_detailpage_o02_s00)
http://imgur.com/6hoamp2
I am about to declare forfeit :-(
PS I use the 5v from the RPi for the transmitter
Interesting! So I guess you can check on the frequency being correct using the SDR? Then it probably is the timing. You will get a lot of jitter on something like a RasPi that does things in the background and isn't 100% dedicated to the task. I've seen some articles on how to minimize it when the system isn't running any other tasks but it's still not going to be perfect. That might be why it doesn't work. I'm guessing you tried looping over different pulse lengths to see if any of them work?
DeleteMight be easier to use a micro. Either hardcoded with the settings for your switch or configurable from the RasPi through I2C, UART, etc..
I guess it depends on what your goal is :) For a challenge I'd go with the micro.
If I just wanted to "get it done" then remote controls that can easily be re-coded and adjusted to work with the Artslon switch are available for like $2 on ebay.
Search term:"remote control security system" then Sort by price ascending. Those white ones with the red buttons will work fine.
They most likely have an SC2260 so you'd need to change the resistor (see http://blog.solidremote.com/post/identify-rf-remote-control.aspx , search for "Oscillation Resistor" LP801 = PT2262)
Then you could just trigger the button with the RasPi using a (reed) relay or something.
And thank you for even answering my question ;-)
ReplyDeleteI have not yet managed to get the frequency from SDR... I will try more. I just assumed it was 433MHz...
ReplyDeleteWhat do you mean by using a micro? If you mean a microphone, in what way?
Your second solution is the last resort one as it will require to have a slave arduino or a GPIO extender to my raspberry because I'll have to use 1 pin per lamp in my home...
It could be. I just hand-tuned my transmitter until it started working so I'm not really sure. Something worth checking at least if you can.
DeleteMicro as in microcontroller. Using a dedicated micro for the encoding would eliminate any timing jitter. If you have an Arduino you could use that to confirm if the issue is the jitter or not.
If it is and you don't want to use a whole arduino then an ATTINY13 like the one I used for example would work just fine. Instead of using the 2 pins as button inputs you could use them for a serial connection to send commands from the RasPi.
It works off 3.3volts so you could hook it up to the RasPI GPIO connector directly I believe.
The arduino could double as a programmer.
I have an arduino nano, I will try that ;-) Thanks!
DeleteI don't know yet what a serial connection is but I will next time I'll write to you :-)