jigga009

I was in a similar boat this time last year as I was installing multiple Canlambdas for a boxer application, so thought I would need an extended lead solution to connect the wideband sensors to the Canlambda modules. Haltech sells a ready-made wideband sensor extension harness that will do what you are looking for. This was an option I was looking at purchasing, but realized it would get expensive since I would have needed 5 of these extension harnesses for my setup which uses 5 Can Lambdas. Alternatively, you can find the required plugs on eBay for dirt cheap from china. I was a little sceptical with respect to the quality of them when I ordered them, but once I had them in hand, quality was just fine, and they connected and clicked into to the Can Lambda wideband connector and the Bosch wideband sensor connectors perfectly. I ended up not needing them thanks to the generous length of the wire used with the Bosch sensors Link includes with the Can Lambda. They were just long enough to able to reach from the sensor locations on the exhaust manifold below the engine. The aforementioned connectors come with the pins and seals. You just provide the wire and wire loom and get as fancy as you like. You can also find the same connectors floating around on Amazon, but the prices in my experience are inflated for what you are getting. If you are installing a single Can Lambda, the Haltech offering might be a nice and easy route to go. If on the other hand you are installing multiple units, it would be cheaper to purchase a bulk pack of plugs like I did and just assemble your own harnesses. It might be wise to upsize slightly on the wire gauge of your extension harness so as not to introduce significant resistance that might skew your sensor readings. This, at least for me, was the plan before I found that I had just enough length to go without them.

I would start by connecting a manual gauge up to see what it actually says about the pressure readings in the oil pressure and fuel system.

Not sure if the Link versions have the ability, so what I'm about to post might not apply to you guys, but the AIM version does allow you to add their CAN remote button interface, which gives the capability to control the screen brightness somewhat (i.e. between full brightness and Auto) via button control on one of the built-in CAN networks on the device. I have it on my MXG, and use a steering wheel mounted button on a 5 button pod to toggle between Full Screen brightness (my typical setting for day driving) and Auto (my typical go-to for night driving, since it auto-dims the screen at night). The other 4 buttons on my button pod duplicate the buttons on the MXG. I have the remote button interface linked to a small button pod attached to my steering wheel, and a curly cord going from the button pod to the remote button module mounted under the dash/steering column area. My particular switch pod has 5 buttons, so I have it linked to the AIM interface such that It gives me the ability to remotely press all 4 buttons located on the MXG, and each press of the 5th button toggles the screen brightness between Auto and full brightness on my dash. The AIM remote interface itself has 6 button inputs (inputs 1-4 duplicate the buttons on the sides of the MXG, input 5 controls the screen brightness, and input 6 resets the odometer). I left off input 6 on my setup since resetting the trip meter isn't something that I do often, and finding a 6 button switch pod that fit neatly within the confines of my steering wheel was proving to be a pain in the posterior. Drawback of the setup is that it requires not just the remote interface, but also requires you to purchase a data hub (if you don't have one already), as well as a suitable switch pod/panel/buttons for it all to work. It likely will also require you to purchase AIM's auxiliary harness to get access to the 12V outputs, which isn't particularly cheap. If you were feeling adventurous, you could in theory use one of the MXG's 12v outputs to trigger a relay that would provide a momentary (non-latching) output which would essentially do the same thing as the button on my button pod does for the screen brightness button, which in effect would allow you to toggle between a headlamps-on screen brightness setting and a headlamps-off screen brightness setting when you twist your headlamp stalk to turn on or off the headlamps. For this to work, you would need a free 0-5V channel on the dash that monitors the status of the headlamps (or a channel expander hub if you don't have any free channels on the primary or secondary harnesses), a sensor pigtail that you can splice into the dash or your stereo headunit wiring to monitor for perhaps a headlamp LED or the circuit that controls the dash LEDs that light up at night, a free 12V output channel on the dash (which I think might require you to purchase AIM's auxiliary harness), the remote button interface, a data hub for the AIM remote button interface to patch into the dash (if you don't have one already), and a 12V momentary relay, and some time to wire everything in. You would need to link the activation of the 12v output to the status of a channel you add to the dash which monitors when the headlamps are on and off. When the dash detects that the headlamps are turned on, you would use one a free "alarm" would trigger the relay, which would in effect be like pushing the button on the appropriate channel on the Aim remote button interface, which in turn will change the screen brightness. You would then need another "alarm" to trigger the relay again when the headlamps are turned off to change the screen brightness again. So technically very possible, but probably not worth it from a $$ standpoint if you are just after the ability to dim the dash, and don't already have all of the other bits and pieces needed to get it working laying around doing other things like I do. Enabling this functionality on my MXG would only require me to purchase an appropriate relay and spend some time wiring it in. For now, I'm okay just hitting a steering wheel mounted button to toggle between full brightness for day driving and Auto (when the brightness is too much at night), allowing the screen to dim. Might put it on my to-do list down the line for when I'm bored.

OK an update - I was able to solve this issue by putting the purge solenoid on a delay timer. Seems that purge solenoid activation can catch the closed loop fuel correction out briefly if a second purge event is triggered within close temporal succession to the end of the first purge event. More specifically, if the second purge event occurs while the ECU is still busy pulling fuel in response of the first purge event. So by putting the purge solenoid on a 3 second timer delay that starts when the conditions are met for the purge solenoid to be activated (timer starts counting when ECU determines that it is time to purge, and actually activates the purge solenoid 3s later), and resets at the end of the purge event, you now force the ECU to have a minimum delay of 3s between purge events, regardless of whether the purge conditions are met sooner. This allows the ECU a minimum of 3s after the solenoid closes to continue stabilizing fueling before a subsequent purge event can be triggered (at which time closed loop fueling starts pulling the appropriate amount of fuel again).

Hello, I have a purge solenoid wired into my G4+ Xtreme for my Subaru application. I have the ECU controlling the solenoid via PWM in order to be able to get more granular control over just how much fumes are coming into the intake manifold when the ECU commands the purge solenoid on. From what I can see so far, it seems to work, but there are some issues that I have not been able to solve.: Issue 1 - My purge solenoid (a Bosch 0280142353) is being controlled by my G4+ Xtreme with PWM, but I am finding that very low duty cycle numbers (<10%) seem to provoke some rather large AFR swings of up to 40% in CLL when the purge solenoid is activated. For example, duty cycles of perhaps 3-5% can cause an AFR swing that taps out the CLL correction at 40%. Not sure if it's an issue with the settings I have for frequency and the like; it may or may not be a big issue given that you can only input values of 0.5 multiples into the PWM table, but it is something I have noticed, nonetheless, and thought I might mention. I spoke to Simon in tech support about it, and he could not figure out why such small duty cycle figures were causing such a large AFR swing for the ECU to compensate for. Could this be an issue with the set frequency I am using to operate the purge solenoid? Issue 2 - The real issue - On occasions when the purge solenoid is activated (and then CLL is busy pulling fuel out to compensate), and then I take my foot off the throttle, going into overrun, and then back into the throttle when the purge solenoid is immediately activated again, the car seems to go transiently lean causing quite a large "bang" out of the exhaust. It's such that it can be detected on my pre-turbo backpressure sensors. My initial suspicion was that the issue was due to the closed loop "reactivation timeout" since in other logs it coincided with when the timeout was active and CLL was "asleep". However, in the latest log I have, overrun fuel cut was not activating for other reasons (so no reactivation timeout after overrun fuel cut), and yet the re-opening of the purge solenoid seems to cause a transient lean event that occurs too quickly for the CLL to catch, causing a brief period of choppy/stuttering power, followed by a loud bang out of the exhaust if I keep my foot steady at the same throttle %. I have consulted tech support, and I've been told that the "reactivation timeout" is not user-adjustable unless I pay up for a G4X. I was also told that I cannot see the actual duty cycle that the ECU is commanding unless I pony up for a G4X. My current suspicion is that it has something to do with my Closed Loop Lambda Gain or Rate settings, but I'd like some smarter people to look at this first before I go on a fishing expedition. Simon from tech support even came up with the slick idea of having the purge solenoid do its purging only during overrun in order to try to avoid the issue, but what happens there instead are loud explosions again in the exhaust during purge events as the vapor runs through the engine and hits the hot exhaust manifold. So in other words, it simply moved the issue elsewhere. Some notes regarding my setup: - Closed loop lambda is averaged of 4 Lambda sensors (Lambda 1,2,3,4) as I have sensors on all 4 cylinders. - There are 2 backpressure sensors - one for each scroll - AN8 and AN9, so overlay both up on top of each other, and you can see when the vapor is lit up in the exhaust manifold where it shows as a small brief intense cluster of exhaust pressure spikes with no actual boost increase or throttle input at certain time indexes in the log. - Purge solenoid is on Aux 6, and is PWM controlled. I have a Virtual Aux 1 also set to Purge Solenoid, so to know when purge solenoid is actually venting into the manifold, you would need to overlay both AUX 6 and Virtual Aux 1 and watch where they both are "ON". I have it set up this way primarily to keep the purge solenoid from purging when in 1st gear. - You might notice that overrun fuel cut is not working in the log - I'm pretty sure its due to my lockout TPS setting of 1%. A setting of 1% is typically fine in cooler weather on my car, but I took this log on one of the hotter days we have had so far this year with ambient temps at around 30C, and I noticed that the throttle cable runs over the hot engine and seems to stretch a little with the heat under the engine bay especially in low speed where there is little airflow into the engine bay (its that or the OEM throttle return spring might be feeling the effects of the under hood heat), so I need to adjust the lockout to perhaps around 1.3% to give some room so that the function continues to work properly when things heat up especially on hot summer days. As a plus though, not having the overrun fuel cut working during the log conveniently helped rule out the closed loop reactivation lockout as the cause of the issue (which I originally suspected). Screenshot of my datalog to show spikes in EMAP You can see what I am referring to in the image above occurring at time indexes 1:02, 1:06, and again at 1:18.04. The "bang" can be "seen" as the jump in both EMAP traces at those time indexes. You can also see how the "lean" condition that occurs as soon as the purge solenoid opens when throttle is reintroduced following throttle lift off preceded by a purge event, as well as what the CLL is doing prior and after each event. Again, you can see on all 3 occasions that the purge solenoid was active, and then I let off the throttle briefly to coast, and then went back into the throttle, and then experienced a slight stuttering/hesitation as car ran lean and then BANG (out of the exhaust), and then the car continues as if nothing happened. If I turn off the purge solenoid completely via the ECU, the car drives normally, no matter what I'm doing with the throttle. I'd rather keep the purge on though, as I am not a fan of the smell of fuel venting from my gas tank. I can literally smell it inside the car if I roll the windows down and drive slowly. I can also detect other drivers keeping their distance when the purge solenoid is deactivated, no doubt because they can smell raw fuel emanating from the car. ECU map and log Any assistance from our wise members would be much appreciated. Thanks!

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 .

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?

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.

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!

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.

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.

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.

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?

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.

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.

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?

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.

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!

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.

I'd probably get the alternator bench tested to rule any issues out with a blown diode or similar, and then start voltage drop testing your power wires between the battery, alternator, starter motor and main fuse box in your engine bay during a cranking event. You may find a high resistance connection in there causing your issues. Also be sure to check alternator belt tension also to ensure the alternator belt is not slipping when you load the car.

In the meantime, other things perhaps to check would be to ensure your electrical connections on the positive and negative side are sound (check the pos and neg as the enter the 4 way DTM connector as well as the crimps at the battery side. You might also install the capacitor as outlined in the manual between the positive and negative battery lines to the canlambda. it filters out voltage spikes from the electrical supply. Finally, you might also try swapping in a known-good lambda sensor to see if that makes a difference.

Do you have a datalog that includes you cranking the engine over?

Pretty much. I was able to solve it by fixing any and all leaks in the intake and exhaust manifold, replacing v-band clamps, ensuring that intake and exhaust cam gears lined up (purchased the RCM eccentric idlers for this), and once I ruled out other issues with the ignition and fuel system, I then added a few percent of fuel throughout the fuel table to start compensating for the cams, and adjusting the cylinder fuel trim in order to dial things in further. Oh... I also replaced those cracked cam gears with fresh units. The car now starts and idles properly. Next item on the list is to dial the fuelling in using mixture map. Before doing this though, I am upgrading the battery wiring on the car in order to reduce voltage drop in the starting and charging system as much as possible, as my CanLambda would give error codes when it saw low battery voltage due to the current inrush when the starter motor was engaged. I'll get it all sorted eventually.. just need the time to get to it. Are you having similar issues?

Wanted to see your line of testing through in case something pops up. Here is a ECU datalog using the "lambda test" map you attached, with of a few consecutive engine starts. CAN setup is back to Can Lambda now as you requested, and battery is fully charged. Charger is not connected during this log: https://drive.google.com/file/d/1Hv9EcO9tGH3qlPSfvUbm03ZQeIk-NljD/view?usp=sharing Thanks.

Understood. Thanks so much for the info. I will start putting things back to the way it was before and see "Lamb48- APE Overvoltage" makes another appearance. Hopefully as you say, the changes solved it. If it does pop up again and it can be attributed to how I have the CAN stuff set up, I may need your guidance again setting up the canbus stuff. I'll update once I have a chance to retest things. Thanks again!