<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 6 May 2018, at 4:02 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Robin,<br class="">
<br class="">
just a note: I've used this neat ISO-TP implementation for my
Arduino projects: <a class="moz-txt-link-freetext" href="https://github.com/altelch/iso-tp">https://github.com/altelch/iso-tp</a><br class="">
<br class="">
…specifically for <a class="moz-txt-link-freetext" href="https://github.com/dexterbg/Twizy-Cfg">https://github.com/dexterbg/Twizy-Cfg</a> to provide
the OBD2 commands.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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 :)<br class="">
<br class="">
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.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 06.05.2018 um 02:56 schrieb Robin
O'Leary:<br class="">
</div>
<blockquote type="cite" cite="mid:20180506005627.GA8337@mail.ro.nu" class="">
<pre wrap="" class="">On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">Suggestion: Can the model year of the car be determined from the VIN?
We do that for a few other of the models.
</pre>
</blockquote>
<pre wrap="" class="">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:
<a class="moz-txt-link-freetext" href="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</a>
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!
</pre>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>