## Removing random noise signals without delay

9 posts / 0 new
Author
Message
if(distance<40)
{
if(TCNT1>156 && p<6)                                                    //0.01s when used with 1024 prescaler
{
sv[p]=distance; p++; TCNT1=0;                                   //resetting the timer and incrementing array position
}
else if((sv[1]<40 && sv[1]!=0) && (sv[2]<40 && sv[2]!=0) && (sv[3]<40 && sv[3]!=0) && (sv[4]<40 && sv[4]!=0) && (sv[5]<40 && sv[5]!=0))
{
n=1;                                                                     //indicating distance is lesser than 40
TCNT1=0; sv[0]=0; sv[1]=0; sv[2]=0; sv[3]=0; sv[4]=0; sv[5]=0;   //reseting the array and timer
p=0;
}
if(p==6)
p=0;
}

I am using this code to remove random errors given by a long distance sensor. Although this code does work i want to ensure if its actually checking the errors or is it coming to be true at random?

I check whether the distance has been lesser than a specified value for atleast 5 times, checked every 0.01 seconds. If it is, I assume that the value is actually lesser than the specified value.

The last condition is not needed when using only this code, but has been added due to certain other parts of the entire code.

I'm sorry but what's the question?

Also, if you want people to look at your code, you need to show us what size all your variables are.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Brian Fairchild wrote:
Also, if you want people to look at your code, you need to show us what size all your variables are.
Also things like what the mystery 'p' variable is and what it represents

On the surface the code looks extremely confused which almost certainly means it is not the result of thorough design.

"I check whether the distance has been lesser than a specified value for atleast 5 times, checked every 0.01 seconds. "

How is that "without delay"?

Four legs good, two legs bad, three legs stable.

Tell us a bit more about the noise:

What is a "good" distance ?

How often does the noise appear ?

How have you characterised the noise ? (Impulse on otherwise completely clean signal or burst of noise etc.)

and a bit of useful info about the prooject:

What sort of sensor ?

What interface ? (Analogue/Digital) How are you connecting it ?

Only once we have the above detail can any freak here stand a decent chance of reviewing the code as to how well it rejects any noise.

PS: If you maintain a 6-deep pipeline of readings surely you can dispense with the timer because each array member has an inherent "age". Unless I'm misunderstanding the code; clearing to 0 is probably not right however.

PPS: What sort of F*c&ing idiot JavaScript hacker overrides right click in this editing frame which breaks Firefox spelling correction ?

Last Edited: Fri. Sep 21, 2018 - 10:06 AM

N.Winterbottom wrote:

PPS: What sort of F*c&ing idiot JavaScript hacker overrides right click in this editing frame which breaks Firefox spelling correction ?

See the recent topic I made in 'Site Feedback'.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Depending of the kind of noise perhaps a median filter could be used

First:

1). Variable names with less than 3 letters are hard to read. Longer names can be easily searched for and highligheded in a decent IDE which makes it a lot easier for other people to scan the code for where a particular variable is used.

2). Where does your "distance" come from? How and how often is it updated?

3). Do not use "magic values" in your code. What does "40" mean? What if you want to change "40 to 38 ?

4). Manual "unrolling" of loops is tedious and error prone and has a big code size. Use loops to clear arrays, check values etc. (Speed penalty for a loop is minimal, FLASH is precious in a small uC).

5). Always, I mean *** ALWAYS *** use braces around compound statements, even if blocks of 1 line. This prevents nasty bugs from creaping into your code while editing. It is only allowed to not use braces with single line statements for historical compatibility reasons, but it is bad practice nontheless.

Designing good algorithms is a very dificult task and completely separate from learning a programming language.

if(distance<40)

And then fill an array with values < 40, and check that 5 times ???

Those values will always be < 40.

So this does not check 5 consecutive samples, but only if there have ever been a totoal of 5 samples < 40.

A better way would be to turn your array in a circular buffer like structure, and write a value into it, then check for all 5 indices of the array.

Untested code:

#define ARRAY_SIZE 5
#define MIN_DISTANCE 40

uint16_t sv[ARRAY_SIZE];
uint8_t p;
uint8_t index;
uint8_t cnt;

if( Time_Interval_Elapsed) {
if( ++p >= ARRAY_SIZE) {	// Calc new "p" index.
p = 0;
}

sv[p] = distance;	// Store next measured distance at new index.

for( index = 0, cnt = 0; index <= ARRAY_ZIZE, ++index) {  // Check all indices for size.
if( sv[ index] < MIN_DISTANCE) {
++cnt;
}
}

if( cnt >= ARRAY_SIZE) {
// Counted 5 small values...
}
}

But it can be simplified. You do not need to save all those distances in an array, you only have to know if a distance is or is not within the intended range.

Something like:

#define COUNTER 5
#define MIN_DISTANCE 40

bool check_distance( uint16_t);

void main( void) {

for( ;;) {
if( Time_Interval_Elapsed) {
if( check_distance( distance)) {
// Found small distance
}
}
}
}

bool check_distance( uint16_t distance) {
static uint8_t cnt;

if( distance < MIN_DISTANCE) {
cnt++
}
else {
cnt = 0;
}

if ( cnt >= COUNTER) {
cnt = COUNTER	// Prevent overflow / wrap around.
// Found COUNTER consecuttive small distances.
return true;
}
return false;
}

Also:

Designing algorithms it is much easier to do on a PC.

You can have (a bunch of) arrays with test distances, and you can feed those test distances into your distance check algorithm and use printf to print all kind of intermediate values, or tables to clarify what your algorithm is doing.

Those test distances are known in advance, and can be easily made for specific test data.

You can also use single stepping, breakpoints or watching variables without having to buy Atmel / Microchip debug hardware.

Your code has 3 or more tabs on most lines, which is unexpected indentation. It also makes your text so wide that it gets wrapped in my web browser.

This probably is a left over from a cut & paste operation, but if you want to intice others to look at your code, then put some effort in it to make it easier to read.

If you copied / pasted to an empty edit window in your IDE and reformatted it those tabs would have been gone, and you would have had a check for matching braces.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Sat. Sep 22, 2018 - 01:53 PM

I check whether the distance has been lesser than a specified value for atleast 5 times

Your approach doesn't seem to make too much sense...If it is less than 40 five times in a row, then it is "likely" to really be less than 40 (and less likely to be "random")...in that case you are erasing all the values.

However, if it does not occur 5 times (say it happens only once), then you are keeping the values..but in this case it is more likely than the above case to be a glitch.

So when you are more certain about it, you erase; however if it is more likely a glitch, you keep it?   Maybe you need to clearly spell out what you are actually trying to do.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Sep 22, 2018 - 03:48 PM