Show Posts
Pages: 1 2 3 [4] 5 6 ... 25
46  Using Arduino / Project Guidance / Re: Why inaccurate tempo? on: March 31, 2014, 10:53:30 pm
... ceramic resonator ...  Is this true?
Indeed.  The schematic, available here - - shows a device labeled "CSTCE16M0V53-R0 16MHZ" between the ATMega's XTAL pins.  The manufacturer shows that gizmo to be a "timing device," with initial tolerance of 0.5%, temperature stability of 0.3%, and frequency aging of 0.2%, here:

Quote from: Shakespeare, Hamlet, ~1600
The time is out of joint. O cursed spite, that ever I was born to set it right!

The OP reports that the Arduino's LED is "inverted" after 1 minute 40 seconds.  Presuming that means that the two devices are off by 1/2 cycle, at 60 beats per minute, here's how it works out:
  • 60 beats per minute = 1 Hz;
  • accumulated error at 1 minute 40 seconds = 1/2 cycle = 0.5 seconds;
  • relative error = 0.5 seconds / 100 seconds = 0.005 = 0.5%,
and that's the reported initial tolerance for the resonator.  All's well that ends well.

The Arduino isn't good at keeping time.  Folklore says that using the crystal that drives the ATMega16U2 for the 328, or using two crystals, would prevent the device from passing the US FCC's electromagnetic emissions test, so the designers opted for accuracy in communication timing, and something less in the processor clock.  If you want something precise, you can get a clone that uses a crystal, like a Diavolino -

Quote from: Shakespeare, All's Well That Ends Well, ~1604
Our remedies oft in ourselves do lie.
Or, you can build your own.
47  Using Arduino / Project Guidance / Re: Music tuner that monitors four sources at once on: March 26, 2014, 08:20:32 am
Always nice to come for help and get insulted.
A thin-skinned bagpiper?  You mean you didn't see that coming when you posted?

Initially, I thought you wanted to tune all the pipes by examining a single signal, separating the component tones, and reporting their frequencies - like polyphonic guitar tuners that have come out lately.  That's a demanding task, likely beyond even an ingenious Arduino implementation.  It's especially challenging for bagpipes, with three of the four sounders playing the same note.  After your fourth post, it looks like you're contemplating something with four separate sensors, and tuning the signals one at a time.  That's certainly feasible for the drones, if you can keep the sensors from hearing each other's pipes.  Tuning the chanter while playing, though, is likely to be challenging.

The "instructables" link referenced earlier is applicable to single-tone tuning.  So is this one, which uses autocorrelation to estimate the frequency:

You've gotten several useful references for this project, but I don't see any evidence that you've looked at them.  That makes me think that maybe you intend for someone else to implement this for you.  If that's so, you might try the "Gigs and Collaborations" section, here:  If you want to continue pursuing it in this section, you'd do well to provide a more detailed description of your vision.
48  Using Arduino / Project Guidance / Re: Music tuner that monitors four sources at once on: March 23, 2014, 12:24:11 am
This is the first I've heard that anyone ever tries to tune bagpipes.  None of the ones I've heard suggest that intonation is high on anyone's priority list.

Single-tone tuners are hard - just do a search on this forum, and see how many people aspire to making one, and how few report success.  They're much easier if they don't have to identify the input frequency automatically.  It may be that you don't need that feature.

You can see a solution for this project in Patent #8,309,834, an Apple patent for a polyphonic tuner.  A quick reading says that the technique is: use some kind of frequency discrimination function - almost certainly an FFT - to identify a frequency close to the lowest fundamental you're looking for, and then identify a couple of harmonics of that frequency to be sure that the fundamental is really present; repeat that for the other frequencies of interest using the same data; and finally, report the results as either sharp or flat.  It's written in patent-ese, with the intent of covering as many implementations of the concept as possible, without really giving much away.  A Google search for the patent will yield descriptions that are more understandable, but generally equally uninformative.

This scheme calls for some pretty precise frequency estimates.  For a six-string guitar, some of the interesting frequencies are close together, requiring narrow frequency bins to differentiate between them.  It might work if you're Apple, doing this on a smartphone or audio workstation, where memory sizes and processor speeds start with, "giga-," and high sample rates spanning several cycles aren't particularly challenging.  The Arduino Uno may not be up to it.

