Post by thread:[PIC] DTMF decoding

The recent discussion on DTMF decoding made me think about a project I had been considering for a while. I did some simulations to verify my math was right and look at filter time constants and the like. You can see the result at http://www.embedinc.com/temp/dtmf.gif. The input is bursts of the DTMF tones 697, 770, and 853 Hz. Each burst and the gaps between the bursts are 50mS long, which is the time you are supposed to be able to detect a DTMF tone within. The blue trace is the square of the magnitude of the detected tone. The algorithm was set up to detect 770Hz, which is the frequency of the center burst. As you can see, this worked very well. The blue trace would have eventually reached 1.0 if the center burst persisted. But clearly the center burst was well detected and the other two were not, even though the frequencies between adjacent tones differ by less than 11%. Below is the core code of the simulation. The complete code contains too many distractions to show here, like CSV file writing and other logistics. for sampn := 0 to nsamp do begin {once for each input sample} t := sampn * sampdt; {make time of this sample} samp := getsamp (t); {get input sample} r := t * freq; {make reference frequency phase} ii := trunc(r); r := r - ii; r := r * pi2; prods := samp * sin(r); {mix by ref freq sine and cosine} prodc := samp * cos(r); filter (filts, prods); {low pass filter mixer results} filter (filtc, prodc); magsq := sqr(filts.val) + sqr(filtc.val); {make square of magnitude} magsq := magsq * 4.0; {normalize} Obviously you wouldn't normalize the result in the PIC, you'd adjust the detection threshold instead. The FILTER subroutine does a two pole low pass filter. Each pole has a filter fraction of 1/128, which means it can be realized inside a PIC with a right shift of 7 bits. The input was sampled and processed every 100uS. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On Tue, Mar 30, 2010 at 9:57 PM, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTembedinc.com> wrote: {Quote hidden}> The recent discussion on DTMF decoding made me think about a project I had > been considering for a while. I did some simulations to verify my math was > right and look at filter time constants and the like. > > You can see the result at http://www.embedinc.com/temp/dtmf.gif. The input > is bursts of the DTMF tones 697, 770, and 853 Hz. Each burst and the gaps > between the bursts are 50mS long, which is the time you are supposed to be > able to detect a DTMF tone within. The blue trace is the square of the > magnitude of the detected tone. The algorithm was set up to detect 770Hz, > which is the frequency of the center burst. > > As you can see, this worked very well. The blue trace would have eventually > reached 1.0 if the center burst persisted. But clearly the center burst was > well detected and the other two were not, even though the frequencies > between adjacent tones differ by less than 11%. > > Below is the core code of the simulation. The complete code contains too > many distractions to show here, like CSV file writing and other logistics. > > for sampn := 0 to nsamp do begin {once for each input sample} > t := sampn * sampdt; {make time of this sample} > samp := getsamp (t); {get input sample} > r := t * freq; {make reference frequency phase} > ii := trunc(r); > r := r - ii; > r := r * pi2; > prods := samp * sin(r); {mix by ref freq sine and cosine} > prodc := samp * cos(r); > filter (filts, prods); {low pass filter mixer results} > filter (filtc, prodc); > magsq := sqr(filts.val) + sqr(filtc.val); {make square of magnitude} > magsq := magsq * 4.0; {normalize} > > Obviously you wouldn't normalize the result in the PIC, you'd adjust the > detection threshold instead. The FILTER subroutine does a two pole low pass > filter. Each pole has a filter fraction of 1/128, which means it can be > realized inside a PIC with a right shift of 7 bits. The input was sampled > and processed every 100uS. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. >

