<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thanks Mark! I think that should fix it.<div>Sorry for making the bug!</div><div><br></div><div>Best regards,</div><div>Geir</div><div><div id="AppleMailSignature" dir="ltr">Sendt fra min iPhone</div><div dir="ltr"><br>8. mai 2019 kl. 14:10 skrev Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>:<br><br></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8">It seems the change made in commit 4fa745190bac56a4501787590ee95bf644532dbf (Geir) was to VEHICLE_POLL_TYPE_OBDIIEXTENDED response, to add support for multi-frame extended responses. However, that change removed the support for single frame responses (as used by Volt/Ampera).<div class=""><br class=""></div><div class="">The code is currently checking for:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">// Multi-frame initial response</div><div class="">      if (((frame->data.u8[0]>>4) == 0x1)&&</div><div class="">          (frame->data.u8[2] == 0x40+m_poll_type)&&</div><div class="">          ((frame->data.u8[4]+(((uint16_t) frame->data.u8[3]) << 8))  == m_poll_pid))</div></div><div class="">…</div><div class=""><br class=""></div><div class="">// Multi-frame second response</div><div class="">else if (((frame->data.u8[0]>>4)==0x2)&&(m_poll_ml_remain>0))</div><div class="">….</div></blockquote><div class=""><div><br class=""></div><div>I have now added back:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div><div>// Single frame response</div><div>else if ((frame->data.u8[1] == 0x62)&&</div><div>               ((frame->data.u8[3]+(((uint16_t) frame->data.u8[2]) << 8)) == m_poll_pid))</div></div></div></blockquote><div class=""><div><br class=""></div><div>Byte 0 should be the number of bytes in the response. Geir’s modification seems to look for a 1 in the high nibble, so that shouldn’t match for ’normal’ single frame responses. For a single frame response, m_poll_ml_remain should always be zero.</div><div><br class=""></div><div>So, I think my modification should not affect Geir’s usage, and should add back support for single frame extended responses (as used by Volt/Ampera). But, I don’t have any active polling dumps from volt/ampera, so no way to test it beyond the very rudimentary testing I have done (can can1 rx standard 7EC 05 62 83 34 12 34, at the appropriate time).</div><div><br class=""></div><div>Could someone with a volt/ampera please test this, and see if it works? I have built into edge as 3.2.001-206-g0f4c05b.</div><div><br class=""></div><div>If it doesn’t work, can we get a CRTD dump during the active poll (ignition on)?</div><div><br class=""></div><div>Regards, Mark</div><div><br class=""><blockquote type="cite" class=""><div class="">On 8 May 2019, at 1:52 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">There seems to be an issue with the latest OBD2 polling code changes (?)<br class=""><br class=""><a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/221" class="">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/221</a><br class=""><br class="">…or maybe it's just a Volt/Ampera issue? We should try to clarify / resolve that for 3.2.002.<br class=""><br class="">It would be so nice if Espressif would at least communicate on the PSRAM fix progress…<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class=""><br class="">Am 08.05.19 um 07:31 schrieb Mark Webb-Johnson:<br class=""><blockquote type="cite" class="">Let’s cut-off at Friday night (UTC). Then, Saturday I will build a 3.2.002 and put it into ‘eap'. Then perhaps ‘main’ mid next week?<br class=""><br class="">I had hoped that Espressif would fix the PSRAM corruption issue, but they say still working on it - I think no point waiting longer for that.<br class=""><br class="">Regards, Mark<br class=""><br class=""><blockquote type="cite" class="">On 8 May 2019, at 1:23 PM, Anko Hanse <<a href="mailto:anko_hanse@hotmail.com">anko_hanse@hotmail.com</a>> wrote:<br class=""><br class="">Hi Michael,<br class=""><br class="">I am currently testing a change that I would really like in there, as it is a follow-up to earlier changes in this version (making the Leaf code less dependent on the 'max_gids' setting)<br class="">So far the tests gave no issues, so I think I will be ready to push my changes either tomorrow or Friday.  Could you wait with the new release until then?<br class=""><br class="">OKidoki,<br class="">Anko<br class=""><br class="">-----Original Message-----<br class="">From: Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> <br class="">Sent: Wednesday, 8 May 2019 6:58 AM<br class="">To: <a href="mailto:ovmsdev@lists.openvehicles.com">ovmsdev@lists.openvehicles.com</a><br class="">Subject: [Ovmsdev] Time for 3.2.002?<br class=""><br class="">The Twizy code has finally reached release 1.0. With my recent additions, all V2 features I planned to include in V3 are now done.<br class=""><br class="">As we're also again >200 commits from 3.2.001, maybe it's time for 3.2.002?<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class="">--<br class="">Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class=""><br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></blockquote></blockquote><br class="">-- <br class="">Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<br class="">Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class=""><br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>OvmsDev mailing list</span><br><span><a href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a></span><br><span><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a></span><br></div></blockquote></div></body></html>