3
\$\begingroup\$


I have this remote control and transmitter and I want to reverse engineer the 2 RF signals sent by the transmitter. This is the board.
The board says "ak-rk01se". I can also open up the transmitter and see it has a PT2264 chip.

To my disposal is also a DVB-T hacked ham radio device. so I can see all the data coming out from 315MHz.
Here is an example recording from the big button with AM demodulation
Does anyone know how to tackle this?

Update, this is how it looks when I import it and run a normalize signal in audacity. The same square wave is repeated over and over again. Aucacity shows a sane signal

The question remains: How do I use an RF signal transmitter to imitate this signal? I have a raspberry pi and I can get an RF transmitter.

\$\endgroup\$
  • \$\begingroup\$ What exactly is it that you want to do? Emulate transmitter or something else? What do you mean by CW decoding in this context? Did you down-convert the frequency into baseband? Anywany, the chip just provides baseband signal than later on needs to be multiplied by carrier, so this makes analyses easier. \$\endgroup\$ – AndrejaKo Sep 6 '13 at 13:03
  • \$\begingroup\$ I want to figure out what signal is being transmitted, then use something like this and imitate the current signal with a Raspberry Pi. I removed the CW (carrier wave). Since I managed to decode the signal which is AM based. \$\endgroup\$ – GuySoft Sep 6 '13 at 13:18
  • \$\begingroup\$ I don't have time for thorough answer right now, but to me it looks like the best way would be to read the PT2264 datasheet, understand the way it generates output and then figure out settings for your particular device using captured data and by inspecting the pin connections directly. Next, generate that data on R-Pi and get a transmitter which can sustain the required data rate and uses ASK. Finally, feed the data into the transmitter and hope for the best. \$\endgroup\$ – AndrejaKo Sep 6 '13 at 13:40
  • 1
    \$\begingroup\$ @GuySoft - what you have described could easily be ASK i.e. digital square waves over AM. I suspect it is ASK. \$\endgroup\$ – Andy aka Sep 6 '13 at 17:15
  • 1
    \$\begingroup\$ @GuySoft Well ASK is a type of modulation where you have a fixed number of amplitude levels and the carrier amplitude changes between them. When you filter out the carrier, you get suqares of various levels. What you linked doesn't look like simple ASK to me. It looks that in addition to use of ASK, they're using line coding as well. You can see that at the end of every zero, there is a short section where the amplitude is one and at the beginning of every one, there is a short section where amplitude is zero. I can't remember the name of that particular code at the moment... \$\endgroup\$ – AndrejaKo Sep 6 '13 at 19:22
3
\$\begingroup\$

How about doing the simple thing: Just hook up a PT2264 to the Raspberry PI! No sense reinventing the wheel.

It looks like a relatively inexpensive chip, and does all of the proper modulation that you want. All you need to do is figure out exactly what the carrier frequency is and hook things up appropriately.

\$\endgroup\$
  • \$\begingroup\$ Because I it means adding logic switches, they cant talk because the PT2264 uses 12V. It would mean building a much more complex circuit. I rather use an RF module, and keep the remote intact. \$\endgroup\$ – GuySoft Sep 6 '13 at 17:32
  • \$\begingroup\$ @GuySoft Well, it depends on where your strengths are, and how much time you want to spend on this. For many people it is easier to do the switching than to figure out an RF communications scheme. The interfacing isn't all that hard, either. Just some resistors and transistors. I'm not saying that hacking an RF module is bad, just that it's not the only valid solution. \$\endgroup\$ – user3624 Sep 6 '13 at 17:41
  • \$\begingroup\$ I already have the signal, all that I have left is to figure out how to recreate it. We even know from one of the answer its encoding. Using a cheap RF module that would be much simpler, at least for me. \$\endgroup\$ – GuySoft Sep 6 '13 at 17:53
  • \$\begingroup\$ Got it working in the end using this TB217 Encoder Transmitter: cgi.ebay.com/ws/… Its basically a PT2264 with the board ready \$\endgroup\$ – GuySoft Dec 9 '13 at 11:04
6
\$\begingroup\$

