December 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 19 May '17

19 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 22 Feb '16

22 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

Alternative OVMS server
by Michael Balzer 22 Jan '16

22 Jan '16

FYI: I now operate an alternative OVMS server located in Europe (Strasbourg). The web frontend is a new development based on my own framework. It offers CSV download of historical records and a command shell (well, command line interface up to now, more to come). It also allows to subscribe to notifications by email. The server currently cannot send iOS notifications. => http://dexters-web.de/ Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 4

Possible Manufactoring fault last Batch
by Frank Demes 16 Jan '16

16 Jan '16

Hi Jérôme, could you check your OVMS for some missing soldering on the CAN chip? Gruß Frank > Am 06.12.2015 um 23:35 schrieb Jérôme Nicolle <jerome(a)ceriz.fr>: > > > > Le 06/12/2015 23:19, Michael Balzer a écrit : >> you need to switch on the Twizy to read >> registers. > > Just tried aboard my twizy, in INIT an ON state, couldn't get any reading. > > > -- > Jérôme Nicolle > 06 19 31 27 14 > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

4 6

Twizy current control
by Michael Balzer 27 Dec '15

27 Dec '15

I'm preparing a new Twizy release adding an option to control max current level and raise torque & power levels above the safety limits. T80 example: raise current level to 500 A, set 100 Nm torque level and power level to 15.5 kW (mech): CFG POWER 182 127 119 111 Code and manual updates are in the hub, firmware file can be downloaded from: http://dexters-web.de/f/tw-beta/OVMS-Twizy-3.7.0.zip This has been tested during the last weeks, but on T80 only up to now. T45 should work, but maybe the flux map modification needs some specific optimization. To check this I need some more T45 register data. Maybe some T45 driver can fill the "?" fields in the "Twizy-SDO-List" to help on this: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

DIAG mode Perl clients
by Michael Balzer 27 Dec '15

27 Dec '15

I've added two DIAG mode Perl clients to the repository: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/commit/91cf3… Both have not yet been tested on a Windows system, please report if you do so. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Issue with Open Chargemap on iOS, newest Xcode and SDK
by Geir Øyvind Vælidalo 14 Dec '15

14 Dec '15

Hi guys, I have problems with OCM when I compile with the newest Xcode and SDK. The JSON-response from OCM looks fine, but the data-object containing the JSON-response might be different from the old SDK. Trying to fetch data from the JSON-object fails. This is the first code that fails: - (void)syncAction:(NSDictionary *)data { ... [self parseConnectionTypes:NULL_TO_NIL(data[@"ConnectionTypes"])]; The watch tells me data[@"ConnectionTypes”] is an "invalid expression”, which is understandable since data is an NSCFArray with 100 entries of NSCFDictionary, so data simply do not contain any keys. Shouldn't data have been a dictionary instead? Any ideas, guys? Regards, Geir

2 2

Re: [Ovmsdev] Issue with Open Chargemap on iOS, newest Xcode and SDK
by Christopher Cook 13 Dec '15

13 Dec '15

Yes it sounds like the iOS sdk has gotten stricter parsing JSON. Assuming this is the OCM reference data being parsed nothing significant has changed there. Connections Types will be an array of 20-30 connection type items (j1772 etc). The parent Json object will have entries for CountryList, ConnectionTypes, UsageTypes etc Sent from my Samsung Galaxy smartphone.-------- Original message --------From: Geir Øyvind Vælidalo <geir(a)validalo.net> Date: 14/12/2015 6:16 am (GMT+08:00) To: ovmsdev(a)lists.teslaclub.hk Subject: [Ovmsdev] Issue with Open Chargemap on iOS, newest Xcode and SDK Hi guys, I have problems with OCM when I compile with the newest Xcode and SDK. The JSON-response from OCM looks fine, but the data-object containing the JSON-response might be different from the old SDK. Trying to fetch data from the JSON-object fails. This is the first code that fails: - (void)syncAction:(NSDictionary *)data { ... [self parseConnectionTypes:NULL_TO_NIL(data[@"ConnectionTypes"])]; The watch tells me data[@"ConnectionTypes”] is an "invalid expression”, which is understandable since data is an NSCFArray with 100 entries of NSCFDictionary, so data simply do not contain any keys. Shouldn't data have been a dictionary instead? Any ideas, guys? Regards,Geir

1 0

Re: [Ovmsdev] Apple Watch
by Christopher Cook 13 Dec '15

13 Dec '15

Hi Geir,Let me know what problem your seeing getting the open charge map portion to work. I've not been involved in the OVMS code for OCM but I have a vested interest in keeping it working. Christopher Cook Sent from my Samsung Galaxy smartphone.-------- Original message --------From: Geir Øyvind Vælidalo <geir(a)validalo.net> Date: 13/12/2015 9:35 pm (GMT+08:00) To: ovmsdev(a)lists.teslaclub.hk Subject: Re: [Ovmsdev] Apple Watch Hi Michael, I don’t even know if there are any iOS-developers here at the moment. I’m playing around with the iOS-app, but I can’t make the app work with the Open Chargemap when I compile it, so I’m not really comfortable with it yet. Also I don’t have nor have any plans to buy an Apple Watch in the near future. Regards, Geir > 13. des. 2015 kl. 14.01 skrev Michael Jochum <mikeljo(a)me.com>: > > Hi, > > did anybody have a plan to make the App works with the Apple Watch? > > Bye > Michael J. > _______________________________________________ > 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

2 1