[Ovmsdev] OVMS v3.3 hardware
dexter at expeedo.de
Tue Dec 14 05:48:48 HKT 2021
some earlier discussions on the fifo issue with some answers:
Am 13.12.21 um 22:28 schrieb 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
> Is the hw overflow in a uart in the esp32? I found this thread about
> uart overflows:
> 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:
> 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
>> 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
>> 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
> (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
> 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.
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the OvmsDev