Active EV-CAN sampling: cell voltages, pack temperatures...

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

GregH

Well-known member
Joined
Jul 1, 2011
Messages
860
Location
Irvine, CA
So with a little help from TickTock and a friend at Nissan, we've been able to replicate some of the specific CAN messages used by the technician's scan-tool to read data from the Leaf battery management system.
First of course I should say that SENDING CAN messages to your Leaf (as compared to passively listening) could cause problems although most of the harmful writable data is usually protected with additional check-sums.
Anyway.. Proceed at your own risk..

What we're doing here is sending specific request messages asking for groups of data from the HV battery subsystem.
As best we can tell all of the requests from the scan-tool regarding the HV battery are sent on the 0x79b CAN ID with responses on 0x7bb. All packets are 8 bytes although sometimes not all 8 are utilized.
We've found 6 different groups of data...
Group 1 has 6 lines of data (precision SOC, Ah Capacity and perhaps battery State of Health %)
Group 2 has 29 lines of data and contains all 96 of the cell voltages.
Group 3 has 5 lines and contains the Vmin and Vmax as well as a few other things we haven't figured out yet.
Group 4 has 3 lines of data and contains the 4 pack temperatures.
Group 5 has 11 lines and again, not sure what it is yet..
Group 6 (discovered by Lincomatic) has 4 lines of data and contains the status of the resistive cell balancing shunts.

In order to read a group of data, first send the initial request command on ID 0x79b:
0x02 0x21 group 0xff 0xff 0xff 0xff 0xff (those last 5 bytes can be 0xff or 0x00, doesn't seem to matter, and yeah I tried group 0 and 6.. didn't see anything)

For example to request pack temperatures you'd start with
0x79b: 0x02 0x21 0x04 0 0 0 0 0

Which returns something like:
0x7bb: 0x10 0x10 0x61 0x04 0x01 0xfb 0x15 0x01

The first byte is an index (incremented on subsequent lines), the 2nd byte is a sort of group size, the 3rd byte is 0x61 (responding to the 0x21) and the 4th byte is the group number. The actual data starts on the 5th byte.
In this example the first temperature is a 3 byte value (16bit raw A/D and 8bit temp) 0x01fb 0x15 meaning 21 degrees C with the raw 10 bit A/D NTC thermistor value 0x1fb or 507 decimal. The start of the 2nd temperature is the last byte of the message.

To ask for additional lines of data, they must be requested within about a second of the initial request. In my software I ask for the 2nd line immediately after receiving the first and then ask for subsequent lines every 16ms or so.
The request additional lines command is
0x79b: 0x30 0x01 0x00 0xff 0xff 0xff 0xff 0xff

All subsequent lines will have an index in the first byte with 2 as the MS nibble and the lower nibble (4 bits) as the index.. The remaining 7 bytes are all data.
Such as:
0x7bb: 0x21 0xf8 0x15 0x02 0x06 0x13 0x02 0x0d
(ie the other 2/3rds of temp2, all of temp3 and the first 2/3rds of temp4)

In order to receive the last line, another 0x30 0x01 0x00 request is sent and for this example the response looks like:
0x7bb: 0x22 0x13 0x13 0x00 0xff 0xff 0xff 0xff
(giving the last byte of temp4.. not sure what if anything the extra 0x13 and 0x00 mean... maybe some check-sum)

On a side note, I'm trying to recreate the thermistor circuit so that we might be able to get more precise temperatures calculated from the raw A/D value as compared to the car's 1 degree C reading. As temps go up, the A/D value goes down and it's nonlinear.. It's kinda noisy though so better than 1/4 degree C isn't likely.

In larger groups (cell voltages in group 2) the index byte continues 0x23, 0x24, 0x25 etc wrapping from 0x2f back to 0x20.

The cell voltages in Group 2 start with the 5th byte in the first line (just like the temps) with the first two cell voltages then subsequent lines contain another 3 and a half cell voltages on each.

example:
0x7bb: 10 C6 61 02 0F D8 0F D4
0x7bb: 21 0F D0 0F D9 0F D0 0F
0x7bb: 22 CC 0F D3 0F D0 0F D0
etc..

If you ask for more than the above mentioned lines for each group (including the first line from the initial request), you won't get a response.

