[Ovmsdev] OVMS Poller module/singleton

Sun Jan 19 20:51:38 HKT 2025

With my latest push - you could also call AddFilter() before turning on the
CAN bus and reduce the load on the Poll queue.

//.ichael

On Sun, 19 Jan 2025 at 20:40, Simon Ehlen via OvmsDev <
ovmsdev at lists.openvehicles.com> wrote:

> Hi,
>
> Am 19.01.2025 um 12:48 schrieb Michael Balzer via OvmsDev:
>
> 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:
>
> esp32can::InitController():
> […]
>   /* Set sampling
>    * 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
>    * 0 -> single; the bus is sampled once; recommended for high speed
> buses (SAE class C)*/
>   MODULE_ESP32CAN->BTR1.B.SAM=0x1;
>
> 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."
>
> If setting SAM=0 for 500 kbit/s, our timing setup is exactly as
> recommended by two tested SJA1000 timing calculators on the web.
>
> Maybe we should give that a try? I.e.
>
>   MODULE_ESP32CAN->BTR1.B.SAM = (MyESP32can->m_speed < CAN_SPEED_125KBPS)
> ? 1 : 0;
>
> Simon, can you try if that helps?
>
>
> I have adjusted the corresponding line.
> I will check tomorrow whether this has an effect on the active mode.
> 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.
>
> 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?
>
> RegisterCanBus(1, CAN_MODE_LISTEN, CAN_SPEED_500KBPS);
> RegisterCanBus(2, CAN_MODE_LISTEN, CAN_SPEED_125KBPS);
> 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?
>
> Cheers,
> Simon
>
>
>
> Am 17.01.25 um 17:49 schrieb Michael Balzer via OvmsDev:
>
> OK, I've got a new idea: CAN timing.
>
> Comparing our esp32can bit timing to the esp-idf driver's, there seem to
> be some differences:
>
> https://github.com/espressif/esp-idf/blob/master/components/hal/include/hal/twai_types_deprecated.h#L75
>
> 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.
>
> Is that plausible?
>
> 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.
>
> The atomic types are said to be fast, but I never checked their actual
> implementation on the ESP32. Maybe they can block as well?
>
> @Simon: it would be an option to try commenting out the overflow counting,
> to see if that's causing the issue.
>
> Regards,
> Michael
>
>
> Am 17.01.25 um 15:37 schrieb Chris Box via OvmsDev:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Chris
>
>
> On 2025-01-15 18:18, Derek Caudwell via OvmsDev wrote:
>
> 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.
>
> ....
> 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.
>
> 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.
>
> It might be useful to have an extra option on the enable can write to only
> enable it when the car is parked/charging.
>
>
>
>
>
> _______________________________________________
> 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 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 listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> 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/20250119/c5d6746c/attachment.htm>