Cheap PIC Frequency Counter Module (eBay / China) - Page 1
Forum section: electronics / projects

author: brian_mk
author_rank: Regular Contributor
timestamp: February 11, 2018, 02:27:10 pm
content: 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 describedin 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.htmlandhttp://akizukidenshi.com/download/ds/sainsmar/21-010-340.pdf2) 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 point0 ... 9.999 kHz X. XXXX 1 second flashing (which means "kHz")10 ... 99.99 kHz XX.XXX 1/2 second flashing100 ... 999.9 kHz XXX.XX 1/4 second flashing1 ... 9.999 MHz X.XXXX 1/4 second steady (which means "MHz")10 ... 50.00 MHz XX.XXX 1/4 second steadyIn 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.

author: bd139
author_rank: Super Contributor
timestamp: February 11, 2018, 02:34:12 pm
content: 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.phpCode 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

author: John Heath
author_rank: Frequent Contributor
timestamp: February 11, 2018, 03:17:58 pm
content: 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?

author: mino-fm
author_rank: Regular Contributor
timestamp: February 11, 2018, 03:26:18 pm
content: 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

author: John Heath
author_rank: Frequent Contributor
timestamp: February 11, 2018, 03:43:57 pm
content: Quote from: mino-fm on February 11, 2018, 03:26:18 pmLiv 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/

author: bd139
author_rank: Super Contributor
timestamp: February 11, 2018, 03:59:12 pm
content: 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!Seehttp://www.vhfcomm.co.uk/Counter.pdf

author: JanJansen
author_rank: Frequent Contributor
timestamp: February 11, 2018, 04:01:04 pm
content: Quote from: bd139 on February 11, 2018, 02:34:12 pmWith 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.

author: bd139
author_rank: Super Contributor
timestamp: February 11, 2018, 04:22:08 pm
content: 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.

author: mino-fm
author_rank: Regular Contributor
timestamp: February 11, 2018, 08:24:42 pm
content: Quote from: bd139 on February 11, 2018, 03:59:12 pmAn 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

author: brian_mk
author_rank: Regular Contributor
timestamp: February 19, 2018, 03:34:51 pm
content: 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 fromhttp://www.qsl.net/dl4yhf/freq_counter/freq_counter.zipand 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?

author: bd139
author_rank: Super Contributor
timestamp: February 19, 2018, 04:26:05 pm
content: 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.

author: brian_mk
author_rank: Regular Contributor
timestamp: February 19, 2018, 06:04:50 pm
content: 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.

author: theHWcave
author_rank: Regular Contributor
timestamp: March 29, 2018, 01:56:32 pm
content: 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/8rOCmhPWLWwand the modified firmware is (and hex file) can be downloaded here:https://github.com/TheHWcave/PIC-freq.counter-modification

author: g0odp
author_rank: Newbie
timestamp: April 07, 2018, 01:34:25 pm
content: 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

author: TechieTX
author_rank: Contributor
timestamp: April 09, 2018, 02:39:53 am
content: If you want accuracy below ~1KHz (wild guess) you'd do better to flip over and measure theperiodof 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.

author: horo
author_rank: Regular Contributor
timestamp: March 10, 2021, 12:07:34 pm
content: Quote from: g0odp on April 07, 2018, 01:34:25 pmSome time has passed, but for completeness:https://github.com/TheHWcave/PIC-freq.counter-modificationAnd if you want to measure your mains frequency with 1mHz resolution:https://github.com/Ho-Ro/DL4YHF-Source-Code

author: theHWcave
author_rank: Regular Contributor
timestamp: March 18, 2021, 10:38:05 pm
content: @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.. >100MHzby 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 countingRPM: 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 zeroThe 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 RPMRP=2 = RPM 2 pulses per revolution up to 92130 RPMRP=3 = RPM 3 pulses per revolution up to 92140 RPMRP=4 = RPM 4 pulses per revolution up to 92145 RPMcount = event counting up to 99999

author: magic
author_rank: Super Contributor
timestamp: March 19, 2021, 08:42:29 am
content: 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.

author: horo
author_rank: Regular Contributor
timestamp: March 19, 2021, 11:37:05 am
content: Quote from: magic on March 19, 2021, 08:42:29 amThe 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.

author: magic
author_rank: Super Contributor
timestamp: March 19, 2021, 12:15:25 pm
content: 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.

author: BrokenYugo
author_rank: Super Contributor
timestamp: March 19, 2021, 07:43:49 pm
content: Quote from: theHWcave on March 18, 2021, 10:38:05 pmNeat, 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.

author: theHWcave
author_rank: Regular Contributor
timestamp: March 19, 2021, 07:57:54 pm
content: 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...

author: horo
author_rank: Regular Contributor
timestamp: March 21, 2021, 10:57:51 am
content: Quote from: magic on March 19, 2021, 12:15:25 pmYou'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.Quote from: magic on March 19, 2021, 12:15:25 pmWell, let me make a quick'n'dirty assumption...Code:;--------------------------------------------------------------------------; 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:|<------------ 1 second ----------->||aaa↗11111↗22222↗33333↗...↗_n-1_↗zzz|1st P1 P2 P3 Pn-1 last999.5 Hz -> freq = 999, pcnt = 998, period = 49925 or freq = 1000, pcnt = 999, period = 499751000 Hz -> freq = 1000, pcnt = 999, period = 499501000.5 Hz -> freq = 1000, pcnt = 999, period = 49925 or freq = 1001, pcnt = 1000, period = 499751001 Hz -> freq = 1001, pcnt = 1000, period = 49950The 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-modificationMartin

author: theHWcave
author_rank: Regular Contributor
timestamp: March 21, 2021, 11:13:52 pm
content: @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.

author: cdev
author_rank: Super Contributor
timestamp: March 21, 2021, 11:34:29 pm
content: I have the other PIC frequency counter , best known as the PLJ-8LEDThis onehttps://www.zl2pd.com/files/PLJ-8LED_Manual_Translation_EN.pdfand 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:Quote from: brian_mk on February 11, 2018, 02:27:10 pm

author: horo
author_rank: Regular Contributor
timestamp: March 22, 2021, 12:35:00 pm
content: Quote from: theHWcave on March 21, 2021, 11:13:52 pmOk, let's keep the discussion here as it is really covered by "Projects, Designs, and Technical Stuff".I see the limitation below 2 Hz, but this was not my idea. Instead I want to understand how you solved it in the higher Hz ranges. You explained your reciprocal measurement with an example for 50.123 Hz:Quote from: theHWcave on March 21, 2021, 11:13:52 pmMaybe we can reuse some of your effort, so let me put my thoughts step by step:- If you measure e.g. 1000.0 Hz for one second (i.e. 50000 ticks of 20 µs) then you will get a period length of 1000 µs and 999 full periods.Total accumulated period time is 999000 µs, giving 49950 ticks, the reminder to the 50000 ticks (=1 second) is 50 ticks.- If you measure e.g. 1000.1 Hz then you will get a period of 999.9 µs and 999 full periods.Total accumulated period time is 998900 µs, giving 49945 ticks, reminder 55.- If you measure e.g. 1000.2 Hz then you will get a period of 999.8 µs and 999 full periods.Total accumulated period time is 998800 µs, giving 49940 ticks, reminder 60.So the reminder to the full 1 second period of 50000 ticks increases with increasing sub-Hz frequency.IIRC this 499xx value (the full period tick sum) is always available even for higher frequencies.All we have to do is to calculate the length of one period (in ticks), in my 1000 Hz example i.e. 50 ticks.This value is calculated by "one_period = 50000 / int( frequency )"And if you calculate finally "x = reminder - one_period" you will get x = 0, 5, 10, 15,... i.e. 1/50 Hz resolution.Same calculation for 2000,x Hz gives 0, 3, 5, 8, 10,... so even in higher ranges we have the possibility to get down to 0.1 Hz resolution.For 9999 Hz the resolution drops to 0.2 Hz.But in the range 200..999 Hz we could for sure get one valid decimal digit.Quote from: theHWcave on March 21, 2021, 11:13:52 pmI totally agree!

author: horo
author_rank: Regular Contributor
timestamp: March 24, 2021, 04:11:26 pm
content: I had some time to think about my proposal:Quote from: horo on March 22, 2021, 12:35:00 pmMy idea so far:Check resolution extension for DL4YHF – Range 200..2500 HzCalculate number of "deci-periods" as correction sum and add it to 10 * pcnt -> result = 10*freqThe calculation does not exceed the uint16_t range (for the targeted frequency range 200..2500)Input (integer values)total (50000 ticks)pcnt (total number of full periods)sum_of_p (cumulated length of all full periods, measured in ticks)Calculation (expressed in meta-language)reminder = total – sum_of_p; // length of not fully captured periods before and after pcnttmp = reminder/2 * freq + 1250;// divide reminder by two to keep the product below 65535, prepare roundingcorrection = tmp / 2500; // rounded number of additional deci-periodsresult = 10 * pcnt + correction; // total number of deci-periods per second = frequency in deci-hertzNOPE!I looked again into the source and saw your comments as well as the code:Code:;Note 2: This method could create a pcnt that can get too high for the subsequent 32-bit maths;Therefore there is a check to stop accumulating periods and incrementing pcnt if; 80 (in frequency mode) or 140 (in RPM) mode is reached...;; check if pcnt has reached maximum. If yes, don't add amy further periods;...goto P_done ; [64+1] stop if pcnt >= 80 (freq) or >= 140 (rpm)So my idea does not work unless I add a 2nd 16-bit period accumulator and a 2nd 16-bit period counter without compromising the loop timing -> shifted to low priority.Nevertheless I'm happy with 1 Hz resolution for 256..99999 Hz and the increased resolution below.

author: horo
author_rank: Regular Contributor
timestamp: March 27, 2021, 08:59:01 pm
content: Next try, at least the range 256.0 .. 999.9 got 1 decimal digit:https://github.com/Ho-Ro/DL4YHF-Source-Code/commit/7d89af60f1ee40d7922c779da5db1bbfb0862f31Remarks?

author: theHWcave
author_rank: Regular Contributor
timestamp: March 28, 2021, 01:34:54 pm
content: I understand what you mean and agree that this would be great, but unfortunately The PLJ-8LED needs a 13 MHz clock, so a simple 10 MHz GPSDO wont be any good. Also, simple GPS-derived frequency standards don't actually adjust a local oscillator, instead they contain a programmable divider that is normally set to produce the 1Hz aka 1PPS signal. Popular GPS chips like the NEO 7N for example allow you to set the divider to anything you like to change the 1PPS signal to 10 MHz for example. You can also set it to 13 MHz although that is actually outside the spec. The problem is that in the case of the NEO 7N (and probably similar chips) that frequency is full of jitter. If you set it to 10 MHz, you get a precise 10 million pulses in exactly 1 second, in other words 10 MHz, but the width of each pulse is not a constant 50ns, instead some are only 41ns and others 62ns. This happens only at some frequencies, unfortunately 10MHz (and 13 MHz) are such frequencies. I made an investigation about this here:Those GPS-based references are still very useful to verify the accuracy of counters. A properly aligned counter should show exactly 10.000.000 because it gets exactly 10 million pulses per second. The fact that the pulses have different length does not matter. However, I don't think using such a signal as a clock would be very good. The alternative would be a proper GPSDO that uses a PLL to adjust a local TCXO. The mini GPS ref. clock from Leo Bodnar is such a thing that can produce a very accurate and clean signal from 400Hz to 800 MHz. I have one of these and it works very well, but I have not tried using it to replace the oscillator in the PLJ-8LED. To be honest, I don't use the PLJ-8LED much because its horrible pre-amps mangle any input signal all the way to the source so inserting it to measure frequency in a circuit usually means that that circuit stops working or behaves strangely.

author: cdev
author_rank: Super Contributor
timestamp: March 28, 2021, 10:25:43 pm
content: Quote from: theHWcave on March 28, 2021, 01:34:54 pmIS IT REALLY THAT BAD???Quote from: theHWcave on March 28, 2021, 01:34:54 pmI have one of these and it works very well, but I have not tried using it to replace the oscillator in the PLJ-8LED. To be honest, I don't use the PLJ-8LED much because its horrible pre-amps mangle any input signal all the way to the source so inserting it to measure frequency in a circuit usually means that that circuit stops working or behaves strangely.

author: cdev
author_rank: Super Contributor
timestamp: March 28, 2021, 10:49:08 pm
content: What is the music you're playing near the end? Its perfect for this subject matter.

