- OvmsDev - Open Vehicles

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

Can't set OVMS time zone
by Tom Saxton 27 Nov '14

27 Nov '14

I'm having problems setting the time zone from the iPhone app. When I try to change parameter #23 from -07:00 to -08:00 (or simply -8, or even -07:00), I get a "parameter out of range" error. The server log says: 2014-11-26 07:23:11 C 4 -200 -07:00 2014-11-26 07:23:14 c 4 1 Parameter out of range 2014-11-26 07:23:18 C 4 -200 2014-11-26 07:23:22 c 4 1 Parameter out of range 2014-11-26 07:23:29 C 4 -200 -08:00 2014-11-26 07:23:32 c 4 1 Parameter out of range 2014-11-26 07:24:02 C 4 -200 2014-11-26 07:24:05 c 4 1 Parameter out of range 2014-11-26 07:24:12 C 4 -200 -07:00 2014-11-26 07:24:16 c 4 1 Parameter out of range Is anyone else having this issue? I do have a few small changes in my version of the firmware, but nothing anywhere near the parameter setting code. Tom

2 2

module GPRS connection frequency
by Lee Howard 11 Nov '14

11 Nov '14

For those of you using unlimited data plans this may not matter, but for those of us using per-use/per-minute/per-MB plans the frequency at which the OVMS module connects via GPRS to the OVMS server is quite relevant for the long-term cost of using OVMS. For example, I'm using AT&T "GoPhone" per-minute plans which basically result in a $0.01 charge every time the OVMS module connects via GPRS to the OVMS server. The OVMS module does this a bit more-frequently than I had anticipated... about 3X more frequently. Consequently, I was a bit surprised to find what I had hoped to be a $100-per-year account get used faster than that... requiring me to add $100 to the account every four months or so. So the per-minute/per-use/per-MB plan I'm on ends up not really being less-expensive than their $25 per-month plan. I see that the OVMS module is connecting with the OVMS server roughly every 7 minutes... even if the car is stationary and there have been no changes to SOC or other vehicle information. I see this behaviour both with module type "VA" and "XX". I would prefer to see the OVMS module connect with the server with *greater* regularity (like, every 2 minutes) when GPS position is changing (more than the expected 60-meter or so "jitter" that I usually see) or when SOC is changing or some other information changes. However, if the vehicle is stationary and there are no SOC changes or other information changes, then I would prefer to see the OVMS module connect to the OVMS server very infrequently... like only every 30-90 minutes. Is this, by chance, something configurable? Or is this something that I'm going to need to build-into the firmware, myself? 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

3 6

Tesla Model S
by Bruce Sharpe 11 Nov '14

11 Nov '14

There was a discussion on this list some months ago that sounded quite promising for reading CAN bus data from the Model S. Then it went quiet. Are people still interested in exploring this? Regards, Bruce

2 1

How to get a quick and reliable GPS fix
by Arthur Hebert 08 Nov '14

08 Nov '14

Hi All, Does anyone know the details of how, most reliably and most quickly, to get a location fix from the GPS module after it has been powered up and after it has come out of sleep mode? I have written my own code using the OVMS hardware. To save power, it turns off the GPS power (AT+CGPSPWR=0) and puts the module to sleep (AT+CSCLK=2) while the vehicle is parked (i.e. no CAN bus activity). Once there is CAN activity again, it comes out of sleep mode (AT+CSCLK=0) and turns on the GPS (AT+CGSPPWR=1). Immediately after turning on the GPS power, I also issue one of the GPS reset commands (AT+CGPSRS=0 or AT+CGPSRST=1). The module documentation if vague about when to use the 0 reset or the 1 reset. I know that the GPS module itself isn't made to function while the module is asleep even though the commands may not give an error. I've read that it takes up to 15 minutes to get a fix on most GPS devices. In practice, sometimes I get a fix within a minute every time I start up, and other times I don't get a fix even after hours of trying with either reset option. Any information will be greatly appreciated. Thanks, Arthur

4 5

Re: [Ovmsdev] Contents of OvmsDev digest...
by Gianluca Magalotti 30 Oct '14

30 Oct '14

Flame on > or tell auto-pilot to drive the car to my location. Wow! mark do you think would be possible to add such feature in ovms in next firmware release? Flame off :) I think the only ovms limit is the communication layer and the vehicle - server - client model (that I prefer over the local communication one because of the wider list of functionalities that this model can provide). I think the real problem is the very heterogeneous markets of data plans. Maybe an umts modem would make simpler connection matters but wouldn't resolve that. When m2m sim would be commodities all over the world (and moving toward an IOT era this cannot be delayed more) this won't be a problem any longer. Until then maybe would be nice to let "switch off" some communication behaviors (position, battery status and so on) or throated as "on demand".

1 0

Re: [Ovmsdev] Tick math
by Gianluca Magalotti 23 Oct '14

23 Oct '14

Ok, so you every 104.8576ms will add 5243MarkSecs (just invented a new time unit) right? And when the counter reaches or pass 50000 you add one second and subtract 50000 to the count. This way you are over 0.0024ms per timer interrupt, roughly 0.022ms per second, that is less than 2s per day (that is, every 43690s we count one second more.) Please check my math.... But you won! Gianluca Magalotti dal mio iPad mini > Il giorno 22/ott/2014, alle ore 06:00, ovmsdev-request(a)lists.teslaclub.hk ha scritto: > > Sorry, in my P.S., I think I miscalculated the improvement. > > 1] Current methodology: > > Signed 16 bit integer > Every 104.8576ms timer interrupt, add 105ms to the counter. > If counter >1,000 treat it as 1 second and deduct 1,000 from counter. > > Accuracy: loses 0.1424ms per timer interrupt. > > 2] 50ms methodology: > > Signed 16 bit integer > Every 104.7576ms timer interrupt, add 5243 to the counter. > That is equivalent to 5242.88 50ms chunks. > Difference is 0.88 / 50 ms > Accuracy: loses 0.01760ms per timer interrupt > > Or, is my new maths wrong? Is the inaccuracy 0.01760ms or 0.12ms per timer tick? > > Confused, I am. > > Mark.

5 7