Electronics > Beginners
automated noise check for gearbox continued
<< < (4/4)
gildasd:
I use a version of this at work.

https://www.spminstrument.com/Products/Portable-instruments/Electronic-Stethoscope/

Ours in integrated into a vibration checker (needs bearing data to determine if it within specs under load) but that is probably way overkill for your usage.

I would suggest using a contact probe microphone like this as they are usable even is very noisy environments.
engineheat:

--- Quote from: Ian.M on February 13, 2019, 07:40:51 pm ---That would be reasonable idea from the point of view of doing the signal analysis, high level control and logging, but the Pi doesn't have any ADC inputs ant it isn't great at realtime control (see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspberryPi ).  Add a USB soundcard for the signal capture, and an external smart controller for the steppers and to monitor the limit and home sensors for each axis and it would be viable.  I would recommend logging to USB stick, not to its own on-board SD card, as the more you write to it the more likely it is to go bad, and as it holds the OS and your user application,  its a PITA to recover from a corrupted card.

--- End quote ---

I will use a USB sound card. Can you please provide a link to an example of a home sensor and smart controller so I can learn more about them?

thanks
rhb:
I'm sorry to say this, but you are highly unlikely to succeed in your efforts which is a great disappointment to me.  I found it an interesting problem.

In the previous thread you imposed extreme limits upon the amount of time allowed for a test.  Now you are compounding it by demanding that the data collection period be even shorter.  And making the solution more complex and more expensive.

You are not an experienced digital signal processor.  You do not know how to analyze and process the data.  Despite repeated requests that you post some data you have not.

It is routine in reflection seismic processing to take data which is so noisy that the raw recordings look as if they are pure noise and produce beautiful, crisp images.  That is the job function of a seismic processor, dealing with the noise.  The rest of it can be done by a high school dropout.  But the noise suppression cannot.

The noise reduction requires understanding the noise characteristics and the signal characteristics and then  selecting from a very wide range of noise suppression techniques  a data space where the noise and the data are separable.   The noise is not a homogeneous entity.  "Noise" is the name given to all the things which are not information that is wanted.  There's an old saying in seismology, "That's not noise, it's signal we don't know what to do with."  Over the course of many years I have seen a wide variety of "noise" transformed into additional data that a simpler model does not describe.

A number of years ago when I still did Seismic Unix support a grad student at Scripps posted a query to the mailing list.  He had some very poorly acquired academic data over a seamount in the Pacific.  The "birds", which are movable wings mounted to the streamer containing the hydrophones and which maintain the streamer at the desired depth, were either broken or not being operated properly.

This condition  led to what is called "cable strum".   The birds are behaving as if they were picks plucking a string very rapidly.  This leads to  waves which travel up and down the cable and reflect off the ends.

Hydrophones are accelerometers, just as are contact piezoelectric microphones.  So the problem was that he was trying to detect motions of a millionth of an inch on a cable which was moving several inches due to the strum.  His data was extremely bad.  No oil company would have accepted it, but academic research vessels are mostly crewed by graduate students.  There is no budget for a reshoot, so "what you see is what you get".

Seismic Unix is a large body of code ranging from brilliant to awful.  Most of it has been written by scientists and students who do not now how to program.  So it's a pretty ornery beast.  Lot's of things don't work as they should.  For the student this was all new territory whereas I had been using and fixing bugs in SU for many years.

I thought I could do it in an afternoon, so I got a data sample and put together a work flow showing how you handle the problem.  Because the program that performed the particular filtering operation needed did *not* work the way the documentation stated it wound up taking me 4 days rather than 4 hours.  But I put together a basic workflow for him showing how to suppress the noise. What I gave him was not a solution.  It was a cartoon, a pebble tossed in the general direction of the solution.  After he understood how to suppress the strum there were many more operations needed.   And in addition  I provided him with some simple examples of how to produce an image from his data.

IIRC it took him a couple of months, but he sent me an image that knocked my socks off.  It was substantially better than what I thought could be achieved from looking at the data.  And this was a side job, not his dissertation project.  But he clearly put a huge amount of effort into experimenting with parameter choices until he found the right ones.   He later sent me images from his dissertation project which were as good as any I have ever seen produced with single streamer data and much better than a lot of commercial processing of similar data I've seen.

In summary, unless you provide pictures of the line and data, no one can tell what can or cannot be done.  Anything anyone says is just guessing based upon the description of an elephant by the four blind men.

One of the applications of sparse L1 pursuits which I have mentioned previously is called "blind source separation".  In a nut shell this consists of taking a handful of microphones scattered randomly around a room and then picking out any individual speaker anywhere in the room during a crowded cocktail party.

What you want do do can be done.  But you have to know how.  You don't.  Nor does anyone else on this list that I have encountered. If there were, my posts about sparse L1 pursuits would have gotten a response.  I do now how.  That has been the primary focus of my life for 37 years.
engineheat:

--- Quote from: Ian.M on February 12, 2019, 03:00:36 pm ---Home sensing is essential, as the stepper motors aren't absolute positioners. 

--- End quote ---

I decided to use Nema 17 for the XY gantry, found a kit that I can buy for $200. Speaking of stepper motors, there's this:
https://www.applied-motion.com/products/series/str-stepper-drives?

and there's this:
https://www.pololu.com/product/1182

The first one is obviously higher quality and more robust and expensive. But aside from the obvious, what else set them apart?

Thanks
JuanGg:
Just skimmed over the thread.
I recommend you make a list of requirements, drawings, block diagrams etc.
Upon designing the gantry, take into account sizes, forces and speeds involved. Knowing that, you can decide on the linear slides and stepper motors to use. For your application, ground rods and linear bearings, using belts and NEMA17 steppers would do.
Take a look at CNC software, such as grbl. That will take coordinates via a serial port and handle all homing, positioning and acceleration.
(Although for something this simple, just moving over a fixed grid, you could very well code it yourself from scratch).You can often purchase ready-made CNC kits with steppers and stepper drivers. And I can't emphasize drawing a diagram enough.
Just my two cents.
    Juan
Navigation
Message Index
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod