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

[emeeder]

The hotspot needs to make it out of the front trunk of a Classic Beetle (made of pure steel) which acts like a Faraday cage. I was told in order to have the signal make it through that steel even a short distance I really need to use 2.4GHz. If I have to stay with BG what should I switch the other settings to in order to keep the same relative size but the 2.4GHz and non-DRM?

Also, I tried both upper and lower cased version of the MAC address. I'll continue to do the update to get to latest version and am willing to try both upper and lower for MAC address again, but every other settings for the Pi I was told I had to do as lower case.

[emeeder]

I switched back to the "2k"/Drm=true/"AUTO" settings for androidAuto and hotspot just to see if I can get it to work (I'll try both upper and lower-case attempts for the hotspot MAC address) although I'm not sure that the 5GHz will make it through the metal of the frunk ("front trunk").

I also completely updated HUDiy app to v2.2.

I'll let you know what I find...

[emeeder]

Hmmm... several things were going on with these issues, and I've been "playing" with different things part of today.

1) There was a setting that was rejecting P2P on wlan0 so HUDiy was falling over to wlan1... fixed that
2) I was able to bind my A.I. python script to wlan1 from now on within it's "systemctl --user ai-brain.service" file
3) By making those changes I now have removed most of the settings for hotspot in main_configuration.json

I still may end up having issues with the "Faraday cage"-like front trunk of my Beetle, but if that's the case I can grab a 2nd USB WiFi Dongle from Amazon and add that as wlan2 for HUDiy and run it into the cabin of the car, but let's first try this...

[emeeder]

I have done everything I can do... nothing I've tried seems to be working. I've updated HUDiy, I tried multiple iterations and tests of the same things over and over. For whatever reason HUDiy doesn't seem to recognize my hotspot node's value of hardwareAddress : "2C:CF:67:C3:7C:8C"

Code: Select all

    "androidAuto" : {
        "speechAudio" : true,
        "mediaAudio" : true,
        "resolution" : "2k",
        "bluetoothAddress" : "",
        "autostart" : true,
        "fps" : "60",
        "dpi" : 160,
        "widthMargin" : 640,
        "heightMargin" : 240,
        "width" : 0,
        "height" : 0,
        "x" : 0,
        "y" : 0,
        "gpsDataSource" : "GPSD",
        "useRpiDrm" : true,
        "dayNightMode" : "COMMON"
    },
    "hotspot" : {
        "enabled" : true,
        "hardwareAddress" : "2C:CF:67:C3:7C:8C",
        "ipAddress" : "192.168.12.1",
        "passphrase" : "1234567890",
        "ssid" : "Hudiy",
        "bandwidth" : "A",
        "channelConfigurationType" : "AUTO",
        "channelBandwidth" : "40MHz",
        "channel" : 36
    },

I've also attached the dmesg and the hudiy.4.log file in the zipfile

I have no idea what else to try, but the hardware address points to wlan0 but still wlan1 keeps getting spun up. I think that NetworkManager needs to manage the WiFi address being accessed, correct?

logs.zip

[hudiy]

The logs show that the hotspot was successfully created for the address 2C:CF:67:C3:7C:8C (uppercase letters) and Android Auto connects wirelessly to the hotspot.

A few seconds after connecting, packet loss is visible - no response to pings.

[2026-08-26 15:45:24.203570] [0x00007ffef91dd0a0] [info] [hudiy] [HotspotManager] looking for wireless device, hardware address: 2C:CF:67:C3:7C:8C
[2026-08-26 15:45:24.234254] [0x00007ffef91dd0a0] [info] [hudiy] [HotspotManager] activating hotspot, device: 2C:CF:67:C3:7C:8C

[2026-08-26 15:46:08.114272] [0x00007ffeb97ad660] [error] [hudiy] [AndroidAutoEntity] device not responding, pings: 7, pongs: 5

Around the timestamp of establishing the connection with Android Auto, activity on the second network interface (disconnecting from the network and reconnecting) can be seen in dmesg.

