WOT odd shifting behaviors

A forum for discussing applications and implementations of the MegaShift transmission controller code for the GPIO from B&G. This can control up to 8-speeds and 6 shift solenoids (plus a 16x9 table for controlling a PWM line pressure valve). It has manual and fully automatic modes (16x9 load x speed table), with under and over rev-limit protection, and full data logging of all inputs and outputs (among many other abilities). A TransStim to test your completed board is also available.
Bernard Fife
Posts: 1696
Joined: Fri Apr 04, 2008 1:28 pm

Re: WOT odd shifting behaviors

Post by Bernard Fife »

I did notice that the units weren't displayed for minimum decel mode speed (which might have been why it was hard to spot), so the attached INI fixes that:
GPIO_MShift_5102iv.ini
Do not use, use INI below instead
(297.28 KiB) Downloaded 530 times
It should show mph/kph correctly based on your settings.

Here is a new INI with the pulse per mile/km setting fixed:
GPIO_MShift_5102iv.ini
Use this INI
(297.48 KiB) Downloaded 548 times
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
mill3833
Posts: 72
Joined: Mon Jan 27, 2014 3:33 pm

Re: WOT odd shifting behaviors

Post by mill3833 »

Lance,

Yes, I was looking right over it! I was looking for a "default=10", when mine was set at 150. Back a couple of posts ago, you mention how I could disable Decel Mode, which I have done by setting Max Sload=0. So I guess having 150 in there doesn't mater.

Ok, so I just got back from test driving 5102iv. I slowly getting my putt around town shift tables dialed in.

So a couple of questions 1st, while still fresh in my mind...

At time 365.5 I'm backing out of the driveway. Any idea why tGear is bouncing between -1 and 4?

I have an annoying downshift to 1st, a sec or 2 after leaving from a dead stop. It doesn't always do it, here's an example. At time 450.6 I am getting ready to accelerate out onto the road. Time 453.2 it down shifts to 1st. My TPS is constant. Actually, it may be my avload coming up, and getting into the next cell. I'll try bumping that up...

The attempted 1-2 and 2-3 WOT pass happens at time 784. I tried to scrub the tires prior, with some 1st gear blips, but the 1st gear pull was still pretty messy. Hard to get traction on the back country roads of Indiana. My rpm shift points were both set at 5000 rpm. But it looks like I botched the 1-2 shift, by the time I moved the lever to M2, it was well past 5000.

On the 2-3, it didn't seem to follow either the 5000 upshift point nor the 70 mph point. It commanded the shift at around 5600 or 5900 (my trigger is all over the place, darn opti-spark) or around 74 mph. So I'm not sure what's going on there. With my ratty rpm trigger, it might be best to just stick with mph shifting for now.

So here's the data, if you want to look it over.

Dave
Attachments
MShift_CurrentTune 5102iv.msq
(60.23 KiB) Downloaded 519 times
2015-10-19_18.20.39 drv3.msl
(4.81 MiB) Downloaded 528 times
mill3833
Posts: 72
Joined: Mon Jan 27, 2014 3:33 pm

Re: WOT odd shifting behaviors

Post by mill3833 »

Lance,
Just had the last night of racing for the season tonight. Code 5101 with mph shifting worked just fine. Maybe at a later date I will do some more experimenting with 5102iv and the new overrev shift points feature.

As a side note, I usually have some issues when bouncing between firmware versions. I've learned that the "difference report" update, via my MS3Pro usually results in corrupting the GPIO firmware, and I have to reflash it. I have best success if, after flashing it, I upload the desired tune, via the direct connect RS232 cable, and not via CAN pass-through. Once the main tune is in, I can do small incremental changes, one at a time, via the MS3Pro/Tunerstudio CAN pass-through, usually (but not always) without a corruption. And I am careful to wait the extra time for the "burn" to occur, but even then, corruption can occur. The last time I switched from 5102iv code to 5101 code, my pulses per mile went from 2000 to 4000. Weird...

Anyhow, had an uneventful, smooth night tonight with MSGPIO doing the shifting, so thanks.

Dave
Bernard Fife
Posts: 1696
Joined: Fri Apr 04, 2008 1:28 pm

Re: WOT odd shifting behaviors

Post by Bernard Fife »

Dave,

Yes, there are issues when trying to load code via a CANbus connection. I always use a direct serial connection to the GPIO board when loading MShift code and MSQ for that reason. This fault is due to the software in the MS3 and TunerStudio getting 'out of sync' with what is on the GPIO board (separate from the 'burn' indicator), and there's nothing I can do about it in the MShift firmware, unfortunately.

The good thing is that once you have a firmware and MSQ you know works, it ought to stay "un-corrupted" permanently (though I realize it is a pain when swapping code frequently, and I am sorry for that).

Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
mill3833
Posts: 72
Joined: Mon Jan 27, 2014 3:33 pm

Re: WOT odd shifting behaviors

Post by mill3833 »

Lance,

Thanks for the feedback. I just wanted to make sure I wasn't doing something wrong, or could do something different to make the loads go easier. I really appreciate your fast response on these issues. Having a SW developer who is so tightly coupled with the end user is what makes the whole MS experience unique! Thanks again!

Dave
Bernard Fife
Posts: 1696
Joined: Fri Apr 04, 2008 1:28 pm

Re: WOT odd shifting behaviors

Post by Bernard Fife »

Dave,

Thank YOU for trying these things, nothing could happen with it!

Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
Bernard Fife
Posts: 1696
Joined: Fri Apr 04, 2008 1:28 pm

Re: WOT odd shifting behaviors

Post by Bernard Fife »

My rpm shift points were both set at 5000 rpm. But it looks like I botched the 1-2 shift, by the time I moved the lever to M2, it was well past 5000.
Dave,

I never addressed this, so let me do that now.

The shifts are commanded when the rpm hits the user specified target (5000 in this case), with a few things that can block a shift. *BUT* the revs can keep climbing during two periods:
  1. During the pressure adjustment delay (a delay before the shift solenoid states are changed, to allow any line pressure adjustments to occur) and
  2. during the shift completion delay (that sets the time before 'normal' functioning of the controller is restored after a shift but during which the bands and other friction components may be slipping).
You can try reducing the pressure adjustment delay, while increasing the shift completion delay (at high loads). This will activate the solenoids more quickly, limiting the rpm rise during the first period. You can reduce the pressure adjustment delay until the shifts start to get excessively harsh or slip too much (i.e. not enough time for the pressure to adjust for the shift). But you will likely need to increase the shift completion delay at the same time so that the controller doesn't think the shift has been completed before the bands stop slipping (otherwise a confusing second shift can be commanded immediately after the first then a shift back, as you have seen).

You might look at making sure the line pressure isn't overly limited during a shift (to allow faster shifts, but potentially more impact on the internal components). Higher pressures will limit rpm rise during period 2.

You might even have to subtract a factor from your rev limit to allow for the rpm climb during a shift even once the delays are dialed in.

So these are all factors that you might have to tune by trial and error.

Note that mph tends to climb much more slowly than rpm, and the vehicle speed doesn't change a lot during a shift, so it tends to give more predictable shifts.

Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
Bernard Fife
Posts: 1696
Joined: Fri Apr 04, 2008 1:28 pm

Re: WOT odd shifting behaviors

Post by Bernard Fife »

Dave,

My post have above is all 'true', but a bit contrived. That bugged me, so I have been trawling through the code, and I may have found some issues with the rev limiting code (whether or not I have fixed them is another thing...):
Monitor_5102vii.abs.s19
(84.55 KiB) Downloaded 545 times
GPIO_MShift_5102vii.ini
(297.48 KiB) Downloaded 547 times
Hopefully this 5.102vii test code will help (and maybe even work properly). It seems to work on my bench for the rev limiting (though this is surprisingly difficult to check on a bench because of the hysteresis and the fact that the rpm doesn't follow the shifts like it would in a real vehicle).

This code also has fixes from other threads, just as a 'heads-up'.

If you are willing to give it a try, that would be great (do so cautiously, as always).

Lance.
"Never wrestle with pigs. You both get dirty and the pig likes it." - George Bernard Shaw
Post Reply