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
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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?
We’re looking ok for code size at the moment. OVMS v2 had around 96KB of flash, and v3 has 4MB per partition. This is 32bit vs 8bit, but you get the idea.
Is config (flash?) storage accessed directly, or is there a file system?
At the moment, I’ve created a 1MB partition and mounted a virtual flash disk there using wear levelling and FAT filesystem. That is not ideal, and I would rather switch to SPIFFS. Either way, we’ll have a filesystem for config storage in flash.
If anyone has a favorite example, please let me know.
I’m playing with a few at the moment. They all just seem to request some pretty standard PIDs. The trick is going to be to mess with the data provided to fool the display into giving us useful information. For example, they all seem to have some sort of fuel consumption estimate and it would be good to adjust the air flow PIDs to give us the required mileage estimates in that place, or perhaps just Wh/km, etc. Once we’ve got your code running in the framework, we can see what the HUDs are actually requesting. Regards, Mark.
On 7 Jun 2017, at 2:03 AM, Greg D. <gregd2350@gmail.com> wrote:
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (2)
-
Greg D. -
Mark Webb-Johnson