- OvmsDev - Open Vehicles

iOS App 1.2.5
by Mark Webb-Johnson 15 Apr '12

15 Apr '12

The iOS App v1.2.5 (20120415) just got released to testflightapp. This is still a work-in-progress. It won't get released to Apple in its current form, but is just for testflightapp testers to get feedback. Most of the UI revamp (working with Felix on this) has been done. I particularly like the charge port animation. Outstanding is the params/features simplification, with advanced settings moved to a "DEV" button. The big thing still missing is the multi-cars team support, which is coming next. Note that there has been a change to the vehicle location view to show the vehicle rotated to reflect the actual direction of the vehicle. This is really neat when watching a vehicle drive with location streaming. It is, however, beta but I hope stable. Let me know how it works out for you. Regards, Mark. Open Vehicle 1.2.5 (20120415) Team: Open Vehicles What's New: v1.2.5 preview (20120415) - 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 toms - Various minor bug-fixes and stability enhancements Released: April 15, 2012 Expires In: 7 months, 2 weeks Size: 8.3 MB

1 0

Charge Control
by Mark Webb-Johnson 11 Apr '12

11 Apr '12

I'm now starting to think about the v1.3 firmware, which is intended to add the following: Log charge history Log drive history Sophisticated control of charge time We don't really have TOU metering in Hong Kong, so not much use for me, but part [3] would be fun nevertheless. Most charge control in EVs is pretty basic, and it might be interesting to see how sophisticated this can be made without complications. I don't know if this is workable or not, so put my thoughts out into the open for discussion. For charge time, the consensus seems to be that people want to enter the time to FINISH charge, vs the current time to START charge. To do that, we need an estimate of how long the charge will take. For that, we either need a sophisticated model or a collection of historical data we can lookup to find something approximate. Hence item [1] on my list. Elon talked about the car learning about you. Where you park. Where you charge. etc. So, if always leave home at 7:00am to go to the office on Mondays through Fridays, perhaps the car can learn? Or, at least suggest based on what it has seen... Hence item [2] on my list. For [1], we would store such things as temperatures, SOC start, SOC end, charge mode, charge current, charge voltage and duration. The can bus charge message seem to include this information. For [2], we would store such things as date/time of drive, duration (time, distance, and elevation change), battery usage. We seem limited in this from what we have decoded on the can bus so far. Regardless of the above, [1] and [2] would be useful information for any owner, anyway. Privacy is an issue. Two problems - (a) protection of my charge/drive history, (b) the use of 'shared' charge history for [3]. My suggestion is to keep drive and charge history private. Perhaps it could just be stored as paranoid mode blobs. But, there should be an option to allow anonymised sharing of charge history for the use of [3]. My thinking is that if you share your data anonymously, then your lookup includes the pool of others anonymous charge history. if you choose not to share, then your lookup is only against your own charge history. I did toy with the idea of using the server to control this. So, at 3am the server sends a command to the car to start the charge, etc. That would simplify the firmware in the car, but has a major problem of GPRS connectivity - if the cellular signal was lost the charge wouldn't start. Bad. So, I think it best to have the historical database in the server, the calculations in the App, and the settings downloaded to the car while it has cellular signal (after which it just follows them autonomously). The Tesla Roadster currently offers you a choice of charge on plug-in, or start charge at a particular time. It also allows you to limit charge current and set charge mode. My thinking is to extend this by making it per day-of-the-week for a few defined locations, and to provide an override for the 'current' day/night. If the override is not set, and you are in one of the defined locations, then the system looks up the day of the week and controls charge based on what you have set. The UI for this is quite simple - presumably a screen with tabs/selector for day or the week, and then controls to set charge mode, current limit, and time to start/complete by. One developer also had the good idea that a charge SOC limit would be useful (e.g.; please stop charge when it gets to 70% / 220km ideal). How do we handle night vs day charging? Is this only for overnight, or do we base it on when you plugin? Is this workable? Useful? Really interested in people's feedback on this. Mark.

6 15

Volt/Ampera development??
by felix bonnier 10 Apr '12

10 Apr '12

Hi there saw on the forums that someone was asking for a volt/ampera module and app based on the OVMS for the roadster.....?! They already have an app that, what I understand, works great! So why develop another one with an external module that needs time and lots of effort to find the right CAN messages etc.......?? Just me not getting something fundamental, or????! felix b.

2 2

Note to self...
by Mark Webb-Johnson 10 Apr '12

10 Apr '12