[Wed Aug 26 15:45:33 2026] wlan1: deauthenticating from 1c:f2:9a:8c:fb:1a by local choice (Reason: 3=DEAUTH_LEAVING)
[Wed Aug 26 15:45:33 2026] wlan1: authenticate with 1c:f2:9a:8c:fb:1a (local address=3c:33:00:60:94:11)
[Wed Aug 26 15:45:33 2026] wlan1: send auth to 1c:f2:9a:8c:fb:1a (try 1/3)
[Wed Aug 26 15:45:33 2026] wlan1: authenticated
[Wed Aug 26 15:45:33 2026] wlan1: associate with 1c:f2:9a:8c:fb:1a (try 1/3)
[Wed Aug 26 15:45:33 2026] wlan1: RX AssocResp from 1c:f2:9a:8c:fb:1a (capab=0x1031 status=0 aid=2)
[Wed Aug 26 15:45:33 2026] wlan1: associated
[Wed Aug 26 15:45:33 2026] wlan1: Limiting TX power to 30 (30 - 0) dBm as advertised by 1c:f2:9a:8c:fb:1a

Also, based on dmesg, it looks like the Raspberry Pi Wi-Fi module starts scanning for available Wi-Fi networks.

[Wed Aug 26 15:45:34 2026] ieee80211 phy1: brcmf_escan_timeout: timer expired
[Wed Aug 26 15:45:56 2026] ieee80211 phy1: brcmf_vif_set_mgmt_ie: vndr ie set error : -52
[Wed Aug 26 15:45:56 2026] ieee80211 phy1: brcmf_vif_set_mgmt_ie: vndr ie set error : -52
[Wed Aug 26 15:45:56 2026] ieee80211 phy1: brcmf_vif_set_mgmt_ie: vndr ie set error : -52

From Hudiy's perspective, the hotspot and the Android Auto connection are working correctly. It looks like something in your system is taking over access to the 2C:CF:67:C3:7C:8C network interface.

[emeeder]

I'm just gonna consider it a "push" and switch gears...

I just can't get the HUDiy head unit software to work correctly with my Pi5 with dual WiFi modules. I understand what you are saying, and I believe you... and I know that I'm not the easiest person to work with (and you have tried to be helpful). I have attempted to move the locations for things so that signals were stronger, but I am also limited by the truth of the car that I own, and that might make this a very difficult scenario.

I'm just going to enjoy my A.I. on the Pi5 and utilize a separate Android Auto unit for now so that I can drive and enjoy my car for awhile. Maybe I'll monkey around with this over the winter when I have had a chance to reevaluate things and maybe get a 2nd Pi just for playing with.

Adios' for now...

[RockyHarder22]

I have a theory on this. I've been testing HUDIY on a different board the past few weeks, mainly trying to replicate the install to develop a repeatable method. Currently I have one version that fully works so I'm referencing my recreations against it. Then all of sudden one day AA would crash as soon as it started -- you'd see the logo and like maybe a second of the AA projection, then it would drop back to HUDIY -- e ven on the working version, which made no sense until I remembered that I updated AA on my phone (i don't have automatic updates turned on so I manually update). The most recent update -- the one that started this issues -- was 17.6.6634. I uninstalled it and manually installed 17.6.6630 from apkmirro, and my working copy now works again with AA staying on. ETA: I updated maybe 3-4 days ago so I feel like the timing of your issue sounds like there could be a connection.

[emeeder]

Actually I've been "playing" quite a bit, and I think the issue is that I am polling SSIDs to find out if my car has re-entered my home garage (and the home SSID is available) and if so it re-connects to that home SSID.

Well, of course to do that I was incorrectly breaking down the connections via a rescan through NetworkManager on every timed poll, and it was blowing apart the P2P/hotspot connection, too!

So... I modified the way that my python script handles it's polling, and now it shouldn't do that (theoretically).

Like I mentioned prior, I realize that I ask a lot of questions and can be a tad "high maintenance", but with how I am joining it with my A.I. that I coded in Python and both are running simultaneously it's kind of a tricky simpatico.

I'm gonna test my theory during my lunch-time (East coast of USA), and we'll see if I was right and if now everything might be working fine.

[emeeder]

Yup!... everything is working perfectly!

Python script on wlan1, HUDiy on wlan0... the key on of the ignition powers on the monitor and starts the service for HUDiy (and key off shuts it down)

When I say the wake word it mutes the audio output from HUDiy/AA and unmutes when it finishes answering my request

It works amazingly well!

20260412_083000.jpg

[RockyHarder22]

HERBIE!!