[Ovmsdev] OVMS v3.3 hardware

[Craig Leres]

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