<div dir="ltr"><img src="https://api2.activeinboxhq.com/1.0/anon/rr/3ceb4a1e1676dbea326796182816d69e" width="1" height="1" style="display:none !important">Hi,<div><br></div><div>It seems to do what is expected - thanks, you are very fast!</div><div><br></div><div><font face="monospace">D (706161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1<br>V (706161) canlog-monitor: 1607882591.310736 1T11 6F1 07 03 22 dd bc 00 00 00<br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">D (708161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1<br>V (708161) canlog-monitor: 1607882593.310901 1T11 6F1 07 03 22 dd 68 00 00 00<br></font></div><div><br></div><div>But most times I don't get a reply.</div><div><br></div><div>But not never - here's an example that worked:</div><div><br></div><div><font face="monospace">D (896161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1<br>D (896211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DDBC) code=78 (pending)<br>D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC) frm=0 len=2 off=0 rem=4<br>D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC) frm=1 len=4 off=2 rem=0<br>D (896211) v-bmwi3: BMWI3: got SOC=86.7%<br>D (897161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1<br>D (897211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DD68) code=78 (pending)<br>D (897211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DD68) frm=0 len=2 off=0 rem=0<br>D (897211) v-bmwi3: BMWI3: got Volts=388.77V<br></font></div><div><br></div><div>The car is charging but otherwise "off" and locked.  Perhaps that has something to do with the lack of replies.</div><div><br></div><div>Steve</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 13 Dec 2020 at 18:24, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    Steve,<br>
    <br>
    please try the poller rework I just pushed to the new "isotp-extadr"
    branch.<br>
    <br>
    These <font face="monospace">poll_pid_t</font> records would define
    the example shown in the ELM327 manual:<br>
    <br>
    <font face="monospace">    { 0x7b004, 0x7c0f1,
      VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, {  20, 0, 0 }, 0,
      ISOTP_EXTADR },<br>
          { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP,   0xa2, { 
      30, 0, 0 }, 0, ISOTP_EXTADR },</font><br>
    <br>
    I've used these + matching faked rx frames to verify the
    implementation.<br>
    <br>
    Your SOC poll should look like this:<br>
    <br>
    <font face="monospace">    { 0x6F107, 0x607F1,
      VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, {  0, 10, 60 }, 0,
      ISOTP_EXTADR },<br>
    </font><br>
    …and your <font face="monospace">IncomingPollReply()</font> should
    receive the reply with <font face="monospace">pid == 0x607F1</font>.<br>
    <br>
    Please report your results.<br>
    <br>
    Thanks,<br>
    Michael<br>
    <br>
    <br>
    <div>Am 13.12.20 um 11:33 schrieb Michael
      Balzer:<br>
    </div>
    <blockquote type="cite">
      
      Steve,<br>
      <br>
      sorry, totally missed that. That's very unusual, haven't seen that
      before. I first thought maybe that's using CAN extended frame
      mode, but that's a totally different thing: it seems the i3 uses
      the <b>ISO-TP extended addressing scheme</b>.<br>
      <br>
      Quoting from Wikipedia: <a href="https://en.wikipedia.org/wiki/ISO_15765-2" target="_blank">https://en.wikipedia.org/wiki/ISO_15765-2</a><br>
      <br>
      <blockquote type="cite"><span style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">ISO-TP can
          be operated with its own addressing as so-called<span> </span></span><i style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Extended Addressing</i><span style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>or without address
          using only the CAN ID (so-called<span> </span></span><i style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Normal Addressing</i><span style="color:rgb(32,33,34);font-family:sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">). Extended addressing uses the
          first data byte of each frame as an additional element of the
          address, reducing the application payload by one byte.</span></blockquote>
      <br>
      So it's standard frames, with just an additional byte inserted
      before the protocol, used to extend the CAN ID.<br>
      <br>
      The OVMS poller doesn't support this yet.<br>
      <br>
      But it shouldn't be hard to add support for this, as it basically
      just fills the first frame byte from the lower 8 bits of the TX
      and RX IDs, reduces the payload size by one byte and shifts the
      offsets by one. PollerSend() and PollerReceive() need to be
      extended for this, and poll_pid_t needs to be extended by an
      addressing scheme tag.<br>
      <br>
      I'll have a look. Tell me if you'd like to take care of this.<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div>Am 13.12.20 um 09:58 schrieb Steve
        Davies:<br>
      </div>
      <blockquote type="cite">
        
        <div dir="ltr"><img src="https://ci6.googleusercontent.com/proxy/LKubifKFYqc0jmnuEAEOTQiQoUvXmVzNmQasQaKAvodNtjfvl__1hMdj-c1pnWCjY5_ga2c-GYJME1pC_-ynlBE-gv8ws7HVKrMKTioJt3GJ9dbonz1xOOw_tGjwyw=s0-d-e1-ft#https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b" style="display: none;" width="1" height="1"><img src="https://ci6.googleusercontent.com/proxy/LKubifKFYqc0jmnuEAEOTQiQoUvXmVzNmQasQaKAvodNtjfvl__1hMdj-c1pnWCjY5_ga2c-GYJME1pC_-ynlBE-gv8ws7HVKrMKTioJt3GJ9dbonz1xOOw_tGjwyw=s0-d-e1-ft#https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b" style="display: none;" width="1" height="1"><img src="https://ci6.googleusercontent.com/proxy/LKubifKFYqc0jmnuEAEOTQiQoUvXmVzNmQasQaKAvodNtjfvl__1hMdj-c1pnWCjY5_ga2c-GYJME1pC_-ynlBE-gv8ws7HVKrMKTioJt3GJ9dbonz1xOOw_tGjwyw=s0-d-e1-ft#https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b" style="display: none;" width="1" height="1"><img src="https://ci6.googleusercontent.com/proxy/LKubifKFYqc0jmnuEAEOTQiQoUvXmVzNmQasQaKAvodNtjfvl__1hMdj-c1pnWCjY5_ga2c-GYJME1pC_-ynlBE-gv8ws7HVKrMKTioJt3GJ9dbonz1xOOw_tGjwyw=s0-d-e1-ft#https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b" style="display: none;" width="1" height="1"><img src="https://ci6.googleusercontent.com/proxy/LKubifKFYqc0jmnuEAEOTQiQoUvXmVzNmQasQaKAvodNtjfvl__1hMdj-c1pnWCjY5_ga2c-GYJME1pC_-ynlBE-gv8ws7HVKrMKTioJt3GJ9dbonz1xOOw_tGjwyw=s0-d-e1-ft#https://api2.activeinboxhq.com/1.0/anon/rr/30b419480d275d90878a2c12836ea56b" style="display: none;" width="1" height="1">
          <div dir="ltr"><br>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Sat, 12 Dec 2020 at
              17:28, Michael Balzer <<a href="mailto:dexter@expeedo.de" target="_blank">dexter@expeedo.de</a>>
              wrote:<br>
            </div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div>with log level verbose for canlog, you can simply
                activate CAN logging via:<br>
                <br>
                <font face="monospace">can log start monitor crtd</font><br>
                <br>
                …that will log all frames, if that's too much, add a
                filter like this:<br>
                <br>
                <font face="monospace">can log start monitor crtd
                  600-7ff</font></div>
            </blockquote>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>To see what was happening I had to "log level verbose
              canlog-monitor"</div>
            <div><br>
            </div>
            <div>I see this being transmitted:</div>
            <div><br>
            </div>
            <div>V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1
              03 22 dd bc 00 00 00 00<br>
            </div>
            <div><br>
            </div>
            <div>There is no reply.</div>
            <div><br>
            </div>
            <div>The other app I looked at does this on the LM327 as
              setup before sending the request:</div>
            <div><br>
            </div>
            <div><font face="monospace">2020-11-15 10:34:35.115 -->
                ATCEA07⏎ "extended address" 0x07<br>
                2020-11-15 10:34:35.127 <-- OK⏎⏎><br>
              </font></div>
            <div><br>
            </div>
            <div>Looking at the LM327 data sheet this configures an
              "extended address" which is sent after the 0x6F1 </div>
            <div><br>
            </div>
            <div>I'm not sure if that 0x03 in what OVMS is sending is
              that byte, and I need to somehow replace it wih 07, or if
              I have to get another inserted?</div>
            <div><br>
            </div>
            <div>Perhaps this is old hat to those more experienced than
              me.</div>
            <div><br>
            </div>
            <div>From the data sheet and the trace it seems I'm also
              responsible to customise the flow control messages :-</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><font face="monospace">2020-11-15 10:34:35.129 -->
                ATFCSH6F1⏎ Flow control header<br>
                2020-11-15 10:34:35.141 <-- OK⏎⏎><br>
                2020-11-15 10:34:35.143 --> ATFCSD07300800⏎ Flow
                control data<br>
                2020-11-15 10:34:35.156 <-- OK⏎⏎><br>
                2020-11-15 10:34:35.157 --> ATFCSM1⏎ Flow control
                mode<br>
                2020-11-15 10:34:35.170 <-- OK⏎⏎><br>
              </font></div>
            <div><br>
            </div>
            <div>I think that comes down to a flow control being "06 F1
              07 30 08 00"</div>
            <div><br>
            </div>
            <div>Here's the page in the LM327 to help understand what it
              does:</div>
            <div><br>
            </div>
            <div><img src="cid:1765d45c6d5cb971f161" alt="image.png" style="margin-right: 25px;"><br>
            </div>
          </div>
        </div>
        <br>
        <fieldset></fieldset>
        <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
      </blockquote>
      <br>
      <pre cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
  </div>

_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div>