Guitar tuner project

Felipe S. · Joined: 23 Oct 2008 Posts: 10 Location: Vina del Mar, Chile

Hi all. For my grade project in college, I decided to build a digital guitar tuner based on a PIC18F2550.

The phase I'm currently on is testing the sampling capabilities of the PIC's ADC converter. The sampling frequency is 4.3 KHz and for the test I'm going to use a signal generator to "feed" the A0 pin with a sinusoidal signal with a frequency on the 80-330 Hz range. Each digital sample is sent to a register in the RAM data memory where it is stored. Then an algorithm counts the number of samples based on a fixed number of periods (10, in this case) and shows the number on a LCD display.

I've done the test in Proteus and works fairly well, but when transposing to the field, it does the weirdest readings. For example, if the frequency of the analog signal is 300 Hz, the Proteus simulation shows a sample count in the 135-137 range, which is fairly good. But in the real world, the sample count is off, even showing an absurd -7347, for example! Sometimes it even resets the program during the conversion.

So, I probably must be dealing with noise issues. The problem is, I don't know how to fix this. I've done the following:

- Passed the circuit from breadboard to etched prototyping PCB

- Included a low pass filter for anti-aliasing, with fc = 2 KHz. The op-amp used for the filter is a low noise OP07.

I know I'm missing something else, but I don't know what. I'll appreciate any help on the matter.

The code for the program is below. I wouldn't mind the "menu1" and "menu" subroutines, as those are for displaying text on the LCD. Like you can see, I'm not using interrupts:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Ttelmah · Guest

Start with a couple of minor 'comments'.
Why 'reserve' the RAM area for the data?. Just assign an array, so, have:

Guest · Posted: Fri Oct 24, 2008 5:20 pm

Thanks a lot for the answers.

PCW Programmer, thanks for pointing out my newbie mistakes. This is actually my first program in C language, so a couple of inefficiencies in programming were a given, I guess.

Ttelmah, I was aware of that property of the pins, as I noticed how some kind of internal diode cuts the signal below zero, watching with an oscilloscope the AC analog signal entering the A0 pin. I thought of just letting it be, but since it may cause me problems like the one you wrote about, I may as well do as you say and add a DC bias to the analog signal.

I modified the program considering all of that, and it runs quite well on Proteus. I'll let you know for sure when I run the new configuration on the lab.

About the filter, I'm using a Butterworth 2nd order with fc = 2 Khz, although it may be better to change that to a lower value, like 1.5 or even 1 Khz just to be sure that no signal above 2 Khz makes it.

Thank you both for pointing out the use of arrays, I actually read about them somewhere else in this forum, but never bothered to learn to use them. I applied them to the program and it certainly looks much more ordered that way.

BTW, I also read about the use of sleep mode in ADC in order to avoid PIC noise issues. How is that done?

Felipe S. · Joined: 23 Oct 2008 Posts: 10 Location: Vina del Mar, Chile

^^ That is me. Forgot to log in. Razz

Felipe S. · Joined: 23 Oct 2008 Posts: 10 Location: Vina del Mar, Chile

Ok, nevermind, I found this example of how to use sleep mode in a/d conversions, and modified the program accordingly.

I'm happy to say that now the display gives me much more stable readings. There's still some problems in reaching a steady and low-range interval of sample numbers. Here I feel I must explain myself.

The frequencies I'm testing with my program are as follows: 329.6, 246.9, 196, 146.8, 110, 82.4 Hz. Each of them corresponds to the first harmonic of the open note in each of the guitar's strings (we are talking about standard tuning, for those who know the instrument). The program is designed so that at the end of the whole process, the display shows me a number, which is the number of samples taken in 10 periods of the converted signal. This number must be inside a certain range, and the smaller this range, the better. For example (I'm guessing here):

329.6 Hz ----> 53-56
246.9 Hz ----> 60-62
196 Hz ----> 68-70
146. 8 Hz ----> 75-78
110 Hz ----> 84-86
82.4 Hz ----> 93-98

Now, this is the how the a/d conversion loop looks now:

RLScott · Joined: 10 Jul 2007 Posts: 465

I don't see how you are going to measure the frequency of a guitar string with sufficient accuracy to be useful. A typical guitar tuner can measure the pitch to within 0.057%. Are you measuring the pitch based only on the number of samples taken in 10 cycles of the tone? If so, then you had better be taking about 1700 samples in those 10 cycles. If the pitch is 329.6 Hz, as it is in your highest string, then those 1700 samples would have to be taken in 30 mSec, so one sample would have to be taken in 17 usec. Is that what you hope to do? Take an A/D reading every 17 uSec? Or do I totally misunderstand your method?
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting

Guest · Posted: Thu Dec 04, 2008 8:27 am

Hello again. Sorry for not posting updates.

About the previously explained sampling issue, I figured it out. Turns out it wasn't a noise problem like I thought, but a mistake in the sampling counting subroutine. It runs perfectly now, with a signal generator as input. I must stop blaming noise for all the problems I run into. Razz

RLScott, despite seeing similar guitar tuning projects on the Internet using a 5000 Hz sampling frequency (or something along that value), you made a valid point there: how can I be sure that with that sampling freq. I can get an accurate result in tuning? Well, I did a test with the lab's signal generator last week. It turns out it has an error range of about 2.5 Hz on each side of the fundamental frequency of the first string (for example, if the fundamental of a perfectly tuned E first string is 329.6 Hz, my circuit also recognized as "tuned" a limit of 332.1 Hz on one side, and 327.1 Hz on the other), but that range got shorter and shorter as I went up the strings, for obvious reasons (namely, more samples per period, as the frequency in each string got lower and lower).

I found out that there isn't much of a difference in tone between, say, a 329.6 Hz tone and a 332.1 Hz tone and unless you have damn good hearing, you won't notice the difference (my ear is pretty good, so I noticed some minor difference in tone). Still, I'll consider what you said, even though I guess I need to increase the sampling freq just a bit (to, say, 6000 Hz) in order to get very accurate results.

Now, I'm doing the digital filtering part, and here's another part where I need the help of someone more experienced, as I'm a total newbie on the subject. I read that the best choice for the PIC's limited arithmetic capabilities would have to be a butterworth filter of order 1. Using MATLAB to figure out the coefficients, I came up with this formula for the first string (corner frequency = 400 Hz):

Y(n) = 8*X(n) - 6*X(n-1) - Y(n-1)

I approximated the values of the coeffs. which initially gave 7.794 and 5.795 respectively, because I want to work with ints, not with floats, although I'm not sure how much this will affect the result of the filtering (maybe a lot, that's where I need some advice). For this, I'm using pointers, so my filtering subroutine is as follows:

RLScott · Joined: 10 Jul 2007 Posts: 465

Guest · Posted: Thu Dec 04, 2008 5:44 pm

Felipe S. · Joined: 23 Oct 2008 Posts: 10 Location: Vina del Mar, Chile

^^ Me. Forgot to log in again.

RLScott · Joined: 10 Jul 2007 Posts: 465

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

I'm not aware of the technology of today's simple (1 cent accurate) tuners, but I wonder if they use digital signal processing as you intended to do. If so, they may utilize more specialized hardware.

Previous designs have been using analog filtering and e. g. multicycle period measurement. That means to have a defined measurement window, determining the exact location of the first and last zero crossing within and the number of cycles in-between. Measurement accuracy is only limited by signal jitter and clock frequency related to measurement interval.

With a sampled digital signal of rather low sampling rate (e. g. 5k), an individual sample has a huge timing uncertainty without utilizing the amplitude information at the same time. To achieve a zero crossing measurement sufficient for a cent accurate pitch determination based on sampled data, you need to interpolate the samples to a higher timing resolution. As a prerequisite, the sampling process itself must have a low jitter, which may be difficult with a pure software based sampling.

All these operations are basically simple in DSP, but may overstretch a PIC's resources. You need a clever application layout to overcome these limitations, if feasible at all.

Good luck,
Frank

RLScott · Joined: 10 Jul 2007 Posts: 465

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

I completely aggree. I didn't opt for a higher sampling rate, just wanted to clarify, that counting zero crossings probably wouldn't be enough, at least with a limited measuring time respectively when intending a fast response. There are different options to estimate a pitch accurately from a discrete spectrum or to determine it a from a limited length sample, I think.