Cheap PIC Frequency Counter Module (eBay / China)

[brian_mk]

I am building a 10Hz->100kHz low distortion audio oscillator and wanted to include a digital frequency counter.
In the past I have used the 10MHz Intersil ICM7216 but these devices have not been available for some time.
So I decided to try one of the PIC based digital counter module kits from eBay.
I believe these are cheap Chinese clones of an original design by Wolfgang Büscher.

After assembling and testing the kit I quickly reached the conclusion that they are rubbish!

Here are my findings:-

1) The counter turns itself off after 15 seconds if it detects no change in input frequency.
The description indicates that this power save feature is user configurable.
However, the firmware in my version does not appear to support the 'program mode' menu described
in Wolfgang Büscher's documentation.
The original firmware included a 'program mode' menu, entered by holding down the push button for a few seconds.
In the module I received, the button only appears to act as a reset.
Hence you cannot disable the power save feature and you cannot program frequency offsets.

See here for the original documentation:-
http://www.qsl.net/dl4yhf/freq_counter/freq_counter.html
and
http://akizukidenshi.com/download/ds/sainsmar/21-010-340.pdf

2) There is an apparent bug in the firmware which means that certain frequency ranges are displayed incorrectly.
If the input frequency exceeds f = 65535Hz (2^16-1), an internal 16bit counter overflows and the frequency is displayed as f - 65535.
This is completely wrong and makes it useless for my intended application.

3) The decimal point display is not as described in the firmware documentation:-

Frequency range  Display   Gate time    Decimal point
0 ... 9.999 kHz      X. XXXX  1 second     flashing (which means "kHz")
10 ... 99.99 kHz    XX.XXX   1/2 second  flashing
100 ... 999.9 kHz  XXX.XX   1/4 second  flashing
1 ... 9.999 MHz     X.XXXX   1/4 second  steady (which means "MHz")
10 ... 50.00 MHz   XX.XXX   1/4 second  steady

In my case, no decimal point is displayed until the frequency is above 1MHz.
There is no flashing decimal point.

4) The least significant 5th digit is noticeably brighter than the other 4 digits.
I think this is because the 5th digit is driven using a separate external transistor used as a 'nand' gate rather than being connected directly to the PIC output pins.
There are insufficient output ports available on the PIC to drive 5 digits directly. The resulting display looks pretty awful.

5) Despite the documentation indicating that the counter will operate down to 1Hz, the maximum resolution is only 16Hz.
If you feed a 10Hz TTL square wave and gradually increase the frequency, the display jumps in 16Hz steps. i.e. 16, 32, 48, 64 etc.
This also makes it unusable for my intended application.

In conclusion, don't buy these modules to use as a frequency counter. They are rubbish!
They might be good enough if you just want a cheap crystal tester.










 

[bd139]

They are a bit crap. I built one of these a few years ago. Works nicely and has some really cool features:

http://www.hamradio.in/circuits/freq_counter_lcd.php

Code needs modifying a bit if you use a 2 line display though. I built th 16f628a version and added a 2n4416 based follower in the front. This has protection circuitry stolen from the Heathkit IM-4100 in front of it. Used a 2n3866 instead of the 2n2222 to get more gain. Worked up to about 50Mhz

[John Heath]

I was thinking a pic frequency counter then rs232 the results over to a computer or blue tooth over to a cell phone. Now it is the best of both worlds. Mr Pic taking care of the nuts and bolts combined with the best display money can buy , flat screen monitor. Has anyone tried this? Pic to computer or cell phone?

[mino-fm]

Do you need to add offsets? Only PICs are allowed or even AVR?
Take a lock at this: https://www.eevblog.com/forum/projects/frequency-counter-project-61274/msg841889/#msg841889

[John Heath]

Do you need to add offsets? Only PICs are allowed or even AVR?
Take a lock at this: https://www.eevblog.com/forum/projects/frequency-counter-project-61274/msg841889/#msg841889

Liv in that thread link made a frequency counter that is the mouses ear with both reciprocal counting and the interpolator. A nice bit of work.

https://www.eevblog.com/forum/projects/diy-interpolating-frequency-counter-fc-510/

[bd139]

Just a point with the PIC vs AVR; the PICs tend to work quite happily up to 50MHz or so on the T0CKI pin even if it's a 4MHz part. Add a couple of 74F50109's up front and read them from spare IO pins and you're good to 180MHz or so native counting!

See http://www.vhfcomm.co.uk/Counter.pdf

[JanJansen]

They are a bit crap. I built one of these a few years ago. Works nicely and has some really cool features:

http://www.hamradio.in/circuits/freq_counter_lcd.php

