<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks for the summary. Good to have it all in one email.<br>
<br>
Onward!<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:FDA873E0-4008-4E04-83C3-01DB4E25B123@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Short answer: RAM (3.0 has 520KB internal, of which about 100KB is
usable, and 3.1 adds another 4MB of external RAM while allowing us
to claw back some of that missing 400+KB).
<div class=""><br class="">
</div>
<div class="">Long(er) answer:</div>
<div class=""><br class="">
</div>
<div class="">If I’d known back then what I know now (that 80% of
the 520KB internal RAM would be unavailable to us), perhaps a
different decision would have been made. Looking back, OVMS v2
had 3KB RAM. Anyway, we are where we are and a fairly simple
switch to WROVER (from WROOM-32) provides a solution to the
problem.</div>
<div class=""><br class="">
</div>
<div class="">The WROVER and WROOM-32 are really very similar;
pinouts are identical. The only difference is the addition of
the 4MB PSRAM in the module, GPIO 16, GPIO 17, and the change of
VDD_SDIO from 3.3v to 1.8v (which has the knock on effect to our
external 16MB flash). Module price is even almost the same.</div>
<div class=""><br class="">
</div>
<div class="">The circuit layout changes 3.0 -> 3.1 are (a) to
improve electrical isolation and power on the high speed buses
(which should be done anyway), and (b) to cope with the change
to 1.8v on VDD_SDIO affecting our external 16MB flash. Change
(a) has to be made anyway, and (b) is pretty minimal, but does
bring some risk (time).</div>
<div class=""><br class="">
</div>
<div class="">ESP IDF 2.1 -> 3.x had to happen anyway, for the
SDCARD issue as well as for the huge number of bugs Espressif
have squished in the past six months (just have a look at the
3.0b1 release notes).</div>
<div class=""><br class="">
</div>
<div class="">To me, Strider’s comment (on <a
href="http://teslamotorsclub.com" class=""
moz-do-not-send="true">teslamotorsclub.com</a>) this morning
sums it up:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><i class="">Excellent news Mark! Don't rush on our
account. I would rather have a bulletproof unit than to have
it a few weeks earlier.</i></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I don’t want this project to turn into a Perl 5. Our
time aside, I’m particularly aware of all the money, time and
effort the China guys are putting into this without any payback
until we start manufacturing (they get $0 for design work, but a
margin on the production runs). I specifically haven’t run this
as a kickstarter project, to avoid taking people’s money and
committing to a time pressure to get something/anything out. We
need to get it right.</div>
<div class=""><br class="">
</div>
<div class="">Regarding releasing 3.0 now (everything works on the
3.0 boards we have), vs waiting for 3.1 hardware, to me the
points are:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">It seems that with the 3.0 hardware there will
never be enough RAM to run _everything_ (wifi, bluetooth,
cellular, vehicle, etc) at once. It seems that without
bluetooth, we can fit in, but as Michael pointed out the
other day - fixing sdcard just makes the memory situation
tighter. I worry that this will cause end-user issues. There
is just not enough safety margin in the RAM.<br class="">
<br class="">
</li>
<li class="">I don’t think the firmware is production end-user
ready anyway. For developers, it is fine. For technical
end-users, very close. But for non-technical end-users, we
need time to iron out the bugs, and add the ease-of-use
stuff. We had this issue with v1 OVMS - it wasn’t ready for
non-technical end-users, and support in the early days was a
PITA.<br class="">
<br class="">
</li>
<li class="">The 3.x platform is looking extremely powerful
and able to do what we need. In particular, I’m impressed
with connectivity and console (all the work Steve did on
SSH, and consoles), but also Reverse Engineering CAN bus
support, logging, notifications, OBDII HUD, etc. I think
this can be a fantastic platform for all sorts of wonderful
stuff.<br class="">
<br class="">
</li>
<li class="">We need to add that extra electrical protection
on the high-speed buses anyway, so that needs another
prototype board run (just to make sure nothing is messed
up). Moving WROOM-32 -> WROVER adds perhaps a week’s
delay; provided the prototype doesn’t have any problems, of
course.<br class="">
<br class="">
</li>
<li class="">Maintaining two different hardware bases, for
production, is going to be a lot more hassle than one.
Developer units are fine - we can flash our own firmware -
but support for end-user production units is something else
entirely.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On 18 Jan 2018, at 2:01 AM, Greg D. <<a
href="mailto:gregd2350@gmail.com" class=""
moz-do-not-send="true">gregd2350@gmail.com</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=""> So, I'm
not a practicing electrical engineer (though I do know
which end of the soldering iron to hold), but I did
spend many years in R&D project and program
management... Is there a reason the v3.0 hardware can't
go to market? There are many potential customers who
have been waiting patiently for the product, and
switching horses at this late date in a traditional
development scenario would be extremely unusual.
Historically, such things often turn out badly. (I have
scars...)<br class="">
<br class="">
Now, I know (and am grateful) that this isn't a
traditional development project, and that has some
really big advantages. The world of modular hardware
and development has moved light years forward. But we
do need to deliver something. 3.0 doesn't have to be
the last thing we ever do; is it good enough to make a
substantial number of potential customers into real
customers? What would they not be getting? What would
the cost be (both monetary and other) to ship 3.0 as it
is, and roll to 3.1 relatively soon after 3.0 ships?
For example, to ship 3.0 as is, would we need to build a
more complicated fulfillment process to custom-build
each delivery, in order to optimize RAM? What do we
lose by shipping 3.0, in terms of our ability to do 3.1?<br
class="">
<br class="">
Just asking... We've discussed bits and pieces of the
situation, but I wouldn't mind a nice summary. What
really are the options at this point? <br class="">
<br class="">
Greg<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br
class="">
</div>
<blockquote type="cite"
cite="mid:4695D2F3-94DC-4935-B830-EAA8B2BDC990@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class=""><br class="">
</div>
<div class="">We hit a snag with the 3.1 hardware
design. The flash voltage (VDD_SDIO) in WROVER
module is 1.8V. In WROOM-32 module, VDD_SDIO was
3.3V. Also, as previously mentioned, the WROOM-32
modules uses GPIO16 and GPIO17 for external PSRAM
(SPI CLK and CS signals). What wasn’t clear was
_why_ they chose those pins. It now is…</div>
<div class=""><br class="">
</div>
<div class="">The ESP32 design is that some pins
(GPIO16, GPIO17, FL_DATA_2, FL_DATA_3, FL_CMD,
FL_CLK, FL_DATA_0, FL_DATA_1, and of course
VDD_SDIO) operate in the VDD_SDIO domain, and the
rest operate in the 3V3 domain. So, switching
VDD_SDIO to 1.8V (is 3.3V in OVMS v3) also switches
those eight GPIOs to 1.8V. Another complication is
that VDD_SDIO is not exposed (not a problem for
3.3v, but an issue if we want 1.8v to power the
external flash).</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">I attach spreadsheet with ESP32,
WROOM-32, and WROVER pinouts, along with strapping
pins used and power domains (3.3V, SDIO/1.8V,
etc). I think this makes things much clearer.</div>
<div class=""><br class="">
</div>
<div class="">The WROVER pins are essentially the
same as WROOM-32. No more, no less. But, VDD_SDIO
changes from 3.3V to 1.8V.</div>
<div class=""><br class="">
</div>
<div class="">It seems that the simplest approach
is:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Free GPIO4 (SD_DATA1), GPIO12
(SD_DATA2), and GPIO13 (SD_DATA3) and make
SDCARD 1-line protocol.</li>
<li class="">Note that GPIO12 is MTDI and is a
strapping pin for 1.8V/3.3V, so we’ll try not
to use that.</li>
<li class="">GPIO16 and GPIO17 are now used by
PSRAM (CS and CLK), and not exposed. So:</li>
<ul class="">
<li class="">Move UART 2 (TX to modem) to
GPIO13.</li>
<li class="">Move UART 2 (TX from modem) to
GPIO4.</li>
<li class="">Leave GPIO16 and GPIO17
unconnected (used internally by WROVER).</li>
</ul>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">That leaves the problem of GPIO22
(FL_CS2) for our external flash. All the other
(shared) pins are VDD_SDIO (1.8v), but that pin is
in the 3.3v domain, and we need it to drive an
external 1.8v flash chip (which is not 3.3v
tolerant). From what I can see, there are no free
VDD_SDIO domain pins. #17 through #22 are used for
SPI flash HSI, and the last two GPIO16 and GPIO17
are used for the PSRAM (and are not exposed
outside WROVER so nothing we can do about it
anyway).</div>
<div class=""><br class="">
</div>
<div class="">The only solution we can see is to
continue to use GPIO22 for FL_CS2 external flash,
but use a level converter 3.3V -> 1.8V. We only
need uni-directional, but it must operate fast
enough not to interfere with a 40MHz SPI bus.
Maybe a resistor voltage divider would be too slow
/ interfere too much, so safer to use a simple
single channel uni-directional 3.3V->1.8V logic
level shifter chip. Trying to find a flash chip
that is 3.3V tolerant, and test it, would just
introduce more delays (for the sake of one extra
9cent component).</div>
<div class=""><br class="">
</div>
<div class="">Regarding the SDCARD. According to the
specs, this is driven at 3.3V and our circuit has
this on 3.3V pins, so that should be ok. The only
issue is strapping pins GPIO2 and GPIO12. I can’t
get this to work with Analog Lamb’s WROOM-32+PSRAM
module at all, but it works fine on the Espressif
WROVER-KIT I have (in both 1 line and 4 line
modes). So we just use the capacitors and pull-up
resistors from the WROVER-KIT arrangement, along
with our existing GPIO2-GPIO0 link (as per
Espressif SDCARD documentation):</div>
</div>
<div class=""><br class="">
</div>
<div class="">The changes to support this now include:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Swap the GPIOs around, as above
(freeing some pins from moving SDCARD 4-line to
1-line, and staying clear of the nasty GPIO12).</li>
<li class="">Add a new small 3.3v->1.8v
regulator, to power just our 16MB external flash
chip (and level converter).</li>
<li class="">Add a new unidirectional 3.3v->1.8
level converter for CS line of 16MB external
flash.</li>
<li class="">Switch external 16MB flash to a 1.8v
component.</li>
<li class="">Add a few capacitors on the power
lines near external flash and SD CARD, to help
with peak power draws.</li>
<li class="">Re-work SD CARD pull-ups and
protection circuitry (as per latest Espressif
WROVER-KIT design).</li>
<li class="">Minimising length of SPI and SD bus
lines, and keeping them away from sources of
interference (where possible).</li>
<li class="">Increasing size of solder pad for USB
connector, and large capacitors, to make
stronger.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I’m triple checking this tonight (as it
goes to make boards tomorrow). I would appreciate
any feedback from electrical engineers on this list.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class=""><br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">Begin forwarded message:</div>
<br class="Apple-interchange-newline">
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">From: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">Mark Webb-Johnson <<a
href="mailto:mark@webb-johnson.net"
class="" moz-do-not-send="true">mark@webb-johnson.net</a>><br
class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">Subject: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class=""><b class="">[Ovmsdev] OVMS Hardware
v3.1</b><br class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">Date: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">10 January 2018 at 2:41:58 PM HKT<br
class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">To: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">OVMS Developers <<a
href="mailto:OvmsDev@lists.teslaclub.hk"
class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>><br
class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">Reply-To: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">OVMS Developers <<a
href="mailto:ovmsdev@lists.teslaclub.hk"
class="" moz-do-not-send="true">ovmsdev@lists.teslaclub.hk</a>><br
class="">
</span></div>
<br class="">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Production…</div>
<div class=""><br class="">
</div>
<div class="">Analog Lamb, while
interesting, is just (a) too expensive
(double the price), (b) unproven, (c)
uncertified, and (d) has long lead times.
Using proven Espressif certified modules
seems the safer way to go.</div>
<div class=""><br class="">
</div>
<div class="">So, we’ve decided to go with a
switch to a standard certified ESP WROVER
module, and external 16MB flash memory.
The circuit board footprint for this is a
little larger than the WROOM-32 module
we’ve been using, and requires one more
3.3V->1.8V power conversion, but seems
the safest way to go.</div>
<div class=""><br class="">
</div>
<div class="">Accordingly, I’ve agreed with
the China guys to proceed along these
lines for the main board:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="" style="margin: 0px; padding:
0px;">
<ol class="MailOutline"
style="margin-right: 0px; margin-left:
0px; padding: 0px 0px 0px 20px;
list-style-position: inside;">
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Change WROOM-32 to
WROVER (on circuit antenna version,
similar to WROOM-32).<br class=""
style="margin: 0px; padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">We can free IO12
(SD_D2), IO13 (SD_D3), and IO4
(SD_D1), by using just 1-line
SDCARD. I don’t really want to use
IO12 as that is a bootstrapping pin.<br
class="" style="margin: 0px;
padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">WROVER PSRAM uses
IO16 and IO17, so we can’t use that
for modem.</li>
<ul class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px 0px 0px 20px;
list-style-position: inside;">
<li class="" style="margin: 0px;
padding: 0px;">Move modem to IO4
and IO13.<br class=""
style="margin: 0px; padding:
0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
</ul>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Change to 1.8V 16MB
flash chip (W25Q128FW?). As SDD_VDIO
is not exposed, add a simple
regulator 3.3V->1.8V for external
flash?<br class="" style="margin:
0px; padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">When burning e-fuses,
need to take care with 1.8V/3.3V
SDD_SDIO fuse - leave at 1.8V.<br
class="" style="margin: 0px;
padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Add capacitors for SD
CARD and external Flash, as per
Espressif example.<br class=""
style="margin: 0px; padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Increase size of
solder pad for big capacitors, and
USB connector, to make it stronger.<br
class="">
<br class="">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">For the data lines of
circuit traces SDCARD, SPI bus,
external flash, take care to keep
away from power traces or other
sources of interference and keep the
traces as short as possible.</li>
</ol>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">The change to WROVER is a PITA
at this stage, but that 4MB PSRAM should
give us more headroom and the extra
bill-of-materials costs is just a couple
of US$.</div>
<div class=""><br class="">
</div>
<div class="">For the modem, we’re
double-checking the power (which seems ok,
but check to be sure), and changing
passive -> active antenna. At the
moment, it seems to be just a couple of
passive components soldered inline between
two easily accessible points. For existing
developer modems in the field, we’ll try
to make a simple upgrade kit
(passive->active) for GPS, and post
them out. If you don’t need GPS (such as
Roadster users), the modem boards are
functionally the same as the production
ones.</div>
<div class=""><br class="">
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Existing developer OVMS v3
boards (with WROOM-32 module) will
continue to be called v3.0. New production
OVMS v3 boards (with WROVER module) will
be called v3.1. We have conditional
compilation in the firmware, to switch the
pin assignments and whatever else is
required.</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px;
border: none; padding: 0px;" class="">
<div class=""><span style="font-family:
Menlo-Regular; font-size: 14px;"
class=""> Branch: refs/heads/for-v3.0</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Home: </span><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3"
style="font-family: Menlo-Regular;
font-size: 14px;" class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3</a><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Commit:
9504df70be78b6626970ec0ea53d2c2470e90afa</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> </span><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa"
style="font-family: Menlo-Regular;
font-size: 14px;" class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa</a><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Author:
Mark Webb-Johnson <</span><a
href="mailto:mark@webb-johnson.net"
style="font-family: Menlo-Regular;
font-size: 14px;" class=""
moz-do-not-send="true">mark@webb-johnson.net</a><span
style="font-family: Menlo-Regular;
font-size: 14px;" class="">></span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Date:
2018-01-10 (Wed, 10 Jan 2018)</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Changed
paths:</span><br style="font-family:
Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> M
vehicle/OVMS.V3/main/Kconfig</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> M
vehicle/OVMS.V3/main/ovms_peripherals.h</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Log
Message:</span><br style="font-family:
Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> -----------</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Support
for OVMS hardware v3.1</span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class="">Converting developer v3.0
boards to v3.1 is not really feasible (a
skilled solderer could probably use a
16MB Analog Lamb WROOM-32+PSRAM module;
that would be a relatively simple
de-solder + re-solder of the module, a
not-so-simple re-arrange of the traces
for IO16->IO4 and IO17->IO13, and
disabling of external 16MB flash).
Anyway, those existing developer modules
should be fine to continue to use (just
without the extra PSRAM).</div>
</div>
<div class=""><br class="">
</div>
<div class="">We are today finalising the
circuit schematic and board layout for the
above, and building a couple of test
boards (with WROVER modules). I should
have one in about a week’s time (assuming
all the components are available). In that
time, we’ll finish the ESP IDF v3.0
support, and test late next week / over
next weekend (20th/21st Jan). Assuming no
problems, we should be able to give
factory the go-ahead to produce early the
week after.</div>
<div class=""><br class="">
</div>
<div class="">Given that timing, I doubt if
we are going to be able to get these
boards made before the Chinese New Year
holidays. Even if we can get them made,
FastTech distribution may not be able to
get them out during the holidays.
Manufacturing in China starts to close
down around the end of January / early
February this year. New Year itself is
mid-February. Anyway, we’ll get this all
finalised, payment and instruction to
start manufacturing in place, then do the
best we can and get these out available
during February. A big warning is going to
go with them that this is for early
adopters only, and firmware is changing on
a daily basis. Updating firmware via wifi
/ sd card should be fine.</div>
<div class=""><br class="">
</div>
<div class="">I’m seeing a light at the end
of a long dark tunnel.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.teslaclub.hk"
class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">Begin forwarded message:</div>
<br class="Apple-interchange-newline">
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">From: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">Mark Webb-Johnson <<a
href="mailto:mark@webb-johnson.net"
class="" moz-do-not-send="true">mark@webb-johnson.net</a>><br
class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">Subject: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class=""><b class="">OVMS Hardware v3.1</b><br
class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">Date: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">10 January 2018 at 2:41:58 PM HKT<br
class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"
class=""><span style="font-family:
-webkit-system-font, "Helvetica
Neue", Helvetica, sans-serif;" class=""><b
class="">To: </b></span><span
style="font-family: -webkit-system-font,
Helvetica Neue, Helvetica, sans-serif;"
class="">OVMS Developers <<a
href="mailto:OvmsDev@lists.teslaclub.hk"
class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>><br
class="">
</span></div>
<br class="">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Production…</div>
<div class=""><br class="">
</div>
<div class="">Analog Lamb, while
interesting, is just (a) too expensive
(double the price), (b) unproven, (c)
uncertified, and (d) has long lead times.
Using proven Espressif certified modules
seems the safer way to go.</div>
<div class=""><br class="">
</div>
<div class="">So, we’ve decided to go with a
switch to a standard certified ESP WROVER
module, and external 16MB flash memory.
The circuit board footprint for this is a
little larger than the WROOM-32 module
we’ve been using, and requires one more
3.3V->1.8V power conversion, but seems
the safest way to go.</div>
<div class=""><br class="">
</div>
<div class="">Accordingly, I’ve agreed with
the China guys to proceed along these
lines for the main board:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="" style="margin: 0px; padding:
0px;">
<ol class="MailOutline"
style="margin-right: 0px; margin-left:
0px; padding: 0px 0px 0px 20px;
list-style-position: inside;">
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Change WROOM-32 to
WROVER (on circuit antenna version,
similar to WROOM-32).<br class=""
style="margin: 0px; padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">We can free IO12
(SD_D2), IO13 (SD_D3), and IO4
(SD_D1), by using just 1-line
SDCARD. I don’t really want to use
IO12 as that is a bootstrapping pin.<br
class="" style="margin: 0px;
padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">WROVER PSRAM uses
IO16 and IO17, so we can’t use that
for modem.</li>
<ul class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px 0px 0px 20px;
list-style-position: inside;">
<li class="" style="margin: 0px;
padding: 0px;">Move modem to IO4
and IO13.<br class=""
style="margin: 0px; padding:
0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
</ul>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Change to 1.8V 16MB
flash chip (W25Q128FW?). As SDD_VDIO
is not exposed, add a simple
regulator 3.3V->1.8V for external
flash?<br class="" style="margin:
0px; padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">When burning e-fuses,
need to take care with 1.8V/3.3V
SDD_SDIO fuse - leave at 1.8V.<br
class="" style="margin: 0px;
padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Add capacitors for SD
CARD and external Flash, as per
Espressif example.<br class=""
style="margin: 0px; padding: 0px;">
<br class="" style="margin: 0px;
padding: 0px;">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">Increase size of
solder pad for big capacitors, and
USB connector, to make it stronger.<br
class="">
<br class="">
</li>
<li class="" style="font-family: 微软雅黑;
font-size: 14px; margin: 0px;
padding: 0px;">For the data lines of
circuit traces SDCARD, SPI bus,
external flash, take care to keep
away from power traces or other
sources of interference and keep the
traces as short as possible.</li>
</ol>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">The change to WROVER is a PITA
at this stage, but that 4MB PSRAM should
give us more headroom and the extra
bill-of-materials costs is just a couple
of US$.</div>
<div class=""><br class="">
</div>
<div class="">For the modem, we’re
double-checking the power (which seems ok,
but check to be sure), and changing
passive -> active antenna. At the
moment, it seems to be just a couple of
passive components soldered inline between
two easily accessible points. For existing
developer modems in the field, we’ll try
to make a simple upgrade kit
(passive->active) for GPS, and post
them out. If you don’t need GPS (such as
Roadster users), the modem boards are
functionally the same as the production
ones.</div>
<div class=""><br class="">
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; line-break:
after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Existing developer OVMS v3
boards (with WROOM-32 module) will
continue to be called v3.0. New production
OVMS v3 boards (with WROVER module) will
be called v3.1. We have conditional
compilation in the firmware, to switch the
pin assignments and whatever else is
required.</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px;
border: none; padding: 0px;" class="">
<div class=""><span style="font-family:
Menlo-Regular; font-size: 14px;"
class=""> Branch: refs/heads/for-v3.0</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Home: </span><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3"
style="font-family: Menlo-Regular;
font-size: 14px;" class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3</a><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Commit:
9504df70be78b6626970ec0ea53d2c2470e90afa</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> </span><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa"
style="font-family: Menlo-Regular;
font-size: 14px;" class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9504df70be78b6626970ec0ea53d2c2470e90afa</a><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Author:
Mark Webb-Johnson <</span><a
href="mailto:mark@webb-johnson.net"
style="font-family: Menlo-Regular;
font-size: 14px;" class=""
moz-do-not-send="true">mark@webb-johnson.net</a><span
style="font-family: Menlo-Regular;
font-size: 14px;" class="">></span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Date:
2018-01-10 (Wed, 10 Jan 2018)</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Changed
paths:</span><br style="font-family:
Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> M
vehicle/OVMS.V3/main/Kconfig</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> M
vehicle/OVMS.V3/main/ovms_peripherals.h</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Log
Message:</span><br style="font-family:
Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> -----------</span><br
style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class=""> Support
for OVMS hardware v3.1</span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class="">Converting developer v3.0
boards to v3.1 is not really feasible (a
skilled solderer could probably use a
16MB Analog Lamb WROOM-32+PSRAM module;
that would be a relatively simple
de-solder + re-solder of the module, a
not-so-simple re-arrange of the traces
for IO16->IO4 and IO17->IO13, and
disabling of external 16MB flash).
Anyway, those existing developer modules
should be fine to continue to use (just
without the extra PSRAM).</div>
</div>
<div class=""><br class="">
</div>
<div class="">We are today finalising the
circuit schematic and board layout for the
above, and building a couple of test
boards (with WROVER modules). I should
have one in about a week’s time (assuming
all the components are available). In that
time, we’ll finish the ESP IDF v3.0
support, and test late next week / over
next weekend (20th/21st Jan). Assuming no
problems, we should be able to give
factory the go-ahead to produce early the
week after.</div>
<div class=""><br class="">
</div>
<div class="">Given that timing, I doubt if
we are going to be able to get these
boards made before the Chinese New Year
holidays. Even if we can get them made,
FastTech distribution may not be able to
get them out during the holidays.
Manufacturing in China starts to close
down around the end of January / early
February this year. New Year itself is
mid-February. Anyway, we’ll get this all
finalised, payment and instruction to
start manufacturing in place, then do the
best we can and get these out available
during February. A big warning is going to
go with them that this is for early
adopters only, and firmware is changing on
a daily basis. Updating firmware via wifi
/ sd card should be fine.</div>
<div class=""><br class="">
</div>
<div class="">I’m seeing a light at the end
of a long dark tunnel.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
</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.teslaclub.hk" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.teslaclub.hk" class=""
moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/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.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>