[Ovmsdev] More sophisticated hardware

Wed Apr 10 10:21:27 HKT 2013

Michael, Nikki, Kevin, etc,

The reason for the display/touchpad is twofold:

Real-time display of vehicle information (0-60 times, sensors, etc)
Initial setup and monitoring of the OVMS module (avoiding SMS and making troubleshooting much easier)

The display does add complexity+cost, increases theft worries, and is a hassle.

I've previously kept away from using a smartphone as a display for a few reasons:

The smartphone runs hot
It is not elegant
Bluetooth is a 'bag of hurt' on Apple

To use a bluetooth v2 (the standard, with excellent support) module with Apple devices requires the module to be a part of the MFI (Made For iPhone) program. That is a nightmare. Now, more recent devices (iPhone 4S and above, plus very modern Android devices) support bluetooth v4 (BLE) and Apple _supposedly_ has relaxed the rules with that - so long as the functionality is not core (ie; we add it to the existing ovms apps, and not having a device won't stop the app from working), we can probably get it through (but this is at the whim of Apple's approval process). BLE (v4) modules are damn expensive - but significantly less expensive than a 4.3" LCD display with touchpad :-)

Others use WIFI as a way of bypassing Apple's restrictions, but that is nasty. You have to set the device as your wifi access point, and you then lose Internet connectivity.

If we went the use-the-smartphone-as-the-display route, that would reduce costs and complexity (even with BLE). We could do without the second CPU (limiting us to 2xCAN ports and 1xOBDII). I like Michael's idea of exposing some A/D and/or digital I/O ports that could be used to support other vehicle types. The displays are certainly easier to program and look a lot better.

We've also got 6 async ports on the PIC32MX795, so we could also expose the same display protocol that the smartphone apps would use via that - perhaps for a plug-in add-on display option?

Going that route would result in:

1x PIC32MX795 cpu for 2xCAN ports, 1xOBD-II main control tasks (always on)
SD-Card
Wifi
Bluetooth (BLE)
3G+GPS

I/O exposed would be:

Pure OBDII (via standard DB9) connector
OVMS standard DB9 connector (extended for second CAN bus)
OVMS expansion connector (diagnostics, ICSP, plus A/D, digital I/O and async)
USB (for firmware update)
GSM antenna
GPS antenna
SD-Card
(SIM slot internal is probably still best, to avoid theft concerns with the SIM)

Enclosure size would probably have to be bigger than the current one - perhaps the same width/height, just increase the length. I am a little concerned about Wifi and Bluetooth antennas - putting them on the motherboard modules is by far the easiest, but that won't work with a metal case.

Cost probably US$150 - US$170 range (bluetooth, wifi and 3G being responsible for this).

Regards, Mark.

On 10 Apr, 2013, at 2:30 AM, Michael Balzer wrote:

> 
> Am 09.04.2013 12:14, schrieb Nikki Gordon-Bloomfield:
>> Using the Bluetooth serial connection, it should be possible for users to implement a GUI with existing smart phone technology. 
> 
> Oh I forgot: yes! That's the idea behind adding Bluetooth to the Twizplay, they could omit the LCD and use an App as the display device.
> 
> That's really a good option I think! Would also keep cost down.
> 
>> 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.
> ...that's why most Twizplay owners currently use a special quick lock mount just for the Twizplay -- so you need both a mount for the display and one for your mobile phone... bad.
> 
>> 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? 
> That would make the OVMS an option for Ebike and Escooter drivers as well. I've got one of these: http://www.emco-elektroroller.de/elektroroller/novum.html
> 
> ...just a simple chinese scooter, it doesn't have any data port, and it's only display is an analog voltage meter for the overall battery voltage -- you have to guess the SOC based on how deep the voltage drops under load.
> 
> The most simple solution would be to provide two analog I/O ports to feed pack voltage and current (measured as voltage difference on a shunt) into the OVMS. The A/D conversion should be fast enough to provide at least 10 ms resolution, so we can implement an Ah counter in software. Also some digital I/O ports should be available to measure the distance driven (by a reed sensor mounted to a tyre) and maybe record some other system status.
> 
> So, basically the same as available solutions like the "Cycle Analyst" or the "WattsUp" do, but with the added OVMS coolness.
> 
> 
> Regards,
> Michael
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> <dexter.vcf>_______________________________________________
> 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/3619386b/attachment.htm>