Skip to content

Some questions about your projects #3

Open

Description

@Yanndroid

Hi there,

The last couple of days, I've been working on a python program to control a Linux PC and/or a Raspberry with the Siri-Remote and your work has been extremely helpful, since you're basically the only one who worked on this. Thanks btw :)

So far I've got all the essential stuff working, I'm getting byte arrays for every event on the remote (buttons, touch, mic, etc..) and performing actions like volume or media control is also working. I've been looking at the data received from the touchpad for quite a while now and there's some weird things I can't figure out, so I hoped you might have some insight on that.

When I use the touchpad I receive 13 bytes (or 20 with two fingers). The first 6 bytes are just some general information like finger count, button event, etc... and the 7 bytes after that are about the finger (and again 7 bytes for the second finger).

Byte
0     finger count: 1 or 2
1     pressed buttons, else 0
2     always 50
3     ?
4     ? time (increases over time and starts again at 0)
5     ? when the finger is on the edge: 0,4,5,8,9 else 1

6     X coord, left to right: 230...255, (0,...,255)*7 ,1,...,74
7     ? (reacts to movement)
8     Y coord (signed byte), top to bottom: 38,...,1,0,255,...,188
9     ? (0 when released)
10    ? (0 when released)
11    pressure
12    ?

13-19 are like 6-12 for the second finger

The weird thing is the X coordinate: it cycles 7 times from 0 to 255 on the entire touchpad width. So the touchpad basically has >7 vertical "zones" and I didn't recognize any pattern in the other bytes that would indicate in which "zone" the finger is. Same for the second finger.
I am of course able to recognize a direction but as soon as you move a little faster horizontally, you can't know in which direction you actually moved because of the data rate limit.

Maybe I just missed something somewhere, but I'm asking here because you obviously have more experience in that field. I would appreciate it, if you can find some free time to help me out.

Another thing is the audio, I haven't gotten to that part yet because of some Linux related issues, but I saw in your other repo that the audio format is opus. Can I just strait up decode the bytes or do I need to do something first? I'm asking because I have very little knowledge in C. This question might resolve itself when I get to it but since I'm already here I might just ask that as well.

Activity

  1. Yanndroid commented on May 4, 2023

    @Yanndroid
    Author

    Like always, you find the solution after you've opened an issue...😅, turns out the first 3 bits of 7th byte are the "zone" index.
    x = data[6] + 255 * (data[7] & 7)

  2. Jack-R1 commented on May 5, 2023

    @Jack-R1
    Owner

    Hi @Yanndroid,

    Thank you for your comments.

    I'm glad you figured it out as I haven't delved into the touchpad data since another GitHub project had it working for Mac and I just used his code.

    Thank you for sharing the breakdown of the bytes, it looks interesting, others may be able to find it useful as well.

    The audio is encoded with Opus, have a look in the debug section of the code and a sample frames.txt file, it should be straight forward, if you need code in C#, I have that as well.

    I would be interested to see the end result of your project, good luck with it.

    Thanks,

    Jack

  3. Yanndroid commented on May 17, 2023

    @Yanndroid
    Author

    Hi there,

    Unfortunately I wasn't able to make the audio work, because of a bluez limitation on which I spend more time than I'd like to admit. But I did some overall improvements, so I'll just leave it like this for now and pushed it to GitHub.
    https://github.com/Yanndroid/SiriRemote-Linux

    Thanks again,
    Yann

  4. Jack-R1 commented on May 29, 2023

    @Jack-R1
    Owner

    Nice work @Yanndroid 👍

    I can't recall when playing with it on linux if I had any limitation on the audio data but with the Windows driver I did and from my research the issue was due to the bluetooth adapter being ble v4.0, see comments in screenshot:

    image

  5. Yanndroid commented on May 29, 2023

    @Yanndroid
    Author

    The limitation wasn't really with linux but rather with bluez, because Wireshark for example, had no issues reading all the bytes. They're split up in 4 packets and then reassembled.
    image
    (Wireshark output while running my program, which only receives the last first one)

    I'm currently trying to use a lower level in the bluetooth stack (hci instead of gatt) and I'm actually getting some very promising results :). For the moment it still runs in two separate scripts in parallel 😅 but I'm getting all the bytes in the second one. It shouldn't be too difficult now to migrate the code.

    I'll keep you updated :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions