[Ovmsdev] Merging in Twizy and Volt/Ampera work

[Mark Webb-Johnson]

Michael,

This should definitely be done in the module.

One suggestion: can we store the smallest seen raw SOC value > 0, and the largest seen raw SOC value, and default these to 13524 (64400*0.21) and 56028 (64400*0.87) at start up.

Then, the formula in the module can be:

SOC% = (value-smallest)/((biggest-smallest)/100)

That would auto-scale and adjust itself as necessary. As SOC is only 0-100, unsigned int16 maths should be sufficient.

The code would be something like:

unsigned int soc_largest = 56028;
unsigned int soc_smallest = 13524;
unsigned int v;

...

v = (can_databuffer[1]+(unsigned int) can_databuffer[0] << 8);
if ((v<soc_smallest)&&(v>0)) soc_smallest=v;
if (v>soc_largest) soc_largest=v;
car_SOC = (char)((v-soc_smallest)/((soc_largest-soc_smallest)/100));

Regards, Mark.

P.S. Not sure what you mean about the iPad App pictures. Please send a screendump to illustrate. Also, please check you have the right picture selected on the car detail screen.

On 4 Nov, 2012, at 11:38 PM, mikeljo at me.com wrote:

> Hi,
> 
> i ask in the german Ampera Forum about the SOC.
> The iPhone App shows minimum 21% to max. 87%. This is the usable Batterie window.
> Now they would have 0-100% in the App.
> As a "quick and dirty" fix i do this in the App:
>  car_soc = ([[lparts objectAtIndex:0] intValue]-21)*(100.0/66.0);  // 21 - 87% = 0 - 100%  1,515151515151515  MJ
>         //car_soc = [[lparts objectAtIndex:0] intValue];  org
> in the ovmsAppDelegate.m
> Yes i know i can divide by 1.515. But for showing what i do, i do it this way.
> It was faster to change it in the App, but i think it is better to do it in the Module.
> One Problem can occur: If the SOC reaches 21% the car switches to the RangeExtender (RE). BUT the SOC can fall to 18%. At the other end, when the batterie is fully charged (SOC 87%) and the car goes downhill the SOC can go to nearly 90% (or more, i don't know).
> What happend with the App? The 21% (0%) i can test tomorow, but i have no so big hill near me. :)
> 
> BTW: the iPad App don't shows any car Pics on the main screen.
> 
> Bye
> michael
> 
> 
> Am 04.11.2012 um 14:21 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
> 
>> 
>>> That wasn't me.
>> 
>> Whoops. Michael Jochum...
>> 
>>> ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?
>> 
>> The Microchip compiler has an 'overlay' facility. We can put them in the same memory bank so they all overlay each other. You are correct - RAM is the concern.
>> 
>>> So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.
>> 
>> 
>> I think the existing model should work for the EVs I've seen. There are some problems that will need to be fixed (e.g.; imperial-only units for ranges), and some extensions made (e.g.; 2 extra doors for saloon style cars), but those are pretty small.
>> 
>> For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).
>> 
>>> l (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled)
>> 
>> Yes, I've noticed that. From what I can see, it is just garbage tacked on the end but I've been meaning to convert this to a better document. We have full revision control on this.
>> 
>>> The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support).
>> 
>> I think that stuff like this is going to be _very_ hard to fit in ram, but does it actually need to be stored? Say we have 16 can bus messages to send out. We could just use a 2byte bit array with a bit high indicating we need the figure. If the message arrives on the can bus, and the corresponding bit it high, it can get queued for transmission directly, then the bit cleared. I'm not sure if that is clear (hard to explain it in writing), but what I'm saying is have a mechanism for the can driver to be able to queue stuff for transmission directly from the incoming can message. So, rather than storing 16 messages for transmission, we don't need to store any - just have a flag to say 'transmit the values when it next comes off the bus'.
>> 
>>> So, maybe the data and protocol models need to be generalized first?
>> 
>> I think it just needs to be documented better, and expanded as necessary. Let's then see how things fit into that. I'll work on this now, as both Michael's need this urgently.
>> 
>> Regards, Mark.
>> 
>> On 4 Nov, 2012, at 8:37 PM, Michael Balzer <dexter at expeedo.de> wrote:
>> 
>>> 
>>> Am 04.11.2012 04:11, schrieb Mark Webb-Johnson:
>>>> A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars.
>>> 
>>> That wasn't me. The idea sounds good, but...
>>> 
>>> - car platforms to be supported will increase steadily now, there are lots to come in the next years
>>> - even cars with decent builtin online monitoring systems lack some functionality for nerds like us
>>> - there will be a need for custom product configuration per car anyway, as cabling and antenna configuration will be different
>>> 
>>> ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?
>>> 
>>> Also, not only the CAN module may need car specific adaption. I've not yet completely read into the server protocol (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled), but got the impression it contains some common and some Tesla specific data. If we have to integrate specific data from every model supported, the data stream can become quite fat. So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.
>>> 
>>> Example: one of my next ideas is a cell monitor to get a history of the cell voltage levels, so I can detect and alert about cell failures early. The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support). The Tesla has an 11S 9S 69P configuration (?), so that would need much more history RAM + possibly another data layout -- if the voltages are on CAN at all.
>>> 
>>> Another example I already stumbled on: the car_doors1 flag 0x04 (charge port open) is currently used by net_sms_stat(), if it's not set, it assumes "not charging". So even some standard functions rely on Tesla specific data.
>>> 
>>> So, maybe the data and protocol models need to be generalized first? Or am I missing something?
>>> 
>>> 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
>> 
>> _______________________________________________
>> 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.teslaclub.hk/pipermail/ovmsdev/attachments/20121105/f8d75869/attachment.html>