JP1 Remotes

Hello

I was pointed here by one of this forums' members in regards to something i wish to build. I hope my post is in the correct area..

I use a replaytv, which didn't talk to my cable box all that well, not due to having the wrong remote codes, but due to the cable box being very sensitive to long delays between digits that replay was sending.

So i built a translator based on an atmel microcontroller which takes the replay's mangled output, cleans it up and resends it. It is currently hardcoded to only work with my particular hardware setup.

Thinking on from there, i decided it would be a good idea to make this thing take input and translate it to any output. Then i decided it would be a good idea to get the output data from jp1, since it seems to be the format with the most support and data archive.

So i have a few questions:
1) does this sound interesting/useful to anyone here?

2) how often do you people run into IR that is modulated to something OTHER than 38khz? I have never seen it, but i know it exists. is it popular? I currently use a hardware demodulator, and if lots of different systems use different modulations, i will have to switch to software demodulation.

3) where can i find data about the contents and formatting of a jp1 file? I have looked at them in notepad, but only some of it makes sense to me. I am interested in the preceeding data, the bitpattern for the data, and the post-bit pattern data, and then the repeating data.

4) i am sure to have more questions. What is a good spot for discussion?

Background on my device: I am using a motorola QIP2500 cable box. It operates at 38khz modulation. It has space for 32 bits of data, but i've only ever seen it use 22 at the most (tho i never tested the misc. buttons, only 0-9 and enter).
To get the bit pattern data, i used a digital oscilloscope connected to an IR receiver/demodulator to clean up the signal.

It seems the norm here is to use a learning universal remote with a jp1 connector and then download from that... very clever.

Not an expert by any means but I can offer some feedback.

3) There isn't a JP1 file per se but really several different file types for several different tools. To explain the files you kinda have to understand the process. There are typically 2 things used to work with our remotes.

1- IR, This program is used to upload to and download from the remotes. You can see Device codes, Device upgrade, Protocol upgrade and do some setup of keymoves and macros. This program uses .ir files.

2- KM or RM, KM is a spreadsheet and RM is a java app but both serve the same purpose to create the Device upgrades needed for IR and Protocol upgrades if needed. You Select the properties you need like the protocol, device and sub-device numbers and then setup functions and map them to buttons on the remote. Km uses text files and RM uses .RM files but can open up the KM text files too.

Neither of these is really going to be easily usable for you since either is going to rely on code in the protocol built into the remote or in the protocol upgrade to actually generate the signal based on the protocol, the device info and button code which you would have to duplicate to get anything usable outputted from your device. What your probably going to want to use is Pronto hex which is basically a representation of the actual signal sent.

There is a program called makehex which can be used to generate pronto hex from the info in a Km or RM file. You basically select a protocol and tell it the device/sub-device info and the codes for which buttons you want.

ericscottf wrote: i decided it would be a good idea to get the output data from jp1,

I'm not sure I know which you mean by "output" and I have no clue what you mean by the whole phrase.

As I've said every time similar discussions start, I think you would have a much better design if you based your signal generation on IRP notation. Sorry I never got around to creating a central document on IRP notation. It is discussed in many threads here, and I think there are documents available somewhere that Jon Armstrong wrote.

The best collection of IRP notation for specific IR protocols is in the DecodeIR.dll documentation at:
http://john.fine.home.comcast.net/ir/DecodeIr.html

ericscottf wrote:since it seems to be the format with the most support and data archive.

I'm pretty sure you would find Pronto Hex to be the format with the largest amount of online data. LIRC is also pretty large. The JP1 online data might be as big as LIRC. The JP1 data is better organised within each file and thus might be a better basic source.

ericscottf wrote: So i have a few questions:
1) does this sound interesting/useful to anyone here?

I'm always interested in such projects. I often answer posts from people who want various IR translation. I don't know of any great answers for them.

ericscottf wrote: 2) how often do you people run into IR that is modulated to something OTHER than 38khz?

Pretty often. Look through that DecodeIR.dll documentation I mentioned. Some notable items:
RC5 and RC6 and all the related protocols (MCE, etc.) use 36K
Sony uses 40K
RCA uses 58K
Panasonic_old (most often seen in Scientific Atlanta cable boxes now) uses 57.6K
The protocol from the Motorola MC44107 chip (mainly used in European brands) is usually generated at 31K.
There are lots of other examples of non 38K, and some examples not modulated at all.

ericscottf wrote: if lots of different systems use different modulations, i will have to switch to software demodulation.

1) I'm not convinced a translator needs that wide a range of input protocols. A wider range of output protocols is more important.

2) Software demodulation is harder than you would expect.

3) All the unmodulated IR detectors I've tested have really rotten performance. They work decently over only a very narrow range of signal strength, which translates into working over a narrow range of distances the longest of which are too short for normal use. Modulated IR detectors work much better.

4) Modulated detectors are documented as not very picky about frequency. When I've tested them, they seem to be even less picky about frequency than documented.

