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