March 2012 - OvmsDev - Open Vehicles

1.2.2
by Mark Webb-Johnson 01 Apr '12

01 Apr '12

Car firmware 1.2.2 has been committed to github. Changes since 1.2.0 are: 2012-03-30 1.2.2 End-User firmware 1.2.2 Issue #31: Performance mode bug fix and kludgy workaround Issue #32: Bug in net_sms handling CARBITS feature #14 Tesla Roadster v1.5 tested compatible and supported Issue #31 was a minor issue, affecting performance mode. It is a good fix to have in your cars. Issue #32 brings support for 1.5 Tesla Roadsters (thanks to Tom for all his hard work on this). I'd appreciate your help by flashing this to your car modules and let me know if you see any problems. We'll probably start shipping this as the standard firmware from sometime mid-to-late next week. Thanks, Mark. P.S. You can see the code changes with "git diff -r 478c3588d11aa4fd5f30359997fe16d2ee0d34b1 vehicle/OVMS.X/*.c vehicle/OVMS.X/*.h vehicle/OVMS.X/*.def". Really minimal, and the entire patch is only 151 lines.

2 3

Switch to tmc.openvehicles.com
by Mark Webb-Johnson 31 Mar '12

31 Mar '12

I'd like to move all production cars off www.openvehicles.com to tmc.openvehicles.com. Over the coming month we're going to be doing some work on the server (to add some features), and that may mean some interruption. The server could go up and down intermittently as we work on stuff. It would be much easier if everyone is using the production tmc.openvehicles.com server hosted by Tesla Motors Club. We're trying to keep that server as stable as possible (and as it is hosted in USA, it should be fastest for most). To make the change: Send an SMS to the car with "PARAMS K SMS,IP 64.111.70.40" (adjust as appropriate) and wait for the switch to occur. Or, use the apps to change the server IP parameter #4 to 64.111.70.40 then reboot the car module. On your app, switch from using www.openvehicles.com as the server to using tmc.openvehicles.com. On the iPhone this is in the Settings App of the iPhone (not OVMS app) under "Open Vehicles". On Android, you can find it on the car settings screen. Thanks, Mark.

1 0

v1.5 support
by Mark Webb-Johnson 29 Mar '12

29 Mar '12

Guys, Good news regarding v1.5 roadster support. Tom Saxton has been helping us with this, and has found a bug in the SMS part of feature #14 setting (the feature that stores the carbits for things like suppressing sms alerts and most importantly defining the car as a v1.5 roadster). With that fixed, it appears that the OVMS module works perfectly in the v1.5 Tesla Roadsters (even advanced features such as setting charge mode). I expect to cut a v1.2.2 car firmware (to formalise support for v1.5 cars) over the weekend, and would appreciate your assistance with testing this - I'll eMail when it is ready and running in my car. It will include the fix for issue #31 (Performance mode bug fix and kludgy workaround) as well as Tom's fix for the feature #14 support. Other than that, the car firmware seems fine and is now running in a large number of cars (both developers and end-users). I've got a pile of UI enhancements to the iPhone App from Felix, that I've been working on. I hope to get these into a testlight release this weekend as well. And, finally, the new batch of hardware has arrived and QC tested fine. The new cable supply is looking much better - we're really happy with the new connector arrangement and quality of cable crimping. We hope to ship all outstanding back-ordered units today, to clear our backlog, and we should now have plenty of stock of modules going forward. Regards, Mark.

1 0

Fwd: OVMS Vehicule Registration
by Mark Webb-Johnson 19 Mar '12

19 Mar '12

A suggestion from a user... Begin forwarded message: > Quick suggestion: don't you think a bow-tie like on the Riadster would be a better icon for valet mode? >

1 0

Any Telco engineers?
by Mark Webb-Johnson 19 Mar '12

19 Mar '12

