[Ovmsdev] OVMS v3.3 hardware

Tue Dec 14 05:48:48 HKT 2021

Craig,

some earlier discussions on the fifo issue with some answers:

- 
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274
- http://lists.openvehicles.com/pipermail/ovmsdev/2019-October/013749.html

Regards,
Michael


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
>>     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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
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...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20211213/6f726468/attachment.sig>