[Ovmsdev] test works, what next

Michael Balzer dexter at expeedo.de
Mon Jan 7 15:41:01 HKT 2013


Nikolay,

OK, a bit more detail :-)


Am 07.01.2013 08:05, schrieb Nikolay Shishkov:
> In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text.

Use the standard "STAT" message (overloaded) for charge state notifies.

Send other text messages by SMS or by "MP-0 PA...". See Twizy 
notification system on how to do this.


> What "car_" variables I should use for the pack voltage and pack current?
None, those currently are no common properties.

> What "car_" variables I should use for statuses that are not available as a car_variables?
None, use vehicle specific variables until at least Mark agrees on 
adding them to the common set.

> Also the nominal pack temperatures (for the zebra battery) are around 270C (two hundred and seventy Celsius) - any idea if this would be a problem with the current setup?
That's a definite yes, as the temperature vars are currently bytes. That 
also may need to be changed in the common variables. Until then, you 
could do a workaround by re-basing your App readings at e.g. 200 °C, so 
270 can be displayed as 70.

> Eventhough the Tesla and Think are both EVs, they have some significant differences in technology and thus significant differences at what drivers would be interested in seeing.
>
> So should I define my own handling and "think_" parameters, or should I add more "car_" ones?
Add them as "think" vars first, upload your code, then post a suggestion 
what to include into the common set, so we can discuss it.

The common set of properties can be extended and refined, but there 
basically needs to be vehicle specific support in the Apps anyway, and 
that in turn could eliminate the need for most extensions to the common 
set. IMO the common set should cover just the basic functions that can 
be supported by most vehicles. It currently already contains more 
properties than really are common (from the Twizy point of view), so the 
App already will need at least some vehicle feature support matrix.

Regards,
Michael

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130107/51d79d8c/attachment-0002.vcf>


More information about the OvmsDev mailing list