August 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 24 Jan '14

24 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

Incentivising / Rewarding
by Mark Webb-Johnson 10 Sep '13

10 Sep '13

I would like to devise something to incentivise / reward people working on this project. Something beyond the personal satisfaction, and giving back to the community. What I'm thinking is to donate hardware modules to people working on new vehicle support. It would work something like this: Someone steps forward to take on support for a particular vehicle. That developer buys the hardware module, and accessories, as normal. The vehicle_xxx.c file is written, tested, and gets to a stage where it meets the milestones for that vehicle (the core functionality requirements). Open Vehicles either re-imburses the module purchase price, or sends a second module to the developer concerned (option chosen by the developer). In particular, I'd really like to incentivise work on the Leaf and iMiev modules. What about for past contributors? What about for people working on the Apps, or other parts of the system? What do people think? Would this be a good idea, or no use? Regards, Mark. P.S. What I would really like to do is get the OVMS CAN-USB adaptor working, and then give those out in large quantities. The more people decoding vehicle CAN communications, the more cars become open vehicles. But, to do that I need some one / people to step forward and help with this. The China manufacturer is standing by and asking me for the circuit diagram, but I've got too much on my plate at the moment to take on the CAN-USB hardware and firmware as well. Using a PIC32 microprocessor (with built-in USB support), and MCP2551 CAN controller, we can do this for a materials cost perhaps around US$30 (vs US$150 retail for the cheapest commercial units). I'll send out a separate 'appeal' for this, and see if anyone will step forward to help.

6 38

ACC and others
by Mark Webb-Johnson 08 Sep '13

08 Sep '13

Just a short note on progress. I managed to get a lot done over the weekend. Working with Tom on some misc functions for ACC, and all looks good so far. Basic ACC location management is done, and I've worked out a way of using base64 to encode the ACC structures into our limited 32byte parameters. Seems to work quite well - very lightweight (we already have base64 for the comms protocol), and very expandable. I'm now just trying to pull everything together to get cooldown working. Once that is working, I'll commit (even in that unfinished form). Logging (drive and charge) is already done, and part of this. Flash space is getting concerning (approaching 95% now, for experimental with all vehicles), so we'll have to address that once ACC is out. I'm getting a rather large backlog of other requests now (put aside due to ACC work, trip to USA for TESLIVE, and horrendous day job hours). Once the basic ACC is committed, I'll be able to spend some time to try to work through that. Apologies for the delays (to anyone waiting for me). Regards, Mark.

2 9

Hardware hacking OVMS v2 for fun and profit
by Mark Webb-Johnson 07 Sep '13

07 Sep '13

Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help. On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs. You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level. If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command. For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus. Regards, Mark.

5 9

Lefties and righties
by Mark Webb-Johnson 29 Aug '13

29 Aug '13

They are in stock now, and QC checks passed. Hopefully will be up on fasttech tomorrow or over the weekend. Regards, Mark P.S. Working with new suppliers is scary, but sometimes surprisingly easy. This one got our business because he was the first to reply, and work out order details, on a Sunday afternoon :-)

1 0

v2.5.2
by Mark Webb-Johnson 28 Aug '13

28 Aug '13

I've just pushed to github the code for v2.5.2. This includes a workable ACC module, as well as a bunch of bug fixes. It also includes a re-working of the cooldown feature in the Tesla Roadster, based on many a hot evening spent in my car with a CAN USB adaptor and laptop. For the Tesla Roadster, I managed to find two new id#100 messages related to HVAC - 0x87 and 0x9A. This is now used by the cooldown feature to track HVAC usage and try to make it work better. HVAC HVAC message 0x87 and 0x9A are enabled with: 102 06 D0 07 00 00 80 00 08 and disabled with: 102 06 10 27 00 10 00 00 00 HVAC#1 B1=0x87 B2=Toutside (outside temperature, celcius) B3=Tmaxbrick (ESS temperature, celcius) B4=Tcoolant (coolant temperature, celcius) B5=Requested cooling % B6=Received cooling % B7= LSB \ Compressor RPM B8= MSB / HVAC#2 B1=0x9A B2=? B3=? B4=? B5=? B6=? [ seems to be refrigerent pressure (scaled with ~/4) but not certain ] B7=TcabinOutlet (celcius) B8=? [ seems to be outside temperature (celcius) ] The build configs are restructured, as previously announced. Currently, I haven't been able to fit either LOGGING or ACC in the V1 module firmware - it is just too big. I'll keep working on this, as it would be good to get at least ACC in that firmware. One caveat: this is largely untested and probably very buggy - which is why I haven't done binary builds yet. I'll test and debug over the next couple of days and then release binaries when I've got something working well. Regards, Mark.

3 5

OVMS CAN-USB Call for Assistance
by Mark Webb-Johnson 28 Aug '13

28 Aug '13

As some of you may know, over the past couple of years OVMS has made me passionate about the concept of 'open vehicles', and in particular how smartphone control and monitoring can further the cause of EV adoption. One handicap to this is the expense and difficultly of decoding the vehicle buses. I've recently launched a new project on github: https://github.com/markwj/CAN-RE-Tool With the other OVMS projects on-going, I've got too much on my plate to do this all on my own, so I'm announcing it here and hoping that some one / some people will step forward and offer to help. The main areas I need help with are finalising the hardware design and writing the PIC32 firmware - but longer-term if people want to help out with the CAN-RE-TOOL software, that would be wonderful. Open Vehicles can sponsor the hardware for developers - so all I'm looking for is donation of your time and enthusiasm to this project. If you can't directly help with the coding / hardware hacking, then perhaps just help by spreading the news about this. Volunteers please contact me at mark(a)openvehicles.com. Full details here: http://www.openvehicles.com/node/98 Regards, Mark.

1 0

ACC and V1 modules
by Mark Webb-Johnson 28 Aug '13

28 Aug '13

The good news is that by doing some juggling around, I've managed to shoe-horn ACC into the V1_Production code for v1 hardware modules. We've got 3,614bytes of flash and 504bytes of RAM free to play with! The sad news is that this is at the expense of DIAG mode. Anyway, if developers really need that, they can build a custom firmware for it anyway, so not too bad. I may be able to bring it back for v1 hardware at a later stage, if we can reduce code-size elsewhere. I also removed the internal gps from the Tesla Roadster V2_TR_Production build config, as it was just wasting space. I revised Tesla Roadster V2 cooldown charge to 13A, and fixed a bug where the car seemed to be able to still attempt cooldown recycles (range->performance->range) even when the car wasn't charging (presumably if a cooldown was interrupted). It was interesting seeing my car switch from standard to performance mode then to range mode automatically, as I left my driveway this morning :-) Anyway, it let me test the geofencing of ACC, as the behavior stopped when I got out of range of my garage! Other than that, the cooldown and ACC seems to be working as expected, but I continue to test. Finally, I merged in the latest thinkcity changes. Regards, Mark.

1 0

Restructuring build configs
by Mark Webb-Johnson 26 Aug '13

26 Aug '13

We're now up to 11 vehicle modules, and flash memory space is getting very tight. We already can't build all modules with all features, and I don't want to have to limit what we can do. Accordingly, I'm splitting the master project build arrangements as follows: V1_Experimental will dropped (V1 features are all production now). V1_Production will be Tesla Roadster only, with as many features as we can fit in. V2_Experimental will be for the experimental (non-production) vehicles, base features. V2_Production will be for production vehicles, base features (currently this will be none, Tesla Roadster, Volt/Ampera and Renault Twizy). V2_TR_Production will be for Tesla Roadster, full features. V2_RT_Production will be for Renault Twizy, full features. Other private V2_??_Experimental build configs can be used by developers for their own work. As other vehicles make it to production status, and have optional extended features, they will get their own V2_??_Production build configs. I think that this approach brings several advantages: We clearly label vehicle support as Production or Experimental. Experimental work can continue with little impact on Production. For vehicle modules that have a lot of functionality (needing flash space), spinning them off to their own build config gives them the full range of flash to work from. The firmware in new modules from China will be based on V2_Production. I plan to commit these changes sometime this week, along with the ACC code that I'm testing in my car now. The logging code also looks stable, and will make it into production with the next release. I've been running this release in my car for about 10 days now, and things are looking good - very very stable with zero crashes and good recovery from poor GSM/GPRS signals. Regards, Mark.

3 4