Linearity of SOC

TickTock said:

Since the voltage and current is very stable, I think this just means that the car is using something else to generate the gid count that has a fair amount of error.

Click to expand...

If that was the case, then the gids would be useless as a means of indicating SOC, but apparently they work reasonably well. Could it be that the gid messages do not get sent out in sync with the amp/volts messages? If the gids are not sent out at the corresponding voltage/amp messages then any random interval in the system can throw your plot off... Do you get a time stamp on the gid? And does it tell you when the message was sent or when it arrived at the bus?

klapauzius said:

TickTock said:

Since the voltage and current is very stable, I think this just means that the car is using something else to generate the gid count that has a fair amount of error.

Click to expand...

If that was the case, then the gids would be useless as a means of indicating SOC, but apparently they work reasonably well. Could it be that the gid messages do not get sent out in sync with the amp/volts messages? If the gids are not sent out at the corresponding voltage/amp messages then any random interval in the system can throw your plot off... Do you get a time stamp on the gid? And does it tell you when the message was sent or when it arrived at the bus?

Click to expand...

I think this is an over-statement. Most of the points fall within +/- 1 LSB which is a fairly common spec for data converters. Even with the outliers, it is still "good enough" for the purpose. It is possible the gid messages are getting held up somewhere (timestamps are on the message, not the data sample time) but that would be a *very* long pipe in computer terms (over 1.5 minutes long and ~15messages deep).

1. Graphing the Pack Current during charging, I get a lot of "noise".

2. Does each LEAF CAN message contain a time stamp in its header?

If so, I did not know about it, and please educate me.

3. When CAN-Do receives a message it ADDS a Sec+Msec time-stamp to each message, but it is possible that some messages get delayed in the COMM buffers. When logging only one channel (without the Dashboard enabled), the delays should be minimal, probably around one milli-second. However, having an RS232 UART hardware buffer ON could delay getting the last character(s) of one message until the following message starts. I will have to examine the code, and my Windows Hardware settings (Device Manager).

4. For multi-channel Logging, I will have to re-examine my message-receiving strategy, to make sure I gave fair treatment to all channels.

garygid said:

1. Graphing the Pack Current during charging, I get a lot of "noise".

Click to expand...

I am seeing 9.5,10, and 10.5A for most of the charge (only 5% noise). Saw a few as low as 8.5A towards the end of the charge cycle...

garygid said:

2. Does each LEAF CAN message contain a time stamp in its header?

Click to expand...

Not unless you took it out before saving to the log. ;-) My assumption is the timestamp in the log is the time the message was recieved.

garygid said:

If so, I did not know about it, and please educate me.

3. When CAN-Do receives a message it ADDS a Sec+Msec time-stamp to each message, but it is possible that some messages get delayed in the COMM buffers. When logging only one channel (without the Dashboard enabled), the delays should be minimal, probably around one milli-second. However, having an RS232 UART hardware buffer ON could delay getting the last character(s) of one message until the following message starts. I will have to examine the code, and my Windows Hardware settings (Device Manager).

4. For multi-channel Logging, I will have to re-examine my message-receiving strategy, to make sure I gave fair treatment to all channels.

Click to expand...

If the volts and amps can be read at fairly precise timing, you could log the time for those and
initially record a charge/discharge curve along with the gids...since this would be over a long period of time (>> than the timing error on the gids), you can take the measured gids, fit a curve to that and then derive the Wh/gid from the fit and your accurately measured and integrated amp/voltage curve. That would hopefully be less noisy.

As I recall:
1. The Pack V and A values displayed by the SOC-Meter are averaged over 10 messages.
2. The values in the messages seem to be at 1/2 volt and 1/2 amp resolution.