JP1 Remotes

Ever since I've been a member of the JP1 group I've seen occasional postings expressing an interest in learning one thing or another about various RF remote controls. Recently, Rob asked me if I knew of any way to look at a signal from a certain RF remote he was trying to decode. He had asked me that same question maybe a dozen times over the years, so I decided to take it on as a project. I'm happy to report that the outcome of that project is an unbelievably wonderful new toy, and I'm making it my Christmas present to the group.

I have just added a file in the Files>Hardware folder entitled Digitrace.zip (links below). It's an article that tells how to build an RF Sensor that's as simple as a JP1 interface, can be built with less than $5 worth of parts, and can be used in conjunction with some incredible freeware to receive, save, and analyze transmitted signals from virtually any kind of hand-held RF remote control. If you've ever wanted to know what's being sent by your ceiling fan control, or your garage door opener, etc., now you can find out. I've tested it with units operating at 27, 49, 300, 304, 310, 315, 384, 390, 418, 462, and 468 Mhz. You don't even have to know the transmitter frequency, and there are no controls. You just point and shoot.

But wait, there's more. (Do I sound like I used to sell vegetable slicers on TV?) The article goes on to describe a companion IR Sensor that can be made from just one part that's smaller than a pencil eraser and costs less than a dollar. Using the same software, the IR Sensor will record transmissions from virtually any kind of infrared remote, regardless of protocol, and tell you everything you could possibly want to know about the signal. It's all made possible by one of the most remarkable pieces of freeware I have ever encountered, and it runs flawlessly under Win 95/98/ME/2000/NT/XP.

Two years ago I published an article describing how to build a device that could be used to receive and measure raw IR signals transmitted from a remote. It was an extremely accurate device, but never gained popularity, partly because it required ten integrated circuits on a printed circuit board, and ran under a DOS QuickBASIC program rather than Windows. Here's a tool that's much, much simpler to build, yet vastly more powerful and easier to use.

One last comment. I test these designs as thoroughly as I can on as many different kinds of PC's as I can, but there's always something out there that I'm not aware of. So for any of you who build one of these gadgets, please give me some feedback on how it works out for you, what you're using it for, and any problems you may have encountered. In particular, be sure to tell me what processor speed and operating system you use it with, and what "Granularity" it opens with. Don't know what "Granularity" is ? Read my article.

The original design docs (now obsolete) are here:
http://www.hifi-remote.com/forums/dload ... le_id=2043

The revised (as of 06/04/2005) docs are here:
http://www.hifi-remote.com/forums/dload ... le_id=2044

You can download the Digitrace program from here:
http://www.xs4all.nl/~jwasys/old/diy2.html

Just in case that site ever disappears, there is a backup copy here:
http://www.hifi-remote.com/forums/dload ... le_id=2045

UPDATE (August 2005):
Hal has written a new program called CaptureIR which replaces Digitrace, keep an eye on this thread to monitor the progress.

Download CaptureIR prototype 2 here:
http://www.hifi-remote.com/forums/dload ... le_id=2002

Download CaptureIR prototype 3 here:
http://www.hifi-remote.com/forums/dload ... le_id=2035

Tommy Tyler

OK, anybody who doubted that Tommy is THE MAN, please go and stand in the corner and don't come out until you've repented!

I can't wait to build this thing and play with it.

Tommy, THANK YOU!!!!

Here are some useful links...

You can ready about the "DigiTrace" program here...
http://www.xs4all.nl/~jwasys/old/diy2.html

And you can download it from here...
http://www.xs4all.nl/~jwasys/old/digitrace_zip.zip

I have also stored a backup copy of it here:
http://www.hifi-remote.com/forums/dload ... le_id=2045

You can read about PortTalk (the app needed to access the parallel port under Windows 2000) here:
http://www.beyondlogic.org/porttalk/porttalk.htm

And you can download it from here:
http://www.beyondlogic.org/porttalk/porttalk22.zip

Backup copy here:
http://www.hifi-remote.com/forums/dload ... e_id=13532

Tommy, thankyou for finding/investigating/documenting that freeware program and for the associated hardware design.

I've left the progect of integrating DecodeIR into some PC capture hardware on my projects back burner for too long.

Hopefully Rob can get the attention of the author of that program and he will be interested in helping us connect DecodeIR. Failing that, the results you got seem to say that raw bit capturing under Windows has become more practical in the years since I last tried, so I think I'll try again soon.

Just FYI, there's a typo in one of the part numbers in that doc, the correct part number for the 100pf capacitor is 75-1C10C0G101J050B (ie, the red number is a zero, not the letter "O" as stated in the doc)

THis looks like it'll be great for those who don't have a learning remote. Thanks for your work.

This goes beyond that. A learning remote can only capture IR signals, this device captures RF signals.

Tommy,

Looks great!

Some questions:

1. Can it determine the RF frequency?
2. Same question for the IR version.

I have a box full of x10 remotes that can send both IR and RF. IIRC, they just modulate the RF transmitter with the same signal that they send to modulate the LED emitter. The RF transmitter is on a little daughter board about an inch square.

It would seem like we could do the same thing with a JP1 remote, use the x10 remote daughterboard and have both a universal RF and IR remote. Since we will now be able to analyze the RF signal we could use Protocol Builder and create a protocol upgrade. I believe they operate ~400 MHz so it may be too limited in frequency to be useful.

But if you have any interest I'll send you several if you want to play with them, and I'll be glad to attempt to put together protocol upgrades to make it work.

I still make use of your IR analyzer and as recently as a couple of weeks ago. It was the only thing that detected one final command that was issued at key release. The OFA remote (which really is a pretty good learning device) and a Pronto couldn't detect it so it couldn't be learned reliably.

