February 2012 - OvmsDev - Open Vehicles

Strange preparing, connect-pwr-cable state
by Mark Webb-Johnson 26 Feb '12

26 Feb '12

I'm seeing something strange, that I'd like to know if it is repeatable for others. I previously thought this was some sequence problem with the messages we were sending (specifically, sending a start charge command when the charge port is closed or cable not plugged in), but I can now repeat it with just a normal idle car. Steps to reproduce: Charge the car as normal, and wait for "Charge done". Remove the charge plug+cable and close the charge port door. SMS STAT the car and you should get "Standard - Charging done" as the status. All good. Now, with the car still off, open the charge port door, wait a few seconds, then close it. SMS STAT the car and now we seem to get "Standard - Charging, Preparing". A check on the can bus shows charge state 13, sub-state 7 (preparing-to-charge, connect-pwr-cable). The iPhone App will show the battery with copper-coloured tops, as it seems to be expecting the car to be charging. This doesn't seem to happen with a car in 'stopped charge' state. The VDS shows nothing unusual (which implies that Tesla treat it specially, based on the charge door status). Can some other people try this, and let me know what you get? If you can have an App connected at the time of your test (so the server gets the logs), then let me know your vehicle ID, the time you did the test and what the result was, that would be helpful. It is not hard to handle as a special case in the code (both firmware and apps, or hacked in the firmware to detect the issue and put the state back to something more meaningful), but just seems a bit strange, as the state does not accurately reflect the car status. Regards, Mark.

3 4

SPEEDO feature
by Mark Webb-Johnson 24 Feb '12

24 Feb '12

> What is the status of the digital speedo feature? A developer asked about this off-list, and I thought it might be relevant to the wider community, so here it is. The speedo feature is enabled by defining OVMS_SPEEDO_EXPERIMENT at build time (either in ovms.def, or via configuration parameter). It is currently enabled for the experimental configuration, and off for the other two. The feature must also be enabled, after the module is powered up in the car, by setting feature #0 to a value >0. The value 5 is recommended as a good starting point. This feature #0 is volatile, and will be set to 0 if the module is powered down or rebooted. The reason the feature is classified experimental is because while it seems to work, we are really not sure what affect it has on the car. Something unexpected might damage the car. Use it at your own risk. Our warning is "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." If you do use, please let us have feedback on the ovmsdev mailing list. We really need to know more about this and any impact on cars (good, bad or zero). Regards, Mark.

1 0

Public mailinglist archives
by Wido den Hollander 24 Feb '12

24 Feb '12

Hi, Are there any public archives of this mailinglist? I don't know which software you are using, but if it's mailman, you could use pipermail to generate a HTML archive. These archives could be crawled by search engines and make it easier when future users want to know something about it. If any help with this is needed, let me know! If set this up multiple times. Wido

3 5

1.2.0-rc7
by Mark Webb-Johnson 24 Feb '12

24 Feb '12

I've just committed 1.2.0-rc7, with a couple of changes. Here is the changelog for rc6 and rc7: 2012-02-24 1.2.0-rc7 Release Candidate #7 for end-user firmware SOC Alert when SOC<5% (SMS and PUSH notification, when car is off and SOC<5%, every 12 hours) Tighten up StartCharge command restriction to refuse if charge substate=0x07 (connect power cable) 2012-02-23 1.2.0-rc6 Release Candidate #6 for end-user firmware Tighten up restrictions on sms notification charging=done Remove sms notification on telephone call The changes to rc6 were to check again during sms notiications to ensure that the charge state is 'stopped' or 'preparing' (for stopping during heating) before alerting, and to not SMS alert on incoming telephone call. The small change to rc7 was to tighten up the StartCharge command to also check the charge substate and make sure it is not 0x07 (power cable unplugged) before issuing the start charge can command. The big change to rc7 was to a add a feature in response to all the news about bricking Tesla Roadsters. The OVMS module will not check battery SOC once every ten minutes. If it is below 5% (in the current mode) and the car is OFF, the OVMS module will alert (by both SMS and PUSH notification) once every approximately 12 hours until such time as the car either starts or SOC rises to 5%. It will give a grace period of 1 hour after the car is stopped, to allow the SOC to get to 5%, before checking (and alerting). This feature is in addition to the less 'nagging' minimum-SOC feature that Sonny contributed. It is enabled by default, but can be disabled at compile time in ovms.def. This is ok on the bench (where it is a lot easier to test SOC<5%), and will go in my car tomorrow. Assuming no problems, we should be done and 1.2.0 release can be cut this weekend. Regards, Mark.

1 0

1.2.0-rc5 Notification charging/done
by Mark Webb-Johnson 22 Feb '12

22 Feb '12

Guys, I just got these notifications this afternoon: 2012-02-22 16:25:30.157145 +0800 info main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96% 2012-02-22 16:25:48.572604 +0800 info main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96% 2012-02-22 16:26:02.984595 +0800 info main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96% 2012-02-22 16:26:12.055064 +0800 info main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96% 2012-02-22 16:26:48.951721 +0800 info main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96% Not good. The only way that is happening is if the charge state of the car is flipping between done and stopped. The problem is that the reported states around the time of the problem are: 2012-02-22 16:15:03.765201 +0800 info main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0 2012-02-22 16:25:02.540923 +0800 info main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0 2012-02-22 16:35:09.175980 +0800 info main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0 2012-02-22 16:45:30.941930 +0800 info main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0 And, as the notification said 'Charging done', it is clear that between the alert being requested and raised (a split second), the charge state flipped from stopped to done. The car has been sitting idle for a couple of days, without being driven, but has been plugged in continuously during this time. I'm guessing that sometimes we get spurious messages on the can bus, perhaps when the car wakes up once a day to check its charge state, and that is causing the problem. I looked through the logs for the past few days, for any similar alerts from other users, but can't find any. I did have one report of a user getting three or four sms messages in a row, a month or so ago, but suspected at the time the charging point was having problems and restarting the charging. I don't think this is easy to solve. Trying to catch with a can log is going to be next to impossible. One workaround I can think of is in net.c in the handling of net_msg_notify and net_sms_notify - add checks there that (((car_chargestate >= 0x15) || (car_chargestate == 0x0d))&&(car_chargesubstate != 0x03)) - in other words the conditions that we should be alerting on. This would have the affect of filtering out these spurious alerts. Thoughts? Mark.

2 2

Re: [Ovmsdev] RC5 trial with heating state
by Mark Webb-Johnson 21 Feb '12

21 Feb '12

Jack, [took the liberty of replying to this via ovmsdev, for wider dissemination] > When I first opened the OVMS app my phone had lost service and of course the app wasn't working. > After a few minutes I restarted the app and had data right away. No big deal, just a note. We have logic in the iOS App to cope with a complete loss of service. If the iPhone says 'no network', the App will give you a big ugly warning alert dialog. We need this to pass Apple's AppStore gatekeepers (it is one of the top 5 reasons an App gets rejected). I suspect that either (a) something nasty happens in the phone if you continually try to access the network with no network connection, or (b) this was one of Steve's pet peeves. If the phone has network, but the iOS App can't access the server, then things are handled badly. There is no retry attempt, and not a very clear indication. Exit and re-enter the app (or select another car) is the only way to get it back. This is something I would like to improve, and it should not be too hard. But, it is in the App and we can relatively easily release updates. > When in the heating state, the app has the plug icon (nice!) but no indication ( other than the icon) that the car is heating or acting like it's in the charging state (amps/volts whatever). This is OK, just noting it. I can add this to the iOS App. No biggy. > If I select the wake up car command and then try to cancel, it just kind of hangs for a bit, maybe a minute before being able to cancel. Selecting wake up works right away. Again, no big deal, just a note. Might be my connection, but it is repeatable. I guess some network issue. The car can only queue one command at a time, which is a bit limiting but we are tight on RAM. Interestingly, there is another 'quirk' of the Tesla. If you transmit on the CAN bus a "START CHARGE" command while the car is sleeping, it doesn't actually start the charge. A couple of hours later, press the door handle to wake up the car, and the charge will start ;-) Kind of freaked me out the first time I saw it. Our current approach is to handle start charge in the car module by first transmitting the START CHARGE can command, followed by the WAKEUP can command - this is the same approach used by the VDS. > Slide pilot switch off on cable during heating state: > SMS ALERT = "charging, preparing". Ideally we would get a "charge stopped" MSG > OVMS PUSH = "charging, preparing" > After a short time app shows "prepare - 1V@0A" on plug icon I think we made a mistake in the reverse-engineering labeling of the charge states as 'charge state' and 'charge sub-state'. The sub-state seems to be a much more useful and granular indication of what is going on with the car, and the charge state is only really useful to know what happened with the last charge. In your case, when you stop the charge during heating, you get 'preparing' state. Not useful. That said, the car's handling of these states is also a mess (witness the stuck in 'preparing-to-charge' state when a charge is requested and the car charge port is closed). At the moment, for this case, the Alert is raised and that should at least tell the user that something is wrong. I think we can emphasis the sub-state in the App (particularly when the car is unplugged). > Car lock/unlock worked perfectly. US car, right? Be afraid, very afraid. With what we now know, plugging a laptop with a canbus usb adaptor into the diag port, a blackhat could easily output "unlock 0000", "unlock 0001", in very quick succession until the code is guessed. Remotely via OVMS (if he knows the car id and password) is also possible, but much much slower (perhaps one guess every three or four seconds). Thankfully, the non-US cars have separate immobilisers and alarms, so are more secure. > You have really done an outstanding job. I'm excited to have this in our car. So is my wife, who is the one that uses the car the most and has seen the most failed charges (leaving her with a low battery when she needs a full one!). Nice work It has been a truly amazing project. Thanks to everyone's help, we've built something to bring the Tesla Roadster up to the level of, and in some cases surpassing, other more modern EVs. I actually prefer to look at the iPhone App screen rather than the VDS (particularly since Felix cleaned it up so nicely). The next step is to open this up to end-users. I really hope that the people that have been using this for the past few months will step forward and help the not-so-technically-capable roadster owners in their areas get it running. Regards, Mark. On 22 Feb, 2012, at 12:31 PM, Jack West wrote: > > Some notes on my experience using RC5 and the updated app today. I'd like to stress that I think things are looking very good. > > When I first opened the OVMS app my phone had lost service and of course the app wasn't working. My phone did find service a minute later but the app never did start reporting. Changing tabs didn't help. I didn't try to send any commands. After a few minutes I restarted the app and had data right away. No big deal, just a note. > > When in the heating state, the app has the plug icon (nice!) but no indication ( other than the icon) that the car is heating or acting like it's in the charging state (amps/volts whatever). This is OK, just noting it. > > If I select the wake up car command and then try to cancel, it just kind of hangs for a bit, maybe a minute before being able to cancel. Selecting wake up works right away. Again, no big deal, just a note. Might be my connection, but it is repeatable. > > From battery screen, plug icon slide to stop -> looks good! Stops heating mode perfectly. > > Icon slide to start restarts heating exactly as advertised. > > Slide pilot switch off on cable during heating state: > SMS ALERT = "charging, preparing". Ideally we would get a "charge stopped" MSG > OVMS PUSH = "charging, preparing" > After a short time app shows "prepare - 1V@0A" on plug icon > Slide physical pilot switch 'on' > "prepare - 1V@0A" disappears from Icon > Car goes back to heating > > Using the VDS stop by request during heating mode: > Plug icon shows "charge stopped" > No alerts or push > This part is perfect > > Car lock/unlock worked perfectly. > > You have really done an outstanding job. I'm excited to have this in our car. So is my wife, who is the one that uses the car the most and has seen the most failed charges (leaving her with a low battery when she needs a full one!). Nice work > > Jack

1 0

1.1.9 (build 20120221) iPhone App on Testflight
by Mark Webb-Johnson 21 Feb '12

21 Feb '12

The 1.1.9 (build 20120221) iPhone App has been released on Testflight. Change log for this 1.1.9 version includes: This is an update intended for iPhones and iPodTouches only. It is only partially implemented for iPad, and may not work correctly. The major change here is the new UI and support for commands to the car (requires write-enable on the car firmware). Please ensure you are running car firmware v1.2.0-rc4 or later. * When the car is plugged in, a graphical representation will appear on the Battery screen. Slide right to charge, left to stop. * Tapping on the battery will bring up an screen to allow you to change charge mode and current limit. * On the Car screen, tapping on the lock will allow you to lock/unlock the car. The PIN requested is the vehicle pin. Note: Non-US cars have immobilisers fitted. Even if you unlock the car with the App, the alarm will still be enabled and the car can't be driven until you unlock with the key fob. US cars don't have this issue (but are much easier to steal ;-) * On the Car screen, tapping on the valet will allow you to enable/disable valet mode. The PIN requested is the vehicle pin. Note: This is cool. Give the car to the valet, walk away and enable valet mode from your phone - no more having to enter the PIN while the guy looks over your shoulder. * On the Car screen, tapping on the engine compartment will prompt you if you want to wake up the car. Note; A sleeping car has no water pump (rear-right of the car) noise. An awake car has this noise of water rushing through pipes. * Various ancillary functions are on Cars/i/Control. This includes viewing/setting parameters and features, viewing a GPRS network utilisation chart, and resetting the OVMS module in the car. * Sorry, but the iPad version has not yet been done. I'm getting the iPhone stuff working first, then will copy it over. * It is a work-in-progress, and may be buggy. Live with it. Please note that the Cars/i/Control functions have now been implemented for viewing/setting parameters and features, viewing a GPRS network utilisation chart, and resetting the OVMS module in the car. The iPhone and iPodTouch part of this is now complete. We are now working on the iPad version. Regards, Mark.

1 0

1.2.0-rc5
by Mark Webb-Johnson 21 Feb '12

21 Feb '12

I have committed firmware 1.2.0-rc5. Changes (since 1.2.0-rc3) include: 2012-02-21 1.2.0-rc5 Release Candidate #5 for end-user firmware Heating->Preparing, not by-request, -> SMS/IP alert Command 40: Send SMS (params: phone number, SMS message) Command 41: Send MMI/USSD Codes (param: USSD_CODE) Command 49: Send raw AT command (param: raw AT command) Increase message buffers to 200 bytes Support multi-line incoming SMS 2012-02-18 1.2.0-rc4 Release Candidate #4 for end-user firmware Treat HEATING state as car charging (force charging bit high) Tidy up car_charging and stopped charging alerts Implement a command 16 to set charge mode and current in the same message Change logic for commands 10,11,12 and 15 to NOT send battery status message immediately Change can.c to detect changes in battery status and send that as an immediate status update Triple-check notifications for charge stopped vs done Support heating indication in push alerts This contains fixes for all known issues, including a proposed fix for detecting charge abort during battery pre-heating state. The biggest change is a re-working of the incoming SMS handler, to allow for multi-line SMS messages. In addition, three new commands have been added, to allow SMS and MMI/USSD messages to be sent (for things like checking pre-paid SIM balances). As before, I ask all developers to deploy this to your cars, so we can be certain there are no issues. You will want to concentrate testing on (a) SMS commands, (b) the SMS/IP notification facility (which should notify you, if so configured, whenever the charge is stopped on the wall side of the plug - ie; not by pressing STOP on the VDS or App), and (c) charger configuration commands to the car. We are in final release candidate status for this now. Regards, Mark.

1 0

Fwd: Open Vehicle 1.1.9 (1.1.9) is now available
by Mark Webb-Johnson 19 Feb '12

19 Feb '12

I just released the testflight for 1.1.9 (almost 1.2.0) iOS App. This is really intended for iPhone / iPodTouch users only (not iPad) and contains the UI enhancements I've been working with Felix on, as well as support for car commands. If you are going to use the car commands, you should use it against a real car running 1.2.0-rc4 or later firmware. It won't work against the demo car, at the moment. Enjoy, Mark Begin forwarded message: > Open Vehicle 1.1.9 (1.1.9) > Team: Open Vehicles > What's New: > This is an update intended for iPhones and iPodTouches only. It is only partially implemented for iPad, and may not work correctly. > > The major change here is the new UI and support for commands to the car (requires write-enable on the car firmware). Please ensure you are running car firmware v1.2.0-rc4 or later. > > * When the car is plugged in, a graphical representation will appear on the Battery screen. Slide right to charge, left to stop. > * Tapping on the battery will bring up an screen to allow you to change charge mode and current limit. > * On the Car screen, tapping on the lock will allow you to lock/unlock the car. The PIN requested is the vehicle pin. Note: Non-US cars have immobilisers fitted. Even if you unlock the car with the App, the alarm will still be enabled and the car can't be driven until you unlock with the key fob. US cars don't have this issue (but are much easier to steal ;-) > * On the Car screen, tapping on the valet will allow you to enable/disable valet mode. The PIN requested is the vehicle pin. Note: This is cool. Give the car to the valet, walk away and enable valet mode from your phone - no more having to enter the PIN while the guy looks over your shoulder. > * On the Car screen, tapping on the engine compartment will prompt you if you want to wake up the car. Note; A sleeping car has no water pump (rear-right of the car) noise. An awake car has this noise of water rushing through pipes. > * The stuff on Cars/i/Control no longer works, as it has yet to be implemented. > * Sorry, but the iPad version has not yet been done. I'm getting the iPhone stuff working first, then will copy it over. > * It is a work-in-progress, and may be buggy. Live with it. > > Released: February 19, 2012 > Expires In: 9 months, 1 week > Size: 7.9 MB >

1 0

Re: [Ovmsdev] little problem/feature needed/debug
by Sonny Chen 19 Feb '12

19 Feb '12

Mark and everyone, Here's a teaser of the refined home screen widget for Android. It looks cleaner with parking meter hidden (when the car is not parked). The update should be available in a few hours. Sonny

1 0