5 posts / 0 new
Last post
unterix
Peugeot e208

Hello,
I 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.

For the wiring, I share what I found:
On the OBD socket (located on the driver's side, remove the cover under the steering wheel on the left), only the pins 1,3,4,5,6,8,14,16 are wired.
The standard/regulatory CAN bus is on pins 6 and 14 (6: high, 14: low)
The Diagnostic CAN Peugeot bus is on pins 3 and 8 (3: high, 8: low)

Details:
pin 1 + 12v after power
pin 3 can high Peugeot
pin 4 body ground
pin 5 electro ground
pin 6 can high standard
pîn 8 can low Peugeot
pin 14 can low standard
pin 16 + 12v OBD

OVMS side:
Can1 = regulatory/standard can
Can2 = pins 3 and 8 of the OBD socket must be re-mapped on connectors 13 and 12 respectively for OVMS

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" ?

Please found here as an example a Savvycan capture, at the opening of the vehicle.

Thanks for your help !

markwj
markwj's picture
SavvyCAN has some utility

SavvyCAN has some utility functions to help. It can look for particular numbers, etc.

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.

SavvyCAN can help with both the above approaches.

unterix
Hello and thank you for your

Hello and thank you for your reply.
The methodology suits me very well, this is how I will try to move forward.
On the other hand, the question facing me today may seem silly, but how to convert the results into understandable values? like for example miles / km, or a percentage of charge.
Today I cannot interpret data such as:
1587831212.362000 1R11 00000517 DA 0C 03 0C 03 3F CF
1587831212.362000 1R11 00000797 00 00 00 00 00 00 00 00
1587831212.362000 1R11 00000552 03 4E AA 49 00 00 A7 FE
1587831212.362000 1R11 00000512 07 10 00 00
1587831212.362000 1R11 00000412 10 00 00 00 00 3C 00 00
1587831212.362000 1R11 0000056E F4 00 00 00 00 00
I also don't understand why they don't all have the same length.

Thank you for a little help!

Spud_ie
Hi Unterix, have you had any

Hi Unterix, have you had any luck with the data from the e-208?

I've recently got one and am interested in OVMS on the car. I've no experience with the systems and software, but happy to help where I can.

markwj
markwj's picture
Usually, the message ID

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#.

Looking at one example of yours:

00000512 07 10 00 00

That is message ID 512, and 4 data bytes 07 10 00 00. The data could be interpreted in many ways. For example, it could be two 16 bit numbers (0710 and 0000), or four 8bit numbers (07, 10, 00, and 00). It could be a 32 bit number. Or any combination.

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.

A SOC of 64% could be simply 0x40 (hex). But it could also be in 1/10ths of a percent, so 0x280 in hex (and that could be sent as either little or big endian so 02 80 or 80 02).

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.

Log in or register to post comments
randomness