[Ovmsdev] OBD-II dongle message mapping for EVs

[Mark Webb-Johnson]

Greg,

Really looking forward to seeing this integrated. It will be great as a basis for the OBDII HUD display thing I want.

From my point of view, we need some way to map the vehicle metrics to OBDII PIDs. Something that says metric X goes to PID Y in format Z. That would then allow customisation.

Hard to comment on exact PIDs required, based on your list, as I’m not sure what the HUDs I am using look at. Certainly the basics such as speed, rpm, fuel level, temperatures, etc.

Regards, Mark.

> On 6 Jun 2017, at 12:02 PM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> 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
> 
> 
> 
> <OVMS PID Mapping.xlsx>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev