[Ovmsdev] OVMS Poller module/singleton

[Derek Caudwell]

Hi Chris

Here are the required changes, as I understand them, to be compiled into a
new firmware from this thread:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1102/files

Cheers
Derek

On Tue, 21 Jan 2025 at 10:48, Michael Balzer via OvmsDev <
ovmsdev at lists.openvehicles.com> wrote:

> Chris,
>
> there is no prepared branch for these changes, as we still try to
> determine the best (most compatible) configuration.
>
> You need to apply the suggested changes manually to the current master.
>
> Regards,
> Michael
>
>
> Am 20.01.25 um 19:56 schrieb Chris Box via OvmsDev:
>
> I'm happy to try some new code on my Leaf. Which code should I use? The
> current master, or a different branch? It wasn't clear to me from the
> thread below.
>
> Chris
>
>
> On 2025-01-19 19:47, Derek Caudwell via OvmsDev wrote:
>
> I can't recall testing a later version but I think Chris can confirm he
> was on a later version when his Leaf had a similar problem.
>
> The Leaf is now my wife's daily drive so I won't be able to take a look at
> making the suggested changes for a couple of weeks at least.
>
>
> On Mon, 20 Jan 2025, 8:31 am Michael Balzer via OvmsDev, <
> ovmsdev at lists.openvehicles.com> wrote:
>
> Derek,
>
> Am 03.05.24 um 12:53 schrieb Derek Caudwell via OvmsDev:
>
> When running *firmware  **3.3.004-74-gbd4e7196* on my Nissan Leaf I
> suspect (but can't be 100% sure as it's only been 24h without fault) the
> new poller caused the car to throw the attached faults from overloading the
> can bus whilst driving. The fault was sufficient to send the car into limp
> mode and could not be driven until cleared with LeafSpy.
>
>
> Build 3.3.004-74 (released 2024-04-30) did not yet include the poller
> tracing control, i.e. it did lots of logging for frames, significantly
> affecting overall performance.
>
> Poller tracing control was introduced in
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7e4046042a99339d0212aac8f874cc8f780e634e
> on May 12.
>
> That commit was first included in build 3.3.004-103-g11fddbf6 released
> 2024-05-25. Do you remember testing that build or a later one?
>
>
> But as I still don't understand how a software queue overflow could cause
> a bus crash, I've also checked the 500 kbit timing for the MCP2515 and
> found that may have the same issue as the 125 kbit timing:
>
> Our timing is:
>   case CAN_SPEED_500KBPS:
>     cnf1=0x00; cnf2=0xf0; cnf3=0x86;
>   = PROP=1, PS1=7, PS2=7, SJW=1, Sample 3x @56.3%
>
> Remember, the SAE/CiA recommendation is SJW=2, Sample 1x @87.5%. That
> would translate to:
>   PROP=5, PS1=8, PS2=2, SJW=2, Sample 1x @87.5% =
>     cnf1=0x40; cnf2=0xbc; cnf3=0x81;
>
> I also checked the Arduino MCP_CAN lib, and that uses:
>     cnf1=0x40; cnf2=0xe5; cnf3=0x83;
>   = PROP=6, PS1=5, PS2=4, SJW=2, Sample 3x @75%
>
> So our timing for 500 kbit/s on the MCP buses also isn't as recommended.
>
> Derek, could you test the SAE/CiA recommendation and the MCP_CAN config as
> shown? Or anyone else with a live can2/can3 bus at 500 kbit?
>
> If these work, the question is which is the more general setup we should
> adopt. Apparently the MCP_CAN lib also does not follow the CiA
> recommendation, I wonder if the MCP_CAN config is a compromise for
> compatibility.
>
> Regards,
> Michael
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
> Fon 02330 9104094 * Handy 0176 20698926
>
> _______________________________________________
> 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/20250121/6a8f9608/attachment.htm>