ABS on track / competition car?
Discussion
Fastdruid said:
Actually IIRC the RX-8 is just a simple voltage jobbie. I'll try and dig out the manual with it all in. As max_torque says though it's not the best way.
That would make sense on a yaw sensor, but the speed sensors will be working from the toothed ring on the hub and generating a pulse as each tooth comes past (or at least that's my basic understanding). So changing frequency would be the thing being monitored, rather than voltage.All a bit too "heath robinson" for this application perhaps.
Max_Torque said:
Gen1 SAS and YAW sensors were analogue devices, and so quite easy to modify their output. Gen2 devices have pretty much all moved over to CAN output, so a bit trickier to fiddle with (still fairly easy to do however)
The issue i have with fudging the input signals only is twofold:
1) You don't really know what effect you are having on the control system ultimately
2) You still need to provide the std system will all it's normal inputs, and this is a large task for an aftermarket device. There must be a market for track/kit cars (like caterhams/Ultimas etc) where the owners would like that safety net of ABS (which you can easily turn off). Now that the latest systems are down to only a few Kg in weight, this looks to be an attractive option to me?
I seriously looked into doing it (I'm building a GT40 replica kit car). In the end I decided unless I could reprogram the parameters it wasn't worth it. I do still have two ECU's to play with though (and all sensors apart from the 'combined sensor' (yaw+roll)) and would like to keep playing but building the car is taking all my time, I've had no time to play!The issue i have with fudging the input signals only is twofold:
1) You don't really know what effect you are having on the control system ultimately
2) You still need to provide the std system will all it's normal inputs, and this is a large task for an aftermarket device. There must be a market for track/kit cars (like caterhams/Ultimas etc) where the owners would like that safety net of ABS (which you can easily turn off). Now that the latest systems are down to only a few Kg in weight, this looks to be an attractive option to me?
WRT communicating with the ABS ECU, the documentation on the Bosch ABS M4 went into details on to lots of the outputs from that, the 'common' ABS ECU I believe does most of the same (with different ID's), however I believe that communication *to* the ECU is K-line.
Anyway, just ABS would be simpler, it might even work without any changes but unless you can 'tune' it you run the risk of *increasing* braking distances.
Munter said:
Fastdruid said:
Actually IIRC the RX-8 is just a simple voltage jobbie. I'll try and dig out the manual with it all in. As max_torque says though it's not the best way.
That would make sense on a yaw sensor, but the speed sensors will be working from the toothed ring on the hub and generating a pulse as each tooth comes past (or at least that's my basic understanding). So changing frequency would be the thing being monitored, rather than voltage.All a bit too "heath robinson" for this application perhaps.
Krikkit said:
Max_Torque said:
/geek ;-)
Epic post. Are you a systems engineer Max?I've spent very nearly 20 years now (time flies!) doing powertrain and controls engineering, including a lot of benchmarking / reverse engineering other peoples systems!
The lastest systems use two mode current output wheel speed sensors, that output 7mA /14mA depending on if they are over a "mark" or "space" on the target wheel, and the duty cycle of the pulse train also depends upon rotational direction (so the system can tell if you've spun and are now going backwards!) Even so the data rate is actually pretty low, typical 48teeth, so that's only ~1.7KHz @ 250kph. By outputting current at all times(even when wheels aren't turning system fault diagnosis becomes easy.
For basic ABS only operation, the vehicle interface requirements are generally pretty minimal:
1) Brake pedal switch (usually same as turns on brake lights)
2) Optional brake pressure sensor input (later modules have this integrated)
3) Fault lamp output
On early systems all that was hardwired to the rest of the car, later systems have moved over to a serial bus (CAN) architecture to reduce loom mass and complexity etc
For TCS/DSC/BAS then you need a whole lot more
1) SAS
2) YAW + Lat/Long accel
3) Engine torque from EMS (both current value and returning a demanded control value for TCS "torque down" or DSC "torque up" events)
4) Brake pedal position (for brake assist)
My interest is to find out if it is possible to take one of the simpler systems and appropriate it for aftermarket use etc
1) Brake pedal switch (usually same as turns on brake lights)
2) Optional brake pressure sensor input (later modules have this integrated)
3) Fault lamp output
On early systems all that was hardwired to the rest of the car, later systems have moved over to a serial bus (CAN) architecture to reduce loom mass and complexity etc
For TCS/DSC/BAS then you need a whole lot more
1) SAS
2) YAW + Lat/Long accel
3) Engine torque from EMS (both current value and returning a demanded control value for TCS "torque down" or DSC "torque up" events)
4) Brake pedal position (for brake assist)
My interest is to find out if it is possible to take one of the simpler systems and appropriate it for aftermarket use etc
Max,I have just been replacing an abs module in a BMW 1 series(quite common pressure sensor failure on 1 and 3 series)but it had me thinking about this and I wondered about increasing the amount of teeth the sensor reads.
Obviously it would fool the controller into reading a faster than actual wheel speed
moving the point of interaction and should therefore allow more power to be applied at the same time.
How you would determine the optimum amount of teeth is beyond me an would probably require a certain amount of trial and error for each application but would this not be a viable way of tricking it?
Obviously it would fool the controller into reading a faster than actual wheel speed
moving the point of interaction and should therefore allow more power to be applied at the same time.
How you would determine the optimum amount of teeth is beyond me an would probably require a certain amount of trial and error for each application but would this not be a viable way of tricking it?
^^^^ not really a sensible idea unfortunately.
Changing the tooth number will indeed offset the measured wheel speed, and result in the system reading the "wrong" areas of it's maps. Unfortunately, you don't know if the settings for any given speed are "better" than any other, and there are a number of critical "mode" changing speeds that would be also modified (for example, the speed at which abs is suspended (better to lock wheels at very low speed < ~7mph, or the point at which TCS becomes a throttle only effect (rather than brake the spinning wheel etc). Added to which your instrument cluster will now read the wrong speed, and you are likely to get an error in the EMS (which calc road speed by NOVS calc) etc
There is also the issue of tooth timer resolution and max/min counts to deal with (max/min freq of wheel sensor input signal)
Changing the tooth number will indeed offset the measured wheel speed, and result in the system reading the "wrong" areas of it's maps. Unfortunately, you don't know if the settings for any given speed are "better" than any other, and there are a number of critical "mode" changing speeds that would be also modified (for example, the speed at which abs is suspended (better to lock wheels at very low speed < ~7mph, or the point at which TCS becomes a throttle only effect (rather than brake the spinning wheel etc). Added to which your instrument cluster will now read the wrong speed, and you are likely to get an error in the EMS (which calc road speed by NOVS calc) etc
There is also the issue of tooth timer resolution and max/min counts to deal with (max/min freq of wheel sensor input signal)
There's two possibly interesting BMW systems, the first is the Group N ABS from the E36s, it used the standard controller, but using a different program, so basically a factory remap.
The other interesting one is the later E46 M3 DSC modules. A one size fits all version was made, so the later road cars have the M Track mode from the CSL built in, but switched off in coding.
It can now be switched on via the DSC button, and an all new M track light will appear on the dash. I think the M track mode is only a relaxing of the stability side, and the ABS is held at regular levels, but it'd probably be better to see what it says in the manual.
The other interesting one is the later E46 M3 DSC modules. A one size fits all version was made, so the later road cars have the M Track mode from the CSL built in, but switched off in coding.
It can now be switched on via the DSC button, and an all new M track light will appear on the dash. I think the M track mode is only a relaxing of the stability side, and the ABS is held at regular levels, but it'd probably be better to see what it says in the manual.
I did some reading up when I was considering ABS and to my mind the only way is to be able to re-program the ABS ECU.
I'm sure max_torque knows more about this than me but for everyone else there are a number of parameters that the ABS ECU stores, ignoring DSC/EBD etc the main two (and the second one is actually made up of a number of parameters) to my mind are:
1) Maximum possible deceleration
2) Brake characteristics.
Basically modern ABS does not 'just' detect a locked wheel, it constantly monitors wheel speed and if it detects that a wheel is decelerating faster than it believes is possible, well, well before it locks, it isolates that circuit (so to prevent pulsing in the pedal) and releases pressure, just enough (and this is where the brake characteristics comes in) to let the wheel re-accelerate up to the speed it feels it should be, once back up to speed it then re-pressurises that circuit (this is where the pump comes in) and un-isolates it. This then keeps going until a low limit (say something like 5mph) at which point it stops working.
The issue with transferring from one vehicle to another is that those parameters are screwed, even changing wheels/brakes will screw them up, Audi for example (and it's probably common across the VAG range) do it by having multiple configs stored in the ECU, if you replace the ABS ECU you have to log onto it and 'tell' it which model with which brake setup you have. This is the way for example the monster braked massive wheel RS4 can share an ABS ECU across the range with the S4 and plain cooking A4. In addition you have to 'pair' it with your powertrain ECU but that is for the DSC/TCS/eDif functions.
If your 'maximum possible deceleration' is wrong then it will either prevent the ABS from kicking in until its too late (so lots of locking up) or it will kick in too early (so restrict the maximum deceleration).
If your 'brake characteristics' are wrong then the ECU will either waste cycles bleeding additional pressure and adding additional pressure to either get the wheel to stop slowing down or to re-accelerate it, or it will over release pressure, let the wheel accelerate too much and have to re-apply pressure. Either way it will increase braking distance.
Now there *is* some learning going on with these systems but AFAIK its not 'saved' so has to be re-learnt every power on.
I personally think don't its possible to offer an off the shelf re-branded aftermarket ABS system without either altering the code to turn it into a learning ECU or unless it's of the Bosch ABS M4 variety which requires careful programming of the car characteristics. I'd love to be proved wrong though.
Going back to making it more suitable for track use what you really need to do is alter the "maximum deceleration" value" and ideally be able to alter that on the fly to offer a 'range' of settings. Potentially you could do that by some additional hardware which could alter the held values on the fly (or at worst after a reset). Now that I do think is doable *if* you can find the value on the eeprom.
I'm sure max_torque knows more about this than me
but for everyone else there are a number of parameters that the ABS ECU stores, ignoring DSC/EBD etc the main two (and the second one is actually made up of a number of parameters) to my mind are: 1) Maximum possible deceleration
2) Brake characteristics.
Basically modern ABS does not 'just' detect a locked wheel, it constantly monitors wheel speed and if it detects that a wheel is decelerating faster than it believes is possible, well, well before it locks, it isolates that circuit (so to prevent pulsing in the pedal) and releases pressure, just enough (and this is where the brake characteristics comes in) to let the wheel re-accelerate up to the speed it feels it should be, once back up to speed it then re-pressurises that circuit (this is where the pump comes in) and un-isolates it. This then keeps going until a low limit (say something like 5mph) at which point it stops working.
The issue with transferring from one vehicle to another is that those parameters are screwed, even changing wheels/brakes will screw them up, Audi for example (and it's probably common across the VAG range) do it by having multiple configs stored in the ECU, if you replace the ABS ECU you have to log onto it and 'tell' it which model with which brake setup you have. This is the way for example the monster braked massive wheel RS4 can share an ABS ECU across the range with the S4 and plain cooking A4. In addition you have to 'pair' it with your powertrain ECU but that is for the DSC/TCS/eDif functions.
If your 'maximum possible deceleration' is wrong then it will either prevent the ABS from kicking in until its too late (so lots of locking up) or it will kick in too early (so restrict the maximum deceleration).
If your 'brake characteristics' are wrong then the ECU will either waste cycles bleeding additional pressure and adding additional pressure to either get the wheel to stop slowing down or to re-accelerate it, or it will over release pressure, let the wheel accelerate too much and have to re-apply pressure. Either way it will increase braking distance.
Now there *is* some learning going on with these systems but AFAIK its not 'saved' so has to be re-learnt every power on.
I personally think don't its possible to offer an off the shelf re-branded aftermarket ABS system without either altering the code to turn it into a learning ECU or unless it's of the Bosch ABS M4 variety which requires careful programming of the car characteristics. I'd love to be proved wrong though.
Going back to making it more suitable for track use what you really need to do is alter the "maximum deceleration" value" and ideally be able to alter that on the fly to offer a 'range' of settings. Potentially you could do that by some additional hardware which could alter the held values on the fly (or at worst after a reset). Now that I do think is doable *if* you can find the value on the eeprom.
Fastdruid said:
A lot of well put points......
Going back to making it more suitable for track use what you really need to do is alter the "maximum deceleration" value" and ideally be able to alter that on the fly to offer a 'range' of settings. Potentially you could do that by some additional hardware which could alter the held values on the fly (or at worst after a reset). Now that I do think is doable *if* you can find the value on the eeprom.
The key issue is that the maximum deceleration value for a rally car will change when it is on tarmac, to when it is on gravel, to when it is on ice, not just because of the mu levels, but also the suspension settings used including spring rates, ride heights and geometry effects. They all require unique calibrations to optimize the function on those surfaces. Going back to making it more suitable for track use what you really need to do is alter the "maximum deceleration" value" and ideally be able to alter that on the fly to offer a 'range' of settings. Potentially you could do that by some additional hardware which could alter the held values on the fly (or at worst after a reset). Now that I do think is doable *if* you can find the value on the eeprom.
It may be too complex a project for all but the most expert of teams.
To asnwer a couple of questions / points raised:
The point of ABS is to keep the longitudinal tyre slip value during braking at the optimum point. So what is the optimum point? Well, see graph:
In effect, for a given surface, there is a single slip value at which the tyre can provide the maximum retardation (i'm ignoring cornering/ESP for now)
The issue for the older style ABS systems was determining what the true longitudinal velocity of the car was during ABS brake events. During normal drivig (no braking or excess acceleration) the system just averaged all 4 wheel speeds. But during heavy braking with ABS, these speeds diverge from the true speed of the vehicle (imagine on sheet ice, where allk 4 wheels lock immediately you hit the brake pedal!) and so the system must now estimate the true speed (it is actually measuring wheel speed, so no problems with accuracy there, but it must know the true speed to determing the difference).
To overcome this, most systems moved towards a "wheel decceleration" based system. In effect they just assume that there is a maximal decceleration of the wheels that can ever be achieved (say car pulling ~1g deccel on clean dry concrete surface), and any greater decceleration must be caused by impending wheel lock up. These system just use a basic closed loop control on wheel decceleration, making control simple and easy. The problem of course is that you might actually be on a wet oily smooth tarmac road and the basic decceleration programmed into the system would be far too great for the actual vehicle deccel availible.
Luckily for all, increasing demand for ESP systems mean't that pretty much everycar now has a combined yaw gyro/accelerometer built in. So, whilst longitudinal accel is less than a certain value determined not to produce significant wheel slip (either accel or deccel) the system calculates its refference vehicle speed from the average of 4 wheel sensor inputs, but when you start braking the system blends in an "inertial" speed estimate derrived from the Long Accel sensor. Over the long term, integration errors would make this diverge from the true velocity, but during the relatively short brake event (cars now stop from 100mph in <5sec!) this calculated value is plenty accurate enough. Now, for the first time the system can accurately calculate the true value of wheel slip, and hence control it much much better. Of course, the determination of what slip % to target still exisits and the latest systems adapt for surface friction (They know the brake torque at which wheels start to slip (from the brake pressure sensor) and/or the engine torque at which the wheels slip when accelerating, and calculate an adaptive mU value to suit)
The final point is one of stability vs decceleration. Imagine a non abs car on a "split mu" surface (both lhs wheels on dry tarmac, both rhs wheels on ice (worst case!)).
When you brake, the rhs pair of wheels immediately lock, and provide just about no longitudinal force, but the lhs wheels bite into the clean grippy surface and for the same hydraulic pressure generate a massive deccel force. But, this only acts on the lhs of the car, which causes an enormous yaw moment, resulting in the car spinning off towards the left. Early systems that could NOT measure the drivers intended trajectory (via Steering Angle Sensor) and the vehicles actual trajectory (via Yaw sensor) simply had to "select low". What that means is to avoid a loss of control event, they also reduce the brake force on the grippy wheels to a similar value to that of the slippy wheels. This remove the yawing moment, but obviously massively increases stopping distance because the total brake force is reduced (and it is also why old ABS systems had that disconcerting feeling of being "locked out" of the brakes if one wheel hit a bump etc during hard braking). The latest systems DO know what is occuring, and can modulate the balance between stability and stopping distance much much better (because they can brake hard right up until stability IS compromised and only then reduce the brake torque).
However, even with this capability, the typical OEM road calibration will always er towards stability as it's primary objective. The calibration of a racing system can allow for a much more skilled driver, one who themselves can account for yaw events via adjusting their handwheel inputs etc
The point of ABS is to keep the longitudinal tyre slip value during braking at the optimum point. So what is the optimum point? Well, see graph:
In effect, for a given surface, there is a single slip value at which the tyre can provide the maximum retardation (i'm ignoring cornering/ESP for now)
The issue for the older style ABS systems was determining what the true longitudinal velocity of the car was during ABS brake events. During normal drivig (no braking or excess acceleration) the system just averaged all 4 wheel speeds. But during heavy braking with ABS, these speeds diverge from the true speed of the vehicle (imagine on sheet ice, where allk 4 wheels lock immediately you hit the brake pedal!) and so the system must now estimate the true speed (it is actually measuring wheel speed, so no problems with accuracy there, but it must know the true speed to determing the difference).
To overcome this, most systems moved towards a "wheel decceleration" based system. In effect they just assume that there is a maximal decceleration of the wheels that can ever be achieved (say car pulling ~1g deccel on clean dry concrete surface), and any greater decceleration must be caused by impending wheel lock up. These system just use a basic closed loop control on wheel decceleration, making control simple and easy. The problem of course is that you might actually be on a wet oily smooth tarmac road and the basic decceleration programmed into the system would be far too great for the actual vehicle deccel availible.
Luckily for all, increasing demand for ESP systems mean't that pretty much everycar now has a combined yaw gyro/accelerometer built in. So, whilst longitudinal accel is less than a certain value determined not to produce significant wheel slip (either accel or deccel) the system calculates its refference vehicle speed from the average of 4 wheel sensor inputs, but when you start braking the system blends in an "inertial" speed estimate derrived from the Long Accel sensor. Over the long term, integration errors would make this diverge from the true velocity, but during the relatively short brake event (cars now stop from 100mph in <5sec!) this calculated value is plenty accurate enough. Now, for the first time the system can accurately calculate the true value of wheel slip, and hence control it much much better. Of course, the determination of what slip % to target still exisits and the latest systems adapt for surface friction (They know the brake torque at which wheels start to slip (from the brake pressure sensor) and/or the engine torque at which the wheels slip when accelerating, and calculate an adaptive mU value to suit)
The final point is one of stability vs decceleration. Imagine a non abs car on a "split mu" surface (both lhs wheels on dry tarmac, both rhs wheels on ice (worst case!)).
When you brake, the rhs pair of wheels immediately lock, and provide just about no longitudinal force, but the lhs wheels bite into the clean grippy surface and for the same hydraulic pressure generate a massive deccel force. But, this only acts on the lhs of the car, which causes an enormous yaw moment, resulting in the car spinning off towards the left. Early systems that could NOT measure the drivers intended trajectory (via Steering Angle Sensor) and the vehicles actual trajectory (via Yaw sensor) simply had to "select low". What that means is to avoid a loss of control event, they also reduce the brake force on the grippy wheels to a similar value to that of the slippy wheels. This remove the yawing moment, but obviously massively increases stopping distance because the total brake force is reduced (and it is also why old ABS systems had that disconcerting feeling of being "locked out" of the brakes if one wheel hit a bump etc during hard braking). The latest systems DO know what is occuring, and can modulate the balance between stability and stopping distance much much better (because they can brake hard right up until stability IS compromised and only then reduce the brake torque).
However, even with this capability, the typical OEM road calibration will always er towards stability as it's primary objective. The calibration of a racing system can allow for a much more skilled driver, one who themselves can account for yaw events via adjusting their handwheel inputs etc
Well, i've spent a couple of hrs poking around inside the old ATE MK20 ABS controller:
And here's the low down:
Main processor communicates to the solenoid low side driver at 1ms intervals (1KHz) over SPi coms bus, with a 2MHz clock (slow!). The small 256byte eeprom on the pcb is on the same bus, and is read every 7ms. Uploading the contents of this memory shows it doesn't hold any useful cal info, and is just model variant coding and error codes unfortunately. There are some quite nice diagnostic processes going on, like checking each solenoid is still connected by pulsing each one in turn with a lower voltage (not enough to actually operate the soleniod). This happens continuously during non braking time. The MOSFET drive for the pump and solenoids themselves is also checked in a similar manner at key-on. Although the unit does have CAN coms (3 broadcast messages, not had time to work out what they are yet, although 1 is obviously the 4 wheel speeds) it is too old to use the UDS standard for diagnostics and does all that via the "old skool" K line interface. I will probably dig mine out of the cupboard (unused for about 5 years ;-) and prod the module a bit to see if any more can be gleaned about the operaton of the brake solenoids themselves. Otherwise i will have to generate 4 "wheel speed" signals and fool the unit into responding to an "abs" event!.
However, the postie brought me another victim for the operating table this morning, a nice shiney ATE MK70 unit:
This is a much more modern unit, weighing a quite impressively small amount {~1.6kg) and certainly would be no issues to package into an Ultima or even a Caterham etc.
So, to borrow someone elses phrase "Don't turn it on, take it APART"........... ;-)
And here's the low down:
Main processor communicates to the solenoid low side driver at 1ms intervals (1KHz) over SPi coms bus, with a 2MHz clock (slow!). The small 256byte eeprom on the pcb is on the same bus, and is read every 7ms. Uploading the contents of this memory shows it doesn't hold any useful cal info, and is just model variant coding and error codes unfortunately. There are some quite nice diagnostic processes going on, like checking each solenoid is still connected by pulsing each one in turn with a lower voltage (not enough to actually operate the soleniod). This happens continuously during non braking time. The MOSFET drive for the pump and solenoids themselves is also checked in a similar manner at key-on. Although the unit does have CAN coms (3 broadcast messages, not had time to work out what they are yet, although 1 is obviously the 4 wheel speeds) it is too old to use the UDS standard for diagnostics and does all that via the "old skool" K line interface. I will probably dig mine out of the cupboard (unused for about 5 years ;-) and prod the module a bit to see if any more can be gleaned about the operaton of the brake solenoids themselves. Otherwise i will have to generate 4 "wheel speed" signals and fool the unit into responding to an "abs" event!.
However, the postie brought me another victim for the operating table this morning, a nice shiney ATE MK70 unit:
This is a much more modern unit, weighing a quite impressively small amount {~1.6kg) and certainly would be no issues to package into an Ultima or even a Caterham etc.
So, to borrow someone elses phrase "Don't turn it on, take it APART"........... ;-)
Max_Torque said:
Although the unit does have CAN coms (3 broadcast messages, not had time to work out what they are yet, although 1 is obviously the 4 wheel speeds)
Possibly one is the ABS warning light and the other the DSC/TCS warning.Wish I had access to the kind of kit you've got though!
So, MK20 to MK70: (there was a couple of generations of MK60 inbetween)
Quite a change really, reflecting the massive growth in capability and flexibility of the automotive electronics arena. With IC date codes mostly in early 2007, this MK70 was probably manufactured in mid 2007, 10 years or so later than the MK20 i stripped above ^^^^.
In the mid / late 1990's. if you wanted a specific and low cost high volume integrated circuit you pretty much had to roll your own, by 2007, there are a host of semiconductor suppliers desperately wanting your buisness, and this later controlle reflects that with IC's from Freescale and ST. They are still branded ATE, so are "custom" to a degree, but now based on mainsteam product lines (and they come with all the test, development and validation from those high volume lines!)
This new module is probably 60% of the size of the MK20, still just 8 solenoids ABS only flavour in this case (interestingly, unlike the Mk20, there is no provision on the pcb for the "extra 4" solenoids required for TCS/DSC etc, and hence it must be a whole new housing / design for those devices. I suspect ATE elected to get this basic ABS only system as small, light and cheap as possible, which suggests a low end target market in the mid 2000's, so fiesta's, micras, corsa's etc. (Now of course, in 2013, we expect even our shopping cars to come with all the bells and whistles)
As before:
1) Main processor - Freescale microcontroller 100pin TQFP package - almost certainly now a 32b device. Also labelled with ATE, so likely to be a semi custom bit of silicon
2) Main uC XTAL - 24MHz
3) Large (also 100pin) ATE specific ASIC - For cost reasons, integrating all the std ABS measurement and driver functions into one specific chip is a good idea. I suspect this single device does all the low level decoding of wheel speed signals, drives the solenoids and acts in a diagnostic and supervisory function. - It would be very hard to hack this device!
4) Infineon optiMOS H channel power Mosfet, used to switch hydraulic pump power. An "off-the-shelf" automotive rated device, 55V 80A 7mO RDSon.
5) ST microelectronics EEPROM 4Kb - SPi interface
6) ST D30NF04L 30V 30A N channel mosfet - supply switch for hyd solenoids
7) ST S1045 Schotkey diode - to-252 package - Reverse battery protection diode for logic/sol power
8) Interesting "spare" footprint - unknown, could be for a seperate solder-on hybrid pcb, maybe containing a gyro or accelerometer???
9) Another "spare" footprint could well be for some external NVRAM for "flight recorder" purposes?
Generally, as esxpected, this device uses smaller 0603 sized descrete components to save space / cut costs, and much more of it's functions look to be integrated into the main ASICs rather than in seperate logic (descrete or ASIC)
Also interesting is the use of pcb "piercing" solderless contacts. To avoid the issues with solder joints failing with vibration and thermal cycling, the contacts for the connectors and solenoids are just "rammed" into plated holes in the pcb that are too small a diameter. The resulting compressive interferrence fit is, when accurately tolleranced, super reliable:
This i think would make a very good candidate for hosting a new parastic control pcb, just using some of the original IC's (might as well carry across all the power switches/diodes etc) ;-)
Quite a change really, reflecting the massive growth in capability and flexibility of the automotive electronics arena. With IC date codes mostly in early 2007, this MK70 was probably manufactured in mid 2007, 10 years or so later than the MK20 i stripped above ^^^^.
In the mid / late 1990's. if you wanted a specific and low cost high volume integrated circuit you pretty much had to roll your own, by 2007, there are a host of semiconductor suppliers desperately wanting your buisness, and this later controlle reflects that with IC's from Freescale and ST. They are still branded ATE, so are "custom" to a degree, but now based on mainsteam product lines (and they come with all the test, development and validation from those high volume lines!)
This new module is probably 60% of the size of the MK20, still just 8 solenoids ABS only flavour in this case (interestingly, unlike the Mk20, there is no provision on the pcb for the "extra 4" solenoids required for TCS/DSC etc, and hence it must be a whole new housing / design for those devices. I suspect ATE elected to get this basic ABS only system as small, light and cheap as possible, which suggests a low end target market in the mid 2000's, so fiesta's, micras, corsa's etc. (Now of course, in 2013, we expect even our shopping cars to come with all the bells and whistles)
As before:
1) Main processor - Freescale microcontroller 100pin TQFP package - almost certainly now a 32b device. Also labelled with ATE, so likely to be a semi custom bit of silicon
2) Main uC XTAL - 24MHz
3) Large (also 100pin) ATE specific ASIC - For cost reasons, integrating all the std ABS measurement and driver functions into one specific chip is a good idea. I suspect this single device does all the low level decoding of wheel speed signals, drives the solenoids and acts in a diagnostic and supervisory function. - It would be very hard to hack this device!
4) Infineon optiMOS H channel power Mosfet, used to switch hydraulic pump power. An "off-the-shelf" automotive rated device, 55V 80A 7mO RDSon.
5) ST microelectronics EEPROM 4Kb - SPi interface
6) ST D30NF04L 30V 30A N channel mosfet - supply switch for hyd solenoids
7) ST S1045 Schotkey diode - to-252 package - Reverse battery protection diode for logic/sol power
8) Interesting "spare" footprint - unknown, could be for a seperate solder-on hybrid pcb, maybe containing a gyro or accelerometer???
9) Another "spare" footprint could well be for some external NVRAM for "flight recorder" purposes?
Generally, as esxpected, this device uses smaller 0603 sized descrete components to save space / cut costs, and much more of it's functions look to be integrated into the main ASICs rather than in seperate logic (descrete or ASIC)
Also interesting is the use of pcb "piercing" solderless contacts. To avoid the issues with solder joints failing with vibration and thermal cycling, the contacts for the connectors and solenoids are just "rammed" into plated holes in the pcb that are too small a diameter. The resulting compressive interferrence fit is, when accurately tolleranced, super reliable:
This i think would make a very good candidate for hosting a new parastic control pcb, just using some of the original IC's (might as well carry across all the power switches/diodes etc) ;-)
Max_Torque said:
This new module is probably 60% of the size of the MK20, still just 8 solenoids ABS only flavour in this case (interestingly, unlike the Mk20, there is no provision on the pcb for the "extra 4" solenoids required for TCS/DSC etc, and hence it must be a whole new housing / design for those devices.
Certainly in the case of the RX-8 ones I looked at, the hardware is physically different between the ABS only version and the ABS/DCS/TCS version (simple to tell which one is which externally too).Oh and also that box I mentioned previously for the RX-8, here's a link to a forum page discussing it.
http://www.rx8club.com/series-i-wheels-tires-brake...
http://eemotiv.com/?pagename=products
Suggests to contact them for the "HBM technical paper" which might be of interest as to how they've done it but looking at the instructions it connects to the 'combined' sensor and mentions the SAS so I think I was correct in my previous assumption that it fooled with the output from the accelerometers.
Suggests to contact them for the "HBM technical paper" which might be of interest as to how they've done it but looking at the instructions it connects to the 'combined' sensor and mentions the SAS so I think I was correct in my previous assumption that it fooled with the output from the accelerometers.
That^^^ box will basically just act as a CAN gateway module for the yaw/long accel sensor (they are combined on BOSCH systems into the box that looks like this:
In effect it will recieve the CAN data for yaw and long accel on one CAN bus (with the original CAN ID being broadcast by the module) and then multiply / divide the signal magnitudes (depending on the effect you want to have) and re-transmit that data onto the 2nd CAN bus (which will be connected to the ABS/ASR module) with the same ID. That way the modifying effect of the box is disguised from the stability module.
Yes it will work, and with no other choice it's maybe the least bad option, but i can't say i'd particularly want to trick my statility control that way without really knowing what effect it is likely to have etc (and the only way to be SURE would be to have access to the code running in the ABS/ASR module etc )
Having looked at how the MK20 and MK70 ATE abs systems work from a hardware point of view (including their diagnostic capability) it seems very do-able to substitute my own control hardware. For a low volume device (unlike the original device) it's not too costly an approach to just throw processor power at it. Something like a STMF104 series micro controller would add a massive capability for both obtaining a very high control bandwidth (easily 5KHz if you wanted, and in fact the data input rate from the wheel speed sensors would be the limiting factor (ie having to wait for a "new" speed measurement increment from the toothed wheel/sensor) and having plenty of left over power for diagnostics/safety checking, and probably running a ful physics dynamics model as well (F104 series is 32b, floating point @ 170MHz, for about a fiver in <10 quantities!)
I'd also probably go with the "two processor" approach, and chuck on a simple 8bit device (probably an ATMEL AVR of some flavour) as an Equizzer. In effect the processors will "chat" to each other, and on any unexpected response (caused by code hang ups, data errors, or power / data signal issues) EITHER device can pull the plug on the other one (luckily for an 8 sol ABS system, no power = off andjust leaves the normal hydraulic circuit un-affected). By using two different devices, with different tool chains (Manufacturers/compliers / IDEs etc) you very much minimise the chance of a "coding" failure occuring simultaneously on both processors. Beyond that, mixing power requirements (one 5v device, one 3.3v device) also brings fail safety as their power supplies are decoupled (luckily, a gross power failure (fuse pops, wire snaps etc) also means the solenoids switch off and fail safe etc).
The only thing i can't decide is if it is a good idea starting with a system that could be upgraded to DSC/TSC over and above basic ABS at a later date without a major h/w rip up. The MK70 system, which is really small and light cannot just be upgraded to DSC/TSC because it is too physically small to fit in the extra 4 solenoids required for those operating modes.
Other wise the MK70 looks ideal, and is very availible on the s/h market (i brough my test module for £12 on ebay!) it might be worth me getting hold of a BOSCH 8.0 device (like used by the BOSCH motorsport system) for a look see (although, being much newer, these are more costly (go for more like £80-120 on ebay for example). The other issue with going DSC/TCS is that it would need a dedicate EMS system, that can ask for torque requests over the CAN bus (and really a torque based EMS to get the necessary responce accuracy / repeatability)
In effect it will recieve the CAN data for yaw and long accel on one CAN bus (with the original CAN ID being broadcast by the module) and then multiply / divide the signal magnitudes (depending on the effect you want to have) and re-transmit that data onto the 2nd CAN bus (which will be connected to the ABS/ASR module) with the same ID. That way the modifying effect of the box is disguised from the stability module.
Yes it will work, and with no other choice it's maybe the least bad option, but i can't say i'd particularly want to trick my statility control that way without really knowing what effect it is likely to have etc (and the only way to be SURE would be to have access to the code running in the ABS/ASR module etc )
Having looked at how the MK20 and MK70 ATE abs systems work from a hardware point of view (including their diagnostic capability) it seems very do-able to substitute my own control hardware. For a low volume device (unlike the original device) it's not too costly an approach to just throw processor power at it. Something like a STMF104 series micro controller would add a massive capability for both obtaining a very high control bandwidth (easily 5KHz if you wanted, and in fact the data input rate from the wheel speed sensors would be the limiting factor (ie having to wait for a "new" speed measurement increment from the toothed wheel/sensor) and having plenty of left over power for diagnostics/safety checking, and probably running a ful physics dynamics model as well (F104 series is 32b, floating point @ 170MHz, for about a fiver in <10 quantities!)
I'd also probably go with the "two processor" approach, and chuck on a simple 8bit device (probably an ATMEL AVR of some flavour) as an Equizzer. In effect the processors will "chat" to each other, and on any unexpected response (caused by code hang ups, data errors, or power / data signal issues) EITHER device can pull the plug on the other one (luckily for an 8 sol ABS system, no power = off andjust leaves the normal hydraulic circuit un-affected). By using two different devices, with different tool chains (Manufacturers/compliers / IDEs etc) you very much minimise the chance of a "coding" failure occuring simultaneously on both processors. Beyond that, mixing power requirements (one 5v device, one 3.3v device) also brings fail safety as their power supplies are decoupled (luckily, a gross power failure (fuse pops, wire snaps etc) also means the solenoids switch off and fail safe etc).
The only thing i can't decide is if it is a good idea starting with a system that could be upgraded to DSC/TSC over and above basic ABS at a later date without a major h/w rip up. The MK70 system, which is really small and light cannot just be upgraded to DSC/TSC because it is too physically small to fit in the extra 4 solenoids required for those operating modes.
Other wise the MK70 looks ideal, and is very availible on the s/h market (i brough my test module for £12 on ebay!) it might be worth me getting hold of a BOSCH 8.0 device (like used by the BOSCH motorsport system) for a look see (although, being much newer, these are more costly (go for more like £80-120 on ebay for example). The other issue with going DSC/TCS is that it would need a dedicate EMS system, that can ask for torque requests over the CAN bus (and really a torque based EMS to get the necessary responce accuracy / repeatability)
If you are aiming at the kit market. There are going to be all sorts of engine control systems...including distributors and carbs type setups. But not so many of those being built I suspect. I would think keep it simple and go for abs only.
But i'm not actually in the market. I just love this type of project.
But i'm not actually in the market. I just love this type of project.
Gassing Station | Engines & Drivetrain | Top of Page | What's New | My Stuff