On 2025-01-23 16:28, Michael Balzer via OvmsDev wrote:

The CAN status variables are all explained in can.h:
 
 
Thanks for your explanation, which is most helpful.
 
So these are simply indications of RX buffer 0 overflows. These are no "real" overflows, as RX buffer 1 was still available, so the frames were not lost and the rxbuf_overflow counter was not incremented.
 
So with the current code, I should interpret these pairs of errors as a single warning that can2 has a lot of activity, and if it gets worse could result in loss of a frame.
 
It's possible that when I experienced the actual car issues there was something more significant logged. But we don't know because I pulled the plug and the log entries are missing.
 
The driver could clear this condition to avoid signaling this as a CAN error. I think we kept it that way because an RXB0 overflow already indicates a lot of traffic on the bus. This could also result in a warning log, but the CAN framework doesn't know how to distinguish driver specific errors from warnings.

Going back to your earlier advice, I think you're asking us to monitor the rate of can errors in the log, and observe if that changes with different bus timing.

And also monitor can status. With my current firmware (existing timing, single sampling, both buses in active mode) I see can1 is a bit busier than can2 (10 million vs 8.6 million). Can1 has had one genuine receive overflow.

OVMS# can can1 status
CAN:       can1
Mode:      Active
Speed:     500000
DBC:       none
 
Interrupts:            10231357
Rx pkt:                10228979
Rx ovrflw:                    1
Tx pkt:                    1343
Tx delays:                   50
Tx ovrflw:                    0
Tx fails:                   998
 
Err flags: 0x00000000
Rx err:                       0
Tx err:                       0
Rx invalid:                   0
Wdg Resets:                   0
Wdg Timer:                    0 sec(s)
Err Resets:                   1
OVMS# can can2 status
CAN:       can2
Mode:      Active
Speed:     500000
DBC:       none
 
Interrupts:             8661395
Rx pkt:                 8672342
Rx ovrflw:                    0
Tx pkt:                      40
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:                    0 sec(s)
Err Resets:                   0
 
On the transmit side nearly all our activity is on can1. There have been a huge proportion of failures, but this is the only can1 error I can find in the log. 
 
2025-01-23 16:37:06.464 GMT E (31051994) esp32can: can1 stuck bus-off error state (errflags=0x00040c00) detected - resetting bus

It's quite possible there are others from earlier in the day, when I had debug level on. I've now set the level to warn so it should be easy to spot everything significant. I'll update when I have something to report.

Chris