[Ovmsdev] Another incident
Michael Balzer
dexter at expeedo.de
Sun Feb 9 20:37:19 HKT 2025
Michael,
Am 09.02.25 um 11:34 schrieb Michael Geddes:
> A dip/blip is designed simply to say something is going on. It's not
> saying that there's a condition of any sort.. so it's not a false
> alarm.. as it's not really anything.
Thanks for the clarification.
I misinterpreted the dip/blip events as detecting unexpected/irregular
pulse deviations, like the one here at 17:00:
But it's really just about detecting any significant sudden change.
In case there are others misinterpreting these (are there?), we can add
some clarification to the manual.
Regards,
Michael
>
> The low voltage level is different but not going on here.
>
>
> //.ichael
>
> On Sun, 9 Feb 2025, 17:24 Michael Balzer via OvmsDev,
> <ovmsdev at lists.openvehicles.com> wrote:
>
> I'd consider the "dips" logged here as false positives.
>
> Michael, correct me if I'm wrong: your new 12V monitor doesn't yet
> implement a calmdown phase after charging. The voltage decline
> after the DC converter switches off is logarithmic, so can easily
> trigger the "dip" detection in the beginning. That fits these log
> entries:
>
> 13:17:50.184 (vehicle.off) assumption: DCDC off
> 13:17:51.144 (vehicle.aux.12v.charging.dip) [12vmon] 12v > 14.0 &&
> < 0.09 under avg
> 13:17:53.144 (vehicle.aux.12v.dip) [12vmon] 12v <=
> 14.0 && < 0.25 under avg
> 13:17:56.754 (vehicle.locked)
> 13:18:09.144 (vehicle.charge.12v.stop) [leaf] 12v <= 12.8
> 13:18:33.174 (vehicle.aux.12v.normal)
> 13:19:59.174 (vehicle.asleep) [leaf] off since
> 120-130 seconds (awake stale)
>
> Generally I think all aux.12v log entries shortly after a
> vehicle.off should currently be ignored with regards to 12V
> diagnosis. (@Michael: check `m_12v_ticker` for my calmdown
> implementation for the reference voltage measurement)
>
> The same may apply to the start of a 12V charging phase, depending
> on the way the vehicle detects that state.
>
>
> IOW, Chris, you should look for "dip" log entries well within a
> parking / driving / charging phase, when the 12V level should be
> more or less constant.
>
> You should also have a look at the general 12V level behaviour,
> e.g. using the 12V chart plugin or creating a chart from the MQTT
> metric. The V2 Android App also has a 12V chart, if you use V2.
> When using V2/MQTT, consider raising the update interval to get a
> higher time resolution.
>
> Btw, also consider shortening the file logging sync period, 30
> seconds is rather high.
>
>
> On the 12V shutdown: even with 30 seconds log flushing, you would
> have seen the log entries for a shutdown condition, unless you
> configured the shutdown delay to 0 (default is 2 minutes).
>
> That is, if the 12V level wasn't suddenly getting drastically low,
> i.e. too low within seconds to keep the ESP32 in operation. That
> could explain the freeze. Not sure how low that would need to have
> been.
>
> I'd check for another potential source of such a sudden voltage
> drop: a mechanical/electrical issue with the OBD connector or cable.
>
> If for example there is a lose wire in the connection, that
> occasionally causes a short circuit, that would both explain the
> module freeze and the car fault.
>
>
> Regards,
> Michael
>
>
> Am 09.02.25 um 04:45 schrieb Michael Geddes via OvmsDev:
>> Just fyi a 'dip' is 12v voltage decreasing momentarily. A blip is
>> the reverse. Charging.dip is dipping while charging.
>>
>> There's a separate low voltage state for the 12v monitor.
>>
>> //.ichael
>>
>> On Sun, 9 Feb 2025, 06:35 Dan Edwards via OvmsDev,
>> <ovmsdev at lists.openvehicles.com> wrote:
>>
>> Hi Chris,
>>
>> Not sure if you’ve investigated the I-key system error , but
>> thought I’d add my experience here.
>> I have been receiving the same I-key system error in my 2012
>> leaf, with all the same symptoms and resolution as yours.
>> This leaf doesn’t have OVMS installed at the moment, so maybe
>> your issue is not due to OVMS.
>> If you google I-key system error , you’ll find posts on
>> issues with the BCM, which have been resolved with cleaning
>> contacts on bcm (if there’s been moisture issues), and others
>> replacing 12v acc battery.
>> I’m pretty sure I’ve narrowed it down to 12v battery issues
>> in my case, after inspecting BCM behind glove box in RHD
>> edition, finding no issue, recharging 12v, and removing any
>> known 12v drain like OVMS or odb dongle, just waiting for a
>> recurrence to confirm.
>> Check your DTCs with leafspy, if it shows a bunch of DTCs
>> including a B2604 BCM Shift PN diag, then likely low 12v, try
>> a 24 hr charge or replace it.
>> The OVMS log also shows 12v dip around the same time as your
>> issue. This may explain OVMS shutdown as well if you’ve got
>> it set to shut down due to low 12v battery, although I
>> though that might be more graceful.
>>
>> Cheers Dan
>>>
>>> On 9 Feb 2025, at 8:35 am, Chris Box via OvmsDev
>>> <ovmsdev at lists.openvehicles.com> wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>> It's happened again. Yesterday while driving the Leaf lost
>>> drive mode, forcing pulling over. I couldn't reengage gear
>>> until I had disconnected the 12v battery.
>>>
>>> Looking at the evidence today, the incident can't be
>>> explained by writing random bytes in CommandWakeup(), nor by
>>> having the wrong timing. It actually suggests that OVMS
>>> locked up ten minutes before the car was impacted.
>>>
>>> Here's what happened.
>>>
>>> 13:15 to 13:17 I drove off from home, but forgot an item so
>>> quickly returned back there.
>>>
>>> The sd log records this activity just fine, and the last
>>> entries before the suspected hang were these:
>>>
>>> 2025-02-07 13:19:59.174 GMT D (93751944) events:
>>> Signal(vehicle.asleep)
>>> 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping:
>>> 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560
>>> SPI=3262992-3285432)
>>>
>>> There should have been the next housekeeping message at
>>> 13:27:29 but none was recorded on the sd. Log flushes are
>>> configured to occur after 30 seconds.
>>>
>>> The last MQTT metric update my server received was around
>>> 13:27:50. This showed it was connected to home wifi.
>>>
>>> At 13:28 I unlocked the car, started it and drove off
>>> without noticing anything unusual. None of this activity
>>> appears in the log.
>>>
>>> During the drive there should have been a connection via
>>> Hologram to my server, but none was received.
>>>
>>> Ten minutes later at 13:38 I was driving when a yellow
>>> warning light came on and the car moved to neutral.
>>> Essentially the same symptoms as in January: turning off and
>>> on would not clear the fault; it couldn't detect brake
>>> status meaning it told me to press brake pedal when I
>>> already was. Also showed I-key system error.
>>>
>>> As I was stranded I used the only option I knew of to clear
>>> the fault, and I disconnected the 12v battery. On restoring
>>> power and dismissing the fault notice, it was happy to drive.
>>>
>>> The log shows this cold start SNTP was at 13:44. On
>>> returning home, unfortunately 'boot status' says nothing
>>> about a crash, presumably because any information was lost
>>> when I pulled power.
>>>
>>> So it seems there is some mechanism by which OVMS can lock
>>> up, without watchdog oversight. And that ten minutes later
>>> it can do something that becomes a critical issue for the
>>> car systems.
>>>
>>> Chris
>>>
>>> Relevant log entries below, all part of the same file. 1970
>>> follows immediately after 13:22:29.184.
>>>
>>> 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll:
>>> Pollers: Queue SetState()
>>> 2025-02-07 13:17:50.184 GMT D (93622984) vehicle-poll:
>>> Pollers: PollState(0)
>>> 2025-02-07 13:17:50.184 GMT D (93622984) events:
>>> Signal(vehicle.off)
>>> 2025-02-07 13:17:51.144 GMT D (93623944) events:
>>> Signal(vehicle.aux.12v.charging.dip)
>>> 2025-02-07 13:17:53.144 GMT D (93625944) events:
>>> Signal(vehicle.aux.12v.dip)
>>> 2025-02-07 13:17:54.824 GMT E (93627624) can: can2:
>>> intr=15711227 rxpkt=15730955 txpkt=100 errflags=0x22401c02
>>> rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0
>>> wdgreset=0 errreset=0 txqueue=0
>>> 2025-02-07 13:17:56.754 GMT D (93629554) events:
>>> Signal(vehicle.locked)
>>> 2025-02-07 13:17:59.744 GMT E (93632544) can: can2:
>>> intr=15716706 rxpkt=15736447 txpkt=100 errflags=0x23401c01
>>> rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0
>>> wdgreset=0 errreset=0 txqueue=0
>>> 2025-02-07 13:18:09.144 GMT D (93641944) events:
>>> Signal(vehicle.charge.12v.stop)
>>> 2025-02-07 13:18:10.144 GMT I (93642944) powermgmt: No
>>> longer charging 12V battery..
>>> 2025-02-07 13:18:33.174 GMT D (93665944) events:
>>> Signal(vehicle.aux.12v.normal)
>>> 2025-02-07 13:18:33.764 GMT E (93666534) can: can2:
>>> intr=15754521 rxpkt=15774368 txpkt=100 errflags=0x22401c02
>>> rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0
>>> wdgreset=0 errreset=0 txqueue=0
>>> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3:
>>> Connection is <redacted>
>>> 2025-02-07 13:18:45.174 GMT I (93677944) ovms-server-v3:
>>> Status: Connecting...
>>> 2025-02-07 13:18:45.224 GMT D (93677994) events:
>>> Signal(server.v3.connecting)
>>> 2025-02-07 13:18:48.624 GMT I (93681394) ovms-server-v3:
>>> Connection successful
>>> 2025-02-07 13:18:48.644 GMT I (93681414) ovms-server-v3:
>>> Status: OVMS V3 MQTT login successful
>>> 2025-02-07 13:18:48.644 GMT D (93681414) events:
>>> Signal(server.v3.connected)
>>> 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3:
>>> Subscribe to MQTT topics
>>> 2025-02-07 13:18:49.174 GMT I (93681944) ovms-server-v3:
>>> Transmit all metrics
>>> 2025-02-07 13:18:49.464 GMT I (93682234) ovms-server-v3:
>>> Subscription acknowledged
>>> 2025-02-07 13:19:59.174 GMT D (93751944) events:
>>> Signal(vehicle.asleep)
>>> 2025-02-07 13:22:29.184 GMT I (93901954) housekeeping:
>>> 2025-02-07 13:22:28 GMT (RAM: 8b=79028-81980 32b=12560
>>> SPI=3262992-3285432)
>>> 1970-01-01 00:00:08.424 GMT I (7994) command: OpenLogfile:
>>> now logging to file '/sd/logs/log'
>>> 1970-01-01 00:00:13.474 GMT D (13034) events:
>>> Signal(system.event)
>>> 1970-01-01 00:00:13.474 GMT D (13034) events:
>>> Signal(system.wifi.scan.done)
>>> 1970-01-01 00:00:19.424 GMT I (18984) cellular: State: Enter
>>> Identify state
>>> 1970-01-01 00:00:19.434 GMT I (18994) cellular: Identified
>>> cellular modem: SIM7600/Experimental support for SIMCOM SIM7600
>>> 1970-01-01 00:00:19.434 GMT I (18994) cellular: Set modem
>>> driver to 'SIM7600'
>>> 1970-01-01 00:00:19.434 GMT I (18994) cellular: State: Enter
>>> PoweredOn state
>>> 1970-01-01 00:00:19.424 GMT D (18994) events:
>>> Signal(system.modem.installed)
>>> 1970-01-01 00:00:19.434 GMT D (19004) events:
>>> Signal(system.modem.poweredon)
>>> 1970-01-01 00:00:23.474 GMT D (23034) events:
>>> Signal(system.event)
>>> 1970-01-01 00:00:23.474 GMT D (23034) events:
>>> Signal(system.wifi.scan.done)
>>> 1970-01-01 00:00:33.474 GMT D (33034) events:
>>> Signal(system.event)
>>> 1970-01-01 00:00:33.474 GMT D (33034) events:
>>> Signal(system.wifi.scan.done)
>>> 1970-01-01 00:00:39.434 GMT I (38994) cellular: State: Enter
>>> MuxStart state
>>> 1970-01-01 00:00:39.444 GMT I (39004) gsm-mux: Start MUX
>>> 1970-01-01 00:00:39.444 GMT D (39004) events:
>>> Signal(system.modem.muxstart)
>>> 1970-01-01 00:00:39.444 GMT I (39014) gsm-mux: Channel #0 is
>>> open
>>> 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #1 is
>>> open
>>> 1970-01-01 00:00:39.464 GMT I (39024) gsm-mux: Channel #2 is
>>> open
>>> 1970-01-01 00:00:39.474 GMT I (39034) gsm-mux: Channel #3 is
>>> open
>>> 1970-01-01 00:00:39.484 GMT I (39044) gsm-mux: Channel #4 is
>>> open
>>> 1970-01-01 00:00:40.414 GMT I (39984) cellular: State: Enter
>>> NetWait state
>>> 1970-01-01 00:00:40.414 GMT D (39984) events:
>>> Signal(system.modem.netwait)
>>> 1970-01-01 00:00:43.474 GMT D (43034) events:
>>> Signal(system.event)
>>> 1970-01-01 00:00:43.474 GMT D (43034) events:
>>> Signal(system.wifi.scan.done)
>>> 1970-01-01 00:00:46.054 GMT D (45624) events:
>>> Signal(vehicle.awake)
>>> 1970-01-01 00:00:50.444 GMT I (50014) cellular: Network
>>> Registration status: RegisteredRoaming
>>> 1970-01-01 00:00:51.414 GMT I (50984) cellular: State: Enter
>>> NetStart state
>>> 1970-01-01 00:00:51.434 GMT D (50994) events:
>>> Signal(vehicle.aux.12v.blip)
>>> 1970-01-01 00:00:51.434 GMT D (50994) events:
>>> Signal(system.modem.netstart)
>>> 1970-01-01 00:00:51.444 GMT D (51004) events:
>>> Signal(vehicle.charge.12v.start)
>>> 1970-01-01 00:00:51.434 GMT I (51004) cellular: Network
>>> Mode: LTE,Online
>>> 1970-01-01 00:00:52.414 GMT I (51984) powermgmt: Charging
>>> 12V battery..
>>> 1970-01-01 00:00:52.464 GMT I (52034) cellular: PPP
>>> Connection is ready to start
>>> 1970-01-01 00:00:53.424 GMT I (52984) cellular: State: Enter
>>> NetMode state
>>> 1970-01-01 00:00:53.424 GMT I (52984) gsm-ppp: Initialising...
>>> 1970-01-01 00:00:53.434 GMT D (52994) events:
>>> Signal(system.modem.netmode)
>>> 1970-01-01 00:00:53.484 GMT D (53044) events:
>>> Signal(system.event)
>>> 1970-01-01 00:00:53.484 GMT D (53044) events:
>>> Signal(system.wifi.scan.done)
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp:
>>> StatusCallBack: None
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: status_cb:
>>> Connected
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: our_ipaddr
>>> = 100.83.212.151
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: his_ipaddr
>>> = 10.64.64.64
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: netmask
>>> = 255.255.255.255
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp: DNS#0
>>> = 8.8.8.8
>>> 1970-01-01 00:00:53.584 GMT I (53154) gsm-ppp: DNS#1
>>> = 8.8.4.4
>>> 1970-01-01 00:00:53.594 GMT I (53154) gsm-ppp:
>>> our6_ipaddr = ::
>>> 1970-01-01 00:00:53.594 GMT D (53154) events:
>>> Signal(network.interface.up)
>>> 1970-01-01 00:00:53.604 GMT D (53164) events:
>>> Signal(system.modem.gotip)
>>> 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Interface
>>> priority is pp2 (100.83.212.151/255.255.255.255
>>> <http://100.83.212.151/255.255.255.255> gateway 10.64.64.64)
>>> 1970-01-01 00:00:53.604 GMT I (53164) netmanager: Set DNS#2
>>> 0.0.0.0
>>> 1970-01-01 00:00:53.594 GMT I (53164) netmanager: MODEM up
>>> (with WIFI client down): starting network with MODEM
>>> 1970-01-01 00:00:53.594 GMT D (53164) events:
>>> Signal(network.modem.up)
>>> 1970-01-01 00:00:53.594 GMT D (53164) events: Signal(network.up)
>>> 1970-01-01 00:00:53.604 GMT I (53174) time: Starting SNTP client
>>> 1970-01-01 00:00:53.604 GMT D (53174) events:
>>> Signal(network.interface.change)
>>> 1970-01-01 00:00:53.614 GMT D (53174) events:
>>> Signal(network.mgr.init)
>>> 1970-01-01 00:00:53.614 GMT I (53174) webserver: Launching
>>> Web Server
>>> 2025-02-07 13:44:08.584 GMT I (53184) webserver: Binding to
>>> port 80 (http)
>>> 2025-02-07 13:44:08.584 GMT I (53184) ssh: Launching SSH Server
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer *Am Rahmen 5 * D-58313 Herdecke <https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g>
> Fon 02330 9104094 * Handy 0176 20698926
>
> _______________________________________________
> 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/20250209/c66fc458/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl07Ij470f07vnpT.png
Type: image/png
Size: 36951 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250209/c66fc458/attachment-0001.png>
-------------- 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/20250209/c66fc458/attachment-0001.sig>
More information about the OvmsDev
mailing list