[Ovmsdev] Time for 3.2.002?

[Mark Webb-Johnson]

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))
….

I have now added back:

// 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

> On 8 May 2019, at 1:52 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> 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 at 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 at expeedo.de> 
>>> Sent: Wednesday, 8 May 2019 6:58 AM
>>> To: ovmsdev at 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 at 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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190508/a229af09/attachment.htm>