[Ovmsdev] OVMS Poller module/singleton

[Michael Balzer]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250117/a73d6098/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/20250117/a73d6098/attachment.sig>