nisargjhaveri / WirelessAndroidAutoDongle

Use Wireless Android Auto with a car that supports only wired Android Auto using a Raspberry Pi.
MIT License
656 stars 70 forks source link

Moved Wait for Accesory timeout to `aagw.env` #112

Closed hkfuertes closed 2 months ago

hkfuertes commented 4 months ago

I had an issue, most likely due to the slowness of my headunit, that I get in a boot loop of "Unrecognized USB" for several times in a row on my Dacia Media Display.

On my preliminary tests, by changing this value to 0 (infinite) It seems to fix the issue. Anyway, for not needing to recompile each time this value needs to change, I moved it out to the aagw.env file.

Hopefully this helps anyone, but it might for this issues: #98 #34? https://github.com/nisargjhaveri/WirelessAndroidAutoDongle/issues/98#issuecomment-2099430073

Anyway, please review it and merge if you think makes sense.

hkfuertes commented 4 months ago

BTW @nisargjhaveri ... how about using config.txt for our variables aswel?

...
dtoverlay=dwc2,dr_mode=peripheral

[aagw]
# Set the connection strategy to use
# 0 - Dongle mode (default). Waits for both dongle and headunit bluetooth connections and then starts the wifi and usb connections.
# 1 - Phone first. Waits for the phone bluetooth and wifi to connect first, and then starts the usb connection.
# 2 - Usb first. Waits for the usb to connect first, and then starts the bluetooth and wifi connection with phone.
AAWG_CONNECTION_STRATEGY=0

# Timeout for Waiting for Usb Accesory
AAWG_WAIT_FOR_ACCESORY=10

Pseudo code... 🤷‍♂️

  1. Mount /boot
  2. Regex '\[aagw](.*)[\' | xargs
manio commented 4 months ago

BTW @nisargjhaveri ... how about using config.txt for our variables aswel?

Nice idea - this way the whole config is more Raspberry-Pi like and in one place. But the other way around maybe the aawg could be used elsewhere in some different running environment such as x86 or other arm board and there such file may be unavailable. There could be also some hybrid/priority solution where some config/file take precedence over the other.... Let's see what @nisargjhaveri thinks about it...

nisargjhaveri commented 4 months ago

When you remove the timeout, do you know how much time does the headunit take to connect? From my tests, the phone times out in around 10s anyway, so if the headunit takes more than 10 seconds to initialise the connection still wouldn't work because the phone times out by then. Unless headunit is faster in the next attempt and it connects then. Can we please try to verify this from logs once?

If this is the case, I'd also be happy to increase the default timeout for everyone as well. 10s was mostly arbitrary and simply because I thought the phone would also time out by then.

nisargjhaveri commented 4 months ago

BTW @nisargjhaveri ... how about using config.txt for our variables aswel?

Interesting idea! But not too inclined towards this. One, to keep it somewhat generic as @manio also pointed out. We generally shouldn't have to edit config.txt otherwise anyway, right? I don't see much benefit in combining with unrelated config file.

We can have aawg.env or aawg.env.sh in /boot and directly use it from there as we were discussing someplace else. (sorry, haven't been able to work on this yet). I think it would be much cleaner this way and provide same amount of convenience.

hkfuertes commented 4 months ago

When you remove the timeout, do you know how much time does the headunit take to connect? From my tests, the phone times out in around 10s anyway, so if the headunit takes more than 10 seconds to initialise the connection still wouldn't work because the phone times out by then. Unless headunit is faster in the next attempt and it connects then. Can we please try to verify this from logs once?

If this is the case, I'd also be happy to increase the default timeout for everyone as well. 10s was mostly arbitrary and simply because I thought the phone would also time out by then.

Sure, I will try and get some logs.

nisargjhaveri commented 4 months ago

@hkfuertes Let's start with simply increasing the timeout to let say 30s or 40s or even more if required? More config options is always confusion and a larger timeout here would not hurt much.

hkfuertes commented 4 months ago

I have been testing, and In the end increasing or decreasing this number does not have any influence at all, in fact, it made it worse (I build it without a parameter, so infinite, and made it worst). You can close the PR... (I haven't read the issues, and I don't know if it actually helped anyone... that's why I don't close it myself)

The thing that annoys me most, is that I have to go through hell to pair them together... but once they are both connected, it works like a charm (with phone first). So I think that maybe we could include a guide on how to setup the headunit emulator for the first pair, if your car is "special" (as is mine)...

manio commented 4 months ago

FWIW: I tested this timeout set to 0 in regards of mine problem. It doesn't help either.

nisargjhaveri commented 4 months ago

@hkfuertes I'm confused, setting the timeout to zero is not helping with your original issue as well anymore?