mapper

The only reason to run a 4 port or dual 3 ports is if you need a wide range of control values and can't get what you need done with a more simple single spring and single 3 port that will control up to a bit over double that base spring pressure - a 10psi wg spring can typically have good control up to 22-23psi boost and a 1 bar 14.5psi spring can have good control up to 35psi boost.   If you need a 10psi spring to have control up to 50psi of boost, then it makes sense to go to a 4 port or dual 3 port.
4 ports do have pretty terrible resolution for closed loop control in my experience, but seem ok-ish at open loop.  When doing dual 3 ports, I see a lot of recommendations to wire both 3 port solenoids to the same output which in my experience still ends up with poor resolution.  The way I would do it with dual 3 port solenoids is: 1 output runs your upper solenoid with boost control function as per normal single solenoid tuning.  The second solenoid is wired to a separate output using a 3D pwm table with boost target as the primary axis (versus throttle or rpm or whatever similar to your regular boost target table in the boost control menu) - as you run out of duty cycle to achieve your primary boost targets with the first solenoid, at that boost level you set a fixed duty cycle on the lower solenoid to give a bit of restriction to the opening side as necessary to give the first solenoid the ability to control boost. 

Hi,

Is it possible to filter data in an X-Y plot?

For example, RPM (X) vs Lambda (Y) with MGP as the colour axis. I'd like to be able to filter out values below a certain MGP. In Motec i2 you can just click on the colour boxes in the legend to switch them off. I'd attach a pic, but my attachment limit is 20kB.

Cheers,
Ryan

Some OEM's high side drive the VTC solenoid (Honda and Subaru) but there is no specific need to, just what they chose to do.  Some of the early Vtec hondas (B serias and possibly D series) they had a single wire VTEC solenoid where one end of the coil is grounded through the body so the ecu needs to switch the positive side.  But still a half bridge is not needed, just a high side drive or more commonly just a relay.
I suspect where the confusion is coming from is just the loose use of the term "half bridge".  Motec for example call their aux outputs "half bridge outputs" just because they are capable of high side or low side drive, but you dont use them as a half bridge to drive a solenoid.  They only work in half bridge mode if set up as a stepper motor drive or in a pair for E-throttle (but when 2 half bridges are paired like this it is usually called a full bridge).  
On the Xtreme Aux 5-8 are half bridge outputs, but we dont call them that as the only time they actually work as a half bridge is when set up as a 4 wire stepper.  For all other functions such as VTC or idle valves they only function as low side or high side drives. 
 

The amount of retard you get is based on 3 factors.  "Knock level detected", "Ignition Retard Gain" & "Knock Trim Gain Table" - these are all multiplied together.  
"Knock Level Detected" is Knock level - Knock Threshold.  So in your first example on cyl 1 you have a knock level detected of 0.62 (1.62-1.00), your Ign retard gain is 1.00 and knock trim gain table is 1.  So you would get 0.62 x 1.0 x 1.0 = 0.6deg instantaneous retard.  
In the second example on cyl 3 you have a knock level detected of 0.18 x 1 x 1, = 0.18deg (truncated to 0.1deg).
With normalised mode a knock event will be a significant spike above the threshold so your retard would be more significant than your examples.  Looking through my maps with normalised mode I usually have a retard gain around 2.0-2.5 and my trim gain table is just 1.0 right across.
Below is an example pull from our subaru where I have put an extra 5 deg advance in a single cell in the ign table at 3500rpm to purposely make it knock (you can see where Ign angle bumps up as we pass through), Cyl 4 knocks, the ecu instantly pulls 4 deg out of cyl 4 and you see after that the cyl 4 noise level drops back below the others.   
Threshold was 2.8, knock level was 4.64, gain was 2.5 (I have the retard limit set at 4 in this car).

 

Hi all. The alternator control seems to be working well on my car, but I've noticed that it has momentary errors up to 0.8v when accessories are turned on/off. Could it be possible to add load offsets similar to the idle control offsets? This way we can increase/decrease the duty cycle on expected demand?
Another consideration could be adding dedicated targets for charging, overrun, idle and full throttle. Having one target and base table doesn't allow for having multiple of these at once easily.

