HUDiy launches fine but Android Auto does not... help

[hudiy]

Just in case, try updating Hudiy to the latest version, 2.20 viewtopic.php?t=309

The logs show that the phone stops responding during the connection. If the hotspot icon disappears, it might be a power issue or a firmware/driver crash. What is the output of the dmesg command after hotspot icon disappeared?

[emeeder]

Can I run the $HOME/.hudiy/share/updater program from an SSH connection or via RDP, or do I have to run it on the main terminal? (If I have to run it on the main terminal I'll have to take a USB keyboard/mouse out to my garage where the Pi5 is running.)

[hudiy]

There is no difference. You need to run the updater from any terminal on the user account you used to install Hudiy.

[emeeder]

I updated the version of HUDiy. It did the same thing. Here is the dmesg detail that you asked for...

dmesg.zip

[hudiy]

dmesg shows rapid USB disconnections and reconnections of the touchscreen. If the device wasn't manually replugged, this could indicate USB power issues. The USB WiFi adapter in Hotspot mode and the screen might be drawing too much current over USB and the Raspberry Pi is limiting this power draw.

[emeeder]

I'll try to do some playing around with the power of those devices, but I'm not sure what you mean by the power draw of the USB Wi-Fi adapter because the hotspot and in fact all of HUDiy should be using wlan0 which is not USB Wi-Fi it's the onboard Wi-Fi so there shouldn't be any power draw issues for that at all.

Let me check the power draw of the touch screen but are you sure within the head unit app that it's using the onboard Wi-Fi or is it showing it it's still trying to connect across the USB Wi-Fi?

[hudiy]

The hotspot is on 2C:CF:67:C3:7C:8C

According to nmcli

Code: Select all

wlan0: connected to Meeder
        "Broadcom Wi-Fi"
        wifi (brcmfmac), 2C:CF:67:C3:7C:8C, hw, mtu 1500
        inet4 192.168.86.55/24
        route4 default via 192.168.86.1 metric 50
        inet6 fdac:3a9:2461:887b:6247:a6d0:40a0:9488/64
        inet6 fe80::b8b8:e153:230d:bd1b/64
        route6 fe80::/64 metric 1024
        route6 fdac:3a9:2461:887b::/64 metric 601
        route6 fd33:c3f3:94be:1::/64 via fe80::1622:3bff:fe24:50a8 metric 606
        route6 fd33:c3f3:94be:1::/64 via fe80::cef4:11ff:fe44:f533 metric 606

[emeeder]

Yeah, it looks like the system is getting confused as to which is wlan0 and wlan1 (at least from what dmesg is showing), so I added some config changes to lock those in.

As far as the touchscreen power stuff, that was/is being caused because the ignition powers on the touchscreen and my python script sees that the touchscreen is available so it starts the HUDiy service, but the service needed to be tweaked so that all of the HDMI stuff is online and working first (which I also fixed in the hudiy.service file this morning). I also backed off the 2k resolution to something easier to render...

I'm getting there... I'll go out and test it again during my EDT lunch. Excelsior!

[emeeder]

Okay... I have tried everything multiple ways, but it just doesn't seem to want to work.

I know that I have wlan0 (reserved for HUDiy) and wlan1 (reserved for my A.I.). Attached you will find the nmcli, dmesg and hudiy.4.log file. I also have my latest main_configuration.json in there.

I hope that we can get this figured out soon. It seems like the setting in the config to lock it to wlan0 isn't working.

hudiy_stuff.zip