OVMS für den Soul

[^tom^]

Vielen Dank für die Informationen, Digitaldrucker

I'm very happy with even 62kW, but if they open up for even moreit is very welcomed. It will not only make you able to get where you want faster, but it will make the charging queue shorter.
I've been waiting 20-30 minutes for one guy who used the fast charger to fill up his car 100%. If he had moved his car over to the 22kW AC charger, he would have saved money and my time. It was hard to be polite when he finally came

Exactly this is a big problem (those charge and can go to 100%) AND finaly even a 200kW charger can NOT solve this problem because if you charge to 100% the 200kW charger will be only 10 minutes faster. To go from 90 to 100% can go up to 30 Minutes.

I went to a 20er chademo ones and a Tesla was hooked up at the Typ2 plug.......still charging after 05 hours and 29 minutes!

[goev_no05]

I agree. We have a lot of discussion about this in the norwegian forums. There are a lot of people who don't care or don't understand that this is a problem.
I wish the charger would stop and release the plug as soon as charging reaches that level where it is just as fast to charge using the type 2-chargers that usually stand right next to the DC-charger. But of course that won't help when there is a Tesla going on for the sixth hour.

[bill]

New version v0.42: http://geir.validalo.net/OVMS.KIA-v0.42unofficial.zip

// 0.42 25 Nov 2015 (Geir Øyvind Vælidalo)
// - Fixed Trip + added trip to AVG sms (untested)
// - chargefull_minsremaining calculation should calc to range or soc
// specified in CA if present. On ChaDeMo 83% is always max (BMS SOC 80%)
// - SMS-notification when starting charging is now back. Removed by mistake.
// - "Changed" the poll states to 0=off, 1=on, 2=charging
// - ChaDeMo charging is properly detected

Hi Geir,

here some feedback to this version:

Type 2 Charging. SMS and Push notification works again. I think this is a useful feature, e.g. if you are using the charging timer and habe schedules like 80% on 9.00 PM and 100% on 6.00 AM.

Remaining charging time after plug-in like this (time not correct as in earlier Versions)

00:00:44
Standard - Charging
230V/29A
Full: 29 mins
SOC: 8%
Ideal Range: 10 km
Est. Range: 10 km
ODO: xxxxxx km

After polling with SMS ommand STAT? something like this

00:00:52
Standard - Charging
216V/27A
SOC: 27%
Ideal Range: 34 km
Est. Range: 34 km
ODO: xxxxxx km

The remaining time is missing here. It worked fine on previous versions

Tire pressures/temperatures now look good.

In the IOS App the V/A on the plug looks good on standard charging (in my case 27 or 29 ampere as shown above), the Ampere value on the battery now is no more zero as in earlier versions but in my case not 27 or 29 ampere but 32 ampere....

Chademo not tested.

Is it possible to extract all SMS commands out of your code and post them somewhere? Would be great.

I hope this helps

bill

[JejuSoul]

If you look at the CHAdeMO-plug of this station you will see - I think as usual - a certification for maximal current of 125 A.
With a voltage of 360 V and 125 A it would deliver "only" 45 kW.
Because the voltage is fixed in the range of nearly 360 - 400 V there must be a higher current.
It was this way at KIA headquarter in Frankfurt: 175 A.
But that´s not what the CHAdeMO-certification and the plugs are about...
It´s working - but without certification!?...

Yes. Chademo usually maxes at 125A.
But according to http://www.chademo.com/wp/technology/optimal/

The conductor geometry of CHAdeMO connector is designed to allow for 200A, which means it can almost double its power level to adapt to the market environment as necessary.

It could go higher but currently they only certify for 125A.

On the English KiaSoulEV forum we are also discussing Chademo. Specifically why the car's Cumulative Discharge Energy counter is increasing during the last 8 minutes of charge.
see http://www.mykiasoulev.com/forum/viewto ... 4&start=10
and for the data recorded of a Chademo session
https://docs.google.com/spreadsheets/d/ ... 13&vpid=A1

[goev_no05]

This helps very much, Bill!

I don't know why the time is not showing up in the second STAT. I will look into it.

The ampere in the battery is calculated from the maximum 6.6 as the on board charger can take and the voltage in. I will do the same with the ChaDeMo, so we can see what the maximum we can get.

