[Ovmsdev] Car firmware: 1.2.5

Sat May 12 23:22:22 HKT 2012

Thank you all for working on this. I'm just an end user so can't contribute much more than comments but am looking forward to the cool down feature. I am curious though, does anyone have evidence that the cool down feature in beneficial?  If so, I wonder why this is something Tesla never implemented. Thanks. 

David

Sent from my iPad

On May 12, 2012, at 9:33 AM, "Oliver Weidmann" <oliver at sdds.ch> wrote:

> A guy from Switzerland has a working homelink. I’ll have to ask him how he managed to successfully pair it…
>  
> Von: ovmsdev-bounces at lists.teslaclub.hk [mailto:ovmsdev-bounces at lists.teslaclub.hk] Im Auftrag von Pierre Uhl
> Gesendet: Samstag, 12. Mai 2012 13:39
> An: 'OVMS Developers'
> Betreff: Re: [Ovmsdev] Car firmware: 1.2.5
>  
> Re Homelink
>  
> The Homelink in Europe is disabled, because the frequency in Europe is not the same like in the US (FCC regulation?).
>  
>  
> Von: ovmsdev-bounces at lists.teslaclub.hk [mailto:ovmsdev-bounces at lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson
> Gesendet: Samstag, 12. Mai 2012 13:22
> An: OVMS Developers
> Betreff: [Ovmsdev] Car firmware: 1.2.5
>  
>  
> I've committed to github car firmware v1.2.5.
>  
> Changes since v1.2.2 include:
>  
> Support multiple vehicle configurations - TeslaRoadster and VoltAmpera
> New LED indication scheme, and net driver tidy-ups
> Auto-support Tesla Roadster v1.5 cars
> Issue #38 - Prevent user from locking car if car is ON
> Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode
>  
> Please don't get too excited - this doesn't support Volt/Ampera yet - we're just laying the ground work for that support, as some European developers are about to start work on it.
>  
> I don't think this release will make it to end-users in its current form. I'm still working on some features to go in, including:
>  
> Drive logging
> Charge logging
> Timed (delayed) charging mode commands
> Timed charging status feedback
> Complete-charging-by charging mode
> Cooldown
> Moving digital speedo out of experimental and make it available in production units
>  
> Items [1], [2] and [3] are relatively easy and what I'm working on now.
>  
> Item [4] is tricky because we haven't found the status update message on the bus yet. Still looking. Item [5] needs the algorithm and lookup table. Item [6] is easy to do, but needs the thresholds defined (what battery temperature to cooldown from, what battery temperature to stop cooldown at, and what current/voltage to use for cooldown).
>  
> Item [7] seems reasonable now, given the number of cars now using the digital speedo feature and the complete lack of issues seen with it.
>  
> I notice there was some discussion on the TMC forum about homelink control. That would be pretty easy to do, but we don't have homelink modules here in Hong Kong, and I don't have the can bus codes. They are probably easy to find on ID#102. If someone with a usb-can and a homelink adaptor wants to get the codes, I'm very willing to put them in. It certainly is a cool feature.
>  
> So, I'm not sure what will make it into what release, when.
>  
> This v1.2.5 release is definitely developers-only, and intended to check stability of the modem driver revisions and usability of the new LED feedback scheme. It is fully backwards-compatible with v1.2.2, and you can upgrade/downgrade firmware as you need.
>  
> It is in my car now, and seems to be ok. I would be grateful if developers with some time could try it out and let me have feedback on overall stability and usability of the new LED indication scheme.
>  
> I've got a little youtube video demonstrating this:
>  
> http://www.youtube.com/watch?v=MdsB8qK6beY
>  
> The new LED indication scheme is as follows:
>  
> When first powered on, the red led stays on, and the green led blinks the version of firmware in the module (e.g.; 1, 2, 5). After that, it enters normal mode.
> In normal mode, the green led is used to indicate the state, and the red led is used to indicate the last error.
> If the modem needs to be reset, both red and green leds are turned on for the couple of seconds it takes to reset the modem.
>  
> The following states are defined:
> // LED MODES
> #define NET_LED_WAKEUP       10    // Attempting to wake up the modem
> #define NET_LED_INITSIM1     9     // Checking SIM card insertion status
> #define NET_LED_INITSIM2     8     // Checking SIM card PIN status
> #define NET_LED_INITSIM3     7     // Initialising modem
> #define NET_LED_COPS         6     // COPS initialisation
> #define NET_LED_NETINIT      5     // GPRS NET initialisation
> #define NET_LED_NETAPNOK     4     // GPRS APN is OK, final init
> #define NET_LED_NETCALL      3     // GPRS Network call
> #define NET_LED_READY        2     // READY state
> #define NET_LED_READYGPRS    1     // READY GPRS state
>  
> The normal behavior is it will start at 10 green blinks and count down to 2 (GSM only) or 1 (GPRS). If GPRS lock is lost, but GSM is still up, the green will blink 1.
>  
> The followed error codes are defined:
> // LED ERRORS
> #define NET_LED_ERRLOSTSIG   1     // Lost signal
> #define NET_LED_ERRMODEM     2     // Problem communicating with modem
> #define NET_LED_ERRSIM1      3     // SIM is not inserted/detected
> #define NET_LED_ERRSIM2      4     // PIN lock on the SIM
> #define NET_LED_ERRCOPS      6     // COPS GSM lock could not be obtained
> #define NET_LED_ERRGPRSRETRY 7     // Error (maybe temp) during GPRS init
> #define NET_LED_ERRGPRSFAIL  8     // GPRS NET INIT failed
>  
> The error code is cleared (red led turned off) once everything is ok.
>  
> Regards, Mark.
>  
> _______________________________________________
> 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/20120512/c9ebee5f/attachment.htm>