On 2025-01-23 08:19, Michael Balzer wrote:

did you take the can status outputs _before_ unplugging the OVMS when the car wouldn't enter drive ready?
 
No, unfortunately at the time I was only thinking of wanting to get the car working again.
 
 
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.
 
 
Previously I was using git master firmware from 19th November. I covered 800 miles in two months using this firmware and only experienced one issue (drive going to neutral).
 
As this firmware gave me an issue on the same day I flashed it, this morning I've reverted the bus timing back to how it was before. But I've kept the single sampling change:
 
MODULE_ESP32CAN->BTR1.B.SAM = (MyESP32can->m_speed < CAN_SPEED_125KBPS) ? 1 : 0;
 
So we'll see how this one goes.
 
 
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.
 
Could I do this by looking at these counters? e.g. delays/overflow/fails/err/invalid/resets.
 
OVMS# can can1 status
CAN:       can1
Mode:      Active
Speed:     500000
DBC:       none
 
Interrupts:             6752500
Rx pkt:                 6752388
Rx ovrflw:                    1
Tx pkt:                     737
Tx delays:                    0
Tx ovrflw:                    0
Tx fails:                     0
 
Err flags: 0x00000000
Rx err:                       0
Tx err:                       0
Rx invalid:                   0
Wdg Resets:                   0
Wdg Timer:                    0 sec(s)
Err Resets:                   0

The above set was taken before charging.

After charging (and soc limit applied):

OVMS# can can1 status
CAN:       can1
Mode:      Active
Speed:     500000
DBC:       none
 
Interrupts:             7294918
Rx pkt:                 7294172
Rx ovrflw:                    1
Tx pkt:                    1103
Tx delays:                   50
Tx ovrflw:                    0
Tx fails:                   144
 
Err flags: 0x008040d9
Rx err:                       0
Tx err:                     128
Rx invalid:                   0
Wdg Resets:                   0
Wdg Timer:                    2 sec(s)
Err Resets:                   0
 
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
 
I think I'll first give this new firmware a couple of days to see if it's free of issues.
 
If it is, then I could reapply the bus timing changes and then set can1 into listen mode. And see how that goes.
 
Chris