November 2015 - 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

OVMS v3
by Mastro Gippo 20 May '17

20 May '17

Hi all, I'd like to resurrect an old conversation. As we know, the current PIC is quickly running out of resources and maybe it's time to switch to a better platform. Two CAN buses are now desirable too. A microSD slot and direct USB connectivity wouldn't hurt either. I will probably have to design a similar hardware for myself, so I'd like to contribute to the OVMS by sharing the HW platform if you want; no strings attached of course, if you decide that there's no need for the upgrade, I'll keep on working on my project by myself! :) That said, I'd like to throw a few ideas to the table. - MCU: I'd like to use an STM32 micro. They seem to be emerging as the standard choice for diy ARM projects, and this offers a few interesting opportunities: -Programming it in c/c++ with the manufacturer CMSIS standard libraries (boring) -Programming it with the mbed.org SDK. Unfortunately no dev boards are available with dual CAN bus, but it will be easy to move to the correct micro of the same series once most of the software is ironed out on a dev board like the https://mbed.org/platforms/ST-Nucleo-F302R8/ -Programming it with an RTOS. NuttX would be my choice, as it's the one used in the Ardupilot Pixhawk platform, and I'd like to learn it. This would mean a steeper starting curve, but a lot of flexibility later as a lot of stuff is handled on the OS level (network stacks, SD card & filesystems, multitasking...). FreeRTOS is a nice option too. I'd like to use the STM32F405RG as it's the most similar to the one found on the Pixhawk, but of course I'm biased because of that, and that micro is quite overkill for the task. We can of course use a lower specced part and lose some RTOS fuctionality as long as it has 2 CAN buses. - MODEM: I have no experience in this field; is the SIM908 still a good choice or does anyone think that we should try new platforms? I like this, but I don't know if the price puts it out of budget: http://www.telit.com/telit/Pulsar/en_US.Store.display.1001./ge864-gps On the bright side, it can be programmed in python, so we can offload some of the work to the modem. This *could* allow us to free some space on the PIC, and keep that platform without changing MCU.. - Enclosure: I think that, even with the new MCU, we can still fit the old enclosure. Is that ok, or should we think about a more automotive-friendly one? Maybe waterproof for the twizy? And that's it. I think that the core SW developers should voice their opinion, as there is a lot of work to be done on that front. A huge problem will be keeping backwards compatibility to add features for the v2 users, so we should discuss about this too. Regards MG

18 70

OVMS v2 stock / OVMS v3
by Mark Webb-Johnson 23 Feb '16

23 Feb '16

At the current rate, the batch we have of OVMS v2 modules will run out sometime in the next two months. Given the imminent shutdown of AT&T’s 2G network in USA, global re-allocation of 2G frequency bands, and the difficulties we are having obtaining the discontinued SIM908, it is decision time. Option #1: Re-order a large batch now, enough to last us into the new year, but with the risk that I’ll be personally stuck with them. Option #2: Just let the v2 modules run out, and move on with the plans for v3. Development on v2 is stagnating. Partly because the platform already does what we need it to do, and partly because we’re hitting the limits (no external connectivity other than GPRS, single CAN bus, no storage, limited RAM, flash, etc). The v3 plans have been on hold for some time, pending MBED OS release (first beta due this month) and the imminent release of hybrid processors such as that used in the UDOO Neo (due in September). We know what we want, but it is just too hard to pick a long-term platform when everything is on the cusp of changing. I really want a v3 module. Something with lots of RAM and Flash, wifi, bluetooth and cellular connectivity, multiple CAN bus support, and a rich development platform. Something we can all use as a platform for reverse engineering as well as end-user connectivity. I’ll do everything I can to make this a reality. Just not today. Too much is changing and we need to wait for things to stabilise. So, my gut feeling is to choose option #2. 2G GPRS is slowing dying, and building more on that platform just seems to be the wrong decision. This may leave us with several months of no platform stock, but I would rather people waited than spend $100 on something that is going to be obsolete/outdated. Kind of like buying an iPhone in August ;-) I don’t want to be stuck with the stock, and I don’t want people to buy a v2, only to have v3 come out a week later. Even if we started now, which we can’t, an optimistic schedule for the first end-user v3 units would be early 2016. So, tough decisions, but I really think option #2 is best. Bottom line is if you need v2 modules, order them now. If you are likely to need a large quantity for any upcoming projects, let me know. The SIM908 modules will be unavailable within the next month or so, and changing to another module is a PITA I don’t want to deal with (especially given the tight RAM and FLASH we have now). Regards, Mark.

14 37

Kia Soul EV version 0.1
by Robert Cotran 14 Dec '15

14 Dec '15

