SAADC sampling at different rates, but not simultaneously

RE: SAADC sampling at different rates, but not simultaneously

Mike Austin (LPI) — Mon, 22 Jul 2024 06:33:04 GMT

Yeah, went down that rabbit hole a few months ago. Problem is, my signal sits at 1V without stimulation, then will go either up towards 2V or down towards 0V.

So, I really need a window comparator, but can't implement that function with the COMP peripheral on the nRF52832. I did attempt to do something using the COMP and LPCOMP, but of course you can't use both of those together.

I'm about 95% of the way getting the functionality I need using the approach you essentially triggered for me, so thanks!

RE: SAADC sampling at different rates, but not simultaneously

DougR — Sun, 21 Jul 2024 14:14:40 GMT

One other idea: since you don't actually use the sampled LIMIT channel data, other than to do the comparison with your set limit values, this might be an application for the COMP peripheral. Set it up to trigger your events for high or low deviation, and let it run. Then the SAADC peripheral can be set up for the line voltage measurement only. Now you have independent hardware working on your two inputs.

RE: SAADC sampling at different rates, but not simultaneously

Mike Austin (LPI) — Thu, 18 Jul 2024 02:17:54 GMT

DougR

Thanks for your input. My FFT measurement isn't (or in fact doesn't need to be) anywhere near as precise as yours. I'm only really concerned about the 3rd and 5th harmonic content of a 50Hz (or 60Hz, depending on where this thing is deployed) AC signal.

And I believe if I'm going to use PPI, I'm forced to use the Nordic SAADC drivers, rather than the Zephyr ones.

I've had all of this working on a Cypress IC for years, but of course with all the issues with supply chains, couldn't get any more of the IC we were using, so we took a punt and moved everything over to Nordic about 2 years ago. I'm frantically porting all my Cypress stuff over to Nordic, which kinda explains the background of why I've been approaching this as I have - a bit of "that's how I did it before".

Anyway, with some modification, I think your idea would be the best approach. That is:

1. Sample my two channels as fast as I need to for the LIMIT channel to do what I need it to do, using PPI to trigger the SAADC in advanced non-blocking mode

2. When I need to do an RMS voltage measurement, grab the contents of the buffers and do a bunch of averaging to get the information I need. Then do my RMS calc as per normal.

We're pretty limited with the amount of RAM we have left, so can't just have a bunch of 2000 element buffers that we then copy over to another buffer for post-sampling processing (We're using 12 bit resolution). So we would need to be doing some processing of the info in each buffer once its filled, grab an average or something out of that, and then store that elsewhere. One idea I did have, and I'm not sure if its going to work, is to have a dual buffer, each buffer only storing one sample for each channel, and things rapidly swapping back and forth between them as samples are collected. Then, I can trigger an event where I save one of those samples into my 32 sample array using my Counter/Timer as I currently am. Not sure how much overhead the buffer swapping process adds to the acquisition process and what that would mean for the maximum sampling rate I can achieve. I'm only interested in fast sampling for the LIMIT channel, to detect when its outside my limits. I don't actually need to know what value that channel is at any point.

The other thing I haven't yet been able to get my head around, just looking at the saadc examples, is how to configure the buffers that are used in the NRFX_SAADC_EVT_BUF_REQ event. I'm needing to set up a dual buffer, with however many elements for the number of samples I need to take, and for the two channels I am sampling. I could use a bit of help understanding the mechanics of how to get that right

Regards,

Mike

RE: SAADC sampling at different rates, but not simultaneously

DougR — Wed, 17 Jul 2024 16:24:06 GMT

My first comment is that working with a half-cycle of an AC signal seems problematic, at least to me. Signals with frequency near or below the bandwidth of the window you've selected are not easy to analyze with FFT. Something like 5 or 6 cycles would give ~0.1 s of data to work with, and more accurate determination of the fundamental for comparison with the harmonics.

My second comment is that it's not clear to me that you're taking advantage of the hardware's ability to sample all the channels into a buffer using a sequence, and unpack after during processing. Sampling at 200 kHz will be much faster and noisier than you want for the "RMS Voltage" input, but you can do the averaging in software. You might find this code I wrote helpful, which does something similar, or at least related. I think we're using different drivers, however.