[Ovmsdev] More sophisticated hardware

Nikki Gordon-Bloomfield nikki at littlecollie.com
Tue Apr 9 18:14:16 HKT 2013

Hi Mark, 

I think this is an excellent idea, especially keeping the original hardware as a base model. 

I suspect you're right, low-power PIC is the better choice as I presume it'll be easier to write similar firmware for both? 

My thoughts about the display however are mixed. Personally, I don't mind having displays added to my car. But my wife prefers things to look stock. I'm allowed to modify the Leaf (and Twizy) but she wants it to look as standard as possible. As a developer, she likes tech to be hidden, but doing a good job! 

An option I see here, especially with bluetooth, is the following: 

Using the Bluetooth serial connection, it should be possible for users to implement a GUI with existing smart phone technology.  You'd then simply offer TWO different apps: The existing OVMS app, which keeps its basic functionality; and an OVMS-Dash app, which allows you to implement your iOS/Android/WindowsMobile device As the Dash. 

Users could then use something like the Brodit mount system to keep their phone docked and charging while in the car. Or they could use an iPad instead of an iPhone, for example. 

We already know that most OVMS users have smartphones. And they work well, with great touch screens. Why not use the hardware they already have to do the interfacing? I suspect most phones on the market today can have multiple bluetooth pairings? 

The result? A nice system which keeps the cost down, but retains the usability of a touch-screen system. It's also easier to push updates that way too. (Could updates even be pushed via WiFi or bluetooth to the micro controller when parked at home?)

Of course, the con here is that whenever Apple or Samsung, or HTC, or whoever brings out a new OS, there's a risk that Bluetooth may not work as intended. But I'd be happy to test it here. 

There's another advantage to my system: security. To your average car-theif, looking into the car to see a Brodit mount means "hey, this person has a brodit mount… they've probably taken their phone with them"

With a piece of hardware and touch-screen in the car, they're more likely to go "Hey, look, a Car PC! I'll have that!"

For Twizy owners that's an added bonus. There are no door locks, and getting in is as simple as reaching inside and pulling the door handle. Sure, my Twizy has a REALLY LOUD and pretty sensitive motion-detecting alarm, but I would rather not have additional hardware on display if I can duplicate the functionality with my phone. 

Moving forward, I think it'd be great if someone in the self-build community (You may have to work with someone else) could produce a raw "battery pack to OVMS" module, which enables those with converted or custom EVs to use the OVMS system using a standard set of protocols and Can messaging -- or perhaps direct using an add-on IO device? 

I think moving forward with hardware is the way forward. LOTS of EV owners here in the UK (practically every non Leaf owner) I know wants OVMS. But they're put off by the fact they have to open it up to install a SimCard… then configure it with text messages… then program it with a flash tool when there's an update. 

If a device can be developed which works seamlessly with smart phones, has easily-updatable USB programming, and touch-screen menu driven use, I think people will buy it!


On 9 Apr 2013, at 07:21, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> Long post - apologies...
> I'm not suggesting changing the current hardware offering, but coming up with something more powerful to offer along side it. Requirements listed include:
> Bluetooth
> Display
> Full OBD-II
> More CAN buses
> 3G
> SD-Card for data logging capability
> We've been talking about this for a while, and have tried various approaches. It comes down to a choice between:
> Low power embedded PIC style
> High power Linux arm style
> My personal preference is for low-power - especially given the 12V issues we've seen.
> A couple of things have come together over the past few months, and there are some interesting opportunities:
> I've been looking at the PIC32MX795 microcontroller. 128KB of RAM, 512KB flash. 6 async ports. 2 CAN buses. etc.
> Using controller-based touch-screen LCDs is hellishly expensive. But, Microchip have a neat solution. Using an off-chip memory buffer (or on chip ram for lower resolutions) and DMA transfers, a 4.3" LCD WQVGA resolution display (with touchscreen) can be interfaced for a fraction of the cost of a controller-based display, using just 5% to 10% of the CPU.
> 3G is possible - just need to work out the required frequencies to see if we need (a) the tri-band version, or (b) two different dual-band versions.
> Full OBD-II is relatively easy - standard outputs interfaces via async serial ELM327 style (using the newer STN1110).
> Single-wire CAN is also possible.
> The PIC32s have USB on-board (for serial, or firmware upload).
> SD-Card is relatively easy (libraries are available, and plenty of I/O PINs for the I2C controller).
> Bluetooth modules are easy (async serial interface).
> Wifi is possible (for wifi client based setups as an alternative to 3G - hotspot is trickier).
> The design I've been looking at includes:
> A 4.3" multi-touch 400x240 resolution LCD display.
> A primary PIC32MX795 cpu for 2xCAN ports, 1xOBD-II main control tasks (always on).
> A secondary PIC32MX795 cpu with LCC setup to drive the LCD display and touchpad - this is just for UI.
> SD-Card
> Wifi
> Bluetooth
> 3G+GPS
> We could use the 2xCAN ports on the second (display) CPU as well, if we needed them - although the basic setup above already has 3 CAN ports (2 direct and 1 via OBD-II). The primary controller has power control and can power down the other parts of the system (particularly power hungry systems like display) when the car is off.
> It seems to me that the more advanced portion of our user base wants to do some sophisticated stuff, and there is a very large community of users out there using things like the DashDAQ for real-time logging and display of vehicle metrics.
> The DashDAQ costs US$549 (plus extras), and doesn't have wifi, bluetooth, 3G - it only works on OBD-II and is 'closed' (although you can do some screen design in it).
> Feature-wise, I'm looking at something like the DashDAQ. The ability to make screens with real-time metrics, as well as an in-car display. Couple that with logging capability for both low-level CAN/OBD-II traffic and high-level gps-based plots. Wifi-connectivity to home wifis for garages with no 3G coverage, and bluetooth for cell-phone connectivity. Plus, all the existing OVMS features.
> I'm guessing that the hardware to do all of the above would be about double what we have now (so around US$200). The biggest cost items are the 4.3" display and 3G module. CPUs are cheap (about US$10 each). There are quite a large number of ancillary components (especially for OBD-II), but it should fit in an enclosure behind a 4.3" display.
> Other than bread-boarding some mock-ups, to see if this is feasible, I haven't done any extensive work on the above.
> What do people think? Is this something people would want? A way to grow the community? Or, is there a better way of doing it?
> Regards, Mark.
> _______________________________________________
> 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/20130409/61bed4a0/attachment.htm>

More information about the OvmsDev mailing list