EV RANGE DECREASE AFTER CERTAIN USAGE

[Neverfuel]

On another note, it is interesting to see that Anko's battery capacity is 37Ah and Gwatpe's is 37.4Ah.

I wish it was. Mine is only 34.0 :evil:

According to Mitsu, it was only 38.7 (or something like that) upon delivery. Then again, the voltage is more than 300 volt (more like 320, or so). So, with 34.0 you still get to 10.9 kW. Bad, but not as bad as it may seem. Gwatpe would be at 11.97. Advantage of having good weather most of the time?

Sorry Anko - I had 37 in my head when I did the figures even though you had quoted 34 - probably due to having to flick between forum pages.

Mitsu quote a maximum voltage of 4.1V per cell x 80 which would be 328v, so with cell levelling, 310 - 320V is probably a good guesstimate based on 38.7Ah when it was delivered. I guess without knowing the exact voltage and the delivery ampage to work out how close to 12,000Wh the car was when new, it is almost impossible to accurately work out the degradation up to date. You should be able to get an accurate indication going forward though.

Gwatpe's high figure maybe proves his theory on the save/charge usage?

 

[anko]

My guess: percentage wise the same buffer is kept. In terms of kWh, the buffer will be smaller.

 

[maby]

My guess: percentage wise the same buffer is kept. In terms of kWh, the buffer will be smaller.

Interesting. My understanding of the Prius - which follows the same philosophy of using significantly less than 100% of the battery capacity when new, was that as the battery aged, it would reduce the size of the buffer in order to maintain the same capacity for moving the car. It really does not make much sense as the car approaches the end of its useful life to be using less than 60% of the available battery capacity - if my battery is getting close to the end of its useful life, I would prefer to use its full remaining capacity and get a 20 mile EV range rather than continue nursing it along and get a 10 mile EV range.

 

[Neverfuel]

It has been discussed extensively in the Dutch forum. 40 is a nominal valu, no car will ever show it Measure a car new from the factory and will be 38-39. Most depreciation will be in the first few thousand Km. Something around 37 is fine at this stage. As cars age it will drop slowly. How fast remains to be seen.

As the battery ages, does the car continue to stick to the use of the nominal 80% to 25% (give-or-take) of the real capacity, or does it start to use a larger fraction of the real capacity to compensate for the aging?

Very good question - I have only ever seen the SOC levels for Series/AC off/turtle mode/shutdown (<30/22/17/13) in terms of a percentage in all the documentation and whilst I tend to use a rule of thumb 8.4kw available SOC out of the 12 available, I am now beginning to think that the car will continue to need the same amount of power in 5 years as it does now so the percentages will probably change over time.

 

[anko]

For my car, with a rather low health figure, at least the 22% threshold still applies for switching from parallel to serial mode.

 

[gwatpe]

I just used the number 22 as an average minimum to expect to be unavailable. I would be very wary of presenting numbers with too many significant figures. I doubt the car measurements are that good.

Time will tell how the battery ages. A wise man once told me that a battery life is the sum total of the total Ah in and out, in relation to the plate capacity. Temperature and Amps and operation outside of design voltages de-rate the life. Fast charging and discharging as well as too cold, or hot reduce the life.

My driving needs require petrol consumption approx half the time, and it may be that the ICE operation reduces the peak battery needs enough to gain life expectancy at the expense of a bit more petrol. It will depend on the battery replacement cost to see if it is more efficient than burning some petrol and deferring its replacement.

We have an objective way of getting data from the computers, so we will be able to monitor these important components over time without additional payments at service.

I will be looking at the possibility of using a WiFi Arduino chip that I already have and a tablet, or laptop, to automate live data extraction and recording. For the moment the Ah can be easily retrieved and will suffice my immediate needs.

BTW is battery voltage available in line 762 22? mine read 304 and this is like the pack voltage. Will check after a full recharge and when depleted.

 

[Neverfuel]

BTW is battery voltage available in line 762 22? mine read 304 and this is like the pack voltage. Will check after a full recharge and when depleted.

Did you mean line 23 end 4 digits 01 30? It seems a bit unlikely as it happens that it is the same as line 23 on Anko's readout and you both had different states of charge when you did the figures. Would be nice to know what all the lines mean though.

 

[gwatpe]

I did question mark the line number. There may be some reference info in the service manual. I have yet to delve into it.

For a logging exercise, I think that some data will be more interesting than other. Will see what other members believe is important data and move factor this into any app that I come up with to log and graph it.

 