@tbase
I will first explain a couple of things as there are two different parts of the shift involved here.
First the unload for disengagement:
With a car on tarmac for example, to make an upshift you briefly cut ignition, this suddenly reverses the torque load on the dogs because you have gone from "engine driving the wheels" to "wheels driving the engine".  The dogs are easiest to disengage somewhere just as this torque reversal starts to happen. 
In contrast, on a low traction surface when there is significant wheel spin, when you cut ignition to make a shift all that happens is the wheels just slow down closer to the speed of the road surface - there is no complete reversal where the road surface is driving the wheels as it does in the first example.  So typically you need a longer cut to get enough unloading to allow the dogs to disengage.
Generally for this dog unload stage you want as much torque reduction as possible (usually 100% cut).
 
Now, engagement of the next gear:
What you are trying to achieve during engagement of the next gear is to have the dogs on the engine side turning at a similar speed to the mating dogs on the output side so that they have the best chance of the dog making it into the mating gap - and as gently as possible.  If the speeds are significantly different the dogs will just sit there grinding on top of each other or they will actually make it in with a very harsh impact, or they will make it in then bounce straight back out from  heavy impact.  With traditional gear shift strategies you had a fixed cut percentage that was present through the whole shift so it was a balance between getting enough cut to unload/disengage, but not so much cut that the input/output shaft speeds were vastly different.  This was especially an issue on rally cars where the disengagement might need a long cut, but then once disengaged the engine speed was much lower then it needed to be.
 
Related G4X improvements:
The disengage part of the shift (called dog unload) is now separated from the engagement part (called main shift stage), so you can have the 100% cut for best unload and less cut for the engagement stage where you just want enough cut to get the shaft speeds to be similar.   There is a shaft speed matching option, this uses the gear ratios and (optionally) driving wheel speed to calculate what engine RPM is needed to match the shaft speeds for engagement, it will vary the amount of cut to achieve the target.  Using the "gear ratio and speed" target calculation means if the wheel speed changes during the shift then that will be taken into account by varying the target RPM to match.    
I dont have a lot of personal gravel experience but probably know enough to offer some suggestions if you give more detail of the car.
 
@Ronague  I tune a couple of sports cars with geartronics paddle shift controllers on them so can speak from experience with both - I dont think geartronics have any real advantages over G4X now in terms of shift quality.  They do have an autoshift option (but pay extra to unlock) for paddle shift setups that we dont have yet and they have a couple of extra failsafes that we dont have yet such as dual track gear position sensor monitoring.  And in some ways I do kind of like their visual "barrel rotation" GUI thing with all shift settings related to "degrees of barrel rotation", but that's about all.  They can do a nice shift.  Negatives: Analog inputs are quite low resolution, they can only detect about 0.05V change and dither about 0.1V, logging is horrible, documentation is non existent, software is very buggy. 

In short, absolut no. In fact the upersit is the case. The latest gearshift strategy in the g4x is much more advaced than any external gearbox controller I have seen (incl. Geartronics). Checkout the the?gearshift strategy in G4x. Its fantastic?and works like charm. Give you set it up correctly.
I highly recommend to use a strainge gauge and a barel position sensor on the gearbox. Additional a whelspeed sensor and e-throttle helps for perfect autoblip downshifts.

It's always difficult to shift a sequential box with spinning wheels. I highly recommend to use wheelspeed and adaptive cut control. This adjust cut level depending on input/ouput shaft speed.

Gsum = x + y + z accelerometer channels

It can be used to get an idea of much of the available traction a driver is using.  Think traction circle.

Regarding Lambda control error correction table. I spend alot of time to tune these. The base map is adjusted the wrong way around. Because the error correction tables is a % corretion of actual error, you want big corrections like 15%  on small errors (0.03 lambda error) and small correction (like 5%) at the biggest error on the table. This is because a fuel film built up first in the ports when big correction are applied. This means it needs several burn cycles to get the whole change applied and measured. This means lambda control applies big changes two or three times for big corrections which leads to Lambda oscillation.  On small changes fuel film built up is much less.  Lambda change is done and measured much faster and within same burn cycle. This means the Lambda correction can be set much higher, because the change in AFR is measured instant.
I have attached a tuned example.  

