[Ovmsdev] OBD-II dongle message mapping for EVs

[Greg D.]

Hi Mark,

I agree that customization would be best, but I know these sorts of
devices are very resource limited.  What would you like me to optimize
around?  What do we have in the v3 version in terms of code space vs
config info (and its user interface) vs RAM vs CPU speed?  Is config
(flash?) storage accessed directly, or is there a file system?  The
current translator is just a set of nested case statements (thus using
code space, zero config, and almost no RAM), but could be done in other
ways now that I understand how OBD-II works. 

Also, if the primary interest is in driving a HUD display, that would be
great to know, as it defines the use-case that I can focus on.  If
anyone has a favorite example, please let me know.  My experience with
the SyncUp dongle reveals that these things are pretty loosely coded
(read: buggy) compared to the standards, so any particular commercial
product may take some fussing with to get running properly.  Which, of
course supports the need for customization...

My fingers are at your command...

Greg


Mark Webb-Johnson wrote:
> 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev