openinverter forum

I'm looking at options to display my vehicle data on a display in my car, ideally an Android tablet. The simplest way to do this would seem to the the Torque app. Does Openinverter have any support for J1979 / ISO15765 / OBD-II, or would I need my VCU to buffer cache the data and provide the OBD-II responses?

OBD-2 is very straight forward luckily. As it is a query response type structure.

I modified this arduino code to work for some testing: https://github.com/spoonieau/OBD2-ECU-Simulator

Orion is quite detailed on how they done it too. https://www.orionbms.com/general/retrie ... d2-canbus/

tom91 wrote: ↑Sat Jul 02, 2022 3:18 pm OBD-2 is very straight forward luckily. As it is a query response type structure.

Yep, shouldn't be too tricky to implement, and I guess it makes sense to have a single device collect the data and handle all OBD2 queries.

catphish wrote: ↑Sat Jul 02, 2022 3:42 pm

tom91 wrote: ↑Sat Jul 02, 2022 3:18 pm OBD-2 is very straight forward luckily. As it is a query response type structure.

Yep, shouldn't be too tricky to implement, and I guess it makes sense to have a single device collect the data and handle all OBD2 queries.

I do not know if the Torque app allows you to connect to multiple ECUs, so you could be forced into collecting or atleast gatewaying.

I am currently refactoring the CAN module anyway to separate the hardware from the logic part, so I might add an OBD2 layer as well.
I'm kind of tired of my android radio not reliably connecting via wifi so this would be a good alternative.

tom91 wrote: ↑Sat Jul 02, 2022 3:58 pm I do not know if the Torque app allows you to connect to multiple ECUs, so you could be forced into collecting or atleast gatewaying.

My thought was that if each ECU only responds to requests it knows the answer to, and there's no overlap, there shouldn't be a problem with them all using the same address.

johu wrote: ↑Sat Jul 02, 2022 8:26 pm I am currently refactoring the CAN module anyway to separate the hardware from the logic part, so I might add an OBD2 layer as well.
I'm kind of tired of my android radio not reliably connecting via wifi so this would be a good alternative.

It would be fantastic if this is something that can be added. I love the web interface for programming / tuning / debugging, but once the vehicle is up and running, OBD2 would likely be the better option, at least for monitoring. The ESP8266 drives me a little mad.

I just sent a PR to add OBD2 support to the stm32-vcu code: https://github.com/damienmaguire/Stm32-vcu/pull/57

I just created a custom service that maps PID to Param num and let the displaying app deal with formatting it. This was a bit tricky since there appears to be some pretty bad bugs in the Torque code for dealing with signed 32 bit values, but I found a way to brute force it with the basics that do work.

I also mapped a few of the really basic SAE pids to existing params, but we could certainly add more.

tom91 wrote: ↑Sat Jul 02, 2022 3:58 pm I do not know if the Torque app allows you to connect to multiple ECUs, so you could be forced into collecting or atleast gatewaying.

The TorquePro definitely connects to multiple ECUs. I use it in Hyundai Ioniq. The gateway is just routing the requests and responses to/from the other buses. The gateway does not collect the data autonomously.

BTW: ISO15765 is only the transport layer, which makes it possible to transport up to 4095 bytes per PDU. Above is the diagnostic protocol, in these days usually UDS. I think it makes sense to implement this, it is a standard. In one of Damiens videos I even saw that he used ODIS as counterpart on PC side. This is a standard tool for measurement, parametrization, dealing with error memory and running io-control. (I have no idea where he found an unlocked version.)

Does every electric vehicle have a standard pid list for obd2? Or is there a different pid list for the per vehicle? Do you have an example