RNS-E in Audi A2

[korni92]

Hi
I am using Hudiy on a RNS-E and made some scripts to control Hudiy via the RNS-E button. In TV mode some buttons are published to the CAN. I also use certain messages and Hudiy API to switch between Day/Night mode or to shutdown the Pi.
At the moment I am working on showing data from the API fror music, naviagation and phone in the cluster of the car.
I have some trouble with the DDP protocol. I can clear the whole middle section of the screen, but on the middle section I can only write to lower half. No matter what values I write, I always end up on the lower half. Maybe someone has experinced this before.

[a8ksh4]

That's rad. You could show all kinds of useful stats there.

[korni92]

It was a positioning problem.

[korni92]

Some optimizations and it's ready for installation. I am also making a mounting bracket for the unit.

https://youtu.be/cIaL97tjTQE?si=lWCV7qKvPU-zAuBd

[Hiphouser]

Do you have a detailed picture of you custom pi box?
I have found your 3d print Files.
But what composent have you used?

Nice project!

[korni92]

My components:

- Pi 4
- Hifiberry DAC+
- CarPiHat
- The PCB from a cheap Ali Express composite RGBS RNS 810 camera converter.

[hudiy]

Hello korni92,
Thank you for your feedback on Instagram. To follow up, here is a brief overview of how key events are handled in Hudiy:

Regular key events are delivered by labwc (window compositor in Raspberry Pi OS) through the Wayland protocol (communication mechanism between window compositor and UI app). They are received by Hudiy in the UI thread and then, depending on the current input focus, they are either forwarded asynchronously to Android Auto / CarPlay or handled by the Hudiy UI (in the UI thread).

In case of the API, the difference is that events are delivered to the UI thread through the TCP/WebSocket layer, and from that point on the processing path is exactly the same as for physical keyboard events.

In theory, injecting key events via the API should actually be faster, because there are fewer layers for the event to pass through before reaching the UI thread:

Keyboard path:
hardware -> driver (kernel) -> libinput -> labwc -> Wayland protocol -> Hudiy (UI thread)

API path:
API client -> TCP stack (kernel) -> Hudiy (UI thread)

All connections to the API endpoints (TCP/WebSocket) are handled asynchronously using epoll, which is a high-efficiency I/O dispatching mechanism in the Linux kernel.

WebSocket itself (if used instead of plain TCP) doesn’t introduce significant overhead - it’s just an additional lightweight layer on top of raw TCP/IP (similar to SSL).

If you can share the code you use to inject key events via the API, we can run it on our side and help analyze what the possible bottleneck might be.

[korni92]

Hello korni92,
Thank you for your feedback on Instagram. To follow up, here is a brief overview of how key events are handled in Hudiy:

Regular key events are delivered by labwc (window compositor in Raspberry Pi OS) through the Wayland protocol (communication mechanism between window compositor and UI app). They are received by Hudiy in the UI thread and then, depending on the current input focus, they are either forwarded asynchronously to Android Auto / CarPlay or handled by the Hudiy UI (in the UI thread).

In case of the API, the difference is that events are delivered to the UI thread through the TCP/WebSocket layer, and from that point on the processing path is exactly the same as for physical keyboard events.

In theory, injecting key events via the API should actually be faster, because there are fewer layers for the event to pass through before reaching the UI thread:

Keyboard path:
hardware -> driver (kernel) -> libinput -> labwc -> Wayland protocol -> Hudiy (UI thread)

API path:
API client -> TCP stack (kernel) -> Hudiy (UI thread)

All connections to the API endpoints (TCP/WebSocket) are handled asynchronously using epoll, which is a high-efficiency I/O dispatching mechanism in the Linux kernel.

WebSocket itself (if used instead of plain TCP) doesn’t introduce significant overhead - it’s just an additional lightweight layer on top of raw TCP/IP (similar to SSL).

If you can share the code you use to inject key events via the API, we can run it on our side and help analyze what the possible bottleneck might be.

I will have a look, you changed a lot on the API of Hudiy, which is awesome. No virtual environment, for example. It's so much faster and reliable than it was before.
Changing tracks, before there was noticeable delay in delivery the new information to show it on the cluster. Now it's so fast, I needed to add a delay on for the white DIS clusters not to overwhelm the processor of the old dash.

I dumped the code of the control via API, because it felt so much slower, especially when scrolling through playlists. There was a noticeable delay and sometimes it felt that it missed some scrolls, which I haven't noticed with uniput.

[korni92]

It started small, but it escalated totally. In the beginning I wanted to have just Android Auto on the RNS-E. Later also more car integration with day/night mode and as the cherry on top ... DiS integration.

The system works fine and hudiy is awesome. Maybe some theming would be cool in the future, to make the menu look like the actual RNS-E menu structure.



In the process I got so much positive response, that I even started to extend this project, far above my own needs. I found out more and more about the protocol to send data to different types of the screen and got help from Vlad with sending bitmap and handling the color cluster screen.









All different clusters require some different handling. So I started to get a few to improve everything to be as flexible as possible and to wotk in as many Audis as possible that came with the RNS-E

Still not finished, I need to make more graphics for icons, navigation arrows and finishing the car info menu.



Also the physical integration into the car was important. I wanted to have a proper mounting spot and housing, so everything is secure, easy to reach and to maintain.