Absolutely. Here's what I'm envisioning for the inclusion and overall enhancement of .DBC integration and CAN transmit/receive streams. In my project, I'm effectively integrating all the OEM controls into Link. I've created a basic example where I'm sending engine speed to the OEM gauge cluster. To do this under the current setup, you have to create a stream, create a frame, manually select the parameter tied to it, then add all the scaling, factor, offset, position etc. 

Obviously, all this information is embedded in the .dbc's format and can be found (for example) by opening a .dbc in Notepad++ or a legitimate .dbc editor like Vector's CANdb++ editor (example below): 

In my eyes, it'd be great if we could import a .dbc and have each message & signal go to a folder under CAN in the "ECU Settings" menu. Then, using the existing CAN setup we'd select the Message ID which would import all the relevant signals into a CAN stream. Then you'd parameterize "DME_RPM" (in this example) with the PCLink's "Engine Speed" parameter. Done. That would definitely make a huge difference in the level of work I'm trying to accomplish with Link (basically a full ECU replacement w/ OE CANbus functionality). 
Another great feature would be the easy ability to inject CAN messages with user supplied "raw" data. I know this is possible through the use of math blocks, but it's very clunky. Something like this, would be an epic feature: 
 
Basically, you choose the message ID, when it would send (so on ignition on etc.), the cycle time, and than you'd choose the raw data to send in hex format for each byte. 

Hi Vaugan 
Basicly i should allow everything you mentioned. 
Export.DBC file with channel names, unot etc. So it can imported in another software. A typical application is a custom dash stream. Setup all channels on ecu > export .DBC > import on AIM Racestudio > select new stream in Race studio in config > Done ✔️
Import: 
Again with the Dash example
Setup the CAN output stream on Race Studio > Export .DBC in Race Studio > Import to PC link > PC Link opens a Mapping Window to map the AIM naming to a PC LINK Can Input channel. Naming should taken over from the .DBC (e.g. CAN Input - AIM name). This would make it much easier to setup custom streams between CAN devices. It's in fact for what .DBC files habe been invented. It works really good between different Mfg. Devices. With Enumerations plane text can be assigned to channel numbers. So for example for fault code count, the enumeration text is shown on the dash when a fault is active instead of just a number. Makes it 300% more user friendly. 
Where I also see very big potential is syncing everything between LINK ECU and PDM whith DBC. In- and export. So the naming is right in the datalog. Means it shows something like "PDM HP 1  - Fuel Pump". ATMO we only see PDM HP 1 in PC link and need to check the calibration on the pdm to know whats connected there. 
On a a later stage idealy Link is aible to generate new channels and can take over 1:1 everything from the .dbc. File. ( think thats what you meant by Dash style). I usually define all my reverse engineering findings in a DBC editor. Once done I import the .DBC into the can device. An in theory everything should work straight forrward. 
It would be very useful if there is a CAN sniffer function on PC link and PDM Link So signals can be spot, defined in the .dbc and ploted in PC Link. Thats whats needed for reverse engineering. And is the feature. Or I should sayn it's now, because everything works with CAN nowadays.  In a perfect world there is a test transmit function also, to send byte streams to the bus (usually to test if something is activated trough the oem bus) 
I will send you much more ideas and feedback as usual via mail.
BR Adrian, Maptec

Basically, the .DBC file is the raw communication protocol. Means it only define the raw communication format on the lowest layer. All higher layer protocols like OBD, UDS as well as functions like checksum etc. are not defined and are rules that must be handled separately. So for now I would concentrate on the lowest .DBC level.  Basically every car, tractor, industry device manufacturer works with .DBC editors to plan and setup their communication networks. One of the most used tools here in Europe is Vector CAN++. A huge tool for very big CAN projects. 
I think also .DBC file import with a mapping function is well worth, assigning the Link CAN input channels is no big deal. But manually typing all names, offsets, multiplier, etc. is time-consuming and very error-prone. Also for you guys it will save good time in the long run. For example instead of working out a CAN template for 3th part CAN expander and add a template into the software, LinkECU user can just import the .DBC file from the 3th part device.  
 