The "instructables" link isn't really applicable to this project.  It relies on identifying the input signal's zero-crossing with the maximum slope, and measuring the time between those events.  That's iffy for single-tone signals; it's no help for polyphonic signals.  You might be happier with a single-tone tuner.  How often do you have to tune up, and how fast?
49  Using Arduino / Programming Questions / Re: analogRead() Problem on: March 20, 2014, 09:37:02 pm
A0 is a value that the code uses to identify the pin.  To see this in action, try this:
void setup() {

void loop() {
I predict that it will print, "54." 

Your program assigns the value represented by A0 to the variable Potentiometer.  It never assigns anything else to it, so the value of Potentiometer never changes.

For the Due, the value of A0 is established in the file:
If you look into that file, you'll find this line:
static const uint8_t A0  = 54;
When you print A0, you get, "54."  Earlier replies in this thread describe how to store and print the analog value.
50  Community / Bar Sport / Re: Normal English phrase embarrassing in the US on: March 15, 2014, 10:43:20 pm
All y'all are having a lot of fun at Houston's expense.  Since I live in Houston, I feel compelled to defend it.  However, most of what you're saying is true-ish, if not true outright.

... try and avoid saying "I have to shoot off"!
With a reasonable audience, you can get away with it - indeed, you can get away with almost anything - if you say it with a British accent.  Teenagers and young men who don't date much will probably ridicule you for it, no matter what your accent.  Unless you're from Yorkshire, in which case no one will understand you at all.

Never use "pop" or "soda".
I live in Houston now, and I can't remember the last time I heard generic soft drinks called "cokes."  It's a ferocious melting pot here, and things change fast.  I say "soda," and always get away with it.  Out in the hinterland, though, everything seems to be a coke.

If he prefers iced tea sans sugar he must specifically request "unsweetened tea".
Yes, he must.  The default state of iced tea is sweetened.  In the broad swath of the south, an especially sweetened tea has come into use, made by saturating it with sugar while it's hot; that's called, "sweet tea," and you generally have to ask for it specifically.  It the server asks you, "Sweet tea?" and you decline, you'll probably get sweetened tea.  

"Fixin-to" = "planning" or "going to".
"Fixin' to" is used by the speaker to explain why he's idle at the moment.  "Whatchoo doin' up there on the porch with that mint julep, Buford?"  "I'm fixin' to go out back and dig me some post holes."  Post-hole digging is a lot of work, so it sounds like the speaker is very busy, while fixin' to dig post holes is kind of relaxing, and may involve whiskey or beer.

... don't ask for a rubber.
Indeed.  Even an upperclass London accent won't help you with that one.  Especially, don't send your young daughter into the drugstore to ask for them.

Y'all is singular ...
Yeah, sort of.  In my experience, the expected form of address - "you," "y'all," or "all y'all," - depends on the angle that the listeners occupy, from the speakers viewpoint.  Narrow angle, "you;" up to about 90 degrees, "y'all;" more than that "all y'all."

51  Using Arduino / Audio / Re: FFT on Arduino, the audio spectrum is cluttered? on: March 15, 2014, 10:57:50 am
However despite using analogRead(), by adding "ADCSRA = 0xc5;" to the code, I still get the same amount of noise reductions while still having around 20kHz freq range.
What's going on here?
What's going on is this:  by executing "ADCSRA = 0xc5,", you change the ADC settings, and change the way it works.  The ADC prescaler is set to 5, selecting a system clock divider of 32, an ADC clock of 500 kHz, and a sample time of 13.5 ADC clock cycles, 27 microseconds.  That corresponds to a maximum sample rate of about 37 kHz, and a Nyquist frequency of about 18.5 kHz.  Because the ADC conversions are triggered by the program, rather than hardware, you'll lose some time in loop overhead and function calls, so the actual sample rate and Nyquist frequency, will be something less.  You measured 15.5 kHz - something less than 18.5 kHz, as expected.  That suggests that you're losing about 5 microseconds per conversion in software, or about 80 system clock cycles.  That's probably not unreasonable.

Your posted code didn't manipulate ADCSRA, so it uses the default prescaler of 7, didviding the system clock by 128, for an ADC clock of 125 kHz, and a maximum sample rate of about 9.3 kHz.  It aliases at something like 4 kHz.  As expected.

If you want to know how the ADC control registers affect the way the ADC works,
You can read about setting up the ADC in the ATMega328 datasheet, Chapter 24.
52  Using Arduino / Audio / Re: FFT on Arduino, the audio spectrum is cluttered? on: March 14, 2014, 07:38:34 pm
But how come that when I sweep the tone generator to 20khz it shows up on the arduino's far right side?  And anything beyond 20 khz starts to move to the left again?
You're talking about using the Open Music Labs code.  It works up to about 20 kHz because the sampling frequency is about 38.5 kHz.  That code doesn't use analogRead() to get samples; it directly manipulates the ADC.  ADCSRA is set to 0xE5: enable,  start conversion, auto-trigger enable, and prescaler 5.  On a 16 MHz Arduino, that sets the ADC clock to 500 kHz, and, with a conversion every 13 ADC clock cycles, the sample rate is about 38.5 kHz.  The Nyquist frequency is about 19.2 kHz - close to 20 kHz.  You can read about setting up the ADC in the ATMega328 datasheet, Chapter 24.

You've noticed, I'm sure, that you don't get that kind of performance out of your "noise cancelling" code.  That code uses analogRead() to get samples, and leaves the ADC clock at the default setting of 125 kHz, prescaler 7.  The ADC isn't free-running, so samples take 13.5 ADC clock cycles, for a maximum sample rate of about 9.3 kHz, and a Nyquist frequency of about 4.6 kHz.  There'll be some time lost between the end of one conversion and the start of another, so the rate will be a bit less than that.  With sampling controlled by the program, rather than a hardware clock, there'll probably be jitter, but, with interrupts disabled, it may not amount to much.

The results shown in the first post, with a bipolar sine signal directly coupled to the analog input, look about right.  I'd expect the ADC to read zero for the entire negative half-cycle, and to track the input signal for the positive half-cycle, if it wasn't destroyed outright.  Here's a link to a table of Fourier series, showing the coefficients for a half-wave rectified sine signal:  It has a DC component, a component at the fundamental, and decreasing components at even harmonics.  That corresponds qualitatively with the initial results.
53  Using Arduino / Audio / Re: Frequency detection on: March 10, 2014, 10:33:41 pm
See a similar project here, with link to code:
54  Using Arduino / General Electronics / Re: Multi-phase buck converter on: March 07, 2014, 04:22:00 pm
I'd be leery of this code.  It doesn't do anything intentional to establish any particular phase relationship between Timer1 and Timer2; it just gets lucky.  Here's why it seems to work:
  • The last thing that the internal startup code does is to set up and start Timer2.  Timer2 runs at 1/64 of the system clock, so it's still at zero when setup() executes.
  • Timer1 is set to full scale for its mode - 8-bit phase-correct PWM, mode 1 - rather than half-scale, as claimed in the text accompanying this code.  The code sets it explicitly to 0x7FFF, but Timer1 ignores the most significant byte in mode 1, and sets itself to 0xFF.  That more or less works, because the phase-correct mode counts up to the top, and then down to the bottom, rather than rolling over.  Timer1 is set to one tick away from zero, upcounting, at a time when Timer2 is at zero, upcounting.  On the next tick, Timer2 starts counting down, while Timer1 counts up.  They're almost 180 degrees out pf phase, but that's largely a matter of luck.  If the next version of the IDE adds code between setting Timer2 and calling setup(), or if you add code at the beginning of setup(), the phase relationship will be less accurate.  With just a couple of analogRead()'s, it gets off pretty far.

Here's an 8-phase PWM controller, made for applications like this:  It costs about $3 US in big quantities.  I didn't readily find any for sale in singles.  Maybe the manufacturer will sample a couple to you.

I believe that an Uno won't lend itself well to generating the PWM pulses you want.  A Due might.  The datasheet claims, "Up to 8-channel 16-bit PWM," - exactly the right number - but I don't know how that's implemented in the Due, or supported in the IDE.  If you want to investigate that, you might try the Due forum, here:

I'll echo Grumpy Mike's sentiment, and vote that you prototype something with less current.  A buck converter runs just one step ahead of the grim reaper - if a driver doesn't switch off, the supply voltage shows up on the output in short order.  This statement:
I am new to microcontrollers ...
suggests that you'll have multiple rounds of debugging, and, with this project, that suggests that you might see a little smoke.
55  Using Arduino / Programming Questions / Re: Interruptions using TimerOne.h library on: March 04, 2014, 11:22:33 pm
If you're new to this, you may want to try something simpler.  Then, when that works, try adding some additional functions.  Based on what you've said here, it looks like you're trying to write the whole program at once.  When you do that, it can be very difficult to figure out what isn't working.

It sounds like you're making a traffic light controller.  I'll suggest that you try making it work like a simple automatic traffic light:  turns red for a while, and then turns green for a while - you don't mention a yellow light, so I presume that you're not implementing one.  If you can't make it work, you can post your code, describe what you expected, and describe what you it does instead.  If you can make it work, then you can try to add another function, and, when you run into trouble, post code, a clear description of what you expect, and a clear description of what it does.  When you post code, please make sure that you post something that compiles, so that others can load it straight into an Arduino and see how it works.

So far, you haven't told us much.  Your description is hard to understand, and you don't show any code.  It's difficult for anyone to offer any help.

As you get further into this project, you may find that it works well as a state machine.  Here are a couple of references that discuss state machines:
56  Using Arduino / Programming Questions / Re: External interrupt while going to sleep with ADXL345 ends in "endless wait" on: March 04, 2014, 07:12:54 pm
Somebody else had a similar problem, and fixed it, here:  Maybe that solution will work for you, too.
57  Using Arduino / Audio / Re: Comparing frequencies with FFT on: March 01, 2014, 10:45:48 am
OK, it sounds like the audio part of this problem is to discern the difference between these two conditions:
  • A quiet room, and
  • An otherwise quiet room with a baby crying in it.
The fact that it's very easy for a human to make that distinction is promising.  Here are some differences that we'd expect to find between when the baby cries:
  • The total audio signal will be louder overall - maybe a lot louder
  • The signal will have significant content at baby-crying frequencies
A start might be to find some audio files of babies crying, play them to your Arduino in a quiet room, and observe the output of the FFT with and without crying.  It will be easier to see the differences graphically.  I usually print the output to the serial monitor, copy it to a spreadsheet, and graph it.  There may be better or more convenient ways to do it.  A quick google finds a number of mp3's of babies crying.

A more fundamental approach would be to use test tones with known spectral content, to verify that the assembled project accurately reflects the audio signal.  I'd recommend this if it's important that you're able to accurately characterize how your system works, or how you derived your solution.  mp3 files of test tones are easy to google.

I have no expertise on the spectral content of babies crying.  I think that this:
A baby's cry has a frequency of 3500kHz on average.
is probably a typographical error, and that you meant to say 3500 Hz, or maybe 350 Hz.  3500 Hz is the third-highest white key on a concert piano - it's a really high note.  The first estimate of the pitch of a baby's cry that I found was 515 Hz.

Note that the output that you can expect from your code is a logarithmic representation of the Fourier transform.  That representation compresses the magnitude of the spectrum: it de-emphasizes large spectral components, and emphasizes small ones.  You might want to experiment with a linear representation.  You can find information about how to get that in the fft_read_me.txt file in the openmusiclabs FFT library.

What's your current understanding of the meaning of the FFT output?
58  Using Arduino / Audio / Re: Comparing frequencies with FFT on: March 01, 2014, 12:10:08 am
I need to detect a baby's cry out of the surrounding sounds.
For what purpose?  Do you envision a do-it-yourself device minding the baby while you barbecue steaks in the back yard, or nap in the solarium?  I can't really think of another reason for this function.  I'm not sure that I want to be part of it -  I'd rather not have to answer in the next life for the sufferings of an infant in this one.

Maybe you just want to do this for the sheer intellectual joy of proving that it can be done.  Maybe you're talking about some non-human baby crying.  I'm OK with that.  If that's so, then you'll want to explore the whole idea of the Fourier transform, and what it means.  Then, look at the digital Fourier transform, and finally at its special case, the fast Fourier transform.  I'd start with the Wikipedia, and google from there.  Ultimately, you want to understand what the output of the FFT describes, and how it's related to the physical reality that gives rise to it.

You'll also want to read the datasheet for the processor you plan to use.  You need to tell us which one.  I assume that you're using an Uno.  The section on the Analog-to-Digital Converter (ADC) will be especially helpful, since that's the engine that will acquire your data.  The openmusiclabs code that you've incorporated runs the ADC at nearly 40 kHz - faster than the datasheet recommends, and maybe faster than you want, but not so fast that the data isn't usable.  Or, so I read and hear.

You'll need to characterize the sound you want to identify.  I don't really know how you're going to get sample data from a baby crying.  Maybe just run a recorder until you get what you want, or maybe introduce a recorder during the inevitable moments when somebody else unsuccessfully tries to quiet the baby.  For heaven's sake, don't make it cry just to get audio samples.

You'll also need to characterize the ambient sound in the environment where you'll use it.  Obviously, if you're trying to pick out your baby's cry in a nursery full of other children, it'll be a lot harder than picking it out against the background noise of, say, the air conditioner fan blowing in the background.

When you can describe the FFT's of those two sounds - baby crying and not baby crying - then you'll have to devise a way of telling the difference in the sketch.  That might be easy, or it might be hard.

It sounds like you're relatively new to audio analysis, to programming, and to this hardware.  You've selected a very challenging early project.  If you have a high tolerance for frustration and disappointment, then by all means, proceed.  If not, you might be better advised to start with easier projects with hope of quicker success, and less rigorous theoretical demands.

59  Using Arduino / Audio / Re: Comparing frequencies with FFT on: February 28, 2014, 03:38:45 pm
What should I do?
Please be more specific.
  • What are you trying to accomplish?
  • You showed some code - did it work the way you expected?
  • Presuming it didn't work like you hoped- since you're posting here - what did it do?

And, you can do something about the Timer0 interrupt.  Your code disables it early on, and then calls delay(), which relies on the Timer0 interrupt in order to function.  Either refrain from disabling the interrupt, or don't call delay().
60  Using Arduino / Audio / Re: Frequency modulation with arduino uno on: February 21, 2014, 02:00:52 pm
I like seeing abbreviated code.  It keeps me from having to pore through hundreds of irrelevant lines.  When you abbreviate code, though, I'll suggest that you test it before posting, and determine that it compiles, runs, and demonstrates the problem that you're trying to resolve.  If it doesn't compile or run, or it's overly complex, a lot of potential thread participants will skip it and move on to the next thing.  And, obviously, if it doesn't demonstrate the problem, posting the code won't help solve it.  Here's a snippet from "How to use this forum," found here -,148850.0.html - Item #11, "Tips for getting the most out of your post:"
Post a complete sketch (program code)! If you don't you waste time while people ask you to do that. However, with coding problems, if possible post a "minimal" sketch that demonstrates the problem - not hundreds of lines of code. If the problem goes away in the minimal sketch, it wasn't where you thought it was.

From what I see, running the timer at 2 kHz won't resolve the issue - it'll just make it appear less frequently.  The problem is that the TIMER0_COMPA ISR takes longer to execute than the time between TIMER1_OVF interrupts.  Depending on where in the TIMER1 cycle the TIMER0 interrupt occurs, it will execute through two TIMER1 interrupts, and you'll miss one.  The appearance, from an audio viewpoint, will be that the TIMER1 interrupt slows down; in fact, it will just be missing some updates, thus stretching out the output waveform in time. 

Another alternative might be to disable the Timer0 interrupt, poll the timer status in the in the Timer1 interrupt, and execute the Timer0 ISR code when Timer0 has fired.  The Timer0 code takes only a little longer than a Timer1 interrupt.  The fast PWM mode updates the OCR at rollover no matter when the OCR is changed, so, in theory, you have nearly twice the Timer1 duration to manage that calculation if you start early.  That might work, if the rest of the sketch can tolerate having the Timer1 ISR take control for more than its cycle time. 

Note that these notions are strictly intuitive - I haven't tested any of these theories, or tried any proposed solutions.
Pages: 1 2 3 [4] 5 6 ... 25