- OvmsDev - Open Vehicles

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

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

14 Mar '12

Piotr, I think there are 2 reasons you get the occasional amps display: When we use the modem, there is a delay loop, and we don't do the periodic speedo message transmission while in that loop. This is, at worst, once every minute or so. Occasionally, the car is going to win. At aggressive factor 5, I find it acceptable. The AMPS display is pretty rare. This can never be 100% perfect (unless we can find some way to suppress the car messages, which I doubt). Regards, Mark. P.S. Soapbox: this does show how easy it is to do. Tesla could do this _very_ easily in their firmware and that would be perfect. On 14 Mar, 2012, at 6:32 PM, 911carrera4(a)bluewin.ch wrote: > Hi Mark > > i've been usingthe speedo for 2 weeks. No problems. Only that > sometimes (for 1 second or so) it showed the amps insetead of the speed. > > Piotr > > ----Ursprüngliche > Nachricht---- > Von: mark(a)webb-johnson.net > Datum: 14.03.2012 10:10 > An: "ovmsdev(a)lists.teslaclub.hk"<ovmsdev@lists. > teslaclub.hk> > Betreff: [Ovmsdev] Digital Speedometer > > > 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 > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > >

1 0

Digital Speedometer
by Mark Webb-Johnson 14 Mar '12

14 Mar '12

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

1 0

Car firmware version
by Mark Webb-Johnson 13 Mar '12

13 Mar '12

Guys, We've received a few questions recently about whether the car firmware needs to be updated or not, and basically, what version of firmware am I running? It is fairly easy to add a small feature to the server that when the car sends it the firmware version, and the version is < 1.2.0, it sends a PUSH notification to the Apps of that car saying (a) the version of firmware in the car, (b) a reminder that the firmware needs to be updated to v1.2.0 or later. We could limit this to once every week or so (or until the server is restarted). This seems like a good idea, as everyone should really be updating to v1.2.0 to get the full functionality. We could also do something similar if the user connects to the wrong server (ie; their account says TMC server, but they connect to WWW openvehicles.com server). Any objections? Regards, Mark.

2 1

v1.2
by Mark Webb-Johnson 12 Mar '12

12 Mar '12

I've just committed some revisions to the user guide for OVMS in the Tesla Roadster and updated it to v1.2. This completes the v1.2 work, and I have formally branched v1.2 on github so we have a stable reference point in future. You can download the new user guide direct from github at: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/O… The guide contains instructions for installing the module in the car, as well as initial setup for access. It has been updated to match the features in the v1.2 car firmware, and latest GSM/GPRS hardware switch on the car module. Thanks to everyone involved in development, testing and just using the v1.2 firmware and OVMS. This, quite simply, would not have been possible without you all. Now, onwards to v1.3 and beyond ;-) Let's get social. Regards, Mark.

1 0