[Ovmsdev] OVMS Hardware v2.0

Sun Jun 10 17:52:22 HKT 2012

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120610/90017a97/attachment.htm>