January 2013 - OvmsDev - Open Vehicles

Re: [Ovmsdev] OVMS VIN 4E9->4F1->4E1 (was OVMS VIN 4E9->4F1)
by Mark Webb-Johnson 07 Aug '13

07 Aug '13

Michael, OK. I found some old logs you sent me before and these show: 7.628 R11 4E9 E1 80 00 04 6C 00 7.637 R11 514 47 31 52 39 36 45 34 39 8.647 R11 4F1 41 A1 01 A1 00 36 08 88 The 514 looks fine. But, both 4E9 and 4F1 look wrong. In particular, the 4F1 has '41 A1 01 A1 00' - which is what we are seeing for your VIN. But, id #4E1 has: 8.694 R11 4E1 43 55 31 31 36 34 38 39 If the VIN was in 4E1 and 514, that would give us: 8.694 R11 4E1 43 55 31 31 36 34 38 39 7.637 R11 514 47 31 52 39 36 45 34 39 Or, CU116489G1R96E49 for your car. For RScott, his logs show: 41966.094 R11 4E1 42 55 31 30 32 36 38 39 41966.110 R11 514 47 31 52 44 36 45 34 36 Or, BU102389G1RD6E36 for his car. Is that correct? Reading back through the old eMails, I find this from RScott: > The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc. So, I think the whole 4E9 was just a typo, as 4E1 is what is mentioned later in the same sentence. I've committed the code with 4E1 into github now. It works ok on my simulator, and hopefully should be ok in your car now. Can you try? Regards, Mark. On 26 Dec, 2012, at 9:12 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > Michael, > > I've put this up on my test bench, set to VA vehicle type, and setting my simulator to 500Kbps CAN speed, then transmitting the following three messages once a second: > > ID#206 A0 10 00 00 00 00 00 00 > ID#4F1 42 55 31 30 32 36 38 39 > ID#514 47 31 52 44 D6 45 34 36 > > Then, with the module in SETUP mode, I get: > > S MODULE? > # Module: > VehicleID:TESTCAR > VehicleType:VA > Units:K > Notifications:IP > > DIAG > # DIAG > > # Firmware: 2.1.1/VA/V2 > # SWITCH: 1 > # 12V Line: 14.0 V > # Signal: 0 > > # VIN: BU102689G1RD6E46 (VA) > # SOC: 64% (0 ideal, 0 est miles) > > That all looks ok. > The message from your car is: > > GERMANVOLT rx msg F 2.1.1/V2,A??,24,0,VA,E-Plus > > 00000040 20 6d 73 67 20 46 20 32 2e 31 2e 31 2f 56 32 2c | msg F 2.1.1/V2,| > 00000050 41 a1 01 a1 2c 32 31 2c 30 2c 56 41 2c 45 2d 50 |A...,21,0,VA,E-P| > 00000060 6c 75 73 0a |lus.| > > Your VIN is showing up as 41,A1,01,A1 - as you say: wrong. > > But, the firmware version and car type look ok. Not sure why they would not show up in the App. Perhaps the corrupt VIN# is messing up interpretation of that message? Perhaps the high bit on the A1 is messing it up. > > Not sure what is going on in your car itself. Can you check any captures you have for the exact id#4F1 and id#514 messages you have, and let me know? > > Regards, Mark. > > On 21 Dec, 2012, at 9:33 PM, mikeljo(a)mac.com wrote: > >> Hi, >> >> thanks. >> >> Works. Get the correct infos from my car. >> Implement the SOC calculation from my previous mail. >> >> - GPS ok >> - SOC ok >> >> BUT: >> - no VIN >> - No Car Type >> - no car firmware >> >> Here some Pics from the App: >> >> <IMG_1075.PNG> >> <IMG_1076.PNG> >> <IMG_1077.PNG> >> <IMG_1078.PNG> >> >> >> The App is the 1.3.2 compiled from the git. This is NOT the one from the Store!? >> >> BTW: You see the GSM Signal is -113dBm. When one door is open i got -87dBm. Heavy attenuation. >> I think i must mount the antenna outside the car. GPS is ok. >> >> >> Bye >> michael >> >> >> Am 21.12.2012 um 02:19 schrieb Mark Webb-Johnson <mark(a)webb-johnson.net>: >> >>> Michael, >>> >>> Parameter #14 (PARAM_VEHICLETYPE) holds the selected vehicle type. This can be set either from the smartphone apps, or via the SMS MODULE command. >>> >>> Regards, Mark. >>> >>> On 21 Dec, 2012, at 4:31 AM, mikeljo(a)mac.com wrote: >>> >>>> Hi, >>>> >>>> i checked it out. It compiles without error. >>>> But i think i missed something: how to switch between the cars? I know you do something, but couldn't find the howto. >>>> I found the ROM Parameter "VA" in "vehicle.c", but how to put this in the ROM? >>>> SMS Command? >>>> >>>> Sorry. >>>> >>>> Bye >>>> Michael >>>> >>>> >>>> Am 20.12.2012 um 15:08 schrieb Mark Webb-Johnson <mark(a)webb-johnson.net>: >>>> >>>>> Michael J: >>>>> >>>>> The following commit should fix this: >>>>> >>>>> * 269cd4f (HEAD, origin/master, origin/HEAD, master) Ampera VIN 4E9->4F1 >>>>> >>>>> Can you check the code now in master head, and see if it has everything you need. It builds and compiles on v2 hardware, but you'll need to change the compiler flags to get it building on v1 (just change TESLAROADSTER to VOLTAMPERA). >>>>> >>>>> What was the end result of the SOC range changes? Any ideas on the solution? >>>>> >>>>> Regards, Mark. >>>>> >>>>> On 6 Nov, 2012, at 5:28 AM, mikeljo(a)mac.com wrote: >>>>> >>>>>> Hi mark, >>>>>> >>>>>> do you think at the VIN? >>>>>> >>>>>> 1 + 514 + 4F1 >>>>> >>>> >>> >> >

