[Ovmsdev] Firmware enhancements -> 1.2.0-rc4

Mark Webb-Johnson mark at webb-johnson.net
Sun Feb 19 12:53:35 HKT 2012


Jack,

From Michael's 100% heat then charge log, I see:

            0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
            0.0 100 88 07 00 00 FF FF 1A       ->VDS Charger settings (limit 26A) (current 7A) (duration 0mins)
            0.0 100 89 00 E9 00 00 1A          ->VDS Charger interface (speed 0mph) (vline 233V) (Iavailable 26A)
            0.0 100 95 0F 0B 63 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)

            0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
            0.0 100 88 06 00 00 FF FF 1A       ->VDS Charger settings (limit 26A) (current 6A) (duration 0mins)
            0.0 100 89 00 BD 00 00 1A          ->VDS Charger interface (speed 0mph) (vline 189V) (Iavailable 26A)
            0.0 100 95 0D 01 64 A4 01 16 00    ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard)

            0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
            0.0 100 88 00 00 00 FF FF 1A       ->VDS Charger settings (limit 26A) (current 0A) (duration 0mins)
            0.0 100 89 00 03 00 00 00          ->VDS Charger interface (speed 0mph) (vline 3V) (Iavailable 0A)
            0.0 100 95 01 05 64 A4 01 16 00    ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard)

            0.0 100 96 3C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 3C)
            0.0 100 88 00 00 00 FF FF 1A       ->VDS Charger settings (limit 26A) (current 0A) (duration 0mins)
            0.0 100 89 00 EA 00 00 1A          ->VDS Charger interface (speed 0mph) (vline 234V) (Iavailable 26A)
            0.0 100 95 01 05 64 A4 01 16 00    ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard)

That looks like (heating state, heating sub-state, 99%) -> (preparing to charge, starting charge) -> (charging, charging).

Assuming the logic I previously outlined, it should be fine (even though it goes through preparing to charge state).

If you want to directly test the alert, here is the code to add:

case 0x95: // Charging mode
  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();
    }
  if ((car_chargestate == 0x0f)&&
      (can_databuffer[1] == 0x0d)&&
      (can_databuffer[2]!=0x03))
    { // We've moved from heating to preparing, not by-request
    net_notify_status();
    }

(you add the lines in red). The logic is that if the previous charge state was 0x0f (heating) and the new charge state is 0x0d (preparing to charge) and the charge sub-state != 0x03 (by-request), then SMS/PUSH notify alert.

There is one other edge case - what happens if you stop the charge while it is preparing? This could happen either at the start of a normal charge, or between heating and charging for a cold charge. I guess I can test this to see what state we get in the normal case. So long as the new state is stopped-charging (0x15), the first test case should catch it and alert.

Regards, Mark.

P.S. We still need to confirm we get a by-request sub-state for heating->preparing transitions resulting from pressing the VDS STOP button.

P.P.S. For charge states, we now have:

0x01 charging
0x02 top off (although I'm not seeing this)
0x04 done
0x0d preparing to charge
0x0f heating
0x15 stopped charging (vds stop)
0x17 stopped charging (power disconnection)
and, in general, 0x15-0x19 stopped charging

P.P.S. For sub-states, we now have:

0x01 starting charge (power cable has been connected) 
0x02 scheduled start
0x03 by request
0x05 charging
0x07 connect power cable
0x09 done
0x0b heating

On 19 Feb, 2012, at 11:45 AM, Jack West wrote:

> Sliding pilot off during 'heating':
> VDS reads "Preparing to charge, connect power cable"
> 
> Unfortunately it seems that when heating completes normally the next charge state is "preparing"
> just before real charging takes place.  I tried using the pilot bit as a test but ran into trouble.
> 
> Like this 
> case 0x95
> 
>   if((car_chargestate == 0x0f) &&. // old state was heating
>     (can_databuffer[1] == 0x0d) && // new state is preparing
>     (pilot == false))  //. Set pilot flag in case 0x96, test it here
>   // heating failed due to power failure or slide pilot switch off
>   car_ chargestate = 0x17;  //set chargestate to stopped state
>   else
>      car_chargestate = can_databuffer[1];
> 
> 
> Canbus notes reads pilot bit is always 1 on your 2.5, is this accurate?
> 
> Jack
> 
> 
> 
> 
> 
> On Feb 18, 2012, at 5:38 PM, Mark Webb-Johnson <mark at webb-johnson.net> 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
>> _______________________________________________
>> 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/32402fdd/attachment.htm>


More information about the OvmsDev mailing list