[Ovmsdev] Firmware enhancements -> 1.2.0-rc4

Mark Webb-Johnson mark at webb-johnson.net
Sun Feb 19 11:11:38 HKT 2012


Jack,

I see your car reporting in 1.2.0-rc4 firmware at 2012-02-19 07:21:01 HKT (UTC+0800).

After that, there was some charge activity, and here are the logs (all times HKT):

2012-02-19 07:21:01.555044 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:21:05.003760 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:21:16.597740 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:21:34.389765 +0800 info  main: #10 C 1237 rx msg S 88,M,1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:21:40.127664 +0800 info  main: #10 C 1237 rx msg S 88,M,1,0,heating,standard,171,127,12,9,10,0,11,15,0
2012-02-19 07:21:43.825613 +0800 info  main: #10 C 1237 rx msg S 88,M,1,0,heating,standard,171,127,12,9,10,0,11,15,0
2012-02-19 07:21:52.345258 +0800 info  main: #10 C 1237 rx msg S 88,M,249,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:22:03.928926 +0800 info  main: #10 C 1237 rx msg S 88,M,247,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:22:46.983992 +0800 info  main: #10 C 1237 rx msg S 88,M,246,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:23:48.816771 +0800 info  main: #10 C 1237 rx msg S 88,M,251,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:24:34.814502 +0800 info  main: #10 C 1237 rx msg S 88,M,238,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:24:49.642471 +0800 info  main: #10 C 1237 rx msg S 88,M,238,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:24:56.266422 +0800 info  main: #10 C 1237 rx msg S 88,M,237,8,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:26:52.406357 +0800 info  main: #10 C 1237 rx msg S 88,M,236,8,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:27:53.318505 +0800 info  main: #10 C 1237 rx msg S 88,M,238,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:28:53.988284 +0800 info  main: #10 C 1237 rx msg S 88,M,237,7,heating,standard,171,127,12,9,0,0,11,15,0
2012-02-19 07:29:14.768565 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:29:18.318707 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:29:57.357424 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:30:12.923553 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:31:15.062726 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:31:15.998730 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:33:50.012396 +0800 info  main: #10 C 1237 rx msg S 88,M,238,8,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:33:54.183832 +0800 info  main: #10 C 1237 rx msg S 88,M,237,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:34:03.773612 +0800 info  main: #10 C 1237 rx msg S 88,M,236,8,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:34:23.606065 +0800 info  main: #10 C 1237 rx msg S 88,M,236,8,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:35:06.145096 +0800 info  main: #10 C 1237 rx msg S 88,M,237,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:36:06.608010 +0800 info  main: #10 C 1237 rx msg S 88,M,238,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:37:06.672821 +0800 info  main: #10 C 1237 rx msg S 88,M,237,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:38:07.511256 +0800 info  main: #10 C 1237 rx msg S 88,M,236,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:39:07.555680 +0800 info  main: #10 C 1237 rx msg S 88,M,238,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:40:18.297144 +0800 info  main: #10 C 1237 rx msg S 88,M,237,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:41:08.700062 +0800 info  main: #10 C 1237 rx msg S 88,M,237,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:42:08.902266 +0800 info  main: #10 C 1237 rx msg S 88,M,237,8,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:43:09.489557 +0800 info  main: #10 C 1237 rx msg S 88,M,238,7,heating,standard,171,127,12,9,5,0,11,15,0
2012-02-19 07:45:34.034593 +0800 info  main: #10 C 1237 rx msg S 88,M,236,8,heating,standard,171,127,12,9,12,0,11,15,0
2012-02-19 07:45:42.852387 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:45:46.826880 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:46:13.154031 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0
2012-02-19 07:51:12.568576 +0800 info  main: #10 C 1237 rx msg S 88,M,-1,0,prepare,standard,171,127,12,9,100,0,7,13,0

It looks like the charge mode is going 13->15 (prepare->heating), then 15->13 (heating->prepare). That seemed to happen twice (07:29:14 and 07:45:42). Both times the charge sub-state went from 11->7 (heating->connect-power-cable).

Assuming you slide-to-stop on both cases, that would make sense. But, can you do one more test - try the same thing (heating charge) then use the VDS to stop the charge and let me know the time so I can check the logs. Hopefully we will see sub-state go 11->3 (heating->by-request) in that case. If so, it is quite easy to add another test in the 0x95 handler to look for charge state 11->7 with new sub-state != 3, to sms/push notify alert (just like we did with ->charge-stopped states not by-request).

Other than this heating issue, I tested the other cases in my car with 1.2.0-rc4 and it looks good. I get the alert for any power cable type events, but not from a by-request stop. The new logic for sending charging updates seems also to work well - it reflects the change in the App within a couple of seconds, and the animation for slide-to-charge and slide-to-stop works much better.

Has anybody seen any other issues with the rc3 or rc4 firmware? It is looking pretty good to me.

Regards, Mark.

On 19 Feb, 2012, at 10:38 AM, Mark Webb-Johnson wrote:

> Jack,
> 
> Yes, I guess that may be a special case. What does it say on the VDS when you do that? Is it 'stopped charging' or 'preparing'. I think the VDS display is just that charge mode.
> 
> Regards, Mark
> 
> On 19 Feb, 2012, at 10:35 AM, Jack West <jackduncanwest at gmail.com> wrote:
> 
>> I flashed the RC4 today and tested in my cold car for the heating state.  Pilot slide to off or power failure after heating started did not return a charge stop message or alert.  I think if the heating state fails due to power loss or slide pilot off, the new state is preparing.  I'll work on this a little later and retest.
>> 
>> Jack
>> 
>> On Feb 18, 2012, at 5:43 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> 
>>> 
>>> I've made the following changes:
>>> 
>>> Fix net_puts_rom, net_puts_ram handling of empty strings
>>> Refuse to start charge if charge port not open. Refuse to stop charge if car not charging.
>>> Tidy up car_charging and stopped charging alerts
>>> Treat HEATING state as car charging (force charging bit high).
>>> 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
>>> 
>>> and committed is as 1.2.0-rc4.
>>> 
>>> I haven't done the reporting of charge and trip stats to to the server. I think that is too much feature-creep at the moment, and better to work on getting a 100% stable firmware with the existing feature set out.
>>> 
>>> The logic for sms/push notification of charge stopped is now:
>>> 
>>> if ((car_chargestate<0x15)&&
>>>     (can_databuffer[1]>=0x15)&&
>>>     (can_databuffer[2]!=0x03))
>>>   { // We've moved from charging to stopped charging, not by-request
>>>   net_notify_status();
>>>   }
>>> 
>>> The logic is that if the existing (previous) car chargestate is <0x15 (ie; not stopped), and the new car chargestate we've just received is >=0x15 (ie; stopped) and the new car charge substate != 0x03 (by-request), then we SMS/PUSH alert. That should alert on all 'unplug' style and 'power loss' style events, but not the by-request (ie; VDS pressing the STOP button, or sending the Charge Stop from the App) ones. It will not SMS/PUSH on charge done.
>>> 
>>> Much simpler, and saves a whole 2 bytes of ram!
>>> 
>>> It is too late here to put this in my car, or do any bench testing. It does compile ;-) I'll try it in my car tomorrow morning (my time), but if anyone in Europe/USA wants to try it (your day time), that would be helpful (particularly if I wake up tomorrow morning to messages telling me it works perfectly).
>>> 
>>> N.B. Michael suspects there may be a problem with push notifications, that is contributing to inconsistencies with this. The tests he did today had the alerts arriving at the server, but the phone didn't get them. I'll do more testing on this tomorrow, but please bear it in mind.
>>> 
>>> Regards, Mark.
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Mark Webb-Johnson <mark at webb-johnson.net>
>>>> Subject: [Ovmsdev] Firmware enhancements -> 1.2.0-rc4
>>>> Date: 17 February, 2012 10:50:23 PM GMT+08:00
>>>> To: OVMS Developers <OvmsDev at lists.teslaclub.hk>
>>>> 
>>>> 
>>>> I'm planning to work on the car firmware this weekend, hopefully making a 1.2.0-rc4 with the following changes:
>>>> 
>>>> Fix net_puts_rom, net_puts_ram handling of empty strings.
>>>> Treat HEATING state as car charging (force charging bit high).
>>>> Refuse to start charge if charge port not open. Refuse to stop charge if car not charging.
>>>> 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 (this and [6] should improve the UI in the Apps so that when you start/stop a charge, etc, the UI gets updated cleaner).
>>>> Triple-check notifications for charge stopped vs done.
>>>> Try to report charge and trip stats to server (if time allows).
>>>> 
>>>> I'll also double-check the charge mode and limit commands from the prototype iPhone App, and fix anything I find wrong.
>>>> 
>>>> To help people's testing, given the Android problems, I'm committing my work-in-progress iPhone App to git now. You should be able to use it in the iPhone simulator (or build and run on your phone if you've paid your dues to Apple). Some notes:
>>>> 
>>>> When the car is plugged in, a graphical representation will appear on the Battery screen. Slide right to charge, left to stop.
>>>> Note: the UI on updates from the car is not perfect here, and will need the above rc4 firmware fix to be cleaner.
>>>> Note: the function works, it is just the UI updates that are counter-intuitive (stop charge - ok, stopped, no charging, no stopped!)
>>>> 
>>>> Tapping on the battery will bring up an screen to allow you to change charge mode and current limit.
>>>> Note: At the moment, only change one at a time - if you change both only the mode will be set correctly. Firmware support rc4 is required to get this working better.
>>>> Note; Set higher currents than is permitted by the plug has been UNTESTED. Hopefully the car will handle this gracefully, but please don't do this until I've had a chance to check the behavior. If you are brave/dumb enough to try this, please let me know the result.
>>>> 
>>>> 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.
>>>> 
>>>> Most of the stuff on Cars/i/Control no longer works (as it has been moved away).
>>>> 
>>>> 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.
>>>> 
>>>> Enjoy, Mark
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120219/761e33d0/attachment.htm>


More information about the OvmsDev mailing list