[Ovmsdev] Car firmware: 1.2.5

Michael Stegen michael at stegen.com
Wed May 16 03:35:05 HKT 2012


I also have homelink on my car, and a garage door to test it on, so i'll 
give it a try asap.

Regards,
Michael

Op 13-5-2012 4:24, Mark Webb-Johnson schreef:
> To track down the homelink messages, we'd need someone with both 
> homelink and a way to capture can bus messages (a USB CAN bus tool).
>
> I have the tool, but the cars in hong kong have no homelink module 
> installed.
>
> The capture itself should be fairly simple. I'd put money on the 
> messages being on ID#102, and there are a very limited number of those 
> messages.
>
> Regards, Mark.
>
> On 13 May, 2012, at 12:25 AM, 911carrera4 wrote:
>
>> Hallo everybody
>> I was able to configurate the HomeLinks on both our EU-Roadsters (my 
>> wife's and mine). We have two garages with two doors. For the opening 
>> of the doors we use a german product called  maraton 1100SL (the 
>> company is Sommer, D- 73230 Kirheim)
>> I did it in two steps:
>> 1.I sent the code from the garage remote control to the Roadster (as 
>> described in the Tesla manual "How to configurate HomeLink")
>> 2.I paired (linked) the HomeLink from the Roadster to the control 
>> panel of the garage door (as described in the manual you get with 
>> your garage door control pannel)
>> That's all. It works good, but the range is  a bit shorter than with 
>> the original remote control.
>> The frequency of the System is 868Mhz (without external antenna).
>> Piotr
>> *Von:*ovmsdev-bounces at lists.teslaclub.hk 
>> <mailto:ovmsdev-bounces at lists.teslaclub.hk>[mailto:ovmsdev-bounces at lists.teslaclub.hk]*Im 
>> Auftrag von*David Morse
>> *Gesendet:*Samstag, 12. Mai 2012 17:22
>> *An:*OVMS Developers
>> *Betreff:*Re: [Ovmsdev] Car firmware: 1.2.5
>> 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 
>> <mailto: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>[mailto:ovmsdev-bounces at lists.teslaclub.hk]
>>     <mailto:[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>[mailto:ovmsdev-bounces at lists.teslaclub.hk]
>>     <mailto:[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:
>>
>>      1. Drive logging
>>      2. Charge logging
>>      3. Timed (delayed) charging mode commands
>>      4. Timed charging status feedback
>>      5. Complete-charging-by charging mode
>>      6. Cooldown
>>      7. 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:
>>
>>      1. 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.
>>      2. In normal mode, the green led is used to indicate the state,
>>         and the red led is used to indicate the last error.
>>      3. 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 <mailto:OvmsDev at lists.teslaclub.hk>
>>     http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto: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


-- 
Stegen Electronics
Kwartslaan 95
3162 RD Rhoon
The Netherlands

Tel: +31 10-5016960
www.stegen.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120515/f0c0f4d3/attachment.htm>


More information about the OvmsDev mailing list