<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
For comparison, this is my bench module with the old CP2102:<br>
<blockquote><tt>OVMS# simcom status debug </tt><br>
<tt>Network Registration: RegisteredRoaming</tt><br>
<tt>Provider: Vodafone.de Hologram</tt><br>
<tt>Signal: -91 dBm</tt><br>
<br>
<tt>State: NetMode</tt><br>
<tt> Ticker: 593</tt><br>
<tt> User Data: 0</tt><br>
<tt> HW FIFO overflows: 63</tt><br>
<tt> Buffer overflows: 0</tt><br>
<br>
<tt> Mux</tt><br>
<tt> Status: up</tt><br>
<tt> Open Channels: 4</tt><br>
<tt> Framing Errors: 61</tt><br>
<tt> Last RX frame: 0 sec(s) ago</tt><br>
<tt> RX frames: 1069</tt><br>
<tt> TX frames: 47</tt><br>
<br>
<tt>PPP: Connected on channel: #2</tt><br>
<br>
<tt>GPS: Connected on channel: #1</tt><br>
<tt> Status: enabled</tt><br>
<tt> Time: enabled</tt><br>
</blockquote>
<br>
The bench module has both my main Wifi AP and the repeater in reach,
so that may also be due to the Wifi situation.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 23.10.19 um 19:31 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:ba93215a-e4c1-c5d6-a334-17e5ccf50bac@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I've pushed my SIMCOM changes. With these optimizations, fifo
overflows and frame errors have dropped significantly:<br>
<blockquote><tt>OVMS# sim stat de</tt><br>
<tt>Network Registration: RegisteredHome</tt><br>
<tt>Provider: congstar</tt><br>
<tt>Signal: -97 dBm</tt><br>
<br>
<tt>State: NetMode</tt><br>
<tt> Ticker: 73099</tt><br>
<tt> User Data: 0</tt><br>
<tt> HW FIFO overflows: 21</tt><br>
<tt> Buffer overflows: 0</tt><br>
<br>
<tt> Mux</tt><br>
<tt> Status: up</tt><br>
<tt> Open Channels: 4</tt><br>
<tt> Framing Errors: 24</tt><br>
<tt> Last RX frame: 1 sec(s) ago</tt><br>
<tt> RX frames: 151452</tt><br>
<tt> TX frames: 5472</tt><br>
<br>
<tt>PPP: Connected on channel: #2</tt><br>
<br>
<tt>GPS: Connected on channel: #1</tt><br>
<tt> Status: enabled</tt><br>
<tt> Time: enabled</tt><br>
</blockquote>
…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.<br>
<br>
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.<br>
<br>
<br>
<div class="moz-cite-prefix">Am 23.10.19 um 09:31 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:264CC7C9-54CB-4B5D-9CD9-DB1CAAEFBDB7@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
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:
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><a
href="https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf"
class="" moz-do-not-send="true">https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf</a></div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>or the OVMS one (which we based on DEVKIT-C). Just RX and
TX data lines to the ESP32.</div>
</div>
</blockquote>
<br>
What about the RTS/CTS lines connected to IO13 & IO15 in the
core board?<br>
<br>
<blockquote type="cite"
cite="mid:264CC7C9-54CB-4B5D-9CD9-DB1CAAEFBDB7@webb-johnson.net">
<div class="">
<div>However, during flashing there is pretty much nothing
else running on the system and no high level operating
system.</div>
</div>
</blockquote>
<br>
Indeed.<br>
<br>
Regards,<br>
Michael<br>
<br>
<blockquote type="cite"
cite="mid:264CC7C9-54CB-4B5D-9CD9-DB1CAAEFBDB7@webb-johnson.net">
<div class="">
<div>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.</div>
<div><br class="">
</div>
<div>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:</div>
<div><br class="">
</div>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">
<div><a
href="http://read.pudn.com/downloads406/ebook/1729787/MuxImplementation_ApplicationNote_(WLS-CS-11002).pdf"
class="" moz-do-not-send="true">http://read.pudn.com/downloads406/ebook/1729787/MuxImplementation_ApplicationNote_(WLS-CS-11002).pdf</a></div>
</div>
<div><span style="font-family: "Frutiger 45
Light,Bold"; font-size: 14pt;" class=""><br class="">
</span></div>
<div><span style="font-family: "Frutiger 45
Light,Bold"; font-size: 14pt;" class="">6.3
FlowControlonvirtualchannels</span></div>
<div>
<div class="page" title="Page 15">
<div class="layoutArea">
<div class="column">
<p class=""><span style="font-size: 10.000000pt;
font-family: 'Frutiger 45 Light'" class="">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. </span></p>
<p class=""><span style="font-size: 10.000000pt;
font-family: 'Frutiger 45 Light'" class="">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. </span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>Regards, Mark</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 23 Oct 2019, at 3:01 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Mark,<br class="">
<br class="">
also not trying to sound too negative… but please
read: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274"
class="" moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274</a><br
class="">
<br class="">
The flashing process is done with hardware flow
control. With Wifi enabled, we cannot even handle 115
kbit without fifo overflows.<br class="">
<br class="">
We can try the MUX flow control you mentioned, but
will it be able to throttle transmission within frames
longer than the HW FIFO?<br class="">
<br class="">
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.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
Am 23.10.19 um 08:50 schrieb Mark Webb-Johnson:<br
class="">
<blockquote type="cite" class="">But perhaps I am
unintentionally sounding too negative...<br class="">
<br class="">
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.<br
class="">
<br class="">
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.<br
class="">
<br class="">
It would be a fantastic feature to have, and
incredibly useful.<br class="">
<br class="">
Regards, Mark.<br class="">
<br class="">
<blockquote type="cite" class="">On 23 Oct 2019, at
2:33 PM, Mark Webb-Johnson <<a
href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
Regards, Mark.<br class="">
<br class="">
<blockquote type="cite" class="">On 23 Oct 2019,
at 2:23 PM, Peter Lord <<a
href="mailto:plord12@gmail.com" class=""
moz-do-not-send="true">plord12@gmail.com</a>>
wrote:<br class="">
<br class="">
Hi All,<br class="">
<br class="">
I've been lurking here for a while still
debating wether to ditch my autopi in favour of
OVMS.<br class="">
<br class="">
One thing thats held me back is to find a way to
use the wifi hotspot as a NAT router - this is <br
class="">
useful to allow my sat nav to get traffic and
charging point updates. As far as I can see on
<br class="">
the web page this isn't currently supported.<br
class="">
<br class="">
However I did see a couple of projects that adds
NAT support to lwip :<br class="">
<br class="">
<span class="Apple-tab-span" style="white-space:pre"> </span><a
href="https://github.com/martin-ger/lwip_nat_arduino" class=""
moz-do-not-send="true">https://github.com/martin-ger/lwip_nat_arduino</a><br
class="">
<span class="Apple-tab-span" style="white-space:pre"> </span><a
class="moz-txt-link-freetext"
href="https://github.com/jonask1337/esp-lwip"
moz-do-not-send="true">https://github.com/jonask1337/esp-lwip</a><br
class="">
<br class="">
Does anyone know if adding NAT has a fighting
chance ?<br class="">
<br class="">
Cheers,<br class="">
<br class="">
Pete<br class="">
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a class="moz-txt-link-abbreviated"
href="mailto:OvmsDev@lists.openvehicles.com"
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</blockquote>
</blockquote>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</blockquote>
<br class="">
<br class="">
-- <br class="">
Michael Balzer * Helkenberger Weg 9 * D-58256
Ennepetal<br class="">
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br
class="">
<br class="">
<br class="">
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>