[Ovmsdev] OVMS v3

Tue Sep 30 22:32:33 HKT 2014

OK. I’ve completed an (exhausting, taken up far too many evenings over the past three months) review of what is available. Below are my summary conclusions on each of the hardware platforms I’ve tried.

This eMail just shows the five options. The follow-up eMail explains which one I think is best, and why. I’ve provided links for further reading, and am willing to answer questions on any.

Regards, Mark.

1] PIC32 (I tried UBW32 devkit, based on PIC32MX795)

http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX795F512L
https://www.sparkfun.com/products/9713

Specification:

PIC32MX795 32bit CPU @80MHz
128KB of RAM
512KB of Flash
USB Bootloader (with special client OS software for firmware upload)
2xCAN
Embedded design
Power consumption: 120mA (@5V) = 0.6W

Pros: Cheap, dual CAN, low power with plenty of lower power modes.
Cons: Microchip Toolchain, Microchip proprietary libraries, steep learning curve.

Similar to what we are doing today with OVMS v1 and v2 - just a more powerful CPU with more ram + flash.

Biggest drawback is the horrible proprietary Microchip development environment and libraries.

2] BeagleBone Black

http://beagleboard.org/black

Specification:

AM335x ARM® Cortex-A8 @1GHz
512MB of RAM
4GB of Flash
USB plug-and-play disk
No CAN
Linux O/S
Power consumption: 300mA - 450mA (@5V) = 1.5W - 2.25W

Pros: Plenty of RAM+Flash, plug-and-play.
Cons: Power consumption, complex low-power modes, lack of CAN although better connectivity that Pi.

The idea here is that we use the beagle bone black as the base, then add our stuff as a plug-in board (called ‘cape’) on top.

I like this one, but the biggest drawback is power consumption. We’d also have a lot of messing about to do with the kernel to get support for anything other than USB.

3] Raspberry Pi

http://en.wikipedia.org/wiki/Raspberry_Pi

Specification:

ARM1176JZF-S (ARMv6k) @700MHz
256MB or 512MB of RAM
Flash via SD-Card
No USB plug-and-play or disk mode
No CAN
Linux O/S
Power consumption: 400mA (@5V) = 1.5W - 2.0W

Pros: Cheap for Linux.
Cons: Power consumption, complex low-power modes, lack of CAN and poor expansion.

The idea here is that we use the raspberry pi as the base, then add our stuff as a plug-in board on top. Alternatively, there is also the Raspberry Pi compute platform, which would plug into our board just like the CM-T355 below.

Biggest drawback is power consumption, and lack of I/O. The beagle bone black really seems to beat out the Raspberry Pi for connectivity options.

4] CM-T335 Compute Module

http://compulab.co.il/products/computer-on-modules/cm-t335/#specs

Specification:

Texas Instruments AM3354 CPU @600MHz
128MB to 512MB of RAM
128MB to 1GB Flash
No USB plug-and-play or disk mode
Up to 2x CAN
Optional WIFI+Bluetooth on-board
Linux O/S
Power consumption: 40mA - 120mA (@12V) = 0.5W - 1.5W

Pros: Embedded Linux, dual CAN, built-in-wifi+bluetooth.
Cons: Complex low-power modes, restricted I/O options.

The idea here is that we build our own base board with all the I/O we need, and plug in this module to provide the compute power (and wifi/bluetooth connectivity).

Biggest drawback is price, and restrictive options on I/O connectivity.

5] MBED (Freescale freedom FRDM-K64F)

https://mbed.org/platforms/FRDM-K64F/

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.

The idea here is that we use our own board, based on the open source schematics of this one. This would be a reference design that we would tweak to do what we need.

Biggest drawback here is complexity. We’ve got to build it all ourselves.

ENDS

On 17 Jun, 2014, at 9:06 am, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> Mastro,
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> For me, the requirement comes down to a base framework and module that supports:
> 32bit CPU with enough grunt, and a low-power sleep mode
> Dual CAN
> Async + I2C + SPI + GPIO expansion
> SD-Card
> USB
> Lots of RAM and FLASH
> Wifi
> Bluetooth
> Optional GSM
> Optional display (or can we get away with bluetooth to a cellphone?)
> 
> 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 (http://compulab.co.il/products/computer-on-modules/cm-t335/) - 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.
> 
> 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.
> 
> Regards, Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/099b0ba3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.jpg
Type: image/jpeg
Size: 66137 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/099b0ba3/attachment-0010.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.jpg
Type: image/jpeg
Size: 119821 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/099b0ba3/attachment-0011.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.jpg
Type: image/jpeg
Size: 114035 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/099b0ba3/attachment-0012.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.jpg
Type: image/jpeg
Size: 108760 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/099b0ba3/attachment-0013.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.jpg
Type: image/jpeg
Size: 125629 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/099b0ba3/attachment-0014.jpg>