On 11/23/21 18:37, Mark Webb-Johnson wrote:
From what you sent before, it just seemed that the PPP link could not be established. The CSQ figures you show below indicate the dev board has a better signal (and production is marginal):
Indeed, the dev board is in an upstairs bedroom and it's easy to imagine it has a better view of the local cell towers.
I am not aware of any limitation / restriction on inactive PPP cellular data connections - I guess that would depend on the configuration of individual operators. Can you configure the dev board to send some data?
Would that just be a matter of configuring it to use a V2 (or V3) server? Does it matter that the module is not connected to a vehicle? Or that it's constantly on wifi (literally 2m away from the AP). I'm not really clear on how the simcom is used when the module is connected to a vehicle and sits in my garage, connected to wifi, for a week. I've been wondering if the disconnect is just some kind of carrier idle timeout? And after looking at the esp-idf simcom sample code, is the problem that our code is not handling the PPP disconnect event well? Since rebooting the module "fixes" the issue for another 12 hours, it seems it should be possible get back online without rebooting. When PPPERR_USER occurs, all we do is set m_connected to false and SignalEvent that the modem is down. It sort of looks like the example code does more? esp-idf/examples/protocols/pppos_client/components/modem/src/esp_modem.c case PPPERR_USER: /* User interrupt */ esp_event_post_to(esp_dte->event_loop_hdl, ESP_MODEM_EVENT, MODEM_EVENT_PPP_STOP, NULL, 0, 0); /* Free the PPP control block */ pppapi_free(esp_dte->ppp); break; Where pppapi_free() eventually does a tcpip_api_call() which does something to the "TCPIP thread".
I am not really sure how to help here, seeing the little extracts of logs you send and not knowing your environment. From a troubleshooting point of view, the logs should show the cellular activity and behaviour of the modem.
The log is pretty redundant until the failure. I put a copy here if you'd like to look at the whole thing: https://xse.com/leres/scratch/dev1.log.gz Note that it's full of escape sequences because I generated it with xterm and my usual voodoo (ul -Tdumb) doesn't work. Also I can't easily make a sdcard log because the sdcard interface on this unit hasn't worked since I swapped the cp2102 chip; I've been too lazy to debug this plus the CP2102N-A02-GQFN28 chip has been pretty much unobtainium for the last N months. Craig