November 2012 - OvmsDev - Open Vehicles

Merging in Twizy and Volt/Ampera work
by Mark Webb-Johnson 20 Jan '13

20 Jan '13

A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars. I agreed, but at the time, flash space was tight in the v1 hardware and I was concerned we would run out of flash. So, we implemented two separate builds. Now that the v2 hardware is out, I think that is much less of an issue than it was, as the v2 hardware has 50% more flash (taking away the baseline code, that at least triples the amount of free flash we have) - there should be plenty of space to support the cars that need it for the forceable future. In the coming few months, as the Volt/Ampera and Renault Twizy code becomes usable and usable by end-users (rather than developers), it would be much easier to be providing modules pre-flashed with a single version of firmware supporting all the cars. As the work on Twizy and Volt/Ampera is now progressing so fast, I think it best to make the change now rather than later. What I suggest is: We leave the current car modules basically as they are: can_teslaroadster, can_voltampera, and can_twizy. We leave the v1 firmware build basically as it is - just using can_teslaroadster. All the v2 hardware users are Tesla Roadster users. We move the 'shared' interrupt code (can_int_service, high_isr) out of the car_* modules into a can_canbus module. We create a mechanism for car_* modules to register themselves at startup. We create an eeprom parameter to define the vehicle type, and a switch at startup to hook the module supporting the currently defined car. It might be interesting in future to create a car_autodetect module to auto-detect the vehicle type from can bus traffic, but for the moment I think a manual parameter is acceptable. The existing V2_T2, V2_VA and V2_RT build configurations would disappear and be replaced with a single V2 firmware that would include all three car_* modules. I'm not sure of the exact mechanism for [4] and [5], but it should not be too hard to do. I really want to avoid having a single list of the cars anywhere. I'd much rather just have the existence of code in the can_* modules cause the code to be included. Does this sound sensible to everyone? Any better suggestions, or comments? Regards, Mark.

5 47

Android code for OVMS
by Mark Webb-Johnson 13 Dec '12

13 Dec '12

It appears that we're in a mess with the Android code base. The Android project Sonny had worked on containing updates to the OVMS Android App has been accidentally deleted, and the latest updates to the code lost. The NAS backup arrangement that Sonny had in place has also failed, and there is no backup. Sonny apologizes, and has tried hard to recover the files, but cannot. He is also still tied up with work commitments, and can't help much for the next month or two. We still have the code base in github, but that is quite old as it has not been updated with the improvements made in recent months. Primarily the settings screen, partial support for groups, and support for tablets. It is the tablet support that is causing problems with new high-res phones (as it is incorrectly identifying these as tablets) - I suspect that the settings code is the main thing we want to retain. I have tried to reverse-compile the Android code from the APK in the marketplace, and while the resulting code looks pretty good, the resources are not reverse-compilable, and look like they would take a significant amount of work to repair. My approach has been to take the github version, compile it, decompile it, and compare that with the decompiled version of the latest android market APK - applying patch duffs where necessary. The code looks good, and seems to only need minor tidy-ups. But, the resources are a mess. It seems the decompile process retains code symbols, but not resource symbols. The resource IDs and tags end up as numbers. I'm really not familiar with Android development, so am not sure how feasible that approach would be. It looked very easy and successful to start with. So, we are faced with a decision: 1. Someone more experienced with Android development comes up with a brilliant solution to finish off the reverse compilation of the APK to get back the latest version. I don't mind stepping in with the 'donkey work', but I really don't know where to start. What are those "R" class files - they look like they may be the key? 2. We start again with the code as it was a few months ago, and try to take it forward from there. 3. We investigate cross-platform development environments that could perhaps give us a more unified appearance across the the different platforms, as well as support for Windows Phone and others. What do people think? Mark

3 7

Twizy
by Mark Webb-Johnson 09 Dec '12

09 Dec '12

Twizy support seems to be coming along nicely, thanks to the amazing work Michael is doing. Some good functionality there already. I'm starting to see some Twizy users register on openvehicles.com. Perhaps the word is getting out? Some questions / requests: Michael: Can you let me have the details on the cable pinouts and parts you are using at the moment? Is it a standard cable, or are you having to make something up? How is charge control on the Twizy done? Is there any way of stopping or starting (topup) a charge from within the car, or is it just controlled by plugging? Any chance of can bus control of this? Can anyone help with the car images for the Twizy? There are lots of nice images available, but they need to be photoshopped to the right dimensions and transparent background png. Regards, Mark.

5 17

Volt/Ampera SOC and more
by Michael Jochum 01 Dec '12

01 Dec '12

Hi, i implement the following code into the FW: unsigned int soc_largest = 56028; // this is from mark, readout from the logs unsigned int soc_smallest = 13524; // this too unsigned int v; v = (can_databuffer[1]+(unsigned int) can_databuffer[0] << 8); if ((v<soc_smallest)&&(v>0)) v=soc_smallest; if (v>soc_largest) v=soc_largest; car_SOC = (char)((v-soc_smallest)/((soc_largest-soc_smallest)/100)); i got funny Outputs in the iPhone app. Something between 0 and 100%. Not match to the real state. Full can display as 0% or 20, or...... Empty can show as 100%, or something else. This code (org. mark) works: car_SOC = (char)((can_databuffer[1]+((unsigned int) can_databuffer[0] << 8))/644); With this i got 21-87% for the soc. BTW: i thing it is a good idea to deactivate the minSOC warning. It is not nessary for the Volt/Ampera. I activate the internal GPS (OVMS_INTERNALGPS) and get the position from my car. GREAT WORK. I got no Info about the VIN, the OVMS FW and the car type in the iPhone App. 1.3.2 build from the git. Bye michael

