On 12/12/21 23:19, Mark Webb-Johnson wrote:
I can see some improvements:
1. If we get a HW FIFO overflow in MUX mode, there is little point in continuing. Probably simplest to reset the modem at that point.
I'm not sure if I mentioned it before but when ppp tanks, gps continues to work.
2. At the moment, we pickup on various failures (like no MUX traffic, unable to make cellular connection, etc) and reset the modem. But I too have seen cases where the cellular connection can’t be made, that only a module reset seems to fix.
Perhaps the problem is in the async driver? Better to reset that as well?
Is the hw overflow in a uart in the esp32? I found this thread about uart overflows: https://esp32.com/viewtopic.php?t=534 Sounds like the hardware has 128 bytes of buffer. On 12/13/21 08:28, Michael Balzer wrote:
We subscribe to two NMEA sentences, which are sent once per second by the modem.
Looks like it's these two: https://www.trimble.com/oem_receiverhelp/v4.44/en/NMEA-0183messages_GNS.html https://www.trimble.com/oem_receiverhelp/v4.44/en/NMEA-0183messages_RMC.html Since both have latitude, longitude, and time I'm guessing you want both because GNS includes a finely grained mode indicator and number of satellites being tracked while RMC includes the track angle.
3. Hardware flow control would be nice, but sadly we simply don’t have the GPIOs for it. We only have two free unused, and they are desperately needed for expansion modules. The MUX protocol does have a software flow control mechanism, but I am not sure if that would help.
I remember seeing hw flow control being mentioned for the new hardware but I see now you shot that down: On 8/17/21 00:55, Mark Webb-Johnson wrote:
2. Any chance to fix the missing HW flow control on the modem UART connection?
I don’t think we have enough GPIOs. Perhaps later when/if ESP32 S3 becomes suitable?
And I'm guessing there is no change for this either? On 8/16/21 22:30, Mark Webb-Johnson wrote:
# Modem board v1.3: Fix support for DTR sleep/awake support.
4. I wonder why you are getting HW FIFO overflows? I am not seeing these.
Attached are draft 3.3 schematics. I have one change outstanding on these (I want to re-label CAN as CAN1..CAN3, rather than the existing CAN0..CAN2, to better match the firmware labelling), and then will publish.
(I see you also committed versions, thanks!) The only difference I could find is a pullup resistor on "FLIGHTMODE" which I guess allows AT command control over the flightmode feature? But I didn't find any code to enable flightmode. So probably something I don't need? Aside from the v3 esp32, what differences does the V3.3 main board have compared to a V3.2 board? On 12/13/21 00:09, Mark Webb-Johnson wrote:
@Craig do you have GPS/GNSS enabled on yours?
(Yes and) a week ago I converted my spare modem board with the other sim7600 module I had (giving me two total) and I put it in my Cadillac. It worked great until a few miles from work and then it wedged. I tried plugging in a laptop to confirm ppp had tanked but the solder on the usb pins had cracked again so I had to settle for cycling power. I put the 5360 back in that car and since then I've rarely seen the dev/bench unit lose ppp. I'm wondering now if it's because I've turned on a bunch of gsm related logging and that's changed the timing somehow? Going back the 128 byte buffer: aside from GNSS, what other messages does the modem send to the ovms module? I'm thinking most of the data flows from ovms out (e.g. V2 and V3 updates). Perhaps the timing of messages is such that it's rare but possible to have 3 or 4 arrive at the same time and fill up the buffer? Another thing I wondered about was does the ppp startup process get short circuited because the modem (unhelpfully) tells us that ppp is disconnected while we're trying to start ppp and when we see that we tear down ppp? OVMS# D (266645953) cellular: Netstart AT+CGDCONT=1,"IP","hologram";+CGDATA="PPP",1 D (266645993) cellular: mux-rx-line #2: CONNECT 115200 I (266645993) cellular: PPP Connection is ready to start OVMS# D (266646953) cellular: State transition NetStart => NetMode I (266646953) cellular: State: Enter NetMode state V (266646953) cellular: Starting PPP I (266646953) gsm-ppp: Initialising... D (266647033) cellular: mux-rx-line #3: NO CARRIER D (266647033) cellular: mux-rx-line #4: NO CARRIER D (266647043) cellular: mux-rx-line #3: +PPPD: DISCONNECTED I (266647043) cellular: PPP Connection disconnected D (266647043) cellular: mux-rx-line #4: +PPPD: DISCONNECTED I (266647043) cellular: PPP Connection disconnected OVMS# W (266647953) cellular: Lost network connection (+PPP disconnect in NetMode) D (266647953) cellular: State transition NetMode => NetLoss I (266647953) cellular: State: Enter NetLoss state D (266647953) cellular: mux-tx #3: AT+CGATT=0 V (266647953) cellular: Stopping PPP I (266647953) gsm-ppp: Shutting down (hard)... I (266647953) gsm-ppp: PPP is shutdown I (266647953) netmanager: Set DNS#1 0.0.0.0 I (266647963) netmanager: Set DNS#2 0.0.0.0 This is probably enough rambling and speculation for now. Craig