Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

N_743

Member

05-17-2022 04:23 PM - edited 05-17-2022 05:07 PM

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi!

I have an incremental encoder that outputs Sine waves that rides on a voltage level. (Sine, Cosine, Sine*, Cosine*). Aim is to take measurements on its peak values (show overall amplitude) and show only the EDIT: ~~ peak~~ amplitude values on the UI and is preferred to do it (calculations) on FPGA side. I have a VI built in parts, delivers exactly what I need but only when I have these encoders turned by hand. Challenge is when I am trying to read voltage values when this encoder is connected to a motor and that motor is being run by a drive. This induces a lot of noise and random spikes throws off the peak voltage reading. To resolve this, I have a cut off value (for peak and valleys) that helps fixing the values.But it only would work with one particular type of motor, if the motor is changed, it may have more noise or no noise and cut off value would have to be adjusted and it may or may not give expected result.

I would really appreciate if someone has any suggestion for me to better capture values. My hope is to come up with a way to somehow auto correct peak/amplitude values after a spike has passed or ignore spike. I have attached VI that I am using (it is a part of main FPGA VI) and an image of on-screen scope showing noise on the sine wave . (Spike could be on the peak or on the valley of the sine wave). Edit: I am sure it can be done in a simpler way.

Additional information: Edit: (Just in case)

1) Frequency of sinewave is not fixed

2) Encoder I deal with varies from 128-4096 PPR (but this has not hurt with calculations so far but just in-case someone wants to know)

3) It is preferred to do these calculations on FPGA, since making these calculation on PC side is a bit challenging due to architecture in place since this is a small but Edit: has become an essential part of the entire project. But if that is the only way, I can look into making changes.

EDIT: I think the file was not attached. (Attached after edit)

Thank you for your time.

-N

Solved! Go to Solution.

Bob_Schor

Knight of NI