Any Telco engineers here? I've been working on the iOS App code to convert the GSM signal strength indicator that comes back from the car into a 5 bar display and dBm value. There doesn't seem to be a standard for this, so I picked the iPhone 4.0.1 levels, as the reportedly the same as AT&T now use and at least I can compare with my iPhone. Code looks like this: // car_gsmlevel comes back from the car as the output of AT+CSQ // It is reportedly in the range 0..31, 99. int car_gsmlevel = [ovmsAppDelegate myRef].car_gsmlevel; // Calculate dBm from AT+CSQ signal level int car_gsmdbm = 0; if (car_gsmlevel <= 31) car_gsmdbm = -113 + (car_gsmlevel*2); // Tell the user about the dBm m_gsm.text = [NSString stringWithFormat:@"%d dBm",car_gsmdbm]; // Calculate the signal bars 0..5 int car_signalbars = 0; if ((car_gsmdbm < -121)||(car_gsmdbm >= 0)) car_signalbars = 0; else if (car_gsmdbm < -107) car_signalbars = 1; else if (car_gsmdbm < -98) car_signalbars = 2; else if (car_gsmdbm < -87) car_signalbars = 3; else if (car_gsmdbm < -76) car_signalbars = 4; else car_signalbars = 5; Does that look ok, or can anyone with experience of this suggest anything better? I've got a testflightapp build ready with this, and should be able to release tomorrow morning (my time). Just waiting for some device ids / testflightapp recruits to come in from interested developers who have eMailed me offering to help. Regards, Mark. P.S. The last 20120318 testflightapp build looks good. Crashes for the past 24 hours have gone to zero and things seem more stable.

2 2

Fwd: Open Vehicle 1.2.1 (20120317) is now available
by Mark Webb-Johnson 18 Mar '12

18 Mar '12

For you guys with iOS devices (iPhone, iPads, etc) I would appreciate help testing the latest iOS release that is up on testflight. If you've previously registered with TestFlight for OVMS, you just have to open the eMail on your iOS device and follow the install link. This build adds testflght metrics, to better allow us to track down and fix bugs (in particular crashes). It also fixes two crashes we identified in the last testflight release. If you didn't get the testflight invitation, that means you haven't previously registered, and can ignore this. Thanks, Mark. Begin forwarded message: > Subject: Open Vehicle 1.2.1 (20120317) is now available > Date: 17 March, 2012 7:30:44 PM GMT+08:00 > > reply above this line to send feedback directly to the developer. > > Open Vehicle 1.2.1 (20120317) > Team: Open Vehicles > What's New: > Bug fixes: Addressed two crashes found during test flight. > > Released: March 17, 2012 > Expires In: 8 months, 2 weeks > Size: 8.3 MB > Powered by TestFlight >

2 5

Re: [Ovmsdev] Digital Speedometer
by Mark Webb-Johnson 15 Mar '12

15 Mar '12

Mark, > How do you turn it on ? First, you need to ensure you are running an EXPERIMENTAL build (one built with the experimental config, not production). That will make sure the appropriate code is included. Then, after plugging the module into the car, use the Apps to set feature #0 to value 5, or SMS "FEATURE 0 5" to enable it. That will set aggressiveness factor #5. This video shows what to expect: http://www.youtube.com/watch?v=C0gKzCigXhs Our description of this (in the code) covers most of the bases: // The OVMS_SPEEDO_EXPERIMENT switch is a highly experimental feature to // change the dashboard Amps display in the Tesla Roadster to show speed. // Please take extreme care with this and consider it extremely experimental - // use at your own risk. The feature can transmit a lot of messages on the bus // and is spoofing the car message. We can't see any affect (and we've even put // an analyser on at the same time to see if any errors come up - they don't), // but it is very intrusive to the car. One concern we have is if the car is // using that message for anything else (but we can't see how it would as it // also contains data for the battery level display, estimated miles, etc - // it seems very very specific to that dashboard display). // We really don't want anyone breaking their cars with this. //#define OVMS_SPEEDO_EXPERIMENT Regards, Mark. On 14 Mar, 2012, at 5:50 PM, Mark Ramakers wrote: > How do you turn it on ? Under the features list in the App this option is > listed in 1st position ? If I turn this option on does it show the digital > speedo then in the App ? > > On 14-03-12 10:10, "Mark Webb-Johnson" <mark(a)webb-johnson.net> wrote: > >> >> A while ago, I had to turn off the digital speedometer in my car as I had >> some issues that I wanted to be sure it wasn't causing. It turned out to >> be completely unrelated and caused by a faulty PEM. Since replacement of >> the PEM, things have been perfect. >> >> I've now been running the digital speedo on (setting 5) for the past 3 >> weeks and it had been flawless. >> >> Is anyone else running this feature? If so, have you seen any issues and >> what is your opinion? Anyone else brave enough |-) >> >> Regards, Mark >> > > Mark Ramakers > CFO > > > Talpa Holding N.V. > Zevenend 45 - 1251 RL Laren > P.O. Box 154 - 1250 AD Laren > The Netherlands > T +31 35 53 33 553 > E MRamakers(a)talpa.tv > W http://www.talpa.tv > > Chamber of commerce registration number 32083875 > > Talpa Holding is part of the Talpa Group > > -------------------------------------------------------------------------- > The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in relation to the contents of this information is strictly prohibited and may be unlawful. Neither the sender nor the represented institution are liable for the correct and complete transmission of the contents of an e-mail, or for its timely receipt. > -------------------------------------------------------------------------- > > _______________________________________________ > > >> OvmsDev mailing list >> OvmsDev(a)lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >

2 1

Re: [Ovmsdev] Java and questions
by Mark Webb-Johnson 14 Mar '12

14 Mar '12

> I guess from my point of view its better to work on the basis that there can be only one client? It is possible for there to be more than 1 app connected, controlling the car, but not so likely. > Is it true to say that (network issues aside) not all 'C' messages will receive a 'c' response? I think that every 'C' message will receive a 'c' response. Even if the message is not understood, it will come back with a failure response. > Also, how is the car's connection handled, is it always connected to the server if it can be or only when a client connects? The car tries to maintain a connection to the server always. There is no way for the app or server to message or call the car without that connection established. Regards, Mark. On 14 Mar, 2012, at 10:55 PM, Tim Putnam wrote: > Thanks, I think I had the wrong preconceptions here. I guess from my point of view its better to work on the basis that there can be only one client? > > Is it true to say that (network issues aside) not all 'C' messages will receive a 'c' response? > > Also, how is the car's connection handled, is it always connected to the server if it can be or only when a client connects? > > cheers, > Tim > > On 14 Mar 2012, at 14:17, Mark Webb-Johnson wrote: > >> >>> Ah I see so the server is just acting as a proxy and carries no state? >> >> Yes. We try to make the server do as little as possible. It is just a store-and-forward relay (for messages) and forward-only relay (for commands and responses). >> >>> When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error? >> >> Undefined. Most commands should be ok. Some will have an issue and the original command may get lost (overwritten by the subsequent command). >> >>> What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request? >> >> >> Might break backwards-compatibility. Not sure if we could do it while maintaining compatibility (without having to extend each command). >> >> We could do it on something like the client version. At the moment it is "C 99,p1,p2,p3,etc". We could make v1.3.0 or later handle "C 99-key,p1,p2,p3,etc" and respond with "c 99-key,r1,r2,r3,etc". The problem is that if you send that format to a v1.2.0 client it will fail. >> >> Regards, Mark. >> >> On 14 Mar, 2012, at 10:11 PM, Tim Putnam wrote: >> >>> Hi Mark, >>> >>> Ah I see so the server is just acting as a proxy and carries no state? >>> >>> When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error? >>> >>> What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request? >>> >>> best regards, >>> Tim >>> >>> On 14 Mar 2012, at 13:45, Mark Webb-Johnson wrote: >>> >>>> Tim, >>>> >>>> Sounds real useful. >>>> >>>>> Please may I also ask a question - what is the model for synchronicity of the messages? On the android app, if I hammer a button, I appear to be able to send more than one command before a response comes from the server. Is this correct? The protocol appears to not allow you to correlate the response from a command to the request (unless I've missed it), so doesn't appear to be asynchronous, although data messages come from the server asynchronously. Is the intended interaction with the server that there is only ever one active command in action? >>>> >>>> >>>> The command part of the protocol is pretty minimal at the moment. It was added one quite late, and does just the bare minimum of what is needed. >>>> >>>> The server doesn't care about the command massages. Any command from the apps it sends to the car (if connected). Any response from the car it sends to _all_ connected apps. The only exception to this is that it does respond to one command itself (the one for GPRS utilization data). >>>> >>>> The main limitation is the car module. That can only handle one command at a time, and while it is processing it you shouldn't send any more commands. Most commands will be processed within the same cycle, but some take a second or two. >>>> >>>> Regards, Mark. >>> >> >

2 2

Re: [Ovmsdev] Java and questions
by Mark Webb-Johnson 14 Mar '12

14 Mar '12

> Ah I see so the server is just acting as a proxy and carries no state? Yes. We try to make the server do as little as possible. It is just a store-and-forward relay (for messages) and forward-only relay (for commands and responses). > When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error? Undefined. Most commands should be ok. Some will have an issue and the original command may get lost (overwritten by the subsequent command). > What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request? Might break backwards-compatibility. Not sure if we could do it while maintaining compatibility (without having to extend each command). We could do it on something like the client version. At the moment it is "C 99,p1,p2,p3,etc". We could make v1.3.0 or later handle "C 99-key,p1,p2,p3,etc" and respond with "c 99-key,r1,r2,r3,etc". The problem is that if you send that format to a v1.2.0 client it will fail. Regards, Mark. On 14 Mar, 2012, at 10:11 PM, Tim Putnam wrote: > Hi Mark, > > Ah I see so the server is just acting as a proxy and carries no state? > > When you say the car module can handle one command at a time - what happens if another arrives during that time? Do they queue or is there an error? > > What are the chances of adding a field to 'C' commands that just gets passed back in 'c' responses, so that clients can at least attempt to correlate which response goes with which request? > > best regards, > Tim > > On 14 Mar 2012, at 13:45, Mark Webb-Johnson wrote: > >> Tim, >> >> Sounds real useful. >> >>> Please may I also ask a question - what is the model for synchronicity of the messages? On the android app, if I hammer a button, I appear to be able to send more than one command before a response comes from the server. Is this correct? The protocol appears to not allow you to correlate the response from a command to the request (unless I've missed it), so doesn't appear to be asynchronous, although data messages come from the server asynchronously. Is the intended interaction with the server that there is only ever one active command in action? >> >> >> The command part of the protocol is pretty minimal at the moment. It was added one quite late, and does just the bare minimum of what is needed. >> >> The server doesn't care about the command massages. Any command from the apps it sends to the car (if connected). Any response from the car it sends to _all_ connected apps. The only exception to this is that it does respond to one command itself (the one for GPRS utilization data). >> >> The main limitation is the car module. That can only handle one command at a time, and while it is processing it you shouldn't send any more commands. Most commands will be processed within the same cycle, but some take a second or two. >> >> Regards, Mark. >

1 0

Java and questions
by Tim Putnam 14 Mar '12

14 Mar '12

Hello all, I just got my OVMS module yesterday. Before I go any further, what a fantastic piece project. Brilliant achievement, well done to everyone involved and my eternal gratitude. I'm a software developer, and time permitting I would love to be able to contribute something to your efforts. I've been browsing the specs and android source on github. I have a tendency towards java, and something that stands out to me is that there is no abstracted data model or encapsulation of the protocol at a higher level in any language. I am going to write one for my own benefit, but perhaps it would be of use elsewhere? The benefits I see to having it include: - the basis of a higher level specification of the protocol (e.g. for a webservice etc) - give plug and play interaction with the server for any java developer, much reducing the cognitive distance. They could just include the library and already have server connectivity, updated data model, receive relevant events, and have a simple extensible command interface, leaving them to focus on the interface. - could be reused in the android app, or as the basis for a web service application, and also simple desktop swing app I'd quite like to have available on my laptop Please may I also ask a question - what is the model for synchronicity of the messages? On the android app, if I hammer a button, I appear to be able to send more than one command before a response comes from the server. Is this correct? The protocol appears to not allow you to correlate the response from a command to the request (unless I've missed it), so doesn't appear to be asynchronous, although data messages come from the server asynchronously. Is the intended interaction with the server that there is only ever one active command in action? Best regards, Tim Putnam

2 1