I've made a tiny bit of progress with my sim7600a ppp issue.
First I realized that I could now run the master branch. The first test I did with my dev/7600 actually stayed connected to ppp for more than 14 hours... I went looking for differences in my for-v3.3 and master builds and discovered my for-v3.3 tree was still using wolfssl. So I thought I had found the problem until 12 hours later when the dev unit lost ppp again.
I also see that it's possible to get ppp back up without rebooting by powering cell down (power cell off), waiting for that to complete, and then powering back up.
I went looking for additional things to log. I have cellular, cellular-modem-auto, and cellular-modem-factory set to verbose and gsm-mux and gsm-ppp set to debug. What else would be helpful?
I was reviewing this thread and found this:
On 9/6/21 23:28, Michael Balzer wrote:
>
> I also added counters for these, you can query them with the "simcom
> status debug" command:
>
>> OVMS# sim stat deb
>> Network Registration: RegisteredHome
>> Provider: congstar
>> Signal: -97 dBm
>>
>> State: NetMode
>> Ticker: 73099
>> User Data: 0
>> *** HW FIFO overflows: 21*
>> Buffer overflows: 0
>>
>> Mux
>> Status: up
>> Open Channels: 4
>> *** Framing Errors: 24*
>> Last RX frame: 1 sec(s) ago
>> RX frames: 151452
>> TX frames: 5472
>>
>> PPP: Connected on channel: #2
>>
>> GPS: Connected on channel: #1
>> Status: enabled
Indeed I see one fifo overflow on my dev (which has lots ppp one time since boot):
OVMS# cell status debug
MODEM Status
Model: SIM7600
Network Registration: RegisteredRoaming
Provider: AT&T Hologram
Signal: -83 dBm
Mode: LTE,Online
State: NetMode
Ticker: 1434
User Data: 0
UART:
FIFO overflows: 1
Buffer overflows: 0
Parity errors: 0
Frame errors: 0
Driver Buffer overflows: 0
Mux: Status up
Open Channels: 4
Framing Errors: 0
RX frames: 1864
TX frames: 78
Last RX frame: 0 sec(s) ago
PPP: Connected on channel: #2
GPS: Connected on channel: #1
Status: enabled
Time: enabled
I'm not sure if modem::modem() gets called when you power down/up the modem so I don't know if m_err_uart_fifo_ovf has been zero'd since boot.
On 9/6/21 18:35, Mark Webb-Johnson wrote:
>> Is it too soon to add the v3.3 and v1.3 pdfs to the source tree?)
>
> Yes, we haven’t finalised those, or gone through certification yet.
> We’ll release the v3.3 main board and modem layouts and schematics when
> that is complete (probably November/December timeframe).
I was thinking if I had the v3.3 modem schematic I could upgrade my boards to have uart hardware flow control. (I'm guessing if I had this I would not expect to see fifo overflows?)
Would it be useful for me to setup a way for you (Mark) to connect to my dev unit and interact with it while it is in the failed state?
Craig