[Ovmsdev] More sophisticated hardware

Wed Apr 10 16:08:23 HKT 2013

It wouldn't surprise me.

I think the Arduino is good for generalised low-speed control, but I would be concerned using it for thinks like brakes / stability / traction control / etc.

One discussion I had with the guys was also whether the comms was best done in the same control unit. I know it is cost-effective, but I really like separating this. Look at the Tesla Model S - the big 17" display computer is separate from the VMS. If the big 17" display goes, you can still drive (slow down, steer, brake, stop, etc) the car.

I really think OVMS is a good fit the the conversions market. If we bring out plenty of A/D, digital I/O and Async ports, in the more sophisticated hardware, then we should be very usable for them (as well as having the side affect of garage door control, etc :-)

Regards, Mark.

On 10 Apr, 2013, at 3:32 PM, Kevin Sharpe ZCW wrote:

> Many thanks Mark.
> 
> I believe that GVCU has moved on from Macchina and that might explain the 'radio silence'.
> 
> I'll reach out to EVTV and find out what the plans are.
> 
> All the best,
> 
> Kevin
> 
> On 10 Apr 2013, at 02:56, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
> 
>> Kevin,
>> 
>> I did have some discussions a while ago with the Macchina guys - they were wanting to support OVMS (server and apps) from their module. They were driving that, and not sure where it went.
>> 
>> I like the way they are supporting the conversion market, and it is good that EVTV chose them.
>> 
>> Regards, Mark.
>> 
>> On 9 Apr, 2013, at 11:15 PM, Kevin Sharpe ZCW wrote:
>> 
>>> Hi Mark,
>>> 
>>> IMO it would be great if the next OVMS hardware version could be compatible with the 'Generalised Vehicle Control Unit' being promoted by Jack Ricard (EVTV) and a bunch of developers.  This would allow us to move towards a generic and open architecture for future EV control. I'm happy to provide details of the GVCU hardware/software if you think that would be helpful.
>>> 
>>> I think we also want to make any new hardware sufficiently 'sexy' to encourage people to get involved for the benefit of all. While projects like CANary and LEAFSCAN are admirable it's a shame that so much effort is being expended on projects other than OVMS :-)
>>> 
>>> Keep up the good work!
>>> 		Kevin Sharpe | Founder & Patron
>>> Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld
>>> kevin.sharpe at zerocarbonworld.org | www.zerocarbonworld.org | twitter.com/zerocarbonworld
>>> 
>>> Zero Carbon World is a UK Registered Charity #1141347
>>> From: Mark Webb-Johnson <mark at webb-johnson.net>
>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> Date: Tuesday, 9 April 2013 07:21
>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>>> Subject: [Ovmsdev] More sophisticated hardware
>>> 
>>> 
>>> 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:
>>> 
>>> WIFI
>>> 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
>> 
>> _______________________________________________
>> 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/20130410/a25d823d/attachment.htm>