<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="">Robin,<div class=""><br class=""></div><div class="">I don’t think many (any?) are using the OBDII code in the real world. It was there mainly as a proof-of-concept, and looks like that part was broken in the polling port from v2 to v3. VIN not coming up correctly (at all) on my ODBII simulator hardware with vehicle module O2.</div><div class=""><br class=""></div><div class="">Not sure about KiaSoulEV.</div><div class=""><br class=""></div><div class="">I applied your patch, and the vehicle module O2 vs simulator hardware now identifies the VIN correctly.</div><div class=""><br class=""></div><div class="">I can’t really apply your whole commit to the master, as it includes other changes (to vehicle_nissanleaf) which is causing conflicts vs @carrott's recent pull request on Nissan Leaf. In general, easier to keep these code code change commits limited to just one commit (for which a pull request can easily be sent):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/110" class="">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/110</a></div><div class=""><br class=""></div><div class="">vs</div><div class=""><br class=""></div><div class=""><a href="https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/commit/06e0b6880f5a8403f4d17c5afc7105a79f609073#diff-24650a03d76690f39398f5127e405236" class="">https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/commit/06e0b6880f5a8403f4d17c5afc7105a79f609073#diff-24650a03d76690f39398f5127e405236</a></div></blockquote><div class=""><br class=""></div><div class="">Anyway, I manually included the fix to vehicle.cpp and committed that to master - you should be able to pull that back into your now. Can you and @carrott work out what is required and re-do the pull request to include both Nissan Leaf changes?</div><div class=""><br class=""></div><div class="">Thanks, Mark.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 6 May 2018, at 8:56 AM, Robin O'Leary <<a href="mailto:ovmsdev@caederus.org" class="">ovmsdev@caederus.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">Suggestion: Can the model year of the car be determined from the VIN?<br class="">We do that for a few other of the models.<br class=""></blockquote><br class="">So in order to read the Leaf VIN and battery data, I had some fun getting<br class="">to know the ins and outs of ISO-TP and UDS so I could write my own packet<br class="">reassembler. Of course, it was only when I had it all working nicely that<br class="">it dawned on me that Mark's comment above meant that there was probably<br class="">already code for that somewhere that would have saved me the effort,<br class="">which there is, in OvmsVehicle::PollerReceive and IncomingPollReply. Duh!<br class=""><br class="">But when I swapped over to using those methods, I got different<br class="">results---the first byte of the VIN was missing, and IncomingPollReply<br class="">never got called with ml_remain==0 for the much longer battery data.<br class="">So now I was glad that I had my own version for comparison, as it made<br class="">me more sure than I might otherwise have been that PollerReceive was<br class="">processing the first frame incorrectly. Indeed, I think it is doing<br class="">two things wrong: it starts reading data from byte 5 not byte 4, and it<br class="">gets the overall length wrong by 2 (this confusion is likely because the<br class="">length given in the ISO-TP layer includes the two UDS header bytes, but<br class="">the rest of the UDS processing expects those bytes not to be counted in<br class="">the data passed to IncomingPollReply). Fixing both of those made both<br class="">the Leaf VIN and battery data come out correctly. My changes are here:<br class=""><br class=""><a href="https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-poll" class="">https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/leaf-poll</a><br class=""><br class="">That leads me to wonder how existing uses of this code haven't run in<br class="">to the same problems. It is used in at least two places that seem like<br class="">they should have been affected:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>OvmsVehicleOBDII::IncomingPollReply<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>case 0x02: // VIN (multi-line response)<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>OvmsVehicleKiaSoulEv::IncomingVMCU<br class=""> case 0x02: // VIN (multi-line response):<br class=""><br class="">So could it be that the PollerReceive code is correct after all and that<br class="">I am misunderstanding how it works, maybe because there is something<br class="">odd about the Leaf? Could any developers knowledgable about the OBDII<br class="">interface and the Kia Soul see if my changes make things better or worse?<br class="">Thanks.<br class=""><br class="">btw, I still don't know the answer to the original question of whether<br class="">the model year of the car can be determined from the VIN, but at least<br class="">we can now easily see what it is!<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class="">OvmsDev@lists.openvehicles.com<br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>