Apple TV in XBMC mode for 6131 help

[vickyg2003]

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.

The 8811 has a great extender! I don't want to derail you from your project, but make sure to experiment with the features in this extender. The LKP protocol and the temporary device assignments i.e. X_TV are features that really can make remotes easy to use.

If you don't have a bad case of JP1-sickness by now, this extender will probably push you over the edge.

Good Luck

[tildajones]

Quick update:

First try with the new upgrade and protocol is giving mixed results. I am not sure if it is the device upgrade or the keymap file. I have installed a nightly build of XBMC on a MacBook Pro to see if I can get the received IR codes to dump out to the log. If so, I should be able to see exactly where the problem is happening.

[vickyg2003]

Oops! I'll bet this is my problem. I struggle with Right and Left and had orignally designed this as MSB but changed mid stream to LSB's when things were not coming out correctly, I changed to LSB but didn't recalculate the obc's to reflect the LSB structure.

[vickyg2003]

False alarm, it looks good at least to me.



Let me explain what this is supposed to be doing. We want to use 3 digit efc's when possible, especially when there are over 60 functions.

So I combined the function code and part of the device number in the function code and then I use assembly language to put the information in the buffer.

The second nibble of the function hex, is going to the function in reverse.
MSB LSB VALUE
A ----5 --- up
C ----3 --- down
9 ---- 9 ---- left
6----- 6 ---- right
5----- A ---- OK
3----- C----- menu



The first nibble contains part of the Device Number. My assembly code strips that off and moves that to the 4th byte.

We want device codes 150 to 159

0110 1001 = 150 MSB 6 LSB 6
1110 1001 = 151 MSB E LSB 7
0001 1001 = 152 MSB 1 LSB 8
1001 1001 = 153 MSB 9 LSB 9
0101 1001 = 154 MSB 5 LSB A
1101 1001 = 155 MSB D LSB B
0011 1001 = 156 MSB 3 LSB C
1011 1001 = 157 MSB B LSB D
0111 1001 = 158 MSB 7 LSB E
1111 1001 = 159 MSB F LSB F

So if the hex was 96 this would be device 153 + right key

[tildajones]

So if the hex was 96 this would be device 153 + right key

The reason it is 96 rather than 69 is because it is LSB rather than MSB?

[vickyg2003]

The reason it is 96 rather than 69 is because it is LSB rather than MSB?

We don't get a lot of choice in how things go in the buffer. The data portion of this signal, has timimg pairs +550 -574, and +550 and -1674. We determine which one is going to be the 1, and which is going to be 0. and then we fill the buffer with 1's and 0's in the required pattern.

The LSB and MSB thing is something that we use to make the numbers make sense. Since the people that know told us that the Multi-Plex devices were 150-159 we read the signals that Alan captured for us and decided that the timing pairs +550 -574 was a 0 and the pair +550 -1674 was a 1 and that the signals make "sense" read as LSB because we could see the device codes we were looking for.

So our tools convert the OBC's into hex using LSB or MSB logic, but we determined what the OBC's were by deciding what the Hex needs to be.

[tildajones]

Couple of things:

The AppleTV does not differentiate between the various signals. It is treating the base 6 signals exactly the same regardless of the device id. So, either the device id is not being transmitted correctly, or the unit is not mapping the signals correctly. I have removed all custom keymaps and am using the default harmony keymap that ships with XBMC (the one linked in this thread).

Secondly, on the MacBook Pro front, I am able to dump out the received IR signals to the log by running XBMCHelper in verbose multi-remote mode. The original Apple remote works perfectly with my MacBook Pro, but the JP1 remote will not function at all. The machine is not paired to a remote; so, it should respond to any remote that sends Apple signals.

I plan on contacting MaestroDD about debugging the ir on the ATV side. Hopefully, he will have some insight there.

Could there be an issue converting the km.txt device upgrade to rm? I have never had a problem before, but I want to mention that I am using rm rather than km.

[vickyg2003]

Tilda, I've got an 8811 with me. If you post your IR file, I'll load it up and shoot it at the widget to see what is being sent from your remote. I could easily have messed something up when I was buttoning things up and posting files.

I am not surprised that your MacBook can't read these signals. I think they chose the device 150-159 because they were not 'valid' apple device codes.

I also am not surprised that your Apple TV thinks they are all the same code. That would mean that your keymapping isn't in effect.

[tildajones]

Sorry for the delayed response; I have been out of town on business.

Tilda, I've got an 8811 with me. If you post your IR file, I'll load it up and shoot it at the widget to see what is being sent from your remote. I could easily have messed something up when I was buttoning things up and posting files.

The rmdu file I am working on can be found here.

