Kameleon 2nd generation 8210

[dangerous]

Hi,

A few weeks ago I bought a URC 8210 (UK 10 devices) remote.
Following this link:

There is a chart of JP1-compatible remotes and their capabilities in the file section>Miscellaneous>Spreadsheets.

the spreadsheet says it is "??JP1.2" (Not a punctuation error. Question marks show in the file.)

Can anyone confirm this, and if so, is there anyway to hack it from JP1 software?

Does it still use SCL & SDA for data transfer?

[Capn Trips]

The newest versions of the software (IR and RM) work with JP1.2 remotes, but the hardware (read: "cable") is completely different, so you need to build or buy a new interface. Look through the Hardware and Software fora to get the latest poop.

[johnsfine]

I expect the ?? means the author of that xls wasn't sure the 8210 has a JP1.2 connector.

Have you checked the battery area to make sure it has some kind of 6 pin connector? Given the pattern of model numbers, it seems very unlikely that the interface would be anything other than JP1.2. So if it has a six pin connector, I would assume it is JP1.2.

The JP1.2 interface design is documented (make sure you find the current design. Some earlier incorrect designs were posted). But it is a lot harder to build one at a time than JP1 designs. Buying one makes more sense. The ones you can buy use surface mount parts to squeeze everything into a tiny connector. shell.

[dangerous]

Have you checked the battery area to make sure it has some kind of 6 pin connector? Given the pattern of model numbers, it seems very unlikely that the interface would be anything other than JP1.2. So if it has a six pin connector, I would assume it is JP1.2.

There is a 6 pin connector fitted on my R/C but no markings are obvious.

But it is a lot harder to build one at a time than JP1 designs.

Not a problem to me, but thanks for the warning. For playing with I can build on stripboard and hard wire. If I really get to grips with it I can design / make SMD boards later.

Thanks for your help. I'll advise of progress (if I make any).

[Capn Trips]

I would wager a small confectionary that it is JP1.2.

[dangerous]

It would seem so.

Binky123 has sent me some interesting info using a MAXIM IC to do the comms, so that looks helpful.

The remote itself is a wierd looking silver shiny thing with an EL display and touch screen - Remote "Bling" if ever there was such!

It offers 10 devices, but when my new Panasonic PVR has about 50 buttons on its remote, and my Lite-on not many less, It looks like time to program a remote to do major functions.

The 8210 can learn about 30 functions per device, and with the PVRs there is no pre-programmed function that works. Hence my need to program!

[dangerous]

In another thread I read:

You can program modem-equiped remotes using JP1 without a cable. You go through all the normal steps, as outlined in the documentation, then instead of clicking "uoload to remote" in IR.exe, you export the results to a WAV file and load it into your remote that way.

Does this apply to all modem eqipped OFAs, even the JP1.1 & 1.2 version?

It will save some aggro if I can do this on my 8210 Kameleon 10.

Is there any way to read codes from the Kameleon this way? I can program a button using the learning mode, so if I could then recover the codes, I could build a library for each unit I want to control or maybe adapt an existing file with similar codes. I am quite happy to build an IR interface to feed a serial port if need be.

I have several devices I would like to control, TV Sony (OK) DTV box Panasonic (On/off OK - nothing else) DVD/HDD recorder Lite-on, same as DTV, DVD/HDD Panasonic same as DTV, Audio centre Panasonic, same as DTV.

So far, I have replaced a perfectly good TV remote with a very expensive flashy OFA and that is all.

[Capn Trips]

YES you can programme the remote using the modem, but NO you cannot read anything back FROM the remote without a cable.

BUT..... even to upload using the modem, you still need to have a remote that has has an rdf developed, so that you can use RemoteMaster to BUILD an upgrade, and IR (with IRtoWAV) to CREATE the wav file. This requires SOMEBODY with a cable to download from the remote and decipher it to build its rdf file - usually requiring an expert's assistance.

To my knowledge, there is not yet a fully-developed rdf for this really new remote. There is a "starter" rdf but I don't know how "mature" it is.

I recommend building or getting a cable. Then you will be the pioneer in finalising the rdf, and will be able to download from the remote and build your own upgrades to upload.

[johnsfine]

The 8210 can learn about 30 functions per device,

The pool of learning memory is shared by all ten devices. I don't know how many total functions you can learn, but I'm pretty sure it is more than 30 and I'm very sure it is less than 300 (30 each for ten devices).

But I guess you already understand that building upgrades is better. Just use learning to gather information for making the upgrade, then delete the learned signals.

[dangerous]

I thought that I might have a go at building the IR receiver/decoder detailed elsewhere on this site by Tommy Tyler, then maybe I can understand the codes used.

Making the PC talk to the Kameleon may be a bit more of a pain though!

[johnsfine]

There have been a few versions of that discussed. Which one do you have in mind?

If you're planning any parallel port version, tell me what you intend to build. I've generalized CaptureIR so it ought to be able to function with almost any IR detector connected to any data or status pin on the parallel port.

The design I started with, from Tommy, connects the IR signal to a data pin. I think a status pin makes more sense.

The design I started with also uses an active high signal. I built one unit with the QSE156 (totem-Pole output, active high) and I think did minor damage to my printer port through misuse. I built and use another unit with the QSE158 (open-collector, active high). I think one would minimize the risk of damage from misuse with open-collector active low, such as the QSE159.

I'm in the process of making a list of a few other types of IR detectors to buy from mouser.com and/or newark.com to experiment with and see what are the characteristics of CaptureIR with various devices. Most of those are demodulating. I expect CaptureIR would work with such devices but haven't tested yet. Of course that limits you to around +-10% of the modulation frequency of the part you choose.

