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@lists.teslaclub.hk [mailto:ovmsdev-bounces@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:
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:
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:
The new LED indication scheme is as follows:
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.