[Ovmsdev] VDS calculated state vs. data available via CAN

Tue Apr 24 13:48:31 HKT 2012

Tom,

> - plug the car in, but don't slide the locking switch forward
> - wait until the coolant pump turns off
> - slide the locking switch forward

Ok. That explains the weird behavior I was having before. I would change the charge mode/timing remotely via can bus action, and nothing would happen. The next morning I would go down to the car, press the door handle, and the car would start charging!

I see on the can bus that whenever you press anything on the VDS, after a sleep, it sends a id #102 B1=0x0a to wake up something in the VMS. We changed OVMS to match, and everything seems ok now. In other words, when you change the charge mode/timing/current-limit in OVMS, it wakes up the car to avoid this ;-)

> There's another bug if you plug in then change the timer setting. The VDS
> will show the new time, but will charge on the old time.

Been there, done that ;-)

Regards, Mark.

On 24 Apr, 2012, at 1:35 PM, Tom Saxton wrote:

>> Are you 100% certain charge time is maintained across VMS power failure?
> 
> Yes. Your question about that is why I did the experiment. As soon as I have
> a way to capture CAN messages, I'll do it again and let you know what I see
> when the VDS boots up.
> 
> Also, I was reading the notes on the CAN messages. The VDS doesn't control
> charging. In fact there's an annoying bug with that:
> 
> - plug the car in, but don't slide the locking switch forward
> - wait until the coolant pump turns off
> - slide the locking switch forward
> 
> Even though the VDS is on and the car seems totally alert, it doesn't
> recognize the pilot signal and will not charge. I've heard several reports
> of this making surprised Roadster owners very unhappy to find their car not
> charged. To work around the bug, do anything that starts the pump going
> again.
> 
> There's another bug if you plug in then change the timer setting. The VDS
> will show the new time, but will charge on the old time. That one burned me:
> I set the charge time earlier to get a full charge for a long drive that
> needed to start early in the morning. It charged on the old schedule, wasn't
> done when I needed it, and made for a tense day of driving. To work around
> the bug: unplug: close then open the charge door, plug back in.
> 
> I reported both bugs to Tesla over a year ago. No action.
> 
>    Tom
> 
> on 4/23/12 5:34 PM, Mark Webb-Johnson wrote:
> 
>> Tom,
>> 
>> Answers, inline, below.
>> 
>> Regards, Mark.
>> 
>> On 24 Apr, 2012, at 1:42 AM, Tom Saxton wrote:
>> 
>>> When the VDS on a v1.5 Roadster gets reset, it loses the following
>>> information:
>>> 
>>>   Charge History
>>>   Energy History
>>>   Trip Meter Drive Time
>>>   Wh/mile history graph
>>> 
>>> I take this to mean that these things are calculated from info on the CAN
>>> bus and stored in the VDS.
>> 
>> Yes, that makes sense.
>> 
>>> In v1.5 Roadsters, the energy history got screwed up by a firmware update
>>> more than a year ago. The regen energy numbers shown are often ludicrous. In
>>> extreme examples, the day and month regen numbers can be larger than the net
>>> energy numbers. No doubt related to that, I see the regen number going up
>>> when the car is parked. (That's a nice trick!) I take this to mean that
>>> something on the CAN bus changed but the VDS firmware hasn't been updated.
>>> 
>>> Things that are preserved over a VDS reset:
>>> 
>>> Charge time, mode and current limit. (Current limit is stored by location,
>>> presumably by the VMS.)
>>> Trip distance and net energy used.
>>> 
>>> So, presumably all of the values in this group can be queried from the CAN
>>> bus.
>> 
>> We have discovered charge mode and current limit. It is periodically sent from
>> the VMS. Charge kW is also on the bus.
>> 
>> I recently worked on charge time and mechanism (on-demand/delayed) and found
>> the command/response codes for these, but haven't found any periodic
>> transmission for this on the bus, yet. Are you 100% certain charge time is
>> maintained across VMS power failure?
>> 
>> We (Michael, or me?) have also discovered trip distance and odometer. I
>> haven't found net energy used, yet, (not really gone looking) but it is
>> presumably there somewhere. Trip is on id#100, B1=0x9c, and is in 1/10th of a
>> mile - that is fully decoded. There is also an odometer message with this in
>> id#402 - that how some not-yet-decoded bytes at the start, but they don't
>> appear to be incremental are are more likely bit states for something. If
>> energy use is there, it is on one of the undiscovered messages.
>> 
>> Instantaneous amps is available on the dashboard message id#400 B1=0x02 (we
>> use it to spoof the digital speedo).
>> 
>>> Trip efficiency also persists. It may be calculated by the VDS or available
>>> on the CAN bus.
>>> 
>>> My most recent trip meter showed 46.7 miles, 11.32 kWh, and 243 Wh/mile. If
>>> you do the math, 11.32 kWh / 46.7 miles = 242.398 Wh/mi, which should round
>>> to 242. Since the trip distance has been found on the bus at 0.1 mi
>>> resolution, it seems like that's the best data the VDS has. If there are
>>> higher resolution numbers somewhere (VMS?), then maybe the real values are
>>> 46.65 miles and 11.324 kWh -> 242.74 Wh/mi which rounds up to 243. So,
>>> perhaps the efficiency number is calculated elsewhere and broadcast on the
>>> CAN bus. Alternatively, the VDS either may have a higher resolution energy
>>> number than what it's showing or perhaps it just does math badly.
>> 
>> I wouldn't rule out a bad rounding in the VDS. Rounding is done in so many
>> places in the Tesla systems, and often different. For example - reset the trip
>> and look at it on the car speedo vs VDS. We found similar things with the
>> miles/kilometer conversion.
>> 
>>>   Tom
>>> 
>>> 
>>> _______________________________________________
>>> 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