<div dir="ltr">Hi Chris<div><br></div><div>Here are the required changes, as I understand them, to be compiled into a new firmware from this thread: <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1102/files">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1102/files</a></div><div><br></div><div>Cheers</div><div>Derek</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 21 Jan 2025 at 10:48, Michael Balzer via OvmsDev <<a href="mailto:ovmsdev@lists.openvehicles.com">ovmsdev@lists.openvehicles.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
Chris,<br>
<br>
there is no prepared branch for these changes, as we still try to
determine the best (most compatible) configuration.<br>
<br>
You need to apply the suggested changes manually to the current
master.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 20.01.25 um 19:56 schrieb Chris Box
via OvmsDev:<br>
</div>
<blockquote type="cite">
<p>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.</p>
<p>Chris</p>
<p><br>
</p>
<p id="m_3502584311878067824reply-intro">On 2025-01-19 19:47, Derek Caudwell via
OvmsDev wrote:</p>
<blockquote type="cite" style="padding:0px 0.4em;border-left:2px solid rgb(16,16,255);margin:0px">
<div id="m_3502584311878067824replybody1">
<div dir="auto">
<div dir="auto">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.</div>
<div dir="auto"> </div>
<div dir="auto">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.</div>
<div dir="auto"> </div>
<div dir="auto"> </div>
</div>
<div>
<div dir="ltr">On Mon, 20 Jan 2025,
8:31 am Michael Balzer via OvmsDev, <<a href="mailto:ovmsdev@lists.openvehicles.com" rel="noreferrer" target="_blank">ovmsdev@lists.openvehicles.com</a>>
wrote:</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Derek,<br>
<br>
<div>Am 03.05.24 um 12:53 schrieb Derek Caudwell via
OvmsDev:</div>
<blockquote type="cite" style="padding:0px 0.4em;border-left:2px solid rgb(16,16,255);margin:0px">When
running <strong>firmware </strong><span style="color:rgb(0,34,0);font-family:ui-monospace,"Cascadia Mono","Segoe UI Mono",Hack,"Source Code Pro","Roboto Mono",Menlo,Monaco,Consolas,monospace;font-size:13px"><strong>3.3.004-74-gbd4e7196</strong>
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.</span></blockquote>
<br>
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.<br>
<br>
Poller tracing control was introduced in <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7e4046042a99339d0212aac8f874cc8f780e634e" rel="noopener noreferrer" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7e4046042a99339d0212aac8f874cc8f780e634e</a>
on May 12.<br>
<br>
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?<br>
<br>
<br>
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:<br>
<br>
Our timing is:<br>
<span style="font-family:monospace"> case
CAN_SPEED_500KBPS:<br>
cnf1=0x00; cnf2=0xf0; cnf3=0x86;<br>
= PROP=1, PS1=7, PS2=7, SJW=1, Sample 3x @56.3%</span><br>
<br>
Remember, the SAE/CiA recommendation is SJW=2, Sample 1x
@87.5%. That would translate to:<br>
<span style="font-family:monospace"> PROP=5, PS1=8,
PS2=2, SJW=2, Sample 1x @87.5% =<br>
cnf1=0x40; cnf2=0xbc; cnf3=0x81;</span><br>
<br>
I also checked the Arduino MCP_CAN lib, and that uses:<br>
<span style="font-family:monospace"> cnf1=0x40;
cnf2=0xe5; cnf3=0x83;</span><br>
<span style="font-family:monospace"> = PROP=6, PS1=5,
PS2=4, SJW=2, Sample 3x @75%<br>
</span><br>
So our timing for 500 kbit/s on the MCP buses also isn't
as recommended.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<span style="font-family:monospace"></span></blockquote>
</div>
</div>
</blockquote>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div>