<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 12px; font-family: Helvetica, sans-serif;"><div><div><div>Just to be clear the EVTV CAN KIT retails at 149 USD and includes an Arduino Due board, dual channel CAN bus shield, and DB-9 to J1962 Type A ODBII cable;</div><div><br></div><div><a href="http://store.evtv.me/proddetail.php?prod=ArduinoDueCANBUS&cat=23">http://store.evtv.me/proddetail.php?prod=ArduinoDueCANBUS&cat=23</a></div><div><br></div><div>This is by no means a OVMS replacement as it stands but it does give some idea of how little the base hardware should cost especially when you consider that EVTV does not strive to be the cheapest in the market by any means.</div><div><br></div><div>In an ideal world I would like to see a family of hardware products that can scale up or down to meet the requirements of OVMS users (both power and basic) as well as those using GEVCU, CAN-KIT, JLD505, and future products. My motivation is to get developers using the same software platform and libraries because this is where we need the effort… the hardware is trivial in comparison.</div><div><br></div><div><table id="Table_01" width="661" height="185" border="0" cellpadding="0" cellspacing="0" style="font-family: Times; orphans: 2; widows: 2;"><tbody><tr><td width="1" rowspan="2" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><img src="http://www.zerocarbonworld.org/images/email-signatures_03.gif" width="1" height="158" alt=""></td><td width="136" height="81" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><img src="http://www.zerocarbonworld.org/images/logo.png" width="124" height="60" alt=""></td><td width="524" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><span style="font-weight: bold; color: rgb(118, 118, 118); font-size: 13px; ">Kevin Sharpe | Founder & Chair of Trustees</span><br><div style="height: 8px; font-size: 1px; "></div><span style="color: rgb(118, 118, 118); font-size: 11px; ">Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld</span><br><div style="height: 8px; font-size: 1px; "></div><span style="font-size: 11px; "><a href="mailto:kevin.sharpe@zerocarbonworld.org" style="color: rgb(2, 112, 210); ">kevin.sharpe@zerocarbonworld.org </a>| <a href="http://www.zerocarbonworld.org/" style="color: rgb(2, 112, 210); ">www.zerocarbonworld.org</a> | <a href="http://twitter.com/ZCWcharlie" style="color: rgb(2, 112, 210); ">twitter.com/zerocarbonworld</a></span></td></tr><tr><td colspan="2" valign="top" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><img src="http://www.zerocarbonworld.org/images/email-signatures_06.png" width="653" height="49" alt=""><br><span style="font-weight: bold; color: rgb(118, 118, 118); font-size: 11px; ">Zero Carbon World is a UK Registered Charity #1141347</span></td></tr></tbody></table></div></div></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>><br><span style="font-weight:bold">Reply-To: </span> OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br><span style="font-weight:bold">Date: </span> Wednesday, 1 October 2014 12:40<br><span style="font-weight:bold">To: </span> OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br><span style="font-weight:bold">Subject: </span> Re: [Ovmsdev] OVMS v3<br></div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto"><div>Kevin, Colin,</div><div><br></div><div>Last we discussed this, didn't we come to the conclusion that there wasn't enough overlap between the two projects? Different goals, and most importantly, requirements. I am also concerned about the US$600 cost of the gevcu (without stuff like bluetooth, GSM and GPS which we need) - I don't think people are going to pay that much for a telematics module.<br><br>Or, have things changed?</div><div><br>Regards, Mark</div><div><br>On 1 Oct, 2014, at 7:07 pm, Kevin Sharpe <<a href="mailto:kevin.sharpe@zerocarbonworld.org">kevin.sharpe@zerocarbonworld.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div><div>It’s been interesting to watch the GEVCU development and the inevitable move to a more robust hardware platform which will be based on the Cinch Enclosure and connector (version 6). Something many people wanted at the start of the project.</div><div><br></div><div>IMO we need a robust hardware platform and the more we can focus software developers on a single platform the better for us all… my vote is hardware that’s compatible with GEVCU and the amazing libraries that exist today (including Colin’s excellent CAN library).</div><div><br></div><div><br></div><div><table id="Table_01" width="661" height="185" border="0" cellpadding="0" cellspacing="0" style="font-family: Times; orphans: 2; widows: 2;"><tbody><tr><td width="1" rowspan="2" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><img src="http://www.zerocarbonworld.org/images/email-signatures_03.gif" width="1" height="158" alt=""></td><td width="136" height="81" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><img src="http://www.zerocarbonworld.org/images/logo.png" width="124" height="60" alt=""></td><td width="524" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><span style="font-weight: bold; color: rgb(118, 118, 118); font-size: 13px; ">Kevin Sharpe | Founder & Chair of Trustees</span><br><div style="height: 8px; font-size: 1px; "></div><span style="color: rgb(118, 118, 118); font-size: 11px; ">Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld</span><br><div style="height: 8px; font-size: 1px; "></div><span style="font-size: 11px; "><a href="mailto:kevin.sharpe@zerocarbonworld.org" style="color: rgb(2, 112, 210); ">kevin.sharpe@zerocarbonworld.org </a>| <a href="http://www.zerocarbonworld.org/" style="color: rgb(2, 112, 210); ">www.zerocarbonworld.org</a> | <a href="http://twitter.com/ZCWcharlie" style="color: rgb(2, 112, 210); ">twitter.com/zerocarbonworld</a></span></td></tr><tr><td colspan="2" valign="top" style="font-family: Arial, Helvetica, sans-serif; color: rgb(2, 112, 210); "><img src="http://www.zerocarbonworld.org/images/email-signatures_06.png" width="653" height="49" alt=""><br><span style="font-weight: bold; color: rgb(118, 118, 118); font-size: 11px; ">Zero Carbon World is a UK Registered Charity #1141347</span></td></tr></tbody></table></div></div></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Collin Kidder <<a href="mailto:collink@kkmfg.com">collink@kkmfg.com</a>><br><span style="font-weight:bold">Reply-To: </span> OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br><span style="font-weight:bold">Date: </span> Tuesday, 30 September 2014 15:53<br><span style="font-weight:bold">To: </span> OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br><span style="font-weight:bold">Subject: </span> Re: [Ovmsdev] OVMS v3<br></div><div><br></div><div dir="ltr">I haven't really been involved with your OVMS project but I have continued to follow it with interest. I really like what you're doing. With the GEVCU project we went through much the same discussion you're having. We obviously settled on using the Arduino Due (eventually rolling our own board based on the Cortex M3 from the Due). The MBed has many similarities to the Arduino Due hardware-wise but uses a totally different development environment and library.<div><br></div><div>Ultimately I think you are making the right choice. It's very tempting to see something like the BeagleBone Black and want to go that route. But, development of code for something like the BBB is much more complicated unless you write it all in Python. LINUX is awesome on the desktop but I'm not convinced that it is worth the trouble for small embedded projects. Dealing with the complications that linux brings will just make the project more complex and difficult to jump into.</div><div><br></div><div>I know of other people using the MBED platform for vehicle use and it seems to be going well for them. I don't see anything really wrong with MBED and I think it will serve your uses very well. In my view going with the MBED platform would serve you well and propel your project into the future.</div><div><br></div><div>-Collin Kidder<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 10:34 AM, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>And the winner is (or at least who I think the winner should be):<div><br></div><div><u><b>MBED (and probably Freescale </b></u><b><u>K64F variant)</u></b></div><div><u><b><br></b></u></div><div><div style="margin:0px;font-size:12px"><unknown.jpg></div></div><div><div><div><br></div><div>Firstly, hats off to Mastro for pointing this out last year. Back then, I didn’t think much of it - it had some good points, but I am very wary of cloud projects, and closed source cloud terrifies me. But, in the past year, the project has come so far, and actually using the hardware left me very impressed.</div><div><br></div><div>I think our decision comes down to two choices:</div><div><br></div><div><ol><li>A Linux base, probably compute-module style, with Megabytes of RAM, Gigabytes of Flash, incredible flexibility but a challenge to keep power consumption down.</li><li>An embedded base, with hundreds of Kilobytes of RAM, Megabytes of Flash, and all the complexities that go along with embedded systems</li></ol></div><div><br></div><div>For me, the MBED architecture now offers a viable compromise between the two. The latest M4 processors give enough flash space (10 times what we have in our OVMS v2 hardware CPU), and RAM (64 times what we have in our OVMS v2 hardware CPU), that the limitation are lifted. More importantly, drag-and-drop programming means that even if flash space became an issue, we could always just offer different firmware for different vehicles - but this time with re-flashing being simply plugging the module into the PC and drag-and-drop the new firmware file in place. Think of it as like having a PICKIT built onto the board, but with the programming software being the file manager of the operating system - the OVMS v3 module shows up as a drive on the desktop and you just drop the new firmware onto it.</div><div><br></div><div>Let me explain, in a little more detail, how MBED works.</div><div><br></div><div><ul><li>The MBED boards actually have two processors. The larger processor runs the end-user application (OVMS in our case), and the smaller processor makes up a system called the MBED HDK, based on the CMSIS-DAP standard.</li><li>The MBED HDK consists of a USB port (standard Micro-B type) connected to the MBED HDK CPU (on the board), some control circuitry, and an ICSP connection to the main CPU.</li><li>When you plug the MBED into the host O/S, it emulates a flash drive; dropping a file onto that drive programs the file onto the main CPU flash.</li><li>It also emulates a serial port to the host O/S so when you plug it in you get a serial port to the main CPU.</li><li>It provides a CMSIS-DAP standard debugger interface (for more advanced debugging).</li><li>The board itself can be powered from the USB, during MBED development or firmware updating.</li><li>As well as support for open source GCC toolchain (and others), the MBED included access to an on-line compiler - the code is kept in the cloud, in a shared revision control system, can be compiled there, and binaries downloaded for installation on the boards.</li><li>There are a large number of open source libraries available for the MBED platform.</li><li>Coding is in C / C++.</li><li>The MBED software includes a RTOS with thread support (which should make our job much easier than the current state-based and interrupt systems).</li><li>There are lots of low-power modes to work with.</li></ul></div><div><br></div><div>The MBED platform provides the lowest barrier-to-entry I’ve ever seen for embedded computing. No serial ports necessary. Just clone the project, tweak, compile, download (with no large IDEs required). Drag-and-drop firmware flashing.</div><div><br></div><div>It is also still raw in places. For example, I purchased an NXP LPC4088 MBED board to also experiment with (512KB flash, 96KB RAM, 32MB SDRAM, dual CAN) - only to find that the firmware on the HDK for that board doesn’t support OSX (despite the board being available for a year). That said, the freescale K64F seems pretty close to what we want, and has no such issues.</div><div><br></div><div>The other part of the puzzle is how we offer this. Some people want displays, other don’t. For 2G GSM one module was fine, but for 3G we need different modules for Asia, Europe and USA. Some want Bluetooth 2.1, others 4.0 BLE. Some want Wifi, others want cheap. Some want expansion. etc. What I’m thinking of is a baseboard design, with plug-in expansion modules.</div><div><br></div><div><ul><li>The baseboard would contain the MBED HDK + main processor, power supplies, as well as connectors for vehicle, diag, expansion, and USB.</li><li>It would most likely be based off the K64F open source architecture.</li><li>We would have several (perhaps 4 or so) plug-in sockets on the baseboard, to allow expansion modules to be plugged in. Each of these sockets would have connections to the main processor as well as expansion ports.</li><li>The baseboard would give OVMS on 1x CAN port.</li><ul><li>A 3G module would provide GSM + GPS (and would expose both antenna connectors to the outside world). The expansion board for this would be the same, but we would solder on different modules depending on the frequencies required.</li><li>A CAN expansion module would use Microchip MCP2515 controllers + MCP2551 transceivers (or something like it) to take SPI bus from the main CPU and expand CAN pins on the vehicle connector. Plug it in, and the system then has one or two more CAN ports available.</li><li>A wifi expansion module would provide WIFI connectivity.</li><li>A Bluetooth expansion module would use the HC-?? style bluetooth SPP modules. Similar to the 3G module, we can simply use the same expansion board - just solder on different bluetooth modules for v2.1 or v4.0 BLE.</li><li>A generic expansion module could be used to add custom functions.</li></ul><li>For the expansion modules, I’m think of two rows of connectors (one on each side) to provide connectivity and support. Very sturdy and cheap. (something like this: <a href="https://www.sparkfun.com/products/10414" target="_blank">https://www.sparkfun.com/products/10414</a>).</li></ul></div><div><br></div><div>Anyway, those are my thoughts, and suggestions given what is available today. I started this v3 search looking for a Linux base, and really had my heart set on it. But I just can’t solve the power and complexity issues. To meet the goals of having something easy to pick up, MBED really seems the only viable option today.</div><div><br></div><div>But, this is no longer my project. There are now so many people involved, and so many end-users. We are about to hit 1,000 users on the <a href="http://openvehicles.com" target="_blank">openvehicles.com</a> website.</div><div><br></div><div>So what do others think?</div><div><br></div><div>Regards, Mark.</div><span class=""><div><br></div><div>On 17 Jun, 2014, at 9:06 am, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>> wrote:</div><br></span><div><div class="h5"><blockquote type="cite"><div style="word-wrap:break-word">Mastro,<div><br></div><div>Actually, an opportune time as I've made some progress. I'll reply to your mail here, but take into account the follow-up discussions.</div><div><br></div><div><ul><li>The requirements of the OVMS community are diverse. Some want pre-heating, some want relay control, some want a display, some want to reprogram their ECUs, some want GSM, and others want none of these. What we are trying to build is a framework that can be adapted by others.<br><br></li><li>I am stunned that nothing like this exists on the market. I've spent the past six months looking for a low-power, low-cost, module with wifi+bluetooth and a development environment. Linux/RTOS/whatever. But, I haven't found anything perfect. I understand Kevin's frustration - it seems that GEVCU and OVMS could base on the same hardware, but even with that there appear to be difference in requirement that would just drive up costs for OVMS (or drive down functionality for GEVCU).<br><br></li><li>On the GEVCU front, I tend to agree with Rickard's comment that the two systems complement each other, but are very different. OVMS could be a telematics module for GEVCU, and would add great functionality to that project.<br><br></li><li>I spent some time looking at a modular approach. Design a base board with CPU, power and CAN buses. Have that base board support plug-in modules for wifi, bluetooth, cellular, etc. In that way, we can use pre-certified modules, and the user buys what they need. But, the problem with this approach is that if what you need is bluetooth+wifi+cellular, the cost is driven up considerably.<br><br></li><li>Talking to the China factories, it turns out that bluetooth/wifi is cheap as hell and trivial to implement - so long as we are ARM based. They laugh when we mention Microchip. They are stunned when we say we don't run Linux.<br><br></li><li>A data plan just for the car is expensive (particular in some countries like USA), but if we can offer hotspot functionality then it can be shared with other devices in the car. For that, we would need to be Linux based.<br><br></li><li>On the power front, I don't really see the problem as being low power while running, but rather the ability to support a sleep mode when the car is off. We don't need low power always - we just need it for the 90% of the time the car is sitting idle, not charging, not driving. The CPU is not an issue here - they all support a deep sleep mode and we can reduce power requirement to quite literally a trickle. The problem is the comms. We need to be able to be remotely 'woken up' and keeping these GSM/Wifi/Bluetooth modules low power while supporting network stacks is just not possible. The established industry uses USSD messages to remotely wake up their systems, and now I understand why. A GSM module can be designed to be in deep sleep, with very little power usage, but still able to receive a USSD message.<br><br></li><li>GSM modules like the TELIT and SIMCOM are interesting in that they support running code inside the module itself. This is something we haven't taken advantage of, but offers us the opportunity of offloading a significant amount of what we do.<br><br></li><li>For me, the requirement comes down to a base framework and module that supports:<br></li><ul><li>32bit CPU with enough grunt, and a low-power sleep mode</li><li>Dual CAN</li><li>Async + I2C + SPI + GPIO expansion</li><li>SD-Card</li><li>USB</li><li>Lots of RAM and FLASH</li><li>Wifi</li><li>Bluetooth</li><li>Optional GSM</li><li>Optional display (or can we get away with bluetooth to a cellphone?)<br><br></li></ul><li>What is interesting is the advent of low-cost Linux frameworks that are very close to what we need. Things like the BeagleBone and RasberryPi are fascinating, but really designed for HDMI video output - and the overhead of GPU + HDMI is a huge power drain. The closest I've found to what we require is (<a href="http://compulab.co.il/products/computer-on-modules/cm-t335/" target="_blank">http://compulab.co.il/products/computer-on-modules/cm-t335/</a>) - pretty amazing little device - low power, wifi+bluetooth, dual CAN, up to 512MB RAM and 1GB FLASH, for around US$50 (in horrendous quantities). I'm working with my contacts in China to see if we can base on a dev board something like that. If they can make Android phones for US$50, we should be able to get the guts of such a device for something similar. Then, add on GSM, take it from a BOM to a product, and we're probably looking at something still <US$150 but with so much more. The closest thing to ideal I've found at the moment is build a baseboard (connectors, power, CAN buses, etc) and have slots to take that CM-T335 module and an optional GSM module. But, I still think we can find something on the China market even closer to what we want/need.</li></ul></div><div><br></div><div>Anyway, those are my thoughts. My conclusion is that to me it seems sensible to work from a low-power linux base with built in dual-can, wifi + bluetooth.</div><div><br></div><div>Regards, Mark.</div></div></blockquote></div></div></div><div><br></div></div></div><br>_______________________________________________<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" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br><br></blockquote></div><br></div></div></div>
_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a></span></div></blockquote><blockquote type="cite"><div><unknown.jpg></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OvmsDev mailing list</span><br><span><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a></span><br><span><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a></span><br></div></blockquote></div></div>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</span></body></html>