<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div>One way of doing this that I was thinking of:<div><br></div><div>We already have a protocol for talking apps<->server<->car. On the car side, at the moment it uses that protocol in just one place (calling car->server).</div><div><br></div><div>In the v3, we know that we would like to be able to connect over bluetooth / wifi, but why invent something new? My idea was to just use the same protocol, with the difference being that the car module would allow many connections (server via wifi, server via GSM, apps via wifi, apps via bluetooth, etc). Exactly the same protocol, just multiple communication channels open at the same time.</div><div><br></div><div>For the smartphone apps, they could either connect directly via bluetooth/wifi or indirectly via the server.</div><div><br></div><div>For an in-car display, we could either use bluetooth (something like this <a href="http://www.fasttech.com/products/0/10004051/1292002-ti-cc2540-cc2541-bluetooth-4-0-ble-2540-2541">http://www.fasttech.com/products/0/10004051/1292002-ti-cc2540-cc2541-bluetooth-4-0-ble-2540-2541</a>) or an async connection. My preference is bluetooth, as that means all the display needs is power. But, if we do it that way, there would need to be some intelligence in the display. Something to drive the display and receive user input, as well as work the protocol back to the OVMS module.</div><div><br></div><div>That does provide a nice separation of complexity - all the user interface stuff is kept out of the core OVMS.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 17 Jun, 2014, at 4:24 pm, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    Regarding the display, only smartphones can possibly do the job. I
    got quite a lot comments from users saying it's good the OVMS can be
    used without a smartphone. Also I personally would like to have a
    dedicated fixed mounted display for the additional live info from
    the OVMS -- in fact that's why the Twizplay (<a class="moz-txt-link-abbreviated" href="http://www.twizplay.de/">www.twizplay.de</a>) is so
    appealing.<br>
    <br>
    Btw: the Twizplay uses an EA DOGM128-6 LCD module which can be
    controlled via SPI and costs around 11 Euro (1 pc). There's a touch
    panel option for this display available, not sure about getting the
    touch input via SPI though.<br>
    <br>
    For the Samsung NX300, I thought that does 2-3 hours with active
    camera + display + wifi. But I'm not certain about that, just read
    some consumer tests because of the hacking possibilities :-)<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 17.06.2014 07:39, schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote cite="mid:79B56088-4C14-4469-97B2-CB0460F6BCE7@webb-johnson.net" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div><br>
      </div>
      What I'm wondering is how valuable it would be to have a device in
      the car capable of:
      <div><br>
      </div>
      <div>
        <ul class="MailOutline">
          <li>logging can bus traffic to SD card</li>
          <li>logging can bus traffic remotely (over wifi, etc)</li>
          <li>Issuing CAN bus requests remotely</li>
          <li>Receiving firmware updates remotely</li>
        </ul>
      </div>
      <div><br>
      </div>
      <div>And, what if that device was OVMS itself?</div>
      <div><br>
      </div>
      <div>I know that when I am developing for OVMS, I spend a
        tremendous amount of time switching between OVMS and a CAN bus
        logger. Also, removing OVMS to program it, and plugging it back
        in again. My lousy cellular reception at home doesn't help
        (although has probably helped OVMS deal with lousy cellular
        reception situations quite well). My ideal device would be in
        the car always. It would allow me to log all traffic (or
        selected traffic with an easy start/stop/trigger), and remotely
        download those logs. It would allow me to make a change to the
        firmware, remotely, and see the impact. The issue would be doing
        all that while keeping security high as well as power
        consumption and price low.</div>
      <div><br>
      </div>
      <div>Regarding the display, could this be bluetooth to an
        Android/iPhone? Or, do we need a physical display? With most of
        the device nowadays, adding a directly attached display is not
        too hard (and not too expensive) so long as it is on ribbon
        cable less than perhaps 6" away. But, if a remote display is
        required, that tends to drive up the price dramatically. It
        seems that the CPUs nowadays can directly control a display.
        But, if you want to run a remote display than you have to use
        UART (or something like that) and then run a separate CPU in the
        display itself.</div>
      <div><br>
      </div>
      <div>Regards, Mark.</div>
      <div><br>
        <div>
          <div>On 17 Jun, 2014, at 1:20 pm, Tom Saxton <<a moz-do-not-send="true" href="mailto:tom@idleloop.com">tom@idleloop.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">I think it's incredibly valuable to
            keep the $100 price point.<br>
            <br>
            It seems to me that the hard part of adding support for
            other vehicles is<br>
            figuring out the CAN bus codes. That's ideally done with
            hardware<br>
            optimized for that task, which is probably not the OVMS
            device. There's so<br>
            much framework already in place that once you know how to
            read values and<br>
            issue commands, getting that into OVMS isn't that hard.<br>
            <br>
            Making OVMS more expensive to better serve the developer
            community will<br>
            make it a harder buying decision for end users. Hopefully,
            we'll<br>
            eventually have thousands of users for every developer.<br>
            <br>
            It would, of course, be an improvement to make firmware
            updates easier for<br>
            end users, that is an important issue.<br>
            <br>
            I would like to see some sort of display, either on the box
            or remote, so<br>
            I can see SOC in the car without using a phone.<br>
            <br>
              Tom<br>
            <br>
            -----Original Message-----<br>
            From: Lee Howard <<a moz-do-not-send="true" href="mailto:lee.howard@mainpine.com">lee.howard@mainpine.com</a>><br>
            Reply-To: OVMS Developers <<a moz-do-not-send="true" href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br>
            Date: Monday, June 16, 2014 at 11:55 AM<br>
            To: OVMS Developers <<a moz-do-not-send="true" href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br>
            Subject: Re: [Ovmsdev] OVMS v3<br>
            <br>
            <blockquote type="cite">I want to say "amen" to both Kevin's
              and Matt's comments.<br>
              <br>
              Right now it's really only fully useful for Roadster (and
              Model S)<br>
              owners.  Volt/Ampera owners (and Leaf and Twizzy?) can
              remotely get a<br>
              limited amount of incredibly useful information (like
              SOC), but the<br>
              degree of control that the Roaster owners have isn't there
              (locking,<br>
              unlocking, pre-heating/cooling, etc.).<br>
              <br>
              I intend to develop-in some of these features over time -
              at least for<br>
              Volt/Ampera, and the only thing that has me not yet doing
              that is my<br>
              need to get up-to-speed on the development environment and
              methods.<br>
              <br>
              However, even if all of the features available to Roadster
              owners were<br>
              there for everyone, there is still so much more potential,
              as Kevin and<br>
              Matt have said.<br>
              <br>
              If something isn't done to enable the expanded use then
              OVMS will<br>
              continually only cater to a limited audience: one that
              wants access to<br>
              various remote-control and remote-tracking features, but
              with limited<br>
              local (in-car) usability and limited developer appeal.<br>
              <br>
              Thanks,<br>
              <br>
              Lee.<br>
              <br>
              -- <br>
              *Lee Howard*<br>
              *Mainpine, Inc. Chief Technology Officer*<br>
              Tel: +1 866 363 6680 | Fax: +1 360 462 8160<br>
              <a moz-do-not-send="true" href="mailto:lee.howard@mainpine.com">lee.howard@mainpine.com</a>
              | <a moz-do-not-send="true" href="http://www.mainpine.com/">www.mainpine.com</a><br>
              _______________________________________________<br>
              OvmsDev mailing list<br>
              <a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
              <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
              <br>
            </blockquote>
            <br>
            <br>
            _______________________________________________<br>
            OvmsDev mailing list<br>
            <a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
            <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
          </blockquote>
        </div>
        <br>
      </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>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
  </div>

<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>