add discrete code and add unused buttons

[sensismile]

Hi all,

first thanks to Tom for the fast and secure delivery of the JP1 Cable to Germany !!! (the one to 69493)

I own two 6-Device Kameleons (european model) and like to customize them by using the JP1 Interface. I've allready read some (or even all) doc's for beginners, but have still some questions.

My Goal is to add discrete on/off and Video-Input codes for my Pioneer Receiver (AUD/1023) and to add some not used buttons for my TV/Sat (Sat/Cabl/0879) Setup.

The Things I allready know is :
-Load the Remote to the PC
-Add/Edit/Delete Keymoves
-Add/Edit/Delete Macros
-Create / Load / Delete Updates/Protocols
-Save back to the Remote

For the receiver I allready made an update with the 3 discrete codes ( I know them from learning from another remote). But is it possible to create an upgrade which adds these 3 codes to an existing setup without using a new setup and place them by the keymover function to the right place ? what I mean is to "inject" the 3 keys into the setup.

On The TV Side I need some additional keys. I know this setup sends a RC5 Signal and I can decode or recognize the signal with the PC (The PC actual is the Software SAT Reciver Box with a digital Sat Board). Now I like to add some "free" rc5 codes to unused Buttons. I like to add some with the same Device ID (24 in my case). I can see all used codes from the device on the PC (like Jul 21 20:19:45 voyager kernel: #########00000e12######### addr 24 data 0x12 (keycode 103)) - I like to add some whichj are not allready used - How should I do that ?

Thanks in advance
Stefan

[johnsfine]

But is it possible to create an upgrade which adds these 3 codes to an existing setup without using a new setup and place them by the keymover function to the right place ? what I mean is to "inject" the 3 keys into the setup.

You seem to be describing ordinary KeyMoves, for which you don't need an upgrade. I assume the problem is that AUD/1023 uses two byte hex commands rather than EFC numbers. So you need to use hex command rather than EFC when creating the KeyMoves. But the decodes of the learned signals don't tell you the hex commands.

The easiest way is to start to create an upgrade in KM or RM and use the functions sheet to compute the hex commands. Then you don't need to use that upgrade, just use the hex commands.

The protocol used in that upgrade must match the one (AUD/1023 I assume) that will be used by the KeyMoves. AUD/1023 uses the Pioneer 3DEV protocol.

[sensismile]

Wow that was fast -

I understand - I use Keymove but not with a "real" device as source just with the commandos I need. Btw the leraning dont's show me the exact protocol (it shows NEC in 2 from 3 cases) but with the Pioneer (the protocol the 3rd learned function shows me and the EFC's from all 3 it worked fine. And it shows HEX Commands in all 3 cases - I will try them right now and come back to you as soon as the first goal is archieved - THANKS again...
Stefan

P.S. Is anyone from you Pro's available in any chat system like icq, msn or even irc

[johnsfine]

I like to add some "free" rc5 codes to unused Buttons. I like to add some with the same Device ID (24 in my case). I can see all used codes from the device on the PC (like Jul 21 20:19:45 voyager kernel: #########00000e12######### addr 24 data 0x12 (keycode 103)) - I like to add some whichj are not allready used - How should I do that ?

You can either use KeyMoves (to add to SAT/0879) or create an upgrade (to replace SAT/0879).

If you use KeyMoves and want to stay with device 24, you need a way to compute the EFC numbers, because only 64 of the 256 possible EFC numbers in SAT/0879 will produce RC5 commands for device 24. Most will produce commands for device 31 (why does your PC care whether the device number is the same?)

Use KM or RM and start to create an upgrade for RC5 protocol. In KM you would switch to OBC mode, and on the functions sheet put a number from 0 to 63 in the OBC column and leave byte2 blank. It will compute the EFC for you. The OBC is the decimal value corresponding to the hex "data" value your PC decodes. Your example of hex 0x12 is decimal 18, which is the uparrow key from SAT/0869. SAT/0869 uses 29 of the 64 possible OBC numbers, the largest of which is GUIDE=53, so all of 54 through 63 are available (as are 20 through 28).

[johnsfine]

I understand - I use Keymove but not with a "real" device as source just with the commandos

I'm not sure what you mean. But it doesn't sound like you understand.

A KeyMove needs a source setup code and a hex command. It gets the protocol and device information from that setup code and gets the key specific information from the hex command.

An EFC number is OFA's way of encripting a hex command, but it only covers one byte of a hex command, so it isn't enough when a hex command is longer.

I need. Btw the leraning dont's show me the exact protocol (it shows NEC in 2 from 3 cases)

Those are probably bad learns, but good enough to show the right device and command numbers and could easily be good enough to work.

The Pioneer protocol uses a basic frame which is very similar to NEC2. The decoder reports a protocol of NEC when there isn't enough information to distinguish NEC1 vs. NEC2.

the EFC's from all 3 it worked fine.

I don't understand how. Did you test EFCs directly on the remote itself, or
using KeyMoves, or in an upgrade via KM?

Directly testing EFCs in a 2 byte protocol occasionally works but not often nor reproducibly. EFC KeyMoves for a 2 byte protocol are even less likely to work.

In a KM or RM upgrade, depending on which Pioneer protocol is chosen, the other byte might not be necessary, or KM/RM might default the other byte correctly.

And it shows HEX Commands in all 3 cases

The HEX command displayed there is redundant with the EFC. It is only right if the EFC is right. There are several different protocol executors for Pioneer signals. Whether the EFC is right depends on which one you choose in an upgrade. The one in AMP/1023 has two byte hex commands so no EFC alone is right. The OBC value is a characteristic of the actual signal rather than of the protocol executor used to send the signal so it is consistent across all the ways of creating a Pioneer upgrade.

[sensismile]

Hmm don't work - where is my fault ?

ok what works is -

create an upgrade - protocol pioneer, device 165. Add 3 functions :

ON:EFC:251
OFF:EFC247
Device TV: Efc:052
asigne the fuctions to buttons

-WORK-

what's not working is :
use the Keymover to add virtual functions (like I've understand your first reply) -
Add Keymover
Device Aud
Key 2
Fuvtion to perform :
Device Aud
Code 1023
EFC/Hex Command : 052 or $CF

What am I doing wrong ???

Regarding the RC5 device - I could configure the PC to listen to one or to all rc5 devices. I can't listen to all adresses because my TV-Set is using RC5 too ! So I've configured the PC to listen only to one device.

Thanks Stefan

[sensismile]

how do you know this :

>SAT/0869 uses 29 of the 64 possible OBC numbers, the largest of which is GUIDE=53, so all of 54 through 63 are available (as are 20 through 28).

Thanks
Stefan

P.S. I use RM cause I don't have excel installed ...

[johnsfine]

ok what works is -

create an upgrade - protocol pioneer, device 165. Add 3 functions

That makes sense (that this method worked for those functions). And now I know the device and commands you want.

what's not working is :

...

EFC/Hex Command : 052 or $CF

Those need to be two byte hex commands, not EFC nor one byte hex command.

I'm not very expert with Pioneer Protocol, so I'm not 100% sure but I think the three commands are:

ON: 27 48
OFF: A7 48
Device TV: CF 48

[johnsfine]

>SAT/0869 uses 29 of the 64

I meant 0879 of course.
Sorry, there's no available source for finding that sort of detail. I just happened to have it. For many setup codes that sort of info is in devices4.xls, but not this one.

P.S. I use RM cause I don't have excel installed ...

RM's UI for RC5 only makes sense if you enter the device number info on the setup sheet before using the functions sheet. To match SAT/0879 you need Device_1 set to 24 and the "OBC>63" box under that NOT checked. After that, you can enter the OBC on the functions sheet and see the EFC.

[sensismile]

Wow looks like the RC5 Problem is solved !!!

OK I did some trial and error on the rc5 till I found a value that matches -It works and I can find the missing codes but I can't see a relation between the code which is detected by the PC and the code I try to configure by IR / Rm - would I mean is :

calculated by Rm EFC:047 / Dev:24 OBC<64/OBC:20/Hex:ac
receivedby PC : #########00000614######### addr 24 data 0x14 (keycode 0)

where is the relation between the 0x14 and the codes calculated by RM ?? I mean it is possible to find anythin I need - I just like to know if there is a relation.

For the Pioneer codes it doesn't work - where is the difference between the one byte codes used when creating an upgrade and the two byte code when use the keymover ? I still don't get it - SORRY

Thanks
Stefan

P.S. This is the fastest Thread I ever was on ..

[sensismile]

ok I found the answer - I must be blind - It's just the OBC in Hex form -


Thaks
Stefan

[johnsfine]

For the Pioneer codes it doesn't work

What exactly "doesn't work"?

I'm not sure which of my posts you'd seen when you said that.

- where is the difference between the one byte codes used when creating an upgrade and the two byte code when use the keymover ? I still don't get it -

It's one of the trickier aspects of JP1.

There are several different ways to create an upgrade for Pioneer signals. They have different hex commands.

You made a simple Pioneer upgrade for only single part signals with device number 165, so the hex command communicates just the command number.

The setup code Tuner/1023 is for combinations of devices 162, 164 and 165, so the hex command communicates the command number and the selection of device number and (IIUC) whether the signal should be single part or multi part.

[sensismile]

it was this one which doesn't work :

Device TV: CF 48

RC5 Goal is reached - Very thanks for that !

now only the pioneer thing is missing.

This will be my last post for today - I'm going to bed now -

Thanks again - I will continue on the Pioneer Topic tomorrow

n8
Stefan

[johnsfine]

I used KM to compute those two byte hex commands. I'm not expert enough in Pioneer protocols to be sure I (or KM) didn't make a mistake. I was hoping to load the upgrade I used for that into one of my remotes last night and learn the signal to another remote, which would tell for sure whether that two byte hex command was right. I didn't have time.

But I think it is more likely you made an error in creating the KeyMove. You can save an eeprom image file containing the KeyMove you tested (for CF 48) and upload it to the Yahoo JP1 diagnosis folder, and post a URL back here. Then any of the experts here can load that file into IR.EXE and see if the KeyMove is right.

I'd like to know why the two byte keymove using AUD/1023 didn't work. But there is another way to get those three signals to work (that just wastes a little upgrade memory vs. using AUD/1023). Earlier you said you tested an upgrade for those three signals. You can reinstall that upgrade, but not assign it to any device key, and use that setup code as the source setup code for ordinary KeyMoves using the EFC numbers you quoted. (I'm assuming that setup code type and number is not a duplicate of AUD/1023 nor any other setup code you will be assigning to a device key).

[sensismile]

Hi again,

yes this is the second way It could be done - is there a special number scheme I should use like starting with 2xxx device numbers or how do I know which number is free ?

Thanks
Stefan