[Ovmsdev] OVMS Hardware v2.0
mark at webb-johnson.net
Sun Jun 10 13:29:17 HKT 2012
I kind of think that there are two camps out there:
Cheap, simple, just do one function (remote monitoring and control)
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 , but can't really do the more advanced things that  can do.
We already know that  comes in around US$100 in the quantities we are talking about. I've seen  around US$200-US$300. My biggest concern with  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 , 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:
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  camp.
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.
> 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.
> on 6/9/12 7:55 AM, Mark Webb-Johnson wrote:
>> 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:
>>> 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!).
>>> 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
>>>> 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
>>>> QC and logistics done in china - a partnership with a website there to
>>>> handle order processing and logistics from stock.
>>>> 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
>>>> 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
>>>> 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
>>>> Regards, Mark.
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev