Personal tools
Log in
User menu
Main page
All Projects
Recommended Tools
Research
Resume/CV
Links
View source for Porsche 928 LH Replacement Prototype
From Francois Louw
Jump to:
navigation
,
search
<metadesc>LH Replacement ECU Prototype</metadesc> <metakeywords>Porsche,928,S4,LH,Replacement,ECU,Fuel computer,LH ECU,fuel injection,replacement,replace,fix,bosch lh,bosch,bosch ecu,engine control unit,electronic control unit,porsche ecu repair,jetronic,lh jetronic,porsche lh jetronic,ecu replacement,porsche 928 lh ecu,928 ecu repair,lh replacement,porsche 928,repair ecu,ecu replacement,bosch lh jetronic,928 porsche,porsche ecu rebuild,porsche ecu repair,porsche ecu replace,gt,gts,928 s4,928 gt,928 gts,928 s2,35 pin,25 pin,fuel map,performance,engine control,lh-jetronic,l-jetronic,module repair,module rebuild,ECU repair,ECU rebuild,ECM,EZK repair, EZF repair, fuel injection, Mass Airflow Meter repair, MAF, MAF calibration, Porsche repair, lh test, ECU test, MAF test, LH 2.0, LH 2.2, LH 2.3,MAF, Mass Air Flow Meter, Porsche 928, ECU, Porsche Hammer, ECU Repair, SharkTuner,Fault Find,Fault Diagnosis</metakeywords> ==Porsche 928 LH Replacement ECU Prototype Build Page== [[Porsche 928 LH Replacement ECU|Back to Project Page]] [[Projects|Back to All Projects Page]] [[Main Page|Back to Main Page]] The discussion forum can be found at [http://forums.rennlist.com/rennforums/928-forum/602152-plug-in-lh-replacement.html Rennlist] ---- __TOC__ ==Hardware Selection== ===Requirements=== 1) I need to know what each pin of the ECU connector does. In the end when everything is done I want to plug my module in and do nothing to the rest of the car and it should work. 2) USB/Serial port on the board that will allow remapping while driving/dyno 3) Possibly I would want to replicate the bosh diagnostics k/l lines, but I think that would be redundant given that the serial/usb will be able to give errors and diagnose. 4) The processor that I must use must preferably have a/d convertor, lots of digital I/O, support serial and USB, must also run fast enough so that I wont have trouble when it comes to coding. 5) Must withstand the "harsh" temperatures and EM interference that is present in a car 6) Must have lots of LEDs to impress everyone that looks at it ===Component Selection=== Ok here is my list of components, I know that you can get better and the whole ARM vs. MIPS instruction sets blah blah blah... But the components are chosen, not much gonna happen to change it. CPU: Microchip PIC32MX575F512L 100pin TQFP EEPROM: 256K Dont care what brand, going to use the Atmel footprint <= The EEPROM is optional, if the internal flash of the processor is not enough Switching FET: ST Micro ST-D17NF03L <= They are monsters and completely overkill but also cheap and will get the job done BJT to switch FET: BC848 <= Switch sitting inbetween 3.3V CPU and 12V FET Comparators: LM239, Any brand <= Used to switch from 12V digital inputs to 3.3V for the CPU Op-Amp: LM324, Any Brand <= Need to translate the MAF Voltage to 3.3 and the engine temp sensor, etc etc Power Filters: BNX012, 1N4004 protection diodes, Input voltage limiting Diodes <= EMI is bad inside car, thus need to filter Voltage Regulators: LM317 <= Need 8-10V intermediate voltage, ST493C33 <= Current limiting 3.3V supply for CPU These components are the major components and I did not list all the masses of resistors, caps and diodes used in the circuit. ==Schematics== Here are low resolution pic of my schematics, I made it low res on purpose, I don't want other people stealing my design and making money out of it. First Image is page 1-4 of the schematics, second image is page 5-8. Page 1: CPU Page 2: EEPROM Page 3: Power Page 4: Outputs Page 5: Digital Inputs Page 6: Analogue Inputs Page 7: LEDs, USB and Serial Page 8: Connector The third image is the PCB layout, blue is bottom layer, red is top. This board is made using only 2 layers. Most probably if I make second version I will have to go 4 layers to make enough space to route for different connectors. Next step is making the actual PCB, populating and soldering [[File:ECU1-Page1-4.jpg|500px]] [[File:ECU1-page5-8.jpg|500px]] ==PCB Layout== Here is a low res version of the PCB layout [[File:ECU1-PCB.jpg|500px]] ==PCB Creation and populating== The PCB that I must make is a two layer pcb with 0.006" gaps between tracks and 0.012" vias. That is small, and I cannot do it at home. So I sent the info to specialists and received my PCB (5 of them). All the components were ordered from Digi-Key. 34 Different components, 840 components in total for 5 boards) After I got the PCB and components it was time to play around with solder paste and put all the components on. I baked the PCB, and then soldered on the through hole components. There was a small delay with getting the processors, thus the last photo here is the PCB complete without processor. ==Integration== Ok, this step is a really important one. I have to check my design to see if everything works, fits and doesn't blow up. Powering up the board, checking the power LEDS and verifying voltages was first, afterwards checking the digital inputs, and alalogue voltage levels. Here is a list of mistakes I made. The LM317 regulator pin outs in the datasheet is numbered 1-3-2 (3 is in the middle) and in my schematics I used 1-2-3. That now means that I need to make a small wire-mod to fix that. The LH Connector gaps between ping I measured as 5.08mm, but it is in fact 5mm. This means the connector fits a bit tight, but not a problem. (In retrospect I should have realised that it is 5mm and not 5.08, because it is german made and in the 80's the germans were already fully on the metric system. My comparators that I use to translate from 0-battery voltage to 0-3.3v I powered from 3.3 instead of from the battery voltage. This can be fixed by cutting a track and doing a wire mod. Those three mistakes are all that I made. After fixing those the unit's hardware works perfectly. I made a small test application that flips my outputs randomly and puts my test LEDs on when inputs are triggered and everything works perfectly. the next step is to program the unit. The programming will be the remaining steps ==Programming phase 1== Ok, here is a video clip of the car starting and idling with my ECU (1 Minute). I switched off the car in the end. My idling is adjusted to idle higher, will readjust after the units works well. {{#ev:youtube|-JIH2r-TW0g}} At the moment I have just done the idling programming. There is no safety shut off of the fuel pump, and the ECU ignores the RPM and MAF. This is just to illustrate that the unit can get inputs and switch the outputs. The LEDs at the CPU cant be seen in the video but they are flashing in rythm to the EZK inputs and the one far right lights up at WOT. This weekend I will spend most of my time doing the programming. The programming phases are listed as follows: 1) Idling 2) Fuel adjustment according to RPM 3) Adding MAF readings and adjusting to fuel map 4) Add support for engine temperature, safety fuel cut off, tank venting, flappy control 5) Add exhaust feedback support and support for 2 fuel maps - normal/WOT 6) Add communication with PC via Serial, followed by USB 7) Make fuel map dynamically changeable and make windows interface software 8) Dyno the car 9) ? A rough estimate will be 3-4 weeks then all the programming should be done. Hopefully I will be done earlier, so I can enjoy the car more. I will keep everyone updated with videos and I will definitely let everyone know when I'm done and it works perfectly. Remember I only have 4 units "in stock" at the moment, It will be a first come first serve when the project is done, afterwards I will order more PCB and components. Afterwards I will modify the PCB and make units that will be able to work with the 25 pin LH2.2. ==Programming Phase 2: Fuel adjustment according to RPM== Ok, lets give the youtube link first then I will give my boring explanation. {{#ev:youtube|_HC11F8Bi80}} In this video my setup is me sitting with laptop, connected to ICD3 connected to my ECU. The ICD3 in debugging mode allows me to stop and start the CPU when I want (in the bottom of the video on the pc screen you can see me click the run and pause buttons) I have programmed the first part of my fuel map that looks in a 1 dimensional array for the injector opening time. To calculate the RPM I use an internal timer on the CPU. The timer runs at half the CPU speed (40 MHz), along with a divider of 256 that I programmed in. This will yield a timer value of 156.35 for every ms. A bit of calculation later gives me a magic number of 11719. When I take the number 11719 and divide the timer value that measures the time between EZK pulsed, I get a nice 100xRPM value. (value of 5 = 500 rpm etc). Using this method I get a 0.002% error. Meaning I read 7000 rpm instead of 7000.149 (Personally I think this is close enough) I then use that to look up in my table to get the injector opening value. The next step is to program the unit to take the MAF into account. That will not be done today, If I am lucky (read: will not sleep a lot tonight) tomorrow the MAF will be sorted and I will post a video of me driving around the block. ==Programming Phase 3: Fuel adjustment according to MAF and RPM== Ok, here is the video... {{#ev:youtube|kE74lI-tjiE}} ...and here is the explanation. I finally got the A2D converter going on the CPU, took more effort than I thought it would, but at least it is working. In the video the four LEDs at the CPU indicates the voltage of the MAF. I have implemented a basic fuel map that uses RPM and MAF to get the fuel. All of the fuel values in the fuel map are guessed, so the AFR is completely wrong. The software is only set up to work with a maximum MAF input voltage of 6.6V. The next revision I will allow for higher voltages if anyone there wants to use another MAF/MAP that goes higher. But it is good enough to drive with the car. I do not have a vid of me actually driving with the car because of my tranny messing me about. Tomorrow the tranny will be removed and fixed, so I will not be able to do much more coding during next weekt till I get it back. While I wait for the tranny I can continue with some of the coding. ==Programming Phase 4: LH Functionality== Ok, during the time the car was in for repairs I continued working on the coding. The following stuff is implemented and works: Fuel Pump Safety switchoff - After 10 sec of no engine turning the fuel pump will switch off Low battery compensation - When the battery voltage drops the injector open time is increased to compensate Resonance Flap - The resonance flap opens and closes depending on the RPM Idle speed control - The idle speed control signal is sent out. Closed Loop - The exhaust sensor is read and depending on the adjustment pot the fuel is enriched or leaned out (Can be enabled/disabled) Initial engine warm up sequence - Mixture is enriched upon initial engine startup AC Enrichment - When the AC is switched on the fuel is slightly enriched Auto Idle Drop - When the box is in neutral the mixture is leaned out a bit Engine Temperature - Mixture is enriched when engine is cold WOT Mapping - Uses a different fuel map on WOT All of the above is working and is customiseable (how much to enrich with what temperatures, the amount to enrich/lean out with the AC, Idle Drop etc) And to show off a bit I have two videos of me driving around the block today with the new software. {{#ev:youtube|ROYZuZNc_b8}} {{#ev:youtube|6Z2-5_UK_Kg}} The following still needs to be done: "Accelerator Pump" - When the pedal is pressed the mixture must be enriched to compensate USB - The coding for the USB port still needs to be done Windows Tuning - The interface to tune and adjust all the settings must still be written ==Programming Phase 5== Ok, took me quite a while to get to this point. There was a lot of small bugs that had to be fixed. Unfortunately the only time when the bug popped up was while driving. After about a month of proper ECU testing and driving I am confident that all the bugs have been sorted. The "Accelerator jet" coding is also done, and is working perfectly. The USB driver side on the ECU was giving me hell and I was stuck for a few weeks till last night late. I was not able to get communication between the PC and the ECU. Turns out that there is a mistake in the datasheet and application notes of the PIC32 processors. I figured out when I saw that the starter kits from Microchip schematics looked "Wrong" compared to the datasheet and app notes. A small wire mod on my board and suddenly my USB code works. Here is a screenshot of the windows interface software. Still in progress, but gives the idea and layout of it all. [[File:ecu-interface1.jpg|500px]] [[File:ecu-interface2.jpg|500px]] Geeky part: I have decided to use Qt for the interface software. A few reasons made me decide on Qt instead of Visual Studio 2010. At the moment at work I am constantly using Qt and like the functionality available to me. Second, I have a working demo program of Qt using the serial port and it works with my usb code that sits on the ECU. Third Qt is free, VisualStudio 2010 costs more than my car (not really, but it is still way too much). Lastly Qt has awesome graphics, gauges needles etc. that I can use. ==Programming Phase 5-update== USB feedback is 100% operational and adjustments and tuning can be made. The changes cannot be saved yet. Once power is off and back on it resets to the pre programmed defaults. What I am going to do is I am going to finish the last of the programming that allows saving to permanent memory as well as make it capable of updating the programming via USB. Then I am going to distribute the three remaining prototypes to three willing volunteers that can test the system for me (seeing that I cant get to a shark now). If they do testing, then I can fix the last of the bugs and give updates to them to finalise this. New interface screenshot: [[File:ecu-interface3.jpg|500px]] ==Bunch of Micro-updates all thrown together== And I found a few problems that needs adressing. When the board is in firmware update mode, then the injectors are opened (stupid mistake on my part) I also need to improve the connect/disconnect with the windows software Also need to slightly change the default fuel map, it still has my testing options in it, which also result in injectors opened when engine is not turning. Due to all the time that the injectors was opened and the long time that my dad and friend took to do the programming my cylinders are now full of fuel. Anyhow, will have my dad remove plugs and let it dry out over the next day or so, will then test again. I am having problems somewhere in my code. I keep on overfuelling the car. Doesnt want to start and after some turning of the car the cylinders are full of fuel I am trying to get to the bottom of that problem, but the progress is going slow. I am now busy checking the remaining prototypes and will get then out as soon as I have sorted the fuelling problem. I found the problem with flooding of the car. Microchip's sample USB code that I used executes a lot slower than I anticipated (and what they stated in the documentation) meaning that the injectors stayed open for too long thus flooding the car. Also Microchip's bootloader code interfered with the rest of the system, causing uncontrollable interrups delaying the injection for long enough to stall the engine. I am busy replacing the bootloader code, but untill I fix it I cannot send out the other prototypes. Seeing that without the bootloader I cannot send code updates to the testers. I am busy working on it and seeing that I am not doing anything much for xmas and new years I will have some time to work on it. Will keep on working and give updates! there has been some progress. The first prototype in the car got damaged when my dad handled it and shorted out. The second prototype is in there now. i have fixed many...many...many bugs in the microchip usb code, and changed big parts of the code from polling to hardware interrupts. on my test setup it seems to be working 100%, needs to be tested on the car. My exam is over and I have made good progress the past two weeks! I finished the interrupt driven code. That is working 100% The USB code is working 100%, no more delays when using the USB The microchip USB bootloader has been fixed and is working 100% so firmware can be updated via USB. As far as I can physically test the unit without a running car everything is working 100% I am finalising Prototype 4 and 5 so I can send them off to the people who volunteered to help test. I am not completely 100% happy with my user interface and the "accelerator jet" coding and will most probably modify that in the coming week, just so that I am satisified. So I am happy to announce that the prototyping is nearing the ending phase! I will be able to test the complete unit on my car at the end of september. Maybe a bit sooner, depends on a few factors. But hopefully by then I will have shipped the remaining two prototypes to other people for testing. After I have changed the interface so that I am happy I will start the layout of the revised version of the boards. These revisions will include support for the 25 pin connectors. To the people who want to use a different connector I have found a suitable alternative from Samtech that I can bundle along with the unit (the male and female connectors) to anyone who wants to replace that also. I will keep everyone updated as I move along the final stages of this project. ==Update: USB-Interface demo== here are a few youtube videos 1: How the firmware updates work (Not shown in the video is you need to press the button on the computer while switching on ignition to go into firmware update mode - I could not hold camera and do that at same time) {{#ev:youtube|nk3zrobQTM0}} 2: Prototype 2 testing (The annoying buzzing sound is the engine simulator signal connected to speaker so I can hear whats going on) {{#ev:youtube|vkVaARTSN3Y}} 3: Prototype 3 test, more complete testing {{#ev:youtube|RJguEPvmYIo}} ==Demo of USB working in car and revision 2 update== Ok, has been a while since last update, but here it is! I have completed most of the programming and only need to sort out a few unseen bugs. This can only be done by testing in actual vehicles. I have already shipped one of the prototypes to a volunteer tester, and will receive feedback soon! (Thanks AO!!!) To give a small demonstration, here is a video of the prototype in my car, and shows the USB interface on a computer while the engine is running! {{#ev:youtube|hQLtfJMoZ5M}} I have also started working on the PCB of revision 2. Still needs some stuff added, but here is a low quality screenshot of the PCB layout so far. It is a bit smaller than the prototype, but it has extra protection, and should give better analog response! [[File:ECU2-PCB1.jpg|500px]] The build of the second revision will be better explained in its own project page (Coming soon!) ==Logging 16 March 2013== One important feature that would be very nice is to be able to log real time data on the computer, and then save it in a CSV file that can be opened by any other application. My theory was to log all the real time data, along with the current date/timestamp of the system. The update speed is the same as configured in the update speed of the interface software. By default it is 5 updates per second, which should be enough for most situations. I have tested it at 20 updates per second and that is more than fast enough for data capture. here is a screenshot of the logging tab in the Interface software. [[File:ECU-Logging.jpg|500px]] The fields that are saved are relatively obvious. The logging stops when the engine is switched off and automatically resumes when it is on again. Future options will be to add a trigger system where the user can decide when the logging starts, e.g. WOT, or >2000 rpm etc. ==Code Cleanup 17 March 2013== Ok, during all my coding and bug fixing and feature adding I completely messed up the Interface software code. Everything still worked but the code was a mess. Improper variable naming, bad coding, repetition of code, zero comments etc. etc. So the mission was to clean up the Interface Qt code. Add proper comments and optimise a few hidden parts, specifically the way the communication is done. The serial port emulation is kind of temporary so I did not spend too much time on cleaning up that code. I did modify it slightly to make the future transition to non-serial-emulation easier. This also resulted in the build number of the Interface software to take a big jump! New version is build number 539. This will probably change in the near future, but it should be in the download section soon! (This code is compatible with firmware build 1068 to 1099. Probably will support future versions up to a point. ==User Manual 18 March 2013== Ok so I need to start writing that also. It is far from complete, but currently I have a few pages written down on how to enter Bootloader mode, update firmware, and basic usage of the software. I will add more when I am not in the mood for coding :D The manual have also been added to the download section. ==Debug Mode 2 April 2013== Added a debug feature. So far in this page the fuel injection time can be overridden. This is useful when adjusting fuel maps and testing. When the injector time is overridden then the fuel map and WOT map and temperature compensation will be ignored and only the given value will be used. This is to be used rarely, and only when tuning the engine or for testing different settings. This feature is available from Interface569 and firmware 1158. ==EZK Load Signal 9 April 2013== This was a bit overdue, but before the ECU did not send a EZK Load signal to the EZK computer. This resulted in the timing not being adjusted correctly according to load. The addition made was a simple 2D map, similar to the fuel map. The RPM intervals are 500RPM and the MAF voltage intervals are every 0.6V. This map is significantly more simple than the fuel map. There are also hard limits for the minimum and maximum signal that is sent. The signal is a PWM signal at the same frequency of the input RPM signal from the EZK. The values range from 0 to 255, with 0 being no signal and 255 being 100%. The EZK signal can also be completely disabled. This results in a 0 load signal. Here is a screenshot of the new tab in the Interface Software [[File:ECU-EZK.jpg|left|700px]] This table effectively allows the user to tune the EZK timing advance. The EZK can be programmed for different timing advances for different input signals. This allows exact tuning of the EZK timing advance. An extra field was also added to the Real Time Data tab to show the EZK load signal being sent at the moment.
Return to
Porsche 928 LH Replacement Prototype
.