<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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 <anko_hanse@hotmail.com> 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 <dexter@expeedo.de> <br class="">Sent: Wednesday, 8 May 2019 6:58 AM<br class="">To: ovmsdev@lists.openvehicles.com<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="">OvmsDev@lists.openvehicles.com<br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<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="">OvmsDev@lists.openvehicles.com<br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>