author: horo
author_rank: Regular Contributor
timestamp: March 30, 2021, 09:16:47 am
content: Quote from: theHWcave on March 28, 2021, 01:34:54 pmThe NEO manual restricts possible frequencies. They shall be even divisions of 48 MHz and shall be < 24 MHz, so 12, 8, 6, 4, 3, 2, 1 MHz are quite free of jitter, as well as 4.8, 2.4, 1.2 and 0.96 MHz; I used the last one to calibrate my DL4YHF with origial FW, because the last digit (=10 Hz) was almost exact to 10 ppm. Now I use the "calibration zoom" function of my own FW to come down to 1 ppm (short term).Also some NEO modules (e.g. the NEO-M8N I use) provide a TCXO as system clock that gives quite stable output even without GPS-lock.

author: beanflying
author_rank: Super Contributor
timestamp: March 30, 2021, 09:28:10 am
content: Slightly randomly I just finished a case for my cheapy and the filter material for the poorly chosen Blue LED arrived yesterday. I did tweak it a while ago against my GPSDO as is the Siglent. I gave them both a good warmup yesterday and ran the Siglent from 30Meg down across a range to about 100k. Worst case was 1-2 counts off the Siglents set point.There is a problem with the Neo GPSDO chips they have horrid jitter unless you pick off certain multiples. My quoted post below.EDIT SNAP to HoroPost herehttps://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/msg2246022/#msg2246022Quote

author: theHWcave
author_rank: Regular Contributor
timestamp: April 02, 2021, 10:21:11 pm
content: @cdev:All music tracks came from the YouTube - copyright-free music library. I'm not sure which piece you mean but the tracks used were "Ether", "Stale Mate" and "Procession" (not necessarily in that order).Hope that helps

author: theHWcave
author_rank: Regular Contributor
timestamp: April 02, 2021, 10:39:20 pm
content: Yes, this matches my findings (as in that video). All frequencies that produce a whole integer when 24 MHz is divided by that frequency are jitter free. At very low <=100 KHz or so, it does not matter too much because any jitter, if it occur, is is very small. But for example 10 MHz jitters between 8 and 12 MHz.No good to be used as a replacement for a 10 MHz xtal time-base, but as a frequency standard connected to the input of the counter for testing accuracy, it is still ok, even with jitter, because when selecting 10 MHz, the number of pulses per second delivered by the NEO 7N is exactly(*) 10,000,000 and this is what a frequency counter actually measures.(*) limited to GPS accuracy of course.

