MSgpio.com read only forums (Jan.15,2018)

gurov,

No, the slip isn't used for anything, it is just reported. That's partly because a lot of older trans don't have an ISS, and partly because with VSS and ISS averaging, the slip value isn't really reliable at any given moment. Then add potential signal issues on top of that, and it would get a bit dicey to use the slip for any concrete actions.

Lance.

Lance wrote:gurov,

No, the slip isn't used for anything, it is just reported. That's partly because a lot of older trans don't have an ISS, and partly because with VSS and ISS averaging, the slip value isn't really reliable at any given moment. Then add potential signal issues on top of that, and it would get a bit dicey to use the slip for any concrete actions.

Lance.

okay, that makes sense.

is the change that puts input shaft rpm as raw rpm and not a calculated permament ? i'd like to be able to see straight is_rpm, even with signal noise, i will be able to see if it's slipping and alert on that and analyze the logs from boost runs.

gurov,

The addition of is_rpm isn't permanent, but I could make it so. We are currently using 58 of the CAN 64 byte block. I tried to keep this small when we were having CAN blocking issues (a while ago, there is a thread on this). But these seem to be well sorted now. I can add is_rpm to the outpc and datalog, this will give us 60. Then we can add up to 2 more int or 4 more chars, or some combination of these.

This is without extending the CAN messaging to 2 blocks, or increasing the block size. However, we were running as much as 88 bytes and an 80 byte block at one time (removed were things that could be calculated - like is_rpm; or things of less immediate use - like the main loop counter, CAN message counter; or things that can be gathered with the CAN pass-through - vBatt, adv_deg, ic1_period (VSS), ic2_period (ISS), among others). So there is quite a bit of room for expanding.

If you (or anyone else) has ideas about which values would be most useful to include, I will consider adding those for the next code as well.

Lance.

i think i got what i needed out of the slip variable, as i've confirmed that i can keep the geartrain locked 100% to at least 7 psi 2500rpm and up, which is where i'm going to stop upping the boost for a little bit. originally my concern was that the TCC would not withstand that much torque input, but apparently now it can after i've serviced the trans and shimmed a pressure control spring valve.

so yes. i am keeping TCC locked until 160 kpa, with overboost at 155, spinning the turbo up to 150 kpa. i REALLY like this, it feels a lot less like an auto trans now, which is what i was going for from the start.

TCC unlocks at 30 mph, and drives well out of boost.

would it be possible to extend the PWM tcc apply/disengage to have the taper on both sides of the slope ? i'm not sure the KPA-based pwm engage is really useful for me, as i'd like to keep TCC locked above 30 mph. I'm more thinking of riding right around that 30 mph mark and engage-disengage there, so instead of a heavy hit, it's a smooth engagement and disengagement.

other than that. i just need to tune the gearshift tables, which i could potentially devise a clever log-analysis software, drive it in manual for a few days, and analyze the patterns of speed/kpa/target gear.

I am also able to finally read gear and mph in ms3 over CAN (i.e. using CAN VSS and CAN GEAR #, i had to change the default offset for gear to point to current gear instead of target gear in MS3 setup) there's probably some more transmission variables MS3 could pull off the GPIO for a more comprehensive logging ability (i.e. TCC locked, PC%, solstate, trans temp), but i will take that up with the MS3 devs in the future, all of this data is already in the outpc block.

Lance, i'd like to thank you for all the work you've put into this so far, this car would still be sitting in the garage and not driving if not for this code and the changes that were made over the past couple of weeks.

as far as IS_RPM being available in outpc, i think that should be the case, such that ms3 can grab it over CAN.

gurov,

I will definitely add is_rpm to the outpc structure (for datalogs, gauges, etc). I will also add the TCC PWM%.

Having the TCC PWM taper when coming off is a little bit tricky, because it some cases it needs to come off immediately if the brakes are applied. The code is simple, but the potential side-effects aren't 100% clear to me. Let me think about it a bit.

I will also add some code that will force the TCC to always lock if the above a user-specified speed and gear.

This will all be in 2.00C, likely to be out in the next day or two.

Lance.

Lance wrote:gurov,

I will definitely add is_rpm to the outpc structure (for datalogs, gauges, etc). I will also add the TCC PWM%.

Having the TCC PWM taper when coming off is a little bit tricky, because it some cases it needs to come off immediately if the brakes are applied. The code is simple, but the potential side-effects aren't 100% clear to me. Let me think about it a bit.

I will also add some code that will force the TCC to always lock if the above a user-specified speed and gear.

This will all be in 2.00C, likely to be out in the next day or two.

Lance.

i see what you mean about TCC PWM taper. i think that's actually a lesser issue for me anymore, properly tuning shift points will take care of this for me.

right now i am using straight columns of gears in the shift table:



so that's still needs tuning.

also, just so i am very clear on the way the table works.

in the above table, 3 to 4 shift, 3 is at 40, 4 is at 50, is that saying:

at 50 mph, upshift from 3rd to 4th, at 40 mph, downshift from 4th to 3rd ?

also, is the code supposed to pick up the "neutral" position ? whenever i shift into neutral, it keeps either the "reverse" state, or the forward gear state.

gurov,

Yes, you have the table correct (at least I think so, it's a long time since I did that bit, and would need to confirm it on the bench to be 100% certain). I do know that there is no interpolation in the shift table - that was an absolute necessity.

If the solenoids can select neutral, then the code should put them in that state when neutral is selected. It's possible I have that bit messed up (since the transmissions I tested on select neutral with the shift lever and not the solenoids). I will have a look.

Lance.

Actually, after thinking about this for a little, I think the table works a bit differently.

In your example, the 3-4 shift will be at 50 mph, AND the 4-3 downshift will also be at 50 mph. What the code does is look for the current bin using the current speed (and load, of course), and the 40 mph (or kph) column represents speeds from 40 to 49.9 (i.e, the next highest value that isn't covered in the next column), and the 50 is from 50 to 54.9, etc. So when you drop below 50.0 mph, you drop to the 40 column, and the target gear becomes 3.

When you are shifting to neutral, are you doing this with the shift lever (i.e. the "inputs") or are you trying using the paddle shifts? It won't shift from the forward gears using the paddle shift buttons. But it should do this using the shift lever. However, the code doesn't distinguish between Park and neutral, so that might be causing some issues in your case (and this can be fixed, of course).

Lance wrote:Actually, after thinking about this for a little, I think the table works a bit differently.

In your example, the 3-4 shift will be at 50 mph, AND the 4-3 downshift will also be at 50 mph. What the code does is look for the current bin using the current speed (and load, of course), and the 40 mph (or kph) column represents speeds from 40 to 49.9 (i.e, the next highest value that isn't covered in the next column), and the 50 is from 50 to 54.9, etc. So when you drop below 50.0 mph, you drop to the 40 column, and the target gear becomes 3.

When you are shifting to neutral, are you doing this with the shift lever (i.e. the "inputs") or are you trying using the paddle shifts? It won't shift from the forward gears using the paddle shift buttons. But it should do this using the shift lever. However, the code doesn't distinguish between Park and neutral, so that might be causing some issues in your case (and this can be fixed, of course).

not the paddles, i have no paddles yet. and i was not aware i could switch to neutral with paddles ?

my shift to neutral is between D and R, on the shift lever.

i am attaching the log and msq with me shifting into R , neutral and D a bunch. 800-900 rpm is either D or R, higher than 1000 rpm is neutral.

i'm mentioning this because the PC in neutral does not get set to the PC in neutral setting from the shift factors dialog.