Hi folks, I left my module running with the modem connected (WiFi client off) for a couple of days. V2 server configured and connected, but the phone client was not running. The module was sitting on my desk (not in a car), powered from the high-power USB port on my laptop. It was blinking happily last night when I went to bed, but dark this morning. Apparently had crashed and rebooted during the night. Here's the trace-back from the screen. Looks like a link drop was the trigger, or perhaps the result of something else. Hope this helps, Greg I (129194054) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129194064) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129191,0,0,0,0,0,0,0,0,0,0 I (129795064) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129795074) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129792,0,0,0,0,0,0,0,0,0,0 I (130030624) simcom: CREG Network Registration: Searching I (130031414) simcom: Lost network connection (NetworkRegistration in NetMode) I (130031414) simcom: State: Enter NetLosGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x4018f959 PS : 0x00060830 A0 : 0x8018a5d8 A1 : 0x3ffd80f0 0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2) A2 : 0x0000f01d A3 : 0x00000000 A4 : 0x00000000 A5 : 0xfffffffc A6 : 0x3fff2c8c A7 : 0x00000014 A8 : 0x00000000 A9 : 0x00000001 A10 : 0x502b34ca A11 : 0x00000001 A12 : 0x3f42ea90 A13 : 0x3f42eaa4 A14 : 0x3ffda120 A15 : 0x00000000 SAR : 0x0000000b EXCCAUSE: 0x0000001c EXCVADDR: 0x0000f0d2 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff Backtrace: 0x4018f959:0x3ffd80f0 0x4018a5d5:0x3ffd8110 0x4018d3eb:0x3ffd8150 0x4018d40d:0x3ffd8180 0x4018d4ae:0x3ffd81a0 0x4018d90c:0x3ffd81c0 0x4018e46a:0x3ffd81e0 0x4018e4ab:0x3ffd8200 0x40196261:0x3ffd8220 0x4019882d:0x3ffd8240 0x40198874:0x3ffd8260 0x40199e9d:0x3ffd8280 0x40198764:0x3ffd82a0 0x4019a8f2:0x3ffd82c0 0x4019a92e:0x3ffd82e0 0x40196f25:0x3ffd8300 0x40199e9d:0x3ffd8320 0x40197e68:0x3ffd8340 0x40196149:0x3ffd8360 0x401b470c:0x3ffd8380 0x401825ad:0x3ffd83a0 0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2) 0x4018a5d5: tcp_rst at /home/greg/esp/esp-idf/components/lwip/core/tcp_out.c:1336 (discriminator 4) 0x4018d3eb: tcp_abandon at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630 0x4018d40d: tcp_abort at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630 0x4018d4ae: tcp_netif_ipv4_addr_changed_pcblist at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630 0x4018d90c: tcp_netif_ipv4_addr_changed at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1947 0x4018e46a: netif_set_ipaddr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:452 0x4018e4ab: netif_set_addr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:330 0x40196261: cifaddr at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704 0x4019882d: ipcp_clear_addrs at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2192 0x40198874: ipcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2156 0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146 0x40198764: ipcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:687 0x4019a8f2: upper_layers_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:715 0x4019a92e: link_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:701 0x40196f25: lcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:2341 0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146 0x40197e68: lcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:485 0x40196149: ppp_close at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704 0x401b470c: pppapi_do_ppp_close at /home/greg/esp/esp-idf/components/lwip/api/pppapi.c:355 0x401825ad: tcpip_thread at /home/greg/esp/esp-idf/components/lwip/api/tcpip.c:474 Rebooting...
I found this patch from Espressif: https://github.com/espressif/esp-idf/pull/1100/commits/6dd48547adbdaf89e43b6... <https://github.com/espressif/esp-idf/pull/1100/commits/6dd48547adbdaf89e43b680dc027e5aa786d9c0e> They had only applied it to ‘master’, and not the ‘2.1’ branch we use. It seems to resolve the problem. I also made some changes to the ovms_server_v2 to try to tear down the connection _before_ the ppp link goes down (but I now think these are unnecessary, although probably beneficial). Can you guys try updating both your ESP IDF (based on open vehicles 2.1 repo) and ovms v3 firmware. See if it is more reliable? I will leave mine running now, to see if there is any improvement for long-lived connections. Regards, Mark.
On 19 Dec 2017, at 5:14 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi folks,
I left my module running with the modem connected (WiFi client off) for a couple of days. V2 server configured and connected, but the phone client was not running. The module was sitting on my desk (not in a car), powered from the high-power USB port on my laptop. It was blinking happily last night when I went to bed, but dark this morning. Apparently had crashed and rebooted during the night.
Here's the trace-back from the screen. Looks like a link drop was the trigger, or perhaps the result of something else.
Hope this helps,
Greg
I (129194054) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129194064) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129191,0,0,0,0,0,0,0,0,0,0 I (129795064) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129795074) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129792,0,0,0,0,0,0,0,0,0,0 I (130030624) simcom: CREG Network Registration: Searching I (130031414) simcom: Lost network connection (NetworkRegistration in NetMode) I (130031414) simcom: State: Enter NetLosGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump:
PC : 0x4018f959 PS : 0x00060830 A0 : 0x8018a5d8 A1 : 0x3ffd80f0
0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2)
A2 : 0x0000f01d A3 : 0x00000000 A4 : 0x00000000 A5 : 0xfffffffc A6 : 0x3fff2c8c A7 : 0x00000014 A8 : 0x00000000 A9 : 0x00000001 A10 : 0x502b34ca A11 : 0x00000001 A12 : 0x3f42ea90 A13 : 0x3f42eaa4 A14 : 0x3ffda120 A15 : 0x00000000 SAR : 0x0000000b EXCCAUSE: 0x0000001c EXCVADDR: 0x0000f0d2 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
Backtrace: 0x4018f959:0x3ffd80f0 0x4018a5d5:0x3ffd8110 0x4018d3eb:0x3ffd8150 0x4018d40d:0x3ffd8180 0x4018d4ae:0x3ffd81a0 0x4018d90c:0x3ffd81c0 0x4018e46a:0x3ffd81e0 0x4018e4ab:0x3ffd8200 0x40196261:0x3ffd8220 0x4019882d:0x3ffd8240 0x40198874:0x3ffd8260 0x40199e9d:0x3ffd8280 0x40198764:0x3ffd82a0 0x4019a8f2:0x3ffd82c0 0x4019a92e:0x3ffd82e0 0x40196f25:0x3ffd8300 0x40199e9d:0x3ffd8320 0x40197e68:0x3ffd8340 0x40196149:0x3ffd8360 0x401b470c:0x3ffd8380 0x401825ad:0x3ffd83a0 0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2)
0x4018a5d5: tcp_rst at /home/greg/esp/esp-idf/components/lwip/core/tcp_out.c:1336 (discriminator 4)
0x4018d3eb: tcp_abandon at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630
0x4018d40d: tcp_abort at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630
0x4018d4ae: tcp_netif_ipv4_addr_changed_pcblist at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630
0x4018d90c: tcp_netif_ipv4_addr_changed at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1947
0x4018e46a: netif_set_ipaddr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:452
0x4018e4ab: netif_set_addr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:330
0x40196261: cifaddr at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704
0x4019882d: ipcp_clear_addrs at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2192
0x40198874: ipcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2156
0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146
0x40198764: ipcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:687
0x4019a8f2: upper_layers_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:715
0x4019a92e: link_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:701
0x40196f25: lcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:2341
0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146
0x40197e68: lcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:485
0x40196149: ppp_close at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704
0x401b470c: pppapi_do_ppp_close at /home/greg/esp/esp-idf/components/lwip/api/pppapi.c:355
0x401825ad: tcpip_thread at /home/greg/esp/esp-idf/components/lwip/api/tcpip.c:474
Rebooting...
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Simplest to just clone our version. You can setup ‘remotes’ to track both, but you would normally only need that if you were making changes to ours and trying to merge between the two. Regards, Mark
On 24 Dec 2017, at 3:20 PM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
Um, I'm still on the original ESP IDF 2.1 branch from Expresif from when I first got going, not our clone branch. When did they apply the patch (i.e. do I already have it)? I'm assuming not.
I'm heading out of town for a few days, so probably won't be able to switch branches until mid-late next week. Could you remind me how to switch IDF branches, for eggnog mitigation purposes? Do I need to remove the old ESP code and fetch / unpack the new, or is it a simple matter of a git command to a different github location? It was a while ago that I set this up.
Thanks, and Happy Holidays, all,
Greg
Mark Webb-Johnson wrote:
I found this patch from Espressif:
https://github.com/espressif/esp-idf/pull/1100/commits/6dd48547adbdaf89e43b6... <https://github.com/espressif/esp-idf/pull/1100/commits/6dd48547adbdaf89e43b680dc027e5aa786d9c0e>
They had only applied it to ‘master’, and not the ‘2.1’ branch we use. It seems to resolve the problem.
I also made some changes to the ovms_server_v2 to try to tear down the connection _before_ the ppp link goes down (but I now think these are unnecessary, although probably beneficial).
Can you guys try updating both your ESP IDF (based on open vehicles 2.1 repo) and ovms v3 firmware. See if it is more reliable? I will leave mine running now, to see if there is any improvement for long-lived connections.
Regards, Mark.
On 19 Dec 2017, at 5:14 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi folks,
I left my module running with the modem connected (WiFi client off) for a couple of days. V2 server configured and connected, but the phone client was not running. The module was sitting on my desk (not in a car), powered from the high-power USB port on my laptop. It was blinking happily last night when I went to bed, but dark this morning. Apparently had crashed and rebooted during the night.
Here's the trace-back from the screen. Looks like a link drop was the trigger, or perhaps the result of something else.
Hope this helps,
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Seems to work better for me now. Here is a real disconnection (from network side): D (3088634) SIMCOM rx: 50 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 45 44 PD: DISCONNECTED D (3088634) SIMCOM rx: 0d 0a d4 f9 f9 11 ff 2f 0d 0a 2b 50 50 50 44 3a ......./..+PPPD: D (3088634) gsm-mux: ProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, FCS=d4, LEN=29) D (3088634) gsm-mux: ChanProcessFrame(CHAN=3, ADDR=0d, CTRL=ff, LEN=26, IFP=3) D (3088634) simcom: rx line ch=3 len=19 : +PPPD: DISCONNECTED I (3088634) simcom: PPP Connection disconnected D (3088634) SIMCOM rx: 20 44 49 53 43 4f 4e 4e 45 43 54 45 44 0d 0a d9 DISCONNECTED... D (3088634) SIMCOM rx: f9 . D (3088634) gsm-mux: ProcessFrame(CHAN=4, ADDR=11, CTRL=ff, FCS=d9, LEN=29) D (3088634) gsm-mux: ChanProcessFrame(CHAN=4, ADDR=11, CTRL=ff, LEN=26, IFP=3) D (3088634) simcom: rx line ch=4 len=19 : +PPPD: DISCONNECTED I (3088634) simcom: PPP Connection disconnected E (3088644) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (3089474) simcom: Lost network connection (+PPP disconnect in NetMode) I (3089474) simcom: State: Enter NetLoss state D (3089474) SIMCOM tx: f9 0d ff 19 41 54 2b 43 47 41 54 54 3d 30 0d 0a ....AT+CGATT=0.. D (3089474) SIMCOM tx: 14 f9 .. I (3089474) gsm-ppp: Shutting down (hard)... I (3089474) ovms-server-v2: Network is down, so disconnect network connection D (3090734) SIMCOM rx: f9 0d ff 0d 0d 0a 4f 4b 0d 0a 0f f9 ......OK.... D (3091614) SIMCOM rx: f9 09 ff 25 7e ff 7d 23 c0 21 7d 25 7d 29 7d 20 ...%~.}#.!}%})} D (3091614) SIMCOM rx: 7d 24 ff 7d 21 7e fb f9 }$.}!~.. I (3094604) gsm-ppp: StatusCallBack: User Interrupt I (3094604) gsm-ppp: PPP connection has been closed D (3094624) SIMCOM rx: f9 09 ff 1d 0d 0a 4e 4f 20 43 41 52 52 49 45 52 ......NO CARRIER D (3094624) SIMCOM rx: 0d 0a d1 f9 f9 0d ff 1d 0d 0a 4e 4f 20 43 41 52 ..........NO CAR D (3094624) SIMCOM rx: 52 49 45 52 0d 0a 13 f9 f9 11 ff 1d 0d 0a 4e 4f RIER..........NO D (3094624) SIMCOM rx: 20 43 41 52 52 49 45 52 0d 0a 1e f9 f9 09 ff 2f CARRIER......./ D (3094624) SIMCOM rx: 0d 0a 2b 50 50 50 44 3a 20 44 49 53 43 4f 4e 4e ..+PPPD: DISCONN D (3094624) SIMCOM rx: 45 43 54 45 44 0d 0a 16 f9 f9 0d ff 2f 0d 0a 2b ECTED......./..+ D (3094624) SIMCOM rx: 50 50 50 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 PPPD: DISCONNECT D (3094624) SIMCOM rx: 45 44 0d 0a d4 f9 f9 11 ff 2f 0d 0a 2b 50 50 50 ED......./..+PPP D (3094624) SIMCOM rx: 44 3a 20 44 49 53 43 4f 4e 4e 45 43 54 45 44 0d D: DISCONNECTED. D (3094624) SIMCOM rx: 0a d9 f9 ... I (3098474) simcom: State timeout, transition to 5 I (3098474) simcom: State: Enter NetWait state D (3098474) gsm-nmea: GPS disabled I (3098644) ovms-server-v2: Status: Waiting for network connectivity I (3102474) simcom: State: Enter NetStart state It tried to reconnect a few times, failing each time. Then, after a couple of minutes, the connection succeeded. Regards, Mark
On 24 Dec 2017, at 2:53 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I found this patch from Espressif:
https://github.com/espressif/esp-idf/pull/1100/commits/6dd48547adbdaf89e43b6... <https://github.com/espressif/esp-idf/pull/1100/commits/6dd48547adbdaf89e43b680dc027e5aa786d9c0e>
They had only applied it to ‘master’, and not the ‘2.1’ branch we use. It seems to resolve the problem.
I also made some changes to the ovms_server_v2 to try to tear down the connection _before_ the ppp link goes down (but I now think these are unnecessary, although probably beneficial).
Can you guys try updating both your ESP IDF (based on open vehicles 2.1 repo) and ovms v3 firmware. See if it is more reliable? I will leave mine running now, to see if there is any improvement for long-lived connections.
Regards, Mark.
On 19 Dec 2017, at 5:14 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi folks,
I left my module running with the modem connected (WiFi client off) for a couple of days. V2 server configured and connected, but the phone client was not running. The module was sitting on my desk (not in a car), powered from the high-power USB port on my laptop. It was blinking happily last night when I went to bed, but dark this morning. Apparently had crashed and rebooted during the night.
Here's the trace-back from the screen. Looks like a link drop was the trigger, or perhaps the result of something else.
Hope this helps,
Greg
I (129194054) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129194064) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129191,0,0,0,0,0,0,0,0,0,0 I (129795064) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129795074) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129792,0,0,0,0,0,0,0,0,0,0 I (130030624) simcom: CREG Network Registration: Searching I (130031414) simcom: Lost network connection (NetworkRegistration in NetMode) I (130031414) simcom: State: Enter NetLosGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump:
PC : 0x4018f959 PS : 0x00060830 A0 : 0x8018a5d8 A1 : 0x3ffd80f0
0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2)
A2 : 0x0000f01d A3 : 0x00000000 A4 : 0x00000000 A5 : 0xfffffffc A6 : 0x3fff2c8c A7 : 0x00000014 A8 : 0x00000000 A9 : 0x00000001 A10 : 0x502b34ca A11 : 0x00000001 A12 : 0x3f42ea90 A13 : 0x3f42eaa4 A14 : 0x3ffda120 A15 : 0x00000000 SAR : 0x0000000b EXCCAUSE: 0x0000001c EXCVADDR: 0x0000f0d2 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
Backtrace: 0x4018f959:0x3ffd80f0 0x4018a5d5:0x3ffd8110 0x4018d3eb:0x3ffd8150 0x4018d40d:0x3ffd8180 0x4018d4ae:0x3ffd81a0 0x4018d90c:0x3ffd81c0 0x4018e46a:0x3ffd81e0 0x4018e4ab:0x3ffd8200 0x40196261:0x3ffd8220 0x4019882d:0x3ffd8240 0x40198874:0x3ffd8260 0x40199e9d:0x3ffd8280 0x40198764:0x3ffd82a0 0x4019a8f2:0x3ffd82c0 0x4019a92e:0x3ffd82e0 0x40196f25:0x3ffd8300 0x40199e9d:0x3ffd8320 0x40197e68:0x3ffd8340 0x40196149:0x3ffd8360 0x401b470c:0x3ffd8380 0x401825ad:0x3ffd83a0 0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2)
0x4018a5d5: tcp_rst at /home/greg/esp/esp-idf/components/lwip/core/tcp_out.c:1336 (discriminator 4)
0x4018d3eb: tcp_abandon at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630
0x4018d40d: tcp_abort at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630
0x4018d4ae: tcp_netif_ipv4_addr_changed_pcblist at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630
0x4018d90c: tcp_netif_ipv4_addr_changed at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1947
0x4018e46a: netif_set_ipaddr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:452
0x4018e4ab: netif_set_addr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:330
0x40196261: cifaddr at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704
0x4019882d: ipcp_clear_addrs at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2192
0x40198874: ipcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2156
0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146
0x40198764: ipcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:687
0x4019a8f2: upper_layers_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:715
0x4019a92e: link_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:701
0x40196f25: lcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:2341
0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146
0x40197e68: lcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:485
0x40196149: ppp_close at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704
0x401b470c: pppapi_do_ppp_close at /home/greg/esp/esp-idf/components/lwip/api/pppapi.c:355
0x401825ad: tcpip_thread at /home/greg/esp/esp-idf/components/lwip/api/tcpip.c:474
Rebooting...
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 24/12/17 19:53, Mark Webb-Johnson wrote:
Can you guys try updating both your ESP IDF (based on open vehicles 2.1 repo) and ovms v3 firmware. See if it is more reliable? I will leave mine running now, to see if there is any improvement for long-lived connections.
I updated and went for a drive on GSM. The v2 server reported telemetry for 10 minutes and then it stopping talking. I don't know why it stopped. I've now got it on my desk connected to my laptop and it's been working for 20 minutes. I've just unplugged the antenna so we'll see how well it works (signal is strong here so it remains connected, but hopefully this simulates changing cell towers or something). I've also found that you can connect with a terminal emulator at 155200 baud and it doesn't reset the ovms (make monitor does reset it) so hopefully next time it stops communicating while driving I'll be able to see what is wrong.
115200 baud (typo?). Also, you may need to use control-J for the "Enter" key when typing commands. I have a Raspberry Pi that I can put in the car as a monitor, using Putty for the terminal. Will try the new IDE when I get back home. Greg p.s. Why does 'make monitor' reset the module? Seems to do that about half the time for me... On December 25, 2017 1:40:30 AM PST, Tom Parker <tom@carrott.org> wrote:
I've also found that you can connect with a terminal emulator at 155200
baud and it doesn't reset the ovms (make monitor does reset it) so hopefully next time it stops communicating while driving I'll be able to see what is wrong.
-- Sent from my Android device with K-9 Mail. Just so you know...
Greg, It is a feature of idf_monitor that it can reset the device using the RTS line. I thought I read somewhere that this could be disabled, but I didn't find that in the documentation just now. They did mention an alternative "make simple_monitor" to run an earlier version. Maybe it does not do the reset. Regarding the need to type Ctrl-J rather than the Enter key, we could make ConsoleAsync translate \r to \n as ConsoleTelnet and ConsoleSSH do. -- Steve On Mon, 25 Dec 2017, Greg D. wrote:
115200 baud (typo?). Also, you may need to use control-J for the "Enter" key when typing commands. I have a Raspberry Pi that I can put in the car as a monitor, using Putty for the terminal.
Will try the new IDE when I get back home.
Greg
p.s. Why does 'make monitor' reset the module? Seems to do that about half the time for me...
On December 25, 2017 1:40:30 AM PST, Tom Parker <tom@carrott.org> wrote:
I've also found that you can connect with a terminal emulator at 155200
baud and it doesn't reset the ovms (make monitor does reset it) so hopefully next time it stops communicating while driving I'll be able to see what is wrong.
-- Sent from my Android device with K-9 Mail. Just so you know... _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thanks, Steve. I can give the simple monitor a try later this week. But, why would the reset not be consistent? Seems like it's more like a mood it gets into, where make monitor always resets, then it will not reset for a few times, then go back to resets. No pattern that I can discern. Greg On Mon, Dec 25, 2017 at 11:39 AM, Stephen Casner <casner@acm.org> wrote:
Greg,
It is a feature of idf_monitor that it can reset the device using the RTS line. I thought I read somewhere that this could be disabled, but I didn't find that in the documentation just now. They did mention an alternative "make simple_monitor" to run an earlier version. Maybe it does not do the reset.
Regarding the need to type Ctrl-J rather than the Enter key, we could make ConsoleAsync translate \r to \n as ConsoleTelnet and ConsoleSSH do.
-- Steve
On Mon, 25 Dec 2017, Greg D. wrote:
115200 baud (typo?). Also, you may need to use control-J for the "Enter" key when typing commands. I have a Raspberry Pi that I can put in the car as a monitor, using Putty for the terminal.
Will try the new IDE when I get back home.
Greg
p.s. Why does 'make monitor' reset the module? Seems to do that about half the time for me...
On December 25, 2017 1:40:30 AM PST, Tom Parker <tom@carrott.org> wrote:
I've also found that you can connect with a terminal emulator at 155200
baud and it doesn't reset the ovms (make monitor does reset it) so hopefully next time it stops communicating while driving I'll be able to see what is wrong.
-- Sent from my Android device with K-9 Mail. Just so you know... _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Seems much better for me now. 36+ hours connected. One network disconnection and reconnected automatically: I (66104434) ovms-server-v2: Send MP-0 S100,K,0,0,done,standard,200,160,0,0,0,0,13,4,0,0,0,0,160.00,0,0,0,0,-1,0,0,0,0,0,400,0,0.00,400.00,100 I (66104444) ovms-server-v2: Send MP-0 D0,0,5,22,30,25,0,1000000,0,66101,22,0,0,0,1.01099,0,0,0,22,0 I (66618624) simcom: CREG Network Registration: Searching I (66619474) simcom: Lost network connection (NetworkRegistration in NetMode) I (66619474) simcom: State: Enter NetLoss state I (66619474) gsm-ppp: Shutting down (hard)... I (66619474) ovms-server-v2: Network is down, so disconnect network connection E (66619474) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (66619474) gsm-ppp: StatusCallBack: User Interrupt I (66619474) gsm-ppp: PPP connection has been closed I (66628474) simcom: State timeout, transition to 5 I (66628474) simcom: State: Enter NetWait state I (66629474) ovms-server-v2: Status: Waiting for network connectivity I (66638504) simcom: CREG Network Registration: RegisteredRoaming I (66639474) simcom: State: Enter NetStart state I (66640524) simcom: PPP Connection is ready to start I (66641474) simcom: State: Enter NetMode state I (66641474) gsm-ppp: Initialising... I (66647124) gsm-ppp: StatusCallBack: None I (66647124) gsm-ppp: status_cb: Connected I (66647124) gsm-ppp: our_ipaddr = 10.170.204.16 I (66647124) gsm-ppp: his_ipaddr = 10.64.64.64 I (66647124) gsm-ppp: netmask = 255.255.255.255 I (66647124) gsm-ppp: our6_ipaddr = :: I (66649474) ovms-server-v2: Status: Network connectivity established I think we will still probably need an PPP overall connection attempt counter. If PPP can’t be brought up N times, then power cycle the modem and start from scratch. The SIMCOM SIM908/808 modems certainly seemed to require that to be able to recover 100% of the time. Regards, Mark.
On 25 Dec 2017, at 5:40 PM, Tom Parker <tom@carrott.org> wrote:
On 24/12/17 19:53, Mark Webb-Johnson wrote:
Can you guys try updating both your ESP IDF (based on open vehicles 2.1 repo) and ovms v3 firmware. See if it is more reliable? I will leave mine running now, to see if there is any improvement for long-lived connections.
I updated and went for a drive on GSM. The v2 server reported telemetry for 10 minutes and then it stopping talking. I don't know why it stopped.
I've now got it on my desk connected to my laptop and it's been working for 20 minutes. I've just unplugged the antenna so we'll see how well it works (signal is strong here so it remains connected, but hopefully this simulates changing cell towers or something).
I've also found that you can connect with a terminal emulator at 155200 baud and it doesn't reset the ovms (make monitor does reset it) so hopefully next time it stops communicating while driving I'll be able to see what is wrong. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 25/12/17 22:40, Tom Parker wrote:
I've now got it on my desk connected to my laptop and it's been working for 20 minutes. I've just unplugged the antenna so we'll see how well it works (signal is strong here so it remains connected, but hopefully this simulates changing cell towers or something).
It worked all night on my desk with the antenna unplugged but when I took it for a drive (with the antenna plugged in) it disconnected after some time and didn't reconnect. It's now sitting on my driveway in this state. I was able to connect with a terminal emulator but I wasn't able to send commands to it. Do you need local echo? I'm fairly sure I tried ctrl-j to get a carriage return. I also tried minicom's add CR function. I'm only seeing the following in a loop. I'm fairly sure it was using a different mobile provider when I left the house, and the trip did involve going to an area of low or no signal (my cell phone didn't work inside the house we visited but did outside). Could the problem be caused by roaming from one provider to another? I can get a sim card for one of the local providers so I'm not using hologram and potentially roaming between networks if that helps to pin it down. Is it possible to write the logs to an SD card, or do I need to have my laptop connected to catch the actual disconnection event? OVMS > D (19122826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (19122826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (19122826) SIMCOM tx: 0a cf f9 ... D (19122836) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (19122836) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d +CSQ;+COPS?. D (19122846) SIMCOM rx: 0d 0a 2b 43 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a ..+CREG: 0,5.... D (19122846) SIMCOM rx: 2b 43 43 4c 4b 3a 20 22 31 37 2f 31 32 2f 32 36 +CCLK: "17/12/26 D (19122846) SIMCOM rx: 2c 32 30 3a 30 30 3a 32 39 2b 35 32 22 0d 0a 0d ,20:00:29+52"... D (19122846) SIMCOM rx: 0a 2b 43 53 51 3a 20 36 2c 39 39 0d 0a 0d 0a 2b .+CSQ: 6,99....+ D (19122846) SIMCOM rx: 43 4f 50 53 3a 20 30 2c 30 2c 22 56 6f 64 61 66 COPS: 0,0,"Vodaf D (19122846) SIMCOM rx: 6f 6e 65 4e 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c oneNZ Hologram", D (19122846) SIMCOM rx: 32 0d 0a 0d 0a 4f 4b 0d 0a 2....OK.. OVMS > D (19132826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (19132826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (19132826) SIMCOM tx: 0a cf f9 ... D (19132856) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (19132856) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d +CSQ;+COPS?. D (19132906) SIMCOM rx: 0d 0a 2b 43 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a ..+CREG: 0,5.... D (19132906) SIMCOM rx: 2b 43 43 4c 4b 3a 20 22 31 37 2f 31 32 2f 32 36 +CCLK: "17/12/26 D (19132916) SIMCOM rx: 2c 32 30 3a 30 30 3a 33 39 2b 35 32 22 0d 0a 0d ,20:00:39+52"... D (19132916) SIMCOM rx: 0a 2b 43 53 51 3a 20 36 2c 39 39 0d 0a 0d 0a 2b .+CSQ: 6,99....+ D (19132916) SIMCOM rx: 43 4f 50 53 3a 20 30 2c 30 2c 22 56 6f 64 61 66 COPS: 0,0,"Vodaf D (19132916) SIMCOM rx: 6f 6e 65 4e 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c oneNZ Hologram", D (19132916) SIMCOM rx: 32 0d 0a 0d 0a 4f 4b 0d 0a 2....OK.. OVMS > D (19142826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC
Tom, you need some tweaking in the character map (CR/LF). I've attached my minicom ovms configuration. Unzip in home, then start minicom like this: minicom -R utf-8 -C ovms.log -D /dev/ttyUSB0 ovms Regards, Michael Am 26.12.2017 um 09:16 schrieb Tom Parker:
I was able to connect with a terminal emulator but I wasn't able to send commands to it. Do you need local echo? I'm fairly sure I tried ctrl-j to get a carriage return. I also tried minicom's add CR function.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 26/12/17 22:52, Michael Balzer wrote:
you need some tweaking in the character map (CR/LF). I've attached my minicom ovms configuration. Unzip in home, then start minicom like this:
minicom -R utf-8 -C ovms.log -D /dev/ttyUSB0 ovms
It still wouldn't respond with this configuration, but after I turned off hardware flow control it worked perfectly. Thanks.
Log doesn’t show much. Modem has a network connection to VodafoneNZ, and signal strength seems ok. The following output will help: simcom status Plus output of ‘level debug’ for a minute or two. If still no network connection, try: simcom setstate NetLoss And show output at level debug for another minute or so. Regards, Mark.
On 26 Dec 2017, at 4:16 PM, Tom Parker <tom@carrott.org> wrote:
On 25/12/17 22:40, Tom Parker wrote:
I've now got it on my desk connected to my laptop and it's been working for 20 minutes. I've just unplugged the antenna so we'll see how well it works (signal is strong here so it remains connected, but hopefully this simulates changing cell towers or something).
It worked all night on my desk with the antenna unplugged but when I took it for a drive (with the antenna plugged in) it disconnected after some time and didn't reconnect. It's now sitting on my driveway in this state. I was able to connect with a terminal emulator but I wasn't able to send commands to it. Do you need local echo? I'm fairly sure I tried ctrl-j to get a carriage return. I also tried minicom's add CR function.
I'm only seeing the following in a loop. I'm fairly sure it was using a different mobile provider when I left the house, and the trip did involve going to an area of low or no signal (my cell phone didn't work inside the house we visited but did outside). Could the problem be caused by roaming from one provider to another? I can get a sim card for one of the local providers so I'm not using hologram and potentially roaming between networks if that helps to pin it down.
Is it possible to write the logs to an SD card, or do I need to have my laptop connected to catch the actual disconnection event?
OVMS > D (19122826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (19122826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (19122826) SIMCOM tx: 0a cf f9 ... D (19122836) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (19122836) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d +CSQ;+COPS?. D (19122846) SIMCOM rx: 0d 0a 2b 43 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a ..+CREG: 0,5.... D (19122846) SIMCOM rx: 2b 43 43 4c 4b 3a 20 22 31 37 2f 31 32 2f 32 36 +CCLK: "17/12/26 D (19122846) SIMCOM rx: 2c 32 30 3a 30 30 3a 32 39 2b 35 32 22 0d 0a 0d ,20:00:29+52"... D (19122846) SIMCOM rx: 0a 2b 43 53 51 3a 20 36 2c 39 39 0d 0a 0d 0a 2b .+CSQ: 6,99....+ D (19122846) SIMCOM rx: 43 4f 50 53 3a 20 30 2c 30 2c 22 56 6f 64 61 66 COPS: 0,0,"Vodaf D (19122846) SIMCOM rx: 6f 6e 65 4e 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c oneNZ Hologram", D (19122846) SIMCOM rx: 32 0d 0a 0d 0a 4f 4b 0d 0a 2....OK.. OVMS > D (19132826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (19132826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (19132826) SIMCOM tx: 0a cf f9 ... D (19132856) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (19132856) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d +CSQ;+COPS?. D (19132906) SIMCOM rx: 0d 0a 2b 43 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a ..+CREG: 0,5.... D (19132906) SIMCOM rx: 2b 43 43 4c 4b 3a 20 22 31 37 2f 31 32 2f 32 36 +CCLK: "17/12/26 D (19132916) SIMCOM rx: 2c 32 30 3a 30 30 3a 33 39 2b 35 32 22 0d 0a 0d ,20:00:39+52"... D (19132916) SIMCOM rx: 0a 2b 43 53 51 3a 20 36 2c 39 39 0d 0a 0d 0a 2b .+CSQ: 6,99....+ D (19132916) SIMCOM rx: 43 4f 50 53 3a 20 30 2c 30 2c 22 56 6f 64 61 66 COPS: 0,0,"Vodaf D (19132916) SIMCOM rx: 6f 6e 65 4e 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c oneNZ Hologram", D (19132916) SIMCOM rx: 32 0d 0a 0d 0a 4f 4b 0d 0a 2....OK.. OVMS > D (19142826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 27/12/17 01:34, Mark Webb-Johnson wrote:
Log doesn’t show much. Modem has a network connection to VodafoneNZ, and signal strength seems ok.
There is nothing else in the log, I'm running with level debug and it's just that on repeat.
The following output will help:
simcom status
OVMS > simcom status SIMCOM Network Registration: Searching State: NetWait Ticker: 57960 User Data: 0 Mux Open Channels: 4 PPP Not Connected PPP Last Error: User Interrupt GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected
simcom setstate NetLoss
OVMS > simcom setstate NetLoss OVMS > OVMS > OVMS > I (58142726) simcom: State: Enter NetLoss state D (58142726) SIMCOM tx: f9 0d ff 19 41 54 2b 43 47 41 54 54 3d 30 0d 0a ....AT+CGATT=0.. D (58142726) SIMCOM tx: 14 f9 .. I (58142726) gsm-ppp: Shutting down (hard)... I (58142736) gsm-ppp: StatusCallBack: User Interrupt I (58142736) gsm-ppp: PPP connection has been closed D (58142736) SIMCOM rx: 41 54 2b 43 47 41 54 54 3d 30 0d AT+CGATT=0. OVMS > D (58143956) SIMCOM rx: 0d 0a 4f 4b 0d 0a ..OK.. OVMS > I (58151826) simcom: State timeout, transition to 5 I (58151826) simcom: State: Enter NetWait state D (58151826) gsm-nmea: GPS disabled OVMS > D (58161826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (58161826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (58161826) SIMCOM tx: 0a cf f9 ... D (58161846) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (58161846) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d +CSQ;+COPS?. D (58161896) SIMCOM rx: 0d 0a 2b 43 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a ..+CREG: 0,5.... D (58161896) SIMCOM rx: 2b 43 43 4c 4b 3a 20 22 31 37 2f 31 32 2f 32 37 +CCLK: "17/12/27 D (58161896) SIMCOM rx: 2c 30 36 3a 35 31 3a 30 38 2b 35 32 22 0d 0a 0d ,06:51:08+52"... D (58161906) SIMCOM rx: 0a 2b 43 53 51 3a 20 39 2c 39 39 0d 0a 0d 0a 2b .+CSQ: 9,99....+ D (58161906) SIMCOM rx: 43 4f 50 53 3a 20 30 2c 30 2c 22 56 6f 64 61 66 COPS: 0,0,"Vodaf D (58161906) SIMCOM rx: 6f 6e 65 4e 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c oneNZ Hologram", D (58161906) SIMCOM rx: 32 0d 0a 0d 0a 4f 4b 0d 0a 2....OK.. The AT+CREG?; status things then continue in a loop and I did another simcom status which looks pretty similar to before: OVMS > simcom status SIMCOM Network Registration: Searching State: NetWait Ticker: 155 User Data: 0 Mux Open Channels: 4 PPP Not Connected PPP Last Error: User Interrupt GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected
And show output at level debug for another minute or so.
A full transcript of my session is attached. The ovms is still in this state so I can collect more information or perform more experiments.
Weird. Looks like the MUX has failed… D (58042826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (58042826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (58042826) SIMCOM tx: 0a cf f9 ... D (58042836) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (58042846) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d 0d 0a 2b 43 +CSQ;+COPS?...+C D (58042846) SIMCOM rx: 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a 2b 43 43 4c REG: 0,5....+CCL D (58042846) SIMCOM rx: 4b 3a 20 22 31 37 2f 31 32 2f 32 37 2c 30 36 3a K: "17/12/27,06: D (58042846) SIMCOM rx: 34 39 3a 30 39 2b 35 32 22 0d 0a 0d 0a 2b 43 53 49:09+52"....+CS D (58042846) SIMCOM rx: 51 3a 20 39 2c 39 39 0d 0a 0d 0a 2b 43 4f 50 53 Q: 9,99....+COPS D (58042846) SIMCOM rx: 3a 20 30 2c 30 2c 22 56 6f 64 61 66 6f 6e 65 4e : 0,0,"VodafoneN D (58042846) SIMCOM rx: 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c 32 0d 0a 0d Z Hologram",2... D (58042846) SIMCOM rx: 0a 4f 4b 0d 0a .OK.. OVMS > simcom status SIMCOM Network Registration: Searching State: NetWait Ticker: 57947 User Data: 0 Mux Open Channels: 4 PPP Not Connected PPP Last Error: User Interrupt GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected The tx f9 0d ff 3b … cf f9 is a mux transmission. The rx shows that being echoed back along with the CREG 0,5 (which is a roaming connected) but no ‘line’ decode output, and the ‘simcom status’ showing CREG ‘Searching’. Most likely the modem reset itself at some point (without the ESP32 system resetting). Could be a faulty modem, or power issue. Whichever; we should catch the problem and respond appropriately. I’ll add some framing error counters to the mux code, and check those counters in the main simcom state1 handler to reset things if they exceed a threshold. Regards, Mark.
On 27 Dec 2017, at 2:04 AM, Tom Parker <tom@carrott.org> wrote:
On 27/12/17 01:34, Mark Webb-Johnson wrote:
Log doesn’t show much. Modem has a network connection to VodafoneNZ, and signal strength seems ok.
There is nothing else in the log, I'm running with level debug and it's just that on repeat.
The following output will help:
simcom status
OVMS > simcom status SIMCOM Network Registration: Searching State: NetWait Ticker: 57960 User Data: 0 Mux Open Channels: 4 PPP Not Connected PPP Last Error: User Interrupt GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected
simcom setstate NetLoss
OVMS > simcom setstate NetLoss OVMS > OVMS > OVMS > I (58142726) simcom: State: Enter NetLoss state D (58142726) SIMCOM tx: f9 0d ff 19 41 54 2b 43 47 41 54 54 3d 30 0d 0a ....AT+CGATT=0.. D (58142726) SIMCOM tx: 14 f9 .. I (58142726) gsm-ppp: Shutting down (hard)... I (58142736) gsm-ppp: StatusCallBack: User Interrupt I (58142736) gsm-ppp: PPP connection has been closed D (58142736) SIMCOM rx: 41 54 2b 43 47 41 54 54 3d 30 0d AT+CGATT=0. OVMS > D (58143956) SIMCOM rx: 0d 0a 4f 4b 0d 0a ..OK.. OVMS > I (58151826) simcom: State timeout, transition to 5 I (58151826) simcom: State: Enter NetWait state D (58151826) gsm-nmea: GPS disabled OVMS > D (58161826) SIMCOM tx: f9 0d ff 3b 41 54 2b 43 52 45 47 3f 3b 2b 43 43 ...;AT+CREG?;+CC D (58161826) SIMCOM tx: 4c 4b 3f 3b 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d LK?;+CSQ;+COPS?. D (58161826) SIMCOM tx: 0a cf f9 ... D (58161846) SIMCOM rx: 41 54 2b 43 52 45 47 3f 3b 2b 43 43 4c 4b 3f 3b AT+CREG?;+CCLK?; D (58161846) SIMCOM rx: 2b 43 53 51 3b 2b 43 4f 50 53 3f 0d +CSQ;+COPS?. D (58161896) SIMCOM rx: 0d 0a 2b 43 52 45 47 3a 20 30 2c 35 0d 0a 0d 0a ..+CREG: 0,5.... D (58161896) SIMCOM rx: 2b 43 43 4c 4b 3a 20 22 31 37 2f 31 32 2f 32 37 +CCLK: "17/12/27 D (58161896) SIMCOM rx: 2c 30 36 3a 35 31 3a 30 38 2b 35 32 22 0d 0a 0d ,06:51:08+52"... D (58161906) SIMCOM rx: 0a 2b 43 53 51 3a 20 39 2c 39 39 0d 0a 0d 0a 2b .+CSQ: 9,99....+ D (58161906) SIMCOM rx: 43 4f 50 53 3a 20 30 2c 30 2c 22 56 6f 64 61 66 COPS: 0,0,"Vodaf D (58161906) SIMCOM rx: 6f 6e 65 4e 5a 20 48 6f 6c 6f 67 72 61 6d 22 2c oneNZ Hologram", D (58161906) SIMCOM rx: 32 0d 0a 0d 0a 4f 4b 0d 0a 2....OK..
The AT+CREG?; status things then continue in a loop and I did another simcom status which looks pretty similar to before:
OVMS > simcom status SIMCOM Network Registration: Searching State: NetWait Ticker: 155 User Data: 0 Mux Open Channels: 4 PPP Not Connected PPP Last Error: User Interrupt GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected
And show output at level debug for another minute or so.
A full transcript of my session is attached. The ovms is still in this state so I can collect more information or perform more experiments.
<2017-12-27-1-modem-not-working.txt.gz>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 27/12/17 15:11, Mark Webb-Johnson wrote:
Weird. Looks like the MUX has failed…
I took it for a short drive with a laptop logging. The network communication was not great with quite often a lot of lag to updates in the app. However I couldn't reproduce exactly the state that I "normally" see. What I did find was a stack overflow with a fairly disappointing stack trace: D (1254884) gsm-mux: ProcessFrame(CHAN=2, ADDR=09, CTRL=ff, FCS=45, LEN=51) D (1254884) gsm-mux: ChanProcessFrame(CHAN=2, ADDR=09, CTRL=ff, LEN=48, IFP=3) D (1254884) SIMCOM ppp rx: 7e 21 45 00 00 28 4f 63 40 00 2d 06 24 44 bc 8a ~!E..(Oc@.-.$D.. D (1254884) SIMCOM ppp rx: 4b e5 0a aa c7 0f 1a d3 06 b0 75 8a b6 66 00 00 K.........u..f.. D (1254894) SIMCOM ppp rx: 33 ba 50 10 7b 88 d8 f4 00 00 43 51 7e 3.P.{.....CQ~ D (1254894) SIMCOM ppp tx: 7e 21 45 00 01 36 00 5b 00 00 ff 06 e0 3d 0a aa ~!E..6.[.....=.. D (1254894) SIMCOM ppp tx: c7 0f bc 8a 4b e5 06 b0 1a d3 00 00 33 ba 75 8a ....K.......3.u. D (1254894) SIMCOM ppp tx: b6 66 50 18 16 60 01 71 00 00 49 78 52 41 58 64 .fP..`.q..IxRAXd D (1254894) SIMCOM ppp tx: 57 66 6d 47 64 43 4f 62 6d 75 79 6e 35 45 4e 36 WfmGdCObmuyn5EN6 D (1254894) SIMCOM ppp tx: 70 46 31 31 7a 64 59 4f 63 33 69 54 2b 38 4e 46 pF11zdYOc3iT+8NF D (1254894) SIMCOM ppp tx: 44 48 45 78 37 42 33 34 49 72 54 74 34 47 54 4e DHEx7B34IrTt4GTN D (1254894) SIMCOM ppp tx: 71 43 61 6f 51 39 65 4e 55 38 58 6a 33 65 53 69 qCaoQ9eNU8Xj3eSi D (1254894) SIMCOM ppp tx: 61 66 4e 54 6a 4f 5a 57 5a 70 62 41 3d 3d 0d 0a afNTjOZWZpbA==..***ERROR*** A stack overflow in task tiT has been detected. abort() was called at PC 0x40088838 on core 1 Backtrace: 0x40088720:0x3ffcf170 0x4008881f:0x3ffcf190 0x40088838:0x3ffcf1b0 0x40086571:0x3ffcf1d0 0x4008 7b40:0x3ffcf1f0 0x40087afa:0x00000040 Rebooting... ets Jun 8 2016 00:22:57 Full logs are attached. The first couple of reboots (it didn't connect to the network properly) and the last reboot (it didn't appear to be talking to the network after the second stack overflow) were due to me pressing the button. There was another stack overflow shortly after the one quoted above (look for the timestamps to reset).
I’ve been rock solid for three days here, and a couple of network reconnects in that time. But my tcp/is stack size is 4096bytes. Can you check yours in menuconfig, component config, LWIP, tcp/ip task stack size? My tiT task grows to 2472/4096 bytes. Regards, Mark
On 27 Dec 2017, at 7:02 PM, Tom Parker <tom@carrott.org> wrote:
On 27/12/17 15:11, Mark Webb-Johnson wrote:
Weird. Looks like the MUX has failed…
I took it for a short drive with a laptop logging. The network communication was not great with quite often a lot of lag to updates in the app. However I couldn't reproduce exactly the state that I "normally" see. What I did find was a stack overflow with a fairly disappointing stack trace:
D (1254884) gsm-mux: ProcessFrame(CHAN=2, ADDR=09, CTRL=ff, FCS=45, LEN=51) D (1254884) gsm-mux: ChanProcessFrame(CHAN=2, ADDR=09, CTRL=ff, LEN=48, IFP=3) D (1254884) SIMCOM ppp rx: 7e 21 45 00 00 28 4f 63 40 00 2d 06 24 44 bc 8a ~!E..(Oc@.-.$D.. D (1254884) SIMCOM ppp rx: 4b e5 0a aa c7 0f 1a d3 06 b0 75 8a b6 66 00 00 K.........u..f.. D (1254894) SIMCOM ppp rx: 33 ba 50 10 7b 88 d8 f4 00 00 43 51 7e 3.P.{.....CQ~ D (1254894) SIMCOM ppp tx: 7e 21 45 00 01 36 00 5b 00 00 ff 06 e0 3d 0a aa ~!E..6.[.....=.. D (1254894) SIMCOM ppp tx: c7 0f bc 8a 4b e5 06 b0 1a d3 00 00 33 ba 75 8a ....K.......3.u. D (1254894) SIMCOM ppp tx: b6 66 50 18 16 60 01 71 00 00 49 78 52 41 58 64 .fP..`.q..IxRAXd D (1254894) SIMCOM ppp tx: 57 66 6d 47 64 43 4f 62 6d 75 79 6e 35 45 4e 36 WfmGdCObmuyn5EN6 D (1254894) SIMCOM ppp tx: 70 46 31 31 7a 64 59 4f 63 33 69 54 2b 38 4e 46 pF11zdYOc3iT+8NF D (1254894) SIMCOM ppp tx: 44 48 45 78 37 42 33 34 49 72 54 74 34 47 54 4e DHEx7B34IrTt4GTN D (1254894) SIMCOM ppp tx: 71 43 61 6f 51 39 65 4e 55 38 58 6a 33 65 53 69 qCaoQ9eNU8Xj3eSi D (1254894) SIMCOM ppp tx: 61 66 4e 54 6a 4f 5a 57 5a 70 62 41 3d 3d 0d 0a afNTjOZWZpbA==..***ERROR*** A stack overflow in task tiT has been detected. abort() was called at PC 0x40088838 on core 1
Backtrace: 0x40088720:0x3ffcf170 0x4008881f:0x3ffcf190 0x40088838:0x3ffcf1b0 0x40086571:0x3ffcf1d0 0x4008 7b40:0x3ffcf1f0 0x40087afa:0x00000040
Rebooting... ets Jun 8 2016 00:22:57
Full logs are attached. The first couple of reboots (it didn't connect to the network properly) and the last reboot (it didn't appear to be talking to the network after the second stack overflow) were due to me pressing the button. There was another stack overflow shortly after the one quoted above (look for the timestamps to reset). <2017-12-27-2-drive.txt.bz2> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 28/12/17 00:33, Mark Webb-Johnson wrote:
I’ve been rock solid for three days here, and a couple of network reconnects in that time.
But my tcp/is stack size is 4096bytes. Can you check yours in menuconfig, component config, LWIP, tcp/ip task stack size? My tiT task grows to 2472/4096 bytes.
I've only got 2560 (ie the default value from sdkconfig.default). I'll bump it up and try again tomorrow.
Maybe totally unrelated, but I thought I should mention it just in case. I couldn’t get Hologram Sim to work here in Norway with Telenor. I tried another SIM from Atea ( which used Telenor’s network) and that one worked. Only APN differed. Geir
27. des. 2017 kl. 12:41 skrev Tom Parker <tom@carrott.org>:
On 28/12/17 00:33, Mark Webb-Johnson wrote:
I’ve been rock solid for three days here, and a couple of network reconnects in that time.
But my tcp/is stack size is 4096bytes. Can you check yours in menuconfig, component config, LWIP, tcp/ip task stack size? My tiT task grows to 2472/4096 bytes.
I've only got 2560 (ie the default value from sdkconfig.default). I'll bump it up and try again tomorrow. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark Webb-Johnson wrote:
I’ve been rock solid for three days here, and a couple of network reconnects in that time.
But my tcp/is stack size is 4096bytes. Can you check yours in menuconfig, component config, LWIP, tcp/ip task stack size? My tiT task grows to 2472/4096 bytes.
Regards, Mark
I let yesterday's code run on the bench last night. Awoke to it being stuck... Here's the transition zone. Thoughts? I (9715181) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (9715191) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,9712,0,0,0,0,0,0,0,0,0,0 I (10316191) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (10316201) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,10313,0,0,0,0,0,0,0,0,0,0 I (10917201) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (10917211) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,10914,0,0,0,0,0,0,0,0,0,0 I (11518211) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (11518221) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,11515,0,0,0,0,0,0,0,0,0,0 I (12119221) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (12119231) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,12116,0,0,0,0,0,0,0,0,0,0 I (12720231) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (12720241) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,12717,0,0,0,0,0,0,0,0,0,0 I (13321241) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (13321251) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,13318,0,0,0,0,0,0,0,0,0,0 I (13922251) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (13922261) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,13919,0,0,0,0,0,0,0,0,0,0 I (14523261) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (14523271) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,14520,0,0,0,0,0,0,0,0,0,0 I (15124271) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (15124281) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,15121,0,0,0,0,0,0,0,0,0,0 I (15725281) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (15725291) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,15722,0,0,0,0,0,0,0,0,0,0 I (16326291) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (16326301) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,16323,0,0,0,0,0,0,0,0,0,0 I (16927301) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (16927311) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,16924,0,0,0,0,0,0,0,0,0,0 I (17528311) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (17528321) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,17525,0,0,0,0,0,0,0,0,0,0 I (18129321) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (18129331) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,18126,0,0,0,0,0,0,0,0,0,0 I (18730331) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (18730341) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,18727,0,0,0,0,0,0,0,0,0,0 I (19331341) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (19331351) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,19328,0,0,0,0,0,0,0,0,0,0 I (19932351) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (19932361) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,19929,0,0,0,0,0,0,0,0,0,0 I (20029401) simcom: CREG Network Registration: Searching I (20029461) simcom: Lost network connection (NetworkRegistration in NetMode) I (20029461) simcom: State: Enter NetLoss state I (20029461) gsm-ppp: Shutting down (hard)... I (20029461) ovms-server-v2: Network is down, so disconnect network connection E (20029461) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (20029471) gsm-ppp: StatusCallBack: User Interrupt I (20029471) gsm-ppp: PPP connection has been closed I (20038461) simcom: State timeout, transition to 5 I (20038461) simcom: State: Enter NetWait state I (20039461) ovms-server-v2: Status: Waiting for network connectivity I (20048481) simcom: CREG Network Registration: RegisteredRoaming I (20049461) simcom: State: Enter NetStart state I (20050551) simcom: PPP Connection is ready to start I (20051461) simcom: State: Enter NetMode state I (20051461) gsm-ppp: Initialising... I (20054951) gsm-ppp: StatusCallBack: None I (20054951) gsm-ppp: status_cb: Connected I (20054951) gsm-ppp: our_ipaddr = 10.170.146.142 I (20054951) gsm-ppp: his_ipaddr = 10.64.64.64 I (20054951) gsm-ppp: netmask = 255.255.255.255 I (20054951) gsm-ppp: our6_ipaddr = :: I (20059461) ovms-server-v2: Status: Network connectivity established I (20059461) ovms-server-v2: Connection is tmc.openvehicles.com:6867 ROADSTER_834/Gdbkt2017server I (20061011) ovms-server-v2: Connected to OVMS Server V2 at tmc.openvehicles.com I (20061021) ovms-server-v2: Status: Connected to server I (20061021) ovms-server-v2: Status: Logging in... I (20061021) ovms-server-v2: Sending server login: MP-C 0 NYaGgvcdnGlWDJSTSLKl7H 5S2UgEGKxSfoz5fRc+LYJw== ROADSTER_834 I (20061991) ovms-server-v2: Received welcome response MP-S 0 igcHhkZQpibm/UgepO3KdO 8wI19Wfa/W/6uzgSkRzNKA== I (20061991) ovms-server-v2: Got server response: MP-S 0 igcHhkZQpibm/UgepO3KdO 8wI19Wfa/W/6uzgSkRzNKA== I (20061991) ovms-server-v2: Server token is igcHhkZQpibm/UgepO3KdO and digest is 8wI19Wfa/W/6uzgSkRzNKA== I (20061991) ovms-server-v2: Status: Server auth ok. Now priming crypto. I (20061991) ovms-server-v2: Shared secret key is igcHhkZQpibm/UgepO3KdONYaGgvcdnGlWDJSTSLKl7H (44 bytes) I (20062001) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (20062001) ovms-server-v2: Status: Connected and logged in I (20062011) ovms-server-v2: Incoming Msg: MP-0 Z0 I (20533011) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (20533021) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,20530,0,0,0,0,0,0,0,0,0,0 I (20533021) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v2.1-75-g72bb091a) Dec 30 2017 21:39:01,123456789abcdefgh,8,1,TR,T-Mobile Hologram I (21134041) ovms-server-v2: Send MP-0 S0,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (21134051) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,21131,0,0,0,0,0,0,0,0,0,0 E (21155011) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (21155011) simcom: PPP Connection disconnected I (21155011) simcom: PPP Connection disconnected I (21155461) simcom: Lost network connection (+PPP disconnect in NetMode) I (21155461) simcom: State: Enter NetLoss state I (21155461) gsm-ppp: Shutting down (hard)... I (21155461) ovms-server-v2: Network is down, so disconnect network connection I (21160991) gsm-ppp: StatusCallBack: User Interrupt I (21160991) gsm-ppp: PPP connection has been closed I (21164461) simcom: State timeout, transition to 5 I (21164461) simcom: State: Enter NetWait state I (21165021) ovms-server-v2: Status: Waiting for network connectivity I (21168461) simcom: State: Enter NetStart state I (21169551) simcom: PPP Connection is ready to start I (21170461) simcom: State: Enter NetMode state I (21170461) gsm-ppp: Initialising... I (21170651) simcom: PPP Connection disconnected I (21170651) simcom: PPP Connection disconnected I (21171461) simcom: Lost network connection (+PPP disconnect in NetMode) I (21171461) simcom: State: Enter NetLoss state I (21171461) gsm-ppp: Shutting down (hard)... I (21180461) simcom: State timeout, transition to 5 I (21180461) simcom: State: Enter NetWait state I (21183451) gsm-ppp: StatusCallBack: User Interrupt I (21183451) gsm-ppp: PPP connection has been closed I (21184461) simcom: State: Enter NetStart state I (21185551) simcom: PPP Connection is ready to start I (21186461) simcom: State: Enter NetMode state I (21186461) gsm-ppp: Initialising... I (21186631) simcom: PPP Connection disconnected I (21186631) simcom: PPP Connection disconnected I (21187461) simcom: Lost network connection (+PPP disconnect in NetMode) I (21187461) simcom: State: Enter NetLoss state I (21187461) gsm-ppp: Shutting down (hard)... I (21196461) simcom: State timeout, transition to 5 I (21196461) simcom: State: Enter NetWait state I (21199451) gsm-ppp: StatusCallBack: User Interrupt I (21199451) gsm-ppp: PPP connection has been closed I (21200461) simcom: State: Enter NetStart state I (21201531) simcom: PPP Connection is ready to start I (21202461) simcom: State: Enter NetMode state I (21202461) gsm-ppp: Initialising... I (21202641) simcom: PPP Connection disconnected I (21202641) simcom: PPP Connection disconnected I (21203461) simcom: Lost network connection (+PPP disconnect in NetMode) I (21203461) simcom: State: Enter NetLoss state I (21203461) gsm-ppp: Shutting down (hard)... I (21212461) simcom: State timeout, transition to 5 I (21212461) simcom: State: Enter NetWait state I (21215451) gsm-ppp: StatusCallBack: User Interrupt I (21215451) gsm-ppp: PPP connection has been closed I (21216461) simcom: State: Enter NetStart state I (21217541) simcom: PPP Connection is ready to start I (21218461) simcom: State: Enter NetMode state I (21218461) gsm-ppp: Initialising... I (21218571) simcom: PPP Connection disconnected I (21218571) simcom: PPP Connection disconnected I (21219461) simcom: Lost network connection (+PPP disconnect in NetMode)
participants (7)
-
Geir Øyvind Vælidalo -
Greg D -
Greg D.
-
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner -
Tom Parker