Integrating multiple Link Can Lambda modules pre-turbo and post-turbo on a twin scroll setup.

[jigga009]

I have 4 Link CAN Lambda modules inbound to join the existing CAN Lambda I have in the downpipe of my turbo 4 cylinder application. The aim is to replace my current pre-turbo back pressure compensated wideband setup (AEM 4 channel) with the Link Can Lambdas. The AEM works well, but only has a single pressure channel.

Issue is that I have a twin scroll exhaust manifold setup that is separate all to the exhaust dump tubes (2 exhaust waste gates), so will be running individual pressure sensors on each scroll, with information from each pressure sensor being transmitted to 2 Can Lambdas monitoring the cylinders on that particular scroll.

The question is how one would go about setting the Can Lambdas up on the car so that:

 My current Can Lambda in the downpipe does not start backpressure compensating the data it sends to the ECU, given that it would now start receiving pressure data being sent at the same particular CAN ID on the canbus network that the other Can Lambdas (which need to be backpressure compensating) are on.

I run a custom CAN protocol on my G4+ as is to communicate with my MXG, but am not averse to re-writing things if more room is needed.  

Currently on ECU Can 1 (1Mb/s), I have my MXG dash (on dash Can1 network).

Currently on ECU Can 2 (500kb/s), I have my MXG dash (on dash Can 2 network), AEM 4 channel wideband, and post-turbo Can Lambda. The MXG is on CAN 2 also because it has a custom CAN protocol that allows it to receive all of the AEM error data directly from the AEM 4 channel setup, which the ECU is unable to do.

Current plan *was* to install 2 Can Lambdas on Can 1, and then another pair of Can Lambdas on Can 2 (to join the existing post-turbo CanLambda), and then broadcast pre-turbo pressure data from the respective pressure sensors to the appropriate CanLambdas sitting on their respective canbus networks via custom can streams. This way, each wideband has accurate pressure information from which to backpressure compensate with.

However, it just occurred to me that since all Can Lambdas receive info on the same CAN ID, my post-turbo CanLambda would now start receiving backpressure data meant only for 2 of my pre-turbo Can Lambda modules, and then start sending backpressure compensated data to the ECU, which would be wrong.

Having the post-turbo Can Lambda sit exclusively on a canbus network created by the MXG is a bit of a no-go, as there seems to be some kind of processing/filtering that the ECU does to the info it receives from the Can Lambda, so I can't have the MXG pulling info from the Link Can Lambda directly. It has to come from the ECU in order for the CAN Lambda info/error data to show up properly on the MXG.

Any ideas for an install/programming strategy for getting everything to work smoothly?

I tried contacting Link over chat, but they think this is something up our resident canbus guru's (AdamW) alley, given what I'm up to. 

 

 

[Adamw]

I've never personally done this but I believe it is possible if you have enough spare CAN slots, I discussed this with engineering a while ago for someone else.  You will need 2 "user streams" to send out pressure of bank 1 & 2, then 5 user streams to receive the 5 lambdas.   And you will need 2 ID's for each lambda.  So I think if you put 2 lambdas on the bus with the dash and 3 on the other bus you should have just enough streams and ID's to do it all.  

The CAN lambdas apparently will receive exhaust pressure either globally on ID958 or individually on 958+index.  So in this case we wouldnt want to use the built in "Link CAN Lambda" stream as that broadcasts pressure on ID958 so all lambdas would use it.  

What we have to do is first program the lambdas to "lambda 2-6" (we dont want any programmed as lambda 1 ID as its index is 0 so it would need press on 958 which will mess up the others).  If we program them to be identified with Lambda 2-6 ID's then the exhaust pressure will be sent out on ID959-963. You would send the same pressure user stream to the 2 lambdas that work in the same manifold.  

We can still receive the lambda data into the ecu as channels "lambda 1-5" (even though they are programmed as lambda 2-6), so the number relates to cylinder numbers or whatever.  

Start by reprograming the lambdas to 2-6 and I can give you a hand with the CAN side if you need it.  

[jigga009]

Oh wow, thanks very much for the response! This definitely clears things up. I had a sinking feeling that I had purchased these units without really thinking it all through.

Depressing though that it making it work will swallow up so many user streams though!

 

[Adamw]

Could possibly set up the dash to do most of the CAN work for the 4 pressure compensated ones then send those to the ECU in a single stream.  

[jigga009]

Thought about doing that, but the last time I had the MXG receive data directly from a Link CAN Lambda, there was an issue with the status of the CanLambda fluctuating between "disabled" and "diagnostics" constantly on the MXG with the key on the ON position and engine off. It would not stop until I had the Can Lambda data being received by the ECU, and then having the ECU relay the data to the MXG. There were also minor fluctuations/glitches of the lambda values from the CAN Lambda. All of these issues disappeared when I had the ECU receiving the info from the CANLambda directly.

I realized that the ECU seems to process/condition the info it receives from the CAN Lambda before sending it out over CAN in a manner that the MXG does not. I came to this conclusion because the MXG did not seem to have any issues receiving all of the data being broadcasted by the AEM (once a custom protocol was written) , including status and error codes.

 

[jigga009]

Ok 3 questions regarding the installation of the CAN Lambdas...

1) Can you confirm that it would be recommended to have a separate relay powering each Can Lambda module? I'm told that it might not be the best of ideas (from an electrical interference perspective) to use a single relay of appropriate capacity power all 4 relays?

2) Is it okay to use a wideband extension such as this one here by Haltech to bridge the gap between the mounting location of the Can Lambda and the wideband O2 sensor?: HT-010719 Wideband Extension Harness To suit LSU4.9

Issue is that I'd like to install the CANLambda high in the engine bay against the firewall away from the heat of the turbo and exhaust manifold within 20cm of the main CAN bus line into the engine bay, but the lead for the widebands on the CanLambda are too short to reach the wideband o2 sensors located in the exhaust manifold underneath the engine. I'd rather not mount the Can Lambdas near the heat of the exhaust manifold or underneath the car exposed to the elements in order for them to reach the O2 sensors mounted in the exhaust manifold of a horizontally opposed engine.

3) If using an exhaust manifold backpressure signal for the Can Lambda, does one need to physically dampen the signal for the sensor using an emap canister damper? Or is the Can Lambda actually expecting a pure and unfiltered signal for proper operation?

 

[Adamw]

1. I would expect a single common relay will be fine.
2. Assuming that extension has all 6 wires connected it would be fine (some others like Innovate only have 5 wires and rely on free air calibration instead).
3. Yeah you will want at least the majority of the large spikes damped.  

[jigga009]

I'm in the process of setting things up right now. I have all the CAN Lambdas talking to the ECU, and have reprogrammed them 2-6.

Curious about what you mentioned about setting up the MXG to do the CAN work for the 4 pressure compensated CAN Lambdas. I was always under the impression that the G4+ can receive info over CAN BUS, but can only display voltages? Without using a G4X, I'm not sure how one would be able to get the ECU to log actual lambda values instead...Am I missing something?

As an aside, I have both CAN 1 and CAN 2 now operating at 1MB/s (had to run Can 2 @ 500mb/s previously due to the AEM 4 channel wideband I had previously). I have 2 Can Lambdas sitting on Can 2, and 3 Can Lambdas sitting on Can 1. The MXG is the termination point for both CAN networks. 

 

 

 

[Adamw]

What I was getting at was to use the dash as the gateway since it has less restriction in the number of ID's it can use.  So for example it could send 5 different messages out to each lambda controller, some with pressures, some without.  It would receive 5 messages back from each controller, extract the 5 lambda values out of that data, then send the 5 lambdas to the ecu in a single message.  These would be received into the ecu directly as Lambda 1-5 variables, not as voltages.  

