<html><head></head><body><div>Background on the PoweringOn issue for me was, that we yesterday had a complete internet breakdown in our village. A digger cut a fibreglas cable. 2000 people with no internet was the result ...</div><div><br></div><div>We still had DSL sync, but pppOE did not come through anymore.</div><div><br></div><div>I also have very poor (2G) connection with my OVMS sim at our house.</div><div><br></div><div>So I could think of a scenario like this:</div><div><br></div><div>The car thinks</div><div>- I am connected to wifi. Great, lets connect to the server.</div><div>- Hmmm, I can't reach the server. No DNS resolving.</div><div>- Lets try GSM</div><div>- Hmmm, no connection to my provider</div><div>- Lets try wifi again</div><div>- Hmmm, no resolving</div><div><br></div><div>And that for 14 hours, every few seconds ...</div><div><br></div><div>Well it is pure speculation, but perhaps of some help.</div><div><br></div><div>For now the system is completely broken. The system was down, I took it out of the car and broke the USB connector again ...</div><div><br></div><div>I'm taking a break now. Not really having fun at the moment ...</div><div><br></div><div>Chris</div><div><br></div><div><br></div><div>Am Mittwoch, den 30.09.2020, 10:45 -0700 schrieb Craig Leres:</div><blockquote type="cite"><pre>On 2020-09-30 01:42, Chris van der Meijden wrote:
<blockquote type="cite">
Oh boy ...
Found this one:
<a href="http://lists.openvehicles.com/pipermail/ovmsdev/2020-February/006640.html">http://lists.openvehicles.com/pipermail/ovmsdev/2020-February/006640.html</a>
You indeed have to pull the fuse for a minute and not only for two
seconds ...
Very strange, but hey it works now :-)
Network Registration: RegisteredHome Provider: o2 - de+ Signal: -97 dBm
State: NetStart
</blockquote>
I have not seen this issue since Mark made the change in April described
in the attached; he added a uart_flush() call to simcom::PowerCycle():
<a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9de2ecd94da64da6496a57acd0286e48f93dd250">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9de2ecd94da64da6496a57acd0286e48f93dd250</a>
Craig
-------- Forwarded Message --------
Subject: [Ovmsdev] Modem unable to power cycle successfully
Date: Thu, 16 Apr 2020 10:40:20 +0800
From: Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>
Reply-To: OVMS Developers <<a href="mailto:ovmsdev@lists.openvehicles.com">ovmsdev@lists.openvehicles.com</a>>
To: OVMS Developers <<a href="mailto:ovmsdev@lists.openvehicles.com">ovmsdev@lists.openvehicles.com</a>>
I’ve seen cases where the modem will not come up correctly, even
following a power cycle. But, a reset of the OVMS module (ESP32) solves
the problem. This really makes no sense, unless something is getting
corrupted inside the UART / EGPIO driver itself. The modem module status
is not changed during an ESP32 reset - only the software side of it
running in the ESP32.
Thomas Heder has reported some success with using uart_flush to flush
the UART ring buffer when power cycling the modem. Flushing the buffer
would not seem to affect this, as we use ‘AT’ to look for an OK response
during power up check anyway; but perhaps something is corrupt in the
ring buffer itself, so using uart_flush clears that problem.
Note that uart_flush is an alias for uart_flush_input, and the source
code does seem to show a complete reset of the ring buffer pointers with
interrupts disabled (not just a simple emptying).
Anyway, the approach does not seem to do any harm, so I have added it to
the latest code and let’s see if it improves the situation.
<a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/354">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/354</a>
Regards, Mark.
</pre></blockquote></body></html>