[Ovmsdev] OVMS Poller module/singleton

Wed Jan 29 03:12:45 HKT 2025

Chris,

>> The best option to capture anything going on with the bus over the 
>> night is activating an unfiltered can log to the SD card. 
> Do you mean setting the global log level to verbose?

No, I mean activating a CAN logger. You can simply start one on the 
monitor channel, which outputs the CAN log to the system log:

OVMS# log level verbose canlog-monitor
OVMS# can log start monitor crtd

For more info on CAN logging, see the user guide: 
https://docs.openvehicles.com/en/latest/crtd/can_logging.html

I've now added output of the TX queue fill level to the CAN status 
outputs, that should help identifying the effect. Hint: you can use "git 
pull --rebase --autostash" to merge this with your local changes.

On my UpMiiGo (which switches off the bus), the ESP32CAN most of the 
time recognizes an immediate failure for a TX with the vehicle being 
off. That means the TX buffer (in the controller) gets cleared 
immediately, with an immediate "TX_Fail" result for the frame. Ideally 
that would be the case always while the bus is off.

But the ESP32CAN controller sometimes tries to send the frame, waiting 
for an ack, repeating the transmission and then ending up in the frame 
being stuck in the TX buffer. Then the TX queue (software) gets filled 
with the status ping request frame from there, up to the 30 frames 
capacity of the TX queue, then counting TX overflows.

This continues until the ESP32CAN, due to unknown reasons, thinks it 
could send the frame. The TX queue then gets flushed immediately, with 
the frames appearing as being sent successfully (although there is no 
ECU active, the bus is still off).

After the queue has been cleared, this loop starts over.

So it may happen, that the TX queue gets filled, and the ESP32CAN thinks 
it can send frames, even while the bus is shut off.

Reading the Leaf code, I don't see any regular status ping polling, but 
it may still be, the Leaf queued some TX packets just before switching 
off the vehicle. Those would stick in the queue until the ESP32CAN 
enters the state described above, so actually tries to send the frames 
queued.

You should be able to determine if that's the case from the TX fill 
level being logged & displayed in the status output.

Regards,
Michael

Am 28.01.25 um 00:20 schrieb Chris Box:
>
> On 2025-01-27 21:50, Michael Balzer via OvmsDev wrote:
>
>>> 0x8048d9 was logged twice last night while parked and locked, with 
>>> nothing going on
>>
>> So please verify there really was nothing going on. Maybe you didn't 
>> see the vehicle was actually active due to reduced log levels or 
>> missing log entries in the leaf code?
> Logging to SD card was globally at info level, except with debug for 
> can, esp32can, mcp2515 & events. Here's all I saw:
>
> 2025-01-26 19:56:25.997 GMT I (92702057) housekeeping: 2025-01-26 
> 19:56:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285676)
> 2025-01-26 20:01:25.997 GMT I (93002057) housekeeping: 2025-01-26 
> 20:01:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285644)
> 2025-01-26 20:03:57.337 GMT E (93153387) can: can1: intr=4800273 
> rxpkt=4799065 txpkt=900 errflags=0x8048d9 rxerr=0 txerr=128 rxinval=0 
> rxovr=5 txovr=0 txdelay=51 txfail=281 wdgreset=0 errreset=0
> 2025-01-26 20:03:58.337 GMT E (93154387) can: can1: intr=4800319 
> rxpkt=4799065 txpkt=901 errflags=0x8048d9 rxerr=0 txerr=135 rxinval=0 
> rxovr=5 txovr=0 txdelay=51 txfail=282 wdgreset=0 errreset=0
> 2025-01-26 20:06:05.337 GMT E (93281387) can: can1: intr=4800334 
> rxpkt=4799065 txpkt=902 errflags=0x8048d9 rxerr=0 txerr=134 rxinval=0 
> rxovr=5 txovr=0 txdelay=51 txfail=289 wdgreset=0 errreset=0
> 2025-01-26 20:06:26.007 GMT I (93302057) housekeeping: 2025-01-26 
> 20:06:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285676)
> 2025-01-26 20:11:25.997 GMT I (93602057) housekeeping: 2025-01-26 
> 20:11:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285612)
>
> 2025-01-26 23:16:26.017 GMT I (104702057) housekeeping: 2025-01-26 
> 23:16:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285488)
> 2025-01-26 23:21:26.017 GMT I (105002057) housekeeping: 2025-01-26 
> 23:21:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285456)
> 2025-01-26 23:23:04.347 GMT E (105100387) can: can1: intr=4801533 
> rxpkt=4799065 txpkt=903 errflags=0x8048d9 rxerr=0 txerr=131 rxinval=0 
> rxovr=5 txovr=0 txdelay=51 txfail=888 wdgreset=0 errreset=0
> 2025-01-26 23:26:26.017 GMT I (105302057) housekeeping: 2025-01-26 
> 23:26:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285488)
> 2025-01-26 23:31:26.017 GMT I (105602057) housekeeping: 2025-01-26 
> 23:31:25 GMT (RAM: 8b=79720-82596 32b=12560 SPI=3263128-3285456)
>
>>
>> The best option to capture anything going on with the bus over the 
>> night is activating an unfiltered can log to the SD card.
> Do you mean setting the global log level to verbose?
>> The normal behaviour of a parked car is doing 12V battery maintenance 
>> every few hours, i.e. topping up the 12V battery from the main 
>> battery. That will normally also cause a limited CAN wakeup of the 
>> ECUs taking part in that process.
> With the MQTT metrics I observe charging of 12V ceased at 18:40. The 
> batterythen went into gradual decline starting at 12.8V until it 
> reached 12.4V the next morning.
>> Another option is some plugin or script doing a wakeup to query values.
> The only activity I have is an MQTT idle update interval of 10 
> minutes. Overnight this just sends things like free memory, 12V 
> voltage and signal strength.
>> As you don't see any issues yet, proceed with both buses active to 
>> see if the new timing solved that.
> Both buses now set to active.
>
> Thanks
> Chris

-- 
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/20250128/6cf2d748/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/20250128/6cf2d748/attachment.sig>