May 2013 - OvmsDev - Open Vehicles

i-Miev/C-Zero/iOn
by Thomas Bergo 25 Jan '14

25 Jan '14

Hi As a owner of a i-Miev I'm interested in OVMS support for the i-Miev/C-Zero/iOn EV. Has anyone looked into supporting those EV? I'm planing to start looking into adding support for those EV. And asking for help to add a vehicle plug-in module stub for those cars, so that naming and so on is correct. Best regards Thomas B

15 105

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

Advanced Charge Control (ACC)
by Mark Webb-Johnson 02 Jun '13

02 Jun '13

I've spent some time planning this, and now have the time to try to get it done. The observant will have noticed a new branch ACC just appeared in the github repository. This is primarily for Tesla Roadster owners, but once we work out how to do charge control in other cars, it will have use for them. The premise of what I'm thinking is a replacement for the limited charge control in the car, to make an Advanced Charge Control: We have the concept of a 'charge location'. This is an area (square, because it is easiest) around a GPS location. An area of 200m x 200m, centred on the charge location, should be sufficient for gps inaccuracies. Up to 5 such charge locations can be defined (I'm thinking home, work, and one other). Once the car enters a charge location, an action can be triggered. At the moment, I'm only thinking of automatic home link activation, but others are possible. When a car is turned off, while in a charge location, acc is enabled and current charge settings are saved. When a car is turned on, while in a charge location, acc is disabled and previous charge settings are restored. Features that acc should support include: Homelink activation. Cooldown (cool the car using a sequence of low amperage range mode charges) - this would need a minimum temperature (don't cool down unless ESS temperature is above this), a desired temperature (cool down until the ESS reaches this temperature),and a time limit (stop cooling down if we've been trying for too long). Charge mode (standard, storage, range, performance). Charge current limit. Various charge types, including: Charge on plug-in Start charge at specific time Complete charge by specific time Desired charge limit (SOC%, ideal miles/kilometers, or full) In addition to the charge locations, acc should be able to be turned on, one-off, for the current location. This should be done after the car is turned off, before plugging in. It will be effective until the car is turned on again. It should also be possible to use this one-off acc to override the charge control for the current location. This will be effective until the car is turned on again. Control, and status, is possible by SMS commands. Control is also possible by a new tab added to the apps. I'm going to do iPhone first, with the existing charge control moved to a new "Charge" tab. I'm not sure how to do the 'specific time'. This could be simple-to-ludicrously-complex. My inclination is to just put a day-of-week filter on each charge location - with acc only being enabled if the day matches. More than one location could be created for each physical gps location, with different day matches, to control how that would behave. Changes to be made include: Move the roadster digital speedo experimental feature to a fully supported features, and give it a permanent feature storage number. Assign five new permanent parameters, one each for five charge locations (home, work, other, or whatever they want to be known as - we just call them #1, #2, #3, #4 and #5). The parameter storage for these new locations includes the charging preferences for each location. We would also need a parameter for time zone. Add a new module called "acc". If "acc" detects we are at a known charge location, it will take over the charge control from the car. The "acc" will also support commands for the current location, and will be able to take over charge control from now until the car is next driven. Please let me have your comments / suggestions. I'll handle the coding, but I'll need lots of help testing. Regards, Mark.

6 12

Desktop Apps?
by Nikki Gordon-Bloomfield 24 May '13

24 May '13

Hi Folks, Just out of curiosity, has anyone built an Apple or Windows client for OVMS yet? I'm at my desk most of the day, and having something sitting in the background would be truly awesome. Nikki Gordon-Bloomfield http://about.me/aminorjourney/bio email: nikki(a)littleCollie.com tel: +44 7901 553308

2 1

Twizy firmware image V2.3.6 / 2.6.5
by Michael Balzer 15 May '13

15 May '13

For those avoiding self-compiling (Nikki et al), here's the current firmware image with Twizy extensions. It makes GPS logging (RT-GPS-Log) at 5 second intervals stable. To get max GPS precision be sure to activate only the GPS logging (w/o location streaming) by setting feature #8 to 2. The ZIP also contains a guide and spreadsheet template for creating energy use heatmap-style GPS tracks using gpsvisualizer.com -- the guide text is in german now, I can make an english version and add it to the repository if there is demand. Here's an example result: Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

5 20

Spewing Vehicle Alerts
by Tom Saxton 15 May '13

15 May '13

I took our Roadster in for service yesterday, and this morning I noticed that it's sending the same vehicle alert repeatedly at an alarming rate, like once a second. Vehicle Alert Code: TR1N/29 (00000000) I tried calling the store to ask them to unplug the OVMS, but they weren't answering the phone (it was before they were officially open). I then tried to turn off GPRS to get it to stop spewing. I sent a PARAMS command to only allow SMS, but that didn't work. Thinking that it might need to reboot to get the command to stick, I sent a RESET command, which did the trick. I see there's code to call vehicle_initialise() after handling a PARAMS command, so I'm a little surprised the RESET was needed. Then I remembered that version 2.3.2 mentioned a way to turn off vehicle alerts. From the release notes: ## Add facility to suppress vehicle alerts via carbits feature +16 But Mark's email from April 16th says: > Yes, car bits feature 14, add 8 to the value (bit #3) to > suppress vehicle alerts via push notification. >From looking at the code, it looks like adding 8 (setting the 8 bit in binary) to the value for Feature 14 will turn off sending the vehicles alerts to the server. I have Feature 14 set to 1 to indicate that ours is a 2008 Roadster, so I added 1+8=9 and sent "FEATURE 14 9", then re-enabled SMS,IP, and RESET. That restored network comms so the OVMS app is working again, and I'm not seeing the alerts any more. Finally, I notice there's code to prevent OVMS from sending the same alert more than once per minute, but if another code comes in, or the alert gets cancelled, the 60-second timer gets cleared. I wonder if that code should be more aggressive about limiting alert frequency. I suspect what's happening with the Roadster is that it's repeatedly firing and then dismissing an alert message (presumably related to the service they are doing), which completely circumvents the timer, resulting in a ridiculous number of alert messages. I suspect this was happening all night, so my next phone bill may be interesting at $2/MB. Tom

2 1

Look what they found...
by Mark Webb-Johnson 14 May '13

14 May '13

Look what they found behind the cubby under the touchscreen of the Tesla Model S... Reminds me of the Tesla Roadster: Is it wrong of me to want to find a MS, pull down the cubby and plug in (my CAN analyser)? Regards, Mark.

3 7

Current TWiZY Firmware.
by Nikki Gordon-Bloomfield 14 May '13

14 May '13

Hey Guys, Noticed a few strange bits of behaviour lately with the latest Twizy firmware. Michael, I'm getting really long waits between the module contacting the server -- and sometimes it's reporting it can't see the server, despite being able to connect to the GPRS modem. Also, I'm finding I have to reboot the OVMS module every now and then because it becomes unresponsive. Haven't looked at the logs yet though as I'm off to Sweden today. Any thoughts? Nikki.

1 0

OVMS Android localization
by Denis KRAUTH 13 May '13

13 May '13

Hi, I offered my help a few months ago to translate the app into French. Has the app now reached a state where localization into other languages can be considered? Denis. Envoyé depuis mon mobile. -------- Message d'origine -------- De : Mark Webb-Johnson <mark(a)webb-johnson.net> Date : A : OVMS Developers <OvmsDev(a)lists.teslaclub.hk> Objet : [Ovmsdev] OVMS Android goes live @OpenVehicles: OVMS Android App back in Google Play - out of beta and supporting hi-res modern phones and latest EVs. https://t.co/7K8m0IeB27 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

8 27

TESLIVE
by Mark Webb-Johnson 12 May '13

12 May '13

As you may be aware, there is a TESLIVE (Tesla Motors Club / Tesla Motors Corp collaboration) event coming up in Fremont, California - 12th, 13th and 14th July 2013. OVMS has been offered a booth (to show what we have and do), but I can't make it. I would love to go, but it is just bad timing for me, as well as an awful long way to go just for this event. So, I'm opening it up - anyway interested in handling this for us? Based on the limited information I've been given, the expo part of the conference will be on two of the days and the booth would have to be manned for three or four hours on each of those two days. It would mean manning the booth, demonstrating OVMS, perhaps offering firmware upgrades and/or installation advise. You would also get to attend the event itself. Open Vehicles would pay for the booth, as well as one attendance fee for whoever does this for us (assuming you are one of the lucky 300 - and I'm not sure if exhibitors get priority or need to pay for the conference part). If more than one wants to do it, that is fine by me - share the load (and discount the attendance). Supposedly we'll know more about the exhibitor side of things on this coming Friday. Please eMail me (mark(a)openvehicles.com) or respond here, if you can help. Regards, Mark.

2 2