Vaughan:
- Import function as you described sounds great. Check out the DBC. file import function on Motec's Dash manager. Found it well-made.  In the actual software Can values can only be logged if they are assigned to a ECU CAN Input. It would be great if on next gen ECU (or maybe already on G5) everything on the CAN can be logged, even if the channel is not assigned to a ECU function. With GPS coming on G5 and the 1000hz logging we have now, there is no reason to use any other logger in the car. So the usually Logger on the Display, we use for driver and chassis analysis, can be saved (and the budget spent into a more expensive ECU ;-) ). 
- Multiplexing (Compound). It is available in the .DBC standard and should not be a problem. I found Kvaser Database Editor 3 easy and very straight forward to create .DBC files. Might give it a go. I can send you some example .DBC files. It would be awesome if PC Link CAN setup has the columbs added as in database editor 3,  so you basicly setup the dbc, while you cofiguring the Link CAN. And btw. it would really help to have notes and enumerations to each parameter. For things like counters setup by a Math channel (just like Adam postet it today in another treath). So when you come back later, it's clear for what I was setup.  
- Enumerations: it's not  necessary to have user definable Enumerations in the beginning (of course, would be nice). Just the Link channels Enummerations could be packed into the .DBC file. For example, parameters like "Fault Code". "Antilag-State" should have the corresponding Text put into the enumeration slots of the .DBC. Basically everything should already been there. The CAN test calculator shows all the number>Enumeration(Text) translation. 
- Yes, I usually set up a separate .DBC for transmit and receiving. I'm not sure if there is a combined format available and also have not played a lote with notes in .DBC editing softwares. 
- Can Sniffer would be awesome. Also for PDM Link. Even if it is a basic list of traffic it will be quite useful for quick checks.  Second importan function for me is a static ID list with live data, so it's easy to spot what changes if for example a buton is pressed. Ideally recent changed are coloured like in Savvy or CAN Hacker Carbus Analysis software. On a next step you could basicly add all the function what Carbus Analyzer has. 
 
Adam: 
I found a lot of aftermarket devices support .DBC and find it a huge time saver. For example, I wrote the whole Link generic Dash Stream in Race Studio manually + additional channels in AIM Race Studio, 2-3 years ago. Manually typing in all channel names, offsets, etc. is just a waste of time. On top testing all channels for right format needs some more time. 

Regarding floating point, the raw can messages are sent always in binary form, which are then converted to hex or decimal. Significant figures are  handled by multiplication / divisor. The internal dataformat used in the receiving/transmitting device is depending on the device, so it would not make sense to define that in the communication protocol (.DBC). The same holds true for the content of the message. So all counter, checksums, CRC etc. must be generated by a function in the Receiving / Transmitting device. 

Ok, counter 1 will just need the timer2 changed to 0.16s to make the count cycle 0-3 instead of 0-255.
For the mux there are several ways you could do this, below is the option I usually go for as it allows fairly complicated sequences to be generated:
I would use a math block to divide our "counter 1" by 3, with decimal places set to 0.  This will give us a 0 result for counts 0,1&2, and a 1 result for a count of 3.  

Now if we consider our MUX decimal value of "37", in binary it is 00100101. 

 
So in our CAN message we can just place the "math block 3" which generates a "0 or 1" in the 3 bit positions where we would have a 1 in Binary to generate dec 37.  

 
Broadcast result (counter in first byte, mux in 2nd):


 
Note also if you have relatively complete CAN information for these vehicles we could likely hardcode this into the firmware as a preconfigured stream in the dropdown selection if you were happy for every user to have access to it.  
 
 

