Jump to content

Davidv

Members
  • Content Count

    258
  • Joined

  • Last visited

  • Days Won

    24

Davidv last won the day on April 23

Davidv had the most liked content!

1 Follower

About Davidv

  • Rank
    Advanced Member

Recent Profile Visitors

1,827 profile views
  1. An example: Going through the options it looks like MAF is the only one with this quirk. I want to run one of the more modern MAFs which has a humidity sensor. The fact that Humidity outputs as a frequency isnt a problem at all, as theres no input for humidity so its frequency will just be a load axis on a trim table anyway. But the mass air flow signal is digital too, and mass air flow being mass air flow is pretty critical for the rest of the modelled fuel stuff to work nicely. If a frequency based maf doesnt work, not the end of the world to be honest.
  2. The scale on the cal tables can only be volts or resistance... What do I do, for a DI when a cal table has been set?
  3. Davidv

    programmable logic

    I know its a bit of a bodge, but I've done this by using CAN inputs and outputs. You can output variables over can, do maths/programming/etc on your canbus device using the information, then send the variables back into the ECU. I do this to log a litres per 100km parameter into the ECU so I can view it in the logs with everything else (only cc per min is available otherwise) I've also used a canbus input as the load axis on an ignition table and had my device trim the ignition timing with more logic than is available on the ECU. Check out Teensy 3.6 and the IFCT library for it.
  4. What's your load axis currently? If you are using MAP you might find its beneficial to switch over to a TPS based load axis at lower load where map is unstable. Out of interest do you have any logs you could post up? And what kind of intake is on it?
  5. Since that last post spent a bunch more time working on the dash. Been trying to keep an 80s sort of theme to it while looking somewhat like it belongs in the car. It's now at the point where all of the factory dash plugs fit straight into the back of it, it uses some opto isolators to input all of the standard dash things like indicators, high beam, etc. It's got auto dimming on the screen which works great. It can log to SD card, read it back and draw XY plots or histograms or whatever. Learning a lot about interface design, and minimizing distraction. Although it looks plain with only a few things on it, when you turn on an indicator (or whatever) it flashes on screen as you'd expect. The digits for temperature turn yellow then red as you cross a certain threshold. Also building some contextual screens so that it shows you different information when you're racing vs cruise control turned on vs normal driving. Or whatever. So for example, when racing you only really want a tacho bar going from say 4k - 9krpm and only want to see temps or pressures if they're a problem. So show minimal stuff. If you've got cruise control turned on, you're likely more interested to see fuel economy data, estimated remaining range, trip meters and so on. Has been a bloody long project but feels good to be at the fun part instead of battling with trying to learn programming, trying to learn canbus, trying to learn arduino etc all at once! In other news I tried an ITB setup but results seem to indicate less power than factory setup at best of times, and when heat soaking, significantly less power. Sounds completely obnoxiously loud and looks cool though haha. Currently making a few different trumpet designs, will dyno to see which works best and then see what I can do to build an airbox around them to mitigate the temperature issues. But in the meantime, back to standard plenum because I quite enjoy the E-throttle/cruise control, and, well, it looks to make better power too!
  6. Your mixture map is whatever your fuel table is. If you have two fuel tables, you need to go into the options and switch to that instead.
  7. This isnt a Realdash forum, Link dont make it... Maybe contact them directly to see what support avenues they offer.
  8. Davidv

    rough idle help

    If youve got aftermarket cams you might be getting some overlap which makes your map signal unstable at idle. You could make a second fuel table that uses a virtual aux as a switch, so switches to an idle fuel map that's TPS based when you're below say 2% throttle and 1500rpm.
  9. So long as the RX8 outputs two APS signals from the pedal then it will work fine that way. ECU just wants 2 TPS and 2 APS, doesnt care where they come from. Yeah you can setup a table to vary the e-throttle angle based on cold start etc so no ISCV needed. Just something to note, make sure your normal throttle map keeps the throttle plate away from the end stops, like if right to end stop is 100% travel then only go 98% or whatever. As otherwise you break e-throttle gears if it slams the stops (been there done that) If that e-throttle setup has an electromagnetic clutch like the Altezza system does, then you can run a PWM to it to soften the clutch near the end stops to reduce chances of damage.
  10. No you can only physically advance the pulley that far, everything is working correctly.
  11. ISCV is too slow to really be useful for quick changes in closed loop, you really need to get your fuel dialled in nicely and then ignition trim is the best way to keep it stable in my opinion.
  12. Okay so here is why I switched back to a MAF from a MAP based setup. When you are at part throttle and have cam overlap, the low pressure in the intake manifold pulls some exhaust gas back into the cylinder and intake manifold. The more advance you have at lower load, the more this happens. It's good for economy, but unfortunately when intake manifold pressure is the load axis it throws things out of whack. Because you are measuring the pressure with the assumption that all of the air in there is fresh air giving you a certain amount of pressure. When you have some internal EGR happening, for a given MAP reading you want less fuel and more ignition timing, but the ECU sees a higher map reading so puts in more fuel and then less timing. When you use a MAF as a load axis, it only ever reads fresh air coming in, rather than making assumptions about the composition of the gas inside the manifold, so its always way closer to correct. As well as the multitude of other accuracy benefits that a MAF has. This is on a single VVTI beams 3SGE engine.
  13. I've been in two minds about this, currently with a MAF based tune on my engine (NA Toyota) I've got TPS as the load axis for VVTI. But I think with a MAP based tune it makes more sense to have it on same load axis as your fuel, because unlike MAF, MAP has no way to tell how the VE of the engine changes with cam angle. But the catch 22 here is that changing the cam angle can change the map reading at part throttle so it's a bit of a circular reference. Realistically I doubt you'll have much trouble using either.
  14. Hi, Currently with mixture map you set a threshold so that samples within say 25% of the centre of a cell vertically and horizontally. This pool of results are used to contribute towards an average value in the centre of the closest cell. However this means that you've got 25% variation of rpm and load, contributing to a static value in the centre - and you need to throw away 75% (?) of recorded values. I have another idea that can let you use all of the data instead, and improve the results. For simplicity's sake imagine a 4x4 grid, and our current load and rpm point is 25% of the way towards the lower RPM value and 25% of the way towards the lower Load value. If we interpolate these values, as per what the ECU does. Note: I have just titled the columns and rows with percentages to show what percentage of the each cell we are interpolating from. We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 40) = 0.625 + 6.075 + 3.75 + 22.5 = 32.95 is the table value that interpolation produces. Now lets say that you wanted to add 10% to this value. If we just adjust the closest cell by 10%, as per current Mixture Map strategy. Then our bottom left cell changes to 44 so our table now looks like this: If we do the interpolation again, but with the new value to represent running the car again after the update: We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 44) = 0.625 + 6.075 + 3.75 + 24.75 = 35.2 as the new overall value. Which is only makes 6.8% difference to the interpolated value, rather than the 10% we wanted. On the other hand... If PCLink De-interpolated the 10% that it wants to add. Instead of adding 10% to the one cell, we split the 10% addition across the 4 cells based on the same percentage that the value was interpolated from initially. So: Top left cell: (10 * 1.1 * .25 * .25) = 0.6875 Bottom left cell: (30 * 1.1 * .25 * .75) = 6.1875 Top Right Cell: (20 * 1.1 * .25 * .75) = 4.125 Bottom Right Cell: (40 * 1.1 * .75 * .75) = 24.75 = 35.75 is the table value that de-interpolation produces. We were trying to add 10% and this new value produced is 10.5%. So that's pretty good! (The 0.5% error comes from rounding to 3 decimal places in my example) So it's accurate to the provided data in every instance. Which is especially relevant when it's applied 1000s of times across all of the cells. You dont need to throw away any of your recorded data, it all contributes to the cell values. Mixture map is pretty good for roughing out a map initially but because of the inaccuracies of the "nearest cell" method I don't really use it that much anymore when trying to dial in a fuel map. You always overshoot or undershoot unless you set your cell tolerances impossibly tight and have millions of samples. And, since this is all only done in PCLINK rather than the ECU, there's not really any worry about the overheads of the extra maths involved. It's worth having it chug away for a few minutes longer if you can get an awesome result on first or second iteration of Mixture map logging. So - that's my Friday night suggestion. Thanks for reading if you got this far, haha.
×
×
  • Create New...