[Ovmsdev] OVMS v3

Tue Jun 17 23:41:47 HKT 2014

In our Leaf, we have a Gary Giddings SOC meter. It powers up with the car
and shows the SOC on an LED display that's always easily visible day or
night. It's positioned discretely so it doesn't clutter up the car yet is
still easy to see with a quick glance. I don't want to have to fumble with a
cell phone to look at SOC. We don't have a cell phone mount in the car as
that would attract break-ins.

The Roadster is different because it has a good SOC display, so the OVMS is
only used for remote monitoring, occasional control, plus now the incredibly
useful ACC.

The newer Leafs have the option of showing a numerical SOC percent, but
that's still relative to the current pack capacity rather than an absolute
energy estimate. So, displaying something based on Gids would still be
useful to new Leaf owners although it's a less obvious need now.

The 2014 Leaf removed the ability to limit charging to 80% because the EPA
was punishing them for that feature (lowering the estimated range to the
average of 100% and 80% charge, a very stupid move). Perhaps that doesn't
make any difference in battery longevity, but it's a huge setback for owners
(like me) who live at the top of a hill. When every charge is to 100%, you
get no regen going down that first hill which really detracts from the EV
driving experience. So 2014 Leaf owners stand to benefit significantly from
ACC if we can figure out how to do that.

    Tom

On 6/16/14, 11:40 PM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:

Matt,

> Firstly, adding a directly connected display means that the OVMS unit has to
> be mounted in clear view, not behind the dash.

Yes, that is my concern. For my personal use case, I already have 3 displays
in my car (the little VDS, a 2DIN Asteroid Parrot, and an iPhone) - not
counting the speedometer. I could use either the Parrot or iPhone for an
OVMS display without much impact to my daily routine.

So, I'm interested in the requirement for non-smartphone displays. I heard
this originally from the Twizy owners, but it seems Tom sees a use as well.

>  I think it would significantly help to ... (snip) ...  allow an OVMS
> developer to easily co-operate with an EV owner that may not be physically
> close by to read CAN data and try new code

Yes. My exact thinking.

My day job is CTO of a company that manages thousands of remote device in
the field. It is amazingly efficient to be able to remotely connect for
diagnostics and support.

If an owner can just buy and install an OVMS module, with the developer
working remotely, we could leverage this much more.

Regards, Mark.

On 17 Jun, 2014, at 1:52 pm, Matt Beard <matt at beard.tv> wrote:

> A couple of comments.
> 
> Firstly, adding a directly connected display means that the OVMS unit has to
> be mounted in clear view, not behind the dash.
> 
> Secondly, as more EVs get released there needs to be a solution to the problem
> that at the moment an OVMS developer needs to buy an EV of a particular model
> before there is any real hope of getting support for that type. Alternatively
> an owner of such an EV needs to be converted to being a developer. I think it
> would significantly help to a) lower the bar to becoming an OVMS developer
> (such as removing the need to buy lots of extra kit and spend much time
> installing/removing hardware from the car, or driving with laptop attached the
> car) and b) allow an OVMS developer to easily co-operate with an EV owner that
> may not be physically close by to read CAN data and try new code (so log CAN
> data and download details over GSM or 3G and load firmware remotely)
> 
> Matt Beard
> 
> 
> On Tuesday, June 17, 2014, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> 
>> What I'm wondering is how valuable it would be to have a device in the car
>> capable of:
>> 
>> * logging can bus traffic to SD card
>> * logging can bus traffic remotely (over wifi, etc)
>> * Issuing CAN bus requests remotely
>> * Receiving firmware updates remotely
>> 
>> And, what if that device was OVMS itself?
>> 
>> I know that when I am developing for OVMS, I spend a tremendous amount of
>> time switching between OVMS and a CAN bus logger. Also, removing OVMS to
>> program it, and plugging it back in again. My lousy cellular reception at
>> home doesn't help (although has probably helped OVMS deal with lousy cellular
>> reception situations quite well). My ideal device would be in the car always.
>> It would allow me to log all traffic (or selected traffic with an easy
>> start/stop/trigger), and remotely download those logs. It would allow me to
>> make a change to the firmware, remotely, and see the impact. The issue would
>> be doing all that while keeping security high as well as power consumption
>> and price low.
>> 
>> Regarding the display, could this be bluetooth to an Android/iPhone? Or, do
>> we need a physical display? With most of the device nowadays, adding a
>> directly attached display is not too hard (and not too expensive) so long as
>> it is on ribbon cable less than perhaps 6" away. But, if a remote display is
>> required, that tends to drive up the price dramatically. It seems that the
>> CPUs nowadays can directly control a display. But, if you want to run a
>> remote display than you have to use UART (or something like that) and then
>> run a separate CPU in the display itself.
>> 
>> Regards, Mark.
>> 
>> On 17 Jun, 2014, at 1:20 pm, Tom Saxton <tom at idleloop.com
>> <javascript:_e(%7B%7D,'cvml','tom at idleloop.com');> > wrote:
>> 
>>> I think it's incredibly valuable to keep the $100 price point.
>>> 
>>> It seems to me that the hard part of adding support for other vehicles is
>>> figuring out the CAN bus codes. That's ideally done with hardware
>>> optimized for that task, which is probably not the OVMS device. There's so
>>> much framework already in place that once you know how to read values and
>>> issue commands, getting that into OVMS isn't that hard.
>>> 
>>> Making OVMS more expensive to better serve the developer community will
>>> make it a harder buying decision for end users. Hopefully, we'll
>>> eventually have thousands of users for every developer.
>>> 
>>> It would, of course, be an improvement to make firmware updates easier for
>>> end users, that is an important issue.
>>> 
>>> I would like to see some sort of display, either on the box or remote, so
>>> I can see SOC in the car without using a phone.
>>> 
>>>    Tom
>>> 
>>> -----Original Message-----
>>> From: Lee Howard <lee.howard at mainpine.com
>>> <javascript:_e(%7B%7D,'cvml','lee.howard at mainpine.com');> >
>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk
>>> <javascript:_e(%7B%7D,'cvml','ovmsdev at lists.teslaclub.hk');> >
>>> Date: Monday, June 16, 2014 at 11:55 AM
>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk
>>> <javascript:_e(%7B%7D,'cvml','ovmsdev at lists.teslaclub.hk');> >
>>> Subject: Re: [Ovmsdev] OVMS v3
>>> 
>>>> I want to say "amen" to both Kevin's and Matt's comments.
>>>> 
>>>> Right now it's really only fully useful for Roadster (and Model S)
>>>> owners.  Volt/Ampera owners (and Leaf and Twizzy?) can remotely get a
>>>> limited amount of incredibly useful information (like SOC), but the
>>>> degree of control that the Roaster owners have isn't there (locking,
>>>> unlocking, pre-heating/cooling, etc.).
>>>> 
>>>> I intend to develop-in some of these features over time - at least for
>>>> Volt/Ampera, and the only thing that has me not yet doing that is my
>>>> need to get up-to-speed on the development environment and methods.
>>>> 
>>>> However, even if all of the features available to Roadster owners were
>>>> there for everyone, there is still so much more potential, as Kevin and
>>>> Matt have said.
>>>> 
>>>> If something isn't done to enable the expanded use then OVMS will
>>>> continually only cater to a limited audience: one that wants access to
>>>> various remote-control and remote-tracking features, but with limited
>>>> local (in-car) usability and limited developer appeal.
>>>> 
>>>> Thanks,
>>>> 
>>>> Lee.
>>>> 
>>>> -- 
>>>> *Lee Howard*
>>>> *Mainpine, Inc. Chief Technology Officer*
>>>> Tel: +1 866 363 6680 | Fax: +1 360 462 8160
>>>> lee.howard at mainpine.com
>>>> <javascript:_e(%7B%7D,'cvml','lee.howard at mainpine.com');>  |
>>>> www.mainpine.com <http://www.mainpine.com/>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> <javascript:_e(%7B%7D,'cvml','OvmsDev at lists.teslaclub.hk');>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> <javascript:_e(%7B%7D,'cvml','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/20140617/a279dc26/attachment.htm>