On 2020-09-30 01:42, Chris van der Meijden wrote:
Oh boy ...
Found this one:
http://lists.openvehicles.com/pipermail/ovmsdev/2020-February/006640.html
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
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(): https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9de2... Craig -------- Forwarded Message -------- Subject: [Ovmsdev] Modem unable to power cycle successfully Date: Thu, 16 Apr 2020 10:40:20 +0800 From: Mark Webb-Johnson <mark@webb-johnson.net> Reply-To: OVMS Developers <ovmsdev@lists.openvehicles.com> To: OVMS Developers <ovmsdev@lists.openvehicles.com> 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. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/354 Regards, Mark.