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).
The code is currently checking for:
// Multi-frame initial response
if (((frame->data.u8[0]>>4) == 0x1)&&
(frame->data.u8[2] == 0x40+m_poll_type)&&
((frame->data.u8[4]+(((uint16_t) frame->data.u8[3]) << 8)) == m_poll_pid))
…
// Multi-frame second response
else if (((frame->data.u8[0]>>4)==0x2)&&(m_poll_ml_remain>0))
….
// Single frame response
else if ((frame->data.u8[1] == 0x62)&&
((frame->data.u8[3]+(((uint16_t) frame->data.u8[2]) << 8)) == m_poll_pid))
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.
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).
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.
If it doesn’t work, can we get a CRTD dump during the active poll (ignition on)?
Regards, Mark
There seems to be an issue with the latest OBD2 polling code changes (?)
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/221…or maybe it's just a Volt/Ampera issue? We should try to clarify / resolve that for 3.2.002.
It would be so nice if Espressif would at least communicate on the PSRAM fix progress…
Regards,
Michael
Am 08.05.19 um 07:31 schrieb Mark Webb-Johnson:
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?
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.
Regards, Mark
On 8 May 2019, at 1:23 PM, Anko Hanse <anko_hanse@hotmail.com> wrote:
Hi Michael,
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)
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?
OKidoki,
Anko
-----Original Message-----
From: Michael Balzer <dexter@expeedo.de>
Sent: Wednesday, 8 May 2019 6:58 AM
To: ovmsdev@lists.openvehicles.com
Subject: [Ovmsdev] Time for 3.2.002?
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.
As we're also again >200 commits from 3.2.001, maybe it's time for 3.2.002?
Regards,
Michael
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev