- OvmsDev - Open Vehicles

Car firmware v1.2.7
by Mark Webb-Johnson 28 May '12

28 May '12

Inching towards the v1.3.0 release, I've just committed to github v1.2.7 of the car firmware for OVMS. Changelog since v1.2.2 is: 2012-05-27 1.2.7 Preliminary firmware 1.2.7 Bug fix for off-by-one-can-byte bug in roadster id from VIN Add homelink and charge timer support, plus misc fixes Only send non-empty params to PARAMS? sms command Remove need to RESET after can write change Only NETINIT (not SOFTRESET) after a parameter change Re-label parameters internally to match new user-friendly names Re-work of sms command handlers to be table driven - saving 6% of flash Use the 6% of flash we saved to implement a bunch of SMS commands REGISTER? Report on registered phone REGISTER <modulepass> Register caller phone PASS? Report on module password PASS <modulepass> Set new module password GPS?/GPS [<modulepass>] Report GPS location STAT?/STAT [<modulepass>] Report status PARAMS? [<modulepass>] Report on parameters PARAMS <param2> <param3> .. <paramN> Set parameters MODULE? [<modulepass>] Report on module parameters MODULE <vehicleid> <units> <notifies> Set module parameters GPRS? [<modulepass>] Report on GPRS parameters and status GPRS <gprsapn> <gprsuser> <gprspass> Set GPRS parameters SERVER? [<modulepass>] Report on server parameters SERVER <serverip> <serverpass> <paranoid> Set server parameters DIAG?/DIAG [<modulepass>] Technical diagnostics FEATURES? [<modulepass>] Report on features configured FEATURE <feature> <value> Set specified feature value HOMELINK <button> Activate homelink 0, 1 or 2 LOCK <pin> Lock car (with specified pin) UNLOCK <pin> Unlock car (with specified pin) VALET <pin> Activate valet mode (with specified pin) UNVALET <pin> Deactivate valet mode (with specified pin) CHARGEMODE <mode> <current> Set charge mode (sta, sto, ran, per) and current CHARGESTART [<modulepass>] Start charge immediately CHARGESTOP [<modulepass>] Stop charge immediately VERSION [<modulepass>] Report module firmware version RESET [<modulepass>] Reset module 2012-05-11 1.2.5 Preliminary firmware 1.2.5 LED re-work Support multiple vehicle configurations - TeslaRoadster and VoltAmpera 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 I've managed to do this with very little impact to firmware size. Major user-visible extensions in this firmware include: A huge number of new SMS commands. Support for simplified setup steps (working on with Bennett). New status and error LED arrangement. New diagnostic SMS commands. Various minor bug-fixes and improvements. Homelink support (firmware both SMS and app protocol support - app support will follow). Charge timer support (firmware and app protocol support - app and sms support will follow). This is a major re-work of the SMS sub-system. We now have 27 commands and similar functionality to the GPRS smartphone apps. In particular, charge start/stop and mode setting is now available. I've also added in the homelink commands (courtesy of Fuzzylogic's CAN decoding skills). I've tested this on the bench, and it seems to work. I've also put it in my car 10 minutes ago, and got a network connection. That is pretty much the extent of my testing, so consider this pre-beta and definitely NOT for end-users. I haven't completely tested the setup of a module from scratch with these new REGISTER, PASS, MODULE, SERVER, GPRS commands - I hope Bennett, or someone else, will help with that. I haven't tested homelink support. I hope someone will try that (using SMS "HOMELINK 0" command) and let me know if it works. This is now pretty feature complete for the v1.3.0 firmware. I need to do the CHARGETIMER SMS commands, and want to re-work the social group messages to allow streaming of group location messages (if enabled). So, please test this as you can, and let me know any problems you find. Again, please don't put this on end-user cars yet. There has been a lot go into this and I need a week or so of inevitable bug fixing before it is ready for wider testing. There hasn't been much changes to the net subsystem since 1.2.5, and that seem stable, so I think it is fine to put in developer's cars. Regards, Mark.

3 5

Car remote unlock issue
by Oliver Weidmann 28 May '12

28 May '12