11 85

Re: [Ovmsdev] Android App
by Mark Webb-Johnson 07 Feb '13

07 Feb '13

Just a note to acknowledge all the submissions I've had (both personal and to the list) on the Android App. Thanks for your help testing this. I'm not individually acknowledging each feedback message, to keep the volume of messages on the list reasonable. I am collecting all the feedback. Most of the points made so far are very quick and easy to fix. Mostly just cosmetic. I hope to get another update, with these fixes made, over the weekend. So far, it looks like the App works just fine, and I don't think we need many more betas. I may just try to make the arrangements to get it into the Play store directly. Regards, Mark. > Von: ovmsdev-bounces(a)lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Mark Webb-Johnson > Gesendet: Montag, 21. Januar 2013 14:58 > An: OVMS Developers > Betreff: [Ovmsdev] Android App > > > I'm glad to be able to (finally) announce that the new Android App is finally ready for public beta. We're calling it v3.1.1. > > The source code is all in github (for the brave), and there is an APK that can be side-loaded on Android devices, via this link: > > http://www.openvehicles.com/downloads/OVMS.3.1.1.beta.apk > > Functionality wise, it is pretty much on a par with the iOS App. All the core functions are there and, most importantly, the virtual car layer is complete and up-to-date. We've got HOMELINK support (yay!) as well as all the new function and parameter settings. It does have the artwork for the Volts and Amperas, but no Twizy yet (sorry, that slipped through the cracks, but we'll get it in the next build). The App should support any 2.3+ Android phone, and should scale its displays to pretty much any resolution out there. Tablet support is implemented by making them look like big phones. > > There are a few things still incomplete (as previously pointed out at the start of this project): > > No social group support on the map > No cellular usage > Some recent artwork missing (this is easy, and will come in the next beta release) > > These will come, but weren't considered essential for this first release. The most important is to get the Android App up to the same level of functionality as the iOS App, so that they can both be brought forward. > > I think if you want to install this, you first need to uninstall the Play store version. You will probably have to re-setup your vehicle as well. If you have problems with the beta, you can always uninstall it, and roll-back to the Play store version. > > Please send feedback back to this list. > > Regards, Mark. > >

4 9

Power usage / sleep mode
by Michael Balzer 02 Feb '13

02 Feb '13

Mark, List, yesterday my Twizy was temporarily dead... because of the OVMS power usage. I had not driven for 5 days. The Twizy has a very small 12V battery with only 14 Ah capacity, and it only gets charged while charging the Twizy and while driving (from the main battery). The OVMS with GPS activated needs a constant current of ~110 mA according to my measurement, thus sucking that battery empty within 4-5 days, maybe fewer. I'll make the power warning much more prominent in the Twizy user guide. Have there been any considerations yet about using the sleep mode of the PIC and/or SIM chipset? Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

3 25

Android App
by Mark Webb-Johnson 01 Feb '13

01 Feb '13

I'm glad to be able to (finally) announce that the new Android App is finally ready for public beta. We're calling it v3.1.1. The source code is all in github (for the brave), and there is an APK that can be side-loaded on Android devices, via this link: http://www.openvehicles.com/downloads/OVMS.3.1.1.beta.apk Functionality wise, it is pretty much on a par with the iOS App. All the core functions are there and, most importantly, the virtual car layer is complete and up-to-date. We've got HOMELINK support (yay!) as well as all the new function and parameter settings. It does have the artwork for the Volts and Amperas, but no Twizy yet (sorry, that slipped through the cracks, but we'll get it in the next build). The App should support any 2.3+ Android phone, and should scale its displays to pretty much any resolution out there. Tablet support is implemented by making them look like big phones. There are a few things still incomplete (as previously pointed out at the start of this project): No social group support on the map No cellular usage Some recent artwork missing (this is easy, and will come in the next beta release) These will come, but weren't considered essential for this first release. The most important is to get the Android App up to the same level of functionality as the iOS App, so that they can both be brought forward. I think if you want to install this, you first need to uninstall the Play store version. You will probably have to re-setup your vehicle as well. If you have problems with the beta, you can always uninstall it, and roll-back to the Play store version. Please send feedback back to this list. Regards, Mark.

3 7

Nissan Leaf
by Mark Webb-Johnson 29 Jan '13

29 Jan '13

I've created a stub placeholder implementation for the Nissan Leaf. Regards, Mark.

1 0

C18 compiler.
by Nikki Gordon-Bloomfield 29 Jan '13

29 Jan '13

Hi folks, Trying to find the C18 compiler for Mac OS X so I can build a dev environment. It doesn't seem to be available anywhere. Can anyone help? Cheers, Nikki. Nikki Gordon-Bloomfield http://about.me/aminorjourney/bio email: nikki(a)littleCollie.com tel: +44 7901 553308

4 6

Vehicle Support Checklist
by Mark Webb-Johnson 29 Jan '13

29 Jan '13

I've updated the development document with some vehicle module development checklists. You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these. The Tesla Roadster supports 100% of these (obviously). It would be good to use these ongoing for other vehicles, both as a target list to get to 100% support, and as a worksheet for both CAN bus information and progress. I hope you find them useful. Regards, Mark. Parameter Purpose Vehicle Support Notes Vehicle Identification car_type Vehicle type identified car_vin Vehicle VIN Parameter Purpose Vehicle Support Notes GPS Status Vehicle GPS Does the vehicle have a built-in GPS? If so, complete the following. car_gpslock Set to record GPS lock car_stale_gps Denotes GPS data staleness car_latitude Latitude of the vehicle car_longitude Longitude of the vehicle car_direction Direction of the vehicle car_altitude Altitude of the vehicle Parameter Purpose Vehicle Support Notes Tire Pressure Monitoring System TPMS Does the vehicle have a TPMS? If so, complete the following. car_stale_tpms Denotes TPMS data staleness car_tpms_t The temperatures of each wheel car_tpms_p The pressures of each wheel Parameter Purpose Vehicle Support Notes Driving Status car_doors1 [bit7] Set if the car ignition is ON car_speed The speed of the vehicle car_trip The vehicle trip counter car_odometer The vehicle odometer Parameter Purpose Vehicle Support Notes Vehicle Environment car_stale_ambient Ambient temperature staleness car_ambient_temp Ambient temperature car_stale_temps Other Temperature staleness car_tpem Temperature of the PEM car_tmotor Temperature of the MOTOR car_tbattery Temperature of the BATTERY car_doors1 [bit 0] Set if front left door OPEN car_doors1 [bit 1] Set if front right door OPEN car_doors2 [bit 6] Set if bonnet is OPEN car_doors2 [bit 7] Set if trunk is OPEN car_doors1 [bit 2] Set if charge port is OPEN car_doors1 [bit 6] Set if handbrake is ON car_doors2 [bit 5] Set if headlights ON car_doors3 [bit 1] Set if vehicle is AWAKE (or if not supported just follow ignition) car_doors2 [bit 4] Set if valet mode is ENABLED car_doors2 [bit 3] Set if vehicle is LOCKED car_lockstate 4=locked, 5=unlocked (deprecated) car_doors4 [bit 2] Set if alarm SOUNDING car_time Time (in seconds) car_parktime Time (seconds) vehicle parked Parameter Purpose Vehicle Support Notes Battery Status car_SOC State of charge percentage car_idealrange Ideal range car_estrange Estimated range Parameter Purpose Vehicle Support Notes Charging Status car_doors1 [bit 3] Set if pilot signal ON car_doors1 [bit 4] Set if vehicle CHARGING car_linevoltage Line voltage while charging car_chargecurrent Line current while charging car_chargemode Vehicle Mode car_chargestate Charging state car_chargesubstate Charging sub-state car_chargelimit Charge current limit car_chargeduration Charge duration (minutes) car_chargekwh Charge kWh put into battery car_stale_timer Charge timer staleness car_timermode Charge timer mode car_timerstart Charge timer schedule

1 0

[OVMSDEV] Compiler Probs
by Michael Jochum 23 Jan '13

23 Jan '13

Hi, a few people gere from the Ampera Forum have trouble with the precompiled hex in the git. It don't work. I send them the version i compiled and this works perfect. Whats wrong there? Bye Michael

1 0

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

Freemont, CA firmware upgrade support
by Mark Webb-Johnson 19 Jan '13

19 Jan '13

Any OVMS techies, with pickit 2 and experience upgrading firmware, willing to help out with a module firmware upgrade in Freemont, CA, area?

1 0