[Ovmsdev] Twizy release 3.0.2

Nikki Gordon-Bloomfield Nikki at littlecollie.com
Sat Jan 18 18:57:57 HKT 2014


Michael,

Great work!

I wonder if there would be a way to use this as a valet mode option? Really
reduce motor settings etc?

Yes, its no Tesla, but more might be useful for some.

Also, could this be used to make the twizy more secure?

I know it has an immobilizer but no locks on the doors, making it perhaps a
target for thieves?

Could OVMS he used to lock down a twizy with really poor parameters?

In other words, if someone does defeat the lock and turn it on, this could
event them from moving the car?
On 18 Jan 2014 08:27, "Michael Balzer" <dexter at expeedo.de> wrote:

> Thanks :-)
>
> There should also be a visible change in crash history records, my crash
> count with the new version is still 0.
>
> The extended mode also has been running 100% fine during the last days, so
> I can also check in some more Twizy & CANopen functionality later on :-)
>
> Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia
> OVMS development going on somewhere: the Twizy tuning commands should be
> easily portable, should just need to be adapted to the other defaults.
>
> Regards,
> Michael
>
>
>
> Am 18.01.2014 03:46, schrieb Mark Webb-Johnson:
>
>> Wow, just wow!
>>
>> I’ve been running this (2.6.x code, with Michael’s interrupt handling
>> enhancements, and a switch to extended mode compilation) in my car and the
>> difference is amazing.
>>
>> The best indicator I have of interrupt performance is the digital speedo
>> in the Tesla Roadster. That relies on picking up the transmission of a
>> single CAN bus message, then following it up very quickly with a sequence
>> of 3 override CAN bus messages. Previously it was ok, but now (with the new
>> Interrupt code) it seems much much smoother.
>>
>> Well done, Michael! Great contribution.
>>
>> I’ll be fixing up the compiler warnings (just a difference in ‘static’ vs
>> ‘auto’ storage mode in extended mode) and then will commit the switch to
>> extended mode to the repository as 2.6.2. I should get this done today.
>>
>> Regards, Mark.
>>
>> On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter at expeedo.de> wrote:
>>
>>  Mark,
>>>
>>> I now also have compiled in extended mode (got no choice). I only get
>>> some warnings about static function args, not sure if they need to be
>>> static, doesn't seem so.
>>>
>>> First tests have been completely fine in both diag and live mode, so
>>> I'll use the extended mode firmware during the next days to see if anything
>>> goes wrong.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
>>>
>>>> Not sure if we can use extended mode or not - if we can, it will give
>>>> us a lot of breathing room. If I enable extended mode, everything compiles
>>>> just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised
>>>> extended instruction set.
>>>>
>>>> Regards, Mark.
>>>>
>>>>  --
>>> 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
>
>
> _______________________________________________
> 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/20140118/7ec0ffb4/attachment.html>


More information about the OvmsDev mailing list