Support for Android head unit and Type A display about psavancanbridge HOT 24 CLOSED

Hi. That display should work. However I am not sure how that Android unit works as the trip computer data with the consumption info is already translated to CAN bus. So the data is there floating on the bus, maybe the Android unit just ignores it. It might be possible that tha Android unit needs some CAN packets from the display as well.

from psavancanbridge.

Thanks, I will experiment)

from psavancanbridge.

@DenGorobets Please provide some feedback if it works. And also please provide the type of the Android headunit.

from psavancanbridge.

from psavancanbridge.

Thanks for the detailed answer. For 2: I'll implement the reverse gear on CAN so you won't need the extra wire from the next versions. For 7 you can disable that by disabling the QUERY_AC_STATUS from the config.h file. Unfortunately the display of the RT3 display uses a completely different protocol so that won't work (it is a 125kbps CAN though). The head-unit is the gateway there between the VAN and CAN bus. If you have further progress please get back. I am very interested in how people use my project.

from psavancanbridge.

I installed the display. It displays the values ​​of the on-board computer, it is not clear whether they are true or not, it takes time for tests. There are oddities in the operation of the latest firmware of your converter.
On the latest version of the e2b7ee1 firmware and the VAN library from the ad0dadd version from May 10, the steering column multimedia button Previous self-executes, both in the Radio and Music Applications. In previous versions, this was not (VAN library 640b379 and firmware 00e707a).
When blinking with distant light, only the display of the on-board computer is dimmed, although this should not be so. Android and climate control do not change the brightness.
The door opening display does not always work, sometimes nothing is displayed on the display.
Does not show the opening of the hood, the microswitch may not be working (not tested).

In general, I am pleased with such a converter operation. Without it, I would not have what it is. The Android radio transmits the station frequency and track number from the standard application to the on-board computer display.
If there is any correction and need to be tested, write. In my free time I will test. Thank!
https://photos.app.goo.gl/12aJiSA4G8DPCs3M6

from psavancanbridge.

Hi,

I am sorry to hear that some things are not working well. Unfortunately between the two versions there were some major changes. It shouldn't affect the previous button, but well... it is software so who knows :D

I drove a few hundred kilometers but I haven't encountered the issues you mentioned. So if you have some time please try the versions between them, maybe we can find which commit broke it for you. It would be easier to fix it.

When blinking with distant light, only the display of the on-board computer is dimmed, although this should not be so

I don't quite get this. Could you upload a small video where I can see the display and the speedometer at the same time? So I can get a better understanding what do you mean by that.

The door opening display does not always work, sometimes nothing is displayed on the display.

There were some changes regarding this, please try with POPUP_HANDLER set to 2 and 1 also from the config.h file. I saw that you have a type A display. There was a guy who reported some odd behaviour with that. I bought one but I couldn't reproduce the issues he had. However he said that he had one from a 207 mine was from a 307. There shouldn't be a difference, but who knows... It would be nice if you could try a type C, maybe it solves the display related problems. In the meanwhile I try to test my type A as well, to see how it behaves.

I think I found the issue and pushed a fix in 444cc97

Does not show the opening of the hood, the microswitch may not be working (not tested).

You mean the engine bay? Unfortunately I couldn't test that as I don't have a microswitch there. So it is not implemented at all. However if you have a switch there, maybe you can help with that. Capture some packets with the software (through bluetooth, or serial) while you open and close the engine bay a few times. I try to search for the info in the packets (make sure to blink with the turning light to the left when the engine bay is open, and blink to the right when it is closed, it helps me to distinguish between the states)

Btw what kind of car do you have? SW/Break/CC/Hatchback?

from psavancanbridge.

Sorry for the long answer, not enough time to work with the car.

I don't quite get this. Could you upload a small video where I can see the display and the speedometer at the same time? So I can get a better understanding what do you mean by that.

As you requested, the video with the high beam headlight flashing: video

I think I found the issue and pushed a fix in 444cc97

I uploaded firmware to the controller based on the 26b8979 commit and the latest version of the VAN library. The door status began to display normally with the value POPUP_HANDLER 2, but the volume independently increases or stations or music tracks switch independently (depending on the car model selected in the CAN emulator): video
If you set POPUP_HANDLER 1, the problem disappears, but the display starts to flicker when the doors open (as I understand it, the message clears and the message appears on the display): video