<edit> If the car is charging and is OFF (and has been OFF for more than one minute) then initiating a group data request may cause a small clicking noise near the steering column for every new group data request if spaced more than 1 second apart. Most likely this is some controller that is normally asleep during charge that is woken up upon CAN data queries then goes back to sleep after a second or so. Just to be on the safe side, probably not a good idea to sample in such a way as to possibly wear our the relay.. ie between 1 second and probably a few minutes. I would guess it's not a big deal if you were only sampling every few minutes. This is only an issue when the car is off but charging.
I've tried sampling group 3 (which has the Vmin and Vmax) at 4Hz (intermediate lines at 16ms) with no trouble. I tried intermediate line requests at 8ms and that seemed to work but there were a few glitches. Even at 16ms I'm not 100% certain I'm getting ALL the data ALL the time, but mostly it's working great. These 0x7xx messages are the lowest priority on the bus but it's still probably not a good idea to overload it..

We're still trying to decode additional data in group 3 as well as groups 1 and 5, so it'll be fun to see what kind of data the other folks out there are getting on their systems...

<edit>In Group 1, the "Real SOC" (ie the EV-CAN 0x55b message) is represented in much higher resolution..
It's the last 3 bytes on the 5th line.. for example while the EV-CAN 0x55b message reports 79.8%, Group 1 line 5 reports 79.8202 (0x0c2dfa)
The Ah capacity of the battery is on bytes 3, 4 and 5 of the 6th (last) line. For example 0x0A4754 is 67.3620Ah
The battery health (as a percentage) is on bytes 2 and 3 of the 5th (2nd to last) line. For example 0x25a4 is 96.36%

<edit>As mentioned above (and later in this thread), Group 4 has the 4 pack temps as a 16bit raw A/D value and an 8 bit value as the car's reading in degrees C.. Pasted here is the data I've collected thusfar relating raw thermistor A/D values to the car's reported temps. If anyone has data to extend this above 31 or below

-1 degrees C finishes at 730 (Kudos to Sean W. for catching this one!)
-0 degrees C starts at 729
+0 degrees C starts at 720 (LeafDD with original SW is accurate down to here!)
1 degrees C starts at 710
2 degrees C starts at 700
3 degrees C starts at 690
4 degrees C starts at 680
5 degrees C starts at 671 (?!?!) strange, double confirmed. P.S. Thanks Steve S for these single digit confirmations.
6 degrees C starts at 660
7 degrees C starts at 650
8 degrees C starts at 640
9 degrees C starts at 630
10 degrees starts at 620
11 degrees starts at 609
12 degrees starts at 599
13 degrees starts at 589
14 degrees starts at 579
15 degrees starts at 569
16 degrees starts at 558
17 degrees starts at 548
18 degrees starts at 537
19 degrees starts at 527
20 degrees starts at 517
21 degrees starts at 507
22 degrees starts at 497
23 degrees starts at 487
24 degrees starts at 477
25 degrees starts at 467
26 degrees starts at 457
27 degrees starts at 447
28 degrees starts at 438
29 degrees starts at 428
30 degrees starts at 419
31 degrees starts at 410
32 degrees starts at 401
33 degrees starts at 392
34 degrees starts at 383
35 degrees starts at 374
36 degrees starts at 365
37 degrees starts at 357
38 degrees starts at 348
39 degrees starts at 340
40 "" 332 ?
41 "" 324 ?
42 degrees starts at 316
43 degrees starts at 309
44 "" 302 ?
45 "" 295 ?

Group 6 has the cell balancing info as 24 bytes, the lower 4 bits on each byte reflecting the shunts on the resistive loads used to balance the pack.
The shunt for cell #1 is in the first byte bit 3
The shunt for cell #2 is in the first byte bit 2
The shunt for cell #3 is in the first byte bit 1
The shunt for cell #4 is in the first byte bit 0
The shunt for cell #5 is in the 2nd byte bit 3
The shunt for cell #6 is in the 2nd byte bit 2
etc


I'll continue to update this first post as we find more info.
 
Great work, and thanks a bunch for sharing.

What interface are you using to query the EV bus?

Have you experimented with making any Requests on
the CAR-CAN bus or the AV-CAN bus?

Now, I have a good reason to perfect some code for the
AVR-CAN (and Mbed) to send Requests, and actively
receive messages (the Replies).

