@@ Line 1: / Line 1: @@
-===Prototype===
+<metadesc>LH Replacement ECU Prototype</metadesc>
-The discussion forum can be found at [http://forums.rennlist.com/rennforums/928-forum/602152-plug-in-lh-replacement.html]
+<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]]
-I will provide more information later!
+[[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==
+) 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.
+) USB/Serial port on the board that will allow remapping while driving/dyno
+) 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.
+) 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.
+) Must withstand the "harsh" temperatures and EM interference that is present in a car
+) 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:
+) Idling
+) Fuel adjustment according to RPM
+) Adding MAF readings and adjusting to fuel map
+) Add support for engine temperature, safety fuel cut off, tank venting, flappy control
+) Add exhaust feedback support and support for 2 fuel maps - normal/WOT
+) Add communication with PC via Serial, followed by USB
+) Make fuel map dynamically changeable and make windows interface software
+) Dyno the car
+) ?
+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
+: 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}}
+: 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}}
+: 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|500px]]
+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.
+=New USB (LibUSB-win32) 22 April 2013=
+Ok, so far I have used serial emulation to communicate between the PC and the ECU. Not a very elegant solution, but its quick and easy to implement. Downsides were that the user needed to select the correct serial port before being able to connect. After connecting initially there was no problem and the user could forget about reconnecting. Well now I implemented a proper solution. The device now uses the LibUSB generic USB interface.
+I had to rewrite the code on the ECU to use the new Microchip USB stack and I used the libUSB-win32 port. Most of the time the USB port communication in Windows is implemented using static libraries, and compiled into the Interface Software but I prefer to use dynamic linking. By using dynamic linking I don't have to worry about any problems integrating it into Qt.
+New USB drivers are required when the new firmware is executed, as Windows detects a new device. After the new drivers are installed your Device Manager should have an entry like this:
+[[File:ECUNewDeviceManager.jpg]]
+With the new USB interface I don't have to rely on the slightly unstable Qt serial library. The coding required a complete rewrite of the Qt Interface communication protocol because the LibUSB implementation that I use is synchronous communication (vs. asynchronous with the serial emulation), requiring the Interface software to send a "Request for Data" instruction before reading the data. The Firmware required little change, seeing that on both instances I just empty the buffers that I use. On the firmware side I have 2KB buffer for receiving and another 2KB buffer for sending. That should be more than enough for any delays in data that can occur on the USB line. The windows interface uses 4KB send 4KB receive buffers because the way that Qt works there is more delays in the Interface software than in the Firmware.
+Difference in operation to the user now is that in the Interface Software you don't need to select "Connect" anymore, and all detecting and communication happens automatically. when you switch on the ignition then the Interface software will detect and connect to the ECU. The Interface Software also gracefully detects disconnects and reconnects.
+The USB code in the Interface Software is also threaded to allow for smooth communication.
+Another change that was made was the status message box. I changed it to fix an annoying memory leak (shame on me for it being there in the first place).
+On to more testing!
+=Adding Debug Tab 5 May 2013=
+Sometimes with tuning the car you want to completely ignore some values and override them with custom values to debug the car. A very good example is the fuel mapping. Sometimes to test the car and get exact injector timing you want to ignore the fuel map.
+For this purpose I have added a debug tab. At the moment there is only one override value, for the fuel map.
+a screenshot is shown.
+[[File:ECUDebugTab.jpg|500px]]
+=More columns in the logging tab 10 June 2013=
+I have added some more columns in the logging tab, these extra values are purely for debugging and testing and shows all of the sensor data that is being read. This will help with any sensor problems, as you can see real time feedback of the values that are being read.
+The columns are:
+*Date
+*Time
+*RPM
+*MAF Value
+*Engine Temperature
+*EGT Sensor
+*CO2 Adjustment POT
+*Injector On Time
+*Injector Off Time
+*Duty Cycle
+*Throttle Position
+*EZK Load Value
+*Fuel Pump Status
+*LH Relay Status
+*Flappy Status
+*AC Switch
+*Gearbox Switch
+*Tank Vent Status
+*EZKTime(debug)
+*AccelJet(debug)
+*Firmware Build(debug)
+*MAF Raw Value(debug)
+*Idle PWM Out(debug)
+*Current RPM(debug)
+*USB Buffer Count(debug)
+The debug values are used for software debugging and in normal usage can be safely ignored.
+=ECU Renaming 18 August 2013=
+I realised that calling this system the "Porsche LH Replacement ECU" is kind of infringing on the trademark of Porsche. So to avoiding any trouble I have remaned it to "LH Replacement ECU" or LHR Ecu. This should avoid any legal trouble. If it is infringing I will happily rename it more.
+I also added a bunch of micro bug fixes and optimisations. These changes are too small and numerous to mention.
+=Better Idling Control 27 October 2013=
+Thus far the idling has been a static value, and frankly it makes the car hunt while idling. To solve this I have reprogrammed the idle control. This also gives more flexibility to the user. Currently the idling can be adjusted from 500RPM to 1000RPM in 25ROM intervals. The general tab in the interface siftware was also rearranged a bit.
+Here is screenshot of the new and improved general tab.
+[[File:ECUGeneralNew.jpg|500px]]
+=More Real Time Data 1 November 2013=
+Seeing that I am debugging and testing the system more and more I found that I want more data to be displayed in the real time tab. So here is the new Real Time Data tab that I am using
+[[File:ECURealTimeNew.jpg|500px]]
+=Big Update and working system 1 April 2014=
+Ok, it has been a long time since I  updated. I went to South Africa for a holiday during February and March. This allowed me to do some major updates and testing. The result? A working and stable, reliable LHR ECU. I also went on a tour of South Africa with my girlfriend and this tour included a long road trip in the Porsche. Before I could do the road trip I did some changes.
+One big change was that I installed a wideband exhaust sensor that tells me the exact air to fuel ratio. Without this tuning the car is impossible.
+I updated some timing on the interrupts of the firmware. The USB were not loading fast enough before the car starts (by about 50ms) so I delayed the firmware by 50ms to compensate.
+Tuned the fuel map, I did not have access to a full dyno, so the tuning was done using the wideband sensor and driving. I got someone to drive the car while I tuned and checked the wideband readings.
+Some minor fixes, changes and optimisations were done. The result? One awesome car to drive! To test the car properly '''I drove 3800KM in the space of 2 weeks with the ECU on the road trip with zero modifications'''.
+To show off I made a proper video of the entire ECU as it is at the moment. This includes the Interface software, logging, opening the log and plotting graphs and finally driving with the ECU in the original ECU location. This replacement ECU fits in the original housing. The only visible difference between the LHR and the original is the USB cable coming out of the side. This can be easily tucked away behind the carpet, making it invisible and just like new.
+{{#ev:youtube|SYrvetwMzHc}}
+'''Stuff to do'''
+Closed loop control. The closed loop control is not programmed, at the moment the ECU works only in open loop mode. I do not have a narrowband (option on my car was without the sensor) and the wideband is not connected. I will not be able to implement and test this on my car in the near future, but any volunteers are welcome that want to test it if they have the sensor.
+Making  revised PCB. I have started designing the revised board, it will be smaller and a lot more power efficient. I also added the option of enabling more sensors to be connected to allow for easy mods and cstomisation.
+'''Selling prototype copies'''
+At this moment I can make copies of this prototype for people who want it. I need to have at least 5 orders to do a batch. The lead time is 6 weeks from date of ordering the components till delivery. The price? '''US$300+p&p'''. This includes cables and the interface software and future updates to the software and firmware. What it does not include is the housing or the LH Connector. I do offer the service where you post your current ECU and I will swap it out for you with the connector and put it inside the original housing, post it all back to you, your original ECU along with the replacement. Contact me for pricing on that. Another option is a different housing with a different connector. It includes the connector that goes on the wiring side also.
+My email is francois.louw@(this domain). Feel free to email me for information and requests.

Personal tools

Difference between revisions of "Porsche 928 LH Replacement Prototype"

From Francois Louw

Latest revision as of 12:00, 24 July 2014