Rozsko

Thanks Adam. That's an interesting way of adding more fuel, but certainly worth a try before I disassemble all the intake and fuel lines. I recently fitted this 4bar map sensor, and I still have the old one, so I can try to fit that and see what's happening then.

Hey guys, I am not sure if this is ECU related or not, but I need some advice if possible. Long story short, car was running fine on one day while I was doing some cruise logging, then next day made some adjustments in Fuel table2 based on the logs and car won't start any more. More precisely it starts very hard and doesn't want to idle at all. Pedal response is horrible and does not take RPM, even if it takes, it does that only momentarily. If I play with the accelerator pedal like crazy, then I can keep it alive, but runs horribly unstable and wants to die badly. Here are couple of links to check out. video: https://1drv.ms/v/s!Ale4oyMCOgLThOYAFgJCuOEx_CyNsA?e=RUUZGJ rom: https://1drv.ms/u/s!Ale4oyMCOgLThOV8ENECSxApAWCy6w?e=tUtYWX data log trying to keep engine alive: https://1drv.ms/u/s!Ale4oyMCOgLThOV_SbCmk6n707bC0g?e=ABjoJD data log with brake cleaner: https://1drv.ms/u/s!Ale4oyMCOgLThOV-q7ODvC_ZXMMumQ?e=y4lG5O trigger scope: https://1drv.ms/u/s!Ale4oyMCOgLThOV9dCMUpY9L-U2BlA?e=GiOx8d So, things that I checked, tried so far: Fuel pressure is good (you can see in the log) Disconnected the injectors one by one and started the car each time. Did make any noticeable difference in how the engine is running. Did a quick scope test of ignition, injectors, crank and relative compression, and all looks good. In the injector signal I can clearly see the pintle bump and the signal did not miss once. Same for the ignition. Crank signal is nice as it can be with ~1.5v Min peaks at the no tooth section. Relative compression test is perfect. Checked timing belt, did not jump, lined up well. Tried to run the engine with electronic throttle disabled, and actuate the plate by hand. When I did that, engine started, but when I manually opened the plate, engine died right away. This led me to think it is a fueling problem probably. So I connected a can (spray bottle) to one of the vacuum hoses and as I started the car, I sprayed brake cleaner into the intake manifold. Engine was running nicely and happily like that. Checked the logs, including an older one to see if IPW is not good, but actually it is kinda the same. 1.5 to 1.9 ms, depending on RPM and MGP. I obviously tried to upload an older rom that worked just fine before, but that did not help at all. To sum up, it seems like fueling issue, but injectors open and close, fuel pressure is good, and IPW didn't change compared to old logs. I am out of ideas, so I would appreciate any new ones. Thanks, Béla

Just to confirm, I wired up the KM and this works nice. RMP and TPS% displayed on the unit, though it is a bit cluttered as values are jumping up and down with 2,3,4 characters from one moment to an other. Did not dig into the load yet, but I suspect that thresholds can't be setup to consider both RPM and load anyhow, but will keep playing with it until dyno time. Not really ECU related, but wanted to ask if you guys figured out a nice and sturdy way of mounting the unit to the windscreen. What I have now is a clip type phone holder with a fairly short and rigid arm to the suction cup, so it is not too bad, but I feel the clip itself is not the most secure way of holding the the unit. Thanks, Béla

Hello Gents, I think I ran into a little bug in the CAN setup with this firmware. Nothing serious but I guess it is good to know about it. So in my setup I have streams defined with both normal and extended IDs. What is happening on the main CAN setup screen is that if I click a stream with an extended ID then I click one of the streams with normal IDs, the later defaults/changes to 2047. If I click first a stream with normal ID, then it is showing it properly, but again if I click an extended one and then back to the normal, now it is changed to 2047. (Extended IDs are not changed by this behavior) Once the normal ID(s) is changed to 2047 and I press cancel, then it is not saved, so opening the CAN setup again will show me the original good normal IDs (if I click those first) and then the game starts over . If I only click among the normal IDs, they don't change. Thanks, Béla

Thanks Adam. That's exactly how I was thinking about the offset. Wi wire it up and give it a try to see the load piece. Torque management is not something I looked into yet, but it seems time has come to do so.

Hi Guys, Plex recently released some new firmware for the Knock Monitor V2 and they introduced the ability to custom configure the CAN messages to be receive for RPM and Load. Their documentation is far from detailed enough for me and wanted to ask if anyone had figured it out yet. So there are actually questions in my mind: 1) Can I use the Offset to shift RPM or the Load with 2 bytes, so that I can receive both parameters on the same CAN message ID? Or this offset is the same as the usual offset value in the CAN settings? 2) The load axis in the software looks as if it expects to have some values in the range of 0-100%, but load in the G4x is MAP which will go way beyond 100 value. So do you know if this would work, or the load should be setup as TPS in the Knock Monitor config? Thanks, Béla

Just upgraded to the latest firmware, as I was lazy to do the base timing check so far. Base timing was perfect (07 STi), but I have to tell you, I got scared a lot when I hit the update firmware button and PCLink went "Not responding", instead of walking through the green status bar. The other thing I wanted to ask (not related to this particular version, but generally to firmware updates), why is the fuel pump switching on for the duration of the upgrade? It is like the initial 3seconds priming that is done after the ignition switch is turned on. Thanks, Béla

Correct. Weird. Isn't it? Only 1 decimal is displayed. That is the problem with the Throttle position % too. Never tried that, but will and will let you know.

Just FYI - Not sure what is going on with the Load parameter display in the gauge, but something is not quite right, I am pretty sure about that. On the other hand, i found an alternate element of the same messgae (TPS%) that is displayed properly, but only with one decimal digit. If I apply an additional multiplier of 10 though, then I get what I need, but the decimal point is displayed in the wrong place. So worst case I will hack that led somehow so it is shown properly. I also sent a message to the AEM EMS support to see if they have any suggestions or maybe they could provide a custom firmware for the gauge, etc... They actually replied quite quickly which was surprising to me on its own, but of course they can't help. No custom firmware, no instructions on how to desolder/soldier any chips to "hack",... Will see if I can find any information on the chips they are using in this gauge, although it is an SMD based PCB, so soldering would be quite a bit of challenge. Will see.

Thanks Vaughan.

Thanks Adam. I looked at earlier the other two you mentioned, but Haltech does not mention anything about GPS speed (5,10,20Hz) and the types of GPS channels/statelite types it is using. The AEM VDM specs say it is max 20Hz and min10Hz which is again confusing. So I guess I'll stick to the ECUMaster then. Thanks for hint on the CAN configuration too. That makes perfect sense.

Hey Guys, I am thinking about putting a GPS module into the car to have access to actual speed info. Most probably the ECU Master GPS to CAN module will be my choice here (unless you can recommend a better price/value alternate), which is outputting speed data in units of cm/s. As far as I can see, the way to set it up is to configure the CAN frame to receive a CAN Frequency (CAN analogs for me are all used), then have that as an input parameter in a Math channel an convert the cm/s to km/h, then have the Math channel as the source for one of the Speed inputs (GP or LF/RF/LR/RR) with calibration=0 so the km/h value is simply passed through. Then this speed input will be the driven wheel speed source which will be non slipping obviously so can be used for launch and traction control. Can you guys confirm the above or suggest any alternates/improvements? Thanks, Béal

That is very sad, but thanks Adam. As always, appreciate you taking the time to help.

Ignition. For which duty and freq seems to be 0 all the time and status seems to be always active. So what I am looking for really is the analog voltage signal of the first four ignition driver that are triggering the cop coils.

I've got some testing done as suggested by you guys. Here come the results: both multiplier and divider is set to 0. offset 0 1 100 128 200 255 300 383 400 510 600 700 765 1000 gauge 0 0.3 39.2 50.1 78.4 100 117.6 150.1 156.8 200 235.2 274.5 300 392.1 From these numbers it looks as if 2.55 multiplier should be applied, so I tried that, but the end result is far from satisfying. trial 1 2 3 4 multiplier 255 255 255 255 devider 1 10 100 1 offset 0 0 0 -255 gauge 107.2 10.1 0.7 6.x-7.x 10.5 10.9 Trial 1: this is perfectly working and showing proper lambda value times 100. So in the above case it was 1.07. Trial 2: gauge values are obviously 10 times the lambda value, but the fraction piece is not tracking the lambda values properly. Only .1, .5 and .9 are displayed, almost like some weird rounding. Trial 3: this should really be giving the proper lambda, but it only shows 0.7 value (exactly like with the 655 divider and 255 multiplier), irrespectively of how the lambda value changes. Where did the 1. (the whole) part went? Since 255 offset equals to 100 gauge value, I thought to give it an other try (#4): this is showing totally unexpected values. It was showing values between 6 and 7, with fractions changing and tracking the actual lambda values,but only the hundredths and thousandths of the lambda without the whole and the tenths. As per the AEM data, the load itself supports values from 0 to 99.998, so it should support the fractions more then adequately, yet, it seems to looses some resolution if a divider is applied or the value is moved closer to 1 with the offset. Do you guys recognize some correlation that I can't see or do you see anything wrong I am doing? Thanks again, Béla

Do you guys know if it is possible in any way to log the ignition trigger signals that are driven through the Aux ign outputs? Tried the IGN status parameters, but those are always active it seems. Thanks, Béla

Thanks Adam. I found this post too, and found a 3rd one as well with a different scalar value. None of the three is working. Well, probably one of that is displaying afr if I also apply a divider of 10, but I didn't do the math, just kinda looked like it. Thanks for the hint on 5v status test. I'll certainly see what that gives us.

Lately I had a little problem with the engine (2 cylinders not firing at all), so had no chance to actually play with this further until now. Thanks Adam for your earlier response, that is working fine and tbh I feel embarrassed a bit about not being able to figure that out myself. Anyhow, now I can configure the EGT and Lambda1 on two separate addresses, but since some of the AEMNet messages have capable structure to handle both in one frame, I am trying to "hack" the data a little bit. What I am trying to do exactly is to use the 0x01F0A000 message and its first four bytes. Byte 0-1 would transmit the EGT, 2-3 would transmit Lambda1. What is interesting is that the EGT is working perfectly (meaning displayed as if it was RPM), but Lambda1 is not. As you can see on the picture below, the scaling AEM uses for Load is 0.0015259 %/bit and there is no offset, so on the ECU side, I am using a multiplier of 1/0.0015259=655, but the value that the gauge displays is nothing like a lambda value. It displays a number around 230-250 if i remember correctly. If you calculate it backwards, it looks as if an additional multiplier of 255 is applied to the value sent by the ECU. If I apply that as a divider on the ECU side, the the value displayed will be 0.7, which is far from 0.97 lambda. I tried the same with a different message id that has similar structure, but I got pretty much the same result. Do you guys have any idea what the issue is? Thanks, Béla https://1drv.ms/u/s!Ale4oyMCOgLThOQMR_WiHHtBJqzeLQ

Simply because I am out of CAN An inputs. That's what I was suspecting, but not hoping for. Thanks again. Appreciate your answers.

Thanks again Adam. I 100% understand what you are saying, but I don't necessarily agree how this is treated. Of course this is just my opinion and nothing else, so please don't take it wrong. On the other hand I moved the pins in the connector and setup the Analog5,6,7 with 2.2k pull up resistor in the AEM unit and configured the same in the ECU. What I am not sure about is why the CAN output is simply truncating to whole number when the divider is set to 1000, but it is, so instead I do that in the math channels. Overall the result is much better so far, though there is a bit of variance among the AEM IAT sensors (obviously some is expected). I would think that half a C is ok, but the sensor connected to ANTemp2 is the same sensor and is showing 22C. Do you think this is still ok compared to 19.7 and 20.2? The bigger difference tough is with the built in MAF temp sensor. With the std bosch NTC calibration it is showing 24.8C which is really inaccurate. Can you advise which calibration should I really use for that? (06 STi MAF sensor) https://1drv.ms/u/s!Ale4oyMCOgLThONAxSIpICPB2tG5NQ Also returning back my first post a bit on the first two issues/limitations, is that really how it should work? Or do you plan include those functionalities in future releases? It would be really nice to be able receive a bit more types of inputs from CAN and/or assign the CAN TC inputs to GP inputs. Thanks

Thanks Adam for the quick reply. I understand what you are saying about AEM shouldn't convert the voltage to ohms, but (as you said too) I guess they have a reason to do so. Putting that theory aside if you look at the runtime values you can clearly see that the CAN TC parameters are simply receiving an ohm value as if you look that up in the calibration, that equals to roughly 20 C. The same true of the Math channels. All 3 Math channels I use output the Ohm values. So to apply the Cal table 1 unit conversion/mapping to the Math channels should clearly result in showing degrees of Celsius in my mind and I really can't understand why ~3470 as a value of Ohm is handled differently in the G4X depending if this values is received from a Math channel or normal An Temp input. If I look at IAT, its source is An Temp2 with the same Cal Table 1, and it works correctly. The only difference is that An Temp2 is directly wired to an AEM IAT sensor. On your second question, yes, I can try that. In that case, I assume thought the calibration table should be Volts to C.

Hey Everyone, As I was explaining in an earlier thread (https://forums.linkecu.com/topic/13223-can-stream-setup-for-dual-bus/), I connected an AEM 22 channel CAN modul to the ECU. Fortunately not all the 22 channels require an individual address, thus an individual stream, so I ended up needing only two streams. Unfortunately though not everything is quite right. With these additional sensors (3pcs of EMAP - CAN AN6/7/8, 3pcs of IAT - CAN TC5/6/7) there is not much I want to do, but only log them really (well, with the exception of an EMAP which is used by the Link Lambda). The pressure sensors are linear calibration, so I could simply build that into the CAN frame parameter setup, however the NTC sensors being non-linear I need a cal table assigned to them somehow, and that's where my the problem starts. Problem#1: It seems that now the receivable parameter list on the CAN setup is quite narrow and I can't assign these sensor inputs directly to a (let's say) AN Temp pin. The only option that makes sense is to have them assigned to CAN TC. Problem#2: CAN TC inputs can not be assigned as source to any GP Inputs, this is where I thought to give up, but then I looked at the Math channels and voila. Unfortunately this is not working properly either. Problem#3: So after setting up the Math channels with Parameter a = CAN TC input and equation = "a+0" (it seems with simply "a" being in the equation, it is not producing any output), the Ohm values are outputted properly and I can assign the Math channel to the GP Temp inputs as source and assign a calibration table, but using the calibration table for the AEM IAT sensor (which I already use with the IAT input) or the std Bosch NTC calibration for the MAF temp sensor, the temperature values are absolutely non sense. Any idea, any suggestion would be highly appreciated. Thanks, Béla Math channel setup and runtime values: https://1drv.ms/u/s!Ale4oyMCOgLThOMoAk9Foh8uJhedLQ Cal table 1: https://1drv.ms/u/s!Ale4oyMCOgLThOMpKP3Mn4UdmKPIaw GP Temp3: https://1drv.ms/u/s!Ale4oyMCOgLThOMqoebrQ-KASndl8g

Worked on this a little more this morning and I would have a few more questions. I did not start the car, so it is key on engine off now. Moved the Link CAN to bus#2 (previously I set the bitrate to 500kbps as the rest of the gauges are like that on bus#2). Now, Lambda1 reads 0, just like lambd1 temp, but lambda1 error says ok (https://1drv.ms/u/s!Ale4oyMCOgLThN5bPCwdOYm9Zp3Djw). Is that normal at key on engine off? Will these be read only after the engine is started? The other thing is even though I changed the bitrate previously (and I changed it atleast 3 more times recently) when I query the CAN devices in the CAN setup screen, it always returns it as 1Mbps. Then I can change to 500kbps again, powercycle the modul, query again and it is again 1Mbps. I think this is only a glitch on the screen, as if it wasn't 500kbps then none of the gauges would work on the same bus and I assume the lambda1 error would report some sort of error code too.

Those are the AEM x-series gauges I mentioned earlier. Each have a unique CAN ID. Going from stream1 up: Link CAN lambda fuel pressure oil pressure oil temp EGT (this will be converted to a transmit) boost(this is sort of redundant as I have a map sensor obviously, so I might need to give this one up) CAN gauge to display lambda (only configured to test the functionality) ECUMaster EGT modul)

here you go: https://1drv.ms/u/s!Ale4oyMCOgLThN5RLlf4fi2B2J4CqQ?e=GiJK20 the AEM EGT is coming out and the channel will be converted to transmit to an other AEM CAN gauge. So there are 3 more temp sensors going in to be able to see how much heat the turbo puts into the air and what the IC efficiency is, and 3 more pressure sensors to monitor emap at different stages of the exhaust system.