<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Michael, Nikki, Kevin, etc,<div><br></div><div>The reason for the display/touchpad is twofold:</div><div><br></div><div><ol class="MailOutline"><li>Real-time display of vehicle information (0-60 times, sensors, etc)</li><li>Initial setup and monitoring of the OVMS module (avoiding SMS and making troubleshooting much easier)</li></ol></div><div><br></div><div>The display does add complexity+cost, increases theft worries, and is a hassle.</div><div><br></div><div>I've previously kept away from using a smartphone as a display for a few reasons:</div><div><br></div><div><ul class="MailOutline"><li>The smartphone runs hot</li><li>It is not elegant</li><li>Bluetooth is a 'bag of hurt' on Apple</li></ul></div><div><br></div><div>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 :-)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Going that route would result in:</div><div><br></div><div><div><ul class="MailOutline"><li>1x PIC32MX795 cpu for 2xCAN ports, 1xOBD-II main control tasks (always on)</li><li>SD-Card</li><li>Wifi</li><li>Bluetooth (BLE)</li><li>3G+GPS</li></ul></div></div><div><br></div><div>I/O exposed would be:</div><div><br></div><div><ul class="MailOutline"><li>Pure OBDII (via standard DB9) connector</li><li>OVMS standard DB9 connector (extended for second CAN bus)</li><li>OVMS expansion connector (diagnostics, ICSP, plus A/D, digital I/O and async)</li><li>USB (for firmware update)</li><li>GSM antenna</li><li>GPS antenna</li><li>SD-Card</li><li>(SIM slot internal is probably still best, to avoid theft concerns with the SIM)</li></ul></div><div><br></div><div>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.</div><div><br></div><div>Cost probably US$150 - US$170 range (bluetooth, wifi and 3G being responsible for this).</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 10 Apr, 2013, at 2:30 AM, Michael Balzer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Am 09.04.2013 12:14, schrieb Nikki
Gordon-Bloomfield:<br>
</div>
<blockquote cite="mid:39FB1010-07B7-4477-B7D0-BFD536947218@littlecollie.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Using the Bluetooth serial connection, it should be possible
for users to implement a GUI with existing smart phone
technology. <br>
</div>
</blockquote>
<br>
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.<br>
<br>
That's really a good option I think! Would also keep cost down.<br>
<br>
<blockquote cite="mid:39FB1010-07B7-4477-B7D0-BFD536947218@littlecollie.com" type="cite">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.<br>
</blockquote>
...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.<br>
<br>
<blockquote cite="mid:39FB1010-07B7-4477-B7D0-BFD536947218@littlecollie.com" type="cite">
<div>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? <br>
</div>
</blockquote>
That would make the OVMS an option for Ebike and Escooter drivers as
well. I've got one of these:
<a class="moz-txt-link-freetext" href="http://www.emco-elektroroller.de/elektroroller/novum.html">http://www.emco-elektroroller.de/elektroroller/novum.html</a><br>
<br>
...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.<br>
<br>
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.<br>
<br>
So, basically the same as available solutions like the "Cycle
Analyst" or the "WattsUp" do, but with the added OVMS coolness.<br>
<br>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>