Pico frequency counter using RP2040

[mino-fm]

At this moment I have no time to continue my reciprocal frequency counter project, but if you like it, I can give you the  .uf2-file.
All you need is a RP2040 Pico-Board, 5 V supply, an input signal and a RS232->USB-converter or COMx-port of PC. No further components are required.

First extension could be a potentiometer/trimmer of around 5 k to adjust reference frequency of the internal crystal oscillator by +/- 20 ppm. There are three jumpers where you can select (J1) a 10 MHz reference (local crystal or TCXO) or increase (J2) the input frequency range up to 32 MHz. Jumper J3 will reverse TxD-Signal, so no RS232 driver is required to meet RS232->USB-converter input level. Jumpers are recognised at power-on.

preliminary data:
•   input frequency range: 0,1 Hz – 16 MHz (32 MHz ‚turbo‘)
•   resolution: 7 digits/s
•   rate: 3 meas./s or one periode @Fin < 3 Hz, gapless
•   serial data output: 115,2 kBd, format 8N1
•   reference frequency adj.: +/- 20 ppm
•   optional display: 2 x 16 LCD

Maybe you like it.

[mino-fm]

This project has been evaluated with a demo version of IAR EWARM V9.2 and can be used directly. For other IDEs or compilers some files has to be fitted especially files 'cstart_rp2040.c' and 'boot.s'.
http://mino-elektronik.de/progs/RP2040/pico_fmeter_GB.zip

Internal file 'pico_fm.bin' is linked to 0x10000000 starting with XIP-bootloader. Output file 'pico_fmeter_GB.uf2' can be copied to Pico-Board using USB-connection.

To get your own .uf2-file use file converter 'bin2uf2.exe'.
Usage: bin2uf2 -sfilename.bin -dfilename.uf2

It's all WIN10 stuff. I think Linux users will be able to adapt everything to their system.

[mino-fm]

A newer version (not ready at all) offers higher input frequency an additional Fref-input to correct internal XTAL frequency by +/- 100 ppm.
Maybe someone likes to test it.

[mino-fm]

There is are new versions of hardware and software.
GB documentation can be found here: http://mino-elektronik.de/download/Pico-FMeter-RP2040-GB.pdf

.uf2-file is german stuff only: http://mino-elektronik.de/progs/RP2040/pico_fmeter2.uf2

If you like to get your own boards from JLCPCB, Elecrow, ... you can use this: http://mino-elektronik.de/progs/RP2040/pico-fmeter2a.zip

let me show you some pictures.

[mino-fm]

Connecting 2 x 10 MHz OCXOs will show resolution of Pico-Fmeter2a.

One OCXO is connected to Fref-input and after passing the input stage the signal is given to XIN of RP2040 via 22 pF. Ext. 10 MHz reference is enabled by setting GPIO28 to '1' at power on.

The other OCXO is connected to Fin. 0.07 Hz difference of both clocks are compensated by setting TimeLab accordingly.

Setting measurement time to 10 s and waiting for one hour, you can get curves for ADEV (1. picture) and frequency difference (2. picture). I guess there was an air draft at the end of measurement which causes small drifts down and up again.
Modifications for ext. Fref are shown in 3. picture: grey wire + 22 pF and red jumper

[mino-fm]

After several month of evaluation this project seems to be stable so I can give you actual source code: http://mino-elektronik.de/progs/Pico-Fmeter2a/pico_fmeter2.zip
As mentioned before it’s a german version.

Comments in source code will show programming details but will give no overall information of what is going on there. An extra documentation will explain how and why this reciprocal frequency counter works:
http://mino-elektronik.de/download/Arbeitsweise_Pico_Fmeter2_GB.pdf
and for german readers:
http://mino-elektronik.de/download/Arbeitsweise_Pico_Fmeter2.pdf

[MikeK]

Nice project, thanks for posting.  I'll probably build it at some point.

[mino-fm]

Thank you! Now I'm not alone here anymore ;-)

User Paul V. informed me that inside the IAR project a link to ..\EWARM\pico_fmeter2.icf failed because of a dead path. So please correct the path under Workspace -> Options -> Linker to a real location or reload 'pico_fmeter2.zip'.

Please take attention to Workspace -> Options -> Build Actions -> Post-build command line:
..\tool\bin2uf2 -s..\bin\pico_fmeter2.bin -d..\bin\pico_fmeter2.uf2 -b2
pico_fmeter2.bin output is linked to 0x20000000 and my 'bin2uf2.exe' generates 'pico_fmeter.uf2' loaded to 0x10000000 with option -b2.
At startup code will be copied from XIP 0x100000000 to RAM 0x20000000 and then executed from RAM.

[Dbldutch]

I'm the Paul V. Michael is refering to in his latest post.

I'm editing my previous information today (9-01-2023) because Michael has made some changes to the configurations which solved several issues.
It would otherwise confuse new comers to this posting.

This is the first time I'm using the IAR Embedded Workbench (Version Arm 9.32.1) myself, keep that in mind.

I'm using the latest Zip file pico_fmeter2 from the website.

The IAR Workbench system is rather peculiar with it's use of relative paths when you move the configuration from one system to another.
Unless you know what you're doing, the recommended procedure is to unzip the downloaded information in C:\pico_fmeter2

In that directory, there is a configuration file that you can double-click on to start the IAR Workbench. The file is pico_fmeter2.eww.
When you import this into the IAR Workspace, you will get a warning that this is an old format and if you want to convert it. Replying Yes, works without errors. Leaving it in the previous format generates errors I could not understand, so I didn't persue that option.

