<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">OK, so it's not in my python
environment (I recently upgraded to openSuSE 15).<br>
<br>
It seems to happen only on single lines, consecutive lines are
shown correctly.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
Am 09.07.2018 um 04:34 schrieb Mark Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:3F206A43-201C-4E25-9CC2-25E88D179EC8@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Works for me, and the tonight’s edge nightly build will feature
this.
<div class=""><br class="">
</div>
<div class="">Only issue I am seeing is that Espressif seemed to
have messed up the crlf handling on ‘make monitor’ again. The
‘make simple_monitor’ works fine, but for the full monitor
terminal emulator, the CRLF issued by our console (when you
press ENTER) is lost. Just seems to end up as a CR (LF
discarded).</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 9 Jul 2018, at 6:14 AM, 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="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Sorry, no
user feedback up to now on the wifi issues. As I don't
have them myself, I need to wait for feedback. But no
news means it's at least not worse than before ;)<br
class="">
<br class="">
Anyway, I've pushed the changes and esp-idf update.<br
class="">
<br class="">
@all: you need to update your esp-idf to build the
current version:<br class="">
<ul class="">
<li class=""><tt class="">cd $IDF_PATH</tt><tt
class=""><br class="">
</tt></li>
<li class=""><tt class="">git pull</tt></li>
<li class=""><tt class="">git submodule update
--recursive</tt><br class="">
</li>
</ul>
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 08.07.2018 um 10:59
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite"
cite="mid:1CFD2EB7-42D8-4070-8DB4-FEECFC16684C@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">I
even have some more free IRAM now, it used to be
down to ~1K and is now ~7K.</div>
</blockquote>
<div class=""><br class="">
</div>
That is very very good news. Using RELEASE build
(rather than DEBUG), I got mine down to a usable
level, but this should give us some breathing room.
<div class=""><br class="">
</div>
<div class="">Any noticeable improvement to the wifi
issues?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 8 Jul 2018, at 4:49 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="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
The new esp-idf works good, I think I'll
push the changes this evening.<br class="">
<br class="">
I even have some more free IRAM now, it used
to be down to ~1K and is now ~7K.<br
class="">
<br class="">
Remaining crashes recorded up to now:<br
class="">
<ul class="">
<li class=""><tt class="">3.1.008-32-g2fa3ab8-dirty/ota_1/edge
(build idf v3.2-dev-168-g0fb2019f Jul
6 2018
20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 ,</tt><tt
class=""><br class="">
</tt><tt class=""><br class="">
</tt></li>
<li class=""><tt class="">3.1.008-32-g2fa3ab8-dirty/ota_0/edge
(build idf v3.2-dev-168-g0fb2019f Jul
6 2018
20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc
0x00060230 0x80106004 0x3fff0d40
0x3ffc4794 0x00000000 0x3f4020ac
0x3fff1080 0x3fff1060 0x00000008
0x3ffed634 0x00000000 0x00000001
0x3ffc41f5 0x000000ff 0x0000ff00
0x00ff0000 0xff000000 0x00000004
0x0000001c 0x00000064 0x4009ee01
0x4009ee11 0xffffffff ,0x401165fc
0x40106001 0x400d3f9b 0x400d3ab5</tt><tt
class=""><br class="">
</tt><tt class="">→<br class="">
</tt><tt class="">Using elf file:
tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf</tt><tt
class=""><br class="">
</tt><tt class="">0x401165fc is in
_vfprintf_r
(../../../.././newlib/libc/stdio/vfprintf.c:1855).</tt><tt
class=""><br class="">
</tt><tt class="">0x40106001 is in
_siprintf_r
(../../../.././newlib/libc/stdio/siprintf.c:124).</tt><tt
class=""><br class="">
</tt><tt class="">0x400d3f9b is in
std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char>
>::_M_construct<char*>(char*,
char*, std::forward_iterator_tag)
(/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215).</tt><tt
class=""><br class="">
</tt><tt class="">210
basic_string<_CharT, _Traits,
_Alloc>::</tt><tt class=""><br
class="">
</tt><tt class="">211
_M_construct(_InIterator __beg,
_InIterator __end,</tt><tt class=""><br
class="">
</tt><tt class="">212
std::forward_iterator_tag)</tt><tt
class=""><br class="">
</tt><tt class="">213 {</tt><tt
class=""><br class="">
</tt><tt class="">214 // NB: Not
required, but considered best
practice.</tt><tt class=""><br
class="">
</tt><tt class="">215 if
(__gnu_cxx::__is_null_pointer(__beg)
&& __beg != __end)</tt><tt
class=""><br class="">
</tt><tt class="">216
std::__throw_logic_error(__N("basic_string::"</tt><tt
class=""><br class="">
</tt><tt class="">217
"_M_construct null not
valid"));</tt><tt class=""><br
class="">
</tt><tt class="">218 </tt><tt
class=""><br class="">
</tt><tt class="">219 size_type
__dnew =
static_cast<size_type>(std::distance(__beg,
__end));</tt><tt class=""><br class="">
</tt><tt class="">0x400d3ab5 is in
canlog::LogStatus(canbus*,
CAN_LogEntry_t, CAN_status_t const*)
(/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297).</tt><tt
class=""><br class="">
</tt><tt class="">292 return;</tt><tt
class=""><br class="">
</tt><tt class="">293 if
(CheckFilter(bus, type))</tt><tt
class=""><br class="">
</tt><tt class="">294 {</tt><tt
class=""><br class="">
</tt><tt class="">295
CAN_LogMsg_t msg;</tt><tt class=""><br
class="">
</tt><tt class="">296
msg.timestamp = esp_log_timestamp();</tt><tt
class=""><br class="">
</tt><tt class="">297 msg.bus =
bus;</tt><tt class=""><br class="">
</tt><tt class="">298 msg.type =
type;</tt><tt class=""><br class="">
</tt><tt class="">299 msg.status
= *status;</tt><tt class=""><br
class="">
</tt><tt class="">300
m_msgcount++;</tt><tt class=""><br
class="">
</tt><tt class="">301 if
(xQueueSend(m_queue, &msg, 0) !=
pdTRUE)</tt><tt class=""><br class="">
<br class="">
</tt></li>
<li class=""><tt class="">3.1.008-32-g2fa3ab8-dirty/ota_1/edge
(build idf v3.2-dev-168-g0fb2019f Jul
6 2018
20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74
0x4009606f 0x400ddaf7 0x40084e15
0x401e271d<br class="">
→ watchdog timeout, no more info<br
class="">
</tt></li>
</ul>
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 06.07.2018
um 22:07 schrieb Michael Balzer:<br
class="">
</div>
<blockquote type="cite"
cite="mid:27d5eae3-8bfe-ea5b-565b-d3f1b02206c3@expeedo.de"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
I've been using APCLIENT all the time and
only had one crash that looked like a wifi
problem. This really is a very specific
problem. I also have a very good wifi
signal, I can perfectly use my module's
web UI while the car is in my garage two
floors below. But I live in an uncrowded
area, not much wifi competition.<br
class="">
<br class="">
I have updated my esp-idf to the latest
upstream master (it's v3.2 now) and could
build without any memory issues. The wifi
driver now, besided loads of bug fixes,
also supports CSI. Our code only needs a
minor adjustment if you'd like to compile
yourself, add…<br class="">
<br class="">
<tt class="">#define _SOC_SPI_PERIPH_H_ //
don't include spi_periph.h (type
conflict)</tt><br class="">
<br class="">
…in <tt class="">components/spinodma/spi_master_nodma.h</tt>
before <tt class="">#include
"driver/spi_common.h"</tt>.<br class="">
<br class="">
If you don't want to compile, the new
build (with CSI enabled) is also on my
server:<br class="">
<br class="">
<a class="moz-txt-link-freetext"
href="http://ovms.dexters-web.de/firmware/ota/v3.1/edge/"
moz-do-not-send="true">http://ovms.dexters-web.de/firmware/ota/v3.1/edge/</a><br
class="">
<br class="">
…and now being installed by my beta
testers.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 06.07.2018
um 16:28 schrieb Mark Webb-Johnson:<br
class="">
</div>
<blockquote type="cite"
cite="mid:62B5183F-67C4-4F40-898F-75DB5165B162@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"
class="">
<div class="">My 2c:</div>
<div class=""><br class="">
</div>
For the access points I normally use, it
works 100% of the time for me. The only
issue I had was when the SSID password
was wrong on one of my access points
(sharing the same SSID) and that was
randomly causing me connection issues
(every time the ESP32 picked it).
<div class=""><br class="">
</div>
<div class="">
<div class="">I also don’t use
APCLIENT, and only use SCLIENT mode.
I’ve found APCLIENT to be buggy as
hell.</div>
</div>
<div class=""><br class="">
</div>
<div class="">But, I do have problems
connecting to some access points. In
particular phone hotspots. I suspect
either bugs in the wifi stack, or some
issue with channels.</div>
<div class=""><br class="">
</div>
<div class="">The only thing I am wary
of is that our current code does this:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px;
border: none; padding: 0px;" class="">
<div class="">esp_wifi_set_config…</div>
<div class="">esp_wifi_start…</div>
<div class="">esp_wifi_connect...</div>
</blockquote>
<div class="">
<div class=""><br class="">
</div>
<div class="">But the Espressif
examples have:</div>
<div class=""><br class="">
</div>
</div>
<blockquote style="margin: 0 0 0 40px;
border: none; padding: 0px;" class="">
<div class="">
<div class="">
<div class="">esp_wifi_set_config…</div>
<div class="">esp_wifi_start…</div>
<div class="">Wait
for SYSTEM_EVENT_STA_START</div>
</div>
</div>
</blockquote>
<blockquote style="margin: 0 0 0 40px;
border: none; padding: 0px;" class="">
<blockquote style="margin: 0 0 0 40px;
border: none; padding: 0px;"
class="">
<div class="">
<div class="">
<div class="">esp_wifi_connect...</div>
</div>
</div>
</blockquote>
</blockquote>
<div class="">
<div class=""><br class="">
</div>
<div class="">I had that working the
Espressif way in my big wifi
refactor that never made it to
production. But our current code
doesn’t wait for the
SYSTEM_EVENT_STA_START before
calling esp_wifi_connect.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 6 Jul 2018, at
9:04 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="">I've had similar
reports regarding poor wifi
connectivity, and this seems
to affect some modules more
than others (or may be
channel/frequency dependant?).
One<br class="">
user has just 1-2 bars AP wifi
signal with the module placed
~ 50 cm away from the phone.<br
class="">
<br class="">
I also still get reports of
spurious strange crashes, that
mostly seem to be related to
situations with poor wifi
signal. Some crash backtraces
just are<br class="">
complete blank / null, and
there is no crash report on
the USB output for these
before reboot.<br class="">
<br class="">
Yesterday, Frank tried to
perform some wifi scans. The
first scan went fine, the
second never returned, he had
to power off the module. After
reboot, all<br class="">
successive scans worked.<br
class="">
<br class="">
Two users reported they
occasionally cannot auth to
the OVMS AP with the correct
password, and they can then
reconnect just by retrying for
some minutes or by<br class="">
connecting & disconnecting
another client to the AP.<br
class="">
<br class="">
I already had a look at the
wifi tx power configuration,
it's at 100% by default.<br
class="">
<br class="">
This all feels like a) we need
to change something about the
antenna, and b) there are
quite some bugs in the wifi
blob.<br class="">
<br class="">
Looking at <a
href="https://github.com/espressif/esp32-wifi-lib/commits/master"
class=""
moz-do-not-send="true">https://github.com/espressif/esp32-wifi-lib/commits/master</a>
it seems there have been
numerous wifi blob fixes
lately. Last time I checked I
still was<br class="">
out of memory with the current
esp-idf, I'll check again.<br
class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
Am 06.07.2018 um 01:48 schrieb
Stephen Casner:<br class="">
<blockquote type="cite"
class="">I find the wifi
performance of OVMS v3 to be
poor, and I'm wondering<br
class="">
how it might be improved. I
have a mix of thoughts here.<br
class="">
<br class="">
For both my own unit and
that of Timothy Rodgers,
wifi reception in<br
class="">
our garages was unusable.
You can blame that on too
much distance<br class="">
from the access point, but
my iPhone and MacBook both
access the wifi<br class="">
just fine from my garage.
The wifi antenna in the
OVMS is probably<br class="">
smaller and its location
within the metal framework
around the car's<br class="">
firewall may impede radio
transmission. Perhaps it
would be feasible<br
class="">
to switch to an
ESP32-WROVER-I with an
external antenna to improve<br
class="">
performance, but that would
be a big deal. If there is
a transmit<br class="">
power adjustment, perhaps
that could be increased?<br
class="">
<br class="">
When Timothy parks his car
next to his house, which is
about 50 feet<br class="">
closer than the garage, then
the wifi reception was good
enough for<br class="">
the update to 3.1.008 to
succeed. But when he tries
to connect with<br class="">
the browser, page updates
often time out, so it is
close to unusable.<br
class="">
Perhaps we could improve
usability by increasing the
timeout in our<br class="">
javascript to allow more
time for TCP to retransmit?<br
class="">
<br class="">
For my own unit, I switched
from AP+client to just
client mode and at<br
class="">
first it seemed that had
improved the client
performance. But still<br
class="">
the next day I had no access
from the iPhone app. When I
connected to<br class="">
the console to find out why
I saw that server v2 was
repeatedly trying<br
class="">
to connect and failing. I'm
presuming that the cause was
poor wifi<br class="">
connectivity since I was
also not able to reach the
web server on the<br
class="">
client address, although I
have not proven that. But
since the client<br class="">
wifi was associated with the
home AP and had an address,
the OVMS<br class="">
network routing preferred
the wifi and did not try to
use the modem.<br class="">
For now I have resorted to
turning off wifi. I suggest
that the<br class="">
network routing algorithm be
enhanced to back off to use
the modem if<br class="">
some number of attempts to
connect to the server over
wifi have<br class="">
failed. The iPhone will do
this for itself (there is a
setting to<br class="">
enable this called Wi-Fi
Assist).<br class="">
<br class="">
The behavior of repeated
connection attempts and
failures by server v2<br
class="">
seems to induce a more
serious failure after a
while, perhaps due to<br
class="">
some resource starvation.
At that point there is a
failure message<br class="">
"mg_connect(<a
href="http://api.openvehicles.com:6867/"
class=""
moz-do-not-send="true">api.openvehicles.com:6867</a>)
failed: cannot parse
address"<br class="">
every time server v2 tries
to connect. I expect that
is a bug that<br class="">
could be fixed.<br class="">
<br class="">
Lastly, since we may
encounter situations where
network communication<br
class="">
is not working, we should
facilitate access to the
console. When I<br class="">
was trying to help Timothy
change a location radius
setting remotely<br class="">
by phone and the web browser
was timing out, I suggested
that he find<br class="">
a micro-USB cable so he
could connect to the
console. But then I<br
class="">
realized he would not have
any application on his
laptop that would<br
class="">
allow him to connect to the
console. Developers use
"make monitor" in<br
class="">
the software development
cycle, but users won't have
that tool. I<br class="">
have my own program on the
MacBook that I use as an
alternative when I<br
class="">
don't want to induce a reset
when I connect. But is
there a simple<br class="">
program for Windows suitable
for non-developer users that
can connect<br class="">
to the OVMS console?<br
class="">
<br class="">
-- Steve<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="">
</blockquote>
<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 class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" 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 class="">
<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 class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" 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 class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<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>
</blockquote>
</div>
<br class="">
</div>
<!--'"--><br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" 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 class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<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">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<!--'"--><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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>
<br>
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>