I also noticed that some notifications are repeated 3-4 times: video

There is a difference in the displayed mileage before refueling: with DISPLAY_MODE = 1 (correctly displays) and DISPLAY_MODE = 2 (always displays 18 kilometers).

Last time I forgot to mention that when you hold down the on-board computer button, the mileage indicators are not reset, but the indicators cycle on the display: video

It would be nice if you could try a type C

Unfortunately, I am not able to test on a Type C display.

You mean the engine bay? Unfortunately I couldn't test that as I don't have a microswitch there. So it is not implemented at all.

I looked again and also did not find it)

Btw what kind of car do you have? SW/Break/CC/Hatchback?

I have a hatchback version.

PS: While writing, you committed a new version, in which you found the elimination of lowering the brightness of the display with a short-term inclusion of the main beam headlights. Hopefully testing this week.

from psavancanbridge.

Hi,

Thanks for the videos. Finally I figured out that the type A display works a little bit differentthan the type C. That's why it isn't working that well as it should. I started to rewrite the display handling code but it seems like it is more difficult than I thought at first look. So please be patient, I am working on it.

There is a difference in the displayed mileage before refueling: with DISPLAY_MODE = 1 (correctly displays) and DISPLAY_MODE = 2 (always displays 18 kilometers).

DISPLAY_MODE = 1 is how you should use it. DISPLAY_MODE = 2 was introduced for myself. You can find an explanation for the values in DISPLAY_MODE 2:

https://www.eevblog.com/forum/projects/van-bus-interfacing-(to-read-car-speed-and-engine-rpm-peugeot-206-1-4-hdi-2002)/msg2970126/#msg2970126

I think 18 means that there is 18 liters of fuel left (it changes as you drive or refuel).

Last time I forgot to mention that when you hold down the on-board computer button, the mileage indicators are not reset, but the indicators cycle on the display: video

Going to check this as well.

from psavancanbridge.

Notifications repeated a few times, I noticed that issue also. Generally, the notifications code is mine, and this is not a trivial topic. I want to back to that issues and write some additional code to fix this. Also, I have type A and type C displays, so can test it.

from psavancanbridge.

I checked for myself a correction of the display blinking when the high beam was turned on once. It really stopped fading when the actions shown in the video. But when you turn on the high beam, it takes about 3 seconds until the on-board computer display dims. Found in PSAVanCanBridgeMain.cpp the function responsible for dimming:
if (dataToBridge.DashboardLightingEnabled && dataToBridge.NightMode)
{
brightness = 11;
}
else
{
brightness = 15;
}
and remade it like this:
if (dataToBridge.DashboardLightingEnabled)
{
brightness = 11;
}
else
{
brightness = 15;
}
Now the display also does not blink when the high beam is turned on once, immediately dims the backlight when the high beam is turned on, and even dims when the low beam is turned on (before the changes, the brightness was dimmed only when the high beam was turned on).

from psavancanbridge.

@DenGorobets
Originally I wanted to dim the display only when the dipped beam or the high beam is on (two turns on the lights stalk) thats why I included a 3 seconds timeout (otherwise it is impossible to distinguish if you are flashing with the beam, or you turned it on). With your modification the display is dimmed as soon as you turn on your side lights (one turn on the lights stalk). If you feel more comfortable with your change I can add that as a default behaviour to the software.

@karolp1993
I started to rewrite the display handling logic from scratch without the queue. This time the code should be more simple. Now I also have a type A display so I can test that as well. So I suggest to wait for a few days until you start working on it.

from psavancanbridge.

With your modification the display is dimmed as soon as you turn on your side lights (one turn on the lights stalk)

My option is more comfortable for me, as it works without delay and the brightness decreases along with all displays in the car. Can make a choice in Config.h?

from psavancanbridge.

I think I'll make yours the default, without a config as you are right, that way it will get dimmed with all the displays. I'll look more like a factory installation.

from psavancanbridge.

@karolp1993
I started to rewrite the display handling logic from scratch without the queue. This time the code should be more simple. Now I also have a type A display so I can test that as well. So I suggest to wait for a few days until you start working on it.

Sounds interesting but how without queue? My only idea is to make a map of all popups and mark the popup which wants to show.

from psavancanbridge.

