Davidv

If you do that, arent you liable to get e-throttle errors if it over runs past what it thinks is the maximum/minimum allowable voltages? As realistically it's going to overshoot at some times.

One thing that's unique about E-throttle compared to a cable setup, is that its possible to smash the throttle into the end stops and damage the internals of it. (I've got a pile of busted e-throttle gears here somewhere...) So generally the solution is to limit the targeted travel to say 2% and 98% of the actual measured sweep of the throttle. But, its kinda weird looking through the logs when you see it's at 98% when really its 100% as far open as it should be. Or when it's at 2% that's really its closed position. So I know it sounds nitpicky but it would be cool if it could span from say -5% throught to 105% Or maybe on the TPS calibration you tell it to stay XYZ amount off the end stops. Then it stores that trimmed value as 0-100 but has tolerance for going say 2% or 5% over that, without triggering errors.

You can already do that too. You just open the log file manager tab on the side, and then click in the box for the one you'd like to overlay. Then it shows two lots of graph times down the bottom, you can move one back and forth if you want to try make them line up.

Imagine you had your bare engine block, and you hit it with a big hammer. And it went doooooonnnnggggggggggggggggggg like a bell. That's basically what knock does, and it's what you're listening for. The size and shape of your engine block changes the noise that it will make. (Primarily bore size) So it's not a case of setting it up based on what sensor you're using - it's about matching the sensor to your engine. As a knock sensor is basically just a type of microphone. There's a good article on knock sensing here: https://www.hpacademy.com/forum/webinar-questions/show/083-understanding-knock-1

Thank you

Hi, just putting together some math channel stuff where the numbers might get quite big. I am guessing that the largest number you can go to would be a signed 32 bit integer? 2,147,483,647 maximum? Or are they a 16 bit signed int? Or a float? something else. Also, what happens when you overflow this number? Will it stay at the max value, or bounce back to zero or a negative value? Thanks

Ahhh thanks, excited about this now! Will put this back higher up the priority list haha. Does the signal ground wire need to go to the signal ground wire on ECU? Or both to same place? EDIT: Ahhhh no I get it now, feed it 12v constant then PWM on the earth pin back to ECU.

Hi Richard, Do you mean it's as simple as connect 12v pin, earth pin, and then 3rd wire to to an aux output set to high side direct to ECU? Sounds too good to be true! I was anticipating needing to make a pump controller or using SSR to trigger that 12v signal pin. What do you do with the 4th pin on the pump, I was under impression this is essentially a pump speed tacho signal. So you can wire it to a DI. Is this correct?

Definitely put in the tested value. If you want really good accuracy though then it's good to have a fuel pressure sensor so it can work out the fuel pressure differential accurately. As mechanical FPR can fluctuate a little. Your deadtimes being accurate will be a big make or break for accuracy of your fuel consumption though.

Hey Jenova, I've run a redtop 3SGE for a long time with a G4+. Great engine! You can use the Altezza 3SGE basemap, and then just turn off the exhaust side VVTI options. I can give you some decent maps for cam timing / ignition / etc but will need to know what sort of load axis you are using. (MAP sensor?) If you PM me your email address, I'll send you a redtop specific map that you can start from. But keep in mind there are a lot of variables that you'll still need to fine tune yourself for your particular engine. I would reccomend that you switch to a set of Altezza injectors, if you can source them cheap locally where you are. Because I've got good accurate injector data for those, which helps a heap.

Cool! Thanks.

Hi, Just had a thought for an idea while thinking about a situation with an NA rally car. Being a very dirty environment in rally it's prone to clogging air filters and reducing performance. I had an idea that a set of virtual AUX could trigger a light as a "filters clogged" message. Like so: So it would trigger a light to say the filter needs changing. However - the ECU doesnt have any outputs left for a light. So I thought it might be cool if you could trigger a check engine light with virtual aux instead. You could use the label on the virtual aux as the message for why CEL has been triggered. Or, maybe as per OEM ECUs CEL you could have a list of 10 error lights. Then they will flash say 5 flashes in a row then long pause. For error 5. Maybe you could have a drop down "warning status" with the options off, trigger CEL, turn off CEL. So you could have a set of conditions contrary to above, on a second virtual aux which turns the CEL back off if conditions are met.