Marcel Birthelmer wrote: > - filter() looks something like 1/128 * getsamp(t) + 1/128 * getsamp(t > - sampdt) ? No, not really. Each filter pole uses the standard algorithm of FILT <-- FILT + FF(NEW - FILT) Where NEW is the input value being added to the filter, FILT is the filter being updated, and FF is the filter fraction. My filter used two such poles, each with a filter fraction of 1/128. > Or is it an IIR filter? Yes. > - What is the trunc() bit? It converts from floating point to integer by truncating the fraction part. For example, trunc(3.14) = 3. > A peculiarity of the arcane language (I'm > guessing fortran) you're using? It's a variant of Pascal. I was hoping the algorithm would be clear enough even if the syntax details weren't familiar. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Tamas Rudnai wrote: > I slightly remember that Olin was developing a Pascal compiler? Not a compiler, but I created a source to source translater long ago. On Windows I write in Pascal, convert that to C, compile the C, throw out the C, and keep the binary. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On Tue, Mar 30, 2010 at 9:34 PM, Olin Lathrop <olin_piclistKILLspamembedinc.com>wrote: > Tamas Rudnai wrote: > > I slightly remember that Olin was developing a Pascal compiler? > > Not a compiler, but I created a source to source translater long ago. On > Windows I write in Pascal, convert that to C, compile the C, throw out the > C, and keep the binary. > Sounds interesting. Would it work with PIC code too? Tamas > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -

Here's the equivalent in matlab: dt = 100e-6; %time interval t = 0:dt:250e-3; %sample steps freq1 = 697; freq2 = 770; freq3 = 853; %frequencies %below we generate the input signal in five steps sig(1:length(t)) = 0; sig(1:50e-3 / dt) = sin( 2*pi/freq1 * t(1:50e-3 / dt) ); sig(50e-3/dt : 100e-3/dt) = 0; sig(100e-3/dt : 150e-3/dt) = sin( 2*pi/freq2 * t(100e-3/dt : 150e-3/dt)); sig(150e-3/dt : 200e-3/dt) = 0; sig(200e-3/dt : 250e-3/dt) = sin( 2*pi/freq3 * t(200e-3/dt : 250e-3/dt)); k = 1/128; % filter constant f_a = [1 -2*(k-1) 1 ]; f_b = [ k^2 ]; %standardized filter coefficients for 2-pole filter mix_sin_in = sin(2*pi*freq2*t); %mixer input signals mix_cos_in = cos(2*pi*freq2*t); mixed_sin = mix_sin_in .* sig; %mixed signals mixed_cos = mix_cos_in .* sig; ff_sin = filter(f_b, f_a, mixed_sin); %do the filtering ff_cos = filter(f_b, f_a, mixed_cos); magsq = 4* ( ff_cos .^ 2 + ff_sin .^ 2; ) hold on plot(t, sig, 'r-'); plot(t, magsq, 'b-');

Tamas Rudnai wrote: >> Not a compiler, but I created a source to source translater long >> ago. On Windows I write in Pascal, convert that to C, compile the >> C, throw out the C, and keep the binary. > > Sounds interesting. Would it work with PIC code too? It could if there were a MPASM back end for it. The translator has completely independent front ends and back ends. The front end parses the input language and builds a description of the program in memory in language-independent structures. The back end then runs and writes the program in the output language from the data in memory. For the process described above, the Pascal front end and the C back end are used. It is theoretically possible to write a MPASM back end, but I haven't done that yet. One of the things in my mind as a background project is to not only write a MPASM back end that would use the conventions of my existing PIC development environment, but also create a front end for a language I'm calling M. This language is specifically targeted to small embedded systems where the assumptions of most compilers break down. For example, M inherently understands different address spaces each with its own data width and properties, it can be forced to bind certain elements to particular processor resources, etc. I'm also adding a few language constructs that I've always thought other higher level languages should have, like more flexible loop exiting. M has a preprocessor defined as part of the language spec. This is a lot more powerful than the C preprocessor. It's similar in concept to my existing MPASM preprocessor, PREPIC. The preprocessor is essentially a reasonably complete interpreted programming language that is run by the M compiler as a inherent part of its operation. While this is all nice to think about and occasionally I make a little progress, it's only one of many projects that would be nice to do but don't have any real priority. I can't way when, if ever, M will be available for use. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

----- Original Message ----- From: "Olin Lathrop" <.....olin_piclistKILLspam.....embedinc.com> To: "Microcontroller discussion list - Public." <EraseMEpiclistspam_OUTTakeThisOuTmit.edu> Sent: Wednesday, March 31, 2010 9:32 AM Subject: Re: [PIC] DTMF decoding {Quote hidden}> Tamas Rudnai wrote: >>> Not a compiler, but I created a source to source translater long >>> ago. On Windows I write in Pascal, convert that to C, compile the >>> C, throw out the C, and keep the binary. >> >> Sounds interesting. Would it work with PIC code too? > > It could if there were a MPASM back end for it. The translator has > completely independent front ends and back ends. The front end parses the > input language and builds a description of the program in memory in > language-independent structures. The back end then runs and writes the > program in the output language from the data in memory. > > For the process described above, the Pascal front end and the C back end > are > used. It is theoretically possible to write a MPASM back end, but I > haven't > done that yet. How about modifying your "C" generating back end to generate "C" for a PIC? -- Bob Ammerman RAm Systems

Bob Ammerman wrote: > How about modifying your "C" generating back end to generate "C" for > a PIC? That would be relatively easy since there is already a configuration file for the back and that can handle much of the difference between target compilers. A few changes to the source would probably be required to emit special pragmas and the like unique to the particular compiler. However, I don't see why I'd want to do that. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

On Wed, Mar 31, 2010 at 2:32 PM, Olin Lathrop <@spam@olin_piclistKILLspamembedinc.com>wrote: > While this is all nice to think about and occasionally I make a little > progress, it's only one of many projects that would be nice to do but don't > have any real priority. I can't way when, if ever, M will be available for > use. > It is nice, a very interesting subject. Is that open source -- or have you considered to release it as an open source project? Wouter's JAL made a very nice journey since it had released... Tamas > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -

Tamas Rudnai wrote: > It is nice, a very interesting subject. Is that open source -- or > have you considered to release it as an open source project? Wouter's > JAL made a very nice journey since it had released... There isn't much of anything to release one way or the other at this point. If/when I actually get something working, I'll probably release the source with little restriction. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.