Peugeot e208

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.

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.

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 CAN-BUS shields and ODBC Cables, is there anything that is proven that will enable me to sniff and pick up the following:

• Lights on / off
• Indicators left and right
• Brakes
• Reverse

Thank you,

Simon

hi all, I'm just getting started with OVMS in my Peugeot e208.

Thanks to the info provided by @unterix I was able to correctly wire my own custom cable and connect to both CAN buses. Both buses run at 500'000 bps.

I also get some similar data as @unterix on the standard CAN (pins 6/14). On the Peugeot CAN (pins 3/8) I only get data from the single ID 0x353 with the data always being 00 00 00 00 00.

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.

Please let me know if you make any progress or have any additional insights.

Thanks,

Daniel

On this forum they have found the PID for Peugeot e208. (https://www.goingelectric.de/forum/viewtopic.php?f=325&t=64034&start=70)
There is an open GitHub Issue where the main PID-commands are shown (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/719)

(See https://github.com/EVNotify/EVNotify/issues/205#issuecomment-824842473)

#######
####### Setup commands
#######
ATWS ---; Warm reset set back to defaults
ATI ---; Show interface ID
ATE0 ---; Turn off terminal echo
AT@1 ---;
ATSP6 ---; Set to protocol 6: ISO 15765-4 CAN (11 bit ID 500 kbaud)
ATAT1 ---;
ATL0 ---; Disable line feed
ATS0 ---; Disable sending spaces between hex characters
ATH1 ---; Turn on odb2 header
ATCAF1 ---; Turn on CAN auto formatting
ATSH79B ---; Set request message header 79B
ATFCSH79B ---; Set flow control header (CAN ID)
ATFCSD300000 ---; Set flow control data
ATFCSM1 ---; Set flow control mode; 1 = User defined CAN ID and data
#######
####### Data commands
#######
ATSH6A2 ---; Set the header of transmitted OBD messages to header 6A2
ATFCSH6A2 ---; Set flow control header (CAN ID)
ATCRA682 ---; Set the CAN hardware filter to 682
22D4341 ---; Ambient temperature
22D8EF1 ---; Battery temperature
22D4021 ---; Speed
ATSH6B4 ---; Set the header of transmitted OBD messages to header 6B4
ATFCSH6B4 ---; Set flow control header (CAN ID)
ATCRA694 ---; Set the CAN hardware filter to 694
22D8161 ---; Battery current
22D8151 ---; Battery voltage
22D86F1 ---; Battery minimum voltage
22D8701 ---; Battery maximum voltage
22D4101 ---; SOC calibrated
22D8651 ---; kWh available
22D8601 ---; SOH
22D8101 ---; SOC

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.

Car Scanner - Configuration for PSA	Car Scanner - PID for PSA

There is no need for decrypting RAW data because this is already done by others.

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.

Hello,

thanks to many postings and as well from this board I was able to put in place a running solution to transmit automatically the SOC from my Peugeot 208e to my OpenWB (Wallbox).

IT environment:

- Peugeot 208e (works maybe as well with Opel Corsa E )
- OpenWB
- WICAN-OBD-C3 von MeatPi
- IO Broker

Thanks to all, that are sharing their experience and skills via these kinds of boards.