Archive | Frequency Counter RSS for this section

Windows 10 and the game of waiting.

I had a Windows 8 pc which I recently updated to Windows 10. I am not a Windows fan by any means. I prefer to use Linux or Mac(Unix). However, after my Linux SDD stopped working I put my HDD with Windows 8 back in the PC and carried on. I almost installed linux on Windows 8, but thought I would give Windows 10 a try.
What I have found so far is that Windows 10 is like a MS version of Mac. Similar system search concept. But as with all things windows, drivers aren’t there yet.

Let me clarify that. I have drivers for all of my PC hardware. Those are working fine. But I also do MSP430 development on that box. So I downloaded the latest windows version of TI Code Composer Studio and installed it. I then connected my MPS430G Launchpad only to find that CCS couldn’t find the debugger. The serial port enumerates just fine, but the FET is completely missing. So I searched the forums a little and concluded that I was going to just have to wait until CCS and Windows could work it out.
So here I am waiting.


MSP430 replacement of the FreqMite.

I love the idea of the Freqmite. It is currently being sold on 4 States QRP website for $22 a piece isn’t that bad.

But I want something a little different. Something like this.

  1. If this is the only function that the device is doing then it should only be active when I hit the spot button. Otherwise I want the MCU in deep sleep where it is drawing micro-amps. It doesn’t seem like much, but if your receiver is pulling 20-30ma, you then why pull power for a feature you aren’t using.
  2. Why not couple this with a keyer. Then you would have a built in keyer, that also tells you what the frequency is. Now how handy would that be.
  3. The keyer should have a ptt output. So I can key the transmitter, like in the Rockless Rockmite.
  4. The keyer should also have a side tone output. Maybe even configurable.
  5. Part component cost to be under $15.
  6. The code should be open sourced on GitHub so that anyone can download it or modify it to suit their needs.

I think this is going to have to be a future project.

I used to have debuggers to several chip vendors and I got rid of everything but my Segger J-Link. While working on some other projects, you hear about shortly, I have decided that I will only use ARM chips from now on. So this project won’t be done using an MSP430.

Frequency Counter (Update)

Spend some time this weekend and now have the display timer update callback working. I originally set it up to read from a queue, but that did work like I expected. To clarify, the callback worked well, since it was only pulling the data out of the queue. The issue came from putting the data in the queue.
Capturing frequency is really the counts per time period. To do this we tie a counter to an external pin and we see how many counts is has after a time period has expired. The software architecture would typically be to use a timer peripheral setup to fire an interrupt service routine (ISR) when the timer expires.

The process typically looks like this:

  1. Setup the timer so that the expiration period is the gate time.
  2. Clear the counter value.
  3. Enable the timer.

When the gate timer expires the ISR gets called and does the following:

  1. Stop the counter.
  2. Clear the interrupt flag.
  3. Calculate the frequency. (This may be done later)

So everything was going fine, until I tried to put a new entry in the queue.

Seems FreeRTOS compares the priority of the interrupt that is called to the ISR that is used for the system tick of the RTOS.

Now to figure out whether to continue down the path of using the queue, or to switch to just using a global variable.

I put the code on GitHub here.

Frequency Counter

So my Radio Shack frequency counter died. I decided that since I had a few 7-segment LED’s I would just make a bench top frequency counter.


I started with the frequency counter designed by Wolf Buscher, DL4YHF.
He used a Microchip PIC, which I no longer have debugging tools for. A while ago I got rid of all my debuggers except for my J-Link ARM debugger. Having worked with ST, Microchip, Motorola processors, I decided that I would commonize on the ARM architectures. Specifically, on the Cortex-M series.
In my frequency counter I am using seven 7-segment displays, I also wanted a display that was MCU independent. So I used a 74LS47 BCD to 7-Segment driver and a 74HCT239 3 to 8 addressable bus. This means that I need 3 bits to select a segment and 4 bits to select the character to display. The 7-segment displays have their segment lines all tied together and their supply lines are controlled via the 74HCT239.
This works by turning power off to all 7-segment displays, writing the segment values to the 74LS47 chip, then enabling power to the segment using the 74HCT239. This is done for each digit in sequence at a rate faster than 60Hz. To the human eye this gives the impression that all digits are on simultaneously.
This is very similar to the construction method shown here

Front End Circuit

Because I wanted a fast input that converted low voltage sine waves into a square wave at the voltage of the mcu, I am using the following circuit.


For the processor I chose to you a NXP Kinetix Freedom K22F. This processor has a ARM Cortex-M4 processor with an internal floating point unit, DMA, USB, and standard MCU peripherals. The FRDM-K22F costs $30USD and includes an onboard debugger.


I used Kinetis Design Studio (KDS) and the Kinetis Software Development Kit (KSDK) to write the software for the frequency counter. The KSDK provides drivers for the onboard peripherals. For the Real-Time Operating System, I used FreeRTOS. It is my favorite embedded RTOS due to its ease of use and because it is very light weight. Giving it a very small memory footprint.