Rozsko Posted November 8, 2020 Report Share Posted November 8, 2020 Hello there again, I was playing with AEM's CAN gauge (30-0312) as at the end I want that to display the lambda values from the Link CAN Lambda (which is on the way home) and potentially an other one to display EGT. Unfortunately the gauge itself is not customizable by means of specifying what ID or frame structure to use, but it has a big bunch of AEM specific message types preset. I was able to configure the G4X to send the IAT and ECT and those were displayed correctly, however the Infinity user guide states a scaling like this for the lambda vale: 0.00390625 Lambda/bit. There are other parameters with similar scaling, so I guess this is more of a generic scaling question. Do you have any idea how to translate this to G4X "language"? The multiplier and divider fields don't seem to accept fractions and they are limited to 5 digits only. Thanks Quote Link to comment Share on other sites More sharing options...
Adamw Posted November 8, 2020 Report Share Posted November 8, 2020 You can do that no worries. 0.00390625 is 1/256. Since we are converting from lambda to bits we do the opposite of bits to lambda. They also have an offset of 0.5 Lambda applied, so it would look like this: Rozsko 1 Quote Link to comment Share on other sites More sharing options...
Rozsko Posted April 30, 2021 Author Report Share Posted April 30, 2021 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 Quote Link to comment Share on other sites More sharing options...
Adamw Posted April 30, 2021 Report Share Posted April 30, 2021 That should be correct. I think their document is probably wrong. Im pretty sure I remember reading somthing years ago that the AEM load value was scaled in MBar based on a 2 Bar map sensor or something really odd. As a quick test, set up your stream like below. Parameter "5V Analog Supply (status)" will just send a zero out all the time, so you can then use the offset to send different numbers over the bus. An offset of 1 will send "1" over the bus, an offset of 1000 will send 1000 over the bus etc. So try an offset of 1, 100, 255, 1000, & 65535 and record what the gauge displays for each of those, that should give you a pretty good idea what is going on. Edit: found this on their forum too, so one of them is obviously wrong. Better check yourself: Quote Link to comment Share on other sites More sharing options...
Rozsko Posted May 1, 2021 Author Report Share Posted May 1, 2021 On 5/1/2021 at 1:33 AM, Adamw said: That should be correct. I think their document is probably wrong. Im pretty sure I remember reading somthing years ago that the AEM load value was scaled in MBar based on a 2 Bar map sensor or something really odd. As a quick test, set up your stream like below. Parameter "5V Analog Supply (status)" will just send a zero out all the time, so you can then use the offset to send different numbers over the bus. An offset of 1 will send "1" over the bus, an offset of 1000 will send 1000 over the bus etc. So try an offset of 1, 100, 255, 1000, & 65535 and record what the gauge displays for each of those, that should give you a pretty good idea what is going on. Edit: found this on their forum too, so one of them is obviously wrong. Better check yourself: 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. Quote Link to comment Share on other sites More sharing options...
Vaughan Posted May 2, 2021 Report Share Posted May 2, 2021 On 5/1/2021 at 11:33 AM, Adamw said: Parameter "5V Analog Supply (status)" will just send a zero out all the time, so you can then use the offset to send different numbers over the bus You can also do this with any variable if you give it a multiplier of 0. Quote Link to comment Share on other sites More sharing options...
Rozsko Posted May 4, 2021 Author Report Share Posted May 4, 2021 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 Quote Link to comment Share on other sites More sharing options...
Rozsko Posted May 21, 2021 Author Report Share Posted May 21, 2021 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. Quote Link to comment Share on other sites More sharing options...
Adamw Posted May 22, 2021 Report Share Posted May 22, 2021 Can you clarify some of the above. The load channel should read a max of 99.998 according to their data. But your test says 392.1 when sending only 1000 over the bus? Does it only display 1 decimal or was it displayed as 392.100? What value did the gauge show with the 65535 offset? Quote Link to comment Share on other sites More sharing options...
Rozsko Posted May 23, 2021 Author Report Share Posted May 23, 2021 On 5/22/2021 at 10:44 AM, Adamw said: The load channel should read a max of 99.998 according to their data. But your test says 392.1 when sending only 1000 over the bus? Correct. Weird. Isn't it? On 5/22/2021 at 10:44 AM, Adamw said: Does it only display 1 decimal or was it displayed as 392.100? Only 1 decimal is displayed. That is the problem with the Throttle position % too. On 5/22/2021 at 10:44 AM, Adamw said: What value did the gauge show with the 65535 offset? Never tried that, but will and will let you know. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.