Ben Bradley wrote:> Eeyore <rabbitsfriendsandrelations@notmail.com> wrote: > >Eeyore wrote: > >> Jon Kirwan wrote: > >> > >> > (3) On what time scale do these events occur? > >> > >> For example when lights are switched. So the frequency of occurence could > >> be anything. > > > >Just remembered that the air extractor in the 'loo' caused an audible transient too. That was fixed by >replacement with another > model ( reason for the difference not known ). > > Do you still have the old one?Yes, it's been retained.> Will it make the same or similar electrical noise if you just plug it in or unplug it from an outlet?Unknown at this time as another guy was working on the mains wiring.> If not can you hook it back up to that same circuit and reproduce the > problem? I'm thinking you really want to know the "reason for the > difference" in this case, or at least have an (extra) example of a > known-bad audible transient generator, to test how well any future fix > of the sound equipment works.Agreed. Graham
Sharp DSP notch filter
Started by ●May 20, 2009
Reply by ●May 25, 20092009-05-25
Reply by ●May 26, 20092009-05-26
On May 25, 2:21�pm, pantel...@gmail.com wrote:> On May 25, 10:10�pm, "m...@sushi.com" <m...@sushi.com> wrote: > > > You can always dual boot a windows PC. > > It can be quite a challenge for a non Unix wizzard to start using > Linux, > especially command line tools like humfilter. > As humfitler is a a simple command line program,. > written in a simple C, and basically only > does wav file format input to wave file output, > it should be easily portable to DOS, and run in > a MSDOS window in for example XP. > Perhaps compile with the old djgpp compiler? > Several of my programs have been ported to DOS by people. > I am sure you can somehow send the wave output to a soundcard > even in MS software.It's been my experience that it is easier to compile software under Linux. The lack of compilers for windows is the issue. I assume to use the soundcard in windows, you need to use some windows API, and the documentation or lack thereof can be frustrating. While I'm not a programmer, I took a course in VB. Simple enough, except when it came to the APIs. The didn't always work as expected. Jan Axelmans (I think) serial book documented flag that were the opposite of what was described.
Reply by ●May 26, 20092009-05-26
On Fri, 22 May 2009 11:31:03 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:>Eeyore wrote: >> >> Martin Brown wrote: >> >>> Why not null out the 50 & 100 Hz components roughly with an analogue >>> filter and then look at the rest of them. Chances are at least some of >>> the clicks and pops are coming from zero crossing lamp controllers, CFL >>> and other switch mode loads. Fridges, oil boiler and aircon motors seem >>> to have the nastiest startup transients. >> >> I'd half though of that. Make sure you include 150 Hz btw, the worst on the line >> and 250 tends to be pretty bad too from memory of previous spectral analyses. >> However I'd rather go the whole hog because access to studios is relatively rare >> and you don't want to go in half-assed. > >If you capture the raw data as acquired you have an insurance policy. >> >>>>> However I have to go along with Tim. Filtering 50Hz harmonics is not >>>>> going to help. The plops and clicks you mention are not a multiples of >>>>> 50Hz. >>>> That's why I want to eliminate the 50 , 100 , 150 Hz etc so I can see what >>>> they ARE. >>> It might be easier to grab long chunks of the waveform with the 50 & 100 >>> Hz components only crudely nulled out and then use an FFT mask IFT type >>> post processing solution to remove your remaining unwanted fundamentals. >> >> Not really helpful since we want to see it happening in real time in response to >> specific events. > >You could process it on an ordinary PC fast enough to look like realtime >to a human. All you want to ensure is that the signal spike you are >looking for will be adequately digitised so removing all the major >components to within a couple of volts ought to be good enough. > >FFTs are very resilient if you signal average the power spectrum. > >>> You only need to save the buffer when a click is heard. Something that >>> is sharp in the time domain will be extended and spread out in the >>> frequency domain. Clicks and pops should still be visible in the FFT >>> even with some uncancelled fundamental. >> >> Sort of used that method for something else but this really is different. > >What are you hoping to learn from this experiment? > >Wouldn't a transient detector be much simpler to implement and almost as >good? > >>> I'd be more inclined to monitor the buildings 3 phase mains input power >>> in realtime and look for contemporaneous sudden changes in the reported >>> power usage just after a spike/pop/glitch is heard. >> >> It's dual single phase actually. They may even be on the same phase but go back to >> the street separately. > >But total power in is easy to monitor and the signature of the sorts of >heavyweight aircon kit likely to cause trouble should be unmissable. >Thinking about it I'd be inclined to take along a bunch of wireless >webcams pointed at the most likely suspects and record them timestamped >with the other stuff. > >>>>> These are just random spikes on the mains. If these spikes end >>>>> up in your audio circuitry, then you most likely have a ground loop or >>>>> another ground related problem somewhere. It means that the current >>>>> from the spike shares a return path with your audio signal. > >>>> Trust me, my colleague and I know all about ground loops, technical earths >>>> etc and have even completely Faraday caged several studios. >>>> >>>> I do not believe it has anything to do with grounds on the basis of what I've >>>> seen. >>>> >>>> What I'd really like to know is just where I can find info on doing what I >>>> wanted to do, i.e. perform sharp notch filters with a narrowish bandwidth. I >>>> do know what I'm doing in terms of trying to analyse the problem, I just need >>>> some help with the DSP. > >>> I presume you have already tried copper/mu-metal/copper sheets above and >>> below to prevent ingress of stray magnetic fields. >> >> Not possible. The studio is complete and not suited to modification. Sure, there's >> lots of things you could do if you went back to the beginning. In another story I >> could tell you how useless I found mu-metal in an ultra-critical mic amp but that's >> a LONG story and I suspect relates to transformer winding methods. > > >Mu-metal on its own isn't all that good. It has high magnetic >susceptibility but isn't that good a conductor. It needs a layer of very >good conductor on top to generate field cancelling eddy currents. >Bacofoil will do at a pinch. > >Regards, >Martin BrownMartin, you do not seem to quite get the application domain issues yet. The objective is to maintain ultralow EM interference systems in the presence of high magnitude intermittent incident EM interference, in RF regions, ultrasonic regions, and audio regions for both conducted and radiated (including partially rectified and reradiated) cases.
Reply by ●May 26, 20092009-05-26
On Thu, 21 May 2009 21:58:34 +0100, Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:> > >Vladimir Vassilevsky wrote: > >> Eeyore wrote: >> >> > What I will need to do however is to filter all the mains frequencies >> > and harmonics to a very large degree. >> > >> > I imagine I would need for example to null 50 Hz +/- 2 Hz to ~ -100dB. I >> > have done only a little DSP ( I can't see it happening with analogue >> > filters ) and I don't even know where to begin with such a severe filter >> > without affecting the pass-band. Same will go for harmonics up to some >> > serious number. >> >> The multiple notch filter is simple enough, however it will create the >> audible artifacts, and it won't do much help against the power interference. > >It's the interference I want to discriminate from the power line fundamental and >harmonics and see in real time. > > >> > Can anyone offer some advice as to algorithms ( number of cycles for >> > such a deep notch ) >> >> Short answer: that won't work. > >Not sure what you mean there. I've only a small experience of DSP filtering you >see, although I've done some moderately complex audio reverb processing. > > >> > and even better, a readily available eval board upon >> > which it could be set up ? >> >> Use a PC with a sound card. > >Could do, although I'd prefer a 'one box' solution. > > >> > Remember I only need to 'hear' audio band, so >> > 44.1 or 48 kHz sampling should be OK esp given the oversampling ADCs >> > today. >> >> In the broadcasting equipment, they used to inject the AC frequency and >> its harmonics into the audio to cancel out the power interference. > >That must have been ages ago or specific to broadcast. Besides anything that >moves over about 200m gets digitised and goes up fibre optic these days. Not a >technique ever used in recording studios I've ever seen and that goes back a >bit. > > >> The phases and amplitudes were adjusted for maximum rejection. That helped >> to some extent, however the power interference is rather nonlinear and >> nonstationary, which makes the problem difficult and non-trivial. > >Exactly. > > >> So you shouldn't expect the miraculous improvement anyway. > >I think you may have misinterpreted what I'm seeking. Tim Wescott's second post >hit the nail on the head. > >GrahamI would have to say close. Your issue is to find, identify and deal with interference sources, both conducted and radiated.
Reply by ●May 26, 20092009-05-26
On Thu, 21 May 2009 21:48:23 -0700 (PDT), "miso@sushi.com" <miso@sushi.com> wrote:>On May 21, 2:04�pm, Eeyore <rabbitsfriendsandrelati...@hotmail.com> >wrote: >> "m...@sushi.com" wrote: >> > Eeyore <rabbitsfriendsandrelati...@hotmail.com> wrote: >> >> > > I am proposing to engage on a project regarding mains voltage 'purity' >> > > (and absence of ) with regard to audible clicks and pops in high-end >> > > professional and hi-fi audio equipment. >> >> > > Typical EMC filters operate in the RF band and are threfore no use to >> > > filter audio 'in band' noise that can travel through transformer >> > > interwinding capacitance etc. >> >> > > I have found some of the TI INA series that will with suitable >> > > preconditioning, tolerate mains voltages and give excellent common-mode >> > > etc rejection. So assembling a 'preamp' front end should be no problem. >> >> > > What I will need to do however is to filter all the mains frequencies >> > > and harmonics to a very large degree. >> >> > > I imagine I would need for example to null 50 Hz +/- 2 Hz to ~ -100dB. I >> > > have done only a little DSP ( I can't see it happening with analogue >> > > filters ) and I don't even know where to begin with such a severe filter >> > > without affecting the pass-band. Same will go for harmonics up to some >> > > serious number. >> >> > > Can �anyone offer some advice as to algorithms ( number of cycles for >> > > such a deep notch ) and even better, a readily available eval board upon >> > > which it could be set up ? Remember I only need to 'hear' audio band, so >> > > 44.1 or 48 kHz sampling should be OK esp given the oversampling ADCs >> > > today. >> >> > I'd be more inclined to sample the AC by phase locking to it. >> >> Yes, sampling the mains fundamental would be neat. I don't think you'd even >> need to be phase locked for simple notch filters. >> >> > Then you could easily create a comb filter to kill the power line >> > fundamental >> > and harmonics. This implies that you should use a 48kHz sample rate. >> >> Readily available. >> >> > I'm not sure you need any filtering prior to sampling given the >> > dynamic range of ADCs these days. >> >> Agreed. Just a simple first order at some high frequency for luck probably. >> >> > If your spike is say 70dB down from the carrier (60/50 Hz mains), I can't >> > believe it be significant to the >> > power supply design. >> >> I wouldn't make ANY assumptions of that nature with today's high SNR audio ! >> I've seen some astonishing things. >> >> > Besides basic DSP filtering, you could use LMS to get rid of the >> > fundamental. I suppose you could then LMS for each harmonic. >> >> Hadn't thought of LMS. Not looked at it in ages actually. You mean the >> off-the-shelf package ? A bit pricey IIRC. >> >> Graham > >I programmed the LMS fit. For the fundamental, you just phase unwrap >the sampled signal (presumably a sine) with an arcsin. The phase >versus time plot should be series of points that would ideally be a >straight line. If you fit a line to these points using LMS, the slope >will indicate the LMS best fit to frequency. At the time, that was all >I needed to do. But later I hacked a bit by creating a perfect sine >wave using this LMS derived slope. I don't recall how I did the >amplitude fit, but I think I didn't do LMS, but just ran some >optimizer to vary the amplitude to make the difference between samples >and the fitted sine wave go to a minimum. This is not a rigorous >solution to the problem, but probably valid. Note I did this a few >decades ago, so none of this is perfectly fresh in my mind, but the >technique as I recall it is sound. > >As a hardware person, I think the phase locked sampling and comb >filter would be the way to go. You probably would have to come up with >a VXCO for the phase locked source. I hate all this windowing stuff. >Synchronous sampling is much cleaner.Sounds nearly sensible to the task, but does not address detecting the difference of line disturbances very well.
Reply by ●May 26, 20092009-05-26
On a sunny day (Mon, 25 May 2009 20:50:48 -0700 (PDT)) it happened "miso@sushi.com" <miso@sushi.com> wrote in <d946c8cd-b785-4f80-a7da-97d8bcce5d2f@p6g2000pre.googlegroups.com>:>It's been my experience that it is easier to compile software under >Linux. The lack of compilers for windows is the issue. I assume to >use the soundcard in windows, you need to use some windows API, and >the documentation or lack thereof can be frustrating.humfilter does not use the sound card. It just creates a filtered wave file from a non-filtered wave file. there are plenty of free C compilers for MS win, including MS own one. But you can cross-compile on Linux too with for example DJ Delories djgpp as I pointed out. Or even native in MSDOS. I do not have it installed, but for 1000 Euro I could [make a DOS version of humfilter] :-) Else look here: http://www.delorie.com/djgpp/ Anyways, if you port my software (anybody) please keep to the GPL license conditions. I do no very actively pursue and search for GPL violations, but the FSF may torture you and send you to a jail in Cuba :-)
Reply by ●May 26, 20092009-05-26
"miso@sushi.com" <miso@sushi.com> wrote:>On May 25, 2:21=A0pm, pantel...@gmail.com wrote: >> On May 25, 10:10=A0pm, "m...@sushi.com" <m...@sushi.com> wrote: >> >> > You can always dual boot a windows PC. >> >> It can be quite a challenge for a non Unix wizzard to start using >> Linux, >> especially command line tools like humfilter. >> As humfitler is a a simple command line program,. >> written in a simple C, and basically only >> does wav file format input to wave file output, >> it should be easily portable to DOS, and run in >> a MSDOS window in for example XP. >> Perhaps compile with the old djgpp compiler? >> Several of my programs have been ported to DOS by people. >> I am sure you can somehow send the wave output to a soundcard >> even in MS software. > >It's been my experience that it is easier to compile software under >Linux. The lack of compilers for windows is the issue. I assume toLook for Mingw. Thats a GCC that works fine to compile software under Windows. Still, more complex programs cannot be compiled easely because of the Linux build tools.>use the soundcard in windows, you need to use some windows API, and >the documentation or lack thereof can be frustrating.Try to find a library that handles that for you. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
Reply by ●May 26, 20092009-05-26
On Tue, 26 May 2009 19:55:38 +0000, Nico Coesel wrote:>>It's been my experience that it is easier to compile software under >>Linux. The lack of compilers for windows is the issue. I assume to > > Look for Mingw. Thats a GCC that works fine to compile software under > Windows. Still, more complex programs cannot be compiled easely > because of the Linux build tools.MSys (hosted on the MinGW site) provides make, a shell, and most of the common text-processing tools (sed etc). This will allow a lot of Unix projects to build with little or no modification.>>use the soundcard in windows, you need to use some windows API, and >>the documentation or lack thereof can be frustrating.http://msdn.microsoft.com/en-us/library/ms713503(VS.85).aspx
Reply by ●May 26, 20092009-05-26
On Fri, 22 May 2009 20:13:39 +0100, Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:> > >Nico Coesel wrote: > >> Eeyore wrote: >> >Nils wrote: >> > >> >> After reading the discussion I wonder: >> >> >> >> Couldn't you simply connect a transformer to the mains, add a resistor >> >> divider at the output to get the signal down and record the glitches? >> > >> >My front end will do all of that to get the levels right etc. The thing is, >> >you don't seem to be able to see the glitches for the mains, we've already >> >been looking. They must be quite small, or it's getting in via another >> >> Get a proper digital scope. Many scopes lower their samplerates so you >> don't see short glitches. Lecroy is bad when it comes to this kind of >> behaviour. What you need it peak detect. > >I agree but it's beyond our budget for this alone. By making dedicated kit of >our own, designed specifically for this kind of job alone we can avoid that >problem. > >GrahamCheck leasing a good scope for 3 to 6 months. Might be worth it, then again it might not.
Reply by ●May 26, 20092009-05-26
On May 26, 3:43�am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote:> On a sunny day (Mon, 25 May 2009 20:50:48 -0700 (PDT)) it happened > "m...@sushi.com" <m...@sushi.com> wrote in > <d946c8cd-b785-4f80-a7da-97d8bcce5...@p6g2000pre.googlegroups.com>: > > >It's been my experience that it is easier to compile software under > >Linux. The lack of compilers for windows is the issue. �I assume to > >use the soundcard in windows, you need to use some windows API, and > >the documentation or lack thereof can be frustrating. > > humfilter does not use the sound card. > It just creates a filtered wave file from a non-filtered wave file. > there are plenty of free C compilers for MS win, > including MS own one. > But you can cross-compile on Linux too with for example DJ Delories > djgpp as I pointed out. > Or even native in MSDOS. > I do not have it installed, but for 1000 Euro I could [make a DOS > version of humfilter] :-) > Else look here: > �http://www.delorie.com/djgpp/ > > Anyways, if you port my software (anybody) please keep to the GPL license > conditions. > I do no very actively pursue and search for GPL violations, but the FSF may > torture you and send you to a jail in Cuba :-)A bit off topic, but for those that want to do analysis on a wave file, you can use sox to convert it into ascii. I've done this to put sampled signals into spice as a PWL input. Obviously, you need to use some scripting or write a small program to get the data in spice format.