With a 10Hz resolution its worthless for audio,
just use a PIC16 + 1602 LCD, you can program the T1G or something if i remember, its a build in frequency counter in PIC16, dont forget to use a crystal for accuracy.
btw my supersimple freq counter test project has numbers like 50.00 Hz, most freq counters has resolution of 1 Hz, its not good enough for audio.

His oscillator was from 10Hz to 100KHz.

[bd139]

It has 1Hz resolution. Just set the gate time to 1s. You could trivially add 10s gate time to it and get 0.1Hz resolution but most audio sources aren't stable enough for that.

[mino-fm]

Just a point with the PIC vs AVR; the PICs tend to work quite happily up to 50MHz or so on the T0CKI pin even if it's a 4MHz part.

An other simple way for reciprocal counters is to use a STM32F429-Discovery board. STM32 works quite happily too ;-)
From 0.05 Hz to 80 MHz you get 3 meas./s with 7 digits (f >= 3 Hz). Maybe some day I translate that stuff but take a look at the pictures and you can understand what's going on. http://mino-elektronik.de/FM_407/fmeter_407.htm#c1

[brian_mk]

I suspected that most of the problems I found were down to the PIC firmware.
I don't have a PIC programmer, but I gave the module to a friend of mine who does.
He downloaded the original counter2.hex from http://www.qsl.net/dl4yhf/freq_counter/freq_counter.zip and re-programmed the PIC.
Sure enough, all the problems I listed now appear to be fixed. 
Even the problem with the 5th digit appearing brighter has gone away.

I can only guess that some fool from China tinkered with the original software and completely screwed it up. 

The only issue I have now is that the longest gate time is 1 sec, which means the resolution is limited to 1 Hz even at low frequencies.
The 5th digit is blank for all frequencies below 10kHz.
It would be nice if the gate time could be extended to 10sec to get 0.1Hz resolution for frequencies below 100Hz.
The downside is that 10sec is a long time to wait when trying to set a frequency.
Ideally it needs a switch so that the user can manually select the gate time (This is the way the old Intersil ICM7216 chip worked).
Unfortunately, the PIC doesn't have enough inport ports for that.
Although not as convenient as a dedicated switch, now that the 'program mode' menus are working as they should, this could be made one of the user programmable options.

The original source code is available for download, so I could modify it myself (assuming the PIC has sufficient space available).
To do this I would need to buy myself a PIC programmer.
Can anyone recommend one?

Should I give negative feedback to the eBay supplier who is still selling this module with broken firmware?

[bd139]

There's no such thing as a decent PIC programmer unfortunately. As close as you can get is a  PICkit 3, but the price of those, you might as well buy a decent counter and throw the Chinese one in the trash.

[brian_mk]

I thought of a simple way to manually select higher resolution / longer gate times:-

Replace the existing push button that's used to select 'program mode' (connects 0v or +Vcc to PIC RA5 input) with a rotary switch that connects RA5 input to one of the multiplexed digit select outputs D1->D4.
That way, the PIC can determine up to 4 different switch positions.

[theHWcave]

Just saw the post. I have the same frequency counter kit and modified the firmware to get rid of the blank left-most digit (which is a bug IMHO) and the fact that the original firmware runs only at 2Hz resolution for anything between 11520Hz and 105.6KHz.  I also got rid of the  silly crystal test circuit and modified it to be a pre-amp for the counter instead.
The mod (firmware) is described here: https://youtu.be/8rOCmhPWLWw and the modified firmware is (and hex file) can be downloaded here:
https://github.com/TheHWcave/PIC-freq.counter-modification

[g0odp]

Thanks for the most interesting info. I too bought one of these 5 digit counters and found it completely useless, nothing worked apart from the 15 second time out and crystal measuring function. No menu selection and it wouldn't show anything when I input an rf signal from my HP sig genny!
I re-programmed a new pic with counter 1 and as you explained that didn't work, Counter2 improved the situation and I now get the menu but still no results from signals sent from my HP. Could you give a little more detail on the board modification you made to put a pre-amp stage in the counter.... that sounds a great idea.... and what sort of signal level can it now measure, how many millivolts? Thanks again, Paul, G0odp

[TechieTX]

If you want accuracy below ~1KHz (wild guess) you'd do better to flip over and measure the period of the waveform instead of a count of cycles.  Dunno if there's room in the PIC for that extra function, though.  As a plus, you don't need a 10sec gate to measure sub-Hz resolution at lower frequencies.

Yeah, I saw that design of Wolfgang, but wasn't interested due to the display limitations.  An LCD would be better, possibly a 1 or 2x16.  I've seen a few of those, but nothing as cheap as that LED design.