[jigga009]

Ah.. I see..

Before you disappear, can I have you take a quick look at what I have done so far with respect to programming these things?

Give me a few mins to upload my map to google drive...

https://drive.google.com/file/d/1xRK_utdSYcR_CeG0n1vlzsnZD6lFumfb/view?usp=share_link

Here is what I have done so far.. I'm not sure if I'm on the right path.

For Exhaust pressure sensors, I'm using AEM 0-100PSI sensors on Aux 8 and 9

I *think* I have the canbus stuff mostly done, but could use a second pair of eyes on what I have done.

I think you have a point with respect to using the MXG as a gateway, as it seems that there will be barely enough room to do anything else on the G4+ if it has to handle all of this stuff as well.

Still, if you think I have programmed the Canbus stuff correctly on the ECU, I can transfer it across to the MXG and implement it as you have suggested. 

[jigga009]

Ok, took a too long (takes a while to get back into the swing of writing canbus protocol after having not done it for a while) , but I've managed to cook up the canbus protocol to get it working as suggested. There does appear to be an issue though:

- Seems the MXG might not be fast enough on boot up to provide the Can Lambdas with an RPM signal before they start warming up, so they tend to start warming up before the dash is fully loaded, and stay running (peaking at around 780C) while the engine is off. I would guess that a quick and dirty solution to this might be to have the ECU or the MXG control all the can lambdas on a relay? Not sure about that one...

- The other issue I see is same as I experienced in the past when trying to get the MXG to directly take info from the Can Lambdas... It sort of works, but you can see that there is some sort of "conditioning" that the ECU is doing to whatever info it gets from the CAN Lambdas before displaying it. The values I get on the MXG are as expected, but they are "fluctuating""/glitching" every few seconds to some other number. For example, status with key on and engine off keeps fluctuating between "off", disabled, and "ok", and as this is going on, the sensors are heating up (until of course they reach their max of around 750C), and they just stay around there. 

 

I am trying to get the ECU to do more of the heavy lifting with the can lambdas, but that is proving a little difficult because there does not seem to be some parameters within PCLink such as Lambda 3 status, Lambda 3 error, Lambda 3 temp, etc. After Lambda 2, every other subsequent Lambda has no additional information to include into a canstream... just the lambda value itself..

Is there something I'm missing here?

 

[Adamw]

9 hours ago, jigga009 said:

- Seems the MXG might not be fast enough on boot up to provide the Can Lambdas with an RPM signal before they start warming up, so they tend to start warming up before the dash is fully loaded, and stay running (peaking at around 780C) while the engine is off. I would guess that a quick and dirty solution to this might be to have the ECU or the MXG control all the can lambdas on a relay? Not sure about that one...

Hmm, thats a bummer.  Does the dash take more than 15 seconds to boot?  It would be nice to keep the RPM activation for the heating strategy.  I would probably do a ecu or dash controlled relay so that the CAN lambdas are only powered up some time closer to when the dash is sending CAN. 

 

9 hours ago, jigga009 said:

- The other issue I see is same as I experienced in the past when trying to get the MXG to directly take info from the Can Lambdas... It sort of works, but you can see that there is some sort of "conditioning" that the ECU is doing to whatever info it gets from the CAN Lambdas before displaying it. The values I get on the MXG are as expected, but they are "fluctuating""/glitching" every few seconds to some other number. For example, status with key on and engine off keeps fluctuating between "off", disabled, and "ok", and as this is going on, the sensors are heating up (until of course they reach their max of around 750C), and they just stay around there. 

Nah that sounds like an issue with the CAN message, like one of the frames is missing a frame ID or something.    If you share the dash and ecu configs I will take a look when I get a chance (and the RS3 .xc1 files).

 

9 hours ago, jigga009 said:

I am trying to get the ECU to do more of the heavy lifting with the can lambdas, but that is proving a little difficult because there does not seem to be some parameters within PCLink such as Lambda 3 status, Lambda 3 error, Lambda 3 temp, etc. After Lambda 2, every other subsequent Lambda has no additional information to include into a canstream... just the lambda value itself..

Is there something I'm missing here?

For lambda 3-8 the ecu only has runtimes for the lambda value.  

[jigga009]

Link to MXG and G4+Calibrations

Adam, I've included a link above for the MXG calibration as well as the Can 1 and Can 2 protocols being used. Also included is the ECU map.

I have tried getting the ECU to do everything with respect to coordinating all 5 can lambda units, and while it is technically possible, it literally eats up *everything* the ECU has to offer from a channel standpoint. By the time all of the essential streams are laid out, there is no spare channel to use to send the data out of the ECU. In addition, you lose the ability to see error codes on anything aside from the first 2 can lambda units.

The method you suggested with the MXG doing most of the heavy lifting is the most elegant solution IMO because I have access to all of the error and status messages from all of the Can Lambda modules. As a bonus, it leaves a good chunk of spare channel space on the G4+ to send even more data, if the need arose. 

I will probably just hook the ground wire for the relay to an output on the ECU, and power it all up the same way I was with the AEM 4 channel setup I had prior. 

Remember that if the canbus structure on the MXG looks a bit odd to you, it's what you found worked on the MXG 1.0 a while back. 

Thankyou so much for your assistance with this, I'm appreciative. 

 

[jigga009]

15 hours ago, Adamw said:

Nah that sounds like an issue with the CAN message, like one of the frames is missing a frame ID or something.    If you share the dash and ecu configs I will take a look when I get a chance (and the RS3 .xc1 files).

As usual, you are on the money..

I had left out the Frame ID data give in the Can Lambda manual from the Aim Can 1 and Can 2 streams when cooking them up since I was not quite sure what the Frame ID number was doing there in the table in the Can Lambda manual. I had asked on the chat a few days ago as to what exactly that number was, but the individual who was trying to help me wasn't quite sure either, as Canbus is like kryptonite for most!

Once you clued me into the Frame ID possibly being missing from my calibrations, I deduced that this is what the seemingly random number sitting at the Data 0 box in the Can Lambda's output data had to be. I watched a few AIM coaching videos on canbus building until they mentioned how to integrate Frame ID into the configuration.

Now I no longer have any glitching of my status or error codes or my lambda values!

Still have the issue of the Can Lambdas firing up when the dash is turned on. I know that the Can Lambdas have a frame ID on which they receive the RPM and compensation info, but I don't really see a way of including this data in the CAN Output of the MXG at the moment. I will keep looking though. Trying to see if I have to resort to a relay to solve that issue, or whether there is still something I am missing with respect to incorporating the Frame ID info on the Can output of the MXG.

I may have spoken too soon when I mentioned that the MXG might be too slow to get the Can Lambdas the RPM and pressure information since I have not been able to include Frame ID information in the Can 1 or Can 2 output.  Might just have to get the ECU to send that info over to the Can Lambdas since it obviously has provision for Frame ID, length, etc in PC Link. Maybe I can avoid using a dash-controlled relay to control the relays at the end of the day.

 

[Adamw]

"Frame ID" is called "Row Counter" in RS3.  

[jigga009]

Slight update..

I think I have this working now.

I ended up using the ECU to send the RPM and EMAP data to the Can Lambdas. This got me around the real issue here:

Issue of the MXG/RS3 being unable to *send* (it is able to receive though..) multiplexed data out on either of its CAN outputs; an important detail since Can Lambdas are only receiving data on a certain Frame ID within a given Can ID. I did check AIM help videos on programming/building Canbus to confirm that the outputs of even the latest devices don't give them the option to select a Frame ID/Row Counter into any of their outgoing message examples using the newer devices. Solution was to use the ECU to send any required instructions to the Can Lambdas.

To avoid completely tapping out the ECU with handling the Can Lambdas (Just for fun, I did try cooking up a protocol for the ECU using just the ECU to send emap+rpm data to the Can Lambdas, receive the status, temperature and lambda values from the Can Lambdas, and then attempt to send that info to the MXG, and it literally ate up every stream the ECU had, not even leaving one free to send anything to the dash), I had the MXG pick off the Lambda, status, and error information from all of the Can Lambda modules since it can receive multiplexed info, and then created an output Can stream from the MXG to the ECU with the Lambda information in a simple non-multiplex format, since that's all it will allow one to do. 

I had to be pretty creative in using "blank" areas within the EMAP/RPM data streams dedicated for the Can Lambda (from the ECU) to piggyback data that the dash could receive also display.  This is a necessity since getting all the Can Lambdas to work while keeping most of the juicy info the Can Lambdas can provide the user while in use requires a substantial amount of the CAN streams/channels the G4+ has. I did try using the generic dash configurations built into PCLink in order to transfer a lot of the ECU data over to the dash without having to take up streams, but PCLink wasn't having that, saying that there was too much information in the streams.

The good thing now is that the MXG is able to pick off and display all of the error, status and sensor temperature data for each and every Can Lambda module in my setup - something the G4+ is not capable of doing on its own due to not having the runtime information programmed into PCLink.

Quirk in all of this is that even though I can see all of the status and temp info relating to the Can Lambdas on my MXG, I am unable to send the error, status, and sensor temp info back to the ECU  because the G4+ can only accommodate detailed runtime information for only 2 Can Lambda modules, maximum. Perhaps one could use CAN Voltages to somehow log this info on the G4+, but it isn't something I have dug into too much since there are no math channels on the G4+ to decipher anything with. The CAN Digital channels on the G4+ only seem to cover a 1 or 0, which isn't enough to cover all the status values in play for the Can Lambdas. I'll have to play with that a bit more to see how it looks on the ECU end, as I'm away from the car at the moment. With that said, since my MXG is a logger dash, I am able to log all of this info from that end though in a manner that doens't require any special deciphering. Would have been nice to do it all on the ECU end though.

[Adamw]

The CAN Lambda receive stream is just a single frame so you dont need a row counter/frame ID.  Just use the static value function to insert an "85" in byte 0.  

Example:

 

[jigga009]

9 minutes ago, Adamw said:

The CAN Lambda receive stream is just a single frame so you dont need a row counter/frame ID.  Just use the static value function to insert an "85" in byte 0.  

Example:

 

Oh wow! Thankyou! If the MXG can send this info to the Can Lambdas quickly enough, this will really open things up from a parameter transmission front on the ECU side. I was a little bummed out about how little room I had to transmit any of the parameters I previously could from the ECU to the MXG after implementing the Can Lambdas into the setup! 

I'll implement the above and report back!

[jigga009]

Ok, finally had a chance to implement your suggestions, and after some trial and error, it works!

Turns out the MXG is in fact quick enough to send the RPM and EMAP data to the Can Lambdas to keep them from turning on when the key is at the ON position. It is sending the RPM and EMAP data to the Can Lambdas, and they are all staying disabled while the engine is off. Thanks to this, I still have a few streams for sending data over to the MXG. 

 

[jigga009]

Now that this is all working, I have some questions regarding integrating the info these Can Lambdas are bringing in to the ECU itself.

Prior to installing the new 4 can Lambdas, I had a Can Lambda already located on the downpipe, and this was plumbed into the ECU as Lambda 1, and all closed loop fuelling was based off the data that it provided. At this time, my old Closed Loop Lambda settings were as follows in the folder below

 

Folder with screenshots of Old and New CLL settings

You can also see in that folder that I changed CLL to Auto Mode, and preliminarily filled out the tables.

First Question - Should I be switching to the Auto Mode? As is now, the Can Lambda that was located in the downpipe, and labelled as Lambda 1 is now labelled as Lambda 6, and has its data being sent to the ECU from the MXG as Lambda 5, so I made the switch to the Auto mode under the understanding that the G4+ will now be using AVG AFR to calculate closed loop lambda now? Is this correct?

 

Second Question - Are the values that I have filled in for the Closed Loop Lambda Gain Table, CLL pos limit, CLL neg limit, and CLL update rate seem like appropriate numbers/approximate the old settings I was using, which seemed to work fine for the Can Lambda located behind the downpipe? Or will I really want to cook up new settings to accomodate for the new 4 Can Lambdas being located close to the exhaust port of the heads compared to the post turbo Can Lambda?

Third Question - Since the G4+only has canbus runtimes for 2 Lambda inputs, does this mean that the ECU will not turn off closed loop lambda if there is an issue with Canlambdas 3-5? Is the AVG Lambda value going to be calculated based on 2 lambda inputs since there are only runtime values for lambda 1 and lambda 2?

[Adamw]

I would not use closed loop when you have sensors that are not all the same distance from the combustion chamber, they will take a different amount of time to respond to any fuel trim so closed loop control will be very poor.  

G4+ closed loop always uses lambda average so if you want to do closed loop with individual cylinder lambda sensors then I would suggest only those sensors be connected.  

 

4 hours ago, jigga009 said:

Third Question - Since the G4+only has canbus runtimes for 2 Lambda inputs, does this mean that the ECU will not turn off closed loop lambda if there is an issue with Canlambdas 3-5? Is the AVG Lambda value going to be calculated based on 2 lambda inputs since there are only runtime values for lambda 1 and lambda 2?

Any CAN lambda device that is in an error state will output only "0" in its lambda field, the ecu will remove any device that is reporting 0 from the lambda average calculation.  So any sensors that are in error will be ignored and will not effect CLL, CLL will continue to operate using the average of the remaining working sensors.  

[jigga009]

11 hours ago, Adamw said:

I would not use closed loop when you have sensors that are not all the same distance from the combustion chamber, they will take a different amount of time to respond to any fuel trim so closed loop control will be very poor.  

G4+ closed loop always uses lambda average so if you want to do closed loop with individual cylinder lambda sensors then I would suggest only those sensors be connected.  

 

Any CAN lambda device that is in an error state will output only "0" in its lambda field, the ecu will remove any device that is reporting 0 from the lambda average calculation.  So any sensors that are in error will be ignored and will not effect CLL, CLL will continue to operate using the average of the remaining working sensors.  

Thanks for the advice.

I was talking to Jose on tech support about possible settings for the Closed Loop Lambda Auto Mode. He wasn't personally as familiar with that particular mode on PCLink so couldn't help too much there, but he did mention I could implement your advice here by having the post-turbo Can Lambda data be received on the ECU end as a CAN Analog input, so the ECU will still be able to log the AFR data, I can still see it on my MXG, monitor the Can Lambda device error status on my MXG, but the ECU will not try to use it for closed loop lambda calculations in Automatic Wideband Mode as Lambda Avg/AFR Avg since it isn't seen as a Lambda parameter anymore on the ECU end. I just have to make a note somewhere of what the particular CAN AN input represents since it cannot be tagged with a label in PCLink. I will likely just group it with the other cylinder 1-4 AFR data on my logging template to take care of that.

Question:

Would you by any chance have some safe/typical table settings for the Automatic Closed Loop Gain and Update Rate tables for a setup with the sensors close to the exhaust ports like in a per-cylinder lambda application like mine? The only thing I have to go on is the old Gain setting of 5 which was in play for my post-turbo can lambda when it was being used for closed loop operation in Stoich Wideband mode . 

 

[Adamw]

I would start with an update rate around 1-2 at idle, ramping up to 10Hz at higher RPM.  Get the gain as high as you can without overshoot or oscillation.  Start with 1.0 right across, you will probably be able to go significantly higher than that but that should be a good place to start.