I am not surprised that your MacBook can't read these signals. I think they chose the device 150-159 because they were not 'valid' apple device codes.

I did not realize those were invalid device ids; that would explain why it wasn't working on my MacBook.

I also am not surprised that your Apple TV thinks they are all the same code. That would mean that your keymapping isn't in effect.

At this point, all custom keymaps have been removed, and XBMC should be using the default Harmony keymap. Of course, I have no concrete way to verify this (I have triple-checked that multi-remote/harmony is selected in the remote configuration). Hopefully, MaestroDD will be able to provide some direction on the ATV XBMC end.

[vickyg2003]

Well I would have preferred your IR file, so I could make sure there were no other procedural errors (like learns trumping your upgrade, or duplicate protocol numbers) but I did load up the upgrade and compared it to each learn we had from alan.

These 3 agreed on everything.
Number 1
EE,87.A.97 (DEVICE 151 Button 10)

Number 2
EE.87.C.97 (Device 151 Button 12)

Number 5
EE.87.9,98 (Device 152 Button 13)

However there were some discrepencies in the Device numbers in the other codes.

Channel Up BUTTON 71
EE.87.A.9D Device 157 from the 8811
EE.87.A.9E Device 158 from the Harmony

tgl Power Button 61
EE.87.3.9C Device 156 from the 8811
EE.97.3.9D Device 157 from the Harmony

And as I told you before, the Harmony is shooting a function that I hadn't seen for the Apple on the RED key.

So I thought button 61 should be Device 156 and Device 71 should be 157, but perhaps I didn't read the posts above correctly.

I did not realize those were invalid device ids; that would explain why it wasn't working on my MacBook.

That was just an assumption on my part. I thought they looked for a block of devices that would not be a problem, but I'mjust guessing.

Hope that helps

[vickyg2003]

Oops,

I went back and read this

Tilda jones wrote:
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.

Rob wrote:
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

And in all that I never realized that I was supposed to Skip device 156, and that is why I never saw the binary problem that was so obvious to Rob from the Get-go

So all the buttons from button 61 to 890 are off by one device. I'll have to refresh my binary skills to figure out how to get all the values we need.

Edit: So if you want to proceed with testing while I rework the protocol, move all the OBC's from Button 71 and down, up to Button 61 and down. The Buttons 91-96 will not work until I rework the code.

[The Robman]

Actually, I didn't notice that 156 was skipped, and I don't know that it was intentionally skipped. I wanted to eliminate device code 160 from the range because device codes 149-159 only need 1 nibble of variable binary, but 160 uses the other nibble.

[tildajones]

Actually, I didn't notice that 156 was skipped, and I don't know that it was intentionally skipped. I wanted to eliminate device code 160 from the range because device codes 149-159 only need 1 nibble of variable binary, but 160 uses the other nibble.

156 is intentionally skipped.

Line 362 defines the static int array of device ids.

static int device_ids[] = {150, 151, 152, 153, 154, 155, 157, 158, 159, 160};

I will post an IR file later today that only contains this ATV upgrade. Thanks for your continued assistance.

[vickyg2003]

I updated the KM file with a corrected OBC's for the buttons 61 and above, and the protocol is tweaked to handle 160 too.
Hamony Plex codes

if you see anything about other function codes (still trying to figure out why Red has a function of '08' in the file, instead of codes that match what I believe to be the codes for Apple TV I'd like to try to understand what they are doing.

So you need to replace the device AND the protocol in IR. Make sure you don't end up with duplicate devices or duplicate protocols.

I am still trying to figure out what this contraption is.

[tildajones]

I updated the KM file with a corrected OBC's for the buttons 61 and above, and the protocol is tweaked to handle 160 too.
Hamony Plex codes

Here is a clean ir file that contains your latest protocol and device upgrade code. It is based off a stock URC-8811 ir dump.

if you see anything about other function codes (still trying to figure out why Red has a function of '08' in the file, instead of codes that match what I believe to be the codes for Apple TV I'd like to try to understand what they are doing.

Will keep an eye out. I have posted to the XBMC forums here seeking help debugging the signals in XBMC.

So you need to replace the device AND the protocol in IR. Make sure you don't end up with duplicate devices or duplicate protocols.

I always remove both the device and the protocol before adding the new ones back in. Good to double-check, though.

I am still trying to figure out what this contraption is.

An AppleTV is basically a mac running in a small form factor with an HMDI output and proper video overscan.

I have a second one sitting around that I have been thinking about sending over to you for testing. I have about $180 in it; so, it's been hard to decide whether to drop ship it to a stranger for testing. Let me know if you would interested and we can discuss this further through pm.