[Ovmsdev] OVMS Hardware v2.0

Sun Jun 10 18:42:17 HKT 2012

Check here <http://mbed.org/blog/entry/mbed-and-Arduino-shields/>. Cool
thing is, the xbee can be replaced with
this<http://www.sparkfun.com/products/11047>.
And it eats arduino shields.

William

On Sun, Jun 10, 2012 at 5:25 AM, Mark Webb-Johnson <mark at webb-johnson.net>wrote:

> Forgot the link:
>
> http://www.olimex.com/dev/lpc-e2294rb.html
>
> [image: image.jpeg]
>
> On 10 Jun, 2012, at 6:19 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
>
> Interesting browsing:
>
>   4x CAN!
>
> Mark
>
> On 10 Jun, 2012, at 5:52 PM, William Petefish <william.petefish at gmail.com>
> wrote:
>
> I'd say option 2.
>
> I've looked into some processors. The one that the roadster uses in the
> vms (LPC2294) is a little overkill but it would work as you can load a
> linux kernel onto it. (and there are plenty of dev boards.) The LPC1768 is
> also a good choice as the best dev kit is the mbed<http://www.sparkfun.com/products/9564>which uses a web-based IDE and is USB natively upgradable. (Note: Both
> require the MCP2551 or the TJA1048.)
>
> As I remember you can use a serial GLCD w/ SD slot as your display.
> Something like this <http://www.sparkfun.com/products/11075>.
>
> My $0.02, spend it wisely.
> William
>
> On Sun, Jun 10, 2012 at 12:29 AM, Mark Webb-Johnson <mark at webb-johnson.net
> > wrote:
>
>> Tom,
>>
>> I kind of think that there are two camps out there:
>>
>>
>>    1. Cheap, simple, just do one function (remote monitoring and control)
>>    2. Kitchen sink (touch LCD, wifi hotspot, etc)
>>
>>
>> While Sonny and I have looked at 32bit embedded processors, including the
>> PIC and ARM varieties, it feels like half way between the two camps. It
>> will give us more than [1], but can't really do the more advanced things
>> that [2] can do.
>>
>> We already know that [1] comes in around US$100 in the quantities we are
>> talking about. I've seen [2] around US$200-US$300. My biggest concern with
>> [2] is power requirements to keep the thing running when the vehicle is off
>> - not so much a concern for the roadster, but a big issue for little
>> lead-acid 12V battery based systems.
>>
>> In an ideal world, I'd go for camp [3], rip out the pos Alpine and
>> replace it with a double-din in-car-computer that does the job better for
>> 1/3rd the price - can you imaging having a 7" display with exactly what we
>> want, as well as 3G hotspot, OVMS remote control and decent navigation?
>> Sadly, I just don't have the free time and the power requirements are truly
>> terrifying [not to mention the fear of what the Tesla engineer would say
>> next time I took it in for warranty repair / service] :-( I do hold out
>> hope that Tesla will allow us to run some powerful apps on the model S / X
>> displays, but I'm a realist and am not holding my breath.
>>
>> There is another interesting approach - Arduino. These guys:
>>
>> http://www.rechargecar.com/content/first-glimpse-macchina
>>
>> have approached us, and there may be an interesting partnership there. I
>> really like the way they work. Very focussed and in the EV community. They
>> are more into the hardware side of things, and are looking for open source
>> software partners - exactly the opposite of us, and very complementary. I
>> think they signed up for this list, and perhaps can comment here (or maybe
>> too early, but the product is up on their website, so I guess no harm
>> mentioning it)?
>>
>> The reason we initially kept away from Arduino was cost. We were fixated
>> on <US$100 all-in, and to meet that we had to keep things simple and
>> well-and-truly in the [1] camp.
>>
>> Regards, Mark.
>>
>> P.S. An alternative approach for multi-CAN is that the MCP2551+PIC18
>> combination is cheap and simple as hell. It would not be hard to just put
>> multiple microprocessors in their, each handling decoding of their own bus,
>> and multiplexing it all back to the main controller on an I2C style bus.
>> Not elegant, but very expandable :-)
>>
>> On 10 Jun, 2012, at 12:25 AM, Tom Saxton wrote:
>>
>> Cathy and I went to a tech/sales seminar from ST Micro. They have a line
>> of
>> 32-bit ARM chips that includes chips with support for 2 CAN buses, the
>> first
>> I've seen.
>>
>> http://www.st.com/internet/mcu/subclass/1169.jsp
>>
>> The STM32F105 line has dual CAN, dual UART, and USB. The STM32F107 line
>> adds
>> Ethernet support. Flash size varies from 64K to 256K. DigiKey shows unit
>> pricing for the STM32F105 chips in the $4 to $10 range.
>>
>> The tools story is not awesome. Although there was some mention of GCC,
>> it's
>> not clear to me that there are quality, free tools available.
>>
>>    Tom
>>
>> on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
>>
>> Michael,
>>
>>
>> We can only connect to one CAN bus at the moment. I think it is quite
>> tricky
>>
>> to do more, as most of the chips I can find have only 1 ECAN module.
>>
>>
>> Regards, Mark.
>>
>>
>> On 9 Jun, 2012, at 2:17 AM, Michael Jochum wrote:
>>
>>
>> Hi,
>>
>>
>> nice work.
>>
>> I think you are on the right way. Dont put to much in it. A loop through
>>
>> connector for the CAN Bus could be very help full.
>>
>> I think the next step could be a separate Module with LCD, SD-Card Slot,
>> etc.
>>
>> for showing and Logging live Data.
>>
>>
>> One Thing: to how many CAN Buses can you simultaneously connect to? How
>> many
>>
>> can you handle at the same time?
>>
>> I thing i could be a good idea to have the possibility connect to more
>> than
>>
>> one. The Volt/Ampera has 5 (five!).
>>
>>
>>
>> Bye
>>
>> michael
>>
>>
>>
>> Am 08.06.2012 um 02:33 schrieb Mark Webb-Johnson:
>>
>>
>>
>> Apologies for the length of this eMail, but lots to go through...
>>
>>
>> We've come to the end of our initial batch of boards, and there are
>>
>> significant minimum-order-quantities for things like circuit boards, so we
>>
>> are taking the opportunity to switch to hardware v2.0.
>>
>>
>> The roadster owners who wanted something like this presumably already have
>>
>> it, or are waiting for Tesla's solution. So, we're trying to think mostly
>> of
>>
>> the _other_ cars out there. Things like the Volt/Ampera, Leaf and my
>> wife's
>>
>> ICE Nissan children ferry.
>>
>>
>> The problems we've had with the current hardware include:
>>
>>
>> Production reliability issues with the factory
>>
>> Quality issues (particularly soldering) with the factory
>>
>> Too fiddly to produce and too many components
>>
>> Too hard to diagnose problems
>>
>> QC and Logistics is just a hassle for Sonny and myself - not fun ;-)
>>
>>
>> Once we add in using this in other cars, we also get:
>>
>>
>> Concerns over 12V battery load
>>
>> Lack of GPS in some cars
>>
>>
>> Things got better as the existing hardware went from 1.0 (initial
>> prototype
>>
>> with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor
>>
>> cables) to the current 1.2 (little white 4pin and 2pin connectors), but
>>
>> still just too much work to get these made.
>>
>>
>> Accordingly, what we are trying to do is come up with a v2.0 hardware
>>
>> design. As what we have works so well, there seems little point in making
>>
>> any dramatic shifts - we've considered switching to a 32bit processor,
>>
>> built-in touch-screen display, etc - as that would be something completely
>>
>> different. We just want to incrementally improve the points that are
>>
>> 'hurting' now. Keep it a very low cost module that does what it does well.
>>
>>
>> Here are the changes we have come up with:
>>
>>
>> Change to a single-board approach, made by a single factory. The board
>> will
>>
>> contain the controller and SIMCOM GSM/GPRS system in one.
>>
>> The board external connectors will be exposed through the box. We'll use a
>>
>> standard DB9 (male), then adaptor cables from that to each car's
>>
>> requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V.
>>
>> The existing diag DB9 (female) is unchanged, but should be externally
>>
>> accessible.
>>
>> IPC pins to also be externally accessible, so firmware can be updated
>>
>> without opening the case.
>>
>> Upgrade the processor from 2680 to 2685. Gives us more flash (useful for
>>
>> cars other than roadster), but otherwise completely compatible.
>>
>> Connection of 12V line to microprocessor ADC. This will allow us to
>> measure
>>
>> supply voltage and take appropriate actions.
>>
>> Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have
>>
>> it - this can be powered up/down by AT commands.
>>
>> LEDs go to the bottom of the board, to be closer to the holes and hence
>> more
>>
>> visible.
>>
>> QC and logistics done in china - a partnership with a website there to
>>
>> handle order processing and logistics from stock.
>>
>>
>> <ovms_v2_layoutdiagram.png>
>>
>>
>> I really want to make something very very clear - this is not intended as
>> an
>>
>> 'upgrade' for existing v1.x modules for roadster owners. The Tesla
>> Roadster
>>
>> is covered, and work really well with v1.x hardware. New roadster owners
>>
>> will be able to use v2.x hardware as well, but there is no point in
>>
>> 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x
>>
>> hardware is primarily intended to make it easier so support other types of
>>
>> cars.
>>
>>
>> As I mentioned at the top of this email, we're down to the last few v1.x
>>
>> modules - there was a recent unexpected rush of orders. So, today, we've
>>
>> taken down the hardware offering at www.openvehicles.com, until the v2.x
>>
>> hardware arrives. If someone _really_ needs a v1.x module, we still have
>>
>> some and can let you have it, but we really want to keep as many of the
>>
>> modules we have left as repair spares for existing owners.
>>
>>
>> For those working with us on OVMS in other cars (Michael on Volt/Ampera,
>>
>> etc) don't worry - we'll look after you and swap you v2.x hardware if
>>
>> necessary.
>>
>>
>> We're just now entering prototype stage with the factory, so if anyone has
>>
>> any comments/suggestions please send them in. I'm working hard on this. So
>>
>> long as the prototypes are ok, we should have production ready in 4-to-6
>>
>> weeks.
>>
>>
>> Regards, Mark.
>>
>>
>> _______________________________________________
>>
>> 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/20120610/04e609c0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpeg
Type: image/jpeg
Size: 74439 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120610/04e609c0/attachment.jpeg>