Note to self: Before spending an evening trying to work out why my car's OVMS module data and incoming SMS is working, but outbound SMS messages won't send, check pre-paid SIM card expiry date. That's 3 hours of my life I can't get back :-( Note to cellular providers: When you expire something, please expire all related services. Otherwise, it is damn confusing. When you deny outbound SMS messages, due to expired SIM, please still permit the SMS message to check account balance / pin :-( Happy 6 month anniversary, OVMS - we've come a long way ;-) Regards, Mark.

2 2

Easter egg
by Mark Webb-Johnson 09 Apr '12

09 Apr '12

I managed to do some more logging in the car over Easter, and found some nice messages: ID#100 Charge Timer VDS Feedback B1=06 (timer/plugin setting and timer confirmation) B2=1B (timer/plugin setting) B3=0x01 B4=0x00 B5=0x00/0x01 (0x00=plugin, 0x01=timer) B6=0x00 B7=0x00 B8=0x00 B2=1A (timer start hour) B3=0x01 B4=0x00 B5=TimerLSB (see id#102 B1=0x05 for details on this) B6=TimerMSB (see id#102 B1=0x05 for details on this) B7=0x00 B8=0x00 and ID#102 Set timer/plugin B1=05 (timer/plugin setting and timer confirmation) B2=1B (timer/plugin setting) B3=0x00 B4=0x00 B5=0x00/0x01 (0x00=plugin, 0x01=timer) B6=0x00 B7=0x00 B8=0x00 B2=1A (timer start hour) B3=0x00 B4=0x00 B5=TimerLSB \ B6=TimerMSB | (gmthour*60)-1, with special case midnight gmthour=24 B7=0x00 B8=0x00 N.B. Empirical values for TimerLSB and TimerMSB (a GMT+0800 car in Hong Kong) are: 1439 (0x059F) for midnight GMT, 59 (0x003B) for 1am GMT, up to 1379 (0x0563) for 11pm GMT. It is a bit nasty because the ID#100 messages only seem to be sent in response (confirmation?) to a ID#102 command, so for a newly power-on module we won't be able to show the current setting unless we set the value first. This is useful ground-work for the finish-charge-by feature, as it would be nice to just use the car timer. I also found that on ID#100 B1=0x95 charger status message, a car in "Preparing to charge" "Charge scheduled for XX:XX" state will use B2 state 0x0D (preparing to charge) and a newly discovered B3 sub-state 0x05 (waiting for timed start). This seems to be in addition to the previously discovered 0x02 sub-state, and I have still to see when/why one is used vs the other. Regards, Mark.

1 0

Swisscom
by Mark Webb-Johnson 06 Apr '12

06 Apr '12

Anyone know the APN, user and password for Swisscom sim in Switzerland?

2 1

1.2.2
by Mark Webb-Johnson 01 Apr '12

01 Apr '12

Car firmware 1.2.2 has been committed to github. Changes since 1.2.0 are: 2012-03-30 1.2.2 End-User firmware 1.2.2 Issue #31: Performance mode bug fix and kludgy workaround Issue #32: Bug in net_sms handling CARBITS feature #14 Tesla Roadster v1.5 tested compatible and supported Issue #31 was a minor issue, affecting performance mode. It is a good fix to have in your cars. Issue #32 brings support for 1.5 Tesla Roadsters (thanks to Tom for all his hard work on this). I'd appreciate your help by flashing this to your car modules and let me know if you see any problems. We'll probably start shipping this as the standard firmware from sometime mid-to-late next week. Thanks, Mark. P.S. You can see the code changes with "git diff -r 478c3588d11aa4fd5f30359997fe16d2ee0d34b1 vehicle/OVMS.X/*.c vehicle/OVMS.X/*.h vehicle/OVMS.X/*.def". Really minimal, and the entire patch is only 151 lines.

2 3

Switch to tmc.openvehicles.com
by Mark Webb-Johnson 31 Mar '12

31 Mar '12

I'd like to move all production cars off www.openvehicles.com to tmc.openvehicles.com. Over the coming month we're going to be doing some work on the server (to add some features), and that may mean some interruption. The server could go up and down intermittently as we work on stuff. It would be much easier if everyone is using the production tmc.openvehicles.com server hosted by Tesla Motors Club. We're trying to keep that server as stable as possible (and as it is hosted in USA, it should be fastest for most). To make the change: Send an SMS to the car with "PARAMS K SMS,IP 64.111.70.40" (adjust as appropriate) and wait for the switch to occur. Or, use the apps to change the server IP parameter #4 to 64.111.70.40 then reboot the car module. On your app, switch from using www.openvehicles.com as the server to using tmc.openvehicles.com. On the iPhone this is in the Settings App of the iPhone (not OVMS app) under "Open Vehicles". On Android, you can find it on the car settings screen. Thanks, Mark.

1 0

v1.5 support
by Mark Webb-Johnson 29 Mar '12

29 Mar '12

Guys, Good news regarding v1.5 roadster support. Tom Saxton has been helping us with this, and has found a bug in the SMS part of feature #14 setting (the feature that stores the carbits for things like suppressing sms alerts and most importantly defining the car as a v1.5 roadster). With that fixed, it appears that the OVMS module works perfectly in the v1.5 Tesla Roadsters (even advanced features such as setting charge mode). I expect to cut a v1.2.2 car firmware (to formalise support for v1.5 cars) over the weekend, and would appreciate your assistance with testing this - I'll eMail when it is ready and running in my car. It will include the fix for issue #31 (Performance mode bug fix and kludgy workaround) as well as Tom's fix for the feature #14 support. Other than that, the car firmware seems fine and is now running in a large number of cars (both developers and end-users). I've got a pile of UI enhancements to the iPhone App from Felix, that I've been working on. I hope to get these into a testlight release this weekend as well. And, finally, the new batch of hardware has arrived and QC tested fine. The new cable supply is looking much better - we're really happy with the new connector arrangement and quality of cable crimping. We hope to ship all outstanding back-ordered units today, to clear our backlog, and we should now have plenty of stock of modules going forward. Regards, Mark.

1 0

Fwd: OVMS Vehicule Registration
by Mark Webb-Johnson 19 Mar '12

19 Mar '12

A suggestion from a user... Begin forwarded message: > Quick suggestion: don't you think a bow-tie like on the Riadster would be a better icon for valet mode? >

1 0