ericscottf wrote:where can i find data about the contents and formatting of a jp1 file? I have looked at them in notepad, but only some of it makes sense to me. I am interested in the preceeding data, the bitpattern for the data, and the post-bit pattern data, and then the repeating data.

I'm guessing you mean upgrades in .rmdu files and KM txt files. That does not include any of the bitpattern info you want.
The best place to go for the capability to read those files is the Java source code for RemoteMaster.
Those .rmdu files and txt files give a high level view of the info: The protocol name and its parameters, and the function number for each function. That should be combined with the appropriate IRP information to get the bitpattern level info.

I'm guessing you don't mean the learned signals in .ir files. Those do have the bitpattern info you want. But the available archieve isn't big nor well organised. There is also Java source code in RM for reading that.

In both cases, that Java source code will be a much easier starting point than the original Excel and Pascal programs, even if you don't want to end up using any Java.

ericscottf wrote: 4) i am sure to have more questions. What is a good spot for discussion?

I don't know. If Rob thinks otherwise, I expect he'll move this whole thread.

ericscottf wrote: To get the bit pattern data, i used a digital oscilloscope connected to an IR receiver/demodulator to clean up the signal.

You definitely want to look at CaptureIR.

ericscottf wrote: It seems the norm here is to use a learning universal remote with a jp1 connector and then download from that... very clever.

I don't understand why all those people don't also want to use CaptureIR. It is SO MUCH BETTER than downloading from a learning remote.

Yes, it isn't worth the trouble for an ordinary JP1 user to get captureIR hardware (which you already have, you just need to connect it to your printer port instead of to your digital oscilloscope, if it isn't already).

But other JP1 experts would find JP1 experimentation much easier if they were looking at the results via CaptureIR.

The JP1 upgrade files are not designed to be viewed using Notepad, the *.rmdu files should be viewed using the RM java program and the rest of the files should be viewed using the KM spreadsheet program.

In the JP1 world there are 2 parts to an upgrade, the first part supplies the data and the 2nd part defines the protocol. In many cases, the 2nd part doesn't need to be supplied if it's already resident in the remote's ROM memory.

The following may help you understand the format of an upgrade...
http://www.hifi-remote.com/forums/viewtopic.php?t=8663

The Robman wrote:the rest of the files should be viewed using the KM spreadsheet program.

RM can view almost all the files written by KM. RM has a friendlier GUI for a new user (anyone not already used to KM). Since ericscottf seems to want to be able to write a program to read these files, the advantages of RM over KM are even greater. KM is a truely amazing job of working around the limitations of Excel to use Excel as if it were a programming environment, rather than just a spreadsheet. But (speaking from significant experience) it is a nightmare for an outsider to try to understand its processing.

I should have said "... the rest of the files were designed to be viewed using the KM spreadsheet program." John is correct that RM can view almost all of the text files also.

Okay, that clears some things up and brings up other questions.
There is no such thing as a JP1 file with the data i need. good to know.

I guess what i'm looking for is the simplest way for a user to accomplish the uploading of the data set, as that's the purpose of this device - simplicity.

perhaps i'll simply make it learn from a remote?

The chip i use has a serial port on it no matter what, so having the user able to download the data set to it via com port would be a nice feature. I just have to figure out where to get it from!

What i've determined i need based on what i've seen from the remotes i've worked with:
initial pattern: on for x time, off for x time, on again for x, and so forth.
bit pattern and size: Bits are x number of microseconds long each, and there is a dead space of x microseconds between them
the end pattern, which is similar but not identical to the initial pattern
then the repeat data. Does it repeat the initial part? or just a repeat command? or nothing?
etc, etc.

In order for you to be able to use JP1 files, you'd need to write code that re-creates the IR engine that's in all JP1 remotes, which is probably more work than you're intending to put into this.

As John suggested, using Pronto hex is probably a better idea because it has almost everything that you need built into it, the main part that's missing is the required time delay between button presses, as each Pronto hex string represents one button press. Another part that's missing that you might need is the minimum number of repeats. Again, as Pronto hex is designed to replicate a button, it would be up to the user using that button to decide how long to keep the button pressed down, but in your case there is no user, so your device would have to make that decision.

When we program macros in our JP1 remotes, the remote's firmware elects to hold the button down for 2 repeats.

The Robman wrote: When we program macros in our JP1 remotes, the remote's firmware elects to hold the button down for 2 repeats.

That's something I didn't know.

I suspected something like that was happening in this (long) thread:wkeith's LKP problem, where a user's LKPs were generating 2 keypresses through his IR repeater, but working correctly when not thus processed.

(He solved his problem by using learned signals instead of macros as the "targets" of the LKP - which. as a bonus, is a trick I now use to save macro memory )

This new knowledge clears that up for me, thanks.

ericscottf wrote:There is no such thing as a JP1 file with the data i need.

But there are JP1 files with almost everything you need. I think you should take advantage of them. In most cases, all you need beyond the contents of the rmdu or txt files is the simple IRP string that corresponds to the protocol named in that rmdu or txt file.

I suggest simply including a table of irp strings for all the common protocols within your software package.