There is one more peculiar path that you need to edit in the configuration, because it is different from Michael's system.

There are corrections needed to the post build command to automatically convert the .bin to .uf2 at the end of the build process.
It’s a little tricky.
You need to go to Options and then select Build Actions.
In there is a command line that has 3 incomplete paths that must be corrected:
WARNING: do NOT click on the three dots at the end of the line because that will delete this command.

Code: [Select]

..\tool\bin2uf2 -s..\bin\pico_fmeter2.bin -d..\bin\pico_fmeter2.uf2 -b2
Edit this line into this:

Code: [Select]

..\..\tool\bin2uf2 -s..\..\bin\pico_fmeter2.bin -d..\..\bin\pico_fmeter2.uf2 -b2
When that has been entered, the build process will generate the pico_fmeter2.uf2 file that can be downloaded to the Pico.

I noticed with another build that you need to select Clean to remove all files that were produced in the previous environment, and then run a Rebuild All.

Good luck!
Paul

[mino-fm]

Hi Paul,
I sent you a massage yesterday, but 'gmail' doesn't like my sender address.
So I just sent you a PM.

It's fine you can generate your own version now!

Michael

[Kleinstein]

A really nice project.

The regression method should give an advantage of slightly less than the square root of N, as the inner points have less weight. AFAIR with a large N this gives about a factor of 2.5 less gain - still good.

Another point with the regression method is the choice of the weights. The classical linear regression is best for the case of independent noise (e.g. trigger caused jitter). For more frequency noise of the oscillators there should be more weight to the extremes and less to the inner points. So ideally one would have a choice on how to use more capture events.
With 2 of the makeshift capture units in parallel, there could be blocking of the DMA channels and problems this way.

[Dbldutch]

@Kleinstein
You have an awfull lot of experience and that is putting it mildly. 

My plan is to use Michael's project to monitor my GPSDO, and to see if it can measure the 10MHz frequency with the needed resolution to make it usefull.
Are there any words of wisdom you can share before I embark on this adventure?

Many thanks!

[mino-fm]

With 2 of the makeshift capture units in parallel, there could be blocking of the DMA channels and problems this way.

DMA channels are fast and working independently to different memory banks. So there is no delay which could cause timing problems. See Table 153 on page 122 in RP2040 Datasheet.

The three functions which are reading time stamps and DMA transfer cycles are now surrounded by __disable_interrupt() and __enable_interrupts() instructions.
If someone adds an ISR, which could delay stopped DMA transfers for a too long time, timing will be sure anyway.

For higher resolution there is a project using STM32G431 shown exactly two years ago:
https://www.eevblog.com/forum/projects/8-11-digits-reciprocal-frequency-counter-0-1-hz-150-mhz/msg3386880/#msg3386880

[mino-fm]

There is a software update. Some errors are fixed.

Switching regulator of Pico-Board is very noisy. For higher sensitivity of sinusoidal input signals it’s a good advice, to stop its function and add an external low-drop 3.3 V linear regulator.
Put input 3V3_EN of Pico-Board to GND (connect Pin37 and Pin38) to disable it and place the additional regulator at the bottom side of the board. TO92 package is easy to handle.
Further on you can change R2 and R6 to 82 or 91 kOhm.

[bidrohini]

Thanks for sharing.

[Dbldutch]

With the help from Michael, I have put together a very minimal setup with just the Pico and a 16x2 LCD display on a breadboard.
I'm feeding it with my square wave GPSDO 10Mhz output as the input frequency. I'm also using the GPS 1PPS signal to let the software calibrate the Pico clock.
Using square wave inputs means that I don't need any front-end circuitry, I connect the signals straight to the Pico GPIO pins on the breadboard.

I should add that the 1PPS calibration works very well.

With it, I can get a very stable display of 10.000,000,0 MHz with occasionally flipping 1-2 counts.
Going one digit further in resolution shows an unruly last digit.

This is an impressive feat that can be improved by using Michael's PCB and a proper setup with better shielded cables.

That's not my plan, this was just a proof of concept for me that passed with flying colors.

I'm now building the STM32 version (Fmeter-G431) on Michael's PCB to see how far I can get with that.
This will be reported in the other thread.


Enjoy!

Update:
I started a post on my own Blog with more information.
It can be found here : https://www.paulvdiyblogs.net/2023/01/a-high-resolution-reciprocal-counter
Comments are better handled here.

[mino-fm]

There is a new version V2.2 of pico-fmeter2a correcting problems of DMA-TRANS-COUNT overflows.
Additional function is statistical calculation of Fmean, Fmax, Fmin and S-dev.

[mino-fm]

IAR has changed its conditions using EWARM demo-version:

    Time limit for evaluation license is 14 days
    Not allowed to be used for product development or any kind of commercial use
    Source code for runtime libraries is not included
    C-RUN is size-limited to 12 Kbytes of code, excluding constant data
    Limited technical support

14 days are too short and 12 KB code won't work.
So I tried to convert some RP2040 projects to be used by "Segger Embedded Studio for ARM."
https://www.segger.com/downloads/embedded-studio/#ESforARM

If you like to make changes please use these projects as required:
http://mino-elektronik.de/progs/RP2040/Pico_Fmeter_Segger.zip
http://mino-elektronik.de/progs/Pico-Fmeter2a/Pico_Fmeter2_segger.zip
http://mino-elektronik.de/progs/Pico-FM-AS6501/Pico-FM-AS65_segger.zip

File *.emProject will open the project. File *.uf2 can be used and J-Link for RP2040 ist not necessary.