- OvmsDev - Open Vehicles

Car lost GPRS connection notification
by Mark Webb-Johnson 19 May '12

19 May '12

Rafael has suggested that we add a car-lost-gprs-connection notification to the OVMS system. The idea being that when your car loses GPRS connection (cellular coverage, fault, whatever), you get a notification to your app to let you know. And, presumably, another notification should it come back. It is common for a car to lose cellular connection for a minute or so, then re-establish. It is also reasonably common to lose connectivity when the GSM signal is lost. It does seem a nice idea, and not too hard to do. The way it would work would be to have a threshold in the server. A notification time, presumably in seconds. If a car disconnected (or 20 minute timeout was force disconnected), we would put a record in a pending table, timestamped NOW()+thresholdseconds. If the car connected, and the pending table has a record for that car, we would just remove the record. If the car connected, and there was no pending table record for that car, we would send a push notification for all apps on that car to tell them that the car is connected. Periodically, we check the pending table and if any records have timed out, we (a) send a push notification for all the apps on that car to tell them that the car has disconnected, and (b) remove the record. The result of this is that if the car disconnects for a short time, then reconnects, no notification is raised. But, if the car disconnects for a long time, you get a notification both when we find it has disconnected and when we see it reconnect. This can all be done from the server, irrespective of version of firmware in the car/apps. The questions are: (a) what do people think, (b) what should a reasonable timeout be, and (c) could this be _on_ for everyone. Would anyone here _not_ want this? I would suggest a reasonable timeout, to alert after, would be an hour or so. It is easier to code this if it is universally on for everyone - we can just have a single timeout in the server. If we want individual control, we'd have to have a setting per-vehicle and provide the users a mechanism to change that setting. That would be much more work. Regards, Mark.

3 4

Re: [Ovmsdev] Car firmware: 1.2.5
by Oliver Weidmann 16 May '12

16 May '12

A guy from Switzerland has a working homelink. I'll have to ask him how he managed to successfully pair it. Von: ovmsdev-bounces(a)lists.teslaclub.hk [mailto:ovmsdev-bounces@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(a)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: * 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.

7 11

iOS App 1.2.8
by Mark Webb-Johnson 15 May '12

15 May '12

I still have a lot to be done on the iOS App, but so much has been done over the last month or so, that I want to get something out. So, here it goes... I've labelled this version v1.2.8 and have just issued a testflightapp release, as well as submitted to Apple for approval. v1.2.8 UI enhancements (20120515) - Retina vehicle images - Current weather situation indicator - Location vehicle animations - Location lock-to-my-car feature - Location Groups support (preliminary) - UI revamp - App version shown in vehicle info display - Move Control button to car detail screen - Move Info button to car selection screen - Move GSM signal bars to car selection screen - Show car direction on location map - Support display and control of a timer-delayed charge - Use pump status for temp stale - Charge port animations - Stale indicators for ambient, pem, motor, battery and tpms - Various minor bug-fixes and stability enhancements - Cache weather icon - Auto-reconnect 10 seconds after server disconnect - Tidy up parameter naming - Support MMI/USSD codes from iOS App - "Imperial" Temperature display in iOS App - Minor layout revisions - Bring iPad version up to same level as iPhone I'll continue to work on it, but that (in particular the support for Fahrenheit temperatures) should keep people happy... Regards, Mark.

1 0

Mileage and consumption
by Rens Meijer 15 May '12

15 May '12

Hello Mark and other OVMS developers, Last week I was doing some tests how much kWh I could get out of the battery compared to the range. Also I am interested in how much KWh it needs to recharge the battery compared to the consumption. One of the tests was I charged in standard mode and drive to almost empty, write down the kWh consumed on the VDS trip screen and recharged in standard mode. I had some interesting results: After driving about 251 km doing 161 Wh/km it consumed about 40,5 kWh The VDS will show an ideal range and estimated range of 0 km, but by experience I know there is still juice left in the battery, but thanks to the OVMS app we can know still see how much is still left and feel a little more at ease, if we just need to go the extra mile to the charging station :) I attached a screen shot from the iPhone app and I must admit I giggled when I saw it first time. Let this be the future: 6552 km on one charge! But I think we hit a division by zero or something here. Another interesting remark I configured the minimum state of charge feature at 7%, hoping that it would send me warnings. But even when I hit 6% there was no warning. Could you explain how this feature works? Overnight I charged the car in standard mode and the next morning it showed on my kWh meter in my charging equipement and on the VDS that it used 52 kWh (so it seems to be quite accurate), but I only consumed 41 kWh during driving. My feeling is this is quite high, but I have not much data to compare this. So I stared to make note of the driving consumption and the charging consumption. To see with different mileage how much the losses are during charging. So this brings me to my question is there a way we can log or export the charging and consumption data by means of the OVMS application? This would make it easier to gather the statistics. I am also interested if someone has information or an explanation for the result I am measuring. One last question: could you explain the social group option within OVMS? Is this a way that other OVMS drivers could share their data? Then a big thank you to all involved creating the OVMS, I really love the digital speedo meter in the dashboard. I could not do without it anymore. BTW If any of the OVMS followers in Europe are going to: Tesla Motors Club ‏ @TeslaMotorsClub<http://twitter.com/#!/TeslaMotorsClub> 2. RWE eRace, Nürburgring as supporting program for 24h-Rennen Nordschleife 19.5.2012 http://bit.ly/ItauNN<http://t.co/OkgjBDfa> #tesla<http://twitter.com/#!/search/%23tesla> #ev<http://twitter.com/#!/search/%23ev> Please let me know. I am going so maybe we can meet at the event. Met vriendelijke groet / Best regards, Rens Meijer

