July 2013 - OvmsDev - Open Vehicles

OVMS logo
by Mark Webb-Johnson 06 Jun '17

06 Jun '17

We need to change the OVMS logo, to better reflect the vehicle independence. The existing logo is too much Tesla. Felix has kindly prepared a couple of options for us, attached below. My preference is for the one with the car outline (even though it retains a hint of Tesla), as it emphasizes the vehicle comms aspect. This is quite urgent, as the Teslive people are pushing for artwork. What do you guys/gals think? Regards, Mark

8 14

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

OBD-II Cables
by Mark Webb-Johnson 11 Aug '13

11 Aug '13

I'm going to order another batch of OBD-II cables (changing factory because the one I used the last few times is so unresponsive). Is the current 1metre cable length good, or should I order them longer? Regards, Mark.

4 5

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

ODO issue once again
by Kevin Sharpe ZCW 30 Jul '13

30 Jul '13

On the 2nd July OVMS stopped reporting my Tesla ODO… I had this problem historically but it just started working one day and had been fine until the 2nd. I've tried power cycling the unit but that did not help. I was driving in mainland europe at the time and could not receive text messages from the unit although the data connection was fine. Any suggestions? [http://www.zerocarbonworld.org/images/logo.png] Kevin Sharpe | Founder & Patron Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld kevin.sharpe(a)zerocarbonworld.org <mailto:kevin.sharpe@zerocarbonworld.org> | www.zerocarbonworld.org<http://www.zerocarbonworld.org/> | twitter.com/zerocarbonworld<http://twitter.com/ZCWcharlie> [http://www.zerocarbonworld.org/images/email-signatures_06.png] Zero Carbon World is a UK Registered Charity #1141347

1 1

Volt issues.
by Nikki Gordon-Bloomfield 28 Jul '13

28 Jul '13

Hey folks, Finally got the Volt today -- a replacement for our Twizy -- and so got to putting OVMS in the car. The first thing we did was ref lash the module with the latest 2.3.2 firmware. Then checked that it was set to VA in vehicle type. Logging into OVMS and texting the module gets a response. I'm even picking up the VIN number from the car.. But what I'm not getting is the battery SOC, nor does the parking timer appear to be correct. Thoughts? I've got quite a few Ampera/Volt folks in the UK who would like to install, and I said I'd go first. Nikki.

3 6

Development of C-Zero/iOn/iMiev version
by Matt Beard OVMS 25 Jul '13

25 Jul '13

Hi, I am now the proud owner of a V2 box, and accessories for ODB-II connection etc. Unfortunately I currently don't have an EV... but as soon as my C-Zero returns I intend to fit the OVMS. Is there currently a draft iMiev version of firmware? I have seen some partly decoded CAN details. I suspect I will also need to start CAN-logging. Matt Beard

2 1

Tazzari Zero
by Mark Webb-Johnson 22 Jul '13

22 Jul '13

http://www.scmp.com/business/companies/article/1286579/hong-kong-set-plug-i… How popular is this car? Anyone apart from Patrick seeing it in their market? Regards, Mark. P.S. Priced at HK$350,000 (US$45,000) in the tax free market of Hong Kong. This is not going to sell.

1 0

No Pushes coming through
by Patrick Kapsch 16 Jul '13

16 Jul '13

Hi Guys, I'm not receiving any push notifications for around two weeks now. User: TecGadgets Vehicles GTTG3333 GTTG2112 GTTG12212 iOS 6 and 7 iPhones as well as iPads - no incoming pushes. Can anyone please check what might cause this? Regards, Patrick

3 4

CAN-RE-TOOL
by Mark Webb-Johnson 13 Jul '13

13 Jul '13

I've launched a new project on github: https://github.com/markwj/CAN-RE-Tool Background is that I'm pissed how costly CAN-USB adaptors are. For what they are, the cost is too high and the software is terrible. If you want the good software, the hardware cost is beyond ludicrous (thousand of dollars). Bill of materials for these things is around US$20-US$30. Street price is US$150 upwards (excluding shipping). I've got a hardware design (based on PIC32 and MCP2551 chips, plus a little power regulator), and I''m working with China factory to see if we can get these down to US$50-60 (including shipping). On the software side, I've released the CAN-RE-TOOL source code. This is perl code (but with a few libraries necessary), and pretty neat. Still very much a work-in-progress, but very usable. Some notes: It should be cross platform - just textual curses based. But, only tested on OSX so far. Linux should be easy, but not sure about Windows. It works with an Input-Transfrom-Output model, with optional displays. You can define the input as either a disk-based log file (CRTD format) or a CAN-USB adaptor to input from. The output can be discard, disk-based log, or CAN-USB adaptor to output to. The transforms take the input and perform optional transformations. At the start, the main transform is 'Uniques' - which find unique messages and keeps a history of updates to them. The input can be real-time or sped-up/slowed-down. Various real-time displays can be called up, including Cyclic and Scrolling real-time message lists, Unique message display, and coverage (which shows just the parts of the unique messages not currently understood). The uniques system identifies messages by a combination of CAN arbitration IDs plus optional data bytes within the message (an example being Tesla Roadster using byte #1 of ID 0x100 as a unique message). Decoders can be defined, to produce sensors from the messages. These decoders document the protocol and message coverage. Everything is implemented as plugins, so it is very very expandable. I've working on a bunch of experimental plugins to do statistical and heuristic style analysis looking for patterns in the messages captured. Control is via mouse, keyboard commands, or scripts on disk. Here are some screens, to give you an idea of what is possible: Selecting a CRTD log file as the input source: Scrolling CAN message display (input is a CRTD log file being played back in real time): Uniques message display (note the decodes on the right, and message count + interval towards the left): Coverage message display (everything not '*' is unknown): The whole point of this is to provide a system to capture messages from the can bus, work out which messages are unique for that particular car, provide a facility to decode the messages to user-readable sensors (speed, SOC, CAC, odometer, etc), and finally to allow the vehicle message documentation to be produced. It does all this today. Perl is used to make this all scriptable and extremely quick/simple to extend. In future, I'm also interested in providing a facility to simulate a vehicle (we can only do that now by replaying a log file back out). OBDII style support work also be useful (include a PID scanner). This is mostly for me, but I'm putting it out there and sharing it in case anyone else needs this. Regards, Mark.

3 3