[Ovmsdev] Kona electric and http routing
dexter at expeedo.de
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
Signal: -97 dBm
User Data: 0
HW FIFO overflows: 21
Buffer overflows: 0
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
…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
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:
> 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.
> 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:
> 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:
>> 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.
>> 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 :
>>>>> Does anyone know if adding NAT has a fighting chance ?
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> 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>
> 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 --------------
An HTML attachment was scrubbed...
More information about the OvmsDev