Hi All,
This is my first message on this board.
I'm a newbie engineer and also new to filtering and dsp.
My project is a simple speedometer using a PIC18 and a HALL SENSOR counting
the magnets on the wheel.
I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on
every hall sensor input (falling edge), and CCP2 (special event trigger to
reset TIMER3) which is a part of a precise time counter structure.The HW is
sth like that.
/|\
|
Z o|
Z o| PIC
|--o| CCP1
| o|
\
|
///
The input is between 0.5-225 Hz
I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my
another integer that counts TIMER3 overflows (actually CCP2 autoload
interrupts)
There are 2-level depth registers keeping the 4bytes that i explained
above. The last and the previous magnet-pass moments.
Then in main loop, 1 calculate the speed by getting the distance between
two magnets and derivating it by the time difference between last two
magnet-pass times. The result is very stable.
The main loop runs at 16hz. SoThere are two timing conditions. The CCP1
frequency is greater than main loop frequency, or smaller than it.
But i have two problems;
1) when no new sample comes, the previous value (let it be 100kph) remains
for about 2 seconds (because the slowest speed is 0.5hz, i told before)
2) On high speeds, the display always toggles between 2 or 3 values. I
think you define this as ALIASING.
I just want to implement a filter to make the result MONOTONOUS and
ANTI-ALISED. I mean if the speed is increasing, it should increase or stand
still.
I read a lot of application notes on filters but Im so confused now.
What kind of a filter i should use?
How can i implement it basically?
Could you please guide me to implement it?
Thank you for reading ;)
Simple Speedometer, FILTERING HELP!
Started by ●February 17, 2012
Reply by ●February 17, 20122012-02-17
On Fri, 17 Feb 2012 08:38:42 -0600, atakan_1907 wrote:> Hi All, > This is my first message on this board. > > I'm a newbie engineer and also new to filtering and dsp. > > My project is a simple speedometer using a PIC18 and a HALL SENSOR > counting the magnets on the wheel. > > I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on > every hall sensor input (falling edge), and CCP2 (special event trigger > to reset TIMER3) which is a part of a precise time counter structure.The > HW is sth like that. > > /|\ > | > Z o| > Z o| PIC > |--o| CCP1 > | o| > \ > | > /// > > The input is between 0.5-225 Hz > > I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my > another integer that counts TIMER3 overflows (actually CCP2 autoload > interrupts) > > There are 2-level depth registers keeping the 4bytes that i explained > above. The last and the previous magnet-pass moments. > > Then in main loop, 1 calculate the speed by getting the distance between > two magnets and derivating it by the time difference between last two > magnet-pass times. The result is very stable. > > The main loop runs at 16hz. SoThere are two timing conditions. The CCP1 > frequency is greater than main loop frequency, or smaller than it. > > But i have two problems; > 1) when no new sample comes, the previous value (let it be 100kph) > remains for about 2 seconds (because the slowest speed is 0.5hz, i told > before)You know the time vs. speed relationship. So if you know that a hall event is overdue, you know that it's safe to decrease the speed to (distance) / (time since last reading). If your vehicle stops suddenly the reading will still be inaccurate, but at least it'll wind down to zero over a period of two seconds, instead of sitting at 'way fast' then blinking down to zero. The real solution to this is to have lots more lines on your encoder, but that may not be something you can affect.> 2) On high speeds, the display always toggles between 2 or 3 values. I > think you define this as ALIASING.You can define it as aliasing, but it's almost certainly not aliasing in the sense that it's used in sampled time systems. It's much more likely that it's a lack of timer resolution. You can only count an integer number of clocks, so when you're going slow with your 256Hz clock you're counting up to 512 pulses; one pulse difference is less than 0.2% error. Now consider what's happening when pulses are coming in at 225Hz: you're always getting either one pulse or two, so your speed will vary by nearly 50% from the correct value. Trying to calculate speed and then filter will give you all sorts of grief, because you're getting an unbiased estimate of time (the error between your integer value of time and real, continuous time is uniformly distributed), but when you take the reciprocal of time the error is no longer unbiased. So your best bet is probably to filter the time increment, and the best way that I can suggest to do that is to either keep a running average of the time increment. The longer you run the average the less 'bounce' you'll see, but the slower the response of your speedometer. You'll need to find a happy medium.> I just want to implement a filter to make the result MONOTONOUS and > ANTI-ALISED. I mean if the speed is increasing, it should increase or > stand still.You probably mean monotonic, unless by monotonous you mean unchanging.> I read a lot of application notes on filters but Im so confused now. > What kind of a filter i should use? > How can i implement it basically? > Could you please guide me to implement it? > > Thank you for reading ;)Good luck; I hope this makes sense. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●February 17, 20122012-02-17
>On Fri, 17 Feb 2012 08:38:42 -0600, atakan_1907 wrote: > >> Hi All, >> This is my first message on this board. >> >> I'm a newbie engineer and also new to filtering and dsp. >> >> My project is a simple speedometer using a PIC18 and a HALL SENSOR >> counting the magnets on the wheel. >> >> I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on >> every hall sensor input (falling edge), and CCP2 (special event trigger >> to reset TIMER3) which is a part of a precise time counterstructure.The>> HW is sth like that. >> >> /|\ >> | >> Z o| >> Z o| PIC >> |--o| CCP1 >> | o| >> \ >> | >> /// >> >> The input is between 0.5-225 Hz >> >> I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my >> another integer that counts TIMER3 overflows (actually CCP2 autoload >> interrupts) >> >> There are 2-level depth registers keeping the 4bytes that i explained >> above. The last and the previous magnet-pass moments. >> >> Then in main loop, 1 calculate the speed by getting the distancebetween>> two magnets and derivating it by the time difference between last two >> magnet-pass times. The result is very stable. >> >> The main loop runs at 16hz. SoThere are two timing conditions. The CCP1 >> frequency is greater than main loop frequency, or smaller than it. >> >> But i have two problems; >> 1) when no new sample comes, the previous value (let it be 100kph) >> remains for about 2 seconds (because the slowest speed is 0.5hz, i told >> before) > >You know the time vs. speed relationship. So if you know that a hall >event is overdue, you know that it's safe to decrease the speed to >(distance) / (time since last reading). If your vehicle stops suddenly >the reading will still be inaccurate, but at least it'll wind down to >zero over a period of two seconds, instead of sitting at 'way fast' then >blinking down to zero.if there is a new capture, calculate the time and insert in the moving average. But what if there is no new samples? I calculate the time passed from the last read, if its greater than the time between last two readings, i recalculate the speed according to (now) - (last time). Should i insert this to moving average?> >The real solution to this is to have lots more lines on your encoder, but>that may not be something you can affect. > >> 2) On high speeds, the display always toggles between 2 or 3 values. I >> think you define this as ALIASING. > >You can define it as aliasing, but it's almost certainly not aliasing in >the sense that it's used in sampled time systems. It's much more likely >that it's a lack of timer resolution. > >You can only count an integer number of clocks, so when you're going slow>with your 256Hz clock you're counting up to 512 pulses; one pulse >difference is less than 0.2% error. Now consider what's happening when >pulses are coming in at 225Hz: you're always getting either one pulse or >two, so your speed will vary by nearly 50% from the correct value.No, that's not true :) TIMER3 counts 48MHz/4 clock, and overflows exactly 256 times in a second. And in interrupts of overflow, i increase an 16bit counter. CCP1 interrupt captures 16bit TMR3 plus the other 16bit register that counts TMR3 overflow.> >Trying to calculate speed and then filter will give you all sorts of >grief, because you're getting an unbiased estimate of time (the error >between your integer value of time and real, continuous time is uniformly>distributed), but when you take the reciprocal of time the error is no >longer unbiased. So your best bet is probably to filter the time >increment, and the best way that I can suggest to do that is to either >keep a running average of the time increment. The longer you run the >average the less 'bounce' you'll see, but the slower the response of your>speedometer. You'll need to find a happy medium. > >> I just want to implement a filter to make the result MONOTONOUS and >> ANTI-ALISED. I mean if the speed is increasing, it should increase or >> stand still. > >You probably mean monotonic, unless by monotonous you mean unchanging. > >> I read a lot of application notes on filters but Im so confused now. >> What kind of a filter i should use? >> How can i implement it basically? >> Could you please guide me to implement it? >> >> Thank you for reading ;) > >Good luck; I hope this makes sense. > >-- >Tim Wescott >Control system and signal processing consulting >www.wescottdesign.com >Thank you for detailed answer!
Reply by ●February 17, 20122012-02-17
On 2/17/2012 6:38 AM, atakan_1907 wrote: I think Tim probably understands this better than I. Nonetheless, I'm going to ask some "dumb" questions in the hope that they may shed some light for you. As I understand the "system", there is a wheel with magnets on a circle. You can sense the passage of the magnets with the Hall devices. It appears those are connected directly to the PIC CCP pins. So, I guess the magnet waveform would be +,-,+ .. more or less (or -,+,-) and you sense the axis crossings if the time resolution is good enough. Something like that? I don't get your diagram.... I presume that "the input" is the output of the Hall device or.... ? But I don't understand the 0.5Hz lower limit. Where does that number come from? You have a main loop that works running at 16 Hz. So, at least that's a data point. You are sampling the magnet crossings. For the sake of clarity, I'm going to ignore all the cpu register and arithmetic stuff. I think it's best to stick with the physics for now .. well, more or less. So, you start a timer and capture timer differences between magnets to get speed. I know that the magnet-crossing frequency can be zero but I don't know what the magnet frequency maximum can be. I also don't know if you can capture all the magnet crossings reliably with the sampling method/frequency. Can you? Even at the highest frequency of magnet crossings? At high speeds I understand your implementation yields 2 or 3 speeds output that jump around between those 2 or 3 values. Is that right? I'm thinking doing it like this: 1) grab the counts between all the magnet crossings. Then, the speed estimate will be: constant: K=distance traveled per magnet arc. S = count * (counter frequency) = seconds between magnet crossings. Speed: K/S: distance/time. The comparator output presumably tells you the state of the magnet, right? So the sampling frequency here gives some temporal resolution and, thus, some temporal noise around the actual crossing times. Unless the sampling frequency is very high compared to your needed temporal resolution, this noise will be evident. So, that's just another way perhaps of some of what Tim told you. And he goes on to tell you what happens when you effectively use the reciprocal of this time measure. So, yes it appears that filtering a sequence of the counts would be a good idea. Maybe something as simple as a 2-point or 3-point sum would do. (Dividing by 2 or 3 for the average is just a scaling and you need to do scaling anyway so, as long as you account for it, you don't have to compute it .. so I say "sum"). You will certainly have aliasing if you miss magnet crossings. But I don't follow your description well enough to know if this is the case or not. The idea of running the speed down in the face of "late" magnet crossings is a good one. I guess it implies an algorithm something like: - wait until 1.xx times the last interval has past without a new crossing. - set the speed at (K/S)*(1/1.xx) where K/S is the last speed computed. - then do this again OR set the speed according to the next crossing. ... something like that. An approach like this will allow the indicated speed to decay to zero when it needs to. Nothing really different than what Tim said... It would be good to know directly: The maximum frequency of the magnet crossings. The sampling frequency of the magnet crossings. Fred> Hi All, > This is my first message on this board. > > I'm a newbie engineer and also new to filtering and dsp. > > My project is a simple speedometer using a PIC18 and a HALL SENSOR counting > the magnets on the wheel. > > I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on > every hall sensor input (falling edge), and CCP2 (special event trigger to > reset TIMER3) which is a part of a precise time counter structure.The HW is > sth like that. > > /|\ > | > Z o| > Z o| PIC > |--o| CCP1 > | o| > \ > | > /// > > The input is between 0.5-225 Hz > > I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my > another integer that counts TIMER3 overflows (actually CCP2 autoload > interrupts) > > There are 2-level depth registers keeping the 4bytes that i explained > above. The last and the previous magnet-pass moments. > > Then in main loop, 1 calculate the speed by getting the distance between > two magnets and derivating it by the time difference between last two > magnet-pass times. The result is very stable. > > The main loop runs at 16hz. SoThere are two timing conditions. The CCP1 > frequency is greater than main loop frequency, or smaller than it. > > But i have two problems; > 1) when no new sample comes, the previous value (let it be 100kph) remains > for about 2 seconds (because the slowest speed is 0.5hz, i told before) > > 2) On high speeds, the display always toggles between 2 or 3 values. I > think you define this as ALIASING. > > I just want to implement a filter to make the result MONOTONOUS and > ANTI-ALISED. I mean if the speed is increasing, it should increase or stand > still. > > I read a lot of application notes on filters but Im so confused now. > What kind of a filter i should use? > How can i implement it basically? > Could you please guide me to implement it? > > Thank you for reading ;) > >
Reply by ●February 17, 20122012-02-17
On Fri, 17 Feb 2012 11:23:55 -0600, atakan_1907 wrote:>>On Fri, 17 Feb 2012 08:38:42 -0600, atakan_1907 wrote: >> >>> Hi All, >>> This is my first message on this board. >>> >>> I'm a newbie engineer and also new to filtering and dsp. >>> >>> My project is a simple speedometer using a PIC18 and a HALL SENSOR >>> counting the magnets on the wheel. >>> >>> I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on >>> every hall sensor input (falling edge), and CCP2 (special event >>> trigger to reset TIMER3) which is a part of a precise time counter > structure.The >>> HW is sth like that. >>> >>> /|\ >>> | >>> Z o| >>> Z o| PIC >>> |--o| CCP1 >>> | o| >>> \ >>> | >>> /// >>> >>> The input is between 0.5-225 Hz >>> >>> I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my >>> another integer that counts TIMER3 overflows (actually CCP2 autoload >>> interrupts) >>> >>> There are 2-level depth registers keeping the 4bytes that i explained >>> above. The last and the previous magnet-pass moments. >>> >>> Then in main loop, 1 calculate the speed by getting the distance > between >>> two magnets and derivating it by the time difference between last two >>> magnet-pass times. The result is very stable. >>> >>> The main loop runs at 16hz. SoThere are two timing conditions. The >>> CCP1 frequency is greater than main loop frequency, or smaller than >>> it. >>> >>> But i have two problems; >>> 1) when no new sample comes, the previous value (let it be 100kph) >>> remains for about 2 seconds (because the slowest speed is 0.5hz, i >>> told before) >> >>You know the time vs. speed relationship. So if you know that a hall >>event is overdue, you know that it's safe to decrease the speed to >>(distance) / (time since last reading). If your vehicle stops suddenly >>the reading will still be inaccurate, but at least it'll wind down to >>zero over a period of two seconds, instead of sitting at 'way fast' then >>blinking down to zero. > > if there is a new capture, calculate the time and insert in the moving > average. But what if there is no new samples? I calculate the time > passed from the last read, if its greater than the time between last two > readings, i recalculate the speed according to (now) - (last time). > Should i insert this to moving average?Heh. I wrote my response before I had my morning tea, and my uncaffeinated brain missed a beat. Not quite. If it were a real reading, yes you could. The reason you could insert it into your moving average if it were real (and something that suggests a better way), is because you are taking the moving average of a bunch of first differences: mean(a) = (a_1 + a_2 + ... + a_n)/N, but a_n = b_n - b_{n-1} so a_1 + a_2 = b_0 - b_1 + b_1 - b_2 = b_0 - b_2, and in fact a_1 + a_2 + ... + a_n = b_0 - b_n. So instead of doing a moving average of your periods explicitly, you could just take your interval over a larger number of hall events, and if you time out on a reading (because your vehicle is moving slowly) then you could just start taking the current time to (temporarily) calculate speed, either until you time out completely and declare zero speed, or until a real reading comes in. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●February 17, 20122012-02-17
>On 2/17/2012 6:38 AM, atakan_1907 wrote: >I think Tim probably understands this better than I. Nonetheless, I'm >going to ask some "dumb" questions in the hope that they may shed some >light for you. > >As I understand the "system", there is a wheel with magnets on a circle. >You can sense the passage of the magnets with the Hall devices. It >appears those are connected directly to the PIC CCP pins. >So, I guess the magnet waveform would be +,-,+ .. more or less (or >-,+,-) and you sense the axis crossings if the time resolution is good >enough. Something like that? > >I don't get your diagram.... > >I presume that "the input" is the output of the Hall device or.... ? >But I don't understand the 0.5Hz lower limit. Where does that number >come from?I just told you the system basically, inner work; hall sensor voltage matches to pic etc... And no problem, you've understood right. Of course the speed can be 0hz but we cant wait till next year right :) So, I assume the frequencies smaller than 0.5 as 0Hz.> >You have a main loop that works running at 16 Hz. So, at least that's a >data point. > >You are sampling the magnet crossings. > >For the sake of clarity, I'm going to ignore all the cpu register and >arithmetic stuff. I think it's best to stick with the physics for now >.. well, more or less. > >So, you start a timer and capture timer differences between magnets to >get speed. >I know that the magnet-crossing frequency can be zero but I don't know >what the magnet frequency maximum can be. >I also don't know if you can capture all the magnet crossings reliably >with the sampling method/frequency. Can you? Even at the highest >frequency of magnet crossings?This is a car and I'll place a maximum of 6 magnets onto the wheel. And top speed is .... bla bla ... the maximum freq has no way to be greater than 200-225 Hz.> >At high speeds I understand your implementation yields 2 or 3 speeds >output that jump around between those 2 or 3 values. Is that right?This jumping is not from timer inaccuracy or missing magnet crossings. It comes from, naturally, a non-ideal system, non-ideal magnet placement, imperfect constant speed, like a MECHANICAL NOISE ;) But it's still annoying. Also, the vehicle cant rocketed, and has a maximum acceleration. So, a little slow response is not a problem.> >I'm thinking doing it like this: > >1) grab the counts between all the magnet crossings. Then, the speed >estimate will be: > >constant: K=distance traveled per magnet arc. > >S = count * (counter frequency) = seconds between magnet crossings. > >Speed: K/S: distance/time. > >The comparator output presumably tells you the state of the magnet, >right? So the sampling frequency here gives some temporal resolution >and, thus, some temporal noise around the actual crossing times. Unless >the sampling frequency is very high compared to your needed temporal >resolution, this noise will be evident. >So, that's just another way perhaps of some of what Tim told you. >And he goes on to tell you what happens when you effectively use the >reciprocal of this time measure. > >So, yes it appears that filtering a sequence of the counts would be a >good idea. Maybe something as simple as a 2-point or 3-point sum would >do. (Dividing by 2 or 3 for the average is just a scaling and you need >to do scaling anyway so, as long as you account for it, you don't have >to compute it .. so I say "sum"). > >You will certainly have aliasing if you miss magnet crossings. But I >don't follow your description well enough to know if this is the case or >not.No missed crossings.> >The idea of running the speed down in the face of "late" magnet >crossings is a good one. I guess it implies an algorithm something like: > >- wait until 1.xx times the last interval has past without a newcrossing.>- set the speed at (K/S)*(1/1.xx) where K/S is the last speed computed. >- then do this again OR set the speed according to the next crossing. >... something like that. > >An approach like this will allow the indicated speed to decay to zero >when it needs to. > >Nothing really different than what Tim said... > >It would be good to know directly: >The maximum frequency of the magnet crossings. >The sampling frequency of the magnet crossings. > >FredFor clearence, i should better to tell again. 1)PIC runs @48MHz -> TIMER3 (up) counts Fosc/4=12MHz. It have a 16bit register. 2)CCP2 runs in COMPARE mode, and compares a value with TIMER3 registers. Consider that happens on 1/256 seconds often. If a match occurs, it resets TIMER3 to zero and triggers an interrupt. In the ISR, i increment another 16bit register manually. That implements a 4byte counter. Lower word is TIMER3 and higher word is my manually incremented word. 3)CCP1 listens the HALL device, on a falling-edge, samples TIMER3 and triggers an interrupt. In that ISR, i save the sampled TIMER3 word and my MANUAL COUNTER word to somewhere. So the sampling frequency is 12MHz. I keep the last and the prev. value. 2 samples to determine the time difference between them. 4)Using the time base TIMER3 created, main() loops 16 times per second. And the calculations done here. 16 calc/s 5)Magnet crossing freq range is 0-225Hz. But i assume a minimum of 0.5Hz, and ignore the freq. below. Thank you.
Reply by ●February 17, 20122012-02-17
On 2/17/2012 7:38 AM, atakan_1907 wrote:> My project is a simple speedometer using a PIC18 and a HALL SENSOR counting > the magnets on the wheel. > > I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on > every hall sensor input (falling edge), and CCP2 (special event trigger to > reset TIMER3) which is a part of a precise time counter structure.The HW is > sth like that. > > /|\ > | > Z o| > Z o| PIC > |--o| CCP1 > | o| > \ > | > /// > > The input is between 0.5-225 Hz > > I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my > another integer that counts TIMER3 overflows (actually CCP2 autoload > interrupts)So, CCP1 marks *when* the event occurs and CCP2 just reloads the timer (3). The *hardware* captures the value of the timer (so interrupt latency is not a factor in the "accuracy" of that datum). Presumably, you have considered the case where the CCP2 interrupt coincides with the sensor event? I.e., you need to *harvest* the captured timer value AND the state of the "overflow counter" as it existed WHEN THE SENSOR EVENT OCCURRED. (consider carefully whether or not an overflow can appear to occur BEFORE the sensor event when, in fact, it has occured AFTER. This would probably manifest as a datum that was "significantly different" from the temporally adjacent events. It would indicate a bug in your implementation)> There are 2-level depth registers keeping the 4bytes that i explained > above. The last and the previous magnet-pass moments. > > Then in main loop, 1 calculate the speed by getting the distance between > two magnets and derivating it by the time difference between last two > magnet-pass times. The result is very stable.If that is, in fact, the case, then you are NOT seeing these anomalies.> The main loop runs at 16hz. SoThere are two timing conditions. The CCP1 > frequency is greater than main loop frequency, or smaller than it. > > But i have two problems; > 1) when no new sample comes, the previous value (let it be 100kph) remains > for about 2 seconds (because the slowest speed is 0.5hz, i told before)If you are, in fact, operating at that 0.5Hz rate, then this would be what you would *expect*. You are just sampling faster than your event rate.> 2) On high speeds, the display always toggles between 2 or 3 values. I > think you define this as ALIASING.Have you looked at those *actual* two values? And, the data (time differences) associated with them? Do they differ by the resolution of your system? Or, by something a lot larger (like the overflow counter issue I mentioned previously)? Recall that you are measuring a continuous time signal in a discrete time *system*. So, something that is happening at 3.7 "time units" will, sometimes, appear to be happening at 3 units and other times at 4 units. This is just a consequence of discrete time systems. At higher speeds, the difference of one "time unit" appears to be more significant because it is an inverse relationship: speed = K / TimeDifference I.e., as speed goes up, TimeDifference goes down. So a small *difference* in TimeDifference (unfortunate coincidence of terms) translates to a much more apparent change in speed. E.g., K/4 vs. K/3 (using the above "3.7" ACTUAL number) looks like a ~30% speed change -- INSTANTANEOUSLY.> I just want to implement a filter to make the result MONOTONOUS and > ANTI-ALISED. I mean if the speed is increasing, it should increase or stand > still.It will never stand still because there are continuous time conditions that can't be sampled as if they were "unchanging" (see above). How you want to *present* that information depends on the importance of the actual characteristics of the measured value. I.e., alternating between K/3 and K/4 is different than STAYING at K/3 or K/4. If you want to be able to display K/3.7 numerically, then you have to average multiple readings. This makes your display more sluggish (overdamped). And, all it does is kick the can down the road: will you now hunt between 3.695 and 3.705, etc.?> I read a lot of application notes on filters but Im so confused now. > What kind of a filter i should use? > How can i implement it basically? > Could you please guide me to implement it?You have to decide what you want the characteristics of that filter to be -- short and long term. That will depend on how you intend to *use* the information (it factors into the response characteristics of that system). E.g., the speedometer in your automobile works essentially the same way. But, you (the driver) tend not to drive solely by watching the reported speed -- you have other sensory input that gives you more frequent updates. So, if you slam on the brakes, the speedometer may take a sizable fraction of a second to ACCURATELY report your new speed ("stopped"). But, your BODY knows it instantly because of inertial forces and "Hey, the trees aren't 'moving' as quickly, now!". Your "speed reporting algorithm" will (probably) represent the ONLY means of conveying that information to <whatever>. So, think of how you want that <whatever> to handle this "distorted" view of reality.
Reply by ●February 17, 20122012-02-17
>Heh. I wrote my response before I had my morning tea, and my >uncaffeinated brain missed a beat. > >Not quite. If it were a real reading, yes you could. The reason you >could insert it into your moving average if it were real (and something >that suggests a better way), is because you are taking the moving average>of a bunch of first differences: > >mean(a) = (a_1 + a_2 + ... + a_n)/N, > >but a_n = b_n - b_{n-1} > >so a_1 + a_2 = b_0 - b_1 + b_1 - b_2 = b_0 - b_2, and in fact >a_1 + a_2 + ... + a_n = b_0 - b_n. > >So instead of doing a moving average of your periods explicitly, you >could just take your interval over a larger number of hall events, and if>you time out on a reading (because your vehicle is moving slowly) then >you could just start taking the current time to (temporarily) calculate >speed, either until you time out completely and declare zero speed, or >until a real reading comes in. > >-- >My liberal friends think I'm a conservative kook. >My conservative friends think I'm a liberal kook. >Why am I not happy that they have found common ground? > >Tim Wescott, Communications, Control, Circuits & Software >http://www.wescottdesign.com >Yes, that's a good way. It can easily be implemented. Further, i want to give an example; Let the magnet periods be: [10]........[10][11][13][12][14][12]... The results are: |----10--------| |---10.25------| |----11--------| |----11.5------| |----12.5------| |---12.75------| Does it work at low frequencies too?
Reply by ●February 17, 20122012-02-17
>On 2/17/2012 7:38 AM, atakan_1907 wrote: > >> My project is a simple speedometer using a PIC18 and a HALL SENSORcounting>> the magnets on the wheel. >> >> I used CCP1 as CAPTURE and CCP2 as COMPARATOR. CCP1 captures TIMER3 on >> every hall sensor input (falling edge), and CCP2 (special event triggerto>> reset TIMER3) which is a part of a precise time counter structure.The HWis>> sth like that. >> >> /|\ >> | >> Z o| >> Z o| PIC >> |--o| CCP1 >> | o| >> \ >> | >> /// >> >> The input is between 0.5-225 Hz >> >> I'm using CCP1 interrupt to move captured TMR3 (1/256s period) and my >> another integer that counts TIMER3 overflows (actually CCP2 autoload >> interrupts) > >So, CCP1 marks *when* the event occurs and CCP2 just reloads the >timer (3). > >The *hardware* captures the value of the timer (so interrupt latency >is not a factor in the "accuracy" of that datum). Presumably, you >have considered the case where the CCP2 interrupt coincides with the >sensor event? > >I.e., you need to *harvest* the captured timer value AND the state of >the "overflow counter" as it existed WHEN THE SENSOR EVENT OCCURRED. >(consider carefully whether or not an overflow can appear to occur >BEFORE the sensor event when, in fact, it has occured AFTER. This >would probably manifest as a datum that was "significantly different" >from the temporally adjacent events. It would indicate a bug in your >implementation)Actually i take advantage of interrupt priorities in PIC18. Time-keeper ISR has high, speedo ISR has low priority. When the instuction flow enters the speedo ISR, i save counting-registers and check TMR3H again, to know if it had an overflow. In main loop, I sample one of the counter bytes before start to the speed calc process. I calc it to a temporary register, then compare the sampled byte to the actual one. If they meet, i move the temporary speed to the real one. If not, the previous value remains.> >> There are 2-level depth registers keeping the 4bytes that i explained >> above. The last and the previous magnet-pass moments. >> >> Then in main loop, 1 calculate the speed by getting the distancebetween>> two magnets and derivating it by the time difference between last two >> magnet-pass times. The result is very stable. > >If that is, in fact, the case, then you are NOT seeing these anomalies. > >> The main loop runs at 16hz. SoThere are two timing conditions. The CCP1 >> frequency is greater than main loop frequency, or smaller than it. >> >> But i have two problems; >> 1) when no new sample comes, the previous value (let it be 100kph)remains>> for about 2 seconds (because the slowest speed is 0.5hz, i told before) > >If you are, in fact, operating at that 0.5Hz rate, then this would >be what you would *expect*. You are just sampling faster than your >event rate. > >> 2) On high speeds, the display always toggles between 2 or 3 values. I >> think you define this as ALIASING. > >Have you looked at those *actual* two values? And, the data (time >differences) associated with them? Do they differ by the resolution >of your system? Or, by something a lot larger (like the overflow >counter issue I mentioned previously)?As i explained above, it's not an "ideal-frequency". It has some non-idealities, mostly mechanics. Lets call it mechanical noise ;)> >Recall that you are measuring a continuous time signal in a discrete >time *system*. So, something that is happening at 3.7 "time units" >will, sometimes, appear to be happening at 3 units and other times at >4 units. This is just a consequence of discrete time systems.Because of operating fast enough, that issue doesnt affect too much. TIMER3 runs @12MHz, altought the wheel (magnets) runs at only a maximum of 225Hz. The jitter or aliasing (what you name it) is mostly comes from mechanical sources. When i simulate on ISIS with a 200Hz or 20Hz freq source, there is no jitter. Maybe just 1 least significant digit. (1/10)> >At higher speeds, the difference of one "time unit" appears to be more >significant because it is an inverse relationship: > >speed = K / TimeDifference > >I.e., as speed goes up, TimeDifference goes down. So a small >*difference* in TimeDifference (unfortunate coincidence of terms) >translates to a much more apparent change in speed. > >E.g., K/4 vs. K/3 (using the above "3.7" ACTUAL number) looks >like a ~30% speed change -- INSTANTANEOUSLY. > >> I just want to implement a filter to make the result MONOTONOUS and >> ANTI-ALISED. I mean if the speed is increasing, it should increase orstand>> still. > >It will never stand still because there are continuous time conditions >that can't be sampled as if they were "unchanging" (see above). > >How you want to *present* that information depends on the importance of >the actual characteristics of the measured value. I.e., alternating >between K/3 and K/4 is different than STAYING at K/3 or K/4. > >If you want to be able to display K/3.7 numerically, then you have to >average multiple readings. This makes your display more sluggish >(overdamped). And, all it does is kick the can down the road: >will you now hunt between 3.695 and 3.705, etc.?No :) I just make it as monotonic as a bike or a car speedo. As a professional one. I know that a car speedo has much more pulses per revolution. Lets think a bike speedometer ;)> >> I read a lot of application notes on filters but Im so confused now. >> What kind of a filter i should use? >> How can i implement it basically? >> Could you please guide me to implement it? > >You have to decide what you want the characteristics of that filter >to be -- short and long term. That will depend on how you intend >to *use* the information (it factors into the response characteristics >of that system). > >E.g., the speedometer in your automobile works essentially the same way. >But, you (the driver) tend not to drive solely by watching the reported >speed -- you have other sensory input that gives you more frequent >updates. So, if you slam on the brakes, the speedometer may take a >sizable fraction of a second to ACCURATELY report your new speed >("stopped"). But, your BODY knows it instantly because of inertial >forces and "Hey, the trees aren't 'moving' as quickly, now!". > >Your "speed reporting algorithm" will (probably) represent the ONLY >means of conveying that information to <whatever>. So, think of >how you want that <whatever> to handle this "distorted" view of >reality. >
Reply by ●February 17, 20122012-02-17
atakan_1907 <atakan.sarioglu@n_o_s_p_a_m.gmail.com> wrote: (snip)> I just told you the system basically, inner work; hall sensor voltage > matches to pic etc... > And no problem, you've understood right.(snip)> This is a car and I'll place a maximum of 6 magnets onto the wheel. > And top speed is .... bla bla ... the maximum freq has no way > to be greater than 200-225 Hz.Another way is with an analog PLL frequency multiplier. I remember some years ago (TTL days) of a design for a digital tachometer. While you can add more magnets, a tachometer, at least traditionally, measures the ignition spark pulses. For a V8 (more common then) you get four pulses per revolution, so you would have to count 15 seconds to get RPM. Too long. So they used a PLL frequency multiplier to get the frequency high enough to count in a reasonable period. If you multiply by 10, (7490 in the feedback loop), only 1.5 seconds. That gets you down to the analog filter in the PLL, instead of digital filters that are the subject of this group. -- glen
