Open Andreunto opened 10 months ago
Thanks for informing. I believe most of these issues are coming due to the fact that we wait for the car to start the connection before connecting to the phone. I'll try to work on a change where we opportunistically connect to phone anyway regardless of car starting the connection.
Thanks for informing. I believe most of these issues are coming due to the fact that we wait for the car to start the connection before connecting to the phone. I'll try to work on a change where we opportunistically connect to phone anyway regardless of car starting the connection.
Thanks mate. i waiting for test
@Andreunto Please try the builds from #35, builds here, and see if it helps?
@Andreunto Please try the builds from #35, builds here, and see if it helps?
Thanks so much for the quick update. Now the connection with the smartphone is easier (it used to take several attempts) but unfortunately the situation remains the same. Now the bluetooth is immediately disconnected, switching only to the wifi connection, before it remained connected with both bt and wifi
The Bluetooth disconnect is OK, it should do that.
The Bluetooth disconnect is OK, it should do that.
Yes, but remain in "searching for android auto..."
I've also a Dacia/Renault MediaDisplay (AndroidAuto without WiFi) but it works like a charm, also with the pre-build image
I've also a Dacia/Renault MediaDisplay (AndroidAuto without WiFi) but it works like a charm, also with the pre-build image
Which mediav model do you have? I have the Medianav Evolution 2 and I just can't connect it
Which mediav model do you have? I have the Medianav Evolution 2 and I just can't connect it
In MediaNav Evolution Android Auto and Apple CarPlay should be native wireless (or, maybe, bluetooth) without additional dongles.. I found this information after purchasing my Dacia Jogger Hybrid. My device is the MediaDisplay with software V 6.0.10.0. I found in google that it require the minimal Android 11 version to works
Which mediav model do you have? I have the Medianav Evolution 2 and I just can't connect it
In MediaNav Evolution Android Auto and Apple CarPlay should be native wireless (or, maybe, bluetooth) without additional dongles.. I found this information after purchasing my Dacia Jogger Hybrid. My device is the MediaDisplay with software V 6.0.10.0. I found in google that it require the minimal Android 11 version to works
Medianav Evolution 2 it only has BT and AA via USB. It has no way to connect to AA or Carplay wireless
I tried with Raspberry Pi 2 W. Result was the same Smartphone was searching of Android Auto. I did some debugging. It looks that for some reason aawg is not listening on port 5288. Server crashes after this message:
aawgd[398]: Frowarding data between TCP and USB
aawgd[282]: 0 bytes read from TCP
I tried to kill and start aawgd daemon couple of times and with a lot of luck I was able to run AA twice. Server didn't crash and there was communication messages in the log:
aawgd[336]: Read WifiStartResponse. length: 2, messageId: 7
aawgd[336]: Read WifiConnectStatus. length: 2, messageId: 6
aawgd[336]: Bluetooth launch sequence completed
aawgd[336]: Bluetooth adapter was powered off
aawgd[336]: Tcp server accepted connection
aawgd[336]: Phone first connection selected
aawgd[336]: USB Manager: Enabled default gadget
aawgd[336]: USB Manager: Received accessory start request
aawgd[336]: USB Manager: Switched to accessory gadget from default
aawgd[336]: Opening usb accessory
aawgd[336]: Frowarding data between TCP and USB
aawgd[336]: USB Manager: Received accessory start request
aawgd[336]: USB Manager: Switched to accessory gadget from default
aawgd[336]: Opening usb accessory
aawgd[336]: Frowarding data between TCP and USB
aawgd[336]: 10 bytes read from USB
aawgd[336]: 10 bytes written to TCP
aawgd[336]: 12 bytes read from TCP
aawgd[336]: 12 bytes written to USB
aawgd[336]: 313 bytes read from USB
aawgd[336]: 313 bytes written to TCP
aawgd[336]: 2309 bytes read from TCP
aawgd[336]: 2309 bytes written to USB
aawgd[336]: 1229 bytes read from USB
aawgd[336]: 1229 bytes written to TCP
Another problem is that sometimes after running aawgd raspberry is rebooting.
@toek79 Looks like you're using the builds from one of the PRs, which has some issues. Please try the latest build from the main
branch.
@nisargjhaveri yesterday I downloaded "main" branch and compiled by myself.
Today as you suggested I used last build from https://github.com/nisargjhaveri/WirelessAndroidAutoDongle/actions/runs/7978244678 and https://github.com/nisargjhaveri/WirelessAndroidAutoDongle/actions/runs/7994649602. In both cases situation is the same. Phone has problem with TCP connection:
aawgd[398]: Frowarding data between TCP and USB aawgd[282]: 0 bytes read from TCP
Strange thing. I am thinking what can cause the issue. I tried 2 Phones Oppo and Samsung.
I think problem is related to USB communication. In case I am able to run AA on radio logs look like below:
aawgd[318]: USB Manager: Switched to accessory gadget from default
aawgd[318]: Opening usb accessory
aawgd[318]: Forwarding data between TCP and USB
aawgd[318]: Data forwarding: TCP, read_fd 9, write_fd 8
aawgd[318]: Data forwarding: USB, read_fd 8, write_fd 9
aawgd[318]: 10 bytes read from USB
aawgd[318]: 10 bytes written to TCP
aawgd[318]: 12 bytes read from TCP
Every time if AA works I see aawgd[318]: 10 bytes read from USB, in case AA doesn't work aawgd shows that 0 bytes was read from TCP.
aawgd[398]: Frowarding data between TCP and USB
aawgd[282]: 0 bytes read from TCP
I am note sure, but maybe problem is with changing USB mode (changing content of UDC file). Maybe there is some timing issue that is why it sometimes works. Another problem is that after changing USB mode Raspberry Pi sometimes reboots. Still trying to find the root cause.
In my case the problem is when we first time change USB mode:
echo 3f980000.usb > /sys/kernel/config/usb_gadget/accessory/UDC
After above commend we have log in dmsg
dwc2 3f980000.usb: bound driver configfs-gadget.accessory
It is causing USB power cycle of USB port, board reboots, AA doesn't work.
Any idea how we can fix it without connecting second USB to 5V ? Second USB = Power USB.
aawgd[282]: 0 bytes read from TCP
This generally means that the TCP connection timed out before the communication could be started with usb.
Power cycle on enabling usb is new. Does the headunit do this for all devices when connected?
Headunit only have power cycle with Raspberry PI. Other devices like pendrive, Carlinkkit works fine.
I connected RPI to Ubuntu machine. It is interesting what I found in the logs:
RPI:
echo 3f980000.usb > /sys/kernel/config/usb_gadget/accessory/UD
PC
usb usb1-port9: attempt power cycle
I think this is the issue why RPI reboots. Headunit runs power cycle.
I am able to run AA over Wifi. I need to use second power supply and change code:
void UsbManager::writeGadgetFile(std::string gadgetName, std::string relativeFilePath, const char* content) {
std::string gadgetFilePath = "/sys/kernel/config/usb_gadget/" + gadgetName + "/" + relativeFilePath;
Logger::instance()->info("w_f: echo %s > %s\n",content , gadgetFilePath.c_str());
FILE* gadgetFile = fopen(gadgetFilePath.c_str(), "w");
fputs(content, gadgetFile);
fputc('\n', gadgetFile);
fclose(gadgetFile);
usleep(2000 * 1000);
}
I added delay at the end. After that hack, I have to kill and run aawgd process manually and AA works fine. ;-)
Headunit only have power cycle with Raspberry PI. Other devices like pendrive, Carlinkkit works fine. I connected RPI to Ubuntu machine. It is interesting what I found in the logs: RPI:
echo 3f980000.usb > /sys/kernel/config/usb_gadget/accessory/UD
PCusb usb1-port9: attempt power cycle
I think this is the issue why RPI reboots. Headunit runs power cycle. I am able to run AA over Wifi. I need to use second power supply and change code:void UsbManager::writeGadgetFile(std::string gadgetName, std::string relativeFilePath, const char* content) { std::string gadgetFilePath = "/sys/kernel/config/usb_gadget/" + gadgetName + "/" + relativeFilePath; Logger::instance()->info("w_f: echo %s > %s\n",content , gadgetFilePath.c_str()); FILE* gadgetFile = fopen(gadgetFilePath.c_str(), "w"); fputs(content, gadgetFile); fputc('\n', gadgetFile); fclose(gadgetFile); usleep(2000 * 1000); }
I added delay at the end. After that hack, I have to kill and run aawgd process manually and AA works fine. ;-)
Hi, can you confirm have medianav? Because your progress is interesting
Hi @Andreunto. Yes, I have Medianav headunit from 2021. Did you have the same experience that RPI reboots?
Hi @Andreunto. Yes, I have Medianav headunit from 2021. Did you have the same experience that RPI reboots?
I am the author of this post. I have the problems you can read in the first messages. Problems I've encountered with all versions released so far. Basically I have never been able to see Android Auto on the Medianav display. I'm not good at working with software, so I'm following your progress with great interest
@Andreunto by asking about "reboots issue" I meant do you see LED is going down for couple of seconds? I would like to ensure that we are seeing the same problem.
@Andreunto by asking about "reboots issue" I meant do you see LED is going down for couple of seconds? I would like to ensure that we are seeing the same problem.
reboots happen to me with raspberry pi4 because the usb output of the medianav is not powerful enough to power the rpi4. With rpi2w I have no reboot
Interesting. I need to check another RPI board then.
@toek79, the observation that it works after adding the delay seems very interesting. In my understanding, this should even work with delay much smaller than 2 seconds. I've created #73 with a small delay of 0.1 seconds, which I believe Android is also using, we can adjust it as required.
Let me know if the builds from #73 work?
@toek79, the observation that it works after adding the delay seems very interesting. In my understanding, this should even work with delay much smaller than 2 seconds. I've created #73 with a small delay of 0.1 seconds, which I believe Android is also using, we can adjust it as required.
Let me know if the builds from #73 work?
Same situation for me
Sorry for late reply. I was quit busy and more focused on reboot issue. After investigation I found that, BCM2835 has HW bug which generates reboot problem. It is described here:
Quote from RPI site:
There is a bug in the BCM2835 (CM1) bootloader which returns a slightly incorrect USB packet to the host. Most USB hosts seem to ignore this benign bug and work fine; we do, however, see some USB ports that don’t work due to this bug. We don’t quite understand why some ports fail, as it doesn’t seem to be correlated with whether they are USB2 or USB3 (we have seen both types working), but it’s likely to be specific to the host controller and driver. This bug has been fixed in BCM2837.
I had USB issue/reboot issue with RPI zero and zero 2w. Both are based on BCM2835. Now, I would like to try BCM2837 and RPI 3a+.
@Andreunto regarding your question, delay helped me a lot. AA worked all of the time, but ;-) I needed to kill and run aawgd manually from console. I added script which is checking if there is log in /var/log/messages which tells me that AA works fine. If AA doesn't work, script kills aawgd and run it one more time. I know it is not super smart solution, but works. I will share more details when I find solution for USB port reboots.
After investigation I found that, BCM2835 has HW bug which generates reboot problem.
That's unfortunate. :/ Thanks for investigating!
I needed to kill and run aawgd manually from console. I added script which is checking if there is log in /var/log/messages which tells me that AA works fine. If AA doesn't work, script kills aawgd and run it one more time. I know it is not super smart solution, but works. I will share more details when I find solution for USB port reboots.
When you get to it, could you please also share the logs along with the solution that, works for you? If I understood correctly, it works sometimes with the delay, and sometimes you still need to restart and let it reconnect, right?
@nisargjhaveri, @Andreunto finally it works ;-) I am sharing diff where you can check what I changed: changes.txt It is important to add CONFIG_USB_DWC2_DEBUG, it fixed board reboots. I know it sounds stupid and ridiculous, but now board works very stable. Logs probably add some delay that is why it is fixed. I also moved loading USB modules to S92usb_gadget init script. It fixed problem with USB enumeration (only observed if I connected RPI to Linux PC). I also activated UART port of debugging purposes and added 1 sec. delay to writeGadgetFile function.
Tested many times and looks like it works. @Andreunto if you want, I can share my local build via Google Drive.
@toek79 Yes mate, thanks!
@toek79, let's not share local builds here. You can share a branch with your changes or create a PR if you think it might help.
@Andreunto did you try what I shared? @nisargjhaveri sure, no problem. I will create my branch later on.
@toek79 Yes mate, is perfect work! Thanks
@nisargjhaveri I created my own fork. If you are interested, I added all my changes in this commit Now it works as it should. ;-) BTW. Thanks for sharing this amazing project. Well done !!!
@Andreunto I have Renault Zoe from 2016 with R-Link1 (or maybe evolution, not sure), pic here And from what I can see the problem is similar as yours. It has only a BT and AA only via an USB-wire.
My main problem is that when I plug in my android phone directly then a small AndroidAuto icon on the bottom will appear, I can click it and run AA without any issues; but when I use this dongle, then nothing happen after connecting this box in USB port of the car (AA icon on the bottom doesn't appear no matter how hard I tried). I read on the comments of this items that people has similar problems with R-Link1. Do you have the same problem in your Dacia using this project?
I didn't test this project though - I am only trying to figure out/inform about the possible problem with those early Medianav/R-Link devices...
@nisargjhaveri Hi, do you have plans to include @toek79's changes in your main repo? I have similar media in my car, so I think I'll give it a try soon when I grab some spare Raspberry PI Zero 2 W for tests. Please tell me one thing: Pi Zero 2 W has the USB Power port and OTG port. I assume OTG is for AA data, but can it be also powered from the same port? Otherwise I need to power it somehow from the car...
Hi, do you have plans to include @toek79's changes in your main repo?
There are multiple changes in the commit and some seems fragile as they seem to help with some race conditions somewhere. I'd be happy to take in PRs with more targeted fixes if possible.
Please tell me one thing: Pi Zero 2 W has the USB Power port and OTG port. I assume OTG is for AA data, but can it be also powered from the same port? Otherwise I need to power it somehow from the car...
Just connecting the OTG port should be enough as it should be able to power the RPi sufficiently in general.
@nisargjhaveri Based on my previous experiences with mentioned above AA dongle and this issue (@Andreunto problems with Dacia's Medianav) I was wrongly believed that it won't work without @toek79's changes. I was wrong!
Today I installed your last released image on my Pi Zero 2 W and it just works! :) So now I can confirm that your project it is working on the Renault Zoe 2016 with R-Link 1/evolution (with enabled wired AA).
I was not using it for a long time, but I hope it will continue to work great! :)
Much thanks for your time spent on this project! It is working better then commercial boxes available on AliExpress and it is opensource !
Hi everyone, I can confirm that the latest version 0.4.0 installed on Raspberry Pi Zero 2 W, connected via OTG port in the Dacia Duster 2 facelift with MediaNav 4 with version 9.1 works. There are problems only if you disconnect the USB and reconnect it because it is not certain that Android Auto will reconnect, so the advice is to always leave it connected, it would be good solve this problem so that Android Auto always starts. I'll also throw out a nice idea for development, it would be nice to use the Raspberry as a storage for personal music and be able to read it as a multimedia source or be able to attach a memory stick with music to the Raspberry remaining USB port and be able to listen to it, I don't know if it already works, as soon as I can try to see if it works.
There are problems only if you disconnect the USB and reconnect it because it is not certain that Android Auto will reconnect, so the advice is to always leave it connected, it would be good solve this problem so that Android Auto always starts.
weird because the latest release's changelog is saying:
Multiple reliablitly improvements:
- Retry bluetooth connection to phone if phone fails to connect within appropriate time.
- Retry entire connection if USB fails to connect within 10 seconds in phone-first mode.
- More reliably reconnect if the Android Auto connection fails for some reason.
I'll also throw out a nice idea for development, it would be nice to use the Raspberry as a storage for personal music and be able to read it as a multimedia source or be able to attach a memory stick with music to the Raspberry remaining USB port and be able to listen to it, I don't know if it already works, as soon as I can try to see if it works.
I am not an expert but I guess one single USB connection mode is allowed - so if it is in AndroidAuto mode, then no mass storage at the moment, but I may be wrong.
Hi,
Today for the first time during my experience I've got "Disconnected" info on the Nav screen of the car. My android phone seems to be still working fine. The problem is that it cannot reconnect again no matter how long I was waiting (I was also trying to reconnect on the phone forcing on/off Airplane mode
). Finally i just rebooted the Raspberry and I was able to connect again.
So it seems that the Pi has stuck in some weird state. Fortunately I was able to obtain the logs when it was failing to connect. Here it is: https://skyboo.net/temp/aa/10.0.0.1_20240427150919.txt
@nisargjhaveri Maybe you'll find something useful... Maybe some changes from @toek79 branch would be helpful? No idea - just guessing...
@nisargjhaveri If I have a loop with:
Jan 1 00:17:51 buildroot user.info aawgd[265]: AA Wireless NewConnection
Jan 1 00:17:51 buildroot user.info aawgd[265]: Path: /org/bluez/hci0/dev_7C_89_56_13_D0_BB, fd: 160
Jan 1 00:17:51 buildroot user.info aawgd[265]: Sending WifiStartRequest (ip: 10.0.0.1, port: 5288)
Jan 1 00:17:51 buildroot user.info aawgd[265]: Sent WifiStartRequest, messageId: 1, wrote 17 bytes
Jan 1 00:17:51 buildroot user.info aawgd[265]: Read WifiInfoRequest. length: 0, messageId: 2
Jan 1 00:17:51 buildroot user.info aawgd[265]: Sending WifiInfoResponse (ssid: AAWirelessDongle, bssid: 2c:cf:67:44:26:21)
Jan 1 00:17:51 buildroot user.info aawgd[265]: Sent WifiInfoResponse, messageId: 3, wrote 70 bytes
Jan 1 00:17:51 buildroot user.info aawgd[265]: Read WifiStartResponse. length: 2, messageId: 7
Jan 1 00:17:52 buildroot user.info aawgd[265]: Read WifiConnectStatus. length: 2, messageId: 6
Jan 1 00:17:52 buildroot user.info aawgd[265]: Bluetooth launch sequence completed
Jan 1 00:17:54 buildroot daemon.err bluetoothd[166]: src/profile.c:ext_io_disconnected() Unable to get io data for AA Wireless: getpeername: Transport endpoint is not connected (107)
Do you think that changing strategy to 1 or 2 might help or this is not related?
Hello there, I also have a Dacia (with media display) and I also had some issues... changing usbaccesory
timeout seems to solve the issue. I'm still testing.
https://github.com/nisargjhaveri/WirelessAndroidAutoDongle/issues/98#issuecomment-2099430073
@hkfuertes Thanks! Is it sufficient to clone the repo with this change and then build it from this dir using docker-compose? Will it include the local change even uncommited?
Yes, if you want to test it, sure, put a 0 for infinite or a higher value and build. :)
I tried both with Raspberry Pi 2 W and 4. Same situations The Bluetooth connection is successful, but it remains in the loop on "searching for android auto..." The connection with Android Auto does not appear on the car display