Retard with MS3

[Bernard Fife]

gurov,

I think you are missing the point. The 2.111 code works, this is proven by the fact that it works fine with 2.905. The timing retard code couldn't work with that code unless the CAN mechanism underlying it was sound.

The fact that it works with 2.905 means:
- the CAN message is being sent by the MShift code,
- it is being sent in the agreed format based on the B&G protocol
- it is being sent to the user specified controller's CAN ID, block and offset (these are not hard-coded anywhere in the MShift code: it relies entirely on the user values),
- it is being received and properly implemented according to the B&G protocol.
If it isn't working in extra, it must be because either the extra CAN protocol has either been changed (deliberately or through a bug), or the ID/block/offset are incorrectly specified by the user. Both of those are issues to take up with the extra developers, there's nothing I can do about either of them.

2.111 source code has not been published, and won't be until the 2.xxx code is finalized (which won't be until all reported bugs are eliminated). As I said before, the CAN functions in the MShift code is exactly the same as Al uses in the 2.9XX B&G code, and I am sure James has seen that. However, there is no need for James to look at the MShift code at all, he needs to look at the MS3 code/settings - that's where the problem is. So talk to James, and get him to fix the MS3 code.

I don't know how to say that any more clearly, so I won't have any more to say about this since MS3 related code issues should be discussed at msextra.com, not here.

Lance.

[gurov]

gurov,

I think you are missing the point. The 2.111 code works, this is proven by the fact that it works fine with 2.905. The timing retard code couldn't work with that code unless the CAN mechanism underlying it was sound.

The fact that it works with 2.905 means:
- the CAN message is being sent by the MShift code,
- it is being sent in the agreed format based on the B&G protocol
- it is being sent to the user specified controller's CAN ID, block and offset (these are not hard-coded anywhere in the MShift code: it relies entirely on the user values),
- it is being received and properly implemented according to the B&G protocol.
If it isn't working in extra, it must be because either the extra CAN protocol has either been changed (deliberately or through a bug), or the ID/block/offset are incorrectly specified by the user. Both of those are issues to take up with the extra developers, there's nothing I can do about either of them.

2.111 source code has not been published, and won't be until the 2.xxx code is finalized (which won't be until all reported bugs are eliminated). As I said before, the CAN functions in the MShift code is exactly the same as Al uses in the 2.9XX B&G code, and I am sure James has seen that. However, there is no need for James to look at the MShift code at all, he needs to look at the MS3 code/settings - that's where the problem is. So talk to James, and get him to fix the MS3 code.

I don't know how to say that any more clearly, so I won't have any more to say about this since MS3 related code issues should be discussed at msextra.com, not here.

Lance.

i strongly disagree about not looking at the code, the two pieces of code are working together here. not looking to step on any toes, just want my trans to work right.

[Bernard Fife]

gurov,

Okay, if you think it is that important to compare what the two codes are doing, post a link to the latest ms3 code source files, and I will have a look in it for the CAN bugs when I get a chance.

It's worthwhile noting that the CAN code is not specific to MShift, and it is not written by me. Al Grippo writes it, and it is used for both CAN transmitting and receiving in all the codes. It sets the standard for how megasquirt devices ought to communicate. It has been extensively tested (with input and advice from Phil Tobin - the TunerStudioMS guru), and it has been proven to work very well. If the extra developers have changed the way the CAN code works, then it is up to them to either make sure it is 'backwards compatible' with the B&G CAN code, or work with Al to come up with a new standard (which Al would then send to me to incorporate into the MShift code). As far as I can tell this hasn't happened. I can't and wouldn't do anything about it on my own.

Lance.

[gurov]

gurov,

Okay, if you think it is that important to compare what the two codes are doing, post a link to the latest ms3 code source files, and I will have a look in it for the CAN bugs when I get a chance.

It's worthwhile noting that the CAN code is not specific to MShift, and it is not written by me. Al Grippo writes it, and it is used for both CAN transmitting and receiving in all the codes. It sets the standard for how megasquirt devices ought to communicate. It has been extensively tested (with input and advice from Phil Tobin - the TunerStudioMS guru), and it has been proven to work very well. If the extra developers have changed the way the CAN code works, then it is up to them to either make sure it is 'backwards compatible' with the B&G CAN code, or work with Al to come up with a new standard (which Al would then send to me to incorporate into the MShift code). As far as I can tell this hasn't happened. I can't and wouldn't do anything about it on my own.

Lance.

wait, before we go further.

in the timing adjustment menu, there's upshift/downshift retards and then 2 3 4 5 gear retard settings. are these applied only during a shift, or are the 2 3 4 5 gear retard values applied at all times ?

my testing method is: sit in parking lot, put car into drive with brake on, go to manual mode, up shift < --- in this case TS shows no different in data coming off MS3. speed = 0, rpm below 1000.

[Bernard Fife]

gurov,

There are upshift/downshift retards applied during a shift (to limit drive line shock and/or wheelspin) *and* in-gear retards to account for the reduced rpm rate of change in higher gears under load (i.e. gear based load retard - often used by drag racers, etc.). Both work in testing here.

So, for example' if you shift from 1st to 2nd, and the upshift retard is 10 degrees, and the second gear retard is 2 degrees, with a base timing of 20 you would see on the timing gauge:

- initially 20 degrees while in 1st before the shift,
- then 10 degrees (20-10) for the duration of the shift if the load is high enough (greater than the user setting),
- then 18 degrees (20-2) while in 2nd for as long as the load threshold was met.

I have tested this very extensively using both the gauges and a scope with MS-II, and it works. This is detailed here: http://www.msgpio.com/manuals/mshift/V2tune.html#ga

Lance.

[Bernard Fife]

gurov,

I will attach a short datalog to demonstrate this. MShift it set up with a 'retard only above' load of 90 kPa, upshift retard of 5.0º, downshift retard of 6.0º, 2nd gear retard of 1.0º, third gear retard of 2.0º and 4th gear retard of 3.0º. I was using MShift 2.111 and B&G 2.905 on MS-II. The only input changed was the VSS, and this forced shifts and thus timing as commanded by MS-II.

Look at the CAN1.cGear (current gear) and compare it to SparkAdv. The base timing is 20.1º, and you can see it drop to 15.1º on the 1-2 shift, then go to 19.1º. On the 2-3 shift it drops to 15.1º, then goes to 18.1º in third, and so on...

retard.msl

Lance.

[gurov]

gurov,

I will attach a short datalog to demonstrate this. MShift it set up with a 'retard only above' load of 90 kPa, upshift retard of 5.0º, downshift retard of 6.0º, 2nd gear retard of 1.0º, third gear retard of 2.0º and 4th gear retard of 3.0º. I was using MShift 2.111 and B&G 2.905 on MS-II. The only input changed was the VSS, and this forced shifts and thus timing as commanded by MS-II.

Look at the CAN1.cGear (current gear) and compare it to SparkAdv. The base timing is 20.1º, and you can see it drop to 15.1º on the 1-2 shift, then go to 19.1º. On the 2-3 shift it drops to 15.1º, then goes to 18.1º in third, and so on...

retard.msl

Lance.

i see.

are there are any lockouts based on speed for this ? manual shifting should still have the same procedure associated with this ?

[Bernard Fife]

gurov,

The only lock-out is load based, which is set by the user as inpram.Tretard_load.

The code checks if this is an upshift or downshift, and in the case of a downshift the code snippet looks like this:

Code: Select all

          // Send shift retard timing to MS-II
          if (outpc.LOAD > inpram.Tretard_load)
           {
           outpc.SpkAdj = inpram.dwnshift_retard;  // down shift
           if (inpram.CAN_enabled) sendCANAdj();  
           }

and there is no distinction between a manual or automatically commanded shift. In sendCANAdj(), the CAN buffer is set as follows:

Code: Select all

       can[1].cx_msg_type[jx] = MSG_CMD; 
       can[1].cx_datbuf[jx][0] = *((char *)&outpc.FuelAdj);
       can[1].cx_datbuf[jx][1] = *((char *)&outpc.FuelAdj + 1);
       can[1].cx_datbuf[jx][2] = *((char *)&outpc.SpkAdj);
       can[1].cx_datbuf[jx][3] = *((char *)&outpc.SpkAdj + 1);
       can[1].cx_datbuf[jx][4] = *((char *)&outpc.IdleAdj);
       can[1].cx_datbuf[jx][5] = *((char *)&outpc.IdleAdj + 1);
       can[1].cx_datbuf[jx][6] = *((char *)&outpc.SprAdj);
       can[1].cx_datbuf[jx][7] = *((char *)&outpc.SprAdj + 1);
       // Put FuelAdj, etc in ECU, in2ram.FuelAdj, etc.
       can[1].cx_destvarblk[jx] = inpram.Adj_blk;
       // below is offset of FuelAdj, etc from start of in2ram in ECU
       can[1].cx_destvaroff[jx] = inpram.Adj_varoffset;
       can[1].cx_dest[jx] = inpram.ms2canID;		// send to ECU (board 0)
       can[1].cx_varbyt[jx] = 8;	 // sending 8 bytes (4 words)

The two bytes of the SpkAdj are loaded into can[1].cx_datbuf[jx][2 and 3]. The inpram.ms2canID, inpram.Adj_blk, and inpram.Adj_varoffset are the user values for the MS-II/MS3 CAN ID, MS-II/MS3 in2ram block, and MS-I/MS3 variable offset specified by the user in the 'CAN Configuration' under 'Tools'. So there's not a lot to go wrong there.

Lance.

[gurov]

okay.

so ms3's block 7 is shared in this case...

Code: Select all

                   // special case for receiving CAN data
                    if (var_blk == 7) {
                        if (var_off >= 0x200) { // datax1 sharing same block no. as outpc
                            var_off -= 0x200; // but at addresses 0x200 and beyond
                            if ((var_off + var_byt) > sizeof(datax1)) {
                                flagbyte3 |= flagbyte3_can_reset;
                            } else {
                                dest_addr = (unsigned int) &datax1;
                            }
                        } else {
                            if ((var_off + var_byt) > sizeof(outpc)) {
                                flagbyte3 |= flagbyte3_can_reset;
                            } else {
                                dest_addr = (unsigned int) &outpc;
                            }
                        }

var offset being given is 630, 630 - 512 = 118, so &(datax1 + 118) would be the start of the 8 byte block

[gurov]

it's just this particular feature that's not working.

ms3 grabs gear number, speed, trans temperature from gpio.
gpio grabs tps, rpm, map from ms3 fine.

there's some disconnect in the writing to ms3 that's happening here.