I assume you understand the various kludges that the various posted designs have used to provide 5V power to the IR detector. I think that's where I had most of my trouble before I took an extreme solution. I cut up an old USB cable for each of my CaptureIR devices and tapped into 5V there. That is more robust than trying to steal power from the printer port and simpler design than the ways of regulating 5V power from the serial port. You sound like you would be better able to deal with that than I as long as you're warned not to trust the simple design of just tapping power from the printer port (might work. For me it somewhat worked, but I didn't like having it as an extra wild card).

[gfb107]

The design I started with, from Tommy, connects the IR signal to a data pin. I think a status pin makes more sense.

The design I started with also uses an active high signal. I built one unit with the QSE156 (totem-Pole output, active high) and I think did minor damage to my printer port through misuse. I built and use another unit with the QSE158 (open-collector, active high). I think one would minimize the risk of damage from misuse with open-collector active low, such as the QSE159.

I'm in the process of making a list of a few other types of IR detectors to buy from mouser.com and/or newark.com to experiment with and see what are the characteristics of CaptureIR with various devices. Most of those are demodulating. I expect CaptureIR would work with such devices but haven't tested yet. Of course that limits you to around +-10% of the modulation frequency of the part you choose.

John,

I received my QSE158 from mouser, and want to build a CaptureIR device. How do you recommend building it with that part?

[johnsfine]

1) Make sure you know which pin is which. I'm pretty sure Tommy's diagram (in "How to build an IR Probe.doc") is correct. I fried one QSE158 by connecting it backwards. The PDF file from Fairchild looked to me like it showed the opposite pinout that Tommy had, so when it wasn't working I purposely reversed it from what Tommy showed and thus fried one.

2) Select your source of + voltage. Tommy's design uses a control pin (pin 1 of the printer port). I had mixed results with that design. I think it was a factor causing imperfect captures. But you probably won't care about capture quality as much as I did. Using pin 1 for power will have varying success by PC. Your results may be better or worse than mine. Pins 14 and 17 are control pins that ought to be in the same state as pin 1 if you want a control pin but not pin 1. External 5V would be more robust, but more trouble.

3) Select your IR data pin. CaptureIR should work with any printer port data pin (pins 2 through 9) or any printer port status pin (pins 10 through 13 or pin 15). I think a status pin would work better, because there is less risk of signals fighting each other when the port is misprogrammed and/or returned to the control of an ordinary printer driver.

If we ever want to try using the same hardware for remote control of the PC or for a CaptureIR with less overhead, we'll need to use the printer interrupt. I don't know if that will work at all, but if it does work at all that is only on pin 10.

4) Select a ground pin. On most printer ports any pin 18 through 25 is an equally good ground.

One more factor in selecting pins: For my main CaptureIR setup I find it very convenient to have my JP1 cable connected at the same time my captureIR cable is connected. I built it so both connect into the same DB25 connector and shell with seperate cables sticking out of that shell. That means the choice of printer port pins should not overlap. I don't have the JP1 cable design handy so I forget what pins you'd need to avoid.

Having decided all that, it may be as simple as soldering three wires into the DB25 end of your existing JP1 cable and the other ends of the three wires into the QSE158. Think though how long you want those wires to be in order to avoid tangles but reach some convenient place where you can secure the QSE158 pointed toward wherever you'll have the remote being tested (probably near your keyboard for typing in notes as you see test results).

For my third build of captureIR hardware, I opened the back of a solderless breadboard and soldered (bizarre use of solderless breadboard) 18 wires from a printer port cable plus 4 wires from a USB cable. Having glued that mess back together, I can now plug any IR detector into any printer port pins working on just the solderless side of the solderless breadboard. That also lets me measure voltages and swap in and out extras such as a pull up resistor. I need a pull up resistor to get a QSE158 to work right on a data pin on the computer that hardware is usually on. I think that is printer port damage from earlier misuse, so you won't need a pull up. But I'm not sure. On status pins I don't need the pull up.

If you can think of a practical way to bring the printer port signals you might want out to some form of solderless connection to the QSE158, I think that would be a good idea to trouble shoot the initial process.

[dangerous]

I seem to have started a riot of interest!

The IR devices available in the UK are diferent, but I can readily obtain a Honeywell device which is open collector with a 10K pullup, contains a schmitt trigger, and is not tuned. This is very similar to the Fairchild device. I was able to obtain mine through Radiospares. Farnell (UK) only keep the active low Fairchild device.

It may be possible to use a PIC as an interface quite easily from either USB or serial ports of a PC. Elektor published a remote code decoder in October 2001, and reprints are still available. This used a Philips micro but details of the RC codes are given in depth. Details are at:
http://www.elektor-electronics.co.uk/De ... earchText=
It costs £1 (about $1.60) to download the pdf file.

The PIC range includes several USB devices, and for personal or small production runs (I believe up to 10K) there is no charge to use Microchip's HID.

FTDI do a USB to RS232 chip which is readily available but is only for that function. It is 8051 based. There are I2C & SPI versions as well, so anyone well versed in 8051 may prefer these, or various Atmel uCs.


There is an excellent development program for Microchip PIC flash parts, (and some Atmel parts) which is free for up to 2K of code, and that is a lot for PICs.

If you play with a PIC take a look at http://www.mikroe.com/. The devlopment software comes in three flavours: C, Pascal or Basic. The IDE includes an excellent serial port terminal HID writer and USB port reader/writer. There is also a software simulator although the current version has a problem with this, but a revision is to be released any day soon (or so they say.)

They have an excelent forum, along similar lines to this one. I have no connection with them, but have used Mikrobasic for about 2 years with good results.