[Ovmsdev] OVMS Poller module/singleton

Mon Jan 20 08:40:51 HKT 2025

The AddFilter calls canbus::AddFilter.

If the frame 'MsgID' matches the bus and is within the range, then it is
INCLUDED.

This means if you add a filter for one bus, you have to add it for all
busses.
AddFilter('1', 0x700, 0x800) ;
would allow only msgid from 0x700 to 0x800 for bus 1.
The char is a bit weird, but that's the original call.
I wonder if I should make it a bit different in the translation.

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)

If you included that in a commit, I wouldn't object.

//.

On Mon, 20 Jan 2025 at 04:51, Simon Ehlen via OvmsDev <
ovmsdev at lists.openvehicles.com> wrote:

> Am 19.01.2025 um 13:51 schrieb Michael Geddes:
>
> With my latest push - you could also call AddFilter() before turning on
> the CAN bus and reduce the load on the Poll queue.
>
> Hi Michael,
>
> I'd be happy to try it out. Can you please give me brief instructions on
> how to use AddFilter()?
> Do I enter the MsgIDs that I want to evaluate or the ones that should be
> discarded?
>
> Thank you!
> Cheers,
> Simon
>
> 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
>>
>
> _______________________________________________
> 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/20250120/5a517713/attachment.htm>