To get it done, the CAN interface chip needs to be in
Transmit-Enabled mode both for sending the requests,
AND for actively Receiving messages. However, if one
wants to continue passively listening to other messages
(not being the active "recipient") one needs to be very careful
to only write the ACK bit to the "response" messages.

Again, thanks for sharing.

My first goal will be to add the 4 Battery Pack temperatures
to the GID-Meter, probably only done once a minute, or so.
 
GregH said:
So with a little help from TickTock and a friend at Nissan, we've been able to replicate some of the specific CAN messages used by the technician's scan-tool to read data from the Leaf battery management system.
First of course I should say that SENDING CAN messages to your Leaf (as compared to passively listening) could cause problems although most of the harmful writable data is usually protected with additional check-sums.
Anyway.. Proceed at your own risk..

What we're doing here is sending specific request messages asking for groups of data from the HV battery subsystem.
As best we can tell all of the requests from the scan-tool regarding the HV battery are sent on the 0x79b CAN ID with responses on 0x7bb. All packets are 8 bytes although sometimes not all 8 are utilized.
We've found 5 different groups of data...
Group 1 has 6 lines of data (not sure what it is yet)
Group 2 has 29 lines of data and contains all 96 of the cell voltages.
Group 3 has 5 lines and contains the Vmin and Vmax as well as a few other things we haven't figured out yet.
Group 4 has 3 lines of data and contains the 4 pack temperatures.
Group 5 has 11 lines and again, not sure what it is yet..

In order to read a group of data, first send the initial request command on ID 0x79b:
0x02 0x21 group 0xff 0xff 0xff 0xff 0xff (those last 5 bytes can be 0xff or 0x00, doesn't seem to matter, and yeah I tried group 0 and 6.. didn't see anything)

For example to request pack temperatures you'd start with
0x79b: 0x02 0x21 0x04 0 0 0 0 0

Which returns something like:
0x7bb: 0x10 0x10 0x61 0x04 0x01 0xfb 0x15 0x01

The first byte is an index (incremented on subsequent lines), the 2nd byte is a sort of group size, the 3rd byte is 0x61 (responding to the 0x21) and the 4th byte is the group number. The actual data starts on the 5th byte.
In this example the first temperature is a 3 byte value (16bit raw A/D and 8bit temp) 0x01fb 0x15 meaning 21 degrees C with the raw 10 bit A/D NTC thermistor value 0x1fb or 507 decimal. The start of the 2nd temperature is the last byte of the message.

To ask for additional lines of data, they must be requested within about a second of the initial request. In my software I ask for the 2nd line immediately after receiving the first and then ask for subsequent lines every 16ms or so.
The request additional lines command is
0x79b: 0x30 0x01 0x00 0xff 0xff 0xff 0xff 0xff

All subsequent lines will have an index in the first byte with 2 as the MS nibble and the lower nibble (4 bits) as the index.. The remaining 7 bytes are all data.
Such as:
0x7bb: 0x21 0xf8 0x15 0x02 0x06 0x13 0x02 0x0d
(ie the other 2/3rds of temp2, all of temp3 and the first 2/3rds of temp4)

In order to receive the last line, another 0x30 0x01 0x00 request is sent and for this example the response looks like:
0x7bb: 0x22 0x13 0x13 0x00 0xff 0xff 0xff 0xff
(giving the last byte of temp4.. not sure what if anything the extra 0x13 and 0x00 mean... maybe some check-sum)

On a side note, I'm trying to recreate the thermistor circuit so that we might be able to get more precise temperatures calculated from the raw A/D value as compared to the car's 1 degree C reading. As temps go up, the A/D value goes down and it's nonlinear.. It's kinda noisy though so better than 1/4 degree C isn't likely.

In larger groups (cell voltages in group 2) the index byte continues 0x23, 0x24, 0x25 etc wrapping from 0x2f back to 0x20.

The cell voltages in Group 2 start with the 5th byte in the first line (just like the temps) with the first two cell voltages then subsequent lines contain another 3 and a half cell voltages on each.

example:
0x7bb: 10 C6 61 02 0F D8 0F D4
0x7bb: 21 0F D0 0F D9 0F D0 0F
0x7bb: 22 CC 0F D3 0F D0 0F D0
etc..

If you ask for more than the above mentioned lines for each group (including the first line from the initial request), you won't get a response.