3 2

1.5.1
by Mark Webb-Johnson 27 Nov '12

27 Nov '12

Firmware 1.5.1 has been built for all platforms and is now on github. The primary focus of this release has been adaptive reporting and simplifying provisioning. Due to the drastic reduction in cellular data usage with this release, and improvements in cellular connection handling, this firmware is recommended for all end users. Github issues addressed (since 1.2.9) are: #93 Car: Notify server/app when charge has completed #92 Try TCP reconnect, rather than full GPRS re-init, if server connection fails #90 AP via SMS #89 Report GSM operator #86 Get ICCID from SIM during startup #84 Detect lack of comms between PIC and modem #82 Adaptive Reporting #80 Make GSMLOCK use short service name #79 SMS/PUSH notify if alarm is activated #78 can_poll0 100 vs 102 check #77 Option for GSM Network selection #76 SMS HELP command #75 Car: Basic (stub only) Renault Twizy Support #74 Car: SETUP (DIAG) mode for firmware #71 Car: Send line voltage level back to server #70 Car: Send hardware version along with firmware version #69 Wakeup temperature subsystem when car is woken up #58 Car: Strange range when low on power #57 Car: Motor temperature overflow Regards, Mark.

2 3

Gone quiet...
by Mark Webb-Johnson 27 Nov '12

27 Nov '12

I've received quite a few OVMS development eMails in my inbox these last few days, and I'm having trouble finding the time to respond properly. Apologies if you are waiting on something from me. I'm also snowed under at my day job with a huge product launch this coming Friday. After that, things should get easier. I'm working through the backlog, so please be patient :-) I should be able to catch-up over the weekend. Regards, Mark.

1 0

Some Twizy Graphics
by Mark Webb-Johnson 20 Nov '12

20 Nov '12

Bruce has submitted some nice graphics for the Twizy, and I've just added them to the iOS App and released a version to TestFlight with both Volt/Ampera and Twizy graphics. Many thanks to Bruce for his hard work on this. The other reason for this release is because the provisioning profile is about to expire (8 days) and this release renews it for another year. Regards, Mark. P.S. With all the Michael's working on this project, things were getting confusing. Now, having a Bruce from Australia is so much easy to remember :-) > From: "Bruce McMillan" <brucemcmillan(a)exemail.com.au> > Subject: Some Twizy Graphics > Date: 20 November, 2012 6:37:10 PM HKT > To: <ovmsdev(a)lists.teslaclub.hk> > > > Hi Mark, > > > Although I don't own a Volt at this time, I'm very interested in its progress. Of course I see you are steaming ahead with the Twizy implementation, which also helps with the ground work for other electric cars (including the Volt). > I applaud you all involved in the creation development of these excellent applications and of course the hard work in developing the hardware as well. > > > Hope these are of use and are of some help. There are quite a few to do, however I was only able to get these from the web site ... > http://www.conceptcarz.com/vehicle/default.aspx?carID=20336&i=3#menu > > Twizy Urban - has 4 different colours > Twizy Technic - has 2 different colours (I have provided 1 from this range) > Twizy Colour - has 9 different colours (I have provided 3 from this range) > > > Please find attached three of the Twizy Colour range vehicles and one of the Twizy Technic range. > · Diamond Black with Ivy Green > · Snow White and Flame Orange > · Snow White and Urban Blue > · Snow White with Black > > car_twizycolour_diamondblackwithivygreen > car_twizycolour_snowwhiteandflameorange > car_twizycolour_snowwhiteandurbanblue > car_twizytechnic_snowwhitewithblack > > map_car_twizycolour_diamondblackwithivygreen > map_car_twizycolour_snowwhiteandflameorange > map_car_twizycolour_snowwhiteandurbanblue > map_car_twizytechnic_snowwhitewithblack > > ol_car_twizycolour_diamondblackwithivygreen > ol_car_twizycolour_snowwhiteandflameorange > ol_car_twizycolour_snowwhiteandurbanblue > ol_car_twizytechnic_snowwhitewithblack > > > Kindest Regards, Bruce.

2 2

Open Vehicle iOS 1.3.3 (20121120)
by Mark Webb-Johnson 20 Nov '12

20 Nov '12

Enjoy (particularly Twizy and Volt/Ampera developers) Open Vehicle 1.3.3 (20121120) Team: Open Vehicles What's New: 1.3.3 20121120 - Twizy graphics - Volt/Ampera graphics - Build with new provisioning profile, to extend validity Released: November 20, 2012 Expires In: 12 months Size: 17.9 MB

1 0

Hacking Linux in cars
by Mark Webb-Johnson 19 Nov '12

19 Nov '12

Interesting article forwarded to me today by one of my Linux hackers: https://lwn.net/Articles/518923/ I'd seen the 2010 paper before, but not the 2011 refresh. Regards, Mark.

1 0

New features: sufficient charge alerts, ideal max range
by Michael Balzer 13 Nov '12

13 Nov '12

Mark, I just checked in my latest Twizy updates: https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/0a70e483b… These contain two extensions that could be generally useful: 1) As the Twizy "ideal" range varies widely depending on your driving, geography and environment, I implemented a feature for that config. 2) If I just need an intermediate charge for a certain SOC or range (to get home for example), I can now activate an alert for one or both values. I used the next three free feature slots for these: #define FEATURE_SUFFSOC 0x0A // Sufficient SOC feature #define FEATURE_SUFFRANGE 0x0B // Sufficient range feature #define FEATURE_MAXRANGE 0x0C // Maximum ideal range feature I know, feature slots are getting full... what do you think? Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

2 7