<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">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>
<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">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">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">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>
<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>
<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>
</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>
</blockquote>
<br>
</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>