ericscottf wrote: I guess what i'm looking for is the simplest way for a user to accomplish the uploading of the data set, as that's the purpose of this device - simplicity.

I think what I'm suggesting would be simplest for the user.

ericscottf wrote: perhaps i'll simply make it learn from a remote?

That's a lot more work for the user and may give lower quality results, and doesn't give you access to discrete codes, and doesn't help in all the cases where the user wants translation but lacks the original remote.

ericscottf wrote: What i've determined i need based on what i've seen from the remotes i've worked with:
initial pattern: on for x time, off for x time, on again for x, and so forth.
bit pattern and size: Bits are x number of microseconds long each, and there is a dead space of x microseconds between them
the end pattern, which is similar but not identical to the initial pattern
then the repeat data. Does it repeat the initial part? or just a repeat command? or nothing?

That way of viewing IR signals corresponds very closely with Pronto Hex. It covers most IR signal systems, but not all.

IRP notation covers a wider range of IR signal systems. It represents the data in a much more concise form, which may be important in memory use on the micro and/or communication. It makes generation of possible discrete codes simpler. It makes automatic correction of poor quality learns practical.

The Robman wrote:As John suggested, using Pronto hex is probably a better idea because it has almost everything that you need built into it,

I didn't really suggest that.
I think Pronto Hex is inferior to using a combination of IRP notation plus the info from RemoteMaster, for the reasons described above and several more.

Also the choice of archive format and PC side processing format is somewhat different from the choice of format on the micro.

It would greatly simply the micro programming to use something like Pronto Hex. That is very bulky, but it is simple to program. Valuing your time as a programmer over memory or capacity issues in the micro, you would choose something very like Pronto Hex as a format on the micro.

But even if you choose Pronto Hex as the format on the micro, you may still prefer to use JP1 files as your primary archive and use an IRP processor on the PC to convert to Pronto Hex before download to the micro.

Puting part or all of the IRP processing on the micro would give greater flexibility and capacity at the cost of more coding effort.

The Robman wrote:the main part that's missing is the required time delay between button presses, as each Pronto hex string represents one button press.

Pronto Hex lacks the ability to represent the rarely used IR feature of a terminating signal (a button release signal), but it is fully able to represent the initial signal, the time before the first repeat, the repeating part and the time between repeats (which before rereading is what I thought you were saying it didn't have).

There is also the issue of delay between functions in a macro, assuming you can translate one input signal into a sequence of output signals. But (allowing enough bulk) Pronto Hex can do that as well. It just isn't a concise or elegant way of doing that.

The Robman wrote:Another part that's missing that you might need is the minimum number of repeats. Again, as Pronto hex is designed to replicate a button, it would be up to the user using that button to decide how long to keep the button pressed down, but in your case there is no user, so your device would have to make that decision.

That's certainly something you need to give serious attention to. But in fact it can be represented (in a very bulky way) in Pronto Hex. It just can't be learned by devices that turn learning into Pronto Hex. That can be represented concisely in IRP notation, but even that won't consistently be enough to solve the issue. You should provide a user level override for duration in the PC GUI when programming the micro for a specific translation.

johnsfine wrote:

The Robman wrote:the main part that's missing is the required time delay between button presses, as each Pronto hex string represents one button press.

Not correct. Pronto Hex lacks the ability to represent the rarely used IR feature of a terminating signal (a button release signal), but it is fully able to represent the initial signal, the time before the first repeat, the repeating part and the time between repeats.

You're describing when a button is held down, I was referring to the gap between seperate button presses. For example, if the user wants to select channel 12 on their STB, they must press the "1" button, then press the "2" button, but an automated process needs to know how long to wait between sending the "1" signal and the "2" signal, and the pronto hex doesn't describe that. It also doesn't describe how long a button needs to be held down in order for it to work. Both of these pieces of information are needed all the time for a device such as the one described by the OP.

You are correct that the pronto format doesn't allow for the "break" signal, but apart from keyboards, this is very rarely used by remotes, so while it is an issue, it's not a major issue.

In theory:
What you could do is have your PC software dynamically code the running program for that device, likely with a number of protocol modules, if not an IRP protocol engine+ device code engine (similar to JP1 upgrade), if you are looking to directly code the IR transmit from the microcontroller.

For receiving, just choose an easy to decode device code the transmitting device will have.

Anecdotally, I was in a not quite similar situation;
I have a Lifetime TiVo I pieced together, but could not get the IR blaster to work, so I put an Atmel microcontroller to work. I basically made it receive serial commands for a DirecTV receiver (TiVo serial port still working), interpreted that, and used the outcome to control a 4051 and 4052 CMOS switches, which closed the button matrix on an OEM remote for my satellite receiver. A JP1 remote could easily be used.

You can see it at
http://www.flickr.com/photos/classicsat ... 929352158/

I won't supply schematics (they are simple, really) or code (a little more complex), as I know it could be used to aid in FTA pirates getting TiVos and ReplayTVs to work with their pirate receivers, something I won't abet.