[Ovmsdev] OVMS Poller module/singleton

Michael Balzer dexter at expeedo.de
Mon Jan 20 15:33:16 HKT 2025


> 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)

AddFilter with bus=0 (actual zero, not '0') translates to "any bus", 
which is handy for can logging. Probably not needed for a vehicle 
implementation, but still I'd suggest keeping it consistent, so '0' + 
busno should only be applied for busno >= 1.

I think the char digits for actual buses stuck from the string spec 
parsing, could be changed if necessary.

Regards,
Michael


Am 20.01.25 um 01:40 schrieb Michael Geddes via OvmsDev:
> 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 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
>>>
>>>         _______________________________________________
>>>         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
>>
>
>     _______________________________________________
>     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

-- 
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/20250120/1b243862/attachment-0001.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/20250120/1b243862/attachment-0001.sig>


More information about the OvmsDev mailing list