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
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
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
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
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@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@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.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Thanks Mark! I think that should fix it. Sorry for making the bug! Best regards, Geir Sendt fra min iPhone
8. mai 2019 kl. 14:10 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
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@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@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.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
The 3.2.002 has been built, and is in both edge and eap release level on api.openvehicles.com <http://api.openvehicles.com/>. Regards, Mark.
On 8 May 2019, at 1:31 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (4)
-
Anko Hanse -
Geir Øyvind Vælidalo -
Mark Webb-Johnson -
Michael Balzer