[Ovmsdev] OVMS Poller module/singleton
Michael Balzer
dexter at expeedo.de
Sun Jan 19 21:54:24 HKT 2025
OK, here's my analysis & comparison of our 125 kbit timing for the MCP2515:
We currently use:
mcp2515::Start()
[…]
case CAN_SPEED_125KBPS:
cnf1=0x03; cnf2=0xf0; cnf3=0x86;
// BRP=3, PRSEG=0, PS1=6, PS2=6, SJW=0, BTLMODE=1, SAM=1, SOF=1,
WAKFIL=0 → Sample point at 9/16 = 56,25%
break;
That results in this timing, with a very early sample point and a narrow
sync jump width of 500 ns:
The Arduino MCP_CAN library uses this config:
#define MCP_16MHz_125kBPS_CFG1 (0x43) /* Increased SJW */
#define MCP_16MHz_125kBPS_CFG2 (0xE5)
#define MCP_16MHz_125kBPS_CFG3 (0x83) /* Sample point at 75% */
Which results in this timing:
This sets the sample point later and doubles the SJW. This has
The CiA recommendation of sampling at 87.5% and SJW 2 would require this
config:
case CAN_SPEED_125KBPS:
cnf1=0x43; cnf2=0xbc; cnf3=0x81;
Timing:
IOW, our timing seems to be quite far off.
The 125 kbit configuration is only used by the Tesla Model S adapter
currently, maybe it's OK for the Tesla, but not generally?
@Mark, do you remember where you got the MCP 125 kbit timing from?
(introduced in commit eb78f8ec8509fe20f501bfb4946e809d29e2bb1d)
@Simon, you could test these alternative setups on can2:
a)
// CiA recommendation: PROP=5, PS1=8, PS2=2, SJW=2, sampling 1x @87.5%
cnf1=0x43; cnf2=0xbc; cnf3=0x81;
b)
// Arduino MCP_CAN: PROP=6, PS1=5, PS2=4, SJW=2, sampling 3x @75%:
cnf1=0x43; cnf2=0xe5; cnf3=0x83;
Regards,
Michael
Am 19.01.25 um 13:39 schrieb Simon Ehlen via OvmsDev:
> 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
--
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/d0e4aa55/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 125kbit-ovms-current-03-f0-86.png
Type: image/png
Size: 41163 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250119/d0e4aa55/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 125kbit-arduino-mcp-can-43-e5-83.png
Type: image/png
Size: 41340 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250119/d0e4aa55/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 125kbit-cia-recommend-43-bc-81.png
Type: image/png
Size: 40833 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250119/d0e4aa55/attachment-0005.png>
-------------- 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/d0e4aa55/attachment-0001.sig>
More information about the OvmsDev
mailing list