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

Hardcoding a LagFactor / Smoothing the baro sensor

Post by Dennis_Zx7r »

edit: Edited the title to better describe the change in direction this thread took.
---

I want to smooth my baro sensor even further and am already at a lag factor of 15 for the CLT/MAT/BattV/Baro. Unfortunately for me I can only alter them all at once in TS, which is why I'm looking for a way to alter the baro smoothing seperately. I stumbled upon this in the code:

Code: Select all

 if(first_adc)
            outpc.baro = tmp1;
        else {
            //            outpc.baro += (short)((flash4.adcLF * (adcval - outpc.baro)) / 100);
            __asm__ __volatile__ (
                    "ldd    %1\n"
                    "subd   %3\n"
                    "tfr    d,y\n"
                    "clra\n"
                    "ldab    %2\n"      // it is a uchar
                    "emuls\n"
                    "ldx     #100\n"
                    "edivs\n"
                    "tfr     y,d\n"
                    "addd    %3\n"
                    : "=d"(outpc.baro)
                    : "m"(tmp1),
                    "m"(flash4.adcLF),
                    "m"(outpc.baro)
                    : "x", "y" );
        }
As adcLF is the lag factor for CLT/MAT/BattV/Baro, am I assuming correctly that I would have to exchange this variable with a number to hardcode a baro lag factor?
What would the correct format be, for example if I want to hardcode the factor to 10? "%10\n"?
Last edited by Dennis_Zx7r on Tue Sep 27, 2016 9:22 am, edited 1 time in total.
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

Post by robs »

In a word, don't.

Some time back I posted this thread about how lag factors are full of surprises. I'm not sure, but I don't think the developers have done anything about it in the meantime. The upshot of that thread was that it is a bad idea to use a lag factor less than 50 anywhere -- it's not so much a lag as a fuzz factor. I use 100 for all lags (but I have a median-3 filter on them instead).

I don't have a baro sensor, but I'd have thought it'd be the last thing to give noise problems.

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

Post by Dennis_Zx7r »

Well, this would explain why my MAT and baro correction results are getting worse. I just read your thread and checked old datalogs. There definately is a trend there, most noticably the maximum of BattV becoming lower and lower with newer versions of my tune (adcLF decreasing) . It's now 13.9V at LF 15 and was 14.2 with LF 50 (stable value, no peaks).

Here's what I'd like to try.
I still would like to hardcode the baro LF, although I'll keep it a little higher than I originally wanted. I'm using 15 right now, and this seems to fit the theoretical values quite nice.
This way, I hope to keep the steady baro this low factor allows me to have, and set adcLF (now only responsible for BattV/MAT/CLT) to a much higher value. I still don't know what to write in there if I want to exchange the variable with the equivalent of an integer :?:
In addition, I'll try your modified code, which uses rounding. This way, I hope to improve the steady-state error variable for the highly smoothed baro.
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

Post by robs »

A lag factor of 15 is a bad idea. Just to be clear, as stated in that thread, a lag factor of 15 means your lagged battery voltage will stop converging on the true voltage when it's within 0.66V. Since the images on that thread have been expired, here's one of the graphs I posted back then:
lags.jpg
Both plots show 10 iterations of the lag algorithm applied to a true step of 1.2V. Left is standard MS2 algorithm, right is with rounding added. The red and green lines are lags of 10 and 20. Even with rounding, 15 is not going to converge very well.

Here's another of the plots from that thread that shows how this slop is two-sided:
voltlag.jpg
That's with a 50 lag (IIRC), red standard, blue rounded. Notice how the 12.5V reading is spot on to begin with, misses on the low side, then misses on the high side. Imagine your 15 lag converging much more slowly, and with much more slop.

Anyhow, it's up to you to experiment. In your opening comment you asked how to hard-wire the lag factor. That was the right snippet of code. It's in-line assembly language and the % symbol is not to do with percentages -- it tells the C compiler how to pass arguments between its generated assembly language and this chunk of hand-written assembly code. Anyhow, if you still want a wired in 15 there change the "ldab %2\n" to "ldab #15\n" and that should do it for you. I'm assuming you have the whole build environment working and are already able to compile and link the standard firmware.

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

Post by Dennis_Zx7r »

Thanks, I really appreciate the feedback. The thing with the baro is, it just spikes a few kpa, but the noise seems normally distributed. As consistency of the signal is way more important than responsiveness on the baro, heavy smoothing would benefit the signal quality immensely in my opinion. Experimented with dozen different capacitors and resistors on the electrical side. The signal is absolutely fine, the noise is introduced after entering the processor. If I knew how, I'd just throw a mean-50 or something even higher at it. I'm fine doing this in C, but I have no clue how to do that in assembler and I doubt that the needed resources would justify the result.

Edit:
For now, I hardcoded the baro to 30, reset adcLF to 60 and implemented the rounding modification for baro, MAT, CLT and BattV. All other LF are 100. I'm open to anyone suggesting a better approach to smoothing the baro.
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

Post by robs »

Clean signal, how's the grounding? Noise on that can certainly mess up the AD conversion. There's not much chance of the noise being caused after ADC.

On the software side, in this situation I'd steer clear of averaging. You want to eliminate the noise, not spread it around. Since you're building a "special" anyway, why not pick a maximum change between samples and reject any samples that change baro by more than this number. Do it in ADC units, get rid of the old lag calculation altogether, and the processor will actually be doing (marginally) less work.

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

Post by Dennis_Zx7r »

Baro is mounted inside the MS casing, directly grounded to proto are. Signal on all other sensors is excellent from what I've seen in other logfiles. I'm successfully running AE with a TPSdot of 13, even though I'm using the WOT scaling feature (set to 30% at idle). MS itself is grounded directly to the battery, as it reduced noise compared to grounding it to the engine as recommended in the manual.
robs wrote:Since you're building a "special" anyway, why not pick a maximum change between samples and reject any samples that change baro by more than this number. Do it in ADC units, get rid of the old lag calculation altogether, and the processor will actually be doing (marginally) less work.
I'm looking into that, but at this point I'm merely a scriptkiddie when it comes to the MS code and I haven't done any assembler coding for several years. In addition to that, I'm working on (too) many things simultaneously regarding the MS, got it running only for about 3 months.
Picture shows a recent log with supposedly constant ambient pressure. I know it's not too bad, but remember this was with a LF of 15 for Baro/Clt/etc. and results in +-0,4% fueling change just due to baro noise, which i think may be completely avoidable. It would be about +-1.5% without filtering.
graph.png
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

Post by robs »

Would be interesting to see a log with lag=100. I gather this is on a bike. Depending on where the baro sensor is picking up air, a lot of noise could enter its signal from turbulence or exhaust noise. It's much less jittery at idle.

Now that I see the plot, rather than my earlier suggestion, I think you're right to look for an averaging solution. The ADC gives a 10-bit value. If you just added each sample for 64 samples, this will give a full 16-bit value which will be easy to scale (and has a nice nerdy computing feel about it). Only updating the real variable every 64 samples can't help but reduce the noise frequency; you'd expect averaging this many samples would reduce the amplitude too.

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

Post by Dennis_Zx7r »

robs wrote:I gather this is on a bike. Depending on where the baro sensor is picking up air, a lot of noise could enter its signal from turbulence or exhaust noise. It's much less jittery at idle.
It's inside the MS box. The MS is mounted in a place enclosed in the back of the vehicle inside the (closed) fairings, where there is nearly no airflow whatsoever. Well, turns out that in all logs, there is a correlation between speed (vehicle) and the baro nonetheless. I also checked RPM vs Baro, way less correlation than Speed vs Baro. Didn't expect to see that, and I'll definately try to improve this. Will be hard though, as I can't imagine a better location right now :?
Image
robs wrote:Would be interesting to see a log with lag=100.
This plot is with 100LF. +-1.5kpa, which equals spikes of +-1.3% fueling change in my baro corr when there should be none, and rare spikes of 1.5%. Bike not moving, idle.
Image

What I've definately planned is to replace the Mpx4250 with a Mpx4115, which is 115kpa max instead of 250 at 5V. I'm trying to write some smoothing code in the next few days in C. Gave up on trying to do this in assembler and on using the lag factor.
My project: Link
jsmcortina
Site Admin
Posts: 39587
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: Hardcoding a LagFactor

Post by jsmcortina »

Is that baro-correction really correct? It seems large that barocor is having an equal effect on fuelling.

I'll add baro smoothing to the TO-DO list.

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

Post by Dennis_Zx7r »

jsmcortina wrote:Is that baro-correction really correct? It seems large that barocor is having an equal effect on fuelling.
Image
This is my current curve, built on steadied ego-correction values in idle. 100% is at about 98kpa. No obvious correlation between AFR-offsets and baro readings in the logfiles running this curve, too.
For the flat spots, I didn't gather data yet, and the 88-point is extrapolated a little. Also, it seems to fit in nicely with OEM data for a similiar sportsbike, although the OEM curve is even steeper. I guess it's because their fuel pressure isn't compensated.
jsmcortina wrote:I'll add baro smoothing to the TO-DO list.
Thank you!
My project: Link
dontz125
Super MS/Extra'er
Posts: 4200
Joined: Mon May 11, 2009 7:14 pm
Location: York, ON
Contact:

Re: Hardcoding a LagFactor

Post by dontz125 »

Dennis_Zx7r wrote:It's inside the MS box. The MS is mounted in a place enclosed in the back of the vehicle inside the (closed) fairings, where there is nearly no airflow whatsoever. Well, turns out that in all logs, there is a correlation between speed (vehicle) and the baro nonetheless. I also checked RPM vs Baro, way less correlation than Speed vs Baro. Didn't expect to see that, and I'll definately try to improve this. Will be hard though, as I can't imagine a better location right now :?
I'm not surprised to see a significant vaccum in / under the tail. If you have the harness length, try tucking the MS box in the very nose of the bike, forward of the gauges.
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

Post by robs »

The lag=100 plot is interesting and I've changed my mind back again -- the spikes look spurious and a median filter would be more the thing, discarding them rather than spreading them around as an averaging filter would. Not as easy to code though.

But where are the spikes coming from? As dontz125 says, a speed/pressure trend is not too surprising and, as long as it reflects the air pressure at your air filter, it's doing its job. The spikes are another thing. Perhaps an experiment wrapping the MS box in some sort of sound insulation might be worth trying.

You earlier said that the signal was clean. Was that using an oscilloscope? If MS spikes like that in a few seconds near idle and it isn't spiking on a scope, that suggests the AD conversion ground reference itself is noisy. But then all your other AD inputs are clean (are they still clean with lag=100?). Beats me. In any case, fitting a higher resolution sensor sounds a good idea and will surely reduce any lurking electrical noise problems.

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

Post by Dennis_Zx7r »

robs wrote:You earlier said that the signal was clean. Was that using an oscilloscope? If MS spikes like that in a few seconds near idle and it isn't spiking on a scope, that suggests the AD conversion ground reference itself is noisy. But then all your other AD inputs are clean (are they still clean with lag=100?).
Image
The spikes didn't show on an oscilloscope. Overall, the signal was less noisy than in the logs. Unfortunately I didn't measure it again with the sensor connected to the MS and I can't access it to do so right now (borrowed, not mine). TPS seems fine to me? Don't mind the MAP, it's always this way on idle and a QuadraMap's with 115kpa sensors is already ordered. Isn't it kinda strange, that baro isn't proportional to baro correction, or is this simply due to my low data rate (~17/s to 18/s)?
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

Post by robs »

As you said earlier, those baro spikes are around 1.5kPa. With the 2.5 bar sensor that's about 30mV which mightn't stand out all that much on the scope (depending on how it's configured). The CLT graph does a lot more jiggling than I'm used to. Could be other things, but it's quite like a grounding problem. Have you done the quick test of unplugging the MS DB37 and checking with an ohmmeter that none of the sensors has another path to ground?

TPS does look good, but I'm pretty sure it's doing oversampling and averaging. MAP is impressively jittery -- I take it you're not using the MAP averaging option. And yes, the log file only gets a smallish proportion of all the stuff the MS sees. You have to assume that the MS barocor is responding to values that didn't make it to the log file.

I'd be happy to help with code changes if it's not sorted by the new sensor (or other hardware tweaks). If you want that, better let me know what code version you're using. Happy to experiment with mean64 or spike rejection approaches or whatever you think might help.

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 »

robs wrote:As you said earlier, those baro spikes are around 1.5kPa. With the 2.5 bar sensor that's about 30mV which mightn't stand out all that much on the scope (depending on how it's configured). The CLT graph does a lot more jiggling than I'm used to. Could be other things, but it's quite like a grounding problem. Have you done the quick test of unplugging the MS DB37 and checking with an ohmmeter that none of the sensors has another path to ground?
I just checked yesterday, there's no path to ground on any sensor. The baro itself is grounded in the proto area.
robs wrote:MAP is impressively jittery -- I take it you're not using the MAP averaging option.
I DO use averaging, all 4 ITBs connected. It's only this jittery in idle, way better while driving. This is on a 20 year old superbike with ITBs and very wide, short intake ports, a light crankshaft and cams delivering peak torque at about 9500rpm. Driveability is very good nonetheless, and totally smooth compared to the original carbs. However, I already ordered a QuadraMap in trying to improve the signal.
Image
---
robs wrote:I'd be happy to help with code changes if it's not sorted by the new sensor (or other hardware tweaks). If you want that, better let me know what code version you're using. Happy to experiment with mean64 or spike rejection approaches or whatever you think might help.
I'd gladly volunteer to be the guinea pig for a mean64. I'm using MS2Extra. I checked several 6 second intervals in my logs for their average (data rate ~11/s). Even in the worst case with large spikes in the baro in one direction I could find in a log, it only differs by about 0.15 kpa comparing the mean of 64 data points. I think this would be absolutely sufficient, even without spike elimination.
Worst case in log:
Image
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

Post by robs »

I was after the particular release of MS2/Extra -- so that I can be sure the patch will match the version you're building. The name of the top-level directory of the devel tree will do (e.g. "ms2extra_3.3.1a_release").

Just to be clear, mean64 will be on 64 internal samples so will update much more frequently than at 6 second intervals. Should still smooth things up pretty well. I think I'll drop the lag-factor calculation for baro at the same time. Doesn't seem sensible to apply two different "mean" filters.

Tied up today, but should be able to get to this over the weekend.

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

Post by Dennis_Zx7r »

I'm using the latest stable, 3.4.2.
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

Post by robs »

I've made what I think are suitable changes. Untested (I don't have a baro sensor), but it does compile and I think everything is covered.

Here's a patch to apply to the ms2extra-release-2.4.2 code:

Code: Select all

diff -Naur orig/ms2_extra_misc.c new/ms2_extra_misc.c
--- orig/ms2_extra_misc.c	2016-09-24 07:43:49.000000000 +1000
+++ new/ms2_extra_misc.c	2016-09-24 09:15:29.000000000 +1000
@@ -609,49 +609,40 @@
             tmpadc = 0;
         }
 
-        //          adcval = (long)flash4.baro0 +
-        //            ((long)(flash4.baromax - flash4.baro0) * tmpadc) / 1023; // kPa x 10
-        __asm__ __volatile__ (
+        if(first_adc) {		// start with 64xfirst sample
+	    adc_count = 63;
+            outpc.baro = tmpadc << 6;
+	} else {
+	    accum_baro += tmpadc;
+	}
+	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"
-                "ldx    #1023\n"
-                "ediv\n"
                 "tfr    y,d\n"
                 "addd   %2\n"
-                : "=d"(tmp1)
+                : "=d"(outpc.baro)
                 : "m"(flash4.baromax),
                 "m"(flash4.baro0),
-                "m"(tmpadc)
+                "m"(accum_baro)
                 : "y", "x");
-
-        if(first_adc)
-            outpc.baro = tmp1;
-        else {
-            //            outpc.baro += (short)((flash4.adcLF * (adcval - outpc.baro)) / 100);
-            __asm__ __volatile__ (
-                    "ldd    %1\n"
-                    "subd   %3\n"
-                    "tfr    d,y\n"
-                    "clra\n"
-                    "ldab    %2\n"      // it is a uchar
-                    "emuls\n"
-                    "ldx     #100\n"
-                    "edivs\n"
-                    "tfr     y,d\n"
-                    "addd    %3\n"
-                    : "=d"(outpc.baro)
-                    : "m"(tmp1),
-                    "m"(flash4.adcLF),
-                    "m"(outpc.baro)
-                    : "x", "y" );
-        }
-        if (outpc.baro < flash4.baro_lower) {
-            outpc.baro = flash4.baro_lower;
-        } else if (outpc.baro > flash4.baro_upper) {
-            outpc.baro = flash4.baro_upper;
+	    if (outpc.baro < flash4.baro_lower) {
+		outpc.baro = flash4.baro_lower;
+	    } else if (outpc.baro > flash4.baro_upper) {
+		outpc.baro = flash4.baro_upper;
+	    }
         }
+
+	// Convert ADC units to kPa x 10
+        //          adcval = (long)flash4.baro0 +
+        //            ((long)(flash4.baromax - flash4.baro0) * tmpadc) / 1023; // kPa x 10
     }
 
     if (((flash4.EgoOption & 0x07) == 2) || ((flash4.EgoOption & 0x07) == 4))  {
diff -Naur orig/ms2_extra_vars.h new/ms2_extra_vars.h
--- orig/ms2_extra_vars.h	2016-09-24 07:43:49.000000000 +1000
+++ new/ms2_extra_vars.h	2016-09-24 09:08:44.000000000 +1000
@@ -211,12 +211,12 @@
 extern unsigned int TC_ovflow;
 extern unsigned long lmms,t_enable_IC,t_enable_IC2,Rpm_Coeff,ltch_lmms,ltch_lmms2,rcv_timeout;
 extern unsigned int asecount, adc_lmms;
-extern unsigned char flocker,tpsaclk,egocount,igncount,altcount,next_adc,first_adc,   
-        txmode, burn_idx, crc_idx, synch,
+extern unsigned char flocker,tpsaclk,egocount,igncount,altcount,next_adc,first_adc,
+        txmode, burn_idx, crc_idx, synch, adc_count,
         egopstat[2], FSensStat,knk_clk,knk_clk_test,knk_stat,knk_count,mms,millisec;
 extern unsigned char rxmode, srl_err_cnt;
 extern unsigned int burnstat;
-extern unsigned int boost_ctl_timer;
+extern unsigned int boost_ctl_timer, accum_baro;
 #define SYNC_SYNCED     0x1
 #define SYNC_FIRST      0x2
 #define SYNC_RPMCALC    0x4
Apply the patch by:
  1. save patch file to my.patch
  2. cd ms2extra
    patch -p1 < my.patch
Removed more lines than were added, but the image ended up 29 bytes larger. Could have reused first_adc to keep count, but decided to keep it simple. 3 extra bytes of RAM used.

Fingers crossed, this will make your baro correction a bit steadier. I'm sure you'll let us know.

Have fun,

Rob.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: Hardcoding a LagFactor

Post by robs »

Sheesh. Silly mistake.

Code: Select all

+            outpc.baro = tmpadc << 6;
should have been

Code: Select all

+           accum_baro = tmpadc << 6;
It would only affect the very first baro reading, which would be pretty much random.

Here's a zip file of the fixed patch.
smbaro.zip
Have fun,

Rob.
Post Reply