December 2014 - 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

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

Tesla Model S CAN bus hacking (for fun, not necessarily profit)
by Mark Webb-Johnson 02 Jan '15

02 Jan '15

I'm setting up a mailing group for Tesla Model S CAN bus hacking. If you are interested, please let me have your eMail address and I'll add you in. Just starting work now on having a look at what is going on inside the Model S, decoding messages, and looking at possibilities for OVMS or other projects. Current status: https://github.com/openvehicles/CAN-RE-Tool/blob/master/rules/teslamodels Regards, Mark.

10 9

Fwd: [3-8620000005468] Google Notification to Open Vehicle Monitoring System
by Mark Webb-Johnson 11 Dec '14

11 Dec '14

Google getting strict, or just a little fish caught in a bigger net? Mark Begin forwarded message: > From: maps-api-usage-questions(a)google.com > Date: 11 December, 2014 3:56:58 pm HKT > To: Mark Webb-Johnson <mark(a)openvehicles.com> > Subject: RE: [3-8620000005468] Google Notification to Open Vehicle Monitoring System > > Dear Developer, > > Thank you very much for sending us additional information about your application. After reviewing the information you sent us and looking again at the application, it is clear to us that your application is not violating the terms we previously mentioned. > > We are sorry about the false alarm. > > Regards > Google Maps Team > > > > On 12/08/14 13:06:06 mark(a)openvehicles.com wrote: > > Thank you for your eMail and bringing this issue to our attention. > > Our project is a pure open source community project. > > Open Source Repository for vehicle firmware: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/tree/master/… > Open Source Repository for vehicle hardware: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/tree/master/… > Open Source Repository for server code: https://github.com/openvehicles/Open-Vehicle-Monitoring-System/tree/master/… > Open Source Repository for iOS App: https://github.com/openvehicles/Open-Vehicle-iOS > Open Source Repository for Android App: https://github.com/openvehicles/Open-Vehicle-Android > > We do not charge any fees for our App, and do not charge any fees for our service. There is no fee based subscription and no fee based restricted access. We do not sell any services, or offer any fleet management facility. > > Can you clarify why you think that we are in violation of these terms, as from our understanding we are not? > > Regards, > Mark Webb-Johnson > >> On 8 Dec, 2014, at 3:05 pm, maps-api-usage-questions(a)google.com wrote: >> >> Dear Developer, >> >> We're happy to see developers interested in our products, however, your app, "Open Vehicle Monitoring System", violates the following Google Maps APIs terms of service (https://developers.google.com/maps/terms) >> >> a) Your app violates clause 9.1.1(a), which states that your application must be generally accessible to users without charge and must not require a fee-based subscription or other fee-based restricted access. Note that mobile apps sold through an app store can be sold for a fee. >> However, if you charge a subscription for your app, you need a Google Maps API for Work license to continue using Google Maps APIs in your app. >> >> b) Your app violates clause 10.2(d)(iii), which does not allow developers to use Google Maps APIs for an enterprise dispatch, fleet management or asset tracking application without an enterprise license. You must obtain a Google Maps API for Work license for your application to continue using Google Maps APIs. >> >> Please contact our sales team using this form to obtain a Google Maps API for Work license: http://www.google.com/enterprise/mapsearth/. >> >> We’re bringing this to your attention so we can work together to make sure your app complies with our terms of service. If you’re not able to bring your app into compliance with the terms, we will take action to restrict your access to the service. Further, we may request removal of your app from all app stores. >> >> Please let us know within the next 14 days that you have updated your app to comply with our terms of service. You can respond to this e-mail. >> >> Thanks for your cooperation, >> Google Maps Team >> >> Please contact our sales team using this form to obtain a Google Maps API for Work license: http://www.google.com/enterprise/mapsearth/ >> >> We’re bringing this to your attention so we can work together to make sure your app complies with our terms of service. If you’re not able to bring your app into compliance with the terms, we will take action to restrict your access to the service. Further, we may request removal of your app from all app stores. >> >> Please let us know within the next 14 days that you have updated your app to comply with our terms of service. You can respond to this e-mail. >> >> Thanks for your cooperation, >> Google Maps Team > > > > Begin forwarded message: > >> From: maps-api-usage-questions(a)google.com >> Subject: Google Notification to Open Vehicle Monitoring System >> Date: 8 December, 2014 3:05:05 pm HKT >> To: support(a)openvehicles.com >> >> Dear Developer, >> >> We're happy to see developers interested in our products, however, your app, "Open Vehicle Monitoring System", violates the following Google Maps APIs terms of service (https://developers.google.com/maps/terms) >> >> a) Your app violates clause 9.1.1(a), which states that your application must be generally accessible to users without charge and must not require a fee-based subscription or other fee-based restricted access. Note that mobile apps sold through an app store can be sold for a fee. >> However, if you charge a subscription for your app, you need a Google Maps API for Work license to continue using Google Maps APIs in your app. >> >> b) Your app violates clause 10.2(d)(iii), which does not allow developers to use Google Maps APIs for an enterprise dispatch, fleet management or asset tracking application without an enterprise license. You must obtain a Google Maps API for Work license for your application to continue using Google Maps APIs. >> >> Please contact our sales team using this form to obtain a Google Maps API for Work license: http://www.google.com/enterprise/mapsearth/. >> >> We’re bringing this to your attention so we can work together to make sure your app complies with our terms of service. If you’re not able to bring your app into compliance with the terms, we will take action to restrict your access to the service. Further, we may request removal of your app from all app stores. >> >> Please let us know within the next 14 days that you have updated your app to comply with our terms of service. You can respond to this e-mail. >> >> Thanks for your cooperation, >> Google Maps Team >> >> Please contact our sales team using this form to obtain a Google Maps API for Work license: http://www.google.com/enterprise/mapsearth/ >> >> We’re bringing this to your attention so we can work together to make sure your app complies with our terms of service. If you’re not able to bring your app into compliance with the terms, we will take action to restrict your access to the service. Further, we may request removal of your app from all app stores. >> >> Please let us know within the next 14 days that you have updated your app to comply with our terms of service. You can respond to this e-mail. >> >> Thanks for your cooperation, >> Google Maps Team

