[Ovmsdev] v2.2.6
Michael Balzer
dexter at expeedo.de
Wed Apr 3 21:25:19 HKT 2013
Nikki,
no, that's too far below average... just kidding ;)
FYI: my usage averages at only 90 miles/week, top average in the german
forum has been around 300 miles/week. I read about a german pizza
delivery service using several Twizys each now around 15.000 miles --
they needed to replace their brake discs... recuperation is not strong
enough for pizza boys it seems ;)
Thanks!
Michael
Am 03.04.2013 15:03, schrieb Nikki Gordon-Bloomfield:
> Michael, Mark.
>
> I'm going to be doing about 150 miles a week in my Twizy from next week. Does this count as being a thorough enough test? ;)
>
> Nikki.
>
>
> On 3 Apr 2013, at 13:49, Michael Balzer <dexter at expeedo.de> wrote:
>
>> Mark,
>>
>> I once looked up the stack issue and found it as being reserved outside the variable RAM, so basically we can get to zero. I think your memory map linker option also confirmed this. I and the other german users have had this config in our Twizys for many months now without any problems.
>>
>> A special config is an option if there is a problem, but that means Twizy OVMS users will need to flash their modules if they want full functionality. I think we should deliver factory OVMS with full functionality if possible.
>>
>> Also, as all battery monitor ram usage is in the overlay section, the other car modules should not be affected (and can use that space for their own purposes later on).
>>
>> How about an extended test from all developers using the full featured firmware to see if there are really any problems with this -- I don't think so.
>>
>> Regards,
>> Michael
>>
>>
>> Am 03.04.2013 14:19, schrieb Mark Webb-Johnson:
>>> Michael,
>>>
>>> I just checked, and that OVMS_TWIZY_BATTMON takes ram from 426 bytes free to 208. A little bit scary, given that I am about to add the trip logging functions. I'm really not sure what happens with the stack, and if it is counted in those 208 bytes. Can we get to zero?
>>>
>>> But, I see this as a useful function for Twizy owners.
>>>
>>> How about I create a new firmware config V2_FullTwizy that includes just the Twizy module but also OVMS_TWIZY_BATTMON?
>>>
>>> Regards, Mark.
>>>
>>> On 3 Apr, 2013, at 5:54 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>>
>>>> Nikki,
>>>>
>>>> for the Twizy: I think the V2 "developer version" still does not include the battery monitor -- I had to add the compiler switch again after my last local merge.
>>>>
>>>> If you compile yourself, check the configuration for the OVMS_TWIZY_BATTMON define.
>>>>
>>>> Or let me know if you need a precompiled image.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 02.04.2013 22:08, schrieb Nikki Gordon-Bloomfield:
>>>>> I'll be updating it tomorrow!
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2 Apr 2013, at 20:35, Tom Saxton <tom at idleloop.com> wrote:
>>>>>
>>>>>> Links to the v2.2.6 firmware are now up on my firmware download page:
>>>>>>
>>>>>> http://www.idleloop.com/tesla/ovms/
>>>>>>
>>>>>> The release notes link points to the entry for v2.2.5, which is probably
>>>>>> close enough.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> on 4/2/13 5:48 AM, Mark Webb-Johnson wrote:
>>>>>>
>>>>>>> I was getting 12v alerts in my roadster. I don't think the new logic is
>>>>>>> compatible with the roadster battery behaviour.
>>>>>>>
>>>>>>> Anyway, I've rolled v2.2.6 with the following changes:
>>>>>>>
>>>>>>> 2013-04-02 2.2.6 Firmware 2.2.6
>>>>>>> ## Volt Ampera fixes (from Michael)
>>>>>>> ## Support net_fnbits NET_FN_12VMONITOR and
>>>>>>> NET_FN_SOCMONITOR to allow vehicle module to control what is monitored
>>>>>>>
>>>>>>> I brought in the Volt Ampera fixes pending from Michael (some changes to the
>>>>>>> source of SOC).
>>>>>>>
>>>>>>> I also added NET_FN_12VMONITOR and NET_FN_SOCMONITOR to net_fnbits, to allow
>>>>>>> the vehicle modules to turn on/off those monitoring. I changed the vehicle
>>>>>>> modules appropriately (in particular 12VMONITOR is off in the Tesla Roadster,
>>>>>>> and SOCMONITOR is off in the Volt/Ampera).
>>>>>>>
>>>>>>> Now testing this v2.2.6 in my car, but it will likely be 24 hours before I
>>>>>>> know if it is behaving better.
>>>>>>>
>>>>>>> Regards, Mark.
>>>>>>>
>>>>>>> On 1 Apr, 2013, at 6:59 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>>>
>>>>>>>> This is now in my car, and running well.
>>>>>>>>
>>>>>>>> For CAC, I had:
>>>>>>>>
>>>>>>>> rx msg S 66,K,222,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,0
>>>>>>>>
>>>>>>>> then, I started a charge, and now get:
>>>>>>>>
>>>>>>>> rx msg S 66,K,223,0,charging,standard,206,200,56,0,100,0,5,1,0,0,0,-1,15694
>>>>>>>>
>>>>>>>> That's what I would expect - the code will poll for latest CAC whenever (a) a
>>>>>>>> charge starts, (b) the car is turned on, or (c) the car is turned off.
>>>>>>>>
>>>>>>>> Regards, Mark.
>>>>>>>>
>>>>>>>> On 1 Apr, 2013, at 5:30 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>>>>
>>>>>>>>> Back from the brinkŠ Good grief, there is some nasty stuff coming out of
>>>>>>>>> China now.
>>>>>>>>>
>>>>>>>>> I managed to spend some time on OVMS firmware today, and built v2.2.5.
>>>>>>>>> Change log is:
>>>>>>>>>
>>>>>>>>> 2013-04-01 2.2.5 Firmware 2.2.5
>>>>>>>>> ### Fixes for charge notification logic on VA
>>>>>>>>> ### Show charge, trunk and alarm notifications in
>>>>>>>>> DIAG mode
>>>>>>>>> ### Speed, parking, and general tidy-ups for VA
>>>>>>>>> ### Switch ambient temperature to PID 0x801f for VA
>>>>>>>>> ### Auto-calibration for 12V line reading
>>>>>>>>> ### Twizy version 2.6.1 - power line plug-in
>>>>>>>>> detection
>>>>>>>>> ### Add car_doors5 for rear doors, frunk and 12v
>>>>>>>>> charging
>>>>>>>>> ### 12v alert by MSG protocol fix
>>>>>>>>> ### Rework of 12V reference logic
>>>>>>>>> - Filters out single peaks / misreadings
>>>>>>>>> - Sends "OK" alerts if voltage level restores w/o
>>>>>>>>> charging
>>>>>>>>> - 15 minutes calmdown before taking new ref
>>>>>>>>> voltage
>>>>>>>>> - No alerts while car is on
>>>>>>>>> ### ESS SOC DIAG (for TR)
>>>>>>>>> ### Initial support for CAC in TR and TZ modules
>>>>>>>>> ### Experimental Tazzari (TZ) module
>>>>>>>>> ### Experimental Nissan Leaf (NL) module
>>>>>>>>>
>>>>>>>>> All is in github.
>>>>>>>>>
>>>>>>>>> I haven't run it in my car yet, but it tests out fine on the bench. It is
>>>>>>>>> going into my car in a few minutes time.
>>>>>>>>>
>>>>>>>>> Major changes are the experimental support for Tazzari, some bug fixes and
>>>>>>>>> 12V work on Twizzy, and support for CAC readings in Tazzari and Tesla
>>>>>>>>> Roadster (including protocol extensions to report back to apps).
>>>>>>>>>
>>>>>>>>> Regards, Mark.
>>>>>>>>>
>>>>>>>>> P.S. I haven't had time to make anything good for 1st April this year
>>>>>>>>> (although I did consider an experimental module for Hummer support). Anyway,
>>>>>>>>> please consider any bugs in this version just an April fools joke.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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
>>>> --
>>>> 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
>> --
>> 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
--
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/20130403/cc43d0db/attachment-0002.vcf>
More information about the OvmsDev
mailing list