E36 Track Car - Replacement Engine Build(s)
Discussion
Sf_Manta said:
I was the one mentioning about gauges.
Thoroughly impressed with the build, would be good to see numbers once you've got it mapped fully.
Ironically I've just got myself a 3.0, be it in a E46 touring.
It has been tweaked and dyno'd already, numbers to come soon Thoroughly impressed with the build, would be good to see numbers once you've got it mapped fully.
Ironically I've just got myself a 3.0, be it in a E46 touring.
The thread is a couple of months behind at the moment.Thanks for the comments everyone.
f0xy said:
Yeah thats correct. Well, its actually an M50B25 head, which is the same anyway. This was used as it has an additional coolant sensor location on the head (as per the post above), because the M50's used two separate sensors for the ECU/Dash, whereas the M52's used a single sensor.
I have a local place for machining who I've used for years, so pay different prices to the norm. Generally you're probably looking at £25-30 for a skim and a bit more for honing. Varies quite a bit but its worth going somewhere thats recommended over the cheapest price.
The standard exhaust was very quiet originally, so a long while ago the back box was cut open and the baffles changed, which did increase noise a bit, but it was still under 90db. The new exhaust was 98db @ 4500rpm when at Oulton around a month ago. It does not really drone, its just noisy anyway as there is nothing inside the car..
Great, thanks for that. Keep up the good work!I have a local place for machining who I've used for years, so pay different prices to the norm. Generally you're probably looking at £25-30 for a skim and a bit more for honing. Varies quite a bit but its worth going somewhere thats recommended over the cheapest price.
The standard exhaust was very quiet originally, so a long while ago the back box was cut open and the baffles changed, which did increase noise a bit, but it was still under 90db. The new exhaust was 98db @ 4500rpm when at Oulton around a month ago. It does not really drone, its just noisy anyway as there is nothing inside the car..
Lancia888 said:
Epic! I'm in awe at you mechanical skills. And you must have s
t loads of money or no girlfriend/wife or a well paying job!! I should have tried harder at skool!!
I've only learnt what I know as I go along, I actually work in IT.. Anyone can do it with enough time and patience (and money!)..t loads of money or no girlfriend/wife or a well paying job!! I should have tried harder at skool!! BritishRacinGrin said:
This is interesting. My car has an M50B25TU 
The original M50B25 was just a straight 6 non-VANOS engine (which is preferred by people who Turbo these cars), then the TU had VANOS. All my reference to the M50 in this thread is actually for the TU. The M50 block is the same, just the valve train differentiating between the two.
I have a Fiat Multipla(which has been around the Nurburg ring) that wears parts out every month or so it feels. I have tackled stuff I would never have dreamed of doing myself a couple of years ago. I am lucky that I work in a garage so have access to ramps and the lads lend a hand or tools when I get stuck. I recently changed my a/c condenser which was a bumper off job, with seized nuts, managed to damaged an a/c pipe. Which looked a nightmare to replace but managed to sort myself saving hundreds of pounds. Really enjoyed the detail in the thread and the photo's. It's amazing what knowledge is out there with parts interchangeability. Thanks for posting.
f0xy said:
BritishRacinGrin said:
This is interesting. My car has an M50B25TU
The original M50B25 was just a straight 6 non-VANOS engine (which is preferred by people who Turbo these cars), then the TU had VANOS. All my reference to the M50 in this thread is actually for the TU. The M50 block is the same, just the valve train differentiating between the two.BritishRacinGrin said:
I looked into this a bit myself, I was worried about deck height on the M50 block with 89mm stroke but yours are clearly safe. I was also a little apprehensive about how well a 75mm bore would get on with an 89mm stroke... Did you bore the block out to 84mm? I guess you must've since you're running M54 Pistons (duh!)
M50B25, M52B28 and M54B30 share the same 84mm bore, with the S50B3x using ~86mm. I think the 2.0L 6 cylinders were 80mm bore, which is a slightly different block.. Not sure what models use a smaller size though!So I needed a way of logging data using what I already have - no aftermarket ECUs, no production data loggers or additional sensors etc. I wanted it to work with what was already on the car, and the stock ECU. The main reason for wanting to log data was so I could review RPM vs AFR, and other things such as Throttle Position etc, once I was back on a computer, as its neigh on impossible to watch everything all the time when driving. A quick glance at WOT is fine, but apart from that you've got no chance without a dyno.
These days many people know about the BMW INPA software, which is used for fault code reading/sensor value reading on the older BMW models. You can use this on a Windows laptop with a VAGCOM KKL cable and a BMW 20pin (diagnostic) adaptor, which works fine. Inside INPA, you can view live sensor data and do various sensor/actuator tests, which is handy. The problem is, the refresh rate on this data is terribly slow, 1 update per second, if that. The E36 is not technically OBD, it will report simple fault codes in generic OBD language to off the shelf code readers, but if you want to read sensor data BMW use a different type, being the DS2 protocol.
Essentially when you are using a VAGCOM cable, the driver on your computer installs it as a COM port. With this in mind, the INPA data goes backwards and forwards over this COM port. Next step was to use a COM port monitor to view the raw binary data going over this port, and it may give a clue to how the software is talking to the ECU. I started INPA and got the Analog Sensor Values screen up, which shows information for most of the sensors you would want to see, then started monitoring.
The same request was being sent by the software to the ECU, and a long reply coming back every time, containing sensor data. Although, we're still in binary here, so the values actually mean nothing.
I won't go into too much detail on the actual language, if you are interested how the data is constructed let me know - as I really struggled to find any information out there about the DS2 format, especially for a BMW. I ended up spending weeks working everything out manually, as every byte represents a different sensor, and each has a multiplication factor, sometimes even two.
Before I looked into working out which byte was which sensor, I wanted to try and manually talk to the ECU using a COM port terminal, to see if I got a response without any other software running. I used a virtual machine (running Linux), connected using the same cable, at 9600baud, and sent the same command as above. I then read the contents of the serial buffer to find the ECU responded with the full string of data. This essentially meant I could communicate with the ECU directly over the COM port, without the need for any of the INPA software. Because you are missing out the software layer that INPA uses with the above, you can send this command to the ECU over the COM port and read the responses much quicker. I quickly wrote a small script and managed to get the request sent/data string back from the ECU 6-7 times per second (6-7 times quicker than INPA can) before I getting 'ECU Busy' responses. Not a bad rate of data at all.
With that in mind, next was to decide what hardware and software to use for building something. It had to be small form factor, quick, efficient and accept different types of inputs, especially USB for the VAGCOM cable. I ended up going with a RaspberryPi, as they offer good performance, decent RAM and very small form factor.
I only had two things in mind for the software to begin with - logging the data as quickly as possible and writing it to a CSV file for use in data log explorer/viewers. Databases are not really quick enough on a rPi to be writing data 5+ times a second without filling up a buffer and using more CPU time, so I stuck with flat files. Luckily there are plenty of libraries in Python for doing these sort of things.
Luckily the AEM Wideband outputs a serial stream of data also, which could also be fed into the RaspberryPi, and logged at the same time as all the other sensor data. After a short while and finding some of the multiplication factors for some of the sensor values, I had a starting point..
(Time, RPM, Wideband, Volts)
After a couple of weeks, I had worked out/found all the factors for each value, and which byte represented which sensor. The easily accessible ones (at any sort of speed) are:
After a bit more time on the application and a few tweeks, I had it running on the RaspberryPi, which was powered from a 12v > 5v converter. The resulting log file appeared to show everything was working well:
Now it was running on the Raspberry Pi, I needed some way of starting/stopping the logging, and knowing what its current status is. Originally I planned on just having a switch and a single LED, as the rPi has input/output pins available for use, which is ideal for things like that. I then decided make use of the 18 button OBC already in the car, and have those buttons control the logging. My OBC did not work properly anyway, so I pulled it apart and started tracing the circuit board inside.
I hacked up a bit of the OBC, and added a rocker switch to the far left, which controls the power going to the rPi. I then set up Temp, Speed and Dist as the control buttons for the application. Temp starts the logging, Speed stops the logging, and Dist adds a marker into the log file at the moment it is pressed, in case I ever need to look up a certain part of the log file. On the far right, I used the Clock button which shuts down the rPi properly. With the rPi using an SD card for its operating system, you don't really want to be just turning the power off (essentially pulling the power lead from your computer), as its quite common for the SD card to corrupt.
Once up to this point I was testing the application on the car, and remembered this data could actually be overlaid on videos from track days, making them a bit more interesting. In addition to the live engine data, I wanted to see if it was possible to add GPS data into the same log file, which would also give you a true speed reading, not just somewhere close like the ECU/Speedo do. I picked up a small GPS chip that runs on the same voltage as the rPi, and mounted it at the bottom of the windscreen inside the car. This particular model gets a fix within 30 seconds, and just outputs a serial stream of GPS data at 10hz constantly after getting a fix. The only part left was to incorporate another background thread in my application which would read the latest GPS data from the stream, and insert it into each row with the engine data.
https://www.youtube.com/watch?v=SvatceQG1rU
The whole thing takes about 20 seconds to boot up, which is automatic when you turn the power on. The software application then automatically starts and outputs to the LCD. The Code LED on the keypad illuminates once everything is ready, and the buttons are disabled up to this point. Once you start the logging, the Limit LED flashes to indicate logging is currently in progress. When you stop the logging, the flashing stops. In addition to this, the LCD displays the current logging status, and the length of the current log.
With everything working, I began to run the engine in and once it had a few miles clocked up did a few pulls and then plotted the data..
2nd > 3rd > 4th Gear Pull - Camshaft Angle (Degrees), RPM, Throttle Position (%), AFR
2nd > 3rd > 4th Gear Pull - Speed, RPM, Throttle Position (%), AFR, Ignition Advance (Degrees) and Injector Duration (m/s)
2nd > 3rd > 4th Gear Pull - Speed, RPM, Throttle Position (%), AFR, Coolant Temperature (C), Intake Temperature (C)
The speed is delayed somewhat, due to the delay with GPS. When I get some time I will add a feed from the differential sensor to get the actual wheel speed.
From running the engine in, you can can really see (and feel) where the M54B30 inlet cam comes alive at 2700rpm or so, and the RPMs increase so much quicker than the M52B28 ever did. Plenty more sensor values that can be added and compared, will be good for fault finding along with everything else. which will be easy enough back on a PC.
So after more miles, a few different tweaks to the calibration on the ECU (as the MAF compensation table is pretty good anyway), it was at a stage where I wanted to run it on a dyno. The M54B30 in stock form produces 228hp, 221lb/ft, so somewhere around that figure would have been nice. Generally the ones you see in the US do anywhere from 230-240hp, excluding the dreamer figures that people seem to think it will give you over 300hp... not even an S50B30 produces that.
The parts/spec of the engine now as it stands: M50 Iron Block, M54B30 Crank, M54B30 Pistons + Rods, M52 Cylinder Head, M54 Inlet Camshaft, M52 Exhaust Camshaft, Refurbished B28/M3 'Pinktop' Injectors, M50 Inlet Manifold, M50 Throttle Body, M20 Lightweight Flywheel, M3 3.2 Exhaust Manifolds and Single 2.5" Exhaust System (No Cat), Stock M52B28 Airbox and MAF, Stock M52B28 'Siemens MS41' ECU with modified calibration file.
Here is the dyno run, with the data log over the top of the video:
https://www.youtube.com/watch?v=jXFZ8N0Jgt8
..and the graph, plotted against the old engine (M52B28) results:
It could probably gain a tiny bit more with a bit less fuel at the top end, but everything seems well as is so I don't want to mess around with it too much just yet. The peak power holds much better after 5500rpm when compared to the old 2.8, as does the big increase in torque throughout the RPM range. The power delivery is much better.
With all said and done, it was about time to take it back on track again...
These days many people know about the BMW INPA software, which is used for fault code reading/sensor value reading on the older BMW models. You can use this on a Windows laptop with a VAGCOM KKL cable and a BMW 20pin (diagnostic) adaptor, which works fine. Inside INPA, you can view live sensor data and do various sensor/actuator tests, which is handy. The problem is, the refresh rate on this data is terribly slow, 1 update per second, if that. The E36 is not technically OBD, it will report simple fault codes in generic OBD language to off the shelf code readers, but if you want to read sensor data BMW use a different type, being the DS2 protocol.
Essentially when you are using a VAGCOM cable, the driver on your computer installs it as a COM port. With this in mind, the INPA data goes backwards and forwards over this COM port. Next step was to use a COM port monitor to view the raw binary data going over this port, and it may give a clue to how the software is talking to the ECU. I started INPA and got the Analog Sensor Values screen up, which shows information for most of the sensors you would want to see, then started monitoring.
The same request was being sent by the software to the ECU, and a long reply coming back every time, containing sensor data. Although, we're still in binary here, so the values actually mean nothing.
I won't go into too much detail on the actual language, if you are interested how the data is constructed let me know - as I really struggled to find any information out there about the DS2 format, especially for a BMW. I ended up spending weeks working everything out manually, as every byte represents a different sensor, and each has a multiplication factor, sometimes even two.
Before I looked into working out which byte was which sensor, I wanted to try and manually talk to the ECU using a COM port terminal, to see if I got a response without any other software running. I used a virtual machine (running Linux), connected using the same cable, at 9600baud, and sent the same command as above. I then read the contents of the serial buffer to find the ECU responded with the full string of data. This essentially meant I could communicate with the ECU directly over the COM port, without the need for any of the INPA software. Because you are missing out the software layer that INPA uses with the above, you can send this command to the ECU over the COM port and read the responses much quicker. I quickly wrote a small script and managed to get the request sent/data string back from the ECU 6-7 times per second (6-7 times quicker than INPA can) before I getting 'ECU Busy' responses. Not a bad rate of data at all.
With that in mind, next was to decide what hardware and software to use for building something. It had to be small form factor, quick, efficient and accept different types of inputs, especially USB for the VAGCOM cable. I ended up going with a RaspberryPi, as they offer good performance, decent RAM and very small form factor.
I only had two things in mind for the software to begin with - logging the data as quickly as possible and writing it to a CSV file for use in data log explorer/viewers. Databases are not really quick enough on a rPi to be writing data 5+ times a second without filling up a buffer and using more CPU time, so I stuck with flat files. Luckily there are plenty of libraries in Python for doing these sort of things.
Luckily the AEM Wideband outputs a serial stream of data also, which could also be fed into the RaspberryPi, and logged at the same time as all the other sensor data. After a short while and finding some of the multiplication factors for some of the sensor values, I had a starting point..
(Time, RPM, Wideband, Volts)
After a couple of weeks, I had worked out/found all the factors for each value, and which byte represented which sensor. The easily accessible ones (at any sort of speed) are:
- RPM - x 1000
- AFR - AEM Wideband
- Air Intake Temperature - Degrees C
- Coolant Temperature - Degrees C
- Ignition Advance - Degrees
- Injector Duration - ms
- Camshaft Angle - Degrees
- Engine Load - mg/Stroke
- Air Mass - kg/h
- Idle Control Valve - Current Position %
- Battery Voltage - Volts
- TPS Voltage - Volts
- TPS Percent - Calculated Value Based on TPS Voltage, between 0-100%
- Speed - KPH
- Lambda Bank 1 - Volts
- Lambda Bank 2 - Volts
- Lambda Heater Bank 1 - %
- Lambda Heater Bank 2 - %
After a bit more time on the application and a few tweeks, I had it running on the RaspberryPi, which was powered from a 12v > 5v converter. The resulting log file appeared to show everything was working well:
Time;Date Time;RPM;AFR;Intake Temperature;Coolant Temperature;Ignition Advance;Injector Duration;Camshaft Angle;Engine Load;Idle Control Valve;Battery Voltage;TPS Voltage;TPS Percent
113.593333;01/01/70 01:01:53;0;15.7;18095.000000000004;32.39999999999999;5.866999999999997;0.0;0.0;0.0;12.038039999999999;11.729999999999999;0.663;0
113.822107;01/01/70 01:01:53;0;15.7;18095.000000000004;32.39999999999999;5.866999999999997;0.0;0.0;0.0;12.038039999999999;11.729999999999999;0.663;0
114.050493;01/01/70 01:01:54;0;15.7;18095.000000000004;31.950000000000003;5.866999999999997;0.0;0.0;0.0;12.14514;11.729999999999999;0.663;0
114.278498;01/01/70 01:01:54;0;15.7;18095.000000000004;31.950000000000003;5.866999999999997;0.0;0.0;0.0;12.14514;11.729999999999999;0.663;0
Now it was running on the Raspberry Pi, I needed some way of starting/stopping the logging, and knowing what its current status is. Originally I planned on just having a switch and a single LED, as the rPi has input/output pins available for use, which is ideal for things like that. I then decided make use of the 18 button OBC already in the car, and have those buttons control the logging. My OBC did not work properly anyway, so I pulled it apart and started tracing the circuit board inside.
I hacked up a bit of the OBC, and added a rocker switch to the far left, which controls the power going to the rPi. I then set up Temp, Speed and Dist as the control buttons for the application. Temp starts the logging, Speed stops the logging, and Dist adds a marker into the log file at the moment it is pressed, in case I ever need to look up a certain part of the log file. On the far right, I used the Clock button which shuts down the rPi properly. With the rPi using an SD card for its operating system, you don't really want to be just turning the power off (essentially pulling the power lead from your computer), as its quite common for the SD card to corrupt.
Once up to this point I was testing the application on the car, and remembered this data could actually be overlaid on videos from track days, making them a bit more interesting. In addition to the live engine data, I wanted to see if it was possible to add GPS data into the same log file, which would also give you a true speed reading, not just somewhere close like the ECU/Speedo do. I picked up a small GPS chip that runs on the same voltage as the rPi, and mounted it at the bottom of the windscreen inside the car. This particular model gets a fix within 30 seconds, and just outputs a serial stream of GPS data at 10hz constantly after getting a fix. The only part left was to incorporate another background thread in my application which would read the latest GPS data from the stream, and insert it into each row with the engine data.
https://www.youtube.com/watch?v=SvatceQG1rU
The whole thing takes about 20 seconds to boot up, which is automatic when you turn the power on. The software application then automatically starts and outputs to the LCD. The Code LED on the keypad illuminates once everything is ready, and the buttons are disabled up to this point. Once you start the logging, the Limit LED flashes to indicate logging is currently in progress. When you stop the logging, the flashing stops. In addition to this, the LCD displays the current logging status, and the length of the current log.
With everything working, I began to run the engine in and once it had a few miles clocked up did a few pulls and then plotted the data..
2nd > 3rd > 4th Gear Pull - Camshaft Angle (Degrees), RPM, Throttle Position (%), AFR
2nd > 3rd > 4th Gear Pull - Speed, RPM, Throttle Position (%), AFR, Ignition Advance (Degrees) and Injector Duration (m/s)
2nd > 3rd > 4th Gear Pull - Speed, RPM, Throttle Position (%), AFR, Coolant Temperature (C), Intake Temperature (C)
The speed is delayed somewhat, due to the delay with GPS. When I get some time I will add a feed from the differential sensor to get the actual wheel speed.
From running the engine in, you can can really see (and feel) where the M54B30 inlet cam comes alive at 2700rpm or so, and the RPMs increase so much quicker than the M52B28 ever did. Plenty more sensor values that can be added and compared, will be good for fault finding along with everything else. which will be easy enough back on a PC.
So after more miles, a few different tweaks to the calibration on the ECU (as the MAF compensation table is pretty good anyway), it was at a stage where I wanted to run it on a dyno. The M54B30 in stock form produces 228hp, 221lb/ft, so somewhere around that figure would have been nice. Generally the ones you see in the US do anywhere from 230-240hp, excluding the dreamer figures that people seem to think it will give you over 300hp... not even an S50B30 produces that.
The parts/spec of the engine now as it stands: M50 Iron Block, M54B30 Crank, M54B30 Pistons + Rods, M52 Cylinder Head, M54 Inlet Camshaft, M52 Exhaust Camshaft, Refurbished B28/M3 'Pinktop' Injectors, M50 Inlet Manifold, M50 Throttle Body, M20 Lightweight Flywheel, M3 3.2 Exhaust Manifolds and Single 2.5" Exhaust System (No Cat), Stock M52B28 Airbox and MAF, Stock M52B28 'Siemens MS41' ECU with modified calibration file.
Here is the dyno run, with the data log over the top of the video:
https://www.youtube.com/watch?v=jXFZ8N0Jgt8
..and the graph, plotted against the old engine (M52B28) results:
It could probably gain a tiny bit more with a bit less fuel at the top end, but everything seems well as is so I don't want to mess around with it too much just yet. The peak power holds much better after 5500rpm when compared to the old 2.8, as does the big increase in torque throughout the RPM range. The power delivery is much better.
With all said and done, it was about time to take it back on track again...
Edited by f0xy on Sunday 4th January 18:42
Ford 2 said:
Your a bit special sir..I could see that 52 block pulling threads before it happened there awful for doing it. Serious about IT skills also good job
Heard of it a number of times now since, and seen many bodges along the way, which I dont think id trust! Thankshelix402 said:
Great job. Reminds me of changing block and pistons on M52s under warranty in the 90s. I hadn't heard of putting the 330 cam in the 328 before. I have a humble M52tu with a 330 inlet manifold (bit cheaper than the crank!)
It probably hasn't gained that much with the cam, its only a small increase in lift and duration. In an ideal world you would use the US S50B30 cams, but finding a set of those in good condition is quite difficult to say the least. Best compromise was to just work with what was available from the M54 motor Very interesting thread, love all the pics and detail
F0xy, what do you use to clean the engine block and gearbox etc? I've currently got my (unrelated) engine/box out for a clutch change and I wanted to clean it up a bit before going back in. I've tried using Gunk but it doesn't seem that great.
Cheers
F0xy, what do you use to clean the engine block and gearbox etc? I've currently got my (unrelated) engine/box out for a clutch change and I wanted to clean it up a bit before going back in. I've tried using Gunk but it doesn't seem that great.
Cheers
Toilet Duck said:
Very interesting thread, love all the pics and detail
F0xy, what do you use to clean the engine block and gearbox etc? I've currently got my (unrelated) engine/box out for a clutch change and I wanted to clean it up a bit before going back in. I've tried using Gunk but it doesn't seem that great.
Cheers
For the gearbox, I used Gunk (the brush on stuff) which was left for 10-15 mins then pressure washed off. Quite easy with the BMW box as no water can get in really. It came up quite well, then painted it anyway. Engine block wise its always just cleaned/dipped at the machine shop. I've tried all sorts of cleaners/degreasers and not found anything that's good for everything really, Gunk usually does most of it but you have to give it time usually..F0xy, what do you use to clean the engine block and gearbox etc? I've currently got my (unrelated) engine/box out for a clutch change and I wanted to clean it up a bit before going back in. I've tried using Gunk but it doesn't seem that great.
Cheers
olly22n said:
Well get writing it then!
Anymore on the car development before the engine?
So the chassis - the car had done around 185k when I got it, so I knew bushes/suspension were the first things I wanted to sort. This also includes other stuff and is in no particular order. Z3M shifter and new bushes..Anymore on the car development before the engine?
M3 42mm core radiator fitted, as the original was leaking. Having no expansion tank built into the radiator, so you need the wider mounting feet. Volvo low temperature fan switch fitted in the standard location..
Electric slimline fan added on its own brackets..
Interior non-essentials removed, harness eyelets welded in, centre console cut down, etc..
Seats and harnesses fitted from a previous project..
The car itself sits on HSD coilovers. Started by picking up a spare complete rear subframe...
Stripped the lot down including bushes..
Had it all blasted and powdercoated, which included some M3 ARBs..
Added some extra strength to the rear ARB mounts before it was powdercoated..
Then some subframe polybushes, ball joints in both upper and lower positions (as per E46), new bearings and Powerflex black in the RTABs..
Got an M3 3.15 LSD, turned up some solid bushes for the back plate, and a solid bush for the front (which then goes in the subframe)..
Propshaft cleaned up and new support bearing..
With the Powerflex washers being about as thick as a coke can, I decided to use some thick round plate instead. Drilled..
Subframe studs removed from chassis, replaced with E90 front suspension bolts..
Everything then bolted to the car with adjustable rear camber arms..
Front ARB polybushes fitted, then droplink bushes replaced with polybushes also..
Rest of the front end components, with and some E30 wishbones and new balljoints, polybushed lollipops..
Fresh front subframe as my engine mount mounting had split..
E46 '067' Steering Rack fitted along with new steering arms/track rod ends. M3 power steering pump fitted at the same time.
Steering linkage bushing solid replacement..
Whole lot fitted along with the X-Brace..
All the original brake lines were removed, including the ABS. Fitted an M3 Evo master cylinder, and use a proportioning valve inside the car. Braided lines throughout. This is with M3 front calipers (and hubs), which were rebuilt with new seals. Rears were done also but no pics..
I have used Carbone Lorraine RC5, RC6 and DS3000 at various points. New discs fitted..
Long bull-nose studs fitted all round, easier especially with spacers..
I have a number of sets of 16x8 BBS, usually found on E38's. Much prefer the cheaper sticky tyre prices in 16"..
Front brake cooling ducts..
Had the alignment done (Couple of times over the past 12 months): 3 Degrees Front Camber, Square Toe, 5 Degrees Caster. 2 Degrees Rear Camber, 20minutes Total Toe In.
Lastly some of the car itself..
Probably some parts missed out but all the mains bits have been covered, hopefully get it out a number of times this year
CoolHands said:
all you need now is a decent paint job!
No need on a shell thats just going to rust anyway, rear arches are on their way and the inner/outer sills have been done recentlyDasChin said:
er and a cage. do that before anything else to a dedicated track car.
safety first. also tightens up the chassis a lot so you get handling benefits.
Its the only thing left to do, although it won't be happening on this shell. I'd prefer to properly cage a saloon, just finding a solid one takes time. Unfortunately I'm not doing it to a Coupe, especially one that's rusting. The upside is everything will directly swap over. In previous cars we've sorted the shell, and only ever bothered with full weld in cages, through to the pickups and had a great result overall.safety first. also tightens up the chassis a lot so you get handling benefits.
Awesome build Foxy, despite coming up unlucky with the first engine build.
I particularly like the exhaust build, but presumably the car now is fully track focused and will not be MOT able, so will need to be trailered to and from the track?
I managed to follow the telemetry build up to the point of writing the translation script, I can see there is definitely value in having telemetry for the health of the engine as well as checking on your driving during and post event. Thumbs up
Out of curiosity, what specific oil type and grade did you use on the M50B28 engine for the first track session after running the engine in and what was the condition of the old big end shells that were replaced on the first and second engine builds? I saw the new shells going in but would like to know what the old shells looked like.
Humour
I particularly like the exhaust build, but presumably the car now is fully track focused and will not be MOT able, so will need to be trailered to and from the track?
I managed to follow the telemetry build up to the point of writing the translation script, I can see there is definitely value in having telemetry for the health of the engine as well as checking on your driving during and post event. Thumbs up
Out of curiosity, what specific oil type and grade did you use on the M50B28 engine for the first track session after running the engine in and what was the condition of the old big end shells that were replaced on the first and second engine builds? I saw the new shells going in but would like to know what the old shells looked like.
Humour
Gassing Station | Readers' Cars | Top of Page | What's New | My Stuff