Unexpected down shift
Unexpected down shift
Not so nice doing 150kph....
Attached msq , log file too large.
//Tobmag
- Attachments
-
- graph1.png (20.3 KiB) Viewed 11662 times
-
- graph.png (21.13 KiB) Viewed 11662 times
-
- CurrentTune - Copy.msq
- (45.85 KiB) Downloaded 658 times
-
- Posts: 1696
- Joined: Fri Apr 04, 2008 1:28 pm
Re: Unexpected down shift
We really need the log to see what is going on properly. You can shorten a log easily enough.
Use a text editor (notepad.exe, or my favorite notepad++). Just leave the header (the first few lines of the log - generally this is 4 lines, but it should be obvious looking at the file), and then take out whole lines after that.
It's generally best to leave one continuous block of lines (that illustrates the issue at hand, obviously), otherwise the discontinuities become hard for others to interpret.
If you have several separate incidents from one log to show us, you can edit each incident into its own log file.
Lance.
Re: Unexpected down shift
Cant get any sence out from notepad and notapad++ seems impossible to install, even their download page is corrupt....
You got the file by mail....
BR//Tobmag
Re: Unexpected down shift
select a point in the log, then on the menu search, log editing: Delete Before/After Cusor Position.
I used that for too big files.
Guillaume
Re: Unexpected down shift
Ohh that was the way to do it, very easy indeed.....you can also cut the datalog with megalogviewer
Data log attacehd
- Attachments
-
- 2014-08-17_10_modified.msl
- (978.93 KiB) Downloaded 451 times
-
- Posts: 1696
- Joined: Fri Apr 04, 2008 1:28 pm
Re: Unexpected down shift
Are we talking about the incident at approx. 1538 to 1543 seconds in the log?
There is a 3-4 shift (1538.3 sec): speed = 150, load = 98.8 - this shift is caused by moving horizontally across the top row of the shift table, as we have crossed the boundary from 3rd to 4th. Then there is a 4-3 shift (1540.2 sec): speed = 148.7, load = 13.3 - the throttle has been backed way off (8%), and the speed has dropped. Thought the speed is below 150 again, the reduction in load should push the target gear to a much lower part of the table, and the target gear should still be 4th. So there should be no shift, at first glance. But the load is averaged over time in the code, and the controller is likely still responding to the higher average rather than the current value, so you get the shift. So you might reduce the averaging, by reducing the LOAD Smoothing Factor. You can read about this here: http://www.msgpio.com/manuals/mshift/V41tune.html#gs (this also reminds me that I should add the averaged load to the datalog).
However, I think there may be another clue to why this happens at 1504.754 seconds in the log, where the speed drops to 27 in the log. I think this is may also be happening prior to some of the other unexpected downshifts, but the log is too slow to capture it most of the time. So I will have a look in the code. In the meantime you could try:
- increasing the VSS input masking factor,
- increasing the VSS smoothing factor,
- reducing the max. vehicle speed setting,
- increasing the minimum speed,
These are all described here: http://www.msgpio.com/manuals/mshift/V41tune.html#gv
Some combination of the above should help significantly.
Lance.
-
- Posts: 1696
- Joined: Fri Apr 04, 2008 1:28 pm
Re: Unexpected down shift
I see that the averaged LOAD *is* in the log, it is called "sLoad" (sorry for implying that it wasn't - I didn't see it at first glance).
If you look at it at the point the unwanted downshift occurs, sLoad is at 96.5, which is still the top row of the shift table, and this is why the downshift occurs. sLoad starts dropping soon after that, but too late to prevent the downshift.
So, as I hinted above, you may want to reduce the Load Smoothing factor (maybe by quite a bit!). This will make the sLoad follow the actual instantaneous load more closely, and make the trans more responsive (but if you go to far the target gear might jump all over the gear table, so use some caution).
Lance.
Re: Unexpected down shift
Thanks for that, now its clear and I will reduce the lag factor on Load.
The huge drop in Speed as we see around 1504sec I have never seen before either and I assume Speed is a claculation and not an actual value?
I guess you rember the old issue we had where the speed could start jump around like crazy at different VSS frequenses?
Second thing, if the "dot" we see in the gear shift table is Load wouldnt it be better to actually have sLoad as indicator? Then we can see directly what the lag factor is doing at the same time.
BR//Tobmag
-
- Posts: 1696
- Joined: Fri Apr 04, 2008 1:28 pm
Re: Unexpected down shift
Tobmag,Second thing, if the "dot" we see in the gear shift table is Load wouldn't it be better to actually have sLoad as indicator? Then we can see directly what the lag factor is doing at the same time.
Yes, of course. It was an oversight on my part not to do this a long time ago. I will attach an INI with this change for the current 4.146 test code (from another recent thread), but you (or anyone) can change any earlier INI by using a text editor and finding a line like this near line 2553:
Code: Select all
yBins = LOAD_table1, LOAD, readonly
Code: Select all
yBins = LOAD_table1, LOAD_short, readonly
All future INIs will have this change.
Lance.
- Attachments
-
- Monitor_4146.abs .s19
- (73.43 KiB) Downloaded 449 times
-
- GPIO_MShift_4146.ini
- (221.43 KiB) Downloaded 463 times
Re: Unexpected down shift
BR//Tobmag