Davidv

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.

It's a 32 bit single precision float.
so there are a few answers to the question.

https://en.wikipedia.org/wiki/Single-precision_floating-point_format

No, there are 4 terminals.  1 is constant 12V.  2 is the low current PWM signal from ecu. 3 & 4 are both constant ground (it differentiates signal and power ground but fine to connect them both to chassis).

Correct except there are 2 grounds.  And a GP PWM is lowside drive only.  But as I mentioned earlier these work fine connected directly to an aux out, they donot need a pull-up or anything.
You dont need the controller that mldc attached - this would be for someone that wants to control the pump without an ECU.
 
What diagram are you looking at? On the pump there should be a 4 pin plug, +12V, a power gnd, a signal ground and a PWM signal.  There is no tach output.
 
The G4+ PWM outputs cant do highside drive, only low side.  The Aux outputs already have a 1.5Kohm pull-up internally.  

That isn't the pump manual, The 500mA current specified is the maximum output of the TinyCWA controller, not the current consumption of the PWM input pin on the pump (which will be much lower).  You can control these pumps with either a high side aux, or if none available you could use a low side (I would add a 10k pull up resistor in the pump connector) 
Also, worth noting these pumps should be installed as low as possible and work best in a "reverse flow" configuration as they cannot suck air, and so will fail to pump if coolant levels are low and mounted in the top hose
HTH, 
Richard. 

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.

You can connect both 5v and 12v sensors (and VR sensors etc that have varying voltage output) all to the same sensor ground. 
The reason to chose 1 type of ground over another is not input voltage, but more:
1) how stable does the signal need to be for the engine to run well (crank trigger = really important, any of the temp sensors = not a big issue if the signal bounces around a few percent). And as part of this, will a ground offset cause an incorrect reading that still looks legit. (eg voltage offset on any analog sensor)
2) How much load is expected to go through the ground circuit. eg do not use a sensor ground as the ground side for a vtec solenoid or anything like that.
As long as everything on the sensor grounds is low *current* then adding a flex fuel sensor to sensor ground wouldnt hurt, and generally anything that is an ECU *input* you would lean towards putting on the sensor ground circuits. But if you do see issues that seem like sensor noise once you add it, you can probably move the flex sensor to use a direct ground and not see too many issues. These dont report an analog output anyway so should work just fine with slightly noisy voltage/ground.

Hello,
I have swapped the stock 3sfe to a 3sge redtop beams in my 1991 Toyota Camry and in the process of converting it to a 5 speed manual. So I decided to get a standalone system for it, got a link g4+ fury and need some help figuring out how to set up a base map/tune it?

Added "Custom CEL functions" a few weeks back, no ETA but it's in there.

I agree, it would be nice to have a more configurable driver warning light function.  Some ecu's I work with have a table or check list where you can select which situations or sensors will trigger a warning.  
@Davidv.  I know its not exactly what you want, but just in case you didnt think of this, I often do something like below to give the CE light output multiple functions:

 

Okay so there are a few stages to setting it up.
 
 
1. Wiring
Run one wire to the knock1 or knock2 wire on the link loom, and one to sensor earth, polarity unimportant. must must must must use shielded wire. The knock sensor outputs a very low voltage signal that's prone to interference.
2. Initial settings
Since you are using the 'wideband' knock sensor and an engine with an ~86mm bore has a knock frequency in the ~6khz range select your Freq Channel as 4-10khz Wide Band.
Set Ignition Retard limit to 0 degrees.
Set the RPM high and low lockouts however you like. (500rpm likely not ideal for the low setting)

 

3. Cylinder balancing
Your knock sensor is mounted closer to one cylinder than the others. It picks up vibrations, so the vibrations from that one cylinder will give a stronger signal than the others.
So what you need to do, is hold the motor at say 4000rpm (no load) and check the signal strength of each cylinder.
You can check the signal strength by pressing F12 to get to the runtime values screen and looking at these numbers, knock level cyl 1/2/34

 
 
See how in that example above, the numbers are 235 / 160 / 255 /145. You need to get these numbers as balanced / equal as possible.

You can adjust the values up or down by tweaking the numbers up and down in Knock control > Cyl setup > Cyl 1/2/34 knk level gain
 

 
 
