[Ovmsdev] OVMS Poller module/singleton

Sun Jan 19 19:48:47 HKT 2025

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?

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?

Regards,
Michael

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 list
>> OvmsDev at lists.openvehicles.com
>> http://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

-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250119/5dd75b8f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250119/5dd75b8f/attachment.sig>