freeDSP / freeDSP-aurora

freeDSP ADAU1452 with 8 analog input, 8 analog outputs, S/P-DIF I/O, ADAT I/O, USB Audio Class2, WiFi, Bluetooth
Creative Commons Attribution Share Alike 4.0 International
176 stars 55 forks source link

Add support for multiple models of Apple remote + long press #97

Closed zas closed 2 years ago

zas commented 2 years ago

@dspverden I noticed something in https://github.com/freeDSP/freeDSP-aurora/blob/7bbd8f73960759232f8bb24dc7319ce9ae0a85ca/SOURCES/WEBAPP/ESP32/aurora/hwconfig.h#L41-L44

0x77E12047 seems to be emitted when CENTER or PLAY are released (UP), so the codes are incorrect, but since they weren't used, no problem. Other buttons don't send a different code when releasing, so not sure it is worth bothering.

My remote has codes looking like 77E1xx36, the master source has codes in the form of 77E1xx47, and https://github.com/freeDSP/freeDSP-aurora/pull/95/commits/f35adc31d4f25cd854492b2f142885cc48224d34 has codes in the form of 77E1xx55.

73 gives another set of codes that have the following patten 77E1xxF7

The code here should work with all.

zas commented 2 years ago

@dspverden I improved the thing a bit so it speeds up when maintaining a long press on volume remote buttons, and tried to debounce very short presses, so it's possible to fine tune volume level. On short presses, it goes with 0.5db as it was before, but when maintaining buttons it speeds up to 1db then 2db. Tell me what you think once you tested it.

zas commented 2 years ago

I'm not yet happy with this code. I'll update the PR once I have something good enough.

zas commented 2 years ago

I reworked the code, it is much simpler now, and should work as expected.

exislow commented 2 years ago

Great job. Just tested it. Works like charm. Even the logic regarding short long presses and longer long presses. Love it.

dspverden commented 2 years ago

To make things a bit more complicated, I had a bunch of Apple remotes here, they all showed different patterns. But it can be narrowed down to a scheme. In hex code the second byte identifies the key while byte 4 & 3 are always 0x77E1xxxx. That means masking byte 2 by 0x0000FF00 will give the key code. Here I found two variants for each key, e.g. Play button is either 0x00007A00 or 0x0000FA00. See my last commit on develop. There I already implemented that. Perhaps you want to adapt long press solution to it?

zas commented 2 years ago

@dspverden did you test my code with those remotes ? The 0x00007A00 or 0x0000FA00 should be handled by 0x00007F00 mask

EDIT:

I'm pretty sure this code was working with the variant you added in https://github.com/freeDSP/freeDSP-aurora/commit/00f00122c5b546a5428b267a61df880ef776eac3

I wonder if you actually tested this code, and if it wasn't working, why. Check https://github.com/brackendawson/Appleceiver/blob/357a0a16013d9e35f1119530399aba55b7030bab/Appleceiver.ino#L43-L55:

//Apple remote definitions
//Address
#define A1156_ADDRESS   0x77E1  
/*Button codes
 I've seen many remotes have various codes,
 this is the best decode I have. The address
 is fixed, the message may be as so:
 #define A1156_BUT_PLUS  0x   5    0    9    D
                           0101 0000 1001 1101
                           ||      | |       |
 varies, battery flat?-----+|      | |       |
 fixed?, the button---------+------+ |       |
 varies, serial number?--------------+-------+ */

The first bit on the left varies ("battery flat?"), hence the mask 0x00007F00.

zas commented 2 years ago

@dspverden you didn't answer to my comment above, I need to know what wasn't working with the models you own, before reworking this PR.

dspverden commented 2 years ago

Please have a look at the one of the latest commits from develop. There you can see, it seems to be bit 7 (most left) of the the second byte. As you described it above.