In early experiments (before figuring out how to ask for successive lines) I was toggling between asking for the first line of group 2 and the first line of group 3 at a 1250ms interval (about the max it would let me) and I could hear an odd clicking sound coming from the OBD2 port. Now that we're getting all the data, the clicking seems to have gone away as well as the 1.1 second max sample rate.
I've tried sampling group 3 (which has the Vmin and Vmax) at 4Hz (intermediate lines at 16ms) with no trouble. I tried intermediate line requests at 8ms and that seemed to work but there were a few glitches. Even at 16ms I'm not 100% certain I'm getting ALL the data ALL the time, but mostly it's working great. These 0x7xx messages are the lowest priority on the bus but it's still probably not a good idea to overload it..

We're still trying to decode additional data in group 3 as well as groups 1 and 5, so it'll be fun to see what kind of data the other folks out there are getting on their systems...

A real step forward for the rest of us, Thanks again.

CAUTION: Be very careful when experimenting with writing to the car,
and never do your first experiments while driving, it is just too dangerous.
 
garygid said:
Great work, and thanks a bunch for sharing.

What interface are you using to query the EV bus?

Have you experimented with making any Requests on
the CAR-CAN bus or the AV-CAN bus?

Now, I have a good reason to perfect some code for the
AVR-CAN (and Mbed) to send Requests, and actively
receive messages (the Replies).

To get it done, the CAN interface chip needs to be in
Transmit-Enabled mode both for sending the requests,
AND for actively Receiving messages. However, if one
wants to continue passively listening to other messages
(not being the active "recipient") one needs to be very careful
to only write the ACK bit to the "response" messages.

Again, thanks for sharing.

My first goal will be to add the 4 Battery Pack temperatures
to the GID-Meter, probably only done once a minute, or so.

Very cool.. I'll try to stop by the meeting tomorrow morning after my run.
I used Peak's PCAN dongle and PCAN-View initially to experiment with the bus, but once I'd locked down the major info I moved to a little 8 bit MCU board I made some years back with a single CAN port and 128x64 OLED graphics display. I've only got a few left and am not looking to manufacture or sell anything... There's plenty of other nice hardware already floating around this place!
I can demonstrate my setup tomorrow.
I have not played with the AV or CAR CAN buses although I have break-outs for them on my OBD2 cables.
I did see messages to/from another controller on EV-CAN (0x79d, responses on 0x7bd) but haven't played with it.

I look forward to seeing the temperature responses from you and others.. So far I've seen:
21 degrees 499-505 raw
20 degrees 509-517 raw
19 degrees 518-527 raw
18 degrees 528-536 raw
17 degrees 538-547 raw
.. but for example I don't know if 537 would come down as 17 or 18 degrees.. so I'm looking to fill in this table with more data..
 
TickTock said:
Thanks again Greg! Just finished coding it up. Here's the money-shot.
Sweet!! That's gonna be awesome.

P.S.170 Gids @ 75.4%?? Ouch.. How many capacity bars are you at?
 
garygid said:
The 170/281 = 60.5% GIDs
I usually display %GIDs to make the comparison
with the "Real SOC" percentage easier.

When I was looking at vehicles on the dealer lot I was trying to figure out an equation that could give a consistent battery health number.. Ideally something on the order of Gids/SOC although I saw a small drift in this equation at various states of charge.. What I found worked better (and have been using since) is Gids/(SOC-3)... This will return about 3.0 for a new car (a car capably of 276-281 Gids). Among the various vehicles I measured this morning at the meeting we saw a range from 2.55-2.85. I didn't have the CAN SOC data back with Joulee3 but if memory serves I was getting about 243 Gids on a full charge.. If we assume 95% is full that would be 243/92=2.64. Last night in the new car I had 281 @ 95.4% so 281/92.4=3.041. On a full charge two weeks ago I saw 278 Gids @ 94.5% so 278/91.5 = 3.038.. About the same. If you choose to use % Gids (which is a little confusing imho) then it's off by a factor 2.81.
 
GregH said:
When I was looking at vehicles on the dealer lot I was trying to figure out an equation that could give a consistent battery health number.. Ideally something on the order of Gids/SOC...

I know I've brought this up before, but I don't remember why you didn't like a simple comparison of SOC% (adjusted to 2013 LEAF readout, where 95.4% SOC = 100%) and Gid2%?

