May 2012 - OvmsDev - Open Vehicles

Charge Timing Feature Suggestions
by Bennett Leeds 21 May '12

21 May '12

I'd like to see a "Ready By" feature that also takes into account electricity pricing tiers and battery SOC. I see two scenarios: 1) Daily/commuter charging that leverages off-peak for saving money and reducing demand on the grid, and also doesn't keep the battery full longer than necessary (although this isn't really a problem I've heard). 2) Long trip charging where you don't want the car sitting at Range full for any longer than necessary, and also want to leverage off-peak periods. Here's how I've imagined them working: 1. You tell the car when the off-peak periods are. I think 4 params would be sufficient: a. weekday off-peak start time b. weekday off-peak end time c. weekend off-peak start time d. weekend off-peak end time I know these change with the seasons, but you will just have to reset these twice a year, not a big deal. 2. You set the maximum amperage you can actually draw at this location, unless you've charged here before the and car remembers and OVMS has access to that information. 3. For the commuter version, you then set the time you leave each weekday morning - the Ready-By time. The car starts charging as late in the off-peak period as possible that finishes either by the end of the off-peak period or by the time you're leaving. We may want to have it finish a 45 minutes earlier to enable battery balancing. We use the SOC and max amperage draw to figure out when to start. If we need to start before the off-peak to make the Ready-By time, we do that - better to spend more than not have a full battery the next day. 4. For the long-trip version, you set also set the Ready-By time, but this should include date and time. You might be staying longer than a day and/or only have access to 110 volt charging. The long-trip version does Range mode charging. Here's a proposal for the logic: a. If the Ready-By is during an off-peak period, we start as late as possible to finish on time. If that start isn't during the off-peak time, we see if there's an earlier off-peak period in which we can start, stop when that off-peak ends, then resume during the last off-peak period. If there is no earlier off-peak time, then we start when we need to start to finish on time. b. If the Ready-By is outside an off-peak period, then we first look to see if there's an off-peak period before the Ready-By. If there is, we charge to Standard Mode full by the end of that off-peak period, and then start again as late as possible that still finishes the Range charge by the Ready-By (regardless of peak periods). If this won't get us ready by the Ready-By, then look for an earlier off-peak time to do some charging. If there is no earlier off-peak time then we just start charging so that we'll finish by the Ready-by. This will at least make maximum use of the off-peak period we do have plus not have the car Range full for longer than we need. I know this is pretty complicated. It would be simpler to ignore the tiered pricing and just have the car ready by the Ready-By date/time in whichever mode you want (Standard or Range). And maybe that's the first way this should be implemented. But, for leaving from home, it'd be good to accomodate when you're leaving with getting as much charging done off-peak with not having the battery too full for too long. You can call it "Bennett's Anal Trip Charge Planner." ;^) - Bennett

1 0

Aggressive cellular network timeouts
by Mark Webb-Johnson 20 May '12

20 May '12

I've been working on a weird problem with a Tesla in Guam. Yep, they have Teslas in Guam, apparently. Anyway, the problem is the user gets weird app behavior with the car disconnected a lot of the time. A lot of hunting later, and I find his car reconnects regularly every ten minutes. The old connection is still open to the server (not torn down), and a new connection appears almost exactly ten minutes after the first one. Not an issue for the server (as it interprets that correctly and kicks off the first connection), but uses up bandwidth anyway and means the car is often disconnected (especially if you contact the car in the top half of the ten minute window. More hunting, and I find 2 others cars with similar behavior. I'm chasing down the owners to find what cellular provider they use to see if there is anything in common. It seems that the cellular providers are killing the OVMS TCP/IP connection after ten minutes (or so). A google search came up with this: http://web.eecs.umich.edu/~zmao/Papers/netpiculet.pdf (search for "10 minutes" in the document to find the relevant comment) This seems really dumb, but possible I guess. The solution is to be PING the car from the server, more frequently, but I hate using more bandwidth. Perhaps I can come up with an adaptive algorithm to do this only for cars that connect without disconnection of the previous connection a lot. Anyone heard of this? Regards, Mark.

1 1

iOS App v1.2.8 20120520
by Mark Webb-Johnson 20 May '12

20 May '12

The bad news is Tom found a blocking-bug in the v1.2.8 iOS App (20120515). A nasty problem affecting new installs, with an even more nasty workaround. Accordingly, I've had to pull it from Apple's review queue (they hadn't got to it anyway) and submit a new binary - presumably back to the back of the queue? I've also released to testflightapp. The good news is Felix had two minor UI bugs, fixes for which have made it into this release :-) Regards, Mark. Open Vehicle 1.2.8 (20120520) Team: Open Vehicles What's New: v1.2.8 UI improvements (20120520) - 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 - Remove Model S images - Change default image of DEMO car to a Tesla Roadster - Change default ovms server to tmc.openvehicles.com Released: May 19, 2012 Expires In: 6 months, 1 week Size: 7.6 MB

1 0

Re: [Ovmsdev] Car lost GPRS connection notification
by Bennett Leeds 20 May '12

20 May '12

Why is the car losing connection an alert situation? I would think that anything we have to wait an hour before reporting is not urgent. I think the right level is what we have today: the app tells you the last time the server heard from the car as XXX minutes ago. Do you have some particular scenario in mind where the alert is useful? - Bennett

2 1

Re: [Ovmsdev] Car lost GPRS connection notification
by mm＠raumgleiter.com 19 May '12

19 May '12

3 2

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