JP1 Remotes

First. Love this whole hobby. And any help on this is GREATLY appreciated. I can only offer to post the completed device upgrade when finished. However, I need help setting up a Protocol Upgrade.

I'm setting up a RS 15-2116 remote as a gift for a friend. I have set one up for myself all the way through the Extender 3 with Toadtogs, LKP, macros, KM, Device Combiner, etc. so am pretty familiar with the process (including CCF's and their conversion).

My friend has thrown me a curve. A Lumgen VisionPro scaler. I've learned all the keys and added notes for the ones that aren't obvious. The IR file can be found if you click here . I didn't know if you needed it but the TXT file can be found if you click here .

I also found one post from back in February that had some information about the protocol. I have copied the relevant text below. I tried the Protocol Builder but I am WAY out of my league. Is anyone interested in cracking this protocol? Again, any help is greatly appreciated. I sold him on this idea and after he bought a remote I ran into this buzz saw. Of course the scaler is the heart of his HT and all the Toadtogs in the world are useless without this upgrade. Thanks.

Text from prior post in February:

Posted: Sat Feb 21, 2004 11:48 am Post subject: Lumagen Vision

You can find the CCF file here:
http://www.lumagen.com/docs/Lumagen%20Vision.ccf

I have even more detailed info about the protocol available from the manufacturer:

Each of the buttons transmits a message that consists of 13 short bursts of IR. Every IR burst is identical in frequency and duration. Every IR burst consists of 16 cycles of IR at carrier frequency of 38 kHz. The duration of every burst is 400 us. It is the GAP between these bursts that contains the information. There are thee different gap lengths:

short gap are 2.5 ms between bursts
long gaps are 5.0 ms between bursts
the inter-message gap is 11.0 ms long

A logic 0 consists of a 400 us burst followed by a short gap. A logic 1 consists of a 400 us burst followed by a long gap. The first 4 gaps are the preamble, consisting of two short gaps (logic 0), a long gap (logic 1) then a short gap (logic 0).
This is followed by a parity bit to help ensure data integrity. The parity bit will be a long gap (logic 1) when there is an odd number of long gaps (logic 1). A short gap (logic 0) follows the parity.
The next 7 gaps contain the button information, arranged as 4 bits for row (0-15) and 2 bits for column (1-4). After the final information gap there will be an IR burst followed by a long (12 ms) intermessage gap.

For example, pressing the key in the fourth row, third column will produce the code:
0010 00 0011 10 Preamble 0010 - parity 0 - row 0011 - column 10

That CCF file has slightly higher frequency and slightly longer bits than you describe. But not enough different to really matter. I built the protocol in PB (selecting a pid at random) according to the description you gave above. The result was

Upgrade protocol 0 = 01 C5 (S3C8+) PB v3.10
3D 92 11 8B 0E 85 41 04 08 00 C8 09 B0 00 C8 04
CE 15 7C 8D 01 46
End

Next I'll make a protocols.ini entry for RemoteMaster that delivers that protocol, copies a 4 bit MSB device (value 2 in your example) and a 7 bit MSB OBC (row times four plus column), and the only non trivial part: computes the parity bit.

To use all that you'll need to download RemoteMaster, if you don't have it yet, and edit the entry into protocols.ini

Here is the entry to edit into Protocols.ini, sd RemoteMaster can generate these signals. I haven't tested anything other than RM's generation of the parity bit, so my PB work or some other aspect might be totaly wrong. Good luck

[Lumagen]
PID=00 C5
DevParms=Device:4=2
DeviceTranslator=Translator(0,4)
FixedData=00
CmdParms=OBC:7=0
CmdTranslator=Translator(0,7,1) XorCheck(1,0,1,7,1)
Code.S3C80= 3D 92 11 8B 0E 85 41 04 08 00 C8 09 B0 00 C8 04 CE 15 7C 8D 01 46

I added Lumagen to DecodeIR.dll, so you can get the OBC numbers from that CCF of from your learned signals in IR.EXE

https://www.hifi-remote.com/forums/dload ... ile_id=922

Fiddlesticks! I may have wasted some of your time. The link to the CCF was for the regular Lumagen Vision NOT the Vision Pro. The link for the Pro version CCF is here. It may not make any difference but that may be why things didn't match up exactly. I will load up what you created so far, take it over to his house and see if it works. Thanks so much! I will beta the upgrade and report results. I hope this helps you out as much as you've helped me.

picree wrote: It may not make any difference but that may be why things didn't match up exactly. I will load up what you created so far, take it over to his house and see if it works.

Notice I did NOT create a device upgrade. You can't test a protocol upgrade without also having a device upgrade.

To make a device upgrade from this you need RemoteMaster and DecodeCCF.exe and that new DecodeIR.dll

Edit the copy of protocols.ini that comes with RM and add the entry I put above.

Run RM and create an upgrade for Lumagen, device 2.

Run DecodeCCF on that CCF file and edit the output and copy the function names and OBC numbers to the functions sheet in RM.

If you look at DecodeCCF output in an ordinary text editor (rather than a spreadsheet) the columns do not line up. The OBC is the next number after "Lumagen 2" on each line that has that. It is not the number that seems to be under the OBC column heading.

If you use KM manual mode instead of RM, I think EFC numbers in the decode are correct. KM won't know how to do OBC to EFC translation. Also note the fixed data is hex 20.

Fantastic! Works perfectly! Thanks for your help. I didn't realize that KM wouldn't follow along with the new decodeIR.dll. RM worked as it should. I will post a device upgrade for the Lumagen on a 2116 as soon as I can. Thanks again!

picree wrote:I didn't realize that KM wouldn't follow along with the new decodeIR.dll.

KM, RM and DecodeIR are all seperate software projects with seperate developers. I added Lumagen support to DecodeIR because of this thread. There's no way for KM to suddenly have support for something just because I added it to DecodeIR.

One advantage of RM is that it's protocols.ini structure is designed to make it easier to add protocols, even for someone other than a developer of RM. I was one of the RM developers (not the major one) so it was doubly easier for me to add RM support than KM support: I know RM better than KM and RM is easier for new protocols than KM.

But, KM has manual mode. So if you knew KM just a little better than I remember it, you could do nearly the same thing in KM. (Using EFC instead of OBC as I described before).