[Ovmsdev] OVMS Poller module/singleton

[Michael Balzer]

Chris,

there is no prepared branch for these changes, as we still try to 
determine the best (most compatible) configuration.

You need to apply the suggested changes manually to the current master.

Regards,
Michael


Am 20.01.25 um 19:56 schrieb Chris Box via OvmsDev:
>
> I'm happy to try some new code on my Leaf. Which code should I use? 
> The current master, or a different branch? It wasn't clear to me from 
> the thread below.
>
> Chris
>
>
> On 2025-01-19 19:47, Derek Caudwell via OvmsDev wrote:
>
>> I can't recall testing a later version but I think Chris can confirm 
>> he was on a later version when his Leaf had a similar problem.
>> The Leaf is now my wife's daily drive so I won't be able to take a 
>> look at making the suggested changes for a couple of weeks at least.
>> On Mon, 20 Jan 2025, 8:31 am Michael Balzer via OvmsDev, 
>> <ovmsdev at lists.openvehicles.com> wrote:
>>
>>     Derek,
>>
>>     Am 03.05.24 um 12:53 schrieb Derek Caudwell via OvmsDev:
>>>     When running *firmware **3.3.004-74-gbd4e7196* on my Nissan Leaf
>>>     I suspect (but can't be 100% sure as it's only been 24h without
>>>     fault) the new poller caused the car to throw the attached
>>>     faults from overloading the can bus whilst driving. The fault
>>>     was sufficient to send the car into limp mode and could not be
>>>     driven until cleared with LeafSpy.
>>
>>     Build 3.3.004-74 (released 2024-04-30) did not yet include the
>>     poller tracing control, i.e. it did lots of logging for frames,
>>     significantly affecting overall performance.
>>
>>     Poller tracing control was introduced in
>>     https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7e4046042a99339d0212aac8f874cc8f780e634e
>>     on May 12.
>>
>>     That commit was first included in build 3.3.004-103-g11fddbf6
>>     released 2024-05-25. Do you remember testing that build or a
>>     later one?
>>
>>
>>     But as I still don't understand how a software queue overflow
>>     could cause a bus crash, I've also checked the 500 kbit timing
>>     for the MCP2515 and found that may have the same issue as the 125
>>     kbit timing:
>>
>>     Our timing is:
>>       case CAN_SPEED_500KBPS:
>>         cnf1=0x00; cnf2=0xf0; cnf3=0x86;
>>       = PROP=1, PS1=7, PS2=7, SJW=1, Sample 3x @56.3%
>>
>>     Remember, the SAE/CiA recommendation is SJW=2, Sample 1x @87.5%.
>>     That would translate to:
>>       PROP=5, PS1=8, PS2=2, SJW=2, Sample 1x @87.5% =
>>         cnf1=0x40; cnf2=0xbc; cnf3=0x81;
>>
>>     I also checked the Arduino MCP_CAN lib, and that uses:
>>         cnf1=0x40; cnf2=0xe5; cnf3=0x83;
>>       = PROP=6, PS1=5, PS2=4, SJW=2, Sample 3x @75%
>>
>>     So our timing for 500 kbit/s on the MCP buses also isn't as
>>     recommended.
>>
>>     Derek, could you test the SAE/CiA recommendation and the MCP_CAN
>>     config as shown? Or anyone else with a live can2/can3 bus at 500
>>     kbit?
>>
>>     If these work, the question is which is the more general setup we
>>     should adopt. Apparently the MCP_CAN lib also does not follow the
>>     CiA recommendation, I wonder if the MCP_CAN config is a
>>     compromise for compatibility.
>>
>>     Regards,
>>     Michael
>>
>
> _______________________________________________
> 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/55bc60e1/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/55bc60e1/attachment-0001.sig>