author: JimRemington
author_rank: Regular Contributor
timestamp: April 11, 2021, 11:02:15 pm
content: I had a use for the basic kit and wondered how hard it would be to get my old PIC stuff working again, so I bought a couple on eBay. It was a surprisingly pleasant experience, and I was astonished to discover that MPLAB8 still works with my ancient PICSTART PLUS programmer!The free XC8 compiler associated with MPLABX supports the 16F628A, so here is a simple XC8 program that simply counts up and displays a 16 bit number.The code leaves two pins (RA5 and RA4) free for I/O, which plenty to allow the module to be used as a dedicated 5 digit, 7 segment display. I borrowed the definitions in the frequency counter assembly code to drive the segments.Demo program:Code:#include <stdint.h> /* For uint8_t definition */#include <stdbool.h> /* For true/false definition */// display data bufferunsigned char digits={0};// digit drive table (left=0 to right=4)unsigned char digit_drive={0x07, 0x0B, 0x0E,0x0D,0x0F};// digit drive table (right=0 to left=4)// unsigned char digit_drive={0x0F,0x0D,0x0E,0x0B,0x07};// bitmask for segment A , etc ..#define _A 0x40#define _B 0x80#define _C 0x04#define _D 0x01#define _E 0x08#define _F 0x10#define _G 0x20#define _DP 0x02#define BLANK_PATTERN 0// blank display pattern (7-segment code)//translate to seven-segmentsunsigned char symb[] ={(_A+_B+_C+_D+_E+_F ), // ABCDEF. = '0' ( # 0 )( _B+_C ), // .BC.... = '1' ( # 1 )(_A+_B +_D+_E +_G), // AB.DE.G = '2' ( # 2 )(_A+_B+_C+_D +_G), // ABCD..G = '3' ( # 3 )( _B+_C +_F+_G), // .BC..FG = '4' ( # 4 )(_A +_C+_D +_F+_G), // A.CD.FG = '5' ( # 5 )(_A +_C+_D+_E+_F+_G), // A.CDEFG = '6' ( # 6 )(_A+_B+_C ), // ABC.... = '7' ( # 7 )(_A+_B+_C+_D+_E+_F+_G), // ABCDEFG = '8' ( # 8 )(_A+_B+_C+_D +_F+_G), // ABCD.FG = '9' ( # 9 )(_A+_B+_C +_E+_F+_G), // ABC.EFG = 'A' ( # 10 )( _C+_D+_E+_F+_G), // ..CDEFG = 'b' ( # 11 )( _D+_E +_G), // ...DE.G = 'c' ( # 12 )( _B+_C+_D+_E +_G), // .BCDE.G = 'd' ( # 13 )(_A +_D+_E+_F+_G), // A..DEFG = 'E' ( # 14 )(_A +_E+_F+_G), // A...EFG = 'F' ( # 15 )(_A +_C+_D+_E+_F ), // A.CDEF. = 'G' ( # 16 )( _B+_C +_E+_F+_G), // .BC.EFG = 'H' ( # 17 )( _E ), // ....E.. = 'i' ( # 18 )(BLANK_PATTERN ), // ....... = ' ' ( # 19 )(0xFF ), // all segments on ( # 20 )(_A+_B +_E+_F+_G), // AB..EFG = 'P' ( # 21 )( _E +_G), // ....E.G = 'r' ( # 22 )( _C+_D+_E +_G), // ..CDE.G = 'o' ( # 23 )(_A+_B+_C +_F+_G), // ABC..FG = 'Q' ( # 24 )( _C+_D+_E ), // ..CDE.. = 'u' ( # 25 )( _D+_E+_F+_G), // ...DEFG = 't' ( # 26 )(_A +_C+_D +_F+_G), // A.CD.FG = 'S' ( # 27 )(_A+_B +_D+_E +_G), // AB.DE.G = 'Z' ( # 28 )( _E+_F ), // ....EF. = 'I' ( # 29 )( _B+_C+_D ), // .BCD.. = 'J' ( # 30 )( _D+_E+_F+_G), // ...DEFG = 'k' ( # 31 )( _D+_E+_F ), // ...DEF. = 'L' ( # 32 )(_A+_B+_C +_E+_F ), // ABC.EF. = 'N' ( # 33 )( _C+_D+_E+_F ), // ..CDEF. = 'V' ( # 34 )( _D +_G), // ...D..G = '=' ( # 35 )};/******************************************************************************//* Main Program *//******************************************************************************/#define _XTAL_FREQ 20000000#include <xc.h>unsigned int counter=0;// separate out the digits of "counter" into display buffervoid update_display(void) {digits = counter%10;digits = (counter/10)%10;digits = (counter/100)%10;digits = (counter/1000)%10;digits = counter/10000;}void main(void) {TRISB = 0; //RB as OutputPORTB = 2; //turn on DPTRISA = 0; //RA as OutputPORTA = 0x0F; //turn on 5th (rightmost) digit__delay_ms(1000); //test display/DPunsigned char i,j,k;// display test, all segmentsPORTB = 0xFF; //all segments onfor (j=0; j<5; j++) {PORTA = digit_drive;__delay_ms(400);}PORTB = 0;while(1) //count up and display result{update_display();for (k=0; k<50; k++) {for (j=0; j<5; j++) {PORTA = digit_drive;PORTB = symb[digits];__delay_ms(1);}}counter++;}}Note: exposure caught the display while the last digit was changing.

author: MikeK
author_rank: Super Contributor
timestamp: April 12, 2021, 02:09:05 am
content: I still think it needs a proper preamp...I don't like the idea of feeding an unknown signal directly to the PIC pin.

author: ledtester
author_rank: Super Contributor
timestamp: April 12, 2021, 02:31:25 am
content: Quote from: MikeK on April 12, 2021, 02:09:05 amThere's one sketched out in this PDF:http://www.iw1axr.eu/radio/BiTx/Frequenzimetro%20a%20led%20con%2016F628.pdf(see pages 4 and 6 and 8 )

author: MikeK
author_rank: Super Contributor
timestamp: April 12, 2021, 12:28:28 pm
content: Quote from: ledtester on April 12, 2021, 02:31:25 amI did whattheHWCavedetailed...using the kit parts meant for the "crystal tester" to construct a pre-amp. I just meant thatJimRemingtonshould consider a pre-amp.

author: JimRemington
author_rank: Regular Contributor
timestamp: April 12, 2021, 02:11:18 pm
content: In my application, "known" serial commands will be used to control the display, so no preamp is needed.