Hi everyone When unlocking my Roadster (2.5, EU-Model) via the OVMS-Android-App, the car acknowledges the unlock-command and unlocks the car (everything seems to work like a charm so far). But after the car is unlocked I cannot open one of the doors without triggering the alarm. As soon as I open the driver or passenger door the alarm goes off. Looks like the OVMS sends the unlock command to the Roadster, but the Roadster does not disable the car alarm system after the unlock. Is that a well knows behavior or can anyone confirm this issue? Thanks Oliver

3 3

OVMS iOS App v1.2.8
by Mark Webb-Johnson 27 May '12

27 May '12

Just approved for release v1.2.8 of the iOS App for OVMS. Enhancements include: 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 This is quite a large update, with a lot of work (and thanks to) Bennett and Felix, as well as testing from a bunch of testflightapp folks. I'd like to point out a few important things: As part of the tidy-up, we've removed the Model S images from the App - so you may have to change the car image for any DEMO cars you have. Social Group support is included - you can now set a group in the car, and see the location of all cars in that group on the map. Streaming mode for location, with direction and movement animation is beautiful. Try car RALLY password RALLY for a demo. We now support MMI/USSD codes. These are like "##107#" and can be used to check cellular balance. If you car is set to "Miles", the temperatures will now appear in Fahrenheit. It should appear in the App stores over the next few hours. Regards, Mark. P.S. This brings the iOS App up to the level of functionality in the Android App. We now hope to work to unify these two apps a bit more, as well as fix the display scaling issues seen by some users of modern high-resolution Android phones.

1 0

Firmware Updates for Non Developers
by Tom Saxton 22 May '12

22 May '12

I've written up instructions for updating the OVMS firmware[/URL] for non-developers. http://www.idleloop.com/tesla/ovms/ I also started a thread on TMC: http://tinyurl.com/cwg265d Developers who want to work on the code have to go through a complex procedure to download the source code and install the tools needed to build and update the firmware. It's a lot of work if you're not going to be partying on the code. Fortunately, there's a much simpler procedure if you just want to update your box to the latest firmware. Once you've been through it once, it's very quick and easy. The hardest part is removing the box from the car and undoing the four screws to get at the circuit board. You'll have to invest about $40 in the gizmo that transfers the bits, but it can be shared if there are other OVMS owners nearby. Tom

1 0

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

20 May '12

On Sat, May 19, 2012 at 8:57 PM, <ovmsdev-request(a)lists.teslaclub.hk> wrote: > > Message: 3 > Date: Sun, 20 May 2012 00:19:35 +0800 > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > Subject: Re: [Ovmsdev] Car lost GPRS connection notification > To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> > Message-ID: <DBFD9B76-BD5E-4E5C-823E-0B473D9EBCE8(a)webb-johnson.net> > Content-Type: text/plain; charset=iso-8859-1 > > Bennett, > > The only benefit for this is for the user to be informed when his car is > offline. > > Not my requirement, but I guess if the user is charging somewhere critical > (e.g. on a trip, in a hotel) and wants to be informed if the charging is > interrupted, he also wants to be informed if the car can't tell him the > charge has been interrupted (because it is offline with no cellular > coverage). > > Regards, Mark. Does cell coverage vary while the car is stationary in one place? I would have thought that having parked the car, plugged in it, and started charging that the owner would check the charge status right then and there on the App. If he couldn't reach the server, or if the car couldn't reach the server, then he'd know that right away and the message an hour later would be either superfluous or too late. On a related note, I do think the App could do a better job of saying where connection problems lie. This would help during installation as well, when users don't really know if the car isn't talking to the server or if the App isn't talking to the server. Once you know how things work you can figure it out, but the newbies installing for the first time don't know. I'm thinking of the App saying for each car when it heard from it last (or ever), as well as the App saying when it last heard from the server (if ever). And, while I'm at it, an SMS message asking the car when it heard from the server last would be useful for debugging configuration issues as well. - Bennett >

2 1

Charge Timing Feature Suggestions
by Bennett Leeds 20 May '12

20 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 19 May '12

19 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 19 May '12

19 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 19 May '12

19 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