Hardcoding a LagFactor / Smoothing the baro sensor

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Hardcoding a LagFactor

Post by Dennis_Zx7r »

Count on me testing this tomorrow, no matter the weather :yeah!:

Edit:
I have to disappoint, as I just couldn't find time. Can test thursday evening at the earliest.
My project: Link
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Hardcoding a LagFactor

Post by Dennis_Zx7r »

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.
Image
2016-09-27_17.43.24.msl
edit:
This is with min and max limits as liberal as possible.
Image
2016-09-27_18.41.40.msl
My project: Link
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by robs »

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:

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;
        }
Maybe you'll have it working on Thursday after all.

Have fun,

Rob.
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by Dennis_Zx7r »

Oops, meant to say tuesday.
---

It works :P
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.

Image Image

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
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by Dennis_Zx7r »

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).
Image

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.
Image

Same again in comparison with LF30. LF30 actually makes it worse, transforming the spikes into (slightly lower) plateaus.
Image

Now for the resulting fuelCorrs caused by the baro.
Overview:
Image
Zoomed in:
Image

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.
Image

This is one of the log files recorded during testing, in case someone is interested. ADC6 is the unfiltered baro ADC.
2016-09-28_19-22-08.msl
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
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by robs »

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.
jsmcortina
Site Admin
Posts: 39587
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by jsmcortina »

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
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".
dontz125
Super MS/Extra'er
Posts: 4200
Joined: Mon May 11, 2009 7:14 pm
Location: York, ON
Contact:

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by dontz125 »

Dennis_Zx7r wrote:Let me say it this way. I'll try adapting this for MAT and CLT tomorrow :)
Do you need this? If your MAT / CLT is fluctuating that fast, something is seriously wrong. :?
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by robs »

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.
Is it all that bad? Output of objdump -h megasquirt2.elf includes:

Code: Select all

Idx Name          Size      VMA       LMA       File off  Algn
 11 .bss          00000e0d  00003000  00003000  00001000  2**0
0x1000 - 0x0e0d = 0x01f3 == 499 bytes of RAM not directly allocated by compiler/linker. That's a fair bit, though it might get exhausted by long argument lists or large automatic variables. I see there's a stack_watch() function, but it might be a better approach to mess with the link map, putting the data segment at the top of RAM and growing the stack downwards below the data. Could still keep a sentinel byte at 0x3000, but even if the watcher function misses it, at least important data won't be clobbered. Of course all easy for me to say.

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.
Speedy_G
Experienced MS/Extra'er
Posts: 195
Joined: Fri Aug 01, 2014 8:30 am

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by Speedy_G »

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.
jsmcortina
Site Admin
Posts: 39587
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by jsmcortina »

Rob,
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".
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by Dennis_Zx7r »

dontz125 wrote:
Dennis_Zx7r wrote:Let me say it this way. I'll try adapting this for MAT and CLT tomorrow :)
Do you need this? If your MAT / CLT is fluctuating that fast, something is seriously wrong. :?
I'm talking about this level of noise:
ImageImage
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 :mrgreen:

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
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by robs »

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:

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,
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.
jsmcortina
Site Admin
Posts: 39587
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by jsmcortina »

Also consider when the ign_in interrupt occurs during the biggest mainloop stack usage.

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".
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by ol boy »

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
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.
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by ol boy »

http://www.msextra.com/forums/viewtopic.php?t=63545

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.
Dennis_Zx7r
Experienced MS/Extra'er
Posts: 374
Joined: Thu May 26, 2016 1:25 pm
Location: Germany

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by Dennis_Zx7r »

This is the compiled code I use. It has a hardcoded LF50 for BattV with robs's rounding mod in it too, however.
megasquirt2_ModMean64Baro+RoundedLF50BattV.s19
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
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: Hardcoding a LagFactor / Smoothing the baro sensor

Post by ol boy »

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
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.
Post Reply