September 2013 - OvmsDev

v2.5.3
by Mark Webb-Johnson 18 Sep '13

18 Sep '13

A few days ago, I committed a bunch of code past v2.5.2, labelled v2.5.3. I've been testing this in my car, but the results are not good. I'm getting crashes, and that is causing the cooldown (when configured in ACC mode) to restart. For the moment, I suggest people don't try past 7a6ecc4 (tag: v2.5.2). I'm working on getting the bugs out, but the test cycles are taking me 24-48 hours each, so this is taking some time. I'll let you know as soon as it is stable enough for wider testing. A bit of better news: I finally found a minor typo (CAN ID 0x100 B1=0x8F not B1=0x87) that has been driving me up the wall for the past few weeks. HVAC monitoring during cooldown now seems to be working well, and I'm getting better results for cooldown. At this rate, I may just have cooldown working properly in time to work on heatup for the winter :-( Regards, Mark.

2 1

OVMS Logging and HTTP API
by Tom Saxton 16 Sep '13

16 Sep '13

The new logging stuff plug the HTTP API is pretty cool. I've got a 2.5.2 build running on our v1.5 Roadster, so I'm now getting logging information recorded on the server. With HTTP API, I can now easily download both current and historical information. Here's what my Perl script is currently dumping out: Charge Status: Charge State: done Charge Mode: standard Ambient Temperature: 21C, 70F Battery Temperature: 22C, 72F PEM Temperature: 31C, 88F Motor Temperature: 26C, 79F Line Voltage: -1V Charge Current: 0 of 32A SOC: 97%, 183 IM Vehicle History: C 09/11/2013-03:00:12 (0:06:42): 242V/27A, 96% -> 97%, 182 -> 183 ideal miles D 09/11/2013-16:49:23 (0:11:20): 3.2 mi, 97% -> 95%, 183 -> 179 ideal miles D 09/11/2013-17:56:53 (0:07:52): 1.3 mi, 95% -> 94%, 177 -> 177 ideal miles D 09/11/2013-18:22:28 (0:14:43): 3.2 mi, 94% -> 93%, 177 -> 175 ideal miles C 09/12/2013-03:00:11 (0:27:24): 241V/34A, 92% -> 97%, 174 -> 183 ideal miles C 09/13/2013-03:00:16 (0:07:42): 241V/29A, 96% -> 97%, 182 -> 184 ideal miles C 09/14/2013-03:00:11 (0:08:01): 243V/27A, 96% -> 97%, 182 -> 184 ideal miles C 09/15/2013-03:00:09 (0:06:21): 244V/26A, 96% -> 97%, 182 -> 183 ideal miles The historical records don't seem to have a "units" field, so I just have to assume miles. It would be great to add that, especially for those of us who live near the US/Canada border and switch back and forth. I'd also like to see CAC added to the current charge status. It would be cool to have CAC in the historical records, too, but I'm guessing that would take more EEPROM storage. Maybe only send that field for the current record and drop it from records that have to be stashed for transmission later? Tom

2 1

IFTTT.Com
by Nikki Gordon-Bloomfield 16 Sep '13

16 Sep '13

Hi folks, Probably a little late to the party, but just discovered If This Then That -- IFTTT.com. It's a great way of linking together different APIs in a very clever, fluid way. You can apply to join up for the service. I wonder if an API for OVMS would be useful? You could, for example: •Email yourself when a certain SOC is met. •Set particular charge cycles/pre-conditiong cycles when the weather forecast is for predetermined conditions. •Set home automation when your car reaches the end of your street. The possibilities are pretty endless. Of course, we'd need to work with ifttt.com to build the appropriate links between OVMS and the service…. https://ifttt.com/platform would be the first port of call. As I see it, the service would really expand the possibility of OVMS, without the need for extra hardware or necessarily even a knowledge of programming for the end user. Nikki.

3 3

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 09 Sep '13

09 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

Fwd: Sublicense of USB VID/PID Code
by Mark Webb-Johnson 04 Sep '13

04 Sep '13

Pretty amazing turnaround time (<24 hours). So, if we use microchip the VID/PID issue is solved. If we use AVR, I have another offer (off-list) for more PIDs than we need. Regards, Mark. Begin forwarded message: > Subject: Sublicense of USB VID/PID Code > Date: 4 September, 2013 3:05:33 AM HKT > > Sublicense of USB VID/PID Code > > Subject to the terms and conditions of Microchip Universal Serial Bus Vendor ID Sublicense signed agreement. > The code assigned to you is: > > VID: 0x04D8 PID: 0xF5A2 > > The VID/PIDs above are to be used solely with Microchip Microcontrollers. Use with any other manufacturer devices will result in termination of the sublicense agreement.

1 0

Re: [Ovmsdev] v3.1.5 Android App to Google Play
by Denis KRAUTH 03 Sep '13

03 Sep '13

Hi Mark, Thank you for the update. Unfortunately there are still some french translation strings I provided you missing. Do you want me to give you the latest strings again? Denis. Mark Webb-Johnson <mark(a)webb-johnson.net> a écrit : > >The v3.1.5 Android App has been released to Google Play. > >Enhancements are minor and primarily include support for the display of battery CAC values in the vehicle info sheet. The logo artwork has also been updated, to better reflect the multiple vehicle support we now have available. > >_______________________________________________ >OvmsDev mailing list >OvmsDev(a)lists.teslaclub.hk >http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

4 5

RE : Re: v3.1.5 Android App to Google Play
by Denis KRAUTH 02 Sep '13

02 Sep '13

Thank you! 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 : Re: [Ovmsdev] v3.1.5 Android App to Google Play Denis, I've put that in, and pushed to github. I'll include it in the next version (probably later this week). Regards, Mark. On 2 Sep, 2013, at 7:33 PM, "Denis KRAUTH" <denis.krauth(a)gmail.com> wrote: > Hi Mark, > > Here is my latest values-fr\strings.xml file for the French translation. > > The missing strings in the latest Google Play release I noticed are those > relative to the vehicle view: textMOTOR, textPEM, textBATTERY etc. > I also improved some strings for better UI-fitting as they were to long. > > Denis > > -----Message d'origine----- > De : ovmsdev-bounces(a)lists.teslaclub.hk > [mailto:ovmsdev-bounces@lists.teslaclub.hk] De la part de Mark Webb-Johnson > Envoyé : lundi 2 septembre 2013 03:08 > À : OVMS Developers > Objet : Re: [Ovmsdev] v3.1.5 Android App to Google Play > > Denis, > > Whoops, sorry about that. I thought I had everything. The only thing I added > this time was CAC, and as that doesn't need to be / can't be translated. > > Yes, please send in the latest strings, and I'll get them merged in. > > Regards, Mark. > > On 2 Sep, 2013, at 3:50 AM, Denis KRAUTH <denis.krauth(a)gmail.com> wrote: > >> Hi Mark, >> >> Thank you for the update. >> Unfortunately there are still some french translation strings I provided > you missing. >> Do you want me to give you the latest strings again? >> >> Denis. >> >> Mark Webb-Johnson <mark(a)webb-johnson.net> a écrit : >> >>> >>> The v3.1.5 Android App has been released to Google Play. >>> >>> Enhancements are minor and primarily include support for the display of > battery CAC values in the vehicle info sheet. The logo artwork has also been > updated, to better reflect the multiple vehicle support we now have > available. >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > <strings.xml>_______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

1 0

v3.1.5 Android App to Google Play
by Mark Webb-Johnson 01 Sep '13

01 Sep '13

The v3.1.5 Android App has been released to Google Play. Enhancements are minor and primarily include support for the display of battery CAC values in the vehicle info sheet. The logo artwork has also been updated, to better reflect the multiple vehicle support we now have available.

1 0