[Ovmsdev] OVMS Hardware v2.0
tom at idleloop.com
Sun Jun 10 00:25:56 HKT 2012
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
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
More information about the OvmsDev