[Ovmsdev] OVMS v3
William Petefish
william.petefish at gmail.com
Thu Oct 16 17:53:24 HKT 2014
They do say to use 5v 2a power adaptors. BUT I'd be willing to bet that the
number was with a 2.5" HDD.
They say in a blog entry that fully powered up w/o HDD it uses ~300ma.
No word on sleep mode.
-W
On Thu, Oct 16, 2014 at 3:51 AM, Mark Webb-Johnson <mark at webb-johnson.net>
wrote:
> Any idea on power consumption at normal run? Also, any support for sleep
> mode low power?
>
> Regards, Mark
>
> On 16 Oct, 2014, at 4:32 pm, William Petefish <william.petefish at gmail.com>
> wrote:
>
> It cleanly shutsdown. It also has a power button and a reset button.
>
> It is using an entirely different processor. (Broadcom SOC for the
> raspberry pi VS Allwinner A20 for the banana pi)
>
> -W
>
> On Thu, Oct 16, 2014 at 3:22 AM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
>>
>> Seems to be very similar to raspberry pi - just faster cpu.
>>
>> Presumably suffers from same issues, though - power requirements and
>> issues with unclean shutdown?
>>
>> Regards, Mark
>>
>> On 16 Oct, 2014, at 2:55 pm, William Petefish <william.petefish at gmail.com>
>> wrote:
>>
>> Y'all might try the Banana Pi. I have 2. They run Linux and Android. Tons
>> of GPIO.
>> No Onboard WiFi. BUT that can be fixed with a $10 dongle. It only has one
>> CAN though. BUT another can be added via an expansion board with the
>> MicroOBD 200 module OR it can be made with a SPI-CAN uart from Microchip.
>>
>> -W
>>
>> On Wed, Oct 15, 2014 at 10:04 PM, Mark Webb-Johnson <
>> mark at webb-johnson.net> wrote:
>>
>>> Kevin,
>>>
>>> An Arduino Due clone is about US$30, and a dual CAN bus shield about
>>> US$25.
>>>
>>> But, that doesn't solve the Bluetooth, Wifi, GPS, GPRS, etc, issues.
>>>
>>> The problem we are seeing is that while the hardware seems trivial, it
>>> is proving to be impossible to find. Refer back to the original list:
>>>
>>> • 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?)
>>>
>>> That is what we need. Finding it in a low-power, low-cost, framework is
>>> proving impossible. It seems that we are just too early, and I suspect than
>>> in a couple of years this will actually be trivial. While GEVCU comes
>>> close, the US$600++ pricetag is just too high. The EVTV kit doesn't even
>>> come close but still costs eight times what we have now.
>>>
>>> Regards, Mark.
>>>
>>> On 16 Oct, 2014, at 2:08 am, Kevin Sharpe <
>>> kevin.sharpe at zerocarbonworld.org> wrote:
>>>
>>> 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;
>>>
>>> http://store.evtv.me/proddetail.php?prod=ArduinoDueCANBUS&cat=23
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Kevin Sharpe | Founder & Chair of Trustees
>>> Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld
>>> kevin.sharpe at zerocarbonworld.org <kevin.sharpe at zerocarbonworld.org>|
>>> www.zerocarbonworldorg <http://wwwzerocarbonworld.org/> |
>>> twitter.com/zerocarbonworld <http://twitter.com/ZCWcharlie>
>>> Zero Carbon World is a UK Registered Charity #1141347
>>> From: Mark Webb-Johnson <mark at webb-johnson.net>
>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> Date: Wednesday, 1 October 2014 12:40
>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> Subject: Re: [Ovmsdev] OVMS v3
>>>
>>> Kevin, Colin,
>>>
>>> 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.
>>>
>>> Or, have things changed?
>>>
>>> Regards, Mark
>>>
>>> On 1 Oct, 2014, at 7:07 pm, Kevin Sharpe <
>>> kevin.sharpe at zerocarbonworld.org> wrote:
>>>
>>> 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.
>>>
>>> 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).
>>>
>>>
>>> Kevin Sharpe | Founder & Chair of Trustees
>>> Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld
>>> kevin.sharpe at zerocarbonworld.org <kevin.sharpe at zerocarbonworld.org>|
>>> www.zerocarbonworld.org | twitter.com/zerocarbonworld
>>> <http://twitter.com/ZCWcharlie>
>>> Zero Carbon World is a UK Registered Charity #1141347
>>> From: Collin Kidder <collink at kkmfg.com>
>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> Date: Tuesday, 30 September 2014 15:53
>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> Subject: Re: [Ovmsdev] OVMS v3
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> -Collin Kidder
>>>
>>> On Tue, Sep 30, 2014 at 10:34 AM, Mark Webb-Johnson <
>>> mark at webb-johnson.net> wrote:
>>>
>>>>
>>>> And the winner is (or at least who I think the winner should be):
>>>>
>>>> *MBED (and probably Freescale **K64F variant)*
>>>>
>>>> <unknown.jpg>
>>>>
>>>> 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.
>>>>
>>>> I think our decision comes down to two choices:
>>>>
>>>>
>>>> 1. A Linux base, probably compute-module style, with Megabytes of
>>>> RAM, Gigabytes of Flash, incredible flexibility but a challenge to keep
>>>> power consumption down
>>>> 2. An embedded base, with hundreds of Kilobytes of RAM, Megabytes
>>>> of Flash, and all the complexities that go along with embedded systems
>>>>
>>>>
>>>> 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.
>>>>
>>>> Let me explain, in a little more detail, how MBED works.
>>>>
>>>>
>>>> - 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.
>>>> - 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.
>>>> - 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.
>>>> - 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.
>>>> - It provides a CMSIS-DAP standard debugger interface (for more
>>>> advanced debugging).
>>>> - The board itself can be powered from the USB, during MBED
>>>> development or firmware updating.
>>>> - 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.
>>>> - There are a large number of open source libraries available for
>>>> the MBED platform.
>>>> - Coding is in C / C++.
>>>> - The MBED software includes a RTOS with thread support (which
>>>> should make our job much easier than the current state-based and interrupt
>>>> systems).
>>>> - There are lots of low-power modes to work with.
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>> 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.
>>>>
>>>>
>>>> - The baseboard would contain the MBED HDK + main processor, power
>>>> supplies, as well as connectors for vehicle, diag, expansion, and USB.
>>>> - It would most likely be based off the K64F open source
>>>> architecture.
>>>> - 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.
>>>> - The baseboard would give OVMS on 1x CAN port.
>>>> - 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.
>>>> - 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.
>>>> - A wifi expansion module would provide WIFI connectivity.
>>>> - 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
>>>> - A generic expansion module could be used to add custom
>>>> functions.
>>>> - 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: https://www.sparkfun.com/products/10414
>>>> ).
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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
>>>> openvehiclescom <http://openvehicles.com/> website.
>>>>
>>>> So what do others think?
>>>>
>>>> Regards, Mark.
>>>>
>>>> On 17 Jun, 2014, at 9:06 am, Mark Webb-Johnson <mark at webb-johnson.net
>>>> <mark at webb-johnsonnet>> 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclubhk/mailman/listinfo/ovmsdev
>>>> <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>>>
>>>>
>>> _______________________________________________ OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> <unknown.jpg>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________ OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> 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/20141016/8129b831/attachment.htm>
More information about the OvmsDev
mailing list