<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite">
<div>Maybe the Poller AddFilter should be AddFilter(1, 0x700,
0x800) which passes to the canbus AddFilter( '0' + busno,
busfrom, busto); (to be consistent with the pollers number of
busses)</div>
</blockquote>
<br>
AddFilter with bus=0 (actual zero, not '0') translates to "any bus",
which is handy for can logging. Probably not needed for a vehicle
implementation, but still I'd suggest keeping it consistent, so '0'
+ busno should only be applied for busno >= 1.<br>
<br>
I think the char digits for actual buses stuck from the string spec
parsing, could be changed if necessary.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 20.01.25 um 01:40 schrieb Michael
Geddes via OvmsDev:<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7uJp5P5aheGaKrR0WgT1Wf17EmRUaPWmLJ7+dSt74ftN_A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">The AddFilter calls canbus::AddFilter.
<div><br>
</div>
<div>If the frame 'MsgID' matches the bus and is within the
range, then it is INCLUDED.</div>
<div><br>
</div>
<div>This means if you add a filter for one bus, you have to add
it for all busses.</div>
<div>AddFilter('1', 0x700, 0x800) ;</div>
<div>would allow only msgid from 0x700 to 0x800 for bus 1.</div>
<div>The char is a bit weird, but that's the original call.</div>
<div>I wonder if I should make it a bit different in the
translation.</div>
<div><br>
</div>
<div>Maybe the Poller AddFilter should be AddFilter(1, 0x700,
0x800) which passes to the canbus AddFilter( '0' + busno,
busfrom, busto); (to be consistent with the pollers number of
busses)</div>
<div><br>
</div>
<div>If you included that in a commit, I wouldn't object.</div>
<div><br>
</div>
<div>//.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, 20 Jan 2025 at 04:51,
Simon Ehlen via OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com"
moz-do-not-send="true" class="moz-txt-link-freetext">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">
<div>
<div>Am 19.01.2025 um 13:51 schrieb Michael Geddes:<br>
</div>
<blockquote type="cite">
<div dir="ltr">With my latest push - you could also call
AddFilter() before turning on the CAN bus and reduce the
load on the Poll queue.</div>
</blockquote>
Hi Michael,<br>
<br>
I'd be happy to try it out. Can you please give me brief
instructions on how to use AddFilter()?<br>
Do I enter the MsgIDs that I want to evaluate or the ones
that should be discarded?<br>
<br>
Thank you!<br>
Cheers,<br>
Simon<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 19 Jan 2025 at
20:40, Simon Ehlen via OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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">
<div>
<div>Hi,<br>
<br>
Am 19.01.2025 um 12:48 schrieb Michael Balzer via
OvmsDev:<br>
</div>
<blockquote type="cite"> Regarding CAN timing, our
ESP32CAN/SJA1000 configuration is mostly according
to the SAE/CiA recommendations, with one
exception: we generally enable multi (triple)
sampling, regardless of the bus speed:<br>
<br>
<font face="monospace">esp32can::InitController():<br>
[…]<br>
/* Set sampling<br>
* 1 -> triple; the bus is sampled three
times; recommended for low/medium speed
buses (class A and B) where filtering spikes
on the bus line is beneficial<br>
* 0 -> single; the bus is sampled once;
recommended for high speed buses (SAE class C)*/<br>
MODULE_ESP32CAN->BTR1.B.SAM=0x1;</font><br>
<br>
SAE defines "high speed" (class C) as speeds >=
125 kbit/s. See SAE J2284-1, -2 & -3, section
6.10.8 Data Sample Mode: "The data sampling shall
always be set to single sample mode."<br>
<br>
If setting SAM=0 for 500 kbit/s, our timing setup
is exactly as recommended by two tested SJA1000
timing calculators on the web.<br>
<br>
Maybe we should give that a try? I.e.<br>
<br>
<font face="monospace">
MODULE_ESP32CAN->BTR1.B.SAM =
(MyESP32can->m_speed < CAN_SPEED_125KBPS)
? 1 : 0;</font><br>
<br>
Simon, can you try if that helps?<br>
</blockquote>
<br>
I have adjusted the corresponding line.<br>
I will check tomorrow whether this has an effect on
the active mode.<br>
I tried your recommendation and set the
CONFIG_OVMS_VEHICLE_CAN_RX_QUEUE_SIZE to both 200
and 400. I have not yet checked whether the bus also
crashes in active mode. However, I can see in
listening mode that when I abort a running loading
process (there are currently no overflows), many
overflow messages are received.<br>
<br>
<blockquote type="cite"> But as you also use can2, I
wouldn't rule out a timing issue with the MCP2515
configuration. At which speed do you have can2,
and did you have some indication from the vehicle
error codes regarding a specific bus?<br>
</blockquote>
<div
style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,"Courier New",monospace;font-weight:normal;font-size:14px;line-height:19px;white-space:pre-wrap"><div><span
style="color:rgb(220,220,170)">RegisterCanBus</span><span
style="color:rgb(212,212,212)">(</span><span
style="color:rgb(181,206,168)">1</span><span
style="color:rgb(212,212,212)">, CAN_MODE_LISTEN, CAN_SPEED_500KBPS);</span></div><div><span
style="color:rgb(220,220,170)">RegisterCanBus</span><span
style="color:rgb(212,212,212)">(</span><span
style="color:rgb(181,206,168)">2</span><span
style="color:rgb(212,212,212)">, CAN_MODE_LISTEN, CAN_SPEED_125KBPS);
</span></div></div>
I do not receive any feedback from the car as to
which bus is affected, unfortunately no error code
is saved for the incident. Do you have the option of
specifying the affected bus in the overflow logging?<br>
<br>
Cheers,<br>
Simon<br>
<blockquote type="cite"> <br>
<br>
<div>Am 17.01.25 um 17:49 schrieb Michael Balzer
via OvmsDev:<br>
</div>
<blockquote type="cite"> OK, I've got a new idea:
CAN timing.<br>
<br>
Comparing our esp32can bit timing to the esp-idf
driver's, there seem to be some differences:<br>
<a
href="https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75</a><br>
<br>
Transceivers are normally tolerant to small
timing offsets. Maybe being off a little bit has
no effect under normal conditions, but it has
when the transceiver has to cope with a filled
RX queue. That could be causing the transceiver
to slide just out of sync. If the timing gets
garbled, the transceiver would signal errors in
the packets to the bus, possibly so many the
vehicle ECUs decide to raise an error condition.<br>
<br>
Is that plausible?<br>
<br>
On why the new poller could be causing this (in
combination with too slow processing by the
vehicle): as mentioned, the standard CAN
listener mechanism doesn't care about queue
overflows. The poller does.
`OvmsPollers::Queue_PollerFrame()` does a log
call when Tx/Rx tracing is enabled, that could
even block, but tracing is optional and only
meant for debugging. Not optional is the
overflow counting using an atomic uint32.<br>
<br>
The atomic types are said to be fast, but I
never checked their actual implementation on the
ESP32. Maybe they can block as well?<br>
<br>
@Simon: it would be an option to try commenting
out the overflow counting, to see if that's
causing the issue.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 17.01.25 um 15:37 schrieb Chris Box via
OvmsDev:<br>
</div>
<blockquote type="cite">
<p>Yes, I can confirm I've had one experience
of the Leaf switching to Neutral while
driving, with a yellow warning symbol on the
dash. It refused to reselect Drive until I
had switched the car off and back on. Derek
wasn't so lucky and he need to clear fault
codes before the car would work.</p>
<p>On returning home, I found OVMS was not
accessible over a network. I didn't try a
USB cable. Unplugging and reinserting the
OBD cable caused OVMS to rejoin Wi-Fi.
However the SD logs showed nothing from the
time of the event. CAN writes are enabled,
so it can perform SOC limiting.</p>
<p>My car has been using this firmware since
21st November, based on the git master of
that day. As a relatively new user of OVMS
(only since October) I don't have much
experience of older firmware.</p>
<p>Perhaps a safeguard should be implemented
before releasing a new stable firmware that
will be automatically downloaded by Leaf
owners. But I don't have the expertise to
know what that safeguard should be. Derek's
suggestion of 'only CAN write when parked'
appears to be a good idea.</p>
<p>Chris</p>
<p><br>
</p>
<p
id="m_-4224654484806678593m_7021782356097693777reply-intro">On
2025-01-15 18:18, 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_-4224654484806678593m_7021782356097693777replybody1">
<div dir="auto">Since the following email
I have high confidence the issue on the
Leaf is related/caused by the poller as
there has been no further occurrence and
Chris has also experienced the car going
to neutral on the new poller firmware.
<div dir="auto"><br>
<div dir="auto">....</div>
<div dir="auto">I haven't ruled out it
being a fault with my car yet.
Shortly after it faulted the car was
run into so has been off the road
for sometime, my first step was to
replace 12V battery. The ovms unit
is now unplugged and if it does not
fault over the next month while
driving I'll be reasonably confident
it's ovms related.</div>
<div dir="auto"> </div>
<div dir="auto">Not sure which
firmware version the poller updates
were included in but it was only
after upgrading to it that the
errors occurred (which could be
coincidental however it has faulted
twice more both on version
3.3.004-141-gf729d82c). For periods
where I reverted to 3.3.003 it was
fine.</div>
<div dir="auto"> </div>
<div dir="auto">It might be useful to
have an extra option on the enable
can write to only enable it when the
car is parked/charging.</div>
</div>
</div>
<br>
<div> </div>
</div>
</blockquote>
<p><br>
</p>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
</body>
</html>