[horo]

Could you give a little more detail on the board modification you made to put a pre-amp stage in the counter.... that sounds a great idea....

Some time has passed, but for completeness:
https://github.com/TheHWcave/PIC-freq.counter-modification









And if you want to measure your mains frequency with 1mHz resolution:
https://github.com/Ho-Ro/DL4YHF-Source-Code

[theHWcave]

@horo, thanks for the links to my recent videos.
The latest version (hex file available on my github page)

A summary of the latest features:

Frequency:
  0..200Hz in 0.01 Hz resolution (using period mode)
  200Hz..  >100MHz  by using the prescaler somewhat differently. The range at least in all 4 examples I tested exceeds 110 MHz (this was measured by applying TTL-level square wave signal directly to the input pin (no pre-amp). The counter is now much more tolerant to measure short pulse widths.

Other available modes are:  RPM measurement and event counting

RPM: for example to add this as an RPM display to your lathe or drill press. It can process 1/2/3 or 4 pulses per revolution.

Event counter: for example to count turns when winding coils for transformers. Or, if fed with a 1 Khz signal, you can use it as a stopwatch with 1ms resolution.
Note: in event counting mode, pressing the button at any time resets the counter back to zero

The current mode is shown briefly at start-up (power-on).

If you hold the button at startup, it cycles through all modes,
just let go when the desired mode is shown. The new mode is then used as default.

Modes are:

Freq  = frequency (auto ranging)
RP=1  = RPM 1 pulse  per revolution up to 92100 RPM
RP=2  = RPM 2 pulses per revolution up to 92130 RPM
RP=3  = RPM 3 pulses per revolution up to 92140 RPM
RP=4  = RPM 4 pulses per revolution up to 92145 RPM
count = event counting up to 99999

[magic]

Best performance is achieved by combining direct and reciprocal counting plus using oversampling for linear interpolation.

I don't know if the PIC has enough timer resources for that, but some of mino-fm's counters implement this technique successfully on an ARM micro with a bit of jellybean logic thrown in. I made a proof of concept AVR port which achieved 6 or more digits from DC to Nyquist in a second or less, with no external components.

[horo]

... which achieved 6 or more digits from DC to Nyquist in a second or less ...

The PIC measures also 6 valid digits, but due to the limited port pin number of the chip only 5 LEDs can be multiplexed (and the 5th is already selected via discrete DTL NAND logic if none of the other 4 are active). My SW uses e.g. the 6th digit to round the displayed 5-digit value instead of just truncating. If someone considers a HW redesign a 3to8 decoder driving 6 (or 7) digits should be added, but for me the appeal of the device is that you get the basic HW as a cheap kit from China and can play with the SW.

[magic]

If I'm reading right, you have a dip in resolution to only 3~4 digits in the range 256~9999Hz. This middle range is exactly where it helps to simultaneously count input pulses and timestamp the first and the last of them, then you get the same resolution as with reciprocal counting at 1Hz or direct counting at 1MHz. I'm not familiar with PICs to tell if such approach is possible on this board.

[BrokenYugo]

@horo, thanks for the links to my recent videos.
The latest version (hex file available on my github page)

A summary of the latest features:

Frequency:
  0..200Hz in 0.01 Hz resolution (using period mode)
  200Hz..  >100MHz  by using the prescaler somewhat differently. The range at least in all 4 examples I tested exceeds 110 MHz (this was measured by applying TTL-level square wave signal directly to the input pin (no pre-amp). The counter is now much more tolerant to measure short pulse widths.

Other available modes are:  RPM measurement and event counting

RPM: for example to add this as an RPM display to your lathe or drill press. It can process 1/2/3 or 4 pulses per revolution.

Event counter: for example to count turns when winding coils for transformers. Or, if fed with a 1 Khz signal, you can use it as a stopwatch with 1ms resolution.
Note: in event counting mode, pressing the button at any time resets the counter back to zero

The current mode is shown briefly at start-up (power-on).

If you hold the button at startup, it cycles through all modes,
just let go when the desired mode is shown. The new mode is then used as default.

Modes are:

Freq  = frequency (auto ranging)
RP=1  = RPM 1 pulse  per revolution up to 92100 RPM
RP=2  = RPM 2 pulses per revolution up to 92130 RPM
RP=3  = RPM 3 pulses per revolution up to 92140 RPM
RP=4  = RPM 4 pulses per revolution up to 92145 RPM
count = event counting up to 99999

Neat, I have one of these kits in the to do pile, came with an empty PIC, I think I'll fill it with this firmware.

[theHWcave]

No, at least not in my firmware.
It uses period measurement in the range from 0 to 200 Hz allowing a resolution of 0.01Hz (5 digits remember?). I put this mode in mainly because the RPM measurements are all in that low freq. range and without it the RPM resolution would be horrible. It was a struggle to get to 200 Hz period measurement with the way the software is designed originally and I did not want to rewrite it from scratch. From 200 Hz onwards to 105.6 KHz the gate time is 1s, resolution is 1 Hz but of course beyond 99999Hz, the display resolution drops to 10Hz.  The measurement resolution is 2Hz all the way from 105.6 to 983Hz even though the display cant show it. As a principle I try to maintain the highest possible resolution even if it can't show all the digits, because it still has an effect when last visible digit changes...

[horo]

If I'm reading right, you have a dip in resolution to only 3~4 digits in the range 256~9999Hz.

You're right, TheHWcave's SW (as well as mine, that is based on him) counts the pulses above 200 (or 256 for me) for 1 s => display "_0.256" ... "_9.999" with a blank left digit, giving 3 or 4 valid digits.

This middle range is exactly where it helps to simultaneously count input pulses and timestamp the first and the last of them, then you get the same resolution as with reciprocal counting at 1Hz or direct counting at 1MHz. I'm not familiar with PICs to tell if such approach is possible on this board.

Well, let me make a quick'n'dirty assumption...

Code: [Select]

;--------------------------------------------------------------------------
; Count pulses, fed with the number of loop iterations for the gate time .
;               WHILE counting, the multiplexed LED display is updated .
;               Watchdog is fed in this loop !
; Input:    Count of gate-time-loops in 'gatecnt_hi'+'gatecnt_lo' (16 bit).
; Returns:  The number of pulses in 20us increments
;           The number of periods measured (in pcnt)               (added TheHWcave )
;           the sum of all measured periods in 20us increments     (added TheHWcave )
;           in t0dark the number of pulses tmr0 counted outside this routine (added TheHWcave )
;           in t0last the last value of tmr0 when leaving this routine (added TheHWcave )
;--------------------------------------------------------------------------

If you count frequency N Hz for 1 second you will get N counts and also N-1 in "pcnt" with a total length in "period", aaa+zzz is the uncounted reminder:
 

Code: [Select]

|<------------ 1 second ----------->|
|aaa↗11111↗22222↗33333↗...↗_n-1_↗zzz|
1st   P1    P2    P3        Pn-1 last

999.5 Hz -> freq = 999, pcnt = 998, period = 49925 or freq = 1000, pcnt = 999, period = 49975
1000 Hz -> freq = 1000, pcnt =  999, period = 49950 
1000.5 Hz -> freq = 1000, pcnt = 999, period = 49925 or freq = 1001, pcnt = 1000, period = 49975
1001 Hz -> freq = 1001, pcnt = 1000, period = 49950
The difference between 50000 (GATE_TIME_LOOPS) and period is a measure for the frequency deviation from the integer value N and could be used to correct the value (with no big math overhead?)

@TheHWcave, you're the SW guru, what's your opinion?

BTW: Shouldn't the discussion about SW improvement take place in the right location:
https://github.com/TheHWcave/PIC-freq.counter-modification

Martin

[theHWcave]

@Martin,
Well, I don’t really use Github as a blog for discussions. Maybe this should instead be moved to the software related section of the EEVblog?  No idea how to do that apart from creating a new topic.

In the mean time and just to put minds at rest...  The comment you quote is true but only applies in the range below 2Hz.  Let me explain:

The basic restriction is that the PIC is edge triggered. You can select whether you want the rising or falling edge initially during setup but that is it. The original frequency counter simply counted the number of edges within the gate time (e.g. 1s). For RPM measurements that is way to coarse, so I implemented a reciprocal measurement of the period at low frequencies.  In that mode, my software needs to see at least 2 (say falling) edges = 1 period within the measurement time which is 1 second as the longest gate time used for very low frequencies. That condition is only guaranteed if the frequency is >= 2Hz, hence at frequencies below 2Hz to 1Hz the display flips between showing the correct value, e.g. 1.23Hz and 1Hz, depending if 1 or 2 falling edges were detected within the measurement period. The closer you get to 1Hz the more likely is it that you just see 1 instead of 1.xx. From 1Hz and below you just see zero. This is what the comment meant. It starts working from 1Hz onward but for a fully steady display you need 2Hz or more.

If the frequency is above 1Hz and below 200Hz, reciprocal measurement is used where my software measures the time from the start of the first period all the way to end of the last full period within the measurement period, and counts the number of full periods, it saw. Example, at 50.123Hz, a period is 19.95ms and 49 full periods fit into 1 second, So the total accumulated time measured would be 0.9775s. 49 would then be divided by this to get the frequency.  Crucially these are not 49 separate measurements where each could be affected by missing an edge. Instead this is is one continuous measurement period and all edges are detected. 

In reality, the time within this software is measured in 20us increments and is stored as a 16bit integer. So 0.9775s equates to the value of 48879. This simplification introduces an error of up to 20us. The poor 8-bit PIC is then doing a 32-bit multiplication of 49 * 50000*1000 and then divides that huge number in another 32-bit operation by 48879 to get the result of 50123. This is the frequency in milliHertz which is then rounded to 2 decimals and shown as 50.12Hz. Should the PIC see only 48 instead of 49 full periods, because of just missing the first edge, it simply uses the values for 48 periods and comes to the same result.  Its slightly more complex than that but in principle this is how things work.

This algorithm works up to 255Hz but I decided to draw the line at 200Hz and switch back to the original mode, because in reciprocal mode the accuracy gets rapidly worse the higher the frequency because the 20us is just too coarse for measuring smaller periods. Sadly changing the 20us inherited from the original firmware without a complete redesign of the software is not possible.

I never considered extending the counter the other way, i.e.  below 1Hz operation. The only way to do that would be to extend the gate time / measurement time. That would be fairly easy but having to wait 10 or 100s for each display update seems not very useful.

[cdev]

I have the other PIC frequency counter , best known as the PLJ-8LED

This one https://www.zl2pd.com/files/PLJ-8LED_Manual_Translation_EN.pdf and I wpuld love to be able to use it with my 10 MHz gpsdo frequency standard. Making that connection to allow PLJ-8LED users to have accuracy to 1 hz would be a huge thing that would help a lot of people.
Because the 8 digit PIC counter is very popular.  Here are two  videos about this device:

I am building a 10Hz->100kHz low distortion audio oscillator and wanted to include a digital frequency counter.
In the past I have used the 10MHz Intersil ICM7216 but these devices have not been available for some time.
So I decided to try one of the PIC based digital counter module kits from eBay.
I believe these are cheap Chinese clones of an original design by Wolfgang Büscher.

After assembling and testing the kit I quickly reached the conclusion that they are rubbish!

Here are my findings:-

1) The counter turns itself off after 15 seconds if it detects no change in input frequency.
The description indicates that this power save feature is user configurable.
However, the firmware in my version does not appear to support the 'program mode' menu described
in Wolfgang Büscher's documentation.
The original firmware included a 'program mode' menu, entered by holding down the push button for a few seconds.
In the module I received, the button only appears to act as a reset.
Hence you cannot disable the power save feature and you cannot program frequency offsets.

See here for the original documentation:-
http://www.qsl.net/dl4yhf/freq_counter/freq_counter.html
and
http://akizukidenshi.com/download/ds/sainsmar/21-010-340.pdf

2) There is an apparent bug in the firmware which means that certain frequency ranges are displayed incorrectly.
If the input frequency exceeds f = 65535Hz (2^16-1), an internal 16bit counter overflows and the frequency is displayed as f - 65535.
This is completely wrong and makes it useless for my intended application.