Hi Vaugan 
Basicly i should allow everything you mentioned. 
Export.DBC file with channel names, unot etc. So it can imported in another software. A typical application is a custom dash stream. Setup all channels on ecu > export .DBC > import on AIM Racestudio > select new stream in Race studio in config > Done ✔️
Import: 
Again with the Dash example
Setup the CAN output stream on Race Studio > Export .DBC in Race Studio > Import to PC link > PC Link opens a Mapping Window to map the AIM naming to a PC LINK Can Input channel. Naming should taken over from the .DBC (e.g. CAN Input - AIM name). This would make it much easier to setup custom streams between CAN devices. It's in fact for what .DBC files habe been invented. It works really good between different Mfg. Devices. With Enumerations plane text can be assigned to channel numbers. So for example for fault code count, the enumeration text is shown on the dash when a fault is active instead of just a number. Makes it 300% more user friendly. 
Where I also see very big potential is syncing everything between LINK ECU and PDM whith DBC. In- and export. So the naming is right in the datalog. Means it shows something like "PDM HP 1  - Fuel Pump". ATMO we only see PDM HP 1 in PC link and need to check the calibration on the pdm to know whats connected there. 
On a a later stage idealy Link is aible to generate new channels and can take over 1:1 everything from the .dbc. File. ( think thats what you meant by Dash style). I usually define all my reverse engineering findings in a DBC editor. Once done I import the .DBC into the can device. An in theory everything should work straight forrward. 
It would be very useful if there is a CAN sniffer function on PC link and PDM Link So signals can be spot, defined in the .dbc and ploted in PC Link. Thats whats needed for reverse engineering. And is the feature. Or I should sayn it's now, because everything works with CAN nowadays.  In a perfect world there is a test transmit function also, to send byte streams to the bus (usually to test if something is activated trough the oem bus) 
I will send you much more ideas and feedback as usual via mail.
BR Adrian, Maptec

With Can Sniffing function, DBC file creation, In- and Export should be added, too.

Dream comes true 

AL Fuel cut is waiting on testing

G4X can still do individual cylinder knock control with wasted spark ignition (or even with a distributor and single coil…), provided it has a trigger system capable of 720sync (the evo has).

G5??? Please tell us more about it!

The typical method of hysteresis would be (temperature > lower value AND output already on) OR temperature > higher value.
So use a GP Output for each feeding into virtual Aux's and then a GP Output that takes both the Virtual Aux statuses and feeds it into the actual output or feed the Engine Fan output into a Virtual Aux, use a GP Output into a Virtual Aux for the IAT and then a 2nd GP Output that looks at the engine fan status or engine fan Virtual Aux and the IAT GP Output Aux.

That's not too unusual in my experience, most likely some type of intake resonance as you pass through its natural frequency.  OEM's try to make this "sweet spot" as wide and flat as possible but with aftermarket parts, changes to intake and exhaust systems, different cam profiles etc it tends to become a bit more random.  Resonance in the fuel rail can cause a similar effect but it is usually "sharper".  Your fuel pressure looks ok to me in the 40Hz PC log, but try ecu logging ANV8 raw voltage at 500Hz to get a better idea if fuel pressure is contributing. 

You are not going to be able to get an acceptable flex tune by fumbling around adjusting random stuff blindly.  It is a reasonably complicated process that needs to be done with a specific routine to end up with a decent tune.
All input data must be correct - inj flow rate, deadtimes, fuel press, densities, stoich ratios etc.  Then you need to drain the tank, fill with the first unblended fuel (ie pure gasoline or close to it), tune on that fuel, when that fuel is all tuned and working well then drain tank, fill with the 2nd pure fuel (ie ethanol), check fuel tune again (should be close if injector and fuel data is good), when that fuel is good then check again with some variable fuel blends between these 2 extremes.
It might be worth your while to invest in some courses at HP Academy or Evan performance.  

Space bar is "jump to active cell", so if you had any table present on the same page it would be controlling that.  Enter may be a possibility but I dont know enough about how it works.  I will put your suggestion into the development system for the software guys to look at one day.  
 
Possibly you arent stopping the log?  If the log is still running then the cursor will always be at the current operating instant.  Hit F8 to stop the log and the table cross hair should follow the cursor right away.  Otherwise I might need to see a video to get what is happening. 
 

Im not sure how to answer your question any better than I already did.  Vista was retired in 2012, the first G4X wasnt released until 8 years after that.  So as I say, we havent tested any G4X software on vista, there is little need as apparently less than 0.18% of all of the PC's still running today are running Vista, most of those being in a 3rd world region where they wouldnt use PC Link.  With such a minority we dont even get reports from other users successfully or unsuccessfully running vista.  You will have to try it for yourself if you need to know.  The latest version that I suggested would be the best to try as it has the most mature USB drivers. 
The biggest variable is what version of OpenGL your graphics card supports and how complete the last graphics driver for it was.  OpenGL support is flaky at best in most older PC's.