[chbot] Data filter

[Eliot Blennerhassett]

On 12/05/21 10:11 am, Marshland Engineering wrote:
> This is one of those projects where you learn what is required while doing the
> project!!!
> 
> Make sure you have had you coffee fix before reading on !!   
> 
> This is version 2 of my dyno both hardware and software. The old version was a
> bought package that used a freq to voltage converter and then an A to D
> converter for the input to the PC but the resolution was very poor and I had
> to do a lot of fiddling with higher power bikes to get reasonable data.  

Can we see a picture of the relevant hardware in action?
Also the relevant code on the Atmega that does the sampling.

> My idea with this version is to get as high a resolution as I can, however,
> what this has highlighted is, how many samples do you need for an A4 page size
> graph, and what kind of resolution do I need?
> 
> Here is my data with my current parameters.
> 
> http://www.marshland.co.nz/ftp/Delphi/Plot.jpg
> 
> If you have some time to spare, here is my logic and happy for it to be picked
> to pieces. 
> 
> The drum speed goes from 45 to 65 kph over 4 seconds. Or 12.5 to 18 m/s. 
> Each timing period from the drum represents 200mm on the surface.

I'm assuming a shaft encoder on the drum that outputs a pulse every 200mm

At 12.5m/s you get 62.5 impulses per second.
At 18m/s you get 90 impulses per second.

I suggest that you should be measuring these intervals and storing them directly as your raw data,
they represent the limit of what your setup can measure.

Each interval gives an average speed over the distance travelled. 


> Over the time period, I take 120 samples. That should be enough for an A4

I'm sampling at 30 hz
. 
> The average rate of change of each sample is 0.17 kph or 47 mm/s. If I take
> the 0.17m over the average speed range of 55, it is
> 1/330 or 0.3 %. That is quite optimistic for dyno, but it where I'm starting. 
> 

So you measure the time for the drum to travel 200mm

> ATMEGA can count up to 65535 clock cycles in this period.  My resolution with
> the ATMEGA is therefore  0.003 mm per clock cycle.  

I don't get this logic. The drum is moving a different speeds

> I think I have enough resolution for what I want. 
> 
> One of the problems is that the wheel to drum, engine speed changes etc are
> not exactly linear. I believe this is where the noise is from, however, the
> data below the noise is valid.  

Question is what is "data" and what is "noise" in the context of your experiment.

Is there real variation from slight eccentricity in the tyre on the drum etc etc?



> I can improve the plots by fewer samples, ie getting a bigger rate of change
> between samples but then my resolution will decrease. Maybe 30 hz is too high
> and 0.3 % too optimistic. 
> 
> If not, what filters can I use to smooth the data ? I've looked at a lot of
> them but creating the maths code to use them is a bit beyond my scope at the
> moment.  I'm using Delphi and I cant find any Components for smoothing. 
> 
> The best I found was taking 10 samples, deleting the max and min and averaging
> the rest. If I did that a second time with the result, it wasn't that bad but
> still looking for a better solution. 

A moving average filter is a really bad low-pass filter.

See the green line in the first graph here: https://ptolemy.berkeley.edu/eecs20/week12/freqResponseRA.html

I remember doing something a few years ago about some cam analysis data, where a decent low-pass made 
quite a difference to the result. I still have that around somewhere...

--
Eliot