It should show mph/kph correctly based on your settings.
Here is a new INI with the pulse per mile/km setting fixed:
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.
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.
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).
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,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.
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:
- During the pressure adjustment delay (a delay before the shift solenoid states are changed, to allow any line pressure adjustments to occur) and
- 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 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.
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...):
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).