As you can see in the second screenshot, standard OBD PIDs are almost non-existent. The interface is working the same way ICE engine based cars do, but the PIDs provided are super-sparse. All PIDs successfully requested and received come with timing information using the format "[### ms]". Engine Type and VIN are answered. They are static values (never change) and kind of "configuration information". The PIDs to report PIDs available (e.g. PID01-20) are served, but just respond "there is almost nothing". The AT requests are used to configure the OBD interface but do not carry useful information.
Looking into the two links it becomes clear that BEV manufacturers tend to not use standard PIDs (if applicable at all) but prefer using the underlying protocols (CAN, OBD II) as a formal frame and put relevant information into custom PIDs only. This in turn means, we'd need a "by manufacturer" or worse "by model" configuration. Moreover, custom PIDs are slow when requested using the OBD gateway.
LapTimer supports custom PIDs, so this could be a next step to test access to BEV information. However, this is limited to parameters which can be post processed at all. Saying "post process" I mean three things: calculation of values, display of values and storage of values.
Example "power and torque":
- for ICEs, LapTimer calculates torque and power developed from MAF or MAP, RPM, engine displacement, volumetric efficiency, engine type and intake type. Parts are read from OBD, parts are in the vehicle's information (see Vehicle Details)
- for BEVs, power calculation would use engine voltage and amperage (in your example, other manufacturers may deliver the product of these, i.e. wattage) plus an engine specific characteristic mapping rpm to torque
- for BEVs, multiple engines are common, power needs to be added up at a minimum, for on track driving analytics, storing multiple engine 's data might be of interest...
- once calculated, display and storage would be identical to BEVs.
- can be calculated from rpm, speed, wheel and drive / gear ratios for BEVs
- for most BEVs, gear is irrelevant
- while gear is extremely important for ICE drivers - the gear needs to match engine characteristics and be the one resulting in max power - it is irrelevant for BEVs; this means displaying and storing it is irrelevant too; while storage can be left empty, gear needs to be removed from video overlays and real time gauge displays for a good user experience; it is good example why driving BEVs is less complicated too...
Actually, LapTimer has most of the calculation and storage part for BEVs implemented already. The reason is the never published "Harry's Biker" app which had a focus on eBikes. They are kind of a mix from motorbikes and BEVs. Harry's Biker uses a proprietary BT LE interfaces (Specialized) to retrieve engine and cadence data. As another indicator, you can select Electric as the energy type already.
So this is kind of "in development" and planning for now.
Next steps:
- In case you are interested, try to configure a common parameter like RPM as a custom PID and let me know if it works with the already existing functionality; let me know if you need assistance beyond the Custom OBD PIDs section in the engine data document available on http://www.gps-laptimer.de/documentation
- I need a list of requirements BEV drivers will have when using LapTimer; the ones that come to mind are power / torque as discussed above, SoC, front / rear power distribution, engine/battery temperature, throttle / brake pedal, what else?
The most important rate LapTimet displayed are the gross and net rates data is received at. LapTimer interprets this value as the number of parameters sets(!) received per second. These parameter sets differ depending on car, but include a minimum of RPM and wheel speed, but often additional MAF/MAP or temperature values.