Analyzing a Demodulated Signal using Interrupt, capture and PPI

RE: Analyzing a Demodulated Signal using Interrupt, capture and PPI

ovrebekk — Thu, 18 May 2017 14:39:40 GMT

Hi James

You actually don't need to use two separate GPIO's, just separate GPIOTE channels on the same pin. I am also unsure how using two timers will help. I would assume just having one free running timer, and capture continuously to two different CC registers, should be equally efficient.

Have you measured the worst case (minimum) time interval between two rising or falling edges?
Once the first edge is detected, do you always exit the interrupt, or do hang inside the interrupt waiting for more edges?
What is the typical activity rate of the interface in your application. Is it running continuously, or in bursts?

I am suspecting that the nrf_drv_gpiote library is adding too much overhead, and not a good option in your case. Most likely you should just use the NRF_GPIOTE hardware directly, to keep the latency to an absolute minimum.

RE: Analyzing a Demodulated Signal using Interrupt, capture and PPI

James T — Tue, 16 May 2017 13:14:22 GMT

When I call the function:

nrf_drv_timer_capture_get(&timer, NRF_TIMER_CC_CHANNEL1);

the delay in my ISR is too long and thus causing timing issues but I need the stored value before the next falling or rising edge (depending on the edge that triggered the interrupt).

Thanks

RE: Analyzing a Demodulated Signal using Interrupt, capture and PPI

James T — Tue, 16 May 2017 13:07:13 GMT

Hi, Thanks for the response. I have enabled constant latency mode. I have removed any visible sleep function in my code.

I have tried setting up individual events on rising and falling edge. I have the data stream going to two pins on the nrf52 (one set to interrupt on PosEdge and the other on NegEdge) in hopes that this would solve the issue.

The system seems too slow consistently. The response time from the level changing to the ISR is about 8.5uS. Can you think of any other way I can speed this up? Any workaround ideas would also be greatly appreciated.

Regards, James

...small update.

I am using two PPI's , two GPIO interrupts and two timers with capture enabled. One GPIO interrupt is generated on rising edge, the other on negative edge. Each interrupt generates a capture event using their respective PPI's. The problem I now have is trying to get the data from these captures...

RE: Analyzing a Demodulated Signal using Interrupt, capture and PPI

ovrebekk — Fri, 12 May 2017 14:14:27 GMT

Hi James

Do you put the chip in system ON sleep mode while the data capture is occurring? If so you might want to enable constant latency mode before entering sleep, and you should see quicker event response (at the cost of higher sleep current).

Another trick to give you some more time is to set up individual events on rising and falling flank. Then you should have twice as long time (on average) to process the events.

Would you say that the system is too slow consistently, or is it only during higher priority interrupts that you get issues (such as those generated by the SoftDevice during radio activity)?

Best regards
Torbjørn