3) The decimal point display is not as described in the firmware documentation:-

Frequency range  Display   Gate time    Decimal point
0 ... 9.999 kHz      X. XXXX  1 second     flashing (which means "kHz")
10 ... 99.99 kHz    XX.XXX   1/2 second  flashing
100 ... 999.9 kHz  XXX.XX   1/4 second  flashing
1 ... 9.999 MHz     X.XXXX   1/4 second  steady (which means "MHz")
10 ... 50.00 MHz   XX.XXX   1/4 second  steady

In my case, no decimal point is displayed until the frequency is above 1MHz.
There is no flashing decimal point.

4) The least significant 5th digit is noticeably brighter than the other 4 digits.
I think this is because the 5th digit is driven using a separate external transistor used as a 'nand' gate rather than being connected directly to the PIC output pins.
There are insufficient output ports available on the PIC to drive 5 digits directly. The resulting display looks pretty awful.

5) Despite the documentation indicating that the counter will operate down to 1Hz, the maximum resolution is only 16Hz.
If you feed a 10Hz TTL square wave and gradually increase the frequency, the display jumps in 16Hz steps. i.e. 16, 32, 48, 64 etc.
This also makes it unusable for my intended application.

In conclusion, don't buy these modules to use as a frequency counter. They are rubbish!
They might be good enough if you just want a cheap crystal tester.