Ahhh thats a lot earlier than I was expecting! Awesome, cant wait.

You can do this already

Hi, Would be nice to have some extra options for starter control Clutch lockout So can only start if clutch is depressed. Speed lockout Cranking will be cancelled if the vehicle speed increases while the motor is cranking (Could happen because the car is in gear without realizing it) With a "normal" key, once or twice I've bumped the car forward by having it in gear without realizing... First reaction in this situation is to stop turning the key. So would be nice if ECU could do the same as a precaution.

Hi, Thought it might be a cool idea to, instead of adding correction factors to fuel seperately and ignition seperately. To be able to intercept/adjust the load axis value before it reaches the table to look up the fuel/ignition values. For example, lets say you are cruising along the highway and your car is running at bang on its target AFR. At a given TPS/MAP/RPM that is steady. But then, your intake manifold slowly heat soaks. This is happening after your IAT sensor so it cant be seen by ECU. So the actual mass of air entering the engine has decreased, but ECU has no visibility of this apart from seeing that the lambda value is incorrect. If you use closed loop lambda to trim the fuel, you are correcting the fuel amount but then you end up doubly far away from the ideal ign timing for that airmass. (timing stays the same but less airmass wants more timing, and then running it leaner back to goal AFR at less airmass wants more timing) However instead of this. If you use closed loop lambda to trim the load axis instead. So its like its pushing the MAP value up or down the table for both ign and fuel. Then it corrects both your fuel and ignition closer to whats ideal for the reduced airmass. So, you have a MAP value of 60kpa but then it looks at the table as though its at 55kpa.

That would be pretty cool! Like have a preset number of functions in there.

My ideas: Pump safety Fit a speed sensor onto a dry sump pump. Pump speed / engine speed If the number goes out of bounds you pump has jammed or belt has broken. So you can see a fault before oil pressure needs to drop. Coolant capacity % Will experiment with this but essentially ( ECT - IAT) / (rad temp) x100 So will fiddle with this a bit and try get a number that represents your remaining cooling capacity even when ECT is stable. So you dont need to see ECT climb to know youre nearing saturation point. Could be handy for EWP logic. L/100km & km/l Self explanatory. Need modelled fuel BSFC Need a dyno that outputs a hp figure connected with canbus. Also modelled fuel. But can tune an engine for best bang for buck. Which is otherwise difficult to see. But good for endurance cars etc. Ignition time to 14 adtc (Ign adv + 14) / rpm Shows time period to reach where peak combustion pressure should happen. So could use as an axis on a table that trims your ign timing with afr variations, leaner mix needs more timing and vice versa. But it would be nice if there was just an option to show timing as miliseconds anyway as this makes simple trim tables way more useful across a large rpm range

A % trim has been added in the X software Thats a very cool idea!

Just a note If you go to add calibration data to a sensor, use Cal table 1, if you space them apart at say 0.5v, 1v, 1.5v etc It ends up reverting to full numbers and then does weird stuff if you look at it in the map view by pressing K So the cal tables need some bug fixing to be usable (unless it's a quirk of this empty basemap)

1000hz! Wow thats awesome +1 to the above, lots of awesome changes looking forward to having a play around when some of the bigger brother models become available. The math block functionality is just crazy. So many possibilities!

Thanks, was just about to ask. Haha Logging speed on the ECU screen only shows max of 1hz, 0.5hz, 0hz... Is the max logging speed any different to G4+? 100hz still ?

Have found that setting the injector timing to around the 220-240 deg mark (so spraying injector when valves are open) helps on cold starts to reduce how much enrichment you need. Tested this only with petrol, but had a friend test with E85 and said it made a dramatic difference. As in, cold engine now drivable where previously he had to let it warm up before trying to move it.

Or an X-Tau option would be super cool too.

Currently the gear detection, rather than being a calculation of engine RPM / wheel RPM It's calculating engine RPM / KPH. Which works fine unless you are changing rolling radius. So for example if I change from road tyres to track tyres which are a different size. If I adjust my speedo signal calibration to the known correct value. Then I have to redo my gear detection because the RPM/KPH has changed. Even though the Engine RPM / Wheel RPM is exactly the same of course. So would be nice if it could be separated out so adjusting the speedo calibration doesn't affect gear detection.