<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Michael,<div class=""><br class=""></div><div class="">I very much hope we can get FCC and CE approval for OVMS v3. We are certainly bearing it in mind in the design.</div><div class=""><br class=""></div><div class="">But, for day #1, the first batch of hardware modules, I somehow doubt that it will be approvable, though. While Espressif (the makers of ESP32) have CE and FCC certification for their chip, a modular-certified version isn’t yet available. All the development modules we have so far are not even covered by metal shielding. They have committed to doing this, and we are designing around it, but we need a modular certification otherwise the radio-testing costs would be too high and triple the pricing of the modules (at least).</div><div class=""><br class=""></div><div class="">We need this:</div><div class=""><br class=""></div><div class=""><img apple-inline="no" id="0ED4C63A-269D-41EC-BCF0-EFA59FEFB4E1" height="102" width="109" apple-width="yes" apple-height="yes" src="cid:E65D4DEA-EF43-430A-8F2F-35B84E217B51" class=""></div><div class=""><br class=""></div><div class="">not this:</div><div class=""><br class=""></div><div class=""><img apple-inline="no" id="F76D8A11-EE0C-4617-A712-3E13082C294E" height="102" width="109" apple-width="yes" apple-height="yes" src="cid:93736E18-379D-4E2A-BA2D-C764D827AFF2" class=""></div><div class=""><br class=""></div><div class="">When the modular certified WROOM-32 is available, we will migrate to it, then go through the steps of certification for the rest of our board. The module footprint and circuit layout it the same. It might even be ready before we are, but I am not that confident.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 4 Nov 2016, at 5:28 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    Mark,<br class="">
    <br class="">
    thanks for the detailed update, looks all very well.<br class="">
    <br class="">
    Regarding casing layout, please don't forget the European Union EM
    approvability... sorry for nagging, but an OVMS that's actually
    legal at least on the hardware side would be very nice :)<br class="">
    <br class="">
    I'll see if I can help with the platform base code.<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Am 03.11.2016 um 02:36 schrieb Mark
      Webb-Johnson:<br class="">
    </div>
    <blockquote cite="mid:55564D53-BE6A-443C-B113-727D8C60DD45@openvehicles.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252" class="">
      <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 class="">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br class="">
      <pre wrap="" class="">_______________________________________________
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 class="">
    <pre class="moz-signature" cols="72">-- 
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.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>