Jump to content


  • Content Count

  • Joined

  • Last visited

About f8.

  • Rank

Recent Profile Visitors

670 profile views
  1. Agree with T4700: "ensure the most efficient combustion". Would like to add with statistically significant (large) samples. If we apply the approach of iterating the fine tuning of fueling via the use of lambda with real-world driving data, why can't we attempt the same with ignition? As a simplification, lets say we adopt an imaginary equivalent of lambda metric for knock, called k where k=1 ideal level of knock, k>1 too much knock, k<1 too little knock. For any given load-rpm site, lets say we can reliably log k and automatically step ignition advance/retard by say 1 degree based on each log file's statistically reliable number of samples, won't that iterate towards the most optimal ignition table. And beyond, we might even have a self tuning capability for ignition(by looking at k) in the same vein as idle control(by looking at rpm) or boost control with proportional and derivative gains. Maybe this is already done?
  2. Yes very neat! I'm just running an Atom so Knock control is unavailable to me, but for the more advanced ECU's with knock control, is this coupling between logged knock values and target with option to correct ignition table available? ie the ignition version of this fuel tuning method.
  3. An example of the Mixture Map tab where if you right click it has an option to Correct Fuel Table based on Target and Actual Lambda values. Myself I post-process the logs with a data analysis program called Matlab and it then re-writes a new tune file but I guess this does the same. So tune files iterate with more logs with the aim for error to reduce down.
  4. f8.

    Motec M800 to G4+ plug in

    Hi Michael, I did just that but you need to note that in terms of RPM*Load, Motec supports 40*24 whereas Link does 22*20. If your existing M800 maps exceed 22 rpm sites and 20 load sites then you must first decide what your new rpm and load sites will be which fits within Link's 22*20. Open your latest Motec tune map and change the fuel and ignition axes (hit 'A' for axis setup when in fuel and ignition maps (hit F5)). Then once you entered them all in and click OK, Motec will ask if you want to interpolate the values, hit Yes. From here, click Tool-Save Table and save the fuel and ignition maps as csv (comma separated variable) files. Go to PCLink, setup the exact axes (hit 'X' for axis setup when in fuel (F) or Ignition (I)), and then right click on map, Import/Export-Export to File. Open the Link .lte files with notepad or your favourite text editor, then cut and past in row by row from the Motec csv file onto the .lte file and re-save under a new name. Note that the .lte file has all the values in a single line by going across entire rpm range for each load site in ascending order. Once done, go back to PCLink and right click on map, Import/Export and select Import from File. You should see that all your previous Motec values are now in the Link environment. Last but not least, upload that file onto your Link ECU. You may also need to recalibrate the trigger with a timing gun and adjusting the offset in PCLink. Hope this helps. Foo
  5. Thanks Simon. Agree on the need for going to higher end. For me at least I'm new to Link and came from more than a decade of Motec M800. I was really attracted to the Atom by the price and bought 2 at a go. 1 to take over the M800's role and another for this piggy-back function (which was a 'just for fun' after thought thing). Will let you guys know what I think of the baby Link vs the grandpa Motec . The point is had there not been an entry level like the Atom, I might never have explored beyond Motec onto Link (playing with PCLink convinced me you guys knew what you're doing and sealed the deal). So whoever came up with the Atom strategy is a bit of a genius! (And I'm pleading for Atom to lose 2 resistors....)
  6. Thanks Dave and David. Yes it does seem like extra set of temp sensors is the solution. Just wondering if Links have any comments on this. In terms of product positioning, it would be ironic in the scenario of a piggy-back where not many inputs and outputs are required, the Atom should be ideal; Yet 2 of the already limited inputs on the Atom can't be used without duplicating temp sensors and the Storm/Xtreme needs to be called in. But in that case, wouldn't it be better to have Storm/Xtreme replace the stock ECU completely? Maybe an Atom Piggy-Back version?
  7. Hi, I'm using the Atom as a piggy-back and would like to know if I could remove the pull-up resistors for the AnT1 and AnT2 inputs please? Unfortunately all 3 An V inputs are being used. Failing which, what would happen if 2 ECU's pull-up the same thermistor sensor? If the other ECU also has a 1kOhm pull-up, this would make the Atom always under-read the temperature with NTC sensors? And lastly, assuming the above situation, could we then program eg Cal Table 1 to compensate for this? Sorry for the many questions but just thinking out loud what the possible options might be. Thanks, Foo
  • Create New...