Here are the SMS:
DEBUG? & DEBUG C Outputs some debug data
HELP extend HELP output and should list out the available SMS-commands, but never worked.
RANGE? & RANGE x Range setting. Used to read and specify the range you feel is more correct for a full battery.
CA Charge Alert, see Twizy documentation. Not tested, but in theory everything is in place.
QRY xyz Query CAN-messages. xyz is the CAN-id. So to get door bits, send QRY 018, and QRY 567 for clock
BTMP Returns Battery temperatures
BATT Battery info excluding temps.
BCV x Battery cell voltages where x is 0-3. 0 gives cells 1-25, 1 gives cell 26-50 and so on.
TPMS Tire pressures and temperature
AVG Average power consumption pr. km/mi for last trip and in total

Note that the content of these will change. Many values are kinda cryptic, but that was to get things cramped into 160 bytes.
If any of you have any good suggestion for an SMS, please write it here with info of which values it should contain and what you think it should be called

[JejuSoul]

BATT:
Det9.0%#48 7.6%#3 (the value is maybe by factor 10 to high for the highest and the lowest)

Maybe you are correct. The code does not divide the value by 10(dec) as it should.
looking at https://github.com/goev/Open-Vehicle-Mo ... _kiasoul.c from line 449

Code: Alles auswählen

          }else if( vehicle_poll_ml_frame==4){
            ks_battery_max_detoriation          = (UINT)can_databuffer[2+CAN_ADJ] | ((UINT)can_databuffer[1+CAN_ADJ]<<8);
            ks_battery_max_detoriation_cell_no  = can_databuffer[3+CAN_ADJ];
            ks_battery_min_detoriation          = (UINT)can_databuffer[5+CAN_ADJ] | ((UINT)can_databuffer[4+CAN_ADJ]<<8);
            ks_battery_min_detoriation_cell_no  = can_databuffer[6+CAN_ADJ];
          }

But then something else is also wrong. An integral hex value must be an integral decimal. So how is 7.6% possible if you haven't already divided.

I am keeping track of battery deterioration here - http://www.mykiasoulev.com/forum/viewto ... ?f=6&t=434
The values given above for Tom's car are totally different to everyone elses. I think there must be a mistake in your code.

To give an example from my car at 9000km
line 7EC 24 00 23 02 00 01 53 57
23 hex = 35 dec => max deterioration = 3.5% on cell # 2
01 hex = 1 dec => min deterioration 0.1% on cell # 83

[goev_no05]

It is the stp_l2f-method used for printing that is causing this. In this case I told it to print 1 decimal. It takes an integer value and treats the least significant digit as the decimal value, effectively dividing by 10.

My car has 9.7% and 8.3% after driving 22000km. I hope the actual values 1/10 of this, otherwise we would reach 70% way to soon.

[JejuSoul]

My car has 9.7% and 8.3% after driving 22000km. I hope the actual values 1/10 of this, otherwise we would reach 70% way to soon.

On the 17th October you posted your data on the SoulSpy thread.
At that time your car had values of 10.8% and 9.3%.
It seems your battery has improved.

This has already happened to one car in Canada. We are having a discussion on why this might occur due to battery calibration.
Can you post your current battery data and any ideas about why you think it might have occurred.

Here is a plot of ten cars we have data for showing their battery deterioration against number of battery cycles (Calculated by dividing the cumulative discharge by 27) Tom's car is by far the outlier. I am not proposing that this represents a method to calculate when we reach warranty. Just that currently most cars are showing a similar pattern. But not Tom's. Why?

[^tom^]

Thanks for insert the trip informations.....great!

V0.42 and App
The testride from today gave me the following informations:

The Voltage and Amps still not bigger letters (I can not zoom the App screen) so it is hard to read.
But it is very accurate.

AVG:
Does not show last trip, shows actual trip
Something wrong in the calculation:
00:00:38
Last Trip:
22.6km
0.00kWh/100km (here is a mistake)
5.38km/kWh
Total:
19.15kWh/100km
5.23km/kWh

btmp:
Max22C Min21C (but #8 has 19C) so something wrong here too

I am still looking for the total charged AC/DC ports. Any ideas?

[goev_no05]

Thanks again ^Tom^!

I can't control the size or text shown in the APP from the OVMS-firmware. That has to be done in the APP itself. I can only provide data. The APP is something I might look at later, and first of all the iOS-version as it is what I use, and it's a bit behind the Android.

AVG is not working properly, and I've discovered a flaw in it. It is actually wrong because the discharge contains ALL the energy the motor has used. This means all the recuperated energy too. So, what AVG shows us is the amount of power used from the battery if we didn't have recuperation at all. Interesting, but not exactly what we want.

What I need to do is to find out how much cumulated charge has changed too since the trip started. This will give me the recuperation too. Then I can calculate the proper energy usage.

The BTMP max and min is not something I create. It is values that I read from the BMS. If they are wrong, I don't know why. Maybe I should find max and min myself instead of trusting the BMS, but I think it is low priority at the moment