JP1 Remotes

I think we determined way back when that it this protocol was not possible given the size limit in this model of remote, otherwise UEI would have created one.
Sorry for not responding earlier, but what Rob says is true. I looked at various ways to implement this protocol for the 6805-C9 remotes ...

...if there's anybody around here who still knows that old processor (6805-C9). I remember back when we used to program them ol' 6805 processors. It was uphill. Both ways. In the snow. :roll:

Seriously, though, it would take some time to attempt this as the protocol code is quite large, and the ...

Is the one without "VariantName" actually 0173:2 or do we actually have 3 variants: 0173, 0173:1, 0173:2? By JP1 convention, 0173 without a variant number will be assumed to be variant 1 by default (0173:1). Until we actually identify more than one variant, most PIDs omit the variant number. So ...

I don't understand most of the RDF parameters, so I just copied the original Nokia32 entry and adapted VariantName and Code.MaxQ610. What is the difference between 0173 and 0173:1? Variant 1 has an option to send a final frame with bit 7 of the 4th fixed byte toggled (or set in some versions ...

In KM, I give the user a choice of which to use based on requirements (4, 4X4, 4X4X4). I would imagine protocols.ini should do something similar, but I'm not familiar enough with the various command translators to know if a new one is needed, or if an exisitng one could be used. I would think that ...

I don't believe there's any logic difference between variants 3, 4 and 5, so from a protocols.ini POV they should all be variant 3.

I would like it if someone could confirm that they're all the same though. There are differences, though backward compatibilty with variant 3 is possible if you don't ...

I have been through all the documentation for Protocol Builder but cannot find a simple step-by-step guide on how to import an existing protocol such as :

Code.S3C80=47 93 61 8B 12 87 05 08 04 00 DE 00 00 00 00 00 \
CA D4 44 05 35 01 A8 0C 0A 18 07 02 11 10 08 10 \
07 10 09 10 C1 1E 10 08 10 07 ...

Either the RDFs are in error and the supported variant is simply 012A or else there exists S3C80 code for the 012A:2 variant that is not in protocols.ini. Either way, there is an inconsistency that needs to be resolved. Thr RDF files are correct; there certainly does exist an S3C80 version of the ...

That picture is definitely not a Navigator... It does not look like any Navigator I've ever seen, either. One of the weird things between CYC0 and CYC1 versions is that the CYC0 shifted the addresses of most of the protocol data bytes (including DCBUF) up by one. Since the later CYC1 put things ...

vickyg2003 wrote:I can't figure out which of these fixes corrected the JP1.2 Atlas settings problem, but it seems to be corrected. Thanks.

That would be "Fixed bug where unused std button name conflicts with remote button name".

Corrected in KM v9.22.

The latest version of KM ( v9.22 ) is available.
Changes include: Added support for Denon-K protocol.
Updated 0162 DirecTV pcode to smaller versions.
Modified Apex 1100W protocol to use resident 0046 PID. (Still uses hacked version for fav/scan patch if needed.)
Fixed bug where unused std button ...

Noted. I probably used an older incorrect RDF file when the URC-8206 was added to KM. I'll fix this in the next version.

I took a look and even though all the experts say that subdevice doesn't matter, there is a bump missing on the picture.

It seems to me that most of these were 0.1 codes but I can't find the zip file that shows the complete set of learns.

So bottom line, the upgrade as is will not work until I ...

I've looked at the F12 executor, and it sends signals in one of two ways.
1. It can send 2 identical signals and stop, even if the button is held down.
2. It can send 2 identical signals, wait about 80mS or so, and repeat until the button is let up.

Oddly, it decides which mode to use by looking ...