Live data from your PSA vehicle (Peugeot, Citroรซn) on your smartphone or tablet, directly from the VAN bus.
Don't bore us, give us the screenshots!
๐ See some exciting live videos and pics at https://drive.google.com/drive/folders/1PScPrWulKUc7Rnl3Ug-_TO_tbdkDwQCP !
Main entry screen:
Tuner:
Tuner presets popup:
Audio settings:
CD player:
CD changer:
Second trip counter:
"Pre-flight" checks:
Instrument cluster (YMMV ๐คฃ):
Current location:
Sat nav main menu:
Sat nav enter destination - city:
Sat nav - personal address entry (not mine!):
Sat nav guidance:
Door open popup:
Warning popup:
This application creates a Wi-Fi access point to which you can connect with your smartphone. It contains a captive portal so as soon as you are connected a message gets displayed on your phone to log in. If you tap the message, a browser opens, giving a live visual display of the data as read from the VAN bus.
Of course you can modify the SSID and choose your own password by editing the Config.h
file.
See also the screenshots above.
๐ Note: availability will depend on your vehicle's configuration.
Will not support:
In the beginning of 2000's the PSA group (Peugeot and Citroรซn) used "VAN" bus as a communication protocol between the various comfort-related equipment. Later, around 2005, they started to replace this protocol in their newer cars with the CAN bus protocol, however some models had VAN bus inside them until 2009. This overview lists vehicles that are supposedly fitted with a VAN (comfort) bus.
The application will tap in on the vehicle's VAN bus and visualize the captured data in a browser on your smartphone, tablet, laptop or any other device that runs a web browser. The application will run on any ESP8266 / ESP8285 based board, e.g. Wemos/Lolin D1 mini is supported.
The application will host a HTML web page on standard port 80. It will also host a WebSocket server on standard port 81. The served web page comes with some JavaScript that connects to this WebSocket server in order to stream the live data to be visualized.
The web page itself, as served by this sketch, uses and self-hosts the following open-source bundles:
As said, the served web page self-hosts all resources. No Internet connection is needed!
You can usually find the VAN bus on pins 2 and 3 of ISO block "A" of your head unit (car radio). See https://en.wikipedia.org/wiki/Connectors_for_car_audio and https://github.com/morcibacsi/esp32_rmt_van_rx#schematics .
There are various possibilities to hook up a ESP8266 based board to your vehicle's VAN bus:
Use a MCP2551 transceiver, connected with its CANH and CANL pins to the vehicle's VAN bus. As the MCP2551 has 5V logic, a 5V โ 3.3V level converter is needed to connect the CRX / RXD / R pin of the transceiver, via the level converter, to a GPIO pin of your ESP8266 board.
A board with the MCP2551 transceiver can be ordered e.g. here or here.
Two variants are possible:
Config.h
).
This setup requires GPIO line D1 to be connected, so that the ESP board
wakes up as soon as any activity occurs on the VAN bus.
๐ Notes:
The two terminator resistors R3 and R4 (2 x 100 Ohm, near the CANH and CANL pins) on this transceiver board are meant for operating inside a CAN bus network, but are not necessary on a VAN bus. In fact, they may even cause the other equipment on the bus to malfunction. If you experience problems in the vehicle equipment, you may want to remove (unsolder) these terminator resistors. See also this issue.
- CANH of the transceiver is connected to VAN BAR (DATA B), CANL to VAN (DATA). This may seem illogical but in practice it turns out this works best.
- The clamping circuit (D1, D2, R1) seems to (somehow) help in reducing the amount of bit errors (packet CRC errors).
Use a SN65HVD230 transceiver, connected with its CANH and CANL pins to the vehicle's VAN bus. The SN65HVD230 transceiver already has 3.3V logic, so it is possible to directly connect the CRX / RXD / R pin of the transceiver to a GPIO pin of your ESP8266 board.
A board with the SN65HVD230 transceiver can be ordered e.g. here or here.
The "+12 Volt permanent" variant as described above is possible for this setup too.
๐ Notes:
The terminator resistor R2 (120 Ohm, near the CANH and CANL pins) on this transceiver board is meant for operating inside a CAN bus network, but is not necessary on a VAN bus. In fact, it may even cause the other equipment on the bus to malfunction. If you experience problems in the vehicle equipment, you may want to remove (unsolder) the R2 terminator resistor. See also this issue.
- CANH of the transceiver is connected to VAN BAR (DATA B), CANL to VAN (DATA). This may seem illogical but in practice it turns out this works best.
- The clamping circuit (D1, D2, R1) seems to (somehow) help in reducing the amount of bit errors (packet CRC errors).
๐ Note: I used this schematic during many long debugging hours, but I cannot guarantee that it won't ultimately cause your car to explode! (or anything less catastrophic)
When the IR remote control is used to navigate, e.g. through the sat nav menus, this is usually not reflected on the comfort bus. So, reading the VAN comfort bus is not enough to detect e.g. scrolling through the menus or lists presented.
To see the navigation through the menus and lists also on the browser screen, simply connect an infra-red receiver, e.g. like this one, on pins D5, D6 and D7, facing outward; see also the above schematics.
๐ Notes:
- Don't remove or unsolder the infra-red receiver (PCB) from the original MFD type C display. The original MFD needs that to receive the commands you send to it, in order to generate the correct VAN bus packets.
- The infra-red receiver is not needed to switch screens. If you turn on the head unit (radio, CD player, ...) the screen will automatically switch to it. You can also switch screens on your smartphone or tablet simply by tapping the center of the screen. The smartphone or tablet will cycle only through the applicable screens, i.e., if the head unit is not powered on, the head unit screen will be skipped.
Before proceeding with this project, make sure you check all the following prerequisites.
See Arduino IDE. I am currently using version 1.8.19 but other versions may also be working fine.
Weโll program the ESP8266 using Arduino IDE, so you must have the ESP8266 add-on installed. You will need:
Follow the next tutorial to install the IDE and the ESP8266 Board Package:
In the Arduino IDE, go to the "Sketch" menu โ "Include Library" โ "Manage Libraries...". Make sure to install:
For more explanation on using the Arduino library manager, you can browse to:
๐ Note: for best performance and stability, make sure to copy all the patched files inside and under the VanLiveConnect/Patches/ directory to the indicated directories in your system. In my experience, these patched files significantly improve the stability of the WebSocket (TCP/IP over Wi-Fi) communication.
In the Arduino IDE, go to the "Tools" menu, and choose:
Here is a picture of board settings that have been tested to work:
I seem to have better Wi-Fi performance by setting the variable build.sdk
to:
build.sdk=NONOSDK22x_191122
inside the following file:
%LOCALAPPDATA%\Arduino15\packages\esp8266\hardware\esp8266\2.6.3\platform.txt
To upload the compiled project you will need the following:
First time upload is always via the serial port over USB. After that, the "Over The Air" (OTA) update function will allow uploading via Wi-Fi using a "network port" in the Arduino IDE. See this documentation for help on using the OTA feature of the arduino-esp8266.
If you have no experience in compiling and uploading, have a look at this excellent tutorial for the Wemos D1 mini board
When the compiled sketch is started for the first time on fresh hardware, it will take a few seconds to initialize the flash-based file system. In my experience, a sketch binary uploaded to fresh hardware sometimes causes the board to crash the very first time, but after that it works (uploads) fine.
Android does not like a Wi-Fi connection that does not have an Internet connection.
When connecting to the Wi-Fi access point as offered by the ESP, your android device will present a system notification "PSA display AP has no Internet connection. Tap for options.", similar to this:
When tapping, a popup like this appears:
Make sure to check-mark "Don't ask again for this network", then tap "Yes".
The Wi-Fi icon at the top is now shown, but it has a small "X" in it. This small "X" indicates that the Wi-Fi connection does not offer an Internet connection. Even though, the landing page 'http://<...>/MFD.html' of the ESP can be accessed successfully.
However, it now becomes impossible for the Android device to access the Internet. All network access is routed towards the Wi-Fi connection, which does not offer Internet. This prevents any apps from accessing the Internet.
A commonly suggested option is to turn on the Android developer-option "Settings > System > Developer options > Mobile data always active". But it doesn't work: all apps will still try to use the Wi-Fi connection for their Internet connection. Moreover, having "Mobile data always active" turned on, decreases battery life, so it is a bad idea anyway.
Ideally, we would like all the Android apps to be able to connect to the Internet via mobile data, while at the same time the Android client device is showing the vehicle data as coming in via the (non-Internet) "PSA display AP" Wi-Fi connection
To make the latter possible with mobile data enabled on the Android device, the web server ("WebServer.ino") in the ESP offers a special feature: it will respond to any request for '.../generate_204'. This makes make Android believe that the Wi-Fi connection has an Internet connection, and therefore it chooses Wi-Fi as the preferred medium.
However, even though "Internet access" via Wi-Fi seems now enabled to the Android device, it still sees that the connection is pretty limited. Android tries to access all kinds of other Internet addresses, which (obviously) fails. Therefore, the Android device now presents a different system notification: "PSA display AP has limited connectivity. Tap to connect anyway.":
Make sure to check-mark "Don't ask again for this network", then tap "Yes":
The Wi-Fi icon at the top is now shown without the small "X" in it. The landing page of the ESP can now be accessed via Wi-Fi, even with mobile data enabled.
Unfortunately, the effect is still the same as above: all apps will try to use the (non-Internet) Wi-Fi connection, so all apps still fail to access the Internet.
The solution is to have the web server in the ESP stop responding to requests for '.../generate_204' as soon as a data (WebSocket) connection between the ESP and the Android device is well established.
In this way, the following sequence of events takes place:
More background information and explanation can be found here and here.
If you are using OpenVPN for Android in "Always-on VPN" mode, you will need to add a route to the local network. Without this route, your smartphone or tablet device will not be able to find the ESP device after it connects to the ESP's Wi-Fi access point.
To add the route:
192.168.244.0/24
(note: the "192.168.244."
part must match with the IP address as specified in
Config.h
).Then press the Android 'Back' button to go back to the overview of connection profile.
It is possible (and very convenient!) to automate all actions that are needed to start displaying your vehicle information on your smartphone or tablet as soon as you enter the vehicle. An excellent app that offers all necessary functions is MacroDroid - Device Automation
Below are screenshots that show two macros which perform all the necessary actions:
![]() |
|
---|---|
![]() |
![]() |
Upon connection to the Wi-Fi SSID "PSA display AP", performs the following actions:
Upon disconnection from "PSA display AP", performs the following actions:
Of course, the above actions are just a suggestion. Customize as you like!
In the Arduino IDE, the following libraries are used:
The application itself embeds:
Javascript library jQuery v3.5.1 (compressed, production version) by John Resig is licensed under the MIT License
Font/icons Font Awesome v5.15.2 by Dave Gandy is licensed under the following licenses:
Font Peugeot New
by Emmanuel Benoist for Peugeot Design Lab (http://www.peugeotdesignlab.com)
License: unknown
Question: Will this work on my vehicle?
Answer: I have only tested with one vehicle: a 406 from year 2003 DAM number / Build Code: 9586; see also this page (in Dutch). My vehicle has a so-called "type C" Multi-Functional Display (MFD).
It will work (at least to some extent) if you have a Peugeot of around 1996-2004, fitted with a VAN comfort bus.
As mentioned, VAN bus was used in the beginning of 2000's by the PSA group (Peugeot and Citroรซn) as a communication protocol between the various comfort-related equipment. Later, around 2005, they started to replace this protocol in their newer cars with the CAN bus protocol.
This overview lists vehicles that are supposedly fitted with a VAN (comfort) bus.
Question: Do I still need the original multi-functional display (MFD)?
Answer: Yes, you do. But you do not need its (crappy) LCD to be working. The MFD is only needed to generate the necessary VAN-bus packets to drive the equipment (Tuner, CD-changer, Sat nav, etc.). Maybe in a later stage, I will be able to reverse-engineer the higher-level protocols and state machines that the MFD implmements. But that will take time...
Question: Which web browsers will this work with?
Answer: I have tested successfully on:
For background reading:
This application is open-source and licensed under the MIT license.
Do whatever you like with it, but contributions are appreciated!