05-17-2022 09:32 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Have you ever had a course in Signal Theory? Do you know how Digital Sampling of signals works? Do you know about Fourier Analysis (to find "signals amidst noise"?

Not clear why you need to use FPGA.

Bob Schor

05-18-2022 09:17 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi Bob,

Thank you for responding,

No, I have not taken a course in Signal Theory. I do not really know how Digital Sampling of signals work (may be a little bit but not enough to put it into good words). I am aware of Fourier Analysis. I did try out some of the available signal processing VIs after reading about most of them. Had a little success but not to the point where my custom VI has got me to. (Which I very well know is not the right way to do it).

FGPA is preferred, not absolute necessity. Signal analysis was never really our main requirement, until recently. I did not sign up for this but I am asked to do it. Since I do not know much and do not want to do the wrong thing and am a solo guy, I am reaching out for help.

I will read about the topics you mentioned in your questions. Thank you.

-N

Bob_Schor

Knight of NI

05-18-2022 10:11 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Where are you getting your data? Are you doing the Data Acquisition yourself (DAQmx or something with an "Acquisition Box" that delivers you data samples)? What is the format of the data? I'm assuming you are sampling N "Channels" (N is typically 1 to a few, maybe 16), at what data rate (typically samples are taken "regularly" at some fixed rate, from 100 samples/sec, or Hz, to 10 kHz or higher), and how many points are taken at a time (a typical number would be 1000, so if you are sampling at 1 kHz, then every second, you get another 1000 samples from the, say, 8 Channels you are sampling).

Signal Theory tells you that you need to sample at least twice as fast (and probably 10-100 times faster) than the highest "frequency of interest". If your signal really is, say, a sinusoid of, say, 100 Hz, then 1 second of samples at 1 kHz should, if displayed, show you 10 periods of a sinusoid plus some "noise". Fitting a 100 Hz sinusoid using standard Least-Squares techniques will enable you to estimate the amplitude of the sinusoid that best fits the data. But what if the frequency is "around 100 Hz"? That's where Fourier Analysis comes in -- you basically fit 1 Hz, 2 Hz, 3 Hz, ..., 500 Hz sinusoids and see which one gives you the best "signal-to-noise" (i.e. "fits the data" best), and say "Oh, the frequency seems to be around 102 Hz with an amplitude of X and a phase of Y".

Bob Schor

05-19-2022 09:08 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Thank you for responding to my basic questions Bob and sharing knowledge. Sorry for the delayed response.

-I am getting data first on the FPGA, signals are directly connected analog input port on the sbRIO-9638.

-Analog input IO node is set to calibrated values for it gives out actual voltage values in FXP format. Later this data is sent to RT and then PC, using FIFO and Network Streams, respectively.

-Only 1 channel is sampled at a time.

-I am taking ~6666 samples per second.

Signal Theory tells you that you need to sample at least twice as fast (and probably 10-100 times faster) than the highest "frequency of interest".

Oh yes! I have read this. Since this sine wave does not have fixed frequency, frequency and period on this sine wave depends upon how fast the encoder shaft is turned. There is a set condition to turn encoder at slow speed but consistency is not assured. At stand still of encoder shaft, you will see a constant voltage level. I have attached images to better describe it.

I also attempted to implement FFT (limited samples- 300) analysis but I am not sure if I approached it correctly and not sure what to determine from the output data.

Solution

Accepted by N_743

Bob_Schor

Knight of NI

05-20-2022 03:50 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

OK, this is very helpful -- paradoxically (because I tend to yell a lot on the Forums about not submitting "pictures of code"), the "pictures of your data" are very helpful! Unfortunately, they point to a potential difficulty in getting a "clean answer".

Here's the root of the problem -- analyzing a time-varying signal using Frequency Analysis tools (sometimes called Fourier Analysis) makes a (weak) assumption that the "signal" is __periodic__ and can be described as a combination of sinusoids having discrete frequencies, each frequency having a Gain (amplitude) and Phase (which can be related to where the peak of the sine wave occurs) + uncorrelated "noise" (whose influence you hope to minimize by fitting pure sinusoids to the signal, then reading off the Gains and Phases).

In your case, you have a relatively noise-free (good!), time-varying (oops, bad!) signal. All is not lost, but you need to be a bit more clever in describing the signal. One step up from conventional Fourier Analysis (where you have a signal without time-varying gain and phase, for example, the response of a system when stimulated with a pure sinusoid) is Time-Frequency Analysis, where you have an explicitly time-varying signal. An example is Speech Analysis, which involve "Spectrogram", a 3-D plot of frequency (Y Axis) as a function of Time (X Axis), with the relative __amplitude__ of the Frequency expressed on the Z axis (or as a Color of the points on the conventional X-Y graph). I've done a little of this, but am definitely __not__ an expert (I helped a colleague visualize some Animal Calls for an instrument he was trying to design to study these calls -- we needed to see what frequencies were involved, and how rapidly they change during a Call).

In your case, there is a "Brute-Force" method that might give some useful insights. Your pictures show pretty clean data, with few noise "blips" and more-or-less constant amplitude of the sinusoid. You could "walk along the data", looking for the peaks -- the (time-)difference between the peaks is 1/(frequency) of that (distorted) sinusoid. The Bad News is estimating the time of the Peak is tricky, because the Sinusoid is more-or-less constant at the peak, so a little bit of noise will have a large(r) effect. But you can get an estimate of the __peak height__, and can similarly get an estimate of the "valley depth" (the place of the minimum) -- from these two heights, you can estimate the "mean" value, and now look for where the sinusoid crosses the mean. The reason for this effort is the sinusoid has its maximum slope when it crosses its mean, so you get the most accurate estimate.

I'm doing a little "hand-waving" here, as this isn't something I've actually tried to do, and it is outside my usual experience with Signal Analysis. It also has the "feature" of returning "results" at times that are determined by the __data__ (i.e. you get an estimate of frequency at every zero-crossing, which in your frequency-changing data, are, themselves, time-varying). However, it __is__ an estimate of frequency, and you __can__ plot this estimate vs the time you took the estimate -- it just won't have points equally spaced in time, but rather spaced depending on the frequency (which you are trying to measure) at that point in time.

Wow, I'm not sure even I can be sure I understand what I just said! Let me know if this makes sense to you.

So here's a final question -- were the data you showed "typical", i.e. do you really have nice sinusoids that have a more-or-less fixed amplitude, fixed DC offset, and (relatively-slowly-varying) frequency, which you are sampling at a __fixed__ frequency that is at least 10 times faster than the highest frequency you expect in your sinusoid? If so, could you collect and attach a data sample of "reasonable" size (it might require several thousands of points), and tell me/us the frequency at which you are acquiring the data? I'm pretty sure I can whip up an algorithm based on my hand-waving a few paragraphs back, and my colleagues here on the Forums have probably already done this and may even have better ideas.

Bob Schor

JÞB

Knight of NI

05-21-2022 08:28 AM - edited 05-21-2022 08:52 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Excellent BS!

I'll chime in with some pointers and leave the application of theory for the student as exercise . The signal appears noise free but a low pass filter will help.

- Integrate the signal OR subtract mean to remove any DC offset. (We really don't care about any 90 deg constant phase offset) Call it Y[]
- Create an array of points<X,Y>[] where X0...n = dt*0...n
- pass it through Cartesian to Polar and we can ignore rho

What is left is an array of Theta or phase angle and we already know dt between each sample so ..... instantaneous frequency is (theta(n)-theta(n-1))/dt*360 assuming theta is in degrees and I worked the units right with no paper or pen.

You'll have to do a bit of phase unwrapping at 360 degrees but that's trivial.

EDIT BONUS: Then remove the filter and duplicate the output. Send that over to your mechanical engineers and have them figure out why your drive shift is unbalanced (it looks like driving on a tire that wasn't mounted right~~~~•~)

"Should be" isn't "Is" -Jay

05-21-2022 12:46 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi Bob,

Thanks again for the response.

@Bob_Schor wrote:

OK, this is very helpful -- paradoxically (because I tend to yell a lot on the Forums about not submitting "pictures of code"), the "pictures of your data" are very helpful! Unfortunately, they point to a potential difficulty in getting a "clean answer".

My apologies I forgot to do:

I am attaching another VI with ~557,039 data points.

I'm doing a little "hand-waving" here, as this isn't something I've actually tried to do, and it is outside my usual experience with Signal Analysis. It also has the "feature" of returning "results" at times that are determined by thedata(i.e. you get an estimate of frequency at every zero-crossing, which in your frequency-changing data, are, themselves, time-varying). However, itisan estimate of frequency, and youcanplot this estimate vs the time you took the estimate -- it just won't have points equally spaced in time, but rather spaced depending on the frequency (which you are trying to measure) at that point in time.

Wow, I'm not sure even I can be sure I understand what I just said! Let me know if this makes sense to you.

Its written well enough to visualize what you are trying to say without requiring any external substance.

So here's a final question -- were the data you showed "typical", i.e. do you really have nice sinusoids that have a more-or-less fixed amplitude, fixed DC offset, and (relatively-slowly-varying) frequency, which you are sampling at a

fixedfrequency that is at least 10 times faster than the highest frequency you expect in your sinusoid?

-No, it is not typical, data I showed earlier is of just one instance, one particular type of encoder, one specific motor running by a drive in certain settings.

-Sinusoid are nice only when encoder is disconnected from the motor. (Attached VI has data that will better explain my concerns with the noise)

-No, they do not have fixed dc offset. I am calculating mean value on the fly by measuring peak and valley voltage levels and taking a mean of them. Intent was to make this part flexible and auto calculate mean value, DC offset.

-Per my knowledge, frequency of these sine waves will directly be proportional to the speed of encoder shaft/ motor. Some times encoder could be sitting at standstill and at that point there will be just a constant voltage value coming out.

-My acquisition loop on fpga is fixed to 6000 ticks (Loop Timer) at 40 Mhz (25ns) FPGA CLK. Which should result into 6666hz and sine wave coming in will be around ~341hz (highest frequency) at 10 RPM. This would result into sampling rate ~X19 times the maximum expected frequency.

Please let me know if I should provide any more information.

Also, I attempted to do something like a low pass filter that you will see in the VI and it gives fairly close result but it does not help when trying to show real time data on UI. As actual (true) value takes some time to update.

05-21-2022 01:32 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi JPB,

Thank you for joining this post.

The signal appears noise free but a low pass filter will help.

Please look at the latest VI attached that has more noisy data in it. Low pass filter does help in most scenarios.

- Integrate the signal OR subtract mean to remove any DC offset. (We really don't care about any 90 deg constant phase offset) Call it Y[]
- Create an array of points<X,Y>[] where X0...n = dt*0...n
- pass it through Cartesian to Polar and we can ignore rho
What is left is an array of Theta or phase angle and we already know dt between each sample so ..... instantaneous frequency is (theta(n)-theta(n-1))/dt*360 assuming theta is in degrees and I worked the units right with no paper or pen.

You'll have to do a bit of phase unwrapping at 360 degrees but that's trivial.

I will try and implement this share the findings. Just one small problem, DC offset/ mean is supposed to be calculated on the fly and is not fixed/ pre-defined . This is supposed to auto adjust based on input signal. But I can do something about it, may be pre-define it.

EDIT BONUS: Then remove the filter and duplicate the output. Send that over to your mechanical engineers and have them figure out why your drive shift is unbalanced (it looks like driving on a tire that wasn't mounted right~~~~•~)

Yes! Yes! Yes! thank you for saying that. There are several things that are wrong and needs to be fixed but ignorance is biggest issue in this situation hehe.

JÞB

Knight of NI

05-21-2022 04:56 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

DC offset. Use the integration of the signal and the offset poofs away but introduces a constant phase shift. Int of sin(x) = cos(x)

Since we want only the pt to pt change in phase to calculate instantaneous frequency that constant shift subtracts out.

"Should be" isn't "Is" -Jay