<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    Hi Robin,<br>

    <br>

    I'm guessing that the VIN might only be accessible on one of the two

    CAN interfaces.  Would that be sufficient to determine which bus is

    which?<br>

    <br>

    Greg<br>

    <br>

    <br>

    <div class="moz-cite-prefix">Robin O'Leary wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:20180506005627.GA8337@mail.ro.nu">

      <pre wrap="">On Tue, May 01, 2018 at 09:59:04PM +0800, Mark Webb-Johnson wrote:

</pre>

      <blockquote type="cite">

        <pre wrap="">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="">

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>

      <fieldset class="mimeAttachmentHeader"></fieldset>

      <br>

      <pre wrap="">_______________________________________________

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>

  </body>

</html>