Best to start with a value of 1 for the cylinder that's closest to the knock sensor, and increase the other values to suit. If one of the values reaches '2' (maximum) you can reduce some of the other numbers to less than 1.
4. Non knock noise levels
Since the knock sensor picks up vibrations, there are of course vibrations happening even when there's no knock. As RPM increases, the amount of 'natural' background noise increases too.
The ECU can tell that knock is happening, because there's an unexpected large spike in the 'noise' from the motor around the time of the iginition event. Soooo, you need to find out what the background noise level is for your engine.
According to the manual, a 2 row table with full throttle and 0 throttle is sufficient but this is up to you and how long you want to spend on it haha.
So head to Knock control > Knock target, right click on the table and select Axis setup to define your table similar to this (if you want)
 

 
Then you need to run a datalog through the rpm range at full throttle to see what the values are for this table. (and coast back down off throttle for the zero TP target, although I'm guessing not much knock happens at 0% throttle)
Open the datalog and bring up a screen to show engine rpm and the knock level global.
Knock level global has a maximum value of '1000'. If you find that you are hitting 1000, you need to reduce the Gain Channel number on the main knock sensing setup page to something a bit lower and try again. Remember that the '1000' has to be the maximum even including allowance for knock which is much stronger signal than the background noise so you need to allow headroom for that too.
 

 
Once you've established these background noise levels for the motor in your table, increase all of the numbers in the table by 20% to give it a bit of a margin against picking up normal engine noise as knock.
At this point, because you've set the maximum ignition retard to 0 degrees in your first step, the ECU isnt taking any action against knock.
Now that you've got everything setup though (unless I've missed a step here, haha) you can turn the knock sensing on by setting an ignition retard limit here, to say 3 degrees or 5 degrees or whatever you want:

Then as per reccomendations from the manual, it's best to test that knock sensing is working under a scenario that minimises risk of damage to your engine.
So you could drive along at low load / low rpm and induce knock by creeping the timing forward until it knocks and you can see from the runtime values table (F12) that it's working.
From here, it should all be working awesomely. (No responsibility taken for blown up motor though! This is just what has worked for me)

Hopefully it all makes sense though
Where are you based / what is the car used for? 
Keen to hear how you get on.

Accel fuel has been changed to a simplified X-Tau model

G4X solves this with a VA on the starter switch DI, but I do wonder if we need to move the start position function setting into the starter control settings. I'll put it to the engineers.

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

Is it possible to have a Math block drop down box with the maths all ready worked out? 

Done.
 
Should also be fixed.

So this afternoon I sat at the simulator and started mucking about with a few ideas.
I wanted to calculate my average speed based on some event, I used a digital input latching on.
In the UK we have average speed camera zones, you get snapped at the start and end and they do a distance over time calculation. Often you'll get slowed down by a Karen in an X5 not paying attention, I've always been curious how much I could safely speed up again to catch back up to 50 mph average over the trip.
You can do this in log analysis with the statistics view, but this is obviously operating at runtime.
So there's a few things here I've done that aren't documented yet, yes they will be.
The first is that maths channels can do reassignment, x = x + 1 etc
The next is that they're evaluated at 1000 Hz
Lastly I know of a few built in functions too.
I figured out two methods, of averaging, the first could be used not only for wheel speed, but for really any parameter, lambda, throttle position, you could use another maths function to find lambda, vvt, boost, etc error then feed that function into this one and have an average of error over some time period.
This one uses this algorithm:
newAverage = oldAverage + (newSample - oldAverage)/sampleNumber

the cnt function is a real good cnt function, it counts 1 per cycle (so 1 per millisecond) while c is greater than or equal to 1, so if you feed it a status which evaluates to 0 OFF and 1 ON, then you're away. If you want to use this for Anti-Lag active we might have to get a bit imaginative about an offset, iirc Anti-Lag OFF = 0, ON = 1, Active = 2...etc
I had to add a +1 to cnt because on the first cycle it's 0 and that's div by 0, plus the first cycle is the 1st sample too.
The 2nd method I came up with was to calculate distance, which of itself is a useful function, then calculate distance/time, again using that good cnt function:

Again using reassignment in the Distance function, multiply speed by 1/100th of a second, of a minute, of a hour to get distance travelled per millisecond (rate is 1kHz), I multipled by status to simply switch it on and off. This gives me km.
distance a over time, divide by the same multi as above gets us back to an average.
You don't need to use 8dp for this, I was just using it while getting my exponents sorted.
My functions agree with each other and track to my expectations, but if you spot an error in my maths then shout out
edit: unfortunately this is all in kph as I started running out of characters to add the mph multiplier, I've spoken with engineering and we'll see if we can get the length increased, 2.77e-7 helped a lot, but still lost a bit to parenthesis too.
 

As a feature request can we have the option on which Lambda sensor is used for CLL. 
As example I'm using 5 lambda sensors. One in the turbo dump pipe and 4 in the turbo manifold using a CAN module. The software uses a average for CLL but would be nice to use Lambda one so manifold pressure is not an influence. Currently to get around this from happening I've set the 4 CAN lambdas as CAN TC. 

Yep Multi fuel and traction control will be coming 

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!

Hmm, good catch.  It does actually work and display correct on a live ecu but they are going to have to fix that.  

Just fired it into the issue tracker, cheers @Davidv

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)

 

Even better would be to make a General adusment function for different tires.  For example setup a WET switch in the car, which switches tire diameter, rain light, DBW Map etc. 

Maybe in the X series? I can wait to check the new software