[Ovmsdev] Kona electric and http routing

Thu Oct 24 01:31:40 HKT 2019

I've pushed my SIMCOM changes. With these optimizations, fifo overflows and frame errors have dropped significantly:

    OVMS# sim stat de
    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
         Time: enabled

…but the overflow frequency differs between my modules (both v3.1, the one with the first gen CP2102 has more overflows), and I can still see a direct relation
to Wifi.

With Wifi switched completely off, no overflows occurred over a period of ~5 hours. As soon as Wifi was reactivated (regardless of the mode), the errors were back.

Am 23.10.19 um 09:31 schrieb Mark Webb-Johnson:
> While there is flow control on the USB side, I don’t think there is any between the ESP32 and the CP2102. See Espressif’s example DEVKIT-C schematic:
>
>     https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf
>
>
> or the OVMS one (which we based on DEVKIT-C). Just RX and TX data lines to the ESP32.

What about the RTS/CTS lines connected to IO13 & IO15 in the core board?

> However, during flashing there is pretty much nothing else running on the system and no high level operating system.

Indeed.

Regards,
Michael

> The good news is that these are very very short data lines. Just a few inches, I think. I did look at the signals in the early days of the project, and they
> seem quite clean.
>
> The GMS MUX flow control is at the frame level. I would guess that several frames would still need to be fit into the buffer for it to be effective. It is
> implemented on a per-channel basis, and a short description (from the blox manual) is:
>
>     http://read.pudn.com/downloads406/ebook/1729787/MuxImplementation_ApplicationNote_(WLS-CS-11002).pdf
>
>     6.3 FlowControlonvirtualchannels
>
>     The Flow control of the virtual channel is implemented in terms of MSC packets with the FC bit. If the application processor sets the FC bit to 1 for a
>     particular DLC, the TE does not send data to the application processor for that DLC until FC returns to 0 for the same DLC. The TE has limited resources
>     for buffering data, so if the DLC is involved in large data transfers (for example downloading data through a GPRS connection) a buffer overflow may occur
>     if the time between FC=1 and FC=0 is too long; in this case data may be lost and there is no error indication.
>
>     The application processor should avoid (if possible) the use of this feature or keep the time interval with the FC=1 as small as possible. 
>
>
> I never really did any optimisation of the SIMCOM (or MUX) driver at all. The MUX in particular was written by looking at other implementations, as the
> protocol specification has gone the way of most standards body specifications and is mostly undecipherable. I think there is some opportunity for improvement
> (but given our low bandwidth requirements at the time we never had the incentive). Flow control is not implemented at all.
>
> Regards, Mark
>
>> On 23 Oct 2019, at 3:01 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Mark,
>>
>> also not trying to sound too negative… but please read: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274
>>
>> The flashing process is done with hardware flow control. With Wifi enabled, we cannot even handle 115 kbit without fifo overflows.
>>
>> We can try the MUX flow control you mentioned, but will it be able to throttle transmission within frames longer than the HW FIFO?
>>
>> Btw, I've got an improvement on fifo overflow recovery in testing, if you want to work on this, I can push my changes this evening.
>>
>> Regards,
>> Michael
>>
>>
>> Am 23.10.19 um 08:50 schrieb Mark Webb-Johnson:
>>> But perhaps I am unintentionally sounding too negative...
>>>
>>> The biggest hurdle to this working technically is undoubtedly the LWIP support for SNAT and routing. If the library you caption (jonask1337/esp-lwip) solves
>>> that, it makes this technically feasible.
>>>
>>> My comments on baud rate on the UART link between ESP32 and SIMCOM are more about the practicality of it. That could be tested with a few simple
>>> modifications to our SIMCOM driver, to see how fast it could actually be driven. I know we get up to about 1Mbps for firmware flashing without an issue, and
>>> the ESP32 hardware UART is up to 5Mbps.
>>>
>>> It would be a fantastic feature to have, and incredibly useful.
>>>
>>> Regards, Mark.
>>>
>>>> On 23 Oct 2019, at 2:33 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>>> The connection between the SIMCOM and the ESP32 is 115,200 baud. That could be increased (in software), and there is software flow control on the GSM MUX
>>>> we use (although I have no idea if SIMCOM implements it); but without hardware flow control lines I don’t think it could/would approach 3G speeds.
>>>>
>>>> The alternative is to swap it around. Put the modem and the SIM in some other device designed for that purpose, and have OVMS connect to that as a WiFi client.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 23 Oct 2019, at 2:23 PM, Peter Lord <plord12 at gmail.com <mailto:plord12 at gmail.com>> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I've been lurking here for a while still debating wether to ditch my autopi in favour of OVMS.
>>>>>
>>>>> One thing thats held me back is to find a way to use the wifi hotspot as a NAT router - this is
>>>>> useful to allow my sat nav to get traffic and charging point updates.  As far as I can see on
>>>>> the web page this isn't currently supported.
>>>>>
>>>>> However I did see a couple of projects that adds NAT support to lwip :
>>>>>
>>>>> https://github.com/martin-ger/lwip_nat_arduino
>>>>> https://github.com/jonask1337/esp-lwip
>>>>>
>>>>> Does anyone know if adding NAT has a fighting chance ?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pete
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto: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
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191023/24d674a6/attachment-0001.html>