Apple TV in XBMC mode for 6131 help

[tildajones]

Just a quick update.

Sorry for the delay; work and life are getting in the way of my much more important hobbies.

I am working with an XBMC developer in exploring two options for accomplishing this task.

Apparently, I am the only one experimenting with the Universal Remote mode (at least, that they are aware of). The Harmony users use a multi-remote mode to accomplish this by sending the Apple Remote ID followed by one of the six original ir codes.

I see no reason why we cannot just do the same thing the Harmony guys did.

From MaestroDD:
Every AppleRemote has an ID that is sent with each button press. It's an 8bit value so range is from 0-255 (maybe some are reserved?). The remote API exposes that ID. Normally the ID is used to pair the remote with your Mac like this: Doing the "pair" thingy with the remote (something like menu + done?) increases the ID on the remote and tells your mac to listen _only_ to this new ID.

Now we're using this in a different way. Instead of only interpreting the button-code, we're actually using the button-code + remote ID (thus there are ~255*8 buttons). The Harmony (in PlexPlayer mode) sends the default button codes but with different remote IDs which are then mapped to xbmc actions (this is hardcoded in XBMCHelper).

I am working to acquire this harcoded mapping from him; so, we will know which button ids correspond to which Apple remote id + ir code.

This sounds like a viable option to me to get away from the multi-signal sequences (which has been slow going).

[tildajones]

I have acquired the button id mapping.

Essentially, device ids 150, 151, 152, 153, 154, 155, 157, 158, 159, and 160 are mapped in blocks of 10 defined by the offset. They iterate the array of device ids and increment the offset by 10 to determine the button id.

Such that:
device id 150 + up button == 1
device id 150 + down button == 2
device id 150 + left button == 3
device id 150 + right button == 4
device id 150 + center button == 5
device id 150 + menu button == 6
device id 150 + center hold button == 7
device id 150 + menu hold button == 8
device id 150 + left hold button == 9
device id 150 + right hold button == 10

device id 151 + up button == 11
device id 151 + down button == 12
device id 151 + left button == 13
device id 151 + right button == 14
device id 151 + center button == 15
device id 151 + menu button == 16
device id 151 + center hold button == 17
device id 151 + menu hold button == 18
device id 151 + left hold button == 19
device id 151 + right hold button == 20
...

Then using the keymap file, we can map the physical buttons to the same button ids as the Harmony does.

[The Robman]

If I understand you correctly, you are saying that we can scrap the multi-button strings and use this approach instead, where the device code & command code combination tells the device what to do. Is that right?

Here is the binary for the original 6 buttons:

01110111 11100001 01010000 00100110 - Up
01110111 11100001 00110000 00100110 - Down
01110111 11100001 10010000 00100110 - Left
01110111 11100001 01100000 00100110 - Right
01110111 11100001 11000000 00100110 - Menu
01110111 11100001 10100000 00100110 - Select

As you can see, there are three bytes of fixed data, do you know which of these is being manipulated for this new approach? Also, do you have to use device codes in the range 150-160? Would it be possible to use 144-159 instead, because that range works better in the binary world?

[tildajones]

If I understand you correctly, you are saying that we can scrap the multi-button strings and use this approach instead, where the device code & command code combination tells the device what to do. Is that right?

Yes; it appears we can scrap the multi button sequence stuff and go with this approach.

Here is the binary for the original 6 buttons:

01110111 11100001 01010000 00100110 - Up
01110111 11100001 00110000 00100110 - Down
01110111 11100001 10010000 00100110 - Left
01110111 11100001 01100000 00100110 - Right
01110111 11100001 11000000 00100110 - Menu
01110111 11100001 10100000 00100110 - Select

As you can see, there are three bytes of fixed data, do you know which of these is being manipulated for this new approach?

From what I have read, the last 8bits determine the device id. I have not proven this. The easiest way would be to use a tool that will display the current device id of the paired remote (I believe iRed lite can do this) and dump the codes. Change the device id pairing (holding menu and right for 5 seconds) and dump those codes. The only difference in the binary should be the location of the device id.

Found this: The Magic of Apple Remote's IDs

Also, do you have to use device codes in the range 150-160? Would it be possible to use 144-159 instead, because that range works better in the binary world?

Unfortunately, if we want to piggyback on the Harmony work, we are stuck with those device ids. However, I am in contact with the XBMC developers, and we could submit a C++ patch to the XBMCHelper application to use different device ids for a jp1 mapping. I do know that some of the device ids are reserved; so, this would be quite a bit of work.

[tildajones]

On a side note, I received my two Broadcom Crystal HD chips yesterday and have them both installed in my ATVs.

I have tested Elephants Dream @1080p and Killa Sample.

Killa Sample stutters, but Elephants Dream plays smoothly 90% of the time. Not bad for alpha code.

The chip can certainly handle it; work is still being done on the osx driver.

[The Robman]

If we stay with the Harmony system, do we really need to include device code 160? Are there any functions defined with that device code (ie, button ids 101-110)?

[tildajones]

If we stay with the Harmony system, do we really need to include device code 160? Are there any functions defined with that device code (ie, button ids 101-110)?

The keymap file does not use button ids 101-110. Either way, we can provide users with 100 buttons rather then 6; so, that is a marked improvement.

[vickyg2003]

I am more than a little confused because this is so different from what we were trying to do before.