[anko]

I added to Battery Total Voltage parameter to http://www.myoutlanderphev.com/forum/viewtopic.php?f=10&t=1796&p=19568#p19568

BTW: I already have a solution that retrieves various parameters from various ECU's and transforms that into a dashboard. It is even capable of storing the captured data into a CSV file (in its original HEX format), so you can later analyse it (never done that yet ;-) ). Problem is: as I had no idea how to build an Android or iOS app, I took a huge detour in getting there, making it virtually impossible to share the solution as such.

I have bought a Raspberry PI and installed a home made multi threaded Java application, a web server and some other stuff. One thread of the Java program continuously reads data from the OBDII dongle and stores the data in a shared location in memory. The other thread services requests for data from a web page on my iPhone, by getting the data from the shared memory location and sending it to the web page using Web Sockets.

The reason for doing so, is that (in theory) you get a beter overall performance. With a single thread, you send a request, wait for the OBDII dongle to respond, send the response to the phone, wait for the phone to process the data and come up with a new request. Waiting periods are sequential. With my solution, waiting periods are in parallel.

The two threads work together, in the sense that only data that was requested by the web page will be requested from the OBDII dongle. That way, you do not have to read out all ECU’s in every sweep, and refresh time is dramatically reduced (now between 0.5 and 1 second for a decent dashboard).

The Java application uses two config CSV files, one with addresses of various ECU's and the other with the various parameters that I have been able to identify so far. So, it is rather flexible.

Existing solutions, like DashCmd or TorquePRO will not do it, for two reasons:
- They cannot handle setting up the necessary flow control for the PHEV ECU's
- The different ECU's use the same mode and pit for their requests and responses. Requests 1201 and 1202 are valid for all of them. But DashCmd and TorquePRO cannot tell the responses apart, as they ignore the sender address. So, these apps could not tell the RPM of the front E-motor apart from the RPM of the rear E-motor.

I think existing solutions could work if there was a man-in-the-middle that captures and manipulates traffic between the app and the OBDII dongle. It would have to insert ATFCSH commands to configure flow control, whenever another ECU is targeted by the app, and it would have to remap the 1201 and 1202 request numbers. But even then, I think it will be to slow due to the sequential waiting times.

I think it would be absolutely great if somebody (gwatpe?) could pick up my stuff and transform it into an app (iPhone, Android, or whatever) that doesn’t require a Raspberry PI as an extra component. If gwatpe or somebody else wants to have a shot at it, let me know, and I’ll share as much as possible / time allows, but via email as that works much better, I think.

 

[gwatpe]

I have an Arduino Yun, and this has a WiFi interface. If I am able to get it to communicate with the OBD2 WiFi interface, even to just send the ATZ command and get the ELM reply, will confirm that pretty well anything is possible. I have good experience with COM's between a micro and computer and graphing of data with a PC.

I suspect that while the PHEV is new, that individual cell voltages may not be that important. The graphed time stamped data comparing say, electric power and %SOC, mpg and distance will be most relevant. Comparisons of battery Ah over time will be useful. Coolant temperature and heater operation relationship might also be useful. The battery power, and not just EV motor power would be a plus.

I am not convinced that a phone is the best tool, as in AUS a driver can have an infringement notice issued if a phone is actually held when driving. Better having a laptop, or tablet connected with a big screen and data graphed and stored.

I would have button clicks on a PC initiate a sequence on an Arduino that communicates with the OBD2 with a reply sent back to the PC with a reverse sequence. I don't see this tool as a permanent fixture.

How good would it be if the perfectly good screen in the PHEV on the MMCS, or radio could be used.

I have to agree about timing constraints, but I would only target specific data for logging. By all means have access to as much as possible, but only as needed, and not during logging. Think this is how MUT3 handles the task already. I am not savvy with automation of a telnet type app, on phone or PC. I would have to presently use an intermediate micro component between the car and PC and the MUT3 has a box between the car and the PC as part of the coms package.

 

[anko]

Just now realise and Arduino Yun is pretty much the same as a Raspberry PI. In that case, I am where you want to be (although it was all done bitch-ugly). My PI has travelled with me to Croatia back and forth (3000 kms) monitoring several parameters in real time. What I am looking for is how to convert this into a solution that doesn't require a PI (or Arduino).

EDIT: Which doesn't mean I am not willing to share info with you ;-)

Don't you guys have holders to fix phones to dashboards?