[Ovmsdev] Car firmware: 1.2.5
davemorse at morsecentral.com
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.
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
> Moving digital speedo out of experimental and make it available in production units
> Items ,  and  are relatively easy and what I'm working on now.
> Item  is tricky because we haven't found the status update message on the bus yet. Still looking. Item  needs the algorithm and lookup table. Item  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  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:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev