Hardcoding a LagFactor / Smoothing the baro sensor
Moderators: jsmcortina, muythaibxr
-
- Experienced MS/Extra'er
- Posts: 374
- Joined: Thu May 26, 2016 1:25 pm
- Location: Germany
Re: Hardcoding a LagFactor
Count on me testing this tomorrow, no matter the weather
Edit:
I have to disappoint, as I just couldn't find time. Can test thursday evening at the earliest.
Edit:
I have to disappoint, as I just couldn't find time. Can test thursday evening at the earliest.
My project: Link
-
- Experienced MS/Extra'er
- Posts: 374
- Joined: Thu May 26, 2016 1:25 pm
- Location: Germany
Re: Hardcoding a LagFactor
Well, I found some time. Unfortunately the code doesn't seem to be working yet - baro is oscillating between min and max
I'll try to help find the problem later this evening. I already checked if the patching went wrong, but it's the same when I apply all changes manually.
edit:
This is with min and max limits as liberal as possible.
I'll try to help find the problem later this evening. I already checked if the patching went wrong, but it's the same when I apply all changes manually.
edit:
This is with min and max limits as liberal as possible.
My project: Link
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Sorry about that. Afraid it's another "sheesh" mistake: accum_baro needs to be cleared to start the next average. That certainly explains the randomness.
To fix it just put "accum_baro = 0" at the close of the block containing the assembly snippet:
Maybe you'll have it working on Thursday after all.
Have fun,
Rob.
To fix it just put "accum_baro = 0" at the close of the block containing the assembly snippet:
Code: Select all
if (++adc_count == 64)
{
adc_count = 0;
// convert accumulated value to mean kPa x 10.
// outpc.baro = flash4.baro0 + (long)
// ((flash4.baromax - flash4.baro0)*accum_baro / 65536)
__asm__ __volatile__ (
"ldd %1\n"
"subd %2\n"
"ldy %3\n"
"emul\n"
"tfr y,d\n"
"addd %2\n"
: "=d"(outpc.baro)
: "m"(flash4.baromax),
"m"(flash4.baro0),
"m"(accum_baro)
: "y", "x");
if (outpc.baro < flash4.baro_lower) {
outpc.baro = flash4.baro_lower;
} else if (outpc.baro > flash4.baro_upper) {
outpc.baro = flash4.baro_upper;
}
accum_baro = 0;
}
Have fun,
Rob.
-
- Experienced MS/Extra'er
- Posts: 374
- Joined: Thu May 26, 2016 1:25 pm
- Location: Germany
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Oops, meant to say tuesday.
---
It works
Here's a comparison on the test bench. In the top, the unfiltered ADC is displayed as a reference. The 'competitor' is lag factor 50 in the graph on the left, and as a reference the unfiltered baro (LF 100) in the right picture. LF50 is somewhat proportional to the raw ADC and provides a little dampening.
Notice that the single little spike on the Mean64 is just .1kpa, the minimal change possible. Otherwise it's rock steady.
Looks very good to me right now, but keep in mind the raw ADC is free of spikes with the MS not in operation.
I plan to reinstall the MS and have a test drive in the evening to see how it works in practice. As I already know that even values as low as LF15 still don't handle the spikes well I won't do a back to back test drive with the standard vs. the modded code and will rely on the unfiltered ADC values as reference.
---
It works
Here's a comparison on the test bench. In the top, the unfiltered ADC is displayed as a reference. The 'competitor' is lag factor 50 in the graph on the left, and as a reference the unfiltered baro (LF 100) in the right picture. LF50 is somewhat proportional to the raw ADC and provides a little dampening.
Notice that the single little spike on the Mean64 is just .1kpa, the minimal change possible. Otherwise it's rock steady.
Looks very good to me right now, but keep in mind the raw ADC is free of spikes with the MS not in operation.
I plan to reinstall the MS and have a test drive in the evening to see how it works in practice. As I already know that even values as low as LF15 still don't handle the spikes well I won't do a back to back test drive with the standard vs. the modded code and will rely on the unfiltered ADC values as reference.
My project: Link
-
- Experienced MS/Extra'er
- Posts: 374
- Joined: Thu May 26, 2016 1:25 pm
- Location: Germany
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Overview, baro behaviour for whole log, compared with LF100. The mean values of both graphs fit the expected values for the test route very well (2 different routes in this graph).
This is zoomed in, time frame of 47 seconds. Both logs are in idle at this point and should display a constant value.
Notice how Mean64 alternates between 99.3 and 99.4 kpa.
Same again in comparison with LF30. LF30 actually makes it worse, transforming the spikes into (slightly lower) plateaus.
Now for the resulting fuelCorrs caused by the baro.
Overview:
Zoomed in:
As it seems to work nicely for most of the time, I tried finding the worst part in the logs. The worst resulting noise I found was worth an offset of .3kpa in relation to the assumed "true" value. As there ony seems to be one data point in 14 minutes worth of log with this value, I think an additional filter for spikes would be overkill. For comparison, jumps of 2.0kpa weren't that unusual using LF100.
This is one of the log files recorded during testing, in case someone is interested. ADC6 is the unfiltered baro ADC. Conclusion:
The algorithm seems to work very well. The limiting factor for even better results seems to be the limitation of the outpc.baro to 0.1kpa. Even though the spikes with unknown origin aren't filtered especially, they don't seem to cause harm anymore. There may be a less drastic improvement when using a 100kpa sensor instead of the standard 250kpa MPX4250, but with the data I collected so far I have no doubts that it'll still be there when switching sensors. At this point, this code seems like a significant improvement to me. Many thanks for your efforts, Rob!
Let me say it this way. I'll try adapting this for MAT and CLT tomorrow
Many thanks again!
This is zoomed in, time frame of 47 seconds. Both logs are in idle at this point and should display a constant value.
Notice how Mean64 alternates between 99.3 and 99.4 kpa.
Same again in comparison with LF30. LF30 actually makes it worse, transforming the spikes into (slightly lower) plateaus.
Now for the resulting fuelCorrs caused by the baro.
Overview:
Zoomed in:
As it seems to work nicely for most of the time, I tried finding the worst part in the logs. The worst resulting noise I found was worth an offset of .3kpa in relation to the assumed "true" value. As there ony seems to be one data point in 14 minutes worth of log with this value, I think an additional filter for spikes would be overkill. For comparison, jumps of 2.0kpa weren't that unusual using LF100.
This is one of the log files recorded during testing, in case someone is interested. ADC6 is the unfiltered baro ADC. Conclusion:
The algorithm seems to work very well. The limiting factor for even better results seems to be the limitation of the outpc.baro to 0.1kpa. Even though the spikes with unknown origin aren't filtered especially, they don't seem to cause harm anymore. There may be a less drastic improvement when using a 100kpa sensor instead of the standard 250kpa MPX4250, but with the data I collected so far I have no doubts that it'll still be there when switching sensors. At this point, this code seems like a significant improvement to me. Many thanks for your efforts, Rob!
Let me say it this way. I'll try adapting this for MAT and CLT tomorrow
Many thanks again!
My project: Link
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Looks good. As you say, what jitter there is is at the finest unit of resolution.
As I pointed out in that posting a couple of years ago, MS2 lag factors don't do what people think they do. For slow changing inputs -- baro, CLT, vBatt, and probably MAT and TPS -- a simple average will be more robust against noise. And for the fastest changing input, MAP, the code was changed some time back because an averaged over-sampled value was so much better. I think there's a good case for getting rid of the lag factors altogether.
Similar code changes for MAT and CLT should do the trick. There is probably scope for sharing one 64 sample counter between them all. I don't expect MAT or CLT will make any difference to performance, but the graphs will look a bit cleaner.
Anyhow, while I'm a little embarrassed about the coding errors (being careless with a "simple" change), you're very welcome; glad to have helped.
Have fun,
Rob.
As I pointed out in that posting a couple of years ago, MS2 lag factors don't do what people think they do. For slow changing inputs -- baro, CLT, vBatt, and probably MAT and TPS -- a simple average will be more robust against noise. And for the fastest changing input, MAP, the code was changed some time back because an averaged over-sampled value was so much better. I think there's a good case for getting rid of the lag factors altogether.
Similar code changes for MAT and CLT should do the trick. There is probably scope for sharing one 64 sample counter between them all. I don't expect MAT or CLT will make any difference to performance, but the graphs will look a bit cleaner.
Anyhow, while I'm a little embarrassed about the coding errors (being careless with a "simple" change), you're very welcome; glad to have helped.
Have fun,
Rob.
-
- Site Admin
- Posts: 39621
- Joined: Mon May 03, 2004 1:34 am
- Location: Birmingham, UK
- Contact:
Re: Hardcoding a LagFactor / Smoothing the baro sensor
All good info. I'm not sure if there's enough free RAM to do this though, the last time ai checked it was extremely close.
James
James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Do you need this? If your MAT / CLT is fluctuating that fast, something is seriously wrong.Dennis_Zx7r wrote:Let me say it this way. I'll try adapting this for MAT and CLT tomorrow
Temporarily shut down - back soon!
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Is it all that bad? Output of objdump -h megasquirt2.elf includes:jsmcortina wrote:All good info. I'm not sure if there's enough free RAM to do this though, the last time ai checked it was extremely close.
Code: Select all
Idx Name Size VMA LMA File off Algn
11 .bss 00000e0d 00003000 00003000 00001000 2**0
If you're interested, I can win you 1 byte of RAM for free, and three bytes pretty cheaply.
For free, change _stack in memory.x to 0x4000 -- stack decrements before a push so it doesn't matter that 0x4000 is read-only.
At some cost, modify crt0.o so it invokes _main using JMP rathern than JSR. Better yet, it wouldn't be hard to get rid of crt0 altogether and start in main.
Actually, now that I think about it, setting _stack in memory.x to 0x4002 would win you all three bytes for nothing since the crt0 JSR would try pushing to flash and _main would start up with stack at 0x4000 as it should. Bit of a hack though.
dontz125: there were strange jiggles in the CLT graph which, like you, I'd be more inclined to track down rather than cover up. I think applying the averaging to vBatt might be more worthwhile since it has a stronger effect on PW and dwell, and the lag factor behaviour is much more harmful there.
Have fun,
Rob.
Re: Hardcoding a LagFactor / Smoothing the baro sensor
very interesting results.
Maybe this could be considered in future firmware releases, also for MS3.
I've got same problems, especially with all that stuff i installed in the proto-area.
There are always very short peaks in the signal.
I tried to lower the lag factor, but like said you always get a offset from the real value then.
Maybe this could be considered in future firmware releases, also for MS3.
I've got same problems, especially with all that stuff i installed in the proto-area.
There are always very short peaks in the signal.
I tried to lower the lag factor, but like said you always get a offset from the real value then.
-
- Site Admin
- Posts: 39621
- Joined: Mon May 03, 2004 1:34 am
- Location: Birmingham, UK
- Contact:
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Rob,
yes, the stack is that close. If you put it below the data then it would clobber I/O registers instead??
James
yes, the stack is that close. If you put it below the data then it would clobber I/O registers instead??
James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
-
- Experienced MS/Extra'er
- Posts: 374
- Joined: Thu May 26, 2016 1:25 pm
- Location: Germany
Re: Hardcoding a LagFactor / Smoothing the baro sensor
I'm talking about this level of noise:dontz125 wrote:Do you need this? If your MAT / CLT is fluctuating that fast, something is seriously wrong.Dennis_Zx7r wrote:Let me say it this way. I'll try adapting this for MAT and CLT tomorrow
For CLT, there's no practical advantage in my case, mainly getting a cleaner graph in the logs. Remembered this worse. Older logs proved me wrong, though.
It's about +-0,5°C on MAT usually with rare spikes of up to +-1°C. This leads to a fuel corr of +-0.35% caused by MAT noise. I think that's no reason for concern in relation to other factors, but to me as a perfectionist it's something that could be eliminated quite easily. Guess how many hours I tried finding the cause of this on the hardware side
As suggested earlier, I looked into BattV. I'm currently using semi sequential and therefore have to use 2 sqirts per cycle. This results in these small PW, where the DT makes up 50% of the number. Using smaller injectors isn't an option, as this is a common setup for OEMs and similiar engines. However, full sequential is in the making, so I guess that'll reduce the DT influence quite a bit. Just as a background why these numbers are the way they are.
This signal is using LF50 with rounding right now. A typical spike consists in a change of .2V. I calculated the change in PW free from all other corrections and all other parameters going into the fuelcalc constant. It's about 2% relative to PW, or even about 4.1% in relation to the effective PW (time of fuel being injected without DT). Similiar numbers for dwell. Didn't think it would be that much.
Assuming this was noise of course, not real changes in the on-board voltage. Should be halfed on sequential, and of course also less of an issue on setups with higher PW.
The problem I see here is the resolution of BattV. The minimal step size of 0.1V for the BattV corr would still mean a 2% change in mixture, even if BattV would alternate between 14 and 14.1 for example.
However, this only seems to affect idle or closed throttle in practice anyway, and with these small PW I highly doubt there's much linear behaviour of the injector left.
I'll try it nonetheless though, but I guess that'll have to wait until after my vacation.
My project: Link
Re: Hardcoding a LagFactor / Smoothing the baro sensor
James,
IIRC, the I/O area is only the bottom 1k [0:3ff] and writes below 0x3000 will be attempted writes to the 0x3D flash page.
I subscribe to the "fail early" school of thought, and stack growth into read only memory is unlikely to last as long as nibbling away at the top of variable space might. But the main thing is knowing that space is so tight.
I still find it impressive that nearly 500 bytes is filled with stack activity.
Hmm. I've just taken a closer look. For starters, main grabs 42 bytes that will never be available elsewhere. The largest argument list (7 args) is wheel_fill_event_array() and it grabs another 26 bytes at startup, making 52 bytes gone whenever it runs. But the biggest stack frame appears to be do_spkmode which grabs 112 bytes when it starts. Quite a chunk. FWIW, here are the largest stack frames I identified:
So do_spkmode() and serial() look to be the biggest. Anyhow, I included the above in case anything jumps out as a "that isn't right". Odds are that all this space is needed. It is a bit of a thing that the C language assumes an infinite stack. Tricky when the real world says otherwise.
Have fun,
Rob.
IIRC, the I/O area is only the bottom 1k [0:3ff] and writes below 0x3000 will be attempted writes to the 0x3D flash page.
I subscribe to the "fail early" school of thought, and stack growth into read only memory is unlikely to last as long as nibbling away at the top of variable space might. But the main thing is knowing that space is so tight.
I still find it impressive that nearly 500 bytes is filled with stack activity.
Hmm. I've just taken a closer look. For starters, main grabs 42 bytes that will never be available elsewhere. The largest argument list (7 args) is wheel_fill_event_array() and it grabs another 26 bytes at startup, making 52 bytes gone whenever it runs. But the biggest stack frame appears to be do_spkmode which grabs 112 bytes when it starts. Quite a chunk. FWIW, here are the largest stack frames I identified:
Code: Select all
>> dis -l 5 a 38:8127
ISR_Ign_TimerIn_paged:
38:8127 1b f1 ea LEAS -22,SP
38:812a 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
38:812f 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
38:8134 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 39:88a6
calc_advance:
39:88a6 1b f1 ed LEAS -19,SP
39:88a9 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
39:88ae 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
39:88b3 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 39:8daf
calc_rpmdot:
39:8daf 1b f1 ea LEAS -22,SP
39:8db2 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
39:8db7 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
39:8dbc 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 39:9f38
handle_spareports:
39:9f38 1b f1 ef LEAS -17,SP
39:9f3b 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
39:9f40 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
39:9f45 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 39:ab8c
sample_map_tps:
39:ab8c 1b f1 ea LEAS -22,SP
39:ab8f 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
39:ab94 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
39:ab99 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 39:b74e
idle_closed_loop_pid:
39:b74e 1b f1 e6 LEAS -26,SP
39:b751 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
39:b756 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
39:b75b 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 3a:8136
ign_wheel_init:
3A:8136 1b f1 da LEAS -38,SP
3A:8139 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3A:813e 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3A:8143 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 3b:83d4
boost_ctl:
3B:83d4 1b f1 e3 LEAS -29,SP
3B:83d7 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3B:83dc 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3B:83e1 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 3b:aa52
calc_staged_pw:
3B:aa52 1b f1 d0 LEAS -48,SP
3B:aa55 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3B:aa5a 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3B:aa5f 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 3c:8814
ego_closed_loop_pid_dopid:
3C:8814 1b f1 ec LEAS -20,SP
3C:8817 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3C:881c 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3C:8821 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 3d:8000
main:
3D:8000 1b f1 d6 LEAS -42,SP
3D:8003 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3D:8008 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3D:800d 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 3d:aae2
do_spkmode:
3D:aae2 1b f1 9a LEAS -102,SP
3D:aae5 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3D:aaea 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3D:aaef 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 5f95 (5f81:CanRxIsr)
3E:5f95 1b f1 e6 LEAS -26,SP
3E:5f98 7f 30 06 STS 0x3006 ; _.frame
3E:5f9b 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3E:5fa0 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3E:5fa5 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
>> dis -l 5 a 6830 (682b: serial)
3E:6830 1b f1 c5 LEAS -59,SP
3E:6833 7f 30 06 STS 0x3006 ; _.frame
3E:6836 18 01 ae 30 08 MOVW 0x3008,2,-SP ; _.d1,
3E:683b 18 01 ae 30 0a MOVW 0x300a,2,-SP ; _.d2,
3E:6840 18 01 ae 30 0c MOVW 0x300c,2,-SP ; _.d3,
Have fun,
Rob.
-
- Site Admin
- Posts: 39621
- Joined: Mon May 03, 2004 1:34 am
- Location: Birmingham, UK
- Contact:
Re: Hardcoding a LagFactor / Smoothing the baro sensor
Also consider when the ign_in interrupt occurs during the biggest mainloop stack usage.
James
James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
Re: Hardcoding a LagFactor / Smoothing the baro sensor
I'm interested in testing a .s19 file. My baro has a bit of noise on it too. My sensor is aslo mounted in the ECU case. I'm using a 1 bar GM map sensor with most of the plastic cut off to minimize the foot print.
I posted data logs showing noise at 70 lag and at 20.
Sent from my SM-G920V using Tapatalk
I posted data logs showing noise at 70 lag and at 20.
Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
Re: Hardcoding a LagFactor / Smoothing the baro sensor
http://www.msextra.com/forums/viewtopic.php?t=63545
Last post in this thread.
Sent from my SM-G920V using Tapatalk
Last post in this thread.
Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
-
- Experienced MS/Extra'er
- Posts: 374
- Joined: Thu May 26, 2016 1:25 pm
- Location: Germany
Re: Hardcoding a LagFactor / Smoothing the baro sensor
This is the compiled code I use. It has a hardcoded LF50 for BattV with robs's rounding mod in it too, however.
In no way am I claiming this code as my own, as this is MS2Extra 3.4.2 with the exception of robs 2 modification.
If distributing the code this way isn't ok, please let me know. From my perspective, I'm just saving this guy some time installing compiling tools and applying the patch files in this thread.In no way am I claiming this code as my own, as this is MS2Extra 3.4.2 with the exception of robs 2 modification.
My project: Link
Re: Hardcoding a LagFactor / Smoothing the baro sensor
So I got this loaded up and my baro only moves by 0.1 now. 93.7 to 93.6. Much better. Now I just need to chase down this crazy battery volt noise. DMM shows steady 14.2 but TS shows 13.9 to 14.3. Grr...
Good job.
Sent from my SM-G920V using Tapatalk
Good job.
Sent from my SM-G920V using Tapatalk
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.