JP1 Remotes

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:
https://www.hifi-remote.com/forums/viewt ... 2f3f7494d6
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.

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.

I am guessing that the digit keys are not transferred and they are just assumed to be 1, 2, 3, etc,

Actually you are very close here. If you look at this post anatomy of an upgrade you'll see that there is a numbers tables byte. If that number is not zero, the 10 numbers are defined from one of several predefined tables.

Edited 9:03am CST.

bt101 wrote: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.

Vicky already answered regarding the numeric buttons. For any upgrade there are a few bytes of overhead that determine the PID, numeric table entry, the key map bytes, and protocol Fixed Data. Then there is one byte (or 2 for 2-byte protocols) for every button specified. That's why upgrades make the most efficient use of space.

bt101 wrote: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 can't help you at all in understanding what it is in a protocol specification or an executor's contruction that determines when and how a signals will repeat, BUT....

from a simple "user" perspective, unless you have some bizarre signals, the decoded information for your learned signals is adequate to have you select exactly that information when constructing a device upgrade (Protocol, Device, Sub-device - in this instance, Protocol being the key) and you don't have to do ANYTHING to specify repeat behaviour. The selected protocol will do what it needs to do for repeating fuinctions (like Vol=/-) and will not repeat where not required (like Power).

Are you having a problem with an upgrade which does NOT repeat when it ought to? If so, upload and link to any germane IR and KM/RM files and someone will have a look.

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.