3 2

Re: [Ovmsdev] Car firmware: 1.2.5
by Mark Webb-Johnson 12 May '12

12 May '12

Pierre, I think this should help you and I a lot. The codes show status quite well, and while it takes some time to get used to counting them, the result is quite clear. The two most annoying issues of sim not inserted/recognized and pin lock are both clearly alerted on. Regards, Mark On 12 May, 2012, at 7:38 PM, "Pierre Uhl" <pi.uhl(a)bluewin.ch> wrote: > 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(a)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: > > 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(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

1 0

Car firmware: 1.2.5
by Mark Webb-Johnson 12 May '12

12 May '12

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.

2 1

OVMS Not Responding
by Tom Saxton 11 May '12

11 May '12

Our Roadster has been parked for 9 days (since 4/26). When I open the OVMS iPhone app, I see on the Battery screen a flashing antenna in the upper right with a red ball at the top and red text below that says "43 hours". In the upper left it says "P 8 days". When I finished the most recent drive, the SOC was 88%, 168 ideal. This morning when I looked at the car it read 83% and 158 ideal. Then I started a charge. The OVMS app shows 84% and 160 ideal, so it's probably a couple of days old. I get no response when sending an SMS message. So I figured the OVMS box had lost contact, and needed to reboot, but just for fun, I logged into AT&T to see when it stopped sending data. It hasn't! It's been sending data every day for the past month, including 5 burts today from 1KB to 19 KB. The most recent activity I saw was when it forwarded a spam text to me on 4/29. Any thoughts on what's going on, or anything I should do before I reboot it? Tom

2 4

Flashing Lights
by Mark Webb-Johnson 10 May '12

10 May '12

I've been getting frustrated lately trying to help users diagnose problems early-on in the GSM connection sequence. We've had problems with SIMs cards getting recognised (broken sim cards), with sim locks (PIN lock on), with general modem comms issues, and with lack of GSM signal - and all these show up as the same red flash, red solid, red flash, red-green-alternate indicators. Without getting out a USB-serial cable and laptop, it is real hard to diagnose. Talking this through with Bennett, and others, I think we can do better, and I suggest the following changes: Take the LED control out of the individual code files and have them controlled by a central module with its own timer. This module would be told at a high level what to do with the LED (eg; make the green led flash 7 times) and would make it so. Both LEDs off would indicate NO POWER. On startup, animate both LEDs for a short time to demonstrate that they both work. Change init code to (a) use AT to verify modem is connected, (b) check for SIM connected and readable, (c) check for SIM PIN lock, (d) initialize modem to our required settings, and (e) AT+COPS for cellular signal search. By splitting this up, to separate check states, we can individually alert on a failure at a particular state. In general, use the green LED to show status, and the red LED to show the last error (cleared whenever a state is successful). On startup, you would see the green led count up through each stage, and if it got stuck at a particular stage the blinks would tell you where it is. If there was an error at any stage, the red LED would indicate the error code. For blinking, I suggest just off for a second, then rapidly blink the code, then off for a second, then rapidly blink the code, etc. Once we reach a final GOOD state (either GSM with GPRS disabled, or GPRS connected to server), we would just turn both LEDs to a steady blinking pattern (perhaps on for a second, off for a second). As well as the obvious clarity to diagnostics that this brings, it would also be for general use to see at a glance if the module is working correctly and is connected to the server ok. What do people think? Regards, Mark.

4 6

SIMs
by Mark Webb-Johnson 09 May '12

09 May '12

Has anyone had any experience with these: http://www.gosim.com/ Or others like them? That offer global data roaming for @US$1/MB, supposedly with no expiration date so long as you use the card. I know there is rounding involved, but that seems like a simple approach. Regards, Mark

1 0

NL t-mobile apn
by Mark Webb-Johnson 09 May '12

09 May '12

Anyone know the correct apn, username and password for this? Begin forwarded message: > > Parameter command I used: > PARAMS K SMS,IP 64.111.70.40 http://pda.t-mobile.nl - - ... > Any idea what to check?

2 1