September 2012 - OvmsDev

Thoughts on iPhone 5 and its larger display
by Mark Webb-Johnson 24 Sep '12

24 Sep '12

I guess the following thoughts may be interesting to others in our community... I've been looking at our iOS App - as I need to send out a new build anyway (to appease the British in America, and their pesky Celcius vs Miles issue), I had a look at adding support for the new iPhone 5 with its bigger display. The iPhone 4S has a screen of 960 x 640, and the iPhone 5 has a screen of 1136 x 640. An extra 176 pixels in the vertical orientation. 1136 vs 960 is a little over 18% taller. Not much difference, right? If the developer does nothing to his App, it gets letter boxed. Two black borders of 88x640 pixels are added to the top and bottom, and the application virtual size of 960 x 640 is maintained - even though it is running on a 1136x640 display. It turns out by adding one file to the build project (a specially named splash screen at the 1136x640 resolution), you tell the iOS not to letterbox you, but give you the full screen. Doing that I expected to get a little 18% layout problem. Not so fast. If you look at the screenshot (from an iPhone 4S) below, you can see the status bar, top bar, and bottom tab bar are all fixed in size (whether it is running on a 4S or 5). It is the big blue bit in the middle that gets resized. The status bar is 40 pixels in height, the top bar 128 pixels and the bottom tab bar 98 pixels. That leaves 960-(40+128+98) = 694 pixels (the height of that blue background bit) to show the real application content. On an iPhone 5, the status bar, top bar and bottom tab bar all remain the same. That leaves 1136-(40+128+98) = 870 pixels to show the real application content. 870 vs 694 is a little over 25% more usable screen real estate. This explains a lot to me about what is so important about the iPhone 5 being just that little big taller. 25% more usable screen real estate for an App like ours. I've already re-worked the App auto-layout to at least look on the iPhone 5. Things like the map, tables and lists just automatically work and take advantage of the extra room. But, fixed screens like the Battery and Car will take some work to think about and take advantage of that new usable screen real estate. Regards, Mark.

3 7

Auto-Provisioning Profile Table
by Mark Webb-Johnson 22 Sep '12

22 Sep '12

The system I've come up with seems to work really really well. The server is done, and the provisioning record is stored encrypted on the server. A web page will be used to enter all the information necessary (including VIN, ICCID, choice of vehicleid, passwords, etc), and then create and store the encrypted provisioning record ready for the car. The car module is just plugged in, un-configured. It picks up the ICCID from the SIM, the VIN from the CAN bus, connects to the server, gets the provisioning record, sets all parameters as necessary, then reboots itself online. If we know the ICCID prefix, then the system can completely auto-auto-provision the SIM. If we don't know the prefix, that is fine - the user just needs to create one phonebook entry named OVMS-AUTO with the telephone number being the profile number matching the cellular network they are using. For special cases, the system also supports O-XX-YYYY phonebook entries to set parameter #XX to YYYY. I'm creating an Auto-Provisioning profile table for the most common cellular networks our users are using. For each network, I need: Cellular provider service name (eg. AT&T GoPhone) Cellular APN (for GPRS) Cellular Username (for GPRS) Cellular Password (for GPRS) and optionally the ICCID prefix on the sim cards (starts with 89 and is typically 18-20 digits in length) I currently have: // Fields are ICCID-prefix, cellular APN, username and password rom char ap_profiletable[][4][22] = { {"8923418","MOBILEDATA","","" }, // Profile 0: geosim {"", "WAP.CINGULAR","",""}, // Profile 1: AT&T GoPhone {"", "ISP.cingular","",""}, // Profile 2: ATT Telemetry SIM for business {"", "imobile.three.com.hk","",""}, // Profile 3: ThreeHK {"", "internet.com","wapuser1","wap"}, // Profile 4: Rogers "Pay as you go" {"", "gcpre","",""}, // Profile 5: Guam Docomo Pacific GO! {"","","",""} }; The ICCID is normally written on the SIM card itself, or you can get it electronically via AT+CCID, and is described here: http://en.wikipedia.org/wiki/Subscriber_identity_module#ICCID What we need is the Issuer identification number (IIN). It is at the start, a maximum of seven digits, and formed by: Major industry identifier (MII), 2 fixed digits, 89 for telecommunication purposes. Country code, 1–3 digits, as defined by ITU-T recommendation E.164. Issuer identifier, 1–4 digits. It is normally then followed by a bunch of zeros and then numbers (all part of the individual account identification number). If you would like me to add a profile for your network, to be included in the next firmware, please let me know the above details. It would help out users with the same cellular provider as you. Thanks, Mark.

1 0

Without SMS
by Mark Webb-Johnson 20 Sep '12

20 Sep '12

