[Ovmsdev] 3.2.018 release

[Craig Leres]

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