JP1 Remotes

[Mog]

I am trying to create a device upgrade for the Panasonic PT-AE500E projector

I have used the Protocol-Builder spreadsheet to make up a new protocol, and have defined 5 bytes of fixed data as follows: BF FB FE ED FF

I have pasted this protocol into KM 8.23, no problem, and the fixed data is correctly shown in cells C12 and C17

BUT, when I copy the device upgrade data and paste it into IR 5.06,
the fixed data is treated as part of the keymap, and the fixed data area of the dialog is left empty...

The protocol has two command bytes for each key, and I am trying to configure keys as follows:

BF FB FE ED FF_______B1 A2 (Enter)
BF FB FE ED FF_______A1 B2 (Menu)
BF FB FE ED FF_______A5 B6 (Up)
BF FB FE ED FF_______25 36 (Down)
BF FB FE ED FF_______C5 D6 (Left)
BF FB FE ED FF_______45 56 (Right)

After the paste operation, the dialog reads as follows:

#___Keyname_____HEX
1___0____________BF FB
2___(____________FE ED
3___1____________FF B1
4___2____________A2 A1
T8__3____________B2 A5

As you can see, the fixed data appears as part of the first three key definitions

Can anybody help me with this?
( The upgrade is for the Topline URC8550 )

[johnsfine]

IR often makes that type of display error when there are very few buttons defined in an upgrade.

If the upgrade was correct (from KM), the display error doesn't matter.

IR uploads the upgrade to the remote exactly as it received it from KM. IR doesn't need to be able to understand the upgrade. It only tries to understand the upgrade in order to display helpful information to the user.

[johnsfine]

[Mog]

[jon_armstrong]

There is an upgrade in the files for the AE-100.

This is a 56 bit protocol as compared to the usual Panasonic 48 bit protocol. Also if you use the XOR-comp feature and select the third through the 6th bytes you derive the last byte. It will make searching for hidden commands a little easier, although Panasonic has a nasty habit of using multiple sub-devices.

The protocol in the upgrade already does the XOR although the 0/1 values are inverted from what you are using.

BTW, if you post the text file from PB in the diagnosis area it will allow others to see what you did.
_________________
-Jon

[Mog]

OMG!
Well, using that upgrade works fine on the Kameleon for my PTAE500

However, that protocol hasn't exactly made me see the light.

When I look at this protocol using protocol builder, it is shown as having five device bytes, and one command byte,
I guess that it's just the protocol code that generates the extra byte using the XOR method you described.

Would it not be possible to do the get the same result by defining two command bytes, and not bothering with the XOR code?

Also, although I can see that the HEX values on the KM functions page
match the data in byte 6 of the 7 bytes sent, where on earth do the
OBC and EFC values come from (and go, for that matter)?

I understand that the protocol is 56 bit, as I clearly see a sequence of seven bytes.
I can also see that all the 0/1 values are inverted from the examples I gave before

But where is the 'XOR-comp' feature you mentioned?
And how can I get a version of the protocol for the P8/740?

This relates back to my first post:
http://www.hifi-remote.com/forums/viewtopic.php?t=2320

Ultimately, I want to put this device and others yet to be investigated on my Topline8
I can see that I have a way to go before I get to grips with all this

[johnsfine]

[Mog]

Thanks a lot for the speedy replies, guys

I have to say, this is all very impressive stuff, and it looks as if I have
just joined at the right time!
The latest PB looks terrific...

OK, I think maybe I am beginning to see the light.
Hopefully I will get my Topline working with the PTAE500 sometime today... 8)

[mr_d_p_gumby]

You may have problems if you develop your own protocol in PB using an S3C80, and then try to translate it into P8/740 for your Topline. The S3C80-based remotes have a 64-bit transmit buffer, while the P8/740s only have a 48-bit buffer. This means that you cannot use the P8/740 remote's IR engine to generate a 56-bit frame. You might be able to use the P8/740 Direct Calls option in PB, which bypasses the IR engine, but it also generates a larger protocol upgrade.

While it is commendable that you've jumped right into PB, I think overall you'd be better off developing your upgrade using the built-in 00C9 Panasonic protocol if you can. I believe it is present in your Topline (URC-8550 or 5550?).
_________________
Mike England

• JP1 Group at Yahoo!, JP1 Files Area

[johnsfine]

[Mog]

Hmmm, I never seem to get it easy

I have disassembled the PT-AE100 protocol in PB, and get the following:

[johnsfine]

I forget where the "XOR-comp" quote started (I assume in some related previous thread). I just replied to that quote, I didn't verify that XOR-comp is actually correct. The working (I assume) code you quoted seems to be for XOR, not XOR-comp and I think XOR is more likely correct for Panasonic.

Also the code you created with PB for XOR-comp/4-bytes seems to be for too few command bytes. In PB you must set the number of command bytes to include the check byte, not to be the length of the hex command. In this case 1 command byte is in the hex command, but two are in the transmitted data. The code you quoted doesn't seem to get that right.

I think R11 is the number of command bytes (with certain exceptions). The protocol code must change it in most cases in which the length of the hex command does not match the number of command bytes transmitted. I have no idea what the non S3C80 version of that is.

[Mark Pierson]

[mr_d_p_gumby]

Here's a completely untested version of the 56-bit protocol for the P8/740:

[Mog]

First off - thanks a lot for taking so much trouble

It has all been very educational, I must say

Unfortunately, it's not quite working, but I'm not sure if it's something
I did wrong (it's rather late here in the UK now, and I'm getting sleepy)

I appear to be getting the following sequence for every key: