Controlling a Subaru DCCD differential

[masterx81]

I'm studiyng how can be controlled a subaru DCCD (and maybe others...) electronic differential. The differential is a simple coil, energized by a 100hz signal with variable duty. More is the duty and more is the lock of the differential.
On the OEM system the control can be manual (the driver select via a 6 position switch the lock) from dc 0% to 100% dc, or "auto". In "auto" the ecu use the following sensors: accelerometer/yaw, vss, parking brake, brake switch, tps and rpm for try to determine the best suited lock for the differential. Seem that also uses the vss of the single wheels to determine the slip rate of fwd vs rwd wheels.
Mosft aftermarket controllers uses a map similar to this:

where you input simply a dc in the main map, then there are other sub-maps as "modifiers" of the main map.
when the parking brake is pulled the dc goes to 0.
Can be implemented as a spare can controller, but would be nice to integrate it on the iox as it has already all the info needed (via direct connection to sensors or via can)...
Will be possible?
Thanks!

[jbelanger]

That looks doable but I'd have to check if that could be integrated in the IOx or if it would require a dedicated CPU.

Jean

[masterx81]

It may use the interpolation functions already in the code, the only big requirement i think that will be of ram, that commercial controller that i've used as example uses 3 tables 10x10 of 1 byte data (dc can go from 0 to 100% on main table and -100/+100 on "modifier" tables), plus 2 10 byte tables, so for every map we need 330bytes of ram.
This will be a really nice addition...

[tpsretard]

right now i use a simple PWM table, tps v/s rpm.

It works, But it less than adequate. it really needs the use of the acceleromitor and VSS.

[jbelanger]

So do you think that something like what is shown above would be fine or do you have other ideas on how it could be? If I'm going to implement something, it would be good to have the best possible solution (within the CPU's constraints).

Jean

[tpsretard]

It would be amazing if it could be done. I have one, the rally car has one, and 2 other road cars i work with have them also. and i know there are more out there..
It would also open the option for the Nissan Attezza 4wd system also.

The throttle map is as sounds.
The throttle modifier map uses an acceleromiter for lateral g's => The slower you are going and the more lateral g (steering input) you do, the more you want to unlock (lower or subtract duty) the diff to prevent under steer.

the braking modifier map is the one hidden by the pull down menu. this locks the diff more when the car dives under braking to keep the back wheels from locking and the car stable.

These are the important ones to have.

[jbelanger]

I have had a look at this and I think that the best option for me would be to make a dedicated firmware version that would only do the diff control and would initially run on the TinyIOx hardware. Later there could be a dedicated hardware platform with all the needed input and output circuits but using the same CPU and firmware.

In both cases, this could either be a CAN device with an MS2 or MS3 based ECU or a completely independent unit. In the latter case, the serial port would be used to communicate between the unit and a PC for configuring the device through TunerStudio. When used as a CAN device, the configuration would use TunerStudio in CAN passthrough as is currently done with the TinyIOx; the serial port could also be used in the same way as the independent unit.

With that in mind, I tried to see what that could look like using the TunerStudio GUI. There are serious limitations to what can be done (or I need to contact the TS guys and see if I'm missing something or if they want to add something to make it easier). So the picture below gives an idea of what the main setting window would look like. And note that there is no code currently done; this is just a preliminary attempt at what the user interface and different options could be.



The maps are around the same location as they are in the picture in the first post but it's not as pretty. You also have the same options to enable the different maps and modifiers. You can see that you can select one accelerometer or gyro axis for the modifier maps.

The picture below gives you an idea of what the different input ports would be and you would be able to select which physical port to use for each either on the unit hardware or from an MS over CAN.


RPM drop-down: this could use one of the timer port and a tach signal (not a toothed wheel signal but a basic trigger or tach output) or use the MS RPM over CAN.


VSS drop-down: this could use one of the timer inputs with a VSS signal or a combination of 2 timer inputs (left and right wheel speeds for example) or an MS3 VSS input.


Accel drop-down: this can use one of the analog inputs and an analog accelerometer, an I2C accelerometer (I intend to add support for the 6-axis accelerometer/gyro MPU-6050), or the MS3 accelerometer data (I'm not sure this last one would be a good option due to the CAN bus latency).


As I said, there is no code implemented for this at all. But I would like to keep this going and have some feedback on what you see there. As I said, I'm limited in how this is presented in the user interface and will see if I can make this better. So I'm mostly looking for feedback and comments on the rest. And the intent is to have from 4 to 8 maps that the user could switch between using either a rotary button (with analog or digital inputs) or something in the user interface either statically or dynamically.

Jean

[tpsretard]

ok if you are willing to give this a real try, and not just a hack. there are some features that are needed.

It is sometimes disierable to turn the auto setting off and use the manual factory thumb switch. or just a 1k pot.
There are also some lights. it is a display on the dash that shows what it is doing and if it is working.

I do not know if the tinyIOx has the needed pins todo it all. If you want to make it a standalone controller, i do not mind doing the board testing and work to see if we can make this a real product.

here is a schematic of how it is connected.

[jbelanger]

There are enough I/Os for the thumb wheel (or a pot) and the lights. I would need to know what the connections are as this is not obvious from the diagram. Is the thumb wheel a pot? If so that's simply 5V, signal and ground but in which order? Or is that a couple of switches with one for up and one for down? As for the lights, are those 12V bulbs or LEDs or something else? Also, is that a ground that is needed to switch them on or 5V or 12V or something else?

One thing that I don't see there is how the auto mode is switched on and off. Is it through the thumb wheel which clicks off at one end or is it an additional button somewhere? One other possibility with what I had in mind would be to have a 'manual' position for the rotary switch in addition to a position for all the programmable maps.

You also mentioned the Nissan system. Would that be similar or are there some significant difference? It would be good to know if it is possible to plan for both with a single hardware and firmware version.

Jean

[tpsretard]

The thumb switch is just a simple, everyday pot, just in a snazzy case, so as you said, 5v, gnd and signal
The auto manual switch can be an aftermarket switch or a subaru factory option. The factory option has 5 pins, but i know we only use 4 pins with the gems, ground switch and to light a light.

there is also a handbrake overide input that disables the output for while it is pulled or for a few 100milliseconds, this is to allow you to hand brake the car around a corner.

The display uses 7 led's on late factory clusters and 6 on early, the 7th light for the new one is for the lock light, indicating the diff is fully locked up. (undriveable at low speeds) The old ones are 12v switched lights. the new are led. however they are all common anode. i was figuring a few N-Chan mosfets (sot223's) would be nice. or if you know of a nice darlington driver that will do the task of both.

I could get hold of the factory yaw sensor, if needed. (might be nice to get that to work as an option) but i was thinking something like a ADXL335. I was thinking a 3 axis or if there is, a 2 axis unit as you will need that for the braking modifier.

The dccd coil now. there are 2 versions, old and new. The older ones have a bit higher resistance about 4 ohms. the new ones are about 2 ohms. both negative switched. figured something like a BIP373 or an IRF510 can be used.

The Nissan system is for the R32, R33 and R34 Skyline GT-R's. It is called ATTESSA. It is a hydrolic design, but uses a fast PWN solonoid. so it works almost the same way. More duty means more front bias. however the Nissan system can go totally rear wheel drive. The sti is "supposed" to keep a small amount of duty on the diff as it burns up the stock clutch's. but non of the aftermarket controllers do that. (well, that i know of)

The stock ecu checks to see if the coil is good. it does this by measuring its current, to know if it is over or under the limits.

So....

9 outputs (1 of them high current)
7 inputs, one of them being VSS

Can't forget about the CAN connections also

[jbelanger]

Ok, so the inputs are (ignoring the CAN values which could be a possibility for all of them one way or another):

• 1. thumb switch: analog
  2. Auto/Manual switch: digital or analog (for selecting which map to use in auto mode)
  3. TPS: analog
  4. RPM: timer
  5. Brake: analog or digital
  6. Handbrake: digital
  7. VSS: timer (possibly more than one channel)
  8. Accelerometer: analog (possibly more than one channel) or I2C (see below)

The outputs are:

• 1. DCCD coil: timer, high current grounding
  2-8. Lights: digital, medium current grounding

I seem to have counted more inputs and fewer outputs. What am I missing?

The TinyIOx has 6 timer I/Os, 9 ADC inputs, 2 generic digital I/Os and one I2C port; the timer and ADC pins can also be used as generic digital I/Os. I'd rather use the I2C port for the accelerometer since this can be used for 6 axes: 3 accelerometer, 3 gyro. The MPU-6050 is now available in very cheap modules (http://www.ebay.ca/itm/171065014219) and it makes sense for me to support it as it also optimizes the use of the available I/Os. That module would also give you the yaw data instead of using the factory sensor (but I'd be interested of having more information about that sensor).

So that would mean that the I/Os could:
timers (6): RPM, VSS (up to 4) and DCCD coil
ADCs (4): thumb wheel, switch, TPS, brake
digital (8): handbrake, lights (7)

Counting shows that there's one I/O missing on the TinyIOx. This could be solved by limiting the number of VSS inputs so that if 7 lights are used you only have up to 3 VSS inputs. In other words, one timer pin would be used as either a VSS input or a digital output; all the other pins would have a fixed function. That's assuming that my I/O count is correct.

If there is a need to constrain the duty cycle so that it doesn't go below a certain minimum, that's very much doable with a user-defined threshold (which could well be put at 0 if the user doesn't care about their clutch). And the effect of the handbrake can also be user defined by either simply disabling the output or disabling it for a certain amount of time (again user-defined).

I'll have to check if there is a cheap way of measuring the current to check the coil condition. I also have to see how that would work with a PWM signal although at 100 Hz it's slow enough that it may not be an issue. But that would take up one more ADC input which would mean one fewer VSS input once I shuffle the I/Os around.

Jean

[tpsretard]

Wow yup, i was tired clearly. You have inputs that should have been there. i missed them, sorry.

I forgot to count the RPM and TPS.

I do not see a point in having more than one VSS, unless you want to calculate the slip angle and use that to bias the center diff. This is how it is done on the newer cars. All though we will the ABS we keep the sensors as they go to the ecu, but it has to be 4 inputs. In light of this. i think we should just keep it to one VSS input.

I like that module, should not be hard to work with. i Like the idea. i will hunt around and see if i can find any data on the stock Subaru sensor for you.

I think it is important to measure current, i have had 2 coils burn up on me in the passed. happened in transit to a rally stage, if it did not warn me, it would not of ended well for the driver.

[jbelanger]

I had a quick look and I think that using a Hall effect current sensor would work and would not be very expensive: http://www.digikey.ca/product-detail/en ... ND/2470597. And making the measurement during the on period of the signal would also not be an issue as long as the duty cycle is not too close to zero. From that the user could select the valid range for the current and outside that range an output would be turned on.

That means 2 additional I/Os: one ADC input and one digital output for a check light. So taking into account your comment about needing a single VSS input, my previous list would then be:

Inputs:

• 1. thumb switch: analog
  2. Auto/Manual switch: digital or analog (for selecting which map to use in auto mode)
  3. TPS: analog
  4. RPM: timer
  5. Brake: analog or digital
  6. Handbrake: digital
  7. VSS: timer
  8. Accelerometer: I2C (MPU-6050)
  9. Coil current sensing: analog

Outputs:

• 1. DCCD coil: timer, high current grounding
  2-9. Lights: digital, medium current grounding

With the resulting I/O assignments:
timers (3): RPM, VSS, DCCD coil
ADCs (5): thumb wheel, switch, TPS, brake, coil current
digital (9): handbrake, lights (8)

This fills up all the available pins on the TinyIOx. That means the user would only have to choose whether the input is coming from a local pin or from a CAN bus device (MS2 or MS3) and the different settings as discussed.

Jean

[tpsretard]

i like that sensor. i have used it many times and many different projects.

we do not need a check light, we will just flash the bottom light in the cluster, on and off, 500ms gap i think is what the stock one does. so we have one free I/O

have any good idea of what we should use for the drivers. This weekend i can drive my spare dccd coil to full saturation to see what current level we are dealing with.

But the low current outputs. and good ideas.?

[masterx81]

And simply measuring tension on the fet side? If the coil is burned we never have 12v while the coil is turned off. Obviously not work with high duty.
I like the idea to use the tinyiox

[tpsretard]

The problem with that is it will not protect against a shorted coil.

Never happened to me vut have seen it happen a few times. Not nice outcomes.

[masterx81]

Uhm, 2 way analog multiplexer, when pwm is off sensing tension on fet side, when pwm is on sensing current. Or 2 separated analog inputs...

[masterx81]

For driving the coil, vnd10n06? it's the same as the vnd05 used for injector in ms3x, but capable of 10a.

[tpsretard]

i like the idea of the hall sensor, they are cheap, reliable and easy to monitor and you would be able to log real time current, you will then be able to see if something is about to go wrong with the coil and this also only uses one ADC

the vnd10n06 should be capable, but i was thinking the BIP373 as it is a perpous built coil driver with thermal and current limit protection. it can also sink 11amps before the over current limit is tripped.

[jbelanger]

The BIP373 is an ignition coil driver; that's different from other coil types. I prefer the VND14NV04 which has thermal and over-current protection and much lower 0.035 Ohm RDSon. I also think the hall sensor is the best option for the same reasons. I still need to check what could be used for the lights other than small discrete components.

Jean