Trying to work out ways to provision OVMS modules without SMS. One way is the new DIAG port SETUP mode. But, that requires a RS232 connection to the PC (not so easy nowadays, with a USB-RS232 adaptor required for most laptops). Also kind of messy for v1 modules. Another way is phonebook entries on the SIM card. The problem here is that you need some way to create the phone book entries. With older 'feature' phones, that was easy. But, now in the days of iPhone I suspect more tricky. Another problem is that the number field can only be numbers, not alpha-numeric, so textual data must go in the phonebook entry name field itself. For the SIM card phonebook, I'm thinking of two approaches: Create phonebook entries like "O-8-MYVEHICLEID", "O-5-APN", etc. The O- prefix tells us this is OVMS, the next number is the parameter number to set, and the remainder is the value. This is very flexible, but the textual fields are limited in length (typically 16 characters or so), and it looks kind of messy. For specific providers, we could do an auto-provisioning. Something like create a phonebook entry on the SIM 'OVMS-AUTO' with number 0. The number references an auto-provisioning profile, and that just provides the cellular network APN, user and password. The system would then use those to establish a GPRS connection, learn the SIM ID from the SIM, learn the vehicle VIN from the can bus, then provide both to the OVMS server. A shared secret is required here, and we have two private pieces of information, so this should be ok. We can encrypt with the SIM ID, and provide the VIN as the key. The OVMS server would lookup the VIN key provided, decrypt and check it against the SIM ID, and if all is ok could provide back a similarly encrypted provisioning profile containing everything else required (all the other parameters). For this to work, the SIM would just have to have that special "OVMS-AUTO" phonebook entry created. The main reason I'm thinking about this is for the globalsimcard provider I'm working with. They can provide SIM cards that work globally for data only, with pretty good rates. Cards are good for 12 month validating and can be renewed for another year for less than US$10. Monthly cost should be US$1 + data, hassle free, and data should be less than US$2 for most providers. If we can auto-provision these, then setup should be to configure the provisioning information as you want, on the server, then just plug the SIM in and go. Every SIM card issued has a defined prefix in its ID. I'm trying to find out of the globalsimcard prefix will always be the same, and will always differentiate these from others. If so, then we can auto-provision based on SIM ID as well (without even needing the OVMS-AUTO phonebook entry). What do people think? How easy would it be for people nowadays to create a phonebook entry on a SIM card? Regards, Mark.

2 2

USA AT+COPS=?
by Mark Webb-Johnson 18 Sep '12

18 Sep '12

Can someone in USA please help out with something? I need you to connect a RS232 port to the DIAG port of a powered-up OVMS module. Then, at 9600 baud type 'AT' and make sure you get back 'OK'. Then, type 'AT+COPS=?' and let me know what you get back (the command will take about 30 seconds to run). The result should be a list of cellular providers, and their short codes. I'm particularly interested in what AT&T and T-Mobile show up as in USA. Thanks, Mark.

1 0

Adaptive Reporting
by Mark Webb-Johnson 18 Sep '12

18 Sep '12

I've raised a bunch of github issues, to track implementation of adaptive reporting: https://github.com/markwj/Open-Vehicle-Monitoring-System/issues/82 https://github.com/markwj/Open-Vehicle-Monitoring-System/issues/83 https://github.com/markwj/Open-Vehicle-Android/issues/7 https://github.com/markwj/Open-Vehicle-iOS/issues/3 The current approach to GPRS reporting is: If one or more apps are connected, then report everything every 1 minute else report everything every 10 minutes The new approach will be: If one or more apps are connected, then incrementally report changes every 1 minute else if charging or driving then incrementally report changes every 10 minutes else incrementally report changes every 1 hour. The incremental part of the reporting will be done by CRC checksums on the data messages. The change means that if you are charging, driving or an app is connected, there is no effective difference - if something changes that it will be reported. But, if the car is just sitting there switched off and not charging, with no app connected, then it will further back off to just report in changes once an hour. The effect should be about 1/5th (estimated) the data usage if things are changing, and perhaps 1/10th (estimated) the data usage if things are not. Perhaps 2MB/month down to 200-400KB/month. Of course, the mobile providers round up connections, so that is going to reduce the actual billing impact. I still want to report in, periodically, because if the car disconnects then at least we have the data as of worst case 1 hour before it disconnected (or 10 minutes if it was charging / driving). Note that this doesn't affect 'keepalive'. We still have tiny OVMS protocol-level keepalives every 15 minutes, and even tinier TCP/IP keepalives every 4 minutes. Regards, Mark.

2 2

Adaptive Reporting
by Mark Webb-Johnson 17 Sep '12

17 Sep '12

