<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Mark,</p>
<p>I just wanted to say thank you very much for all your efforts on
this. I can only imagine how much work goes into this, and I'm
sure the community of OVMS users is grateful.</p>
<p>I currently have an OVMS v2 installed in our KIA SoulEV and I'll
likely upgrade to OVMS v3 if there is additional functionality.</p>
<p>The cellular provider we're using here in Canada (Rogers) doesn't
have any definitive plans to kill 2G just yet, but moving to
Hologram.IO would be a no brainer in any case.</p>
<p>Thanks again,</p>
<p>Robert<br>
</p>
<br>
<div class="moz-cite-prefix">On 11/2/2016 9:36 PM, Mark Webb-Johnson
wrote:<br>
</div>
<blockquote
cite="mid:55564D53-BE6A-443C-B113-727D8C60DD45@openvehicles.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class=""><br class="">
</div>
<div class="">Firstly, an apology for the continued delays with
this. The IOT environment is changing so fast, and there are so
many amazingly capable choices appearing in the market, that it
is hard to select one and live with it for the coming years.
That said, we now (finally) have a solution that I think will
provide a fantastic platform for OVMS in the future, and meet
most of our goals.</div>
<div class=""><br class="">
</div>
<div class="">So, here’s the design outline.</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">MCU Platform<br class="">
<br class="">
I’ve obtained samples for, and tested, over a dozen MCU
platforms over the past 9 months. None have been perfect,
but one has come very very close. As many of you guessed, I
feel that the <a moz-do-not-send="true"
href="https://espressif.com/en/products/hardware/esp32/overview"
class="">ESP32 platform</a> has pretty much everything we
need and is the clear winner.<br class="">
<br class="">
a) Cost effective (MCU, bluetooth, wifi, plenty of RAM and
FLASH; all in a single module the size of a postage stamp).<br
class="">
b) Free-RTOS based operating system<br class="">
c) Over-the-air update support<br class="">
d) Open GNU based toolchain<br class="">
e) Great community support<br class="">
<br class="">
The main negative is that it only has a single on-board CAN
bus, and that has zero documentation at the moment. But it
has SPI and can interface to something like the MCP25625 to
give us up to 3 CAN buses. The other issue is that this is
so new that documentation is limited; although the
manufacturers are working hard on this, and helping us where
they can.<br class="">
<br class="">
So, from a platform point of view, that is what I am working
on. A motherboard of our own containing buck converter style
DC-DC conversion (high efficiency) from both 12V (vehicle)
and 5V (usb), a WROOM-32 ESP32 FCC/CE certified module,
SD-Card, USB port, OVMS ports, CAN circuitry, and two
expansion slots. Expect 16MB RAM, giving us about 4-6MB
maximum code size (based on the OTA scheme of one factory
firmware image, one running firmware image, and one
downloading firmware image). That base module will support
bluetooth and wifi connectivity. Cellular will be provided
by a plug-in module in an expansion slot, leaving one spare
expansion slot free.<br class="">
<br class="">
Low power modes will be built in to the design, from the
bottom up.<br class="">
<br class="">
I’m trying to get the cost of this right down. Base module
cheaper than OVMS v2. With the cellular option, around the
same price. A base OVMS v3 module could be used for CAN bus
reverse engineering work, data logging, etc, at a very very
competitive price.<br class="">
<br class="">
We’ve got prototypes for this running on breadboards
already, and we are about to start the board and casing
layout. I’ve also got a handful of ESP32 development boards
available if anybody wants to help out with base platform
code.<br class="">
<br class="">
</li>
<li class="">Cellular Connectivity<br class="">
<br class="">
The base module will have an expansion connector for
optional cellular connectivity. The idea is to make this
modular, so we can swap out modems if necessary.<br class="">
<br class="">
The issue with OVMS v1 and v2 has been cellular connectivity
plans. Everyone using a mix of prepaid SIMs, on a huge
number of different networks, and all of us having to deal
with topping-up and other hassles; the AT&T sunset of 2G
being a good example. We tried GeoSIM, but it is just too
expensive.<br class="">
<br class="">
A few years ago, I backed a kickstarter project called
‘konekt’. They were building a small cellular module, and
IOT cloud, very early on. What they have produced has turned
into two offerings: a) their cellular module with support
for their cloud, and b) a MVNO (mobile virtual network
operator) with very competitive data rates and worldwide
coverage. You can find them now at <a
moz-do-not-send="true" href="http://www.hologram.io"
class="">www.hologram.io</a>. I’ve been watching them
grow, and testing their SIMs, and have been very impressed.
It seems to be an amazing match for what OVMS needs.
Specifically:<br class="">
<br class="">
a) Simple SIM that we can add to every OVMS module going out
the door.<br class="">
b) Global activation (they use two zones, with most of the
world where OVMS is in the cheapest zone 1).<br class="">
c) Zone 1 pricing of about US$0.40/month basic upkeep, plus
US$0.60 - US$1.00 per MB of data. Zone 2 perhaps 20%+ more
expensive. A 3MB zone 1 plan is around US$2/month all in
(US$3/month in zone 2).<br class="">
d) Free inbound SMS. We can offer an option to put the
cellular modem to low-power sleep, and be woken up by an SMS
(from OVMS server) when an App connects. Free. Perfect for
vehicles like the Twizy.<br class="">
e) Simple API based console so we automate the accounting
side of things.<br class="">
f) Bi-directional SMS is available for normal SMS style
rates (free inbound, with outbound at about US$0.19/message,
plus US$1/month in USA if you want a fixed number).<br
class="">
<br class="">
Hologram has partnerships with multiple carriers for each
country. For example, in Hong Kong my car OVMS uses a
family-plan style multi-sim approach. I get four SIMs and
they all share the same data, call and sms plan. The one I
use is from a carrier called CSL. It works well, except in
front of my house or in my garage - where there is no
coverage. I pulled out that SIM and put in a hologram sim
(remembering to change the APN to “HOLOGRAM” before I did
it, of course). The Hologram sim immediately connected to
CSL and everything worked smoothly. Then I moved the car to
the front of the garage. I saw the network disconnect from "<span style="white-space: pre-wrap;" class="">Hong Kong CSL Limited” (carrier lost) and reconnect to "SmarTone Mobile Com Ltd”. Then I reversed into the garage, and saw the connection switch to "Hutchison Hong Kong”. On my drive to work I took a northerly route near china and got a switch to "China Mobile HongKong Comp Ltd”. The point is that I’m paying one data plan, but able to take advantage of 4 different networks.</span><br
class="">
<br class="">
The plan is to put these SIMs in every OVMS module from the
factory, and to offer a quick and simple provisioning
system. Other SIMs could of course still be used, but this
would be the default approach.<br class="">
<br class="">
Hologram SIMs are also available today to OVMS v2 users in
USA (particularly those about to be stranded by AT&T).
Hologram supports the T-mobile network in USA. This should
give us some breathing room to give us time to get OVMS v3
out, without rushing things but getting things right as a
base platform going forward.<br class="">
<br class="">
</li>
<li class="">Protocol<br class="">
<br class="">
When OVMS v1 was designed, we rolled our own protocol out.
This was far from ideal, but it was so early in the IOT
world that there wasn’t anything else out there lightweight
and mature enough to be used. Today, things have changed and
there is a huge selection to choose from. That said, there
is one clear winner of all these choices. The IOT world is
varied, but the one clear solution that has appeared is MPPT
(<a moz-do-not-send="true"
href="https://en.wikipedia.org/wiki/MQTT" class="">Message
Queuing Telemetry Transport</a>). The decision as to which
hardware platform to choose has been incredibly hard. By
comparison, the choice of protocol is a ‘no brainer’ - OVMS
v3 will use MQTT. Specifically, MQTT v3.1.1 over SSL over
TCP/IP.<br class="">
<br class="">
The protocol itself is very lightweight, very flexible, and
offers a simple but powerful publish/subscribe model. The
big advantage of this is that it is an open protocol with
many clients and applications supporting it. Your house can
subscribe to vehicle events just as easily as your cellphone
app. Relatively easy to do “Hey siri set my car temperature
to 20 celcius” style actions, as well as hook into home
automation, etc.<br class="">
<br class="">
</li>
<li class="">Server<br class="">
<br class="">
I really like the Amazon approach to MQTT, but consider that
too proprietary and hard to integrate to others. We’ll
probably end up just running our own Mosquitto MQTT server
on the same machine as OVMS v2 currently runs on, but the
protocol is open and easy to choose from the dozens of
implementations out there.<br class="">
<br class="">
</li>
<li class="">Apps<br class="">
<br class="">
Existing Apps should continue to work via a bridged OVMS v2
server. Longer-term, it will not be hard to change the Apps
to switch to MQTT protocol (presumably over websockets).<br
class="">
</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">So, that is the plan. I hate to give timelines
(especially when it depends so much on the ESP32 Expressif guys
getting their documentation out, and WROOM-32 modules available
in large quantities), so all I can say is it is happening ‘now’.
I have the development environment in place, and am building the
framework support for OVMS using the development boards I have.
Also working with the guys in China to get the OVMS v3 hardware
design finalised. I hope to be able to release what I have so
far to github before the end of November.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><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>