[Ovmsdev] More sophisticated hardware

Mark Webb-Johnson mark at webb-johnson.net
Tue Apr 9 14:21:29 HKT 2013

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:

More CAN buses
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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130409/e22a1159/attachment.htm>

More information about the OvmsDev mailing list