
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Michael,<div><br></div><div>I think your cut-and-paste is from the wrong option. Here are the specs and pros/cons for the MBED option:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div>Specification:</div><div><br></div><div><ul class="MailOutline"><li>Freescale K64F Kinetis K64 MCU (MK64FN1M0VLL12) @120MHz</li><li>256KB of RAM</li><li>1MB of Flash</li><li>USB plug-and-play (both disk and serial, although serial needs driver for windows)</li><li>1xCAN</li><li>Embedded design</li><li>Power consumption: 190mA (@5V) = 1W</li></ul><div><br></div></div></div><div><div>Pros: Plenty of RAM+Flash, plug-and-play disk + serial, RTOS, low barrier to entry.</div><div>Cons: Only single CAN, dual CPU arrangement.</div></div></div></blockquote></div><div><br></div><div>Whatever we choose, power consumption will be an issue.</div><div><br></div><div>Here are the power usage figures from my bench, using v1 hardware (remember, this is @12V, not @5V):<div><ul class="MailOutline"><li>PIC (normal mode) on, modem powered down (by power toggle switch): 35mA - 42mA</li><li>PIC (normal mode) on, modem on, gps off: 75mA</li><li>PIC (normal mode) on, modem on,gps on: 120mA</li><li>Very short-lived bursts to 160mA at times, presumably while transmitting on GSM</li></ul></div></div><div><br></div><div>So, the base PIC18 is consuming about 40mA @12V. The MBED option is about 1W. But, the bigger issue is the GSM modem an additional 1.5W. Then, add on bluetooth and wifi, and the problem is exacerbated.</div><div><br></div><div>But, we can improve things in a few ways:</div><div><br></div><div><ol class="MailOutline"><li>We can use low-power modes for the main CPU. For example, the freescale K64F I looked at uses a MK64FN1M0VLL12 CPU, and the data sheet for that shows typical power consumption of 0.135W, but that reduces to 0.005W in low power mode, and almost nothing in stop mode.</li><li>The 1W power consumption I found also includes powering up all the ancillary peripherals on the demo board - we don’t need that.</li><li>The 1W power consumption also includes powering the MBED HDK chipset, which is perhaps 1/4 of the power usage. We’ll arrange our circuit so that is only powered up when the board is connected to USB in MBED mode.</li><li>We’ll use a switching power supply (which is significantly more efficient than the LM we use on the OVMS v2 board. Arthur Hebert gave some figures on this (“OVMS - power drain”, back in June 2014) and he showed the power supply we use is only 40% efficient at 12V (it burns 605 of the power off as heat). An LM2596 switching power supply, by comparison, is 80% efficient at a comparable 5V. Still deciding on final arrangement, but my guess is two separate power supplies - one optimised for 12V car power, and the other for 5V USB power.</li><li>We’ll use low power modes, sleep modes and power-down for the peripherals, wherever possible.</li></ol></div><div><br></div><div>I have also experimented with another idea that might work. Instead of using the Microchip MCP2515 CAN controller (which costs about US$2/piece and is pretty dumb), use a cheap simple low-power CAN capable microcontroller (about US$3/piece, fully programmable). The main CPU could tell that micro controller what conditions should mean low power wake-up, and then the CAN capable micro controller would signal the main CPU to wake up. This way, we can shut everything down but keep the CAN bus up and have signals on that bus control wake-up of the main CPU. Just an idea, but I did prototype something up to try it, and it seemed to work well.</div><div><br></div><div>In general, I think we’ll be ok so long as we treat power consumption as a priority and do everything we can to allow it to be reduced in the fundamental design. My guess is that in our lowest power mode, when car is not charging and not driving and peripherals can be put in low power mode, we’ll be in the 10s of mA (rather than 100s of mA).</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 1 Oct, 2014, at 8:04 pm, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Mark,<br><br>thanks for all your investigation and evaluation!<br><br><br>Am 30.09.2014 um 16:32 schrieb Mark Webb-Johnson:<br><blockquote type="cite">Cons: Power consumption, complex low-power modes, lack of CAN although better connectivity that Pi.<br></blockquote><br>So the MBED will use ~3-4 times the power compared to the v2 module. That means it cannot be used for our purpose without low-power / standby modes.<br><br>What does "complex" mean? Just difficult to implement on the first hand, or a continuing cause of problems?<br><br>Regards,<br>Michael<br><br>-- <br>Michael Balzer * Paradestr. 8 * D-42107 Wuppertal<br>Fon 0202 / 272 2201 * Handy 0176 / 206 989 26<br><br><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>