[Ovmsdev] OBD-II dongle message mapping for EVs

[Greg D.]

Hi folks,

Apologies in advance for the long email.  I am looking for feedback on a
potential feature-addition for the OVMSv3 software.

As I've mentioned earlier, I have a side project to get an OBD-II dongle
running in my Tesla Roadster.  The overall project was to put a few
applications on a Raspberry Pi for in-car use (but not regarding the car
itself), some of which need an Internet connection.  A
too-good-to-pass-up deal from T-Mobile last fall netted me a "free"
SyncUp Drive dongle, which offers a Wi-Fi hotspot in addition to a
number of vehicle monitoring functions.  Much better than tethering my
cell phone.  The dongle, however, is not supported in my Roadster (or
any EV), and it goes into standby about 5 minutes after turning on.  So,
the side project was to create an "OBD-II simulator" to keep the dongle
happy enough to keep the Wi-Fi on and not go to sleep.

Using that Raspberry Pi and a CAN Hat, I have succeeded in creating a
small program that provides enough simulated stimulus that the dongle
stays running (yea!), but of course the simulated data is of no use in
vehicle monitoring.  I don't currently care about that, but from earlier
discussions on this forum, it seems like creating a properly translated
OBD-II port with the OVMSv3 would be of some interest for use with
similar or other OBD-II dongles.  The idea would be to use two of the
CAN interfaces in the OVMSv3 hardware for connecting to the vehicle, and
the third interface would provide the EV-translated OBD-II port for the
dongle.

The question then is, what information is of interest to be provided,
and what OBD-II messages should be used for that purpose?

I have attached a first draft spread sheet of the CAN messages, based on
what my SyncUp Drive dongle reads, and what values might realistically
be returned for them by the simulator.  Please let me know if you have
any suggested additions or corrections to what I have proposed. 

I have connected a regular OBD-II diagnostic dongle (OBDLink SX) to the
simulator, and can view the various (though currently dummy) parameters
returned.  This is probably the best use for the feature, where you can
monitor, log and graph things that the OVMS App doesn't provide access to. 

In the specific case of the SyncUp Drive dongle, most of these
parameters are not directly visible by their smartphone application. 
They digest the data and attempt to provide a higher level "service" to
warn you of issues with the car, give nanny-level alerts (e.g. speeding,
geo-fence violations, aggressive driving), etc., none of which I have
any use for, and several of which may have privacy implications.  My
guess is that they also monetize and/or share the data stream (they
apparently have a deal with Allstate Motor Club for roadside assistance,
for example), so I intend to have the sharing of the VIN configurable... :)

Your thoughts?

Thanks,

Greg



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OVMS PID Mapping.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 6766 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170605/14aa7bc1/attachment.xlsx>