TONE DETECTOR WITH PIC12F683/PIC12F1840

[AlbertoFS]

TONE DETECTOR WITH PIC12F683/PIC12F1840

It has not been straightforward to carry out this project. Because ideas only come little by little as they are found issues.
This has been more of a good exercise to see if I could perform a tone detector with an 8-pin PIC.
I have a larger project with a PIC18F25K20 that has been stopped for a long time. With the Having gained experience, I will be able to finish it and make a much more elaborate tone detector.
I have dedicated a lot of time in making this code and a simple and practical documentation so that Positron users can
understand the complexity of Goertzel filters. I had to calculate tens of coefficients with the manual calculator that
produced smoke, because I haven't used Excel in a long time, and I have forgotten it.
This codes could be a starting point for your new projects.

You will find some theoretical documentation explaining the concepts of Goertzel filters.

I present 2 projects:
The first with a PIC12F683 whose programming is classic according to Goertzel's laws.
And it's not very efficient, but it can detect frequencies from 100Hz to 500Hz at a step of 50Hz, because the code runs
slowly.

The second with a PIC12F1840 whose programming is a little more elaborated, allows us to obtain a quite acceptable result;
being able detect frequencies from 100Hz to 1100Hz at a step of 50Hz.
Due to the tricks used, this tone detector could be made with continuously variable clock frequency with the help of a DDS.

In addition, I attach a simulation with the Proteus and a PIC18F25K20 that allows us to calculate and test
the Sine/Cosine parameters of the target frequency before mounting them on the smaller PIC.
It could be improved even further by using a new 8-pin PIC with 512 Bytes of RAM and reading 120 samples.

The code has been optimized line by line and uses some compiler variables (take care). However, all compilation options
are included. The user will only have to choose them to play with the code.

In the "DOC" folder, you will find of decoder schematic with amplitude limiter and low pass filter necessary for this
application (tested only by Proteus).
Good luck.

Update Tone Detector Version 2: Date 17/04/2024

Fixed errata with the PIC12F683 ADC (Device ID number 3). With right justified the high bytes of the ADRESH register was at 1, sometimes.
Fixed error with the PIC12F1840 for the definition of the 500Hz parameters.
Added an improvement to the simulation.
Added an attempt to make a CTSS detector for 91.5Hz and 100Hz. It should be tested in real world.

[top204]

Many thanks Alberto.

It's nice that you have found out how important the new Declare Auto_Variable_Bank_Cross can be. OK, it does increase the RAM used a little, but it can speed up a program's operation quite a bit, if it is using quite a bit of RAM. It also, sometimes, allows less code memory space to be used because there will not be as many RAM bank changes and extra code to cater for the different RAM banks.

This is because of the fragmented RAM in PIC devices, and the small RAM bank sizes, and the need for RAM bank switching when a multi-byte variable is crossing a RAM bank with its byte pieces.

[John Drew]

Great project Alberto.
I wonder how long it takes to detect 100Hz ?
A big problem in recent times is to obtain decoders for CTCSS.
It seems  that devices with a CTCSS function now have that function built into the main processor.
Speed of recognition is important.
Good luck with the projects.
John

[AlbertoFS]

Hi John,
I have not been able to carry out practical measures due to lack of means. But I have carried out measurements within the PIC that give the following results. The response time would be valid if the input signal corresponds to the start of the Timer. Which is impossible to happen. Then The results must be multiplied by 2.

PIC12F683 => 1 execution block for 80 samples = 29,9mS.
PIC12F683 => 1 execution block for 50 samples = 19,2mS.
PIC12F1840 => 1 execution block for 40 samples = 37,9mS.

There is more data in the program.
I have thought about writing a code to synchronize the input signal with the start of the block, which would give an almost always identical response time. In a few days.
Greetings

[John Drew]

Hi Alberto,
All noted. Have you read ZL2PD web page on CTCSS decoders?
He makes some interesting points and has a non PIC solution but his code is not shared.
Some years back Les shared code for a tone decoder but it worked best at the higher frequencies. I think the project is on his website.
I'm on my phone at present but I think I have it on my computer and will have a look tomorrow. It's 23:30 here. Time for bed.
John

[top204]

The problem with detecting such low frequencies, is the time it takes to actually sample them using an ADC. For example, the FFT routines I wrote work in about 1ms when using 32 blocks for simple frequency checking, but the sampling of low frequencies to fill, even a small array, takes about 15ms to perform.

I'm sure there would be a way of sampling using an interrupt and double buffer, so the detection was within a millisecond or so, but that is another story (and piece of future code to be written). I did something similar with the FFT routines on the dsPIC33 devices, where it samples using an interrupt then calls the FFT and it all operates within microseconds.

I tried the FFT routines to detect 100Hz, and it worked quite well when using only 32-blocks so the FFT is super fast, but it will detect from approx 50Hz to 150Hz as a 100Hz tone because of the low FFT block resolution. So I will try Alberto's code and see what it does.

[John Drew]

I can see why Alberto chose an 8 pin chip - size is important but not so much as the two important criteria of speed of lock 50ms max and resistance to noise and voice.
I know Alberto is aware of this as a radio amateur.
If it was necessary to use a 28pin 16 bit chip running at 120MHz then so be it. If only they still manufactured the FX365 in SM it would solve the problem as they work well.

My interest is in the controllers  for amateur 146MHz and 435MHz repeaters - especially the 2M band as there are increasing problems with all kinds of interference in recent years. CTCSS is an effective solution in most cases.
John

[AlbertoFS]

Hi John,
I just updated the project, because I found some errors. Additionally, I took the opportunity to add an attempt to make a CTCSS decoder that you could try with a transceiver.

In my old project carried out with a PIC18F25K20 with a clock of 80Mhz, I had been able to detect the Morse tone at a speed of more than 20 PWM. I think it could be a solution if the code I have made with the 8-pin PICs does not work.
Greetings

[top204]

Excellent news Alberto.

The enhanced 14-bit core devices are a lot slower than the 18F types, not just because they do not run as fast, but their architecture is not as efficient as those on 18F devices.

If possible, try the new 18FxxQ4x devices because they now come in small 14-pin packages and have plenty of RAM and flash and peripherals, and operate nicely (but unofficially) up to 88MHz if required. They are the newer devices I added to the 4.0.4.0 upgrade.

[keytapper]

and operate nicely (but unofficially) up to 88MHz if required

What about 20MHz quartz and PLL on, wouldn't it work?