jon_armstrong wrote:1. Can it determine the RF frequency?

No, it can't. It pretty much responds to any RF signal in the range Tommy mentioned, but it does not know the RF carrier frequency.

jon_armstrong wrote:2. Same question for the IR version.

Maybe, but from what I read about it, the duty cycle can't be determined with any degree of accuracy. A lot depends on the PC hardware.

jon_armstrong wrote: It would seem like we could do the same thing with a JP1 remote, use the x10 remote daughterboard and have both a universal RF and IR remote. Since we will now be able to analyze the RF signal we could use Protocol Builder and create a protocol upgrade. I believe they operate ~400 MHz so it may be too limited in frequency to be useful.

The X-10 devices are all at 310 MHz. The Radio Shack remotes, like the 15-2117, operate at 430 MHz. Remotes like the Pronto, operate at 418 Mhz. Others are at 433 MHz.

In looking at the schematics of an X-10 UR47A remote it appears the RF signal is exactly the same as it's IR signal. The only difference is the RF transmitter is only enabled for signals intended to be RF. This also appears to be what the 15-2117 does.

So if I understand things correctly if a 15-2117 can learn to send the same IR signals as an X-10 remote then adding the RF daughter board should work.

I'm in the process of hacking the RF daughter board from UR47A into a 15-2117 now.

wkearney99 wrote:In looking at the schematics of an X-10 UR47A remote it appears the RF signal is exactly the same as it's IR signal. The only difference is the RF transmitter is only enabled for signals intended to be RF. This also appears to be what the 15-2117 does.

Yes, except that the RF transmitter in the 15-2117 is always enabled and always transmits every code. I'm not sure how robust the X10 protocol is in terms of its ability to reject other transmissions, like for your TV, etc., but I guess you'll soon find out.

jon_armstrong wrote:2. Same question for the IR version.

Another thought on this subject... As an option for the super-deluxe model (for the hard-core among us), maybe you could use one of the unused sections of the LM324 to provide a third input channel that could be connected directly to the IR LED on a remote. That might enable a more accurate analysis of the carrier frequency/duty cycle.

mr_d_p_gumby wrote:

jon_armstrong wrote:2. Same question for the IR version.

Another thought on this subject... As an option for the super-deluxe model (for the hard-core among us), maybe you could use one of the unused sections of the LM324 to provide a third input channel that could be connected directly to the IR LED on a remote. That might enable a more accurate analysis of the carrier frequency/duty cycle.

What value is there in a more accurate measure of duty cycle? The duty cycle seen by the real IR receiver (in the device you're trying to control) won't be the same as the duty cycle generated inside the transmitting remote. It will be a complex function of characteristics of the IR LED and the circuitry driving it and the distance and the background illumination. If you duplicate the original duty cycle with your JP1 remote and duplicate the distance and background illumination, you still won't duplicate the duty cycle and you have no need to.

As for frequency, getting a better sample of the original leading edges (as you suggest) corrects an insignificant aspect of the frequency measurement error. Even if you corrected the other aspects, that one still wouldn't matter. Without correcting the bigger error sources, that fix to frequency measurement would be absurd.

I don't yet have a good feel for the scale of those "big" errors (though much bigger than the edge shift in the modulation pulses). They come from calibration errors in the capture process, from Windows interference, from memory refresh interference and from bus traffic (netword cards etc.) interference. I don't know how far off all that pushes the timing. As Tommy suggested in his doc, if you're worried enough about timing reliability to care (I am, because I want to debug decoding software and maybe new capture software with this) you should have a fixed square wave at a reliable known frequency on an extra channel (and he suggested what sort of part to use). I want THAT in my "super-deluxe model" not a better connection to the original IR generation.

johnsfine wrote:What value is there in a more accurate measure of duty cycle? The duty cycle seen by the real IR receiver (in the device you're trying to control) won't be the same as the duty cycle generated inside the transmitting remote. It will be a complex function of characteristics of the IR LED and the circuitry driving it and the distance and the background illumination. If you duplicate the original duty cycle with your JP1 remote and duplicate the distance and background illumination, you still won't duplicate the duty cycle and you have no need to.

I agree that the transmission path always introduces variances and distortions, and that the signal received and passed on to the decoder seldom matches what was fed into the transmitter.

But you ask what value there would be in reproducing the duty cycle at the transmitting LED? If you assume that the designers of the OEM remote knew what the receiver liked best and had optimized the duty cycle for best reception & decoding, then it seems to me that being able to reproduce approximately the same duty cycle at the transmitting IR LED in a JP1 remote would be of benefit.

Tommy states that the current duty cycle measurement will not be meaningful because the IR receiver used does not demodulate the carrier, and the signal it recovers will depend heavily upon the distance from the remote, batteries, ambient light, and lots of other variables. Being able to look at the signal fed to the IR LED would remove most of those variables. It's not that I'm looking for more "accuracy", but rather less variability.

And yes, I agree that you should be able to determine the carrier frequency in most cases with enough accuracy without needing the extra input.

johnsfine wrote:As Tommy suggested in his doc, if you're worried enough about timing reliability to care (I am, because I want to debug decoding software and maybe new capture software with this) you should have a fixed square wave at a reliable known frequency on an extra channel (and he suggested what sort of part to use). I want THAT in my "super-deluxe model" not a better connection to the original IR generation.

That reference signal would also be useful in the super-deluxe model. Whether Tommy decides to document the inclusion of the extra input or not, I certainly can design it into my own version. Between us, we've still only used 4 of the 8 available channels, so there's no conflict.

err. wrong thread for that reply. sorry 'bout that.