<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; ">You do make a valid point about the sub-d 15 and sub d-9. When I installed OVMS in the Twizy, I got around it by using the hole already present for the ODB Port to pass the cable through. But yes, smaller connectors are easier to route. <div><br></div><div>Another thought, spurred on by someone who had a fault on their Twizy in the UK yesterday: backup power. </div><div><br></div><div>Is there any way the next gen hardware could have some form of backup, so that it could capture and send any hardware faults as the car is giving up the ghost? Normally of course, the 12V system stays live even if there's something else which goes wrong. But in the case of total failure, a short backup supply of <60 seconds could help gather important data for troubleshooting when things DO go wrong? </div><div><br></div><div>Nikki.</div><div><br></div><div><div><div>On 11 Apr 2013, at 16:05, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael, Nikki,<div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">or a good sub-d 9</div></blockquote></div></blockquote></div><div><br></div><div>Or sub-d 15? Just a bit klunky and hard to route through vehicle areas. I guess if it goes into the back of the box it is fine.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">For the communication between the two units you can use i2c or SPI.</div></blockquote></div></blockquote><br></div><div>I'm a little worried about cable length and interference. What is limit for i2c? Async may be simpler (with some protocol on top for error-checking).</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">- Potential free switch output (Relais, one or more) eventually in a separate box, as an add on.</div></blockquote></div></blockquote></div><div><br></div><div>My suggestion was to include an expansion port (diagnostics, ICSP, plus A/D, digital I/O and async). I think it is better to put the relays in a separate box. It would be nice to have home-control (zigbee/whatever), but that is another mess with so many competing standards and hassle. With bluetooth, wifi and 3G I guess we'll be ok.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Also, there needs to be a way we can have a programming port easily accessible for the portion of the hardware hidden. </div></blockquote></div><div><br></div><div>The incremental programming can be via USB. So, a normal usb extender can be used if necessary (or just a usb cable).</div><div><br></div><div>We'll also have ICSP (6 pin?), but that shouldn't be needed for day-to-day.</div><div><br></div><div>I've been using these for prototyping:</div><div><br></div><div><div style="margin: 0px; font-size: 12px; "><span><400x102xUBW32_v24_SparkFun_sm.JPG.pagespeed.ic.NkWMNm0oSs.jpg></span></div></div><div><div style="margin: 0px; font-size: 12px; "><div style="margin: 0px; "><span><09713-01b.jpeg></span></div></div></div><div style="margin: 0px; font-size: 12px; "><br></div><div style="margin: 0px; font-size: 12px; ">based on a project here: <a href="http://www.schmalzhaus.com/UBW32/">http://www.schmalzhaus.com/UBW32/</a> - but there are other ways to do it. Microchip even have one. I'm thinking the SDCARD may be easier (just put the firmware on the SDCARD, switch it on and it will update), but the cpu has excellent usb support.</div><div style="margin: 0px; font-size: 12px; "><br></div><div style="margin: 0px; font-size: 12px; "><blockquote type="cite" style="font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">When you start thinking for the display unit, ->  howto mounting this to the dashboard or window.</div></blockquote></div></blockquote><br></div><div style="margin: 0px; font-size: 12px; ">At the moment, I'm just playing with stuff like this:</div><div style="margin: 0px; font-size: 12px; "><br></div><div style="margin: 0px; font-size: 12px; "><div style="margin: 0px; "><div style="margin: 0px; "><span><413mYL-A2kL._SX300_.jpg></span><span><41J-KCMFJWL._SY300_.jpg></span></div><div style="margin: 0px; "><br></div><div style="margin: 0px; ">Cheap cheap cheap, but surprisingly good.</div><div style="margin: 0px; "><br></div><div style="margin: 0px; ">But, there are also ones like this:</div><div style="margin: 0px; "><br></div><div style="margin: 0px; "><div style="margin: 0px; "><span><43or-35-tftlcd-display-windscreen-model-and-ccd-camera-315.jpg></span><span><url.jpeg></span></div><div style="margin: 0px; "><br></div><div style="margin: 0px; ">We don't have the quantity for moulding ourselves, so we'll just have to find some end-run of cases and modify for the cable we need. Not too bad if all they have to do is punch a hole. The good news is that there are a lot of these GPS units / rearview monitors in Shenzhen (just across the border) so I don't think it will be too hard to find someone to do an end-run for us.</div></div></div><div style="margin: 0px; "><br></div><div style="margin: 0px; ">Regards, Mark.</div></div><div><br></div><div><div><div>On 11 Apr, 2013, at 5:18 PM, Nikki Gordon-Bloomfield <<a href="mailto:nikki@littlecollie.com">nikki@littlecollie.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Agreed with Michael!<div><br></div><div>Relays are very important, as some car owners (especially those with conversions) will want to use relays to control the timing of charging cycles etc.  </div><div><br></div><div>I also like the idea of hiding the main unit and then having a smaller display. It should make the system look more professional, and give EV owners and builders an option to what they want. </div><div><br></div><div>Also, there needs to be a way we can have a programming port easily accessible for the portion of the hardware hidden. This will make it easier to upload software. Maybe a USB extension or DB9? </div><div><br></div><div>Nikki. </div><div><br></div><div><br></div><div><br><div><div><div>On 11 Apr 2013, at 10:02, Michael Jochum <<a href="mailto:mikeljo@mac.com">mikeljo@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br><div><div>Am 11.04.2013 um 04:43 schrieb Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>An optional second display (with second CPU) is probably the cleanest way. We would need to provide Power + Ground (2 or 3 wires) and serial (2 or 4 wires) - so that would be worst case 7 wires. Perhaps a RJ45 cable would be flexible - allowing us to just use CAT5 cables which are available in so many lengths and easy to connect/disconnect? If we use the CAN, then we need 2 more wires per CAN bus.</div></div></blockquote><div><br></div>or a good sub-d 9. It is better for daily use. For one time installation RJ45 is ok. But when you remove and connect every day they are not very handy.</div><div>For the communication between the two units you can use i2c or SPI. It is a question of the implementation. What is fast, easy, secure. Secure means that the data that was receive are the same that was send. CRC for example.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>The optional display would perhaps be the best solution (rather than putting it all in one box). The combination of the two would be more expensive than one, but it would offer more flexibility (and the display-less version would be cheaper). The main OVMS unit could remain hidden in the car, and for those who want the display, they just add it on. OVMS would work with either the optional display or the smartphone via bluetooth display (or both).</div></div></blockquote><div><br></div>I think this is a great solution. So anybody can get what he want. Buy first only the main unit. If he is satisfied (certain he will!) and want more then he can add the display unit.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>What do people think? Is this a good compromise?</div><div><br></div><div><ul class="MailOutline"><li>Main OVMS box</li><ul><li>2x CAN ports</li><li>1x OBDII port</li><li>BT (BLE)</li><li>Wifi</li><li>3G</li><li>GPS</li></ul><li>Optional display box</li><ul><li>4.3" Display with touch</li><li>Quick disconnect</li></ul><li>Optional cellphone display</li><ul><li>via BLE</li></ul></ul></div></div></blockquote><div><br></div>Thats what i'm thinking for. :-)</div><div><br></div><div>Oh, i think i forget one point:</div><div>- Potential free switch output (Relais, one or more) eventually in a separate box, as an add on.</div><div>You remember that there was a question about this.</div><div>But i think this is only an option of an option.............</div><div><br></div><div>When you start thinking for the display unit, ->  howto mounting this to the dashboard or window.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Regarding the 'raw' mode - that was my surprise! Yes it should be possible to just software switch the OBDII controller chip into the serial / bluetooth port - both are just serial async - and then Torque/whatever should just work. But that would mean OVMS couldn't use the OBDII port while raw mode was in use. We could also do a 'shared' mode - but that would be a lot more work (to fully decode the OBDII controller protocol and support shared PID polling, initialisation and control).</div></div></blockquote><div><br></div>Oh, i can surprise you. ;-)</div><div>I think it is no problem when in raw mode that OVMS could not use the Port. This mode is for logging with external Tools, Hardware etc. only. And only for a short time.</div><div>Or, you implement a mode that the OVMS do like a "ELM" interface. I mean it work like this. It acts like a CAN2BT interface with AT commands.</div><div>And so anybody can use the App he want on the Smartphone he want over BLE. </div><div><br></div><div>Bye</div><div>michael J.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Regards, Mark.<div><br><div><div>On 10 Apr, 2013, at 5:01 PM, Michael Jochum wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>my two cents:</div><div>- minimum 2 CAN Ports</div><div>- BT</div><div>- Wifi</div><div>- 3G</div><div>- GPS</div><div>- Display with Touch (eventually in an separate case, if possible)</div><div>- as an option use of the Smartphone as Display. But i prefer that the Module has its own</div><div><br></div><div>I know the Problems with the BT Stack on the iDevices. In the moment we can use the BT Stack, but what happen in the future?</div><div>We talk about a non jailbreak device!</div><div><br></div><div>When we can separate the Display from the main unit, it is possible to cover the main unit. And with a "quick" release for the display it can secure in your pocket when you leave the car. Nice for twizzy i think. The second is that when we have more than one CAN Bus attached there are a lot of cables to the unit. Bringing this to a device mounted on the dash in a viewable area dont look good.</div><div>I dont talk about a BT (or XBee) connection between the main unit and the display!!!!!! I mean a cable with a handy connector.</div><div><br></div><div>2 CPUs are nice ;-)</div><div>Logging with GPS to an SD Card, with automatic transfer to my Homeserver (or the "Cloud") when the module connects to known Wifi Network(s) will be GREAT.</div><div><br></div><div>Could it be possible to switch the module in "raw" mode. So that the CAN Stream is available at the BT. So it can use as an "ELM" (or so) interface. With the same commands like a "standard" CAN-BT device.</div><div>With the possibility to switch between the different CAN Buses. I think i remember you wrote something about this before!?</div><div><br></div><div>Bye</div><div>Michael J.</div><div><br></div><div><br><div><div>Am 10.04.2013 um 04:21 schrieb Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Michael, Nikki, Kevin, etc,<div><br></div><div>The reason for the display/touchpad is twofold:</div><div><br></div><div><ol class="MailOutline"><li>Real-time display of vehicle information (0-60 times, sensors, etc)</li><li>Initial setup and monitoring of the OVMS module (avoiding SMS and making troubleshooting much easier)</li></ol></div><div><br></div><div>The display does add complexity+cost, increases theft worries, and is a hassle.</div><div><br></div><div>I've previously kept away from using a smartphone as a display for a few reasons:</div><div><br></div><div><ul class="MailOutline"><li>The smartphone runs hot</li><li>It is not elegant</li><li>Bluetooth is a 'bag of hurt' on Apple</li></ul></div><div><br></div><div>To use a bluetooth v2 (the standard, with excellent support) module with Apple devices requires the module to be a part of the MFI (Made For iPhone) program. That is a nightmare. Now, more recent devices (iPhone 4S and above, plus very modern Android devices) support bluetooth v4 (BLE) and Apple _supposedly_ has relaxed the rules with that - so long as the functionality is not core (ie; we add it to the existing ovms apps, and not having a device won't stop the app from working), we can probably get it through (but this is at the whim of Apple's approval process). BLE (v4) modules are damn expensive - but significantly less expensive than a 4.3" LCD display with touchpad :-)</div><div><br></div><div>Others use WIFI as a way of bypassing Apple's restrictions, but that is nasty. You have to set the device as your wifi access point, and you then lose Internet connectivity.</div><div><br></div><div>If we went the use-the-smartphone-as-the-display route, that would reduce costs and complexity (even with BLE). We could do without the second CPU (limiting us to 2xCAN ports and 1xOBDII). I like Michael's idea of exposing some A/D and/or digital I/O ports that could be used to support other vehicle types. The displays are certainly easier to program and look a lot better.</div><div><br></div><div>We've also got 6 async ports on the PIC32MX795, so we could also expose the same display protocol that the smartphone apps would use via that - perhaps for a plug-in add-on display option?</div><div><br></div><div>Going that route would result in:</div><div><br></div><div><ul class="MailOutline"><li>1x PIC32MX795 cpu for 2xCAN ports, 1xOBD-II main control tasks (always on)</li><li>SD-Card</li><li>Wifi</li><li>Bluetooth (BLE)</li><li>3G+GPS</li></ul></div><div><br></div><div>I/O exposed would be:</div><div><br></div><div><ul class="MailOutline"><li>Pure OBDII (via standard DB9) connector</li><li>OVMS standard DB9 connector (extended for second CAN bus)</li><li>OVMS expansion connector (diagnostics, ICSP, plus A/D, digital I/O and async)</li><li>USB (for firmware update)</li><li>GSM antenna</li><li>GPS antenna</li><li>SD-Card</li><li>(SIM slot internal is probably still best, to avoid theft concerns with the SIM)</li></ul></div><div><br></div><div>Enclosure size would probably have to be bigger than the current one - perhaps the same width/height, just increase the length. I am a little concerned about Wifi and Bluetooth antennas - putting them on the motherboard modules is by far the easiest, but that won't work with a metal case.</div><div><br></div><div>Cost probably US$150 - US$170 range (bluetooth, wifi and 3G being responsible for this).</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 10 Apr, 2013, at 2:30 AM, Michael Balzer 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">
    <br>
    <div class="moz-cite-prefix">Am 09.04.2013 12:14, schrieb Nikki
      Gordon-Bloomfield:<br>
    </div>
    <blockquote cite="mid:39FB1010-07B7-4477-B7D0-BFD536947218@littlecollie.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>Using the Bluetooth serial connection, it should be possible
        for users to implement a GUI with existing smart phone
        technology. <br>
      </div>
    </blockquote>
    <br>
    Oh I forgot: yes! That's the idea behind adding Bluetooth to the
    Twizplay, they could omit the LCD and use an App as the display
    device.<br>
    <br>
    That's really a good option I think! Would also keep cost down.<br>
    <br>
    <blockquote cite="mid:39FB1010-07B7-4477-B7D0-BFD536947218@littlecollie.com" type="cite">For Twizy owners that's an added bonus. There are no
      door locks, and getting in is as simple as reaching inside and
      pulling the door handle.<br>
    </blockquote>
    ...that's why most Twizplay owners currently use a special quick
    lock mount just for the Twizplay -- so you need both a mount for the
    display and one for your mobile phone... bad.<br>
    <br>
    <blockquote cite="mid:39FB1010-07B7-4477-B7D0-BFD536947218@littlecollie.com" type="cite">
      <div>Moving forward, I think it'd be great if someone in the
        self-build community (You may have to work with someone else)
        could produce a raw "battery pack to OVMS" module, which enables
        those with converted or custom EVs to use the OVMS system using
        a standard set of protocols and Can messaging -- or perhaps
        direct using an add-on IO device? <br>
      </div>
    </blockquote>
    That would make the OVMS an option for Ebike and Escooter drivers as
    well. I've got one of these:
    <a class="moz-txt-link-freetext" href="http://www.emco-elektroroller.de/elektroroller/novum.html">http://www.emco-elektroroller.de/elektroroller/novum.html</a><br>
    <br>
    ...just a simple chinese scooter, it doesn't have any data port, and
    it's only display is an analog voltage meter for the overall battery
    voltage -- you have to guess the SOC based on how deep the voltage
    drops under load.<br>
    <br>
    The most simple solution would be to provide two analog I/O ports to
    feed pack voltage and current (measured as voltage difference on a
    shunt) into the OVMS. The A/D conversion should be fast enough to
    provide at least 10 ms resolution, so we can implement an Ah counter
    in software. Also some digital I/O ports should be available to
    measure the distance driven (by a reed sensor mounted to a tyre) and
    maybe record some other system status.<br>
    <br>
    So, basically the same as available solutions like the "Cycle
    Analyst" or the "WattsUp" do, but with the added OVMS coolness.<br>
    <br>
    <br>
    Regards,<br>
    Michael<br>
    <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><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div>_______________________________________________<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>