Would it be possible for the Harmony upgrade to be passed along to another Harmony user? I'm thinking someone with a Harmony and a widget (like Alan Richie) might be able to capture a few of these signals for us to make sure we are interpretting this correctly.

[tildajones]

I am more than a little confused because this is so different from what we were trying to do before.

This method is completely different than what we were doing before. I feel like this is a better way to accomplish the goal, and we no longer have to play with sequence timings.

Would it be possible for the Harmony upgrade to be passed along to another Harmony user? I'm thinking someone with a Harmony and a widget (like Alan Richie) might be able to capture a few of these signals for us to make sure we are interpretting this correctly.

If I am reading you correctly, you are asking if a Harmony user who also happens to be a JP1 user can load the Plex codes into their Harmony and use a tool to see the signals.

Yes, a Harmony user can simply load up the Plex configuration from the Logitech app's database (Create a new device of type "Media Center PC", brand Plex, and type "Plex Player" into the box). Plex is a branch of the XBMC code base and uses the same codes for the Harmony as the XBMC app does. The reason the codes are listed as Plex Player in Logitech's database is because Plex branched from XBMC to offer Harmony support as well as some other functionality. The Harmony support was merged back into the XBMC codebase afterward.

[alanrichey]

OK, done that for you. Wierd results

IR Scope is consistently coming up with Gap-582-1676-32? as the IR Protocol and 238.135 as the Device/Sub-Device.

The keycodes are sometimes different, sometimes the same. For example, '1' & '2' both give a Key code of 151, but in the 'Misc' column the '1' key gives EE.87.A.97 and the '2' gives EE.87.C.97.

Anyway, I have zipped up half a dozen 'learns at https://www.hifi-remote.com/forums/dload ... le_id=8056 The ICT files are named by the button and the Keycode IRSCOPE gives.

Let me know if you need anything else.

Cheers

Al

[vickyg2003]

Thanks Alan, seeing the wave makes things a little clearer for me. With these GAP signals we are more concerned with the MISC column.

[vickyg2003]

I had a chance to look at Alan's learns and can see that the last byte is the "device byte".

From my previous work I had used an IR file with the same Apple TV codes that Rob posted above.
fixed fixed function
01110111 11100001 01010000 00100110 - Up
01110111 11100001 00110000 00100110 - Down
01110111 11100001 10010000 00100110 - Left
01110111 11100001 01100000 00100110 - Right
01110111 11100001 11000000 00100110 - Menu
01110111 11100001 10100000 00100110 - Select

IR shows these valuses in the MISC window
Up = EE.87.A.64
Down= EE.87.C.64
Left = EE.87.9.64
right = EE.87.6.64
Menu = EE.87.3.64
Select = =EE.87.5.64

With the learns that Alan did for us, the
Ch UP = EE.87.A.9E (9E being device 158)
Power = EE.87.3.9D
1 = EE.87.A.97
2 = EE.87.C.97
5 = EE.87.9.98

Where I get confused is the RED key

RED = EE.87.8.9F

So where did the 8 come from? If this is how a HOLD keypress is supposed to send, this could explain why TildaJones whas having so many problems with the previous XBMC keys.

Edit: Red is supposed to be key 83, which if I understand this should be 158 9 (the key for LEFT, not a hold key), so maybe this is just an error in the harmony plex code? I looked back through the keymap code and don't see anywhere where they are using codes x7, x8, x9 or x0, so maybe there are only 60 possible codes not 100?

[tildajones]

I had a chance to look at Alan's learns and can see that the last byte is the "device byte".

Thanks for confirming this.

Edit: Red is supposed to be key 83, which if I understand this should be 158 9 (the key for LEFT, not a hold key), so maybe this is just an error in the harmony plex code? I looked back through the keymap code and don't see anywhere where they are using codes x7, x8, x9 or x0, so maybe there are only 60 possible codes not 100?

It is possible that there are errors in the harmony plex code.

I came up with the 100 number because of the way the XBMCHelper is written; it handles held buttons differently than just pressed buttons. I will continue to research this and report back with any developments.

I greatly appreciate everyone's assistance on this. These kinds of challenges always interest me; it's refreshing to find like-minded, curious people.

Edit
Just found this thread that delves more deeply into the binary of the Apple IR protocol. From what I have read thus far, they state what we have already found:

Bytes 1 and 2 are standard for all codes
Byte 3 defines the button
Byte 4 is the device id

[vickyg2003]

Tilda,

here is an upgrade for you to play with this weekendh. I think it sends out the proper signals, but if it doesn't seem to work, I'll recheck it against the limited # of learns we have from the harmony plex.

https://www.hifi-remote.com/forums/dload ... le_id=8073

[tildajones]

Tilda,

here is an upgrade for you to play with this weekendh. I think it sends out the proper signals, but if it doesn't seem to work, I'll recheck it against the limited # of learns we have from the harmony plex.

https://www.hifi-remote.com/forums/dload ... le_id=8073

Excellent!

Looks like I will have an opportunity to experiment with it today.

edit Well, I double checked your label to button id mappings, and everything looks solid. When I went to test it out and loaded the protocol and device in ir, I was warned about running out of macro/key move space for my 8811. Ugh. Knew this was going to happen eventually; so, I also took my first crack at installing an 8811 extender. It rules! Just the allocation of learned eeprom space to move/macro was worth it; not to mention all the flexibility in macros and button assignments. Anyway, with the extender nailed down, I can get back to work on testing the upgrade.