[Ovmsdev] Fixed VIN from IncomingPollReply first frame data?

Mark Webb-Johnson mark at webb-johnson.net
Sun May 6 16:24:57 HKT 2018


I am in favour of a separate service, working in co-operation with vehicle.{h, cpp} and retools.{h, cpp}. Something with command-line syntax as well, for requesting individual PIDs, etc, would be extremely useful.

Regards, Mark.

> On 6 May 2018, at 4:02 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Robin,
> 
> just a note: I've used this neat ISO-TP implementation for my Arduino projects: https://github.com/altelch/iso-tp <https://github.com/altelch/iso-tp>
> 
> …specifically for https://github.com/dexterbg/Twizy-Cfg <https://github.com/dexterbg/Twizy-Cfg> to provide the OBD2 commands.
> 
> The OVMS OBD polling framework is currently really just meant to provide periodical polling of basic registers. I will need a more flexible and complete ISO-TP implementation for issue #95 as well, was thinking about a general service for this like I did with CANopen.
> 
> The Twizy has no standard OBD2 registers and does not follow the standard OBD2 addressing scheme, but of course also provides DTCs and device access via ISO-TP if you know the device addresses.
> 
> The polling framework is necessary for the Renault Zoe implementation as well, and Wolfgang (Zoe developer) also had some troubles with it. So if you'd like to implement a better ISO-TP framework, go ahead :)
> 
> As with CAN, a generalized OBD2 service could later also be configured with just a registers to metrics mapping scheme to provide a basic vehicle adaptation without needing to code anything.
> 
> Regards,
> Michael
> 
> 
> Am 06.05.2018 um 02:56 schrieb Robin O'Leary:
>> On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
>>> Suggestion: Can the model year of the car be determined from the VIN?
>>> We do that for a few other of the models.
>> So in order to read the Leaf VIN and battery data, I had some fun getting
>> to know the ins and outs of ISO-TP and UDS so I could write my own packet
>> reassembler.  Of course, it was only when I had it all working nicely that
>> it dawned on me that Mark's comment above meant that there was probably
>> already code for that somewhere that would have saved me the effort,
>> which there is, in OvmsVehicle::PollerReceive and IncomingPollReply.  Duh!
>> 
>> But when I swapped over to using those methods, I got different
>> results---the first byte of the VIN was missing, and IncomingPollReply
>> never got called with ml_remain==0 for the much longer battery data.
>> So now I was glad that I had my own version for comparison, as it made
>> me more sure than I might otherwise have been that PollerReceive was
>> processing the first frame incorrectly.  Indeed, I think it is doing
>> two things wrong: it starts reading data from byte 5 not byte 4, and it
>> gets the overall length wrong by 2 (this confusion is likely because the
>> length given in the ISO-TP layer includes the two UDS header bytes, but
>> the rest of the UDS processing expects those bytes not to be counted in
>> the data passed to IncomingPollReply).  Fixing both of those made both
>> the Leaf VIN and battery data come out correctly.  My changes are here:
>> 
>> https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-poll <https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-poll>
>> 
>> That leads me to wonder how existing uses of this code haven't run in
>> to the same problems.  It is used in at least two places that seem like
>> they should have been affected:
>> 
>> 	OvmsVehicleOBDII::IncomingPollReply
>> 		case 0x02:  // VIN (multi-line response)
>> 
>> 	OvmsVehicleKiaSoulEv::IncomingVMCU
>>                 case 0x02: // VIN (multi-line response):
>> 
>> So could it be that the PollerReceive code is correct after all and that
>> I am misunderstanding how it works, maybe because there is something
>> odd about the Leaf?  Could any developers knowledgable about the OBDII
>> interface and the Kia Soul see if my changes make things better or worse?
>> Thanks.
>> 
>> btw, I still don't know the answer to the original question of whether
>> the model year of the car can be determined from the VIN, but at least
>> we can now easily see what it is!
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180506/bf34518c/attachment.htm>


More information about the OvmsDev mailing list