Hi all, I'm replying to Micheal Balzer's email from yesterday. I wasn't on the mailing list until late yesterday afternoon, hence I'm not able to click reply. I've got a Kia Soul EV 2016 in Canada which doesn't have the UVO services, so this is of great interest to me. I have the OVMS kit in front of me, but I'm a total newbie, so I'm reading through some guides to get started. Just wanted to say that I'll gladly be the guinea pig for this. What I'd REALLY like is to have a way to remotely turn on the climate control system to warm up/cool down the car at will. Hopefully that's a remote possibility. Tracking it is cool, but controlling it is even better. I'm used to a Tesla (my other car), so I am quite spoiled. I did get Micheal's firmware installed on the OVMS and hooked it up to the car but it's not booting properly (based on status LEDs). Can that be because of the firmware or is the bootup sequence separate from the car-control code? The LEDs flash like - 10 Green, 9 Green, 10 Green, 9 Green, then a few reds, then green and red flash together really fast. I tried sending text messages to the board and no dice. Any help would be appreciated, looking forward to getting this working! Robert

6 25

Building with free C18 compiler
by Matt Beard 19 Nov '15

19 Nov '15

Have I missed a decision to no longer support the free C18 compiler - or has it been like that for ages? I am trying to fix an issue in the iMiev code, but can no longer build 2.6.5 due to needing the full compiler and no way am I paying £300 for it. Matt Beard

9 13

C2DM is deprecated, no new sign-ups
by Lee Howard 17 Nov '15

17 Nov '15

I've got my own OVMS server going. However, I wasn't seeing notifications on my phone (Android) since moving away from tmc.openvehicles.com. Looking at the ovms_server.pl code it appears that ovms_server.conf requires this section: [c2dm] email=<email> password=<password> accounttype=<unknown> [This "c2dm" section, along with the "server", "master", and "log" sections are undocumented in the docs/HOWTO.server.txt file.] Okay, so it would seem that I need to set-up a C2DM account with Google and put that info into the conf file. But, Google has deprecated C2DM in favour of Google Cloud Messaging (GCM), and Google is not granting any new C2DM accounts... http://developer.android.com/google/gcm/c2dm.html Is the C2DM account used by tmc.openvehicles.com a generic account that can be used by other OVMS servers? I suspect that it is a private account. If so, then push notifications for Android users on independent servers will necessarily require a transition to GCM. Thanks, Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard(a)mainpine.com | www.mainpine.com

4 10

Need help with CAN-polling.
by Geir Øyvind Vælidalo 16 Nov '15

16 Nov '15

Hi guys, I have a problem with getting the OVMS to fetch TPMS data from my Kia. This is what I do to get the data using ELM327 and a “terminal” on my iPhone: >atcra 7de OK >21 06 7DE 10 22 61 06 00 25 A7 CB 7DE 21 00 37 00 00 00 25 3E 7DE 22 93 00 37 00 00 00 25 7DE 23 9D F5 00 37 00 00 00 7DE 24 25 3F 65 00 37 00 00 It returns the data I need, but when I add this to the poll-list in OVMS: { 0x7df, 0x7de, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x06, { 60, 10, 0 } }, // TMPS I get no response :-( I’ve tried different module id’s but I don’t quite understand which one the ELM uses. I’ve added several other polls without any problems to the Kia code, and I’m pretty sure the problem isn’t in the poll0-code, as i’ve only added a case 0x7de, and it never seems to trigger. Any tips or ideas? Best regards, Geir

2 2

Kia Soul EV development
by Michael Balzer 01 Nov '15

01 Nov '15

List, I'm pleased to introduce the dedicated OVMS Kia Soul developer (he should have subscribed by now): please welcome Geir :-) > Gesendet: So 1. Nov 2015, 00:32 > Von: goev_no05 > An: dexter > > Hi Michael! > > I've been playing a lot with the code today :D It works quite well, > although the VIN is shifted three bytes so I'm missing the first > characters. The DEBUG 1 and 5 seem to be off too, but it just seem > like they might be off by only one byte. I think so because I can > fetch the aux battery voltage from row 4 byte 4, instead of byte 5 as > should be expected. This is a little strange as it seems to be the > same code as VIN. But I will look into these matters tomorrow! > > I've added a lot of new data to your code: In my version I now show > the correct SOC (V0.2 shows the BMS SOC which is around 4% lower), > Odometer, aux battery voltage, correct charging power (it looks right > at least for 230V systems). I'm also setting the charging modes based > on the charging power and I copied the Range/Ideal range code from the > Twizy and adapted it to the Kia. I think I will copy the CA-setting > too, as they seem to be quite useful. > > I feel that I have quite a good understanding of the system now, so if > you want, I can relieve you from the Kia Soul-development :) > > I am also subscribing to the ovms-developer list, so hopefully I don't > need to bother you here anymore ;) > > Good night, and take care! > > Geir As the OBD polling support for modes 02, 10 & 21 basically works, I now have pushed my latest changes including Kia V0.2 to the main repository. The Kia VIN currently needs to be cut by 3 bytes because the car_vin can only take 17 chars. As RAM is tight I decided to omit the first three chars. There would be space for a 20 bytes car_vin, but then the VIN is not that important IMO. You're right, the aux battery voltage should be in row 4 byte 5, and there is no intended offset, so that might be a bug. Glad to have you on board :-) Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 2