April 2012 - 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 12 Apr '12

12 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 11 Apr '12

11 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 11 Apr '12

11 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 02 Apr '12

02 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