I have done this exact thing with a similar device. I'm actually working on a blog post on reverse engineering it, but sadly it's low on my priority list and the list is long. :-(

These are all part of a very simple group of radio transmitters and receivers. They do not have any smarts in them so you can't just hook up a UART transmit pin or receive pin and expect things to work. It's up to you to send a well-formatted data stream that allows the receiver to maintain lock. Popular methods involve coding the bits in Manchester form or utilizing run-length constraining coding such as 8b10b.

It looks like your particular system is transmitting similar to what mine is; a constant bit time and either a long '1' or a short '1' pulse to signify the two logic levels. This is a very simple on-off keying implementation and it's pretty easy to both create and decode with any microcontroller. It's simpler than Manchester coding or expanding codes such as 8b10b, but you pay for it with reduced available bandwidth. This usually isn't a problem for these kinds of systems since you're not trying to maximize data transmission through the channel.

My particular receiver implementation uses an AT90CAN128's Timer1 peripheral configured in capture mode. I set up a 64us free-running timer and then whenever the receive line changes state the timer peripheral captures the timer value and signals an interrupt. From there I just look to see how long the 'high' time is by calculating the delta in timer values and if it's above a threshold its a 1, otherwise it's a zero (and if it's too short I consider it noise and ignore it). I gather up these bits by shifting them into a variable and when I've gathered enough of them I send the 32-bit value into a little software FIFO and signal my main routine that there's data to process.

For transmitting you can do something similar. Set up a timer with a tick rate that is "nice" for your particular application. (from the picture it looks like about 500us good, since the bit time looks to be about 2ms and the "short pulse" width is about 500us). You want a constant bit time, so you need to transmit one of two states: high for 1.5ms/low for 0.5ms or high for 0.5ms/low for 1.5ms. You can do this with timer overflows or go a little fancier and set the timer to automatically set/clear the pin based on value, if the peripheral allows it. You can probably get away with it by abusing the PWM feature as well. For simplicity, I would make sure you can accurately sleep for about 500us and just bit-bang it. Get it working, then get fancy.

Anyway now to reverse engineer it. Remember that I said these radios are dirt-cheap and dead-simple. You can see from the graph that there is a constant sequence of 16 bits: 0101010101010101; this is to allow the receiver to lock on to the signal. After that it looks like the actual button press is probably sending the 8-bit value 00001101. There's one 0 bit left, which is possibly parity or just used as a stop bit. You will be able to see what's going on if you press other buttons. In my particular reverse engineering adventure for these transmitters I was reverse engineering the protocol used to transmit temperature and humidity. I guessed correctly at the 1 and 0 state (it could have been reversed) and I guessed incorrectly at the bit order (it was LSB, I guessed MSB). There was also a "battery low" bit and a parity bit that I eventually figured out.

Recreating the transmission is just a matter of sending the values you've reverse engineered to the "raw" radio module using one of the methods I described above. You feed those values to the transmitter module and voilà!

\$\endgroup\$
  • \$\begingroup\$ It indeed looks like Manchester code. Good! So now we know what the transmitting is. But I am counting 24 bits, not 16. Question - what can be used to generate that signal? I don't need Tx and Rx. Just Tx, that is just to transmit the exact same sequence of bits, so the receiver will do its job. I just want to mimic the remote. \$\endgroup\$ – GuySoft Sep 6 '13 at 17:51
  • \$\begingroup\$ I see 25 bits - 8 "10" pairs followed by 8 bits followed by what I'm going to call a parity bit. And to transmit, I mentioned three possible methods in the answer, with the suggestion of just bit banging it in a loop. To transmit a 1, set the output high, sleep 1.5ms, set low, sleep 0.5ms. To transmit a 0, set high, sleep 0.5ms, set low, sleep 1.5ms. \$\endgroup\$ – akohlsmith Sep 8 '13 at 0:57
1
\$\begingroup\$

OK let's get this right. You have successfully demodulated your digital data and now you want to be able to recreate this data precisely with a raspberry pi and couple that digital data stream to an AM 315MHz transmitter?

Right so far?

For this to work you must be sure about the transmission modulation used in the original transmitter - if it is simple ASK (amplitude shift keying) then you stand a decent chance of getting it to work but you must be precise with your carrier transmission frequency or your receiver may not pick-up anything at all. You should enlist the use of a spectrum analyser to check the precise frequency it transmits at. Hey you may get lucky but in my experience probably not.

If it is a more complex form of AM transmission like suppressed carrier then you have little chance finding an off-the-shelf transmitter that will do the job.

\$\endgroup\$
  • \$\begingroup\$ When I demodulate using AM I get this digital signal. Its quite clear, you can even see the sine modulation of the square wave! Its not AFK right? Its just sending digital square waves over AM. \$\endgroup\$ – GuySoft Sep 6 '13 at 14:45
  • \$\begingroup\$ Also, here is a second signal (the other button). Looks very similar, except there are two "bits" that changed. \$\endgroup\$ – GuySoft Sep 6 '13 at 14:59
  • \$\begingroup\$ One thing you won't see is the sinewave of the carrier - that is far too high and it's unlikely your screen capture would be sampling at over 630M samples per second to prevent aliasing. It's feasible but get the carrier frequency right. \$\endgroup\$ – Andy aka Sep 6 '13 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.