2 1

Server Log 'S' Records Missing
by Tom Saxton 11 Dec '14

11 Dec '14

First off, I really appreciate that there's a way to get a log of OVMS data from the server. It's been incredibly helpful to have this data as a compliment to what's available in the Roadster's log file. I'm sure it's even more useful for vehicles that don't have an accessible, built-in logging system. Thanks, Mark! In examining the OVMS server logs, I've noticed some missing status 'S' records (generated by the net_msgp_stat function). Specifically, I'm not seeing S records during a charge, when the SOC changes while the car is idle, or when the smartphone app connects to get SOC info. The details... I'm using the HTTP API to download the OVMS records from the default server, tmc.openvehicles.com. I have firmware version 2.6.7/TR/V2 (with Mark's commit on Dec 7th), with a slight modification that has it read the calculated amp-hour capacity (CAC) 11 minutes after each charge or drive segment. I have a script that decodes and summarizes the records to make them more human-readable, and convert the timestamps to local time. I drove yesterday, December 8th, and plugged it in when I got home. I see the expected environment 'D' records once an hour thereafter, up through this one at 4:56 am: 12/09/2014-04:56:02 D odo 42963.6, trip 27.8, Amb 15C, Batt 19C, PEM 26C, Motor 37C, parked 14:04:47 According to the logs, the charge started at 5:53:39 am this morning, December 9th. At 5:55, it sent four S records within 30 seconds as the charge was ramping up. 12/09/2014-05:55:20 S standard 81%, 150 IM, CAC 149.84 Ah, 0:00, 0 kWh, -1V/0A, CTP 1:22 12/09/2014-05:55:25 S standard 81%, 150 IM, CAC 149.84 Ah, 0:00, 0 kWh, 1V/0A, CTP 1:22 12/09/2014-05:55:40 S standard 81%, 150 IM, CAC 149.84 Ah, 0:00, 0 kWh, 1V/0A, CTP 1:22 12/09/2014-05:55:44 S standard 81%, 150 IM, CAC 149.84 Ah, 0:00, 0 kWh, 240V/17A, CTP 1:22 While it was charging, it sent in D records every 10 minutes. 12/09/2014-05:56:08 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 20C, Motor 18C, parked 15:04:57 12/09/2014-06:06:06 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 25C, parked 15:14:48 12/09/2014-06:16:05 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 31C, parked 15:24:50 12/09/2014-06:26:03 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 36C, parked 15:34:52 12/09/2014-06:36:01 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 41C, parked 15:44:43 12/09/2014-06:45:59 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 45C, parked 15:54:45 12/09/2014-06:55:57 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 49C, parked 16:04:46 12/09/2014-07:05:56 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 34C, Motor 52C, parked 16:14:37 Presumably this is from the code in net_state_ticker600() that checks all of the potential messages to the server every 10 minutes when the car is "busy" and sends those that have changed, but why are there D records but not S records when we know the SOC value is changing? Problem #1: Why are there no S records reported during a charge? At the end of the charge, there are two records. This first one shows the car is no longer charging at 7:10:30 am with the SOC at 98% and 182 ideal miles. This is the car's preliminary SOC estimate (which is generally too high). 12/09/2014-07:10:30 S standard 98%, 182 IM, CAC 149.84 Ah, 1:15, 8 kWh, 1V/0A, CTP 1:22 Next is the charge log record which says the charge ended at 07:08:31, and shows the end charge with the preliminary SOC estimate. 12/09/2014-07:11:00 h Charge Log 0, 12/09/2014-05:53:39 1:14:52, Standard, 81% -> 98%, 150 -> 182 IM, CAC 149.84 Ah Next we get another drive record with updated temperatures. 12/09/2014-07:15:59 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 32C, Motor 51C, parked 16:24:49 Ten minutes after a charge (or drive) segment ends, the car updates the SOC estimate with a more reliable number. At the same time, it updates the CAC. (My change to the OVMS firmware reads the CAC a minute after this happens.) Conveniently, I see an S record which has the updated information. I don't see what generates this record, but I have seen this pattern on the last two charges and I like it. 12/09/2014-07:21:23 S standard 96%, 179 IM, CAC 149.90 Ah, -1, 8 kWh, -1V/127A, CTP 1:22 Now the car settles into the idle state where, once an hour, it looks at all of the car data and sends messages to the server with any records which have updated fields. The D record always updates because the park time is constantly changing even if none of the temperatures do. So, we get a string of D records, once every hour. 12/09/2014-08:15:52 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 32C, Motor 51C, parked 17:24:38 12/09/2014-09:15:42 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 32C, Motor 51C, parked 18:24:27 At 9:09, I checked the car's touchscreen and saw that the SOC on the touchscreen was reading 177 ideal miles. I'm not sure when this happened, but it was clearly before 9:15 when the last D record was sent. Problem #2: Why didn't the the net_state_ticker3600() function send an S record when the SOC changed? At 9:59 am, I connected with the OVMS iPhone app, and saw that the SOC was showing correctly in the app. When the screen first drew, it said the car's data was 45 minutes old but it had the correct SOC, 177 ideal miles. It then updated to "live", still showing the correct SOC. From the server log, I see that a D record got recored when I connected with the iPhone, but there's no S record. 12/09/2014-10:00:51 D odo 42963.6, trip 27.8, Amb 16C, Batt 19C, PEM 32C, Motor 51C, parked 19:09:34 Problem #3: How did the app get the updated SOC if the server hasn't received any S records? Clearly, it got the SOC from somewhere, but it's not showing up in the server logs. The firmware code looks great to me. It should send along the S records when the SOC and CAC fields change, but there seem to be a bunch missing from the reported server logs. Either they aren't getting sent (which doesn't explain how the smartphone app gets the correct values) or they aren't being recorded on the server, or they aren't being reported by the HTTP API. Any idea what's going on? Tom

2 2

v2.6.7
by Mark Webb-Johnson 09 Dec '14

09 Dec '14

Its been a while, and quite a bit has changed, so time for a new firmware. Changes: Twizy updates Think city updates TR VECE updates Fix issue #135 (SMS response messed up for GPRS?, etc) Fix for net_msg handling of SMS LOCK, UNLOCK, VALET, UNVALET (and others) in Tesla Roadster module Make all SMS responses include the time (if possible), but add a carbits feature FEATURE_CB_SSMSTIME to allow this to be suppressed Allow ACC acc_handle_msg to choose to handle a particular message First implemention of net_fnbits NET_FN_CARTIME (as per http://lists.teslaclub.hk/pipermail/ovmsdev/2013-November/001819.html <http://lists.teslaclub.hk/pipermail/ovmsdev/2013-November/001819.html>) For the NET_FN_CARTIME, this is enabled in vehicle modules by setting net_fnbits |= NET_FN_CARTIME during initialisation (see vehicle_obdii.c for an example) and then not adjusting car_time at all. The car_parktime can be set as normal (using car_time as a reference). This is completely untested (I’ve somehow lost GSM connectivity to my workbench in the last week or two, so this is proving hard for me to test). The logic for NET_FN_CARTIME is implemented in three places: The vehicle.c implements initialisation of car_time. The led.c implements an interrupt to increment car_time every second. As we treat 104.8576ms as 105ms, we are 0.1424ms inaccurate for each clock tick, which may build up over time (but is still more accurate than the previous approach). The net.c implements handling the response to +CCLK polls, and adjusts car_time and car_parktime if necessary. I’d appreciate it if someone with better connectivity on their workbench could help test this, and fix as appropriate. Hopefully we can get any bugs in this worked out over the next few days and when it is working change the vehicle modules to use it and then cut a firmware v2.6.7. Regards, Mark.

3 6

Twizy SEVCON object dictionary
by Julien NOZAIS 01 Dec '14

01 Dec '14

Hi, I have been working on my thesis with my Twizy and OVMS for a few month. Among the various documents I have used, a Master Object Dictionary from SEVCON helped me a lot to understand all the parameters. However the document I have found (on some forum) is not specific to SEVCON Gen 4, as it includes other versions of the objects and some that are not implemented in Gen 4. I assume the work done on the twizy by you guys needed such dictionary. I am wondering if you happen to have a more recent or updated version for the Gen 4, or a *.cdf file ? If so, would you be so kind as to send me a copy ? I went through the mailing list's archive but no one seems to talk about it. I would also be interested to know how you managed to found that document. Is it easy to get it from SEVCON or from some other source ? Best regards, Julien

2 2