Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moved Wait for Accesory timeout to aagw.env #112

Closed
wants to merge 1 commit into from

Conversation

hkfuertes
Copy link
Contributor

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?
#98 (comment)

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

@hkfuertes
Copy link
Contributor Author

hkfuertes commented May 8, 2024

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
Copy link
Contributor

manio commented May 8, 2024

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Owner

@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
Copy link
Contributor Author

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
Copy link
Contributor

manio commented May 20, 2024

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

@nisargjhaveri
Copy link
Owner

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

@hkfuertes hkfuertes closed this Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants