[Ovmsdev] Car firmware: 1.2.5

Mark Webb-Johnson mark at webb-johnson.net
Wed May 16 20:07:12 HKT 2012


Michael,

I like easy ones ;-)

Is message length 3 bytes?

Also, there are 3 possible home link devices, right?

Could the 0x02 message be a wake up (something like the ID#102 B1=0x0a message)?

Can you send me a CSV log to use to replay for testing?

Thanks, Mark

On 16 May, 2012, at 6:16 PM, Michael Stegen wrote:

> 
> Homelink is on ID #102 as expected, Sub ID is 0x09
> 
> B1= 0x09
> B2= 0x00
> B3= 0x00    (for first Homelink device, 0x01 for second)
> 
> There is also another message on the Can bus just before this message, it's 0x09 0x02 0x00, not sure if it's important.
> 
> I tried sending 0x09 0x00 0x00 back, and it opened/closed my garage door.
> sending 0x09 0x02 0x00 did not do anything.
> 
> -Michael
> 
> 
> 
> 
> 
> 
> 
> Op 15-5-2012 21:35, Michael Stegen schreef:
>> 
>> 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] 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> 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 vonPierre 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 vonMark 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
>>>> _______________________________________________
>>>> 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
>> 
>> 
>> -- 
>> Stegen Electronics
>> Kwartslaan 95 
>> 3162 RD Rhoon
>> The Netherlands
>> 
>> Tel: +31 10-5016960
>> www.stegen.com
>> 
>> 
>> _______________________________________________
>> 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
> <Homelink_open_close.csv>_______________________________________________
> 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/20120516/3ad25c5f/attachment.htm>


More information about the OvmsDev mailing list