[Ovmsdev] Firmware enhancements -> 1.2.0-rc4

Jack West jackduncanwest at gmail.com
Sun Feb 19 11:45:34 HKT 2012 

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/20120218/47831a44/attachment.htm>

More information about the OvmsDev mailing list