This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Frequency detector possible?

Hi. Can anyone think of a way to use the nRF52832 (probably Timer) to detect approximately 125KHz-150KHz variable square wave down to about a 1Hz resolution? I'd like to detect frequency changes at about 100 times a second though. Ideally I'd like to do this without any external hardware (like a heterodyne mixer). Thoughts? Thanks!

(FINAL answer at very bottom. The answer is YES, the nRF52832 can be used even with a SoftDevice to accurately detect a few hundred KHz signal down to a few Hz resolution)

  • Not quite what I was suggesting. You might explain the requirement in more detail before moving forward; not sure why you mention averaging 999 pulses. The stability of the measurement window is probably 20ppm (part per million) given you have HFCLK enabled as suggested, and over a short measurement that would be even better.

    Is the signal encoding an analogue (analog) waveform modulated about the center frequency? If so you don't care about the actual frequency, just the delta modulation which becomes a ratiometric measurement much easier to make (and more accurate) as there are some other techniques available.

    Is the signal instead a changing frequency which has to be measured absolutely, say for a hand-held frequency meter?

    Is the signal a series of digital step increments? Where does the 1Hz resolution requirement come from?

  • I incorrectly assumed the NRF52-DK automatically had that designed into it since it has an external xtal. Now I understand the external xtal has to manually be enabled (right?). When I do so (through enabling a BTLE SoftDevice) the frequency measurements are stable as a rock. It is off by about 2Hz in absolute accuracy, but I can live with that. It oscillates by about 1/2Hz to 1Hz. Very nice performance (on an NRF52-DK).

    So... Your idea worked well! Thank You. I'll post the final code here in case anyone else needs a frequency detector with a few Hz resolution that can measure up to the hundreds of KHz. Just make sure you use a very stable external CLK.

    #define FREQ_MEASURE_PIN  11												// P0.11
    #define kPulseDetectionCount 1000											// Detect this many +edges
    
    static volatile uint32_t pulsesDetected = 0;
    static volatile uint32_t freqDetected = 0;
    
    
    extern "C" void TIMER4_IRQHandler(void)
    {
    	if (NRF_TIMER4->EVENTS_COMPARE[0]) {
    		NRF_PPI->CHENCLR = 1 << 1;				// Disable PPI channel CH1 that initiated counting
    
    		pulsesDetected = NRF_TIMER3->CC[0];		// Get detected pulses (count was captured during PPI event): total count for 1000 +edge events (in 0.0625us units)
    		freqDetected = (pulsesDetected == 0) ? 0 : (16000000.0 * (float)kPulseDetectionCount) / pulsesDetected;
    
    		NRF_TIMER3->TASKS_CLEAR = 1;			// Reset timers
    		NRF_TIMER4->TASKS_CLEAR = 1;
    		NRF_TIMER4->EVENTS_COMPARE[0] = 0;		// Reset for next
    		NRF_PPI->CHENSET = 1 << 1;				// Re-enable PPI - go again
    	}
    }
    
    
    // Must use a stable external CLK for accurate measurements
    static void freqDetectorInit(void)
    {
    		// Pin & GPIOTE init
        IOPinConfig(0, FREQ_MEASURE_PIN, 0, IOPINDIR_INPUT, IOPINRES_NONE, IOPINTYPE_NORMAL);
    	NRF_GPIOTE->CONFIG[0] = 0x01 << 0; 								// Event mode
    	NRF_GPIOTE->CONFIG[0] |= FREQ_MEASURE_PIN << 8;					// Pin number
    	NRF_GPIOTE->CONFIG[0] |= GPIOTE_CONFIG_POLARITY_LoToHi << 16;	// Event rising edge
    
    		// Calls TIMER4_IRQHandler
    	NVIC_SetPriority(TIMER4_IRQn, APP_IRQ_PRIORITY_LOW);
    	NVIC_EnableIRQ(TIMER4_IRQn);
    
    		// Timer 4: Rising edge event counter - detect 1000 +edges then generate an interrupt
    	NRF_TIMER4->TASKS_STOP = 1;
    	NRF_TIMER4->MODE = TIMER_MODE_MODE_Counter;												// Counting external pulses
    	NRF_TIMER4->BITMODE = TIMER_BITMODE_BITMODE_16Bit << TIMER_BITMODE_BITMODE_Pos;			// Only need 16 bits to count 1000 pulses
    	NRF_TIMER4->CC[0] = kPulseDetectionCount + 1;											// # pulses to detect (+1)
    	NRF_TIMER4->TASKS_CLEAR = 1;
    	NRF_TIMER4->INTENSET = TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos;	// Generate int when done to get results
    	NRF_TIMER4->TASKS_START = 1;
    
    		// Timer 3: 16MHz timer during 1000 events
    	NRF_TIMER3->TASKS_STOP = 1;
    	NRF_TIMER3->MODE = TIMER_MODE_MODE_Timer;
    	NRF_TIMER3->BITMODE = TIMER_BITMODE_BITMODE_32Bit << TIMER_BITMODE_BITMODE_Pos;
    	NRF_TIMER3->PRESCALER = 0;
    	NRF_TIMER3->CC[0] = 0;
    	NRF_TIMER3->TASKS_CLEAR = 1;
    
    		// Using PPI CH0, when Timer 4 compares to kPulseDetectionCount +transitions events, capture the count of 0.0625us periods
    		// Add a 2nd task to stop 16MHz timer
    	NRF_PPI->CH[0].EEP = (uint32_t)&NRF_TIMER4->EVENTS_COMPARE[0];
    	NRF_PPI->CH[0].TEP = (uint32_t)&NRF_TIMER3->TASKS_CAPTURE[0];
    	NRF_PPI->FORK[0].TEP = (uint32_t)&NRF_TIMER3->TASKS_STOP;
    	NRF_PPI->CHENSET = 1 << 0;
    
    		 // On PPI CH1, when a GPIOTE rise event happens start TIMER3 (the first time) and increment TIMER4 every time
    	NRF_PPI->CH[1].EEP = (uint32_t)&NRF_GPIOTE->EVENTS_IN[0];
    	NRF_PPI->CH[1].TEP = (uint32_t)&NRF_TIMER3->TASKS_START;
    	NRF_PPI->FORK[1].TEP = (uint32_t)&NRF_TIMER4->TASKS_COUNT;
    	NRF_PPI->CHENSET = 1 << 1;										// Go
    }
    

  • Hugh, I'll reply to your questions offline, OK?

  • Ok - and good job in getting your code running!

  • Hi Dmitry. This technique is working pretty well (thanks again!) but I seem to have an issue when the SoftDevice is transmitting data. It is almost as if the SoftDevice is dropping back to the internal LC oscillator then switching back to the external CLK when it returns control to me.

    When I transmit data via BT as a Characteristic, the readings vary +-150Hz (like it was before I knew about the internal vs. external oscillator selection above). This does NOT happen when I break at the point where the data is transmitted and look at the reading - the breakpoint seems to shut down the BT link and all subsequent readings are stable as a rock each time I continue with the breakpoint and break again the next time around (until the SoftDevice panics and throws an exception like it always does). 

    So basically when I break at my transmission point to see what data it is going to transmit, the link drops and the frequencies are stable. But when I let it run on it's own and transmit the frequency reading every second (from a 1 second timer interrupt), the data transmitted varies about +-150Hz or so. This variance also happens when I turn off BT and the SoftDevice all together which defaults the application to use the internal LC oscillator - that is expected.

    Thoughts about the SoftDevice toggling oscillator sources?

    Also, is there a way to tell the SoftDevice NOT to panic when I am single stepping through code?

    Thanks!

Related