[Ovmsdev] OVMS Poller module/singleton

Michael Balzer dexter at expeedo.de
Thu Jan 23 16:19:41 HKT 2025


Chris,

did you take the can status outputs _before_ unplugging the OVMS when 
the car wouldn't enter drive ready?

The poller timing statistics also should best be captured in case of the 
event, but any may help.

Also, did you use the new poller firmware before without issues, i.e. 
can you confirm the issue only turns up with the new bus timing test? 
That would confirm it's a timing issue, and it would mean the new timing 
makes it worse.


> How would I look for changes in can error frequency in the log?

Basically by counting the error log entries for each bus to see if they 
generally increase or decrease, in more detail by also taking the error 
types logged into account. Some errors log entries are normal, may even 
occur frequently.


Generally, it seems we currently have no idea which of the two CAN buses 
is actually causing the issue for the Leaf (or the Ford).

So I suggest first isolating this by selectively putting one bus into 
listen mode and testing if the issue then still turns up.

Use the "can <bus> start" command to switch the mode, e.g.: can can1 
start listen 500000

The Leaf derives the car & polling state from process data frames, so 
should switch state also in listen mode.

Regards,
Michael


Am 22.01.25 um 23:25 schrieb Chris Box:
>
> Hi.
>
> I have now experienced some issues with this updated firmware. I drove 
> the car home just fine, and parked. When I locked the car it issued a 
> continuous warning tone suggesting I shouldn't leave the car in that 
> state. All doors were definitely shut. I turned the car back on, and 
> the dashboard said "When parked apply parking brake". But the 
> handbrake was firmly on. On dismissing that, it reported "I-Key system 
> fault". It wouldn't enter drive ready state.
>
> I turned the car off, unplugged OVMS and turned on again. Errors still 
> present. It told me to press the brake pedal in order to turn the car 
> on. I was pressing it, but it didn't seem to recognise this.
>
> After a while I came back and disconnected the 12V. On starting up 
> again the I-Key message was still on the dash. I dismissed it, and 
> then it seemed happy. OVMS is now plugged back in.
>
> I'm guessing these errors are indicative of CAN bus problems, e.g. 
> preventing communication of brake state?
>
> Some command outputs from very recently (i.e. after the events 
> described above):
>
> OVMS# can can1 status
> CAN:       can1
> Mode:      Active
> Speed:     500000
> DBC:       none
>
> Interrupts:             7299933
> Rx pkt:                 7299698
> Rx ovrflw:                    3
> Tx pkt:                    1371
> Tx delays:                   50
> Tx ovrflw:                    0
> Tx fails:                   108
>
> Err flags: 0x008040d9
> Rx err:                       0
> Tx err:                     128
> Rx invalid:                   0
> Wdg Resets:                   0
> Wdg Timer:                    8 sec(s)
> Err Resets:                   0
>
>
> OVMS# can can2 status
> CAN:       can2
> Mode:      Active
> Speed:     500000
> DBC:       none
>
> Interrupts:              210984
> Rx pkt:                  211985
> Rx ovrflw:                    0
> Tx pkt:                       8
> Tx delays:                    0
> Tx ovrflw:                    0
> Tx fails:                     0
>
> Err flags: 0x01000001
> Rx err:                       0
> Tx err:                       0
> Rx invalid:                   0
> Wdg Resets:                   0
> Wdg Timer:                    8 sec(s)
> Err Resets:                   0
>
>
> How would I look for changes in can error frequency in the log?
> In these numbers perhaps?
>
> 2025-01-22 17:28:17.683 GMT E (16789963) can: can2: intr=9475533 
> rxpkt=9494723 txpkt=52 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 
> rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> 2025-01-22 17:28:17.693 GMT E (16789973) can: can2: intr=9475533 
> rxpkt=9494724 txpkt=52 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 
> rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
>
> 2025-01-22 21:40:18.843 GMT E (10075543) can: can2: intr=210249 
> rxpkt=211242 txpkt=8 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 
> rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> 2025-01-22 21:40:18.843 GMT E (10075543) can: can2: intr=210249 
> rxpkt=211243 txpkt=8 errflags=0x23401c01 rxerr=0 txerr=0 rxinval=0 
> rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
>
> I can't see any mentions of can1 in the log, other than ovms-server-v3 
> pollstats. The log is set to debug level.
>
> I have poller times and can share those if needed.
>
> Chris
>
>
> On 2025-01-22 16:24, Michael Balzer via OvmsDev wrote:
>
>> Chris,
>>
>> typically "can can1 status" & "can can2 status" will give the 
>> statistics of the buses, and "poller times on" will enable poller 
>> timing statistics to be then shown by "poller times status".
>>
>> The Leaf uses can2 to query these values:
>> // VIN [19]
>> // QC [2]
>> // L0/L1/L2 [2]
>>
>> ...but only when the car is on, but not in drive mode. So you should 
>> check if you get these values.
>>
>> It also uses can2 for TCU commands, if the model year is >= 2016.
>>
>> So you should try commands and see if they work correctly.
>>
>> Please also check the log for changes in can error occurence & frequency.
>>
>> Regards,
>> Michael
>>
>>> On 2025-01-21 00:41, Derek Caudwell via OvmsDev wrote:
>>>
>>>     Hi Chris
>>>     Here are the required changes, as I understand them, to be
>>>     compiled into a new firmware from this thread:
>>>     https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1102/files
>>>     <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1102/files>
>>>     Cheers
>>>     Derek
>>>

-- 
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/20250123/25a62b2f/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/20250123/25a62b2f/attachment.sig>


More information about the OvmsDev mailing list