By looking at some older captures it seems that the messages are going away by themselves. So after a while the BSI starts to send FF as the message id which means no message should be displayed. The other thing I have noticed is that the old display remembers which message was shown last time. So if you send that message on the VAN bus it just ignores it. So if we want to have the same functionality with the new display, we need to implement the same behaviour: store the last message which was displayed (if it wasn't a door related message) so a queue shouldn't be required. Of course this means that if you have and auto light on message followed by an automatic door locking message and another auto light on message then the auto light will get displayed twice (separated by another message). But that is how it works on the old display and that is the intended behaviour. If we don't want certain messages to be displayed more than one then we need to create an array with those messages and mark them as shown so those will be ignored until the next ignition cycle (just like how I implemented the ice alert message. There is no other way.

from psavancanbridge.

With original display, for example, when message "Fuel level low" appears, after that auto lighting, antipollution fault and others are displaying. What about that situation?

from psavancanbridge.

On the type A display, I did not notice false messages, only their repetition (for example, a message about the automatic turning on of wipers or headlights, as in the video in the message above)

from psavancanbridge.

And that's how it works with original display.

from psavancanbridge.

I prefer having everything displayed just like the original display does it but I admit that some of the messages can be quite frustrating. In my opinion it is pretty dangerous to swallow repeated messages as we didn't really now what is going on inside the BSI. In my opinion there are some harmless messages like the auto lighting, automatic door locking, auto wiper (etc..) messages which doesn't really matter if they get displayed or not. But an antipollution fault, fuel level low, airbag/abs errors should be displayed in every circumstances (as many times as the BSI decides to send them to the display). But at the end the software is open source, and with the config.h file and the architecture it is possible to have several implementation for the display so everybody can choose which version to use :)

from psavancanbridge.

@DenGorobets @karolp1993
Hi guys thanks for your patience with these issues. These were pretty nasty ones. The trip computer data flickering (#10) seems to be finally fixed. Also I created a new popup handler which should resolve some issues with the type A display and with some repetitive popup messages. Now POPUP_HANDLER type 3 is the default in the config.h file. This should work just as the original display did even with type A displays. (I tested the original display and the CAN version side by side). Unfortunately from time to time a door message flickers once-twice but I couldn't remove it completely. But now it should be way better than it was before.

@DenGorobets you mentioned that it is impossible to reset the trip computer data. I found the root cause of this, and created an issue (#9). I know what should be the solution but unfortunately I ran into some issues while implementing it (I described it in the issue text). So it needs further investigation and work so it is on my todo list, but it needs some additional time. In the meanwhile as a workaround you can reinstall your original display and reset the trip data while. After resetting, you can remove the original display again.

from psavancanbridge.

Hi. I have flashed the latest firmware. Everything is fine with notifications, but again there was a problem with independent switching of tracks on the Android radio. Only it happens less often than on DISPLAY_MODE = 1. So far, I left the previous version of the firmware. I don't even know why this problem appears on Android, but not on the standard one.

from psavancanbridge.

Hi, @DenGorobets.

I bought a Junsun Android head unit which is pretty similar to yours: https://www.aliexpress.com/item/4000114216216.html. I haven't installed it in the car yet, just hooked it quickly to check whether it is working or not. I had the same issue as you had with the repeated keypresses. I made some quick fixes (3bcd943 and 8844884) to the code and it seems it resolved the keypress issues.

As it was expected the Android device is working in a different way than the original head unit so it was required to distinguish two operating modes for the two units. I implemented the autodetection of the original head units based on one of the CAN messages which the RD4/RD43 and RD45 are sending regularly. So if I got this particular message I assume that a factory unit is installed. If I don't get this message that means we have an Android unit. So if for some reason both of them (Android and RD4x) are installed (or my PSAWifiDisplayController) then issues can occur. But if only one headunit is installed then it should work fine. If you have time please test it and report if something is still wrong.

Edit:
The reverse gear detection on the CAN bus is working so the additional wiring is not needed anymore, and I incorporated the fix for the dashboard lighting a few weeks ago. So that should be also fine.

Edit2:
Actually the reverse gear detection is still needs a wire. Just the CAN box and wiring loom sent by the seller should contain that wire preinstalled.

from psavancanbridge.

No reply in 4 months, closing it now.

from psavancanbridge.