[Ovmsdev] OVMS v3

Tue Jun 17 09:06:34 HKT 2014

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.

On 16 Jun, 2014, at 11:41 pm, Mastro Gippo <gipmad at gmail.com> wrote:

> Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either.
> I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :)
> That said, I'd like to throw a few ideas to the table.
> 
> 
> - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities:
>  -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring)
>  -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/
>  -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too.
> 
> I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses.
> 
> 
> - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? 
> I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps
> On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. 
> 
> 
> - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy?
> 
> 
> And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too.
> 
> Regards
> MG
> _______________________________________________
> 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/20140617/deaf7776/attachment.htm>