VAN bus interfacing (to read car speed and engine RPM Peugeot 206 1.4 HDI 2002)

[morcibacsi]

You need to have the esp32 in the car all the time as it acts as a gateway between the VAN bus and the CAN bus.

[henrioliver]

I understand, I'm going to start assembling the board, I ordered the printing of the PCB in China at a lower cost, in the end with all the components the cost is a little high, but having the new CB will be worth it Very thanks for public your project and congratulations for the excellent work.

[reggaester]

Hi Peter
https://github.com/morcibacsi/JunsunPSARemote
It will work with van can bridge also?

[morcibacsi]

If you order a Junsun headunit for CAN bus cars you will get a Raise CAN box. If you connect this box to the CAN part of my VAN-CAN Bridge it works (temperature, and remote controls at the steering wheel, display brightness based on the headlights). However with the help of the library the VAN-CAN Bridge can be left out as custom software can be made to translate the VAN messages for the Junsun unit. For example my PSASteeringWheelAdapter could have an extension for remote control.

[reggaester]

Hi Peter,
I have seen some bridge firmware updates. Can you tell us what other improvements are you planning?
Will the problem with the reset button ever be solved?

[morcibacsi]

Hi,

Yeah, there were some issues reported by users which were quite annoying to prevent the usage of the device for them. Recent fixes included a function to read the VIN code from the radio. So now it isn't necessary to know the VIN code of it, and one doesn't need to have access to a car with CAN bus, and diagnostics interface. Another hotfix needed to be released because in some cars the door status was flickering (again ). And also with some odometer brightness setup the display was blinking. These issues needed special attention.
Currently I work on some code refactorings, to support a new type of board, which could be more compact and professional-looking. The reset button fix is definitely on my todo list as that might be the last one to have a full conversion (that might be the next one to fix after the code refactor). Also trying to make the TSS461 VAN protocol driver working instead of the TSS463. This should be done because the TSS463 will eventually run out of stock and the TSS461 can be scavenged from old displays, and odometers. There are two other things that I would also like to implement. One of them is to support the RD3 radio with the new display. And the other one is to support the newer navigations (RT3/RT6/RNEG, etc). However this has low priority as I couldn't figure out the messages for the compass on them until now (It is calculated somehow from the wheels rotation speeds and its differences). It seems like a tough job.

Edit: BTW the source code is there... contributions are welcome. Feel free to implement the features you miss the most.

[agmar]

Hi all
morcibacsi can i ask you  is there a way to use a bluetooth - gadget receiving music from phone meant to be installed on RD4 (aux connector )  -  on an RD3 ( cd changer connector) 

[morcibacsi]

Unfortunately it isn't. There are such devices for RD3 as well. I am sure you can find them on aliexpress, or ebay or some other similar sites.

[reggaester]

Hi Peter,
After the last update, the car goes into economy mode when it is closed, the radio and display of course are off. Do you know this problem.

The reset button now works, but when pressed and held before the milage resets, the computer reads into a loop. Do you think it can be made to look like the original?

[morcibacsi]

After the last update, the car goes into economy mode when it is closed, the radio and display of course are off. Do you know this problem.

Fixed it yesterday.

The reset button now works, but when pressed and held before the waveform resets, the computer reads into a loop. Do you think it can be made to look like the original?

I am well aware of that issue, but one step at a time (you just got the reset functionality working). After the reset is done, you can go back to your favourite page, so it isn't a deal breaker. Eventually it might get fixed, but as I said before the code is there for everyone to make it better. I like working on the project, but you have to understand that I work on it in my free time. Demanding new features and fixes won't exactly help in getting updates faster.

[reggaester]

Sorry I didn't notice this update 

I am well aware of that issue, but one step at a time (you just got the reset functionality working). Eventually it might get fixed, but as I said before the code is there for everyone to make it better. I like working on the project, but you have to understand that I work on it in my free time. Demanding new features and fixes won't exactly help in getting updates faster.

I understand it 100% and big thanks for this project.

[morcibacsi]

I released a new version which should fix the issues with the trip reset functionality. Updating the TSS463 library to v2.0.0 is also necessary.

[reggaester]

Hi Peter.
12 pin emfs are quite expensive and 6 pins ones often cost half as much, so do you think this display will work?
of course, if I convert the plug to the one in the picture and attach the pins

[morcibacsi]

Hi,

Unfortunately it uses a newer protocol, so it won't work. When I find the time I'll try to add support for it.

[RJSV]

(I wrote OBDII coding for SNAP-ON TOOLS, BALCO 1992-1995).
 I must say, finding the shear BULK DETAIL of this thread was hard to follow. I suspect some manufacturers like the obscurity, as a defacto 'copy protection' to protect the product line.
   And this VAN and CAN, ...Who or what are they ?
Only kidding there, but assuming that's a standard??? Along with 'MUX', another mystery sounding term.
'MUX' to me as a software engineer, simply means shared system, especially meaning 'shared system data BUS'. But I wouldn't go straight to a hardware schematic, to figure out that protocol.
   I believe this sh1#t goes straight to the heart of the 'right to repair' dynamic seen recently.
So, if a person thinks about it, is it a good business model, excluding perfectly competent techs from repair access (i.e. OBD data stream etc)?
I just think it would be fair, taking customer CASH money, to supply non-propriety interface, to car computer. It's running the dang dashboard CLOCK, among other things: that is ridiculous that an owner is locked out, from access to software features.

   That said, I did see some very minor things done, such as reversal of bit 7, that sort of oddball mode of use, really only purpose being to lock customer out of access, for repair, curiosity, or whatever (legal) pursuit an auto hobbiest wants to try, on his own car.
Thank you.

[morcibacsi]

We have to divide the work done in this thread to two parts.

The first part was trying to come up with a software solution to a problem which is really a job of a hardware (i.e.: try to parse the signals travelling on the wire to something which is humanly readable). For this there is a hardware solution (the TSS463 VAN controller IC), but it isn't as widespread as the CAN controllers (like the MCP2515). This is because the VAN bus had its limitation so the world moved on and replaced it with another solution which is the CAN. Also the VAN bus was mainly used in cars produced 15-20 years ago only in models made by Peugeot and Citroen. This means that there is a lack of interest in the VAN bus as the userbase is quite small.... but back to the hardware: Imagine that the CAN wasn't a wide-used protocol, so there wouldn't be CAN controllers available to decode the signals. The same steps would be necessary to somehow rebuild the data floating around on the wires from software.

When there was a method to retrieve the data in a human readable format there was the second task to figure out what the data encoded in these messages are doing.

Would it be obscure? Well it is if I think about it in a way that there is no open database for the users, where everything is well-documented. Could an average user do anything with that information? I really doubt it. I mean when something is wrong in a car, these messages are either not present, or damaged as this is on the lowest level in a car (it is beyond OBD). Figuring out any errors from damaged or missing packets is almost impossible (the DATA lines aren't even exposed to the outside world, you need to disassemble the dashboard to get to them). Even registered repair shops, or people who are specialized in Peugeot and Citroens are lack of the information how the data goes around the wires. It is beyond a point what is necessary to know for people outside the software engineering world. But apart from this... I agree it would be nice if these information was available, it would make my hobby much easier

Oh MUX comes from MUltipleXed network. The earliest Peugeot 206 models didn't have the VAN bus, which resulted in much more cables around the car.

[henrioliver]

hello morcibacsi, how are you? Could you let me know if the reset functionality is working without depending on the original display? Thanks

[morcibacsi]

Hi, I am fine thanks. Yes, it works.

[bagou91]

Hi morcibacsi,

I created a board with arduino and TSS463, and i connected an EMF-B.
I use your sketch tss463_van_monitor.ino
EMF-B display correctly date, hour, and temperature.

if i understand correctly, functions TripButtonPressed() and AnswerToTripData() simulate press button on right commodo and allow to send the information on the display.

I try to display the line fuel consumption and trip distance (odb info), but nothing appear on emf-b.
I use random values on bytes:
14-15::int:   : range (km)
16-17::int: X/10   : consumption (mean) l/100 km
22-23::int:   : consumption (immediate) l/100 km
24-25::int:   : mileage (km)


can you help me ?

thank

[morcibacsi]

Hi,

Indeed it is a trip button replacement with the simultaneous press of two buttons on the radio stalk for those who don't have the trip button on their COM2000. It was a while ago I was experimenting with that, but it was working. Unfortunately I don't have the setup right now to test for you. But one question I have which might get you started: are you sure that the trip computer functionality is enabled in the display you are testing? It needs to be enabled with PP2000.

[bagou91]

Hi,

Yes i enabled odb in emf-b with pp2000.

Update:
I reused your sketch without modification, and it's ok: odb display correctly
But, when add frame ID E24 with VIN wich repeat every 1s, odb no longer wants to display.
in loop, I add this:
//VIN[] = "VF 17 chars"
VANInterface->set_channel_for_transmit_message(4, 0xE24, VIN, 17, 0);

maybe there is conflict between this frame or channel... ??

I can't quite understand how channels work ....


Update2:
Finally, I changed priority (or order) of frame with channel parameter.
I did like this:
channel 4 = frame E24 for sending VIN
channel 4 = frame 8A4 for brightness display and temperature
channel 5 = frame 8C4 (function tripbuttonpressed)
channel 6 = frame 564 (function answertotripdata)

before push trip button (simulate), it is also necessary to wait about 1 minute after starting sketch for the odb reacts.
maybe there are traffic jams in the first frames ...

but the essential: everything works as I want

[BL4]

Hi morcibacsi,

I own a Peugeot 307 from 2003 and bought an android radio on aliexpress where the seller divided the types of compatible radios by A, B and C taking into account the years and whether or not they had controls on the steering wheel. According to the seller my car would be type C. The radio came with a CAN box "Hiworld-PSA PA11.20" however the steering wheel controls do not work. When researching about this I found this forum and your work on converting VAN signals to CAN, so I would like to know if it is yours
Can PSASteeringWheelAdapter and/or PSAVanCanBridgeHW projects be used to get the commands working on my radio?

[morcibacsi]

With some work it should be possible. I also have a repository for controlling Junsun headunits directly. You can check that out here: https://github.com/morcibacsi/JunsunPSARemote But if you are not familiar with Arduino I would recommend buying a ready to use adapter from aliexpress. I think this should work https://www.aliexpress.com/item/1005001779396537.html

[BL4]

Thank you for the link.

Really a ready-made solution would be the best option for me, however today the radio seller told me that what I need to do for the controls to work is to connect the main line of the steering wheel controls to the Key1 line of the radio.

I was a little confused by this explanation because from what I understand there isn't a main line that comes from the steering wheel controls right?

I also found this adapter (https://www.ebay.es/itm/401566426307?hash=item5d7f3964c3:g:u6UAAOSwjZ5bRyiC) which seems to work with any radio and has connections to Key1 (the connection the seller told me about).

[morcibacsi]

There is no "main line" for the steering wheel controls. It is connected to the network of the car, so there is nothing to hook up to the Key1. The Android devices I saw were connected to the car on the "CAN RX" and "CAN TX" port (those aree actually TTL serial ports) and the "CAN box adapter" was responsible for translating the signal of the cars (CAN or VAN bus) to TTL signals. The adapter you found might work, but I can't tell you that for sure. What type of Android unit did you buy?