[Ovmsdev] OVMS v3

[Mark Webb-Johnson]

Michael,

I think your cut-and-paste is from the wrong option. Here are the specs and pros/cons for the MBED option:

Specification:

Freescale K64F Kinetis K64 MCU (MK64FN1M0VLL12) @120MHz
256KB of RAM
1MB of Flash
USB plug-and-play (both disk and serial, although serial needs driver for windows)
1xCAN
Embedded design
Power consumption: 190mA (@5V) = 1W

Pros: Plenty of RAM+Flash, plug-and-play disk + serial, RTOS, low barrier to entry.
Cons: Only single CAN, dual CPU arrangement.

Whatever we choose, power consumption will be an issue.

Here are the power usage figures from my bench, using v1 hardware (remember, this is @12V, not @5V):
PIC (normal mode) on, modem powered down (by power toggle switch): 35mA - 42mA
PIC (normal mode) on, modem on, gps off: 75mA
PIC (normal mode) on, modem on,gps on: 120mA
Very short-lived bursts to 160mA at times, presumably while transmitting on GSM

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.

But, we can improve things in a few ways:

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.
The 1W power consumption I found also includes powering up all the ancillary peripherals on the demo board - we don’t need that.
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.
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.
We’ll use low power modes, sleep modes and power-down for the peripherals, wherever possible.

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.

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).

Regards, Mark.

On 1 Oct, 2014, at 8:04 pm, Michael Balzer <dexter at expeedo.de> wrote:

> Mark,
> 
> thanks for all your investigation and evaluation!
> 
> 
> Am 30.09.2014 um 16:32 schrieb Mark Webb-Johnson:
>> Cons: Power consumption, complex low-power modes, lack of CAN although better connectivity that Pi.
> 
> 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.
> 
> What does "complex" mean? Just difficult to implement on the first hand, or a continuing cause of problems?
> 
> Regards,
> Michael
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> 
> <dexter.vcf>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20141001/d0dbf22c/attachment.htm>