E208 Car

[Jomega Gibson]

HelloI in turn launch into the experience on my vehicle : the new Peugeot e208.

The e208 is based on a new technical platform from the manufacturer, common for thermal and electric models. Perhaps even more specific on the electric for OBD, like any electric vehicle.

After a quick start / installation of the OVMS module, everything seems functional.

Then, I followed the recommendations from the article "General suggestions for adding support for a new vehicle to OVMS".

If the first two steps have gone well, I have a little more trouble for the rest ...

The connection with the 2 can buses seems to be well established. Very verbose data does arrive from can 1 (regular broadcast).

As advised, I use Savvycan to capture the data. I observe an evolution of the data according to the action launched on the vehicle (opening / closing, poweron / off, etc.) but I am unable to extract any concrete information from it.

OVMS does not seem to recognize any of the known standard PIDs, so I have no feedback in the dashboard (no Soc, no VIN, etc.).

The vehicle being very recent, I did not find any documentation on the internet, nor in the somewhat 'specialized' forums.

So I have a few questions, maybe I'm on the wrong track ...

- how to interpret the data collected in Savvycan? if I could identify real values, I would be able to deduce the function concerned.

- I suppose that can2 only responds on request from the OVMS, what type of tests or requests can I test to validate obtaining a response forme the can bus ?

- for all these tests, what is the appropriate setting for "vehicle type" in OVMS, I currently use "OBDII" ?

In general what I do when looking for a particular metric is get the current value, and then look in the bus for messages that could contain that value (formatted in different ways - for example mileage is often represented as 1/10ths of a mile, and could be little or big end Ian). Once I've found some candidate messages, I try to change the metric (by driving the car, for example), and then look for the changed metric value in the messages.

For action style events, I look for changing messages. Filter out anything which is not changing, so you only get a few messages. Ignore those. Then do the action, and see if something else has changed.

Usually, the message ID defines a particular message from a particular ECU in the car (often destined for another ECU). The data bytes that follow are dependent on the message type (ID). So, there can be anywhere from 0 to 8 bytes of data. There are cases, however, where one particular message ID can be overloaded for many different messages, and this is known as a multiplexor. An example of that would be a message containing battery module data, with the first byte indicating the module#.

Look at a temperature, for example. 32celcius could be encoded as 0x20 in hex. But often it is offset to allow for a certain range of negative value - for example +32 offset to allow for -32 upwards. In that case, you would see 0x40 in the data.

SavvyCan has some utility functions to help you try the different alternatives. The good news is that particular car manufacturers tend to standardise, so once you've worked out one message the others tend to be easier.

A good starting approach is to get some dumps in various states of the car. Then look for unique message IDs. Forget about the data - just identify the unique IDs. That becomes your target list. Then go looking for specific metrics.

Hi I've got a Peugeot e-expert which I suspect is very similar. Just wondering where you got to with this. I got an OBD II module from powercruisecontrol but it needed an adaptor to connect a couple of pins to another couple of pins....

I've just purchased an e-208, GT Premium, it will arrive in Jan / Feb 2022. I am interested in interfacing to the CAN BUS and have lots of adapters and cables that I have purchased in the past, however with my current car Audi A5, I have not had much (any) success in getting any data from the CAN BUS.

I have just managed to get the live monitoring with savvycan working. It was necessary to disable the "Require validation of GVRET connection" option in File -> Preferences in order to fix periodic TCP/Telnet connection resets over OVMS Wifi. Still not sure how reliable the recording/transmission is, since I get bursts of traffic with periodic pauses in between. I don't see this pattern in the log files recorded to the SD card. There it looks more like a continuous stream of telegrams.

Not having a reliable live monitor makes it harder to reverse-engineer the data by correlating it with actions in the car (i.e. push the gas pedal, turn on the lights etc). What I can see so far is that none of the actions seem to result in additional IDs being transmitted on the bus (compared to the baseline traffic when no action is performed). So either all modules are continuously transmitting all the time, or they are using yet another bus to communicate which is not accessible on the OBDII port. Further data analysis is necessary to try and pick out events.

My next step will probably be to try and reverse-engineer the functionality of a bluetooth OBDII dongle that I tried out a few weeks ago. With that dongle I was able to display live data such as battery current and vehicle speed on a mobile app. I will try to figure out whether this dongle/app extracts the data from the available data stream or whether it uses some polling mechanism.

Car Scanner is compatible with PSA EVs and have listed the same PIDs from above.

If I understand correctly, to be able to receive the right messages, this string needs to be send in the beginning to configure the connection.

I have no experience with programming a new car within OVMS. I have experience with programming the microcontroller inside (ESP32).

I think it would be fairly easy for an experienced OVMS-programmer to "convert" this into code for OVMS3.

I hope we can make the Peugeot e208 (fully) compatible with OVMS.

3a8082e126