I've raised a bunch of github issues, to track implementation of adaptive reporting: https://github.com/markwj/Open-Vehicle-Monitoring-System/issues/82 https://github.com/markwj/Open-Vehicle-Monitoring-System/issues/83 https://github.com/markwj/Open-Vehicle-Android/issues/7 https://github.com/markwj/Open-Vehicle-iOS/issues/3 The current approach to GPRS reporting is: If one or more apps are connected, then report everything every 1 minute else report everything every 10 minutes The new approach will be: If one or more apps are connected, then incrementally report changes every 1 minute else if charging or driving then incrementally report changes every 10 minutes else incrementally report changes every 1 hour. The incremental part of the reporting will be done by CRC checksums on the data messages. The change means that if you are charging, driving or an app is connected, there is no effective difference - if something changes that it will be reported. But, if the car is just sitting there switched off and not charging, with no app connected, then it will further back off to just report in changes once an hour. The effect should be about 1/5th (estimated) the data usage if things are changing, and perhaps 1/10th (estimated) the data usage if things are not. Perhaps 2MB/month down to 400KB/month. I still want to report in, periodically, because if the car disconnects then at least we have the data as of 1 hour ago.

1 0

Alarm messages
by Jack West 16 Sep '12

16 Sep '12

Developers, Has anyone decoded the alarm message on the can bus of the Roadster? Any ideas where it might be hiding? Thanks, Jack

2 7

An update on OVMS Pre-Orders
by Mark Webb-Johnson 15 Sep '12

15 Sep '12

Open Vehicle Monitoring System An update on OVMS Pre-Orders Since we announced the v2 hardware, we've been inundated with pre-orders both from Tesla Roadster owners and others wanting to get this in their cars (and willing to help with the necessary CAN bus analysis and coding to achieve that). The initial factory test production run was just 20 modules (limited primarily to make sure the production and QC were acceptable, before committing to a larger order). We sent out a dozen invitations, and shipped the first 14 units, this week. The invitations for the remaining modules in the first batch will go out in the next few minutes. Earlier this week, we also confirmed with the factory the order for the next batch of 100 modules, and are arranging further production runs. That will be sufficient to fulfil all current pre-orders as well as have sufficient modules in stock to be able to ship next-business-day for future orders. The factory has already completed assembly and testing of the cases, cables and antennas. What remains is the soldering of the PCBs, then QC. We expect to receive the next 100 modules within the next 7 to 14 days, and to be able to ship these out to everyone who wants one, before the end of this month (September). We have finalised pricing for the new v2 modules. For Tesla Roadster owners, this will be: OVMS Car Module v2 US$ 99.00 OVMS Tesla Roadster Cable US$ 7.50 OVMS GSM Antenna US$ 2.50 (all the above including air-mail shipping) EMS shipping (to USA): US$ 20.00 (estimate) TOTAL should be around US$129.00 (confirm at checkout) Note: EMS shipping is required on this, due to the value of the goods [ Note that the older hand-built v1 modules were sold at US$99 (module) + US$35 (shipping) = US$134.00 total ] To make the delivery process smoother, we've appointed a China-based on-line distributor Fast Tech to handle this for us. We expect to be able to send out ordering details for the remaining pre-orders in about 7 to 10 days. We apologise for the delays in this, but need to make sure that everything is in place for a smooth scaling up of production and delivery of units. The previous arrangement of Sonny and myself handling all QC, packing and logistics in our spare time was just not scaleable and led to delays in shipment. Fast Tech have committed to next-day shipping for in stock items and can deal with the packing, customs and other logistics issues much better than us. Best Regards, openvehicles.com

1 0

iOS App 1.3.0
by Mark Webb-Johnson 13 Sep '12

13 Sep '12

TestFlightApp testers should have received the following regarding the v1.3.0 release of the Open Vehicles App. Changes are pretty minor. There are now options for setting the temperature and distance units in the iOS Settings App, Open Vehicles section - particularly helpful for British in America. I've also added support for iOS 6 and iPhone 5. If no problems are reported, then I'll submit to Apple sometime next week. Regards, Mark. Open Vehicle 1.3.0 (20120913) Team: Open Vehicles What's New: 1.3.0 (20120913) - Minor bug fixes - Temperature Options in Settings App - Support for iOS 6 - Support for iPhone 5 Released: September 13, 2012 Expires In: 2 months, 2 weeks Size: 9.7 MB Notification Settings Follow Us Support Powered by TestFlight

1 0

Feature request: secured charging
by Dominik Westner 13 Sep '12

13 Sep '12

Hi, I was wondering if it would be possible to trigger the car alarm for 10s if charging is interrupted while the car is locked. I live right in the middle of Munich and don't have a garage where I can charge (really hard to find) close by. However I have some public charging stations very close to my home which I am regularly using. Unfortunately charging will be interrupted almost every second time now, because some people disconnect the cable. It is very annoying and I don't understand why people would do that. But it happens more and more. And it is also likely that it is the same people doing it. My hope is that some people would be scared away if the alarm goes off and not doing it the next time again. Thanks Dominik

4 3