When new, the two equal 100% at full charge, and as the battery degrades, the delta between the two will suggest the % degradation (but not temperature related losses).



TonyWilliams said:
vegastar said:
I am used to the gids percentage, but I think that it would be good to have usable kW.h before turtle, like (gids - 7) x 0.08.

100 ((281 -7) / (281 - 7)) = 100% * 21 = 21kWh

100 ((144 -7) / (281 - 7)) = 50% * 21 = 10.5kWh

100 ((7 -7) / (281 - 7)) = 0% * 21 = 0kWh


The new 2013 will show 100% regardless of capacity, when fully charged, and show the following:

kWh----------Gid----Gid%---Gid2%---2013 dash % (2013 dash % data based on SOC %, not Gids)
21.0--Full----281---100%---100%----100% (non-degraded at 70F; 21kWh usable)
10.5--Half----144--51.2%----50%----50% (non-degraded at 70F; 10.5kWh usable)
10.5--Full***--144--51.2%----50%----100% (***used 50% degraded at 70F; 10.5kWh usable)
3.2---LBW----49---17.4%---15.3%----15%
1.3---VLB----24----8.6%-----6.2%----5%
0.0---Turtle --7-----2.5%-----0%-----0%

NOTE: LBW and VLB are indexed to Gids, therefore those values won't match the SOC derived data of the 2013 dash % with a degraded battery.

Turtle is not indexed to Gids, therefore under a high load, like freeway speed, expect turtle at 7 or 8 Gids, and at extremely low power, as low as 4 Gids to Turtle.
 
garygid said:
Notice that 281 / 300 = 93.67%

I don't expect the two to magically be identical since they are measuring by two different methods, which is why I want them equalized to 100% at the highest Gid2% and highest SOC%, and to use 7 Gid on the bottom as zero, which should closely match the 2013 LEAF "0%".

If 281 is 95.4% SOC, then I want that at 100% (just like the 2013 LEAF already has available to the driver).
 
TonyWilliams said:
GregH said:
When I was looking at vehicles on the dealer lot I was trying to figure out an equation that could give a consistent battery health number.. Ideally something on the order of Gids/SOC...

I know I've brought this up before, but I don't remember why you didn't like a simple comparison of SOC% (adjusted to 2013 LEAF readout, where 95.4% SOC = 100%) and Gid2%?

When new, the two equal 100% at full charge, and as the battery degrades, the delta between the two will suggest the % degradation (but not temperature related losses).
I'm not considering the 2013 SOC% display.. I don't have a 2013. Soon enough we'll know the conversion between CAN SOC% and the 2013 display for those who care..

Also I don't use GID% as I always found it confusing, especially now that we have actual SOC% in the CAN data. I have no problem thinking of raw Gids.
It's not important to me that I see "100%" at a full charge especially now that we know that the car doesn't always charge to the same final estimate of remaining energy.
281 Gids is NOT 95.4%. It was in my car that one time but the fact that on that charge, "full" was 281 and 95.4% does not mean they are related. I wouldn't be surprised if some people can get 281 Gids at 96% or for that matter at 94%.. Some people on this list have reported seeing 282 or 283 Gids as well which is not surprising (and all the more reason not to divide by 2.81).
TickTock has seen the CAN SOC% as high as 98.6% !! (@265Gids) But I'd bet he hasn't seen 281 Gids.. actually he has a most excellent public spreadsheet showing all his data..

https://docs.google.com/spreadsheet...HNwVmRkNkFnaEVOQTVENW5mOTZlb0E&hl=en_US#gid=1

I realize many on this list using Gary's meter are accustomed to seeing Gids/2.81, but for me it's just confusing. As I noted, you could use the same equation using Gid%, it would just be off by a factor of 2.81..

The problem with a straight comparison (or normalizing at the top to 100%) is that it may not be consistent at lower SOCs.. I want something that will return the same basic number regardless of what SOC the vehicle happens to be at when measured. When I watched a friend's Leaf charge and noted the SOC% and Gid#, simply dividing them didn't give consistent results over all SOCs.. yet Gid/(SOC-3) came a lot closer (still some error as the Gids are roughly 1/3 the precision of the SOC%)
I imagine (Gid-7)/SOC could work similarly well but I haven't tested it... but here goes:

From my personal log on the new car 2/5/13 Tuesday
............................GID/(SOC-3).......(GID-7)/SOC
0mi. 278Gid 94.5%........3.04.........2.87
34.3mi 160Gid 56.4%....3.00.........2.71
43.3mi 130Gid 45.9%....3.03.........2.68
78.4mi 49Gid 19.1%......3.04.........2.20
82.7mi 33Gid 12.8%......3.37.........2.03

Guess not..

(edit.. again) Looking at TickTock's log in Arizona..
2/10/12 258Gids, 96.0%.. so "health Gid/(SOC-3) = 2.77
2/25/12 265Gids, 98.6%.... 2.77
3/27/12 246Gids, 94.7%.... 2.68
fast forward..
8/11/12 232Gids, 95.8%... 2.50
9/16/12 213Gids, 95.3...2.31 (Lost 12th capacity bar)
9/24/12 215Gids, 96.4%... 2.30
11/20/12 219Gids, 95.7%... 2.36
1/3/13 217Gids, 94.7%... 2.36
2/21/13 219Gids, 95.0%... 2.38

garygid said:
Notice that 281 / 300 = 93.67%
????
 
One long set of data from the BMS should be the estimated
cell (pair) resistances, derived from noting how much the
cell-pair's voltage sags when current is being withdrawn.

There might be another set of data indicating charging
resistances, derived from how much the voltage rises
when charging.

Perhaps use F (x 10, so in tenths) = (C x 18) + 320
to display the battery temperatures?
 
garygid said:
One long set of data from the BMS should be the estimated
cell (pair) resistances, derived from noting how much the
cell-pair's voltage sags when current is being withdrawn.

There might be another set of data indicating charging
resistances, derived from how much the voltage rises
when charging.

Yes!
There are some odd sets of 10 x 16bit data in group 5.. no clue yet.
Also I'm guessing we might find some sort of counters in there for charge events so that the Nissan battery report can tell how often you've been plugging in at high states of charge or how often you've used QCs..

garygid said:
Perhaps use F (x 10, so in tenths) = (C x 18) + 320
to display the battery temperatures?

It is increasingly looking like Nissan is NOT using a look up table for the non-linear NTC values but rather a set of linear approximations.. (edit-maybe)
So yes in the range of 18-24 degrees it looks like 10 steps per degree C.. but in looks like in the 12-17 degree range it's closer to 10.5 steps. I'm still filling in my temperature data table.. so far I have the following for temp transitions..

13 degrees starts at 589
14 degrees starts at 579
15 degrees starts at 569
16 degrees starts at 558
17 degrees starts at 548
18 degrees starts at 537
19 degrees starts at 527
20 degrees starts at 517
21 degrees starts at 507
22 degrees starts at 497
23 degrees starts at 487
24 degrees starts at 477
25 degrees starts at 467
26 degrees starts at 457
27 degrees starts at 447
28 degrees starts at 438
29 degrees starts at 428
30 degrees starts at 419
31 degrees starts at 410

<edit> If anyone has data below 13 or over 30, please share! :)
(btw as soon as the highest temp clicked over from 468 to 467, the 6th temp bar on the dash lit up. After resting it has gone down to 468 (24.9deg) and the 6th bar went away..)
 
Does the Nissan Consult have the ability to turn on the pack heater? Even though we are heading into spring, this is something I'd like to play around with next winter. I know the heaters are pretty abysmal but it's better than nothing!
 
GregH,
So, it looks like the raw temp data will indicate
a precision of very near a tenth of a degree C,
even if we do not know much yet about the accuracy.

Akso, it seems that tell Pack temperature Bar display
operates on the highest temperature, and there is
essentially no hysteresis.

So, using the raw values, we might try to display the
extended-precision temperatures, like "C20. 3".

In the CANary, scrolling plots of the 4 high-precision
temperatures on one graph would be very interesting.
 
JeremyW said:
Does the Nissan Consult have the ability to turn on the pack heater? Even though we are heading into spring, this is something I'd like to play around with next winter. I know the heaters are pretty abysmal but it's better than nothing!
Hmmm.. good question. I bet there is a way, although we'd have to watch a Consult transaction very carefully to figure out how it's done! Those of us in the warmer climates are doing all we can to keep our packs from getting warm..
 
Back
Top