JP1 Remotes

bt101 · Joined: 25 Feb 2008 Posts: 13

Hello - I'm really wearing out my welcome, but here goes...

I have learned a bunch of remotes and now want to take the learned signals and upgrade the 10820 remote with them.

The problem is that several of the keys on the original remotes will repeat when held down (such as volume). In order to achieve repeating, I assume that I must take the learned info and modify it before transferring it to KM.

I've fried my brain studying raw protocols and can see how the raw protocols do the repeating. However I cannot see a relationship between the raw protocols and the basic information that is transferred from IR to KM (info such as OBC, EFC, etc). That is, when you transfer (for example) an OBC from IR to KM, you are saying what key is to be pressed, but there is no information as to how it should be pressed (ie single or repeat).

The closest post that I could find was this:
http://www.hifi-remote.com/forums/viewtopic.php?p=58608&sid=39d6e824a1acd17da65ece2f3f7494d6
In that post, I don't understand how the solution (the particular byte/value) was chosen, but it appears that there is some way to specify repeating.

Is there a procedure to follow to get repeating to work for particular keys? I would imagine that it is a common problem.

A couple of side notes (I'm not looking for answers here, just illustrating my confusion):
In studying raw protocols, I tried to look at the learned information for some of my keys (in the learned tab of IR) and can't find any relationship between that raw info and any of the protocol specifications. I'm looking for header-hex values and burst pairs and am just not seeing it.

I also did an MCE upgrade of the remote where there are something like 35 keys that are defined. The information that is transferred from KM to IR (minus header info) is 25 bytes. I was kinda confused as to how information about 35 keys is transferred with 25 bytes. I am guessing that the digit keys are not transferred and they are just assumed to be 1, 2, 3, etc.

Also, if it helps anybody, a 10 pin IDC connector works great on the 10820. I found a complete cable with ends in my junk pile. The 10 pin connector fits tightly into the remote case. For a little looser fit, a file or sandpaper can be used to remove a half-a-thou from the IDC connector. The remote case centres the connector perfectly on the pins.

vickyg2003 · Posted: Wed Mar 05, 2008 7:22 am Post subject:

I'm trying to get my head around this whole protocol building thing too.
First off, you are probably studying raw signals, not raw protocols. The device upgrade you create in KM or RM contains a protocol ID. I think your remote first checks to see that the device upgrade exists, then it looks to see if the key pressed has been assigned in the device definition. If so, its going to pass the information for this key to the protocol. The protocol processes the key.

Most of the time we just use the built-in protocol. Sometimes we have to build our own? Did you happen to stumble across this Protocol Builder Help in your reading. Some protocols just use variations that can be supplied by calling routines with specific values. Protcol builder will build a simple protocol for you if you provide the standard information. Other times you need to add assembly code. Here in JP1 land, we've made use of the protocols in the special protocols that were developed to do Pauses, Long Key Press, Double key presses, Toad toggling and Device Specific Macros. These special protocols don't provide any signal at all.

I do believe its the protocol that decides the repeat style, not the device upgrade. I've read a lot about this with Nec and Nec1 and Nec2 protocols. This effects me personally, but I have no idea what protocol is giving you the problem.

If you post your IR file, the experts could probably help you understand.

Mark Pierson

Capn Trips · Expert Joined: 03 Oct 2003 Posts: 3990

bt101 · Joined: 25 Feb 2008 Posts: 13

Thanks for the help. The links provided gave me a much better understanding.

I was wondering why nobody else was having the same problem, and you guys seemed pretty sure that the learned codes should have all the required information. Well it turns out that the rest of the world is not crazy, it's just me.

Here's the thing...
When performing the learning, I thought that I should try and only send a clean short keypress from the source remote. Firstly, I thought that a long burst would send junk that would confuse the target remote or fill memory unnecessarily, and I also thought that the short burst would contain all the necessary information. Well, now I see that the target remote can accept a long burst and only grab what it needs to interpret it correctly. In other words...hold that sucker down.

I made things way more complicated than necessary.

Anyway, that was my last hurdle. This JP1 system works great, and the support is fantastic. Thanks.