MSP430F6779: Help achieving ≥6000 S/s sampling rate on EVM430F6779 for voltage and current measurement

The frequency response of the SINC filter used in the SD24 is not flat in the passband. Which means that your  harmonics will be attenuated. By how much? You will have to do the math and decide if it is acceptable.

Hi David, thanks for the heads-up on the SINC passband not being flat. For now I’m not focusing on that attenuation; I’ll quantify it later and decide whether I need to compensate.

What I’m trying to achieve is ≥6 kS/s, ideally 8,192 S/s to comfortably analyze up to the 50th harmonic (3 kHz) on a 60 Hz system. From what I understand, on the MSP430F6779’s SD24_B the sample rate is set by:

• fs = fM / OSR, where
  fM (modulator clock) comes from SMCLK using SD24SSELx / SD24PDIVx / SD24DIVx, and
  OSR is set per channel via SD24BOSRx.

My plan is to get fs = 8,192 S/s in one of two ways:

Option A (minimal changes):

• Keep the existing modulator clock (typical demo setup has SMCLK → SD24_B prescaled so fM = 2.097152 MHz).

• Set OSR = 256 on the channels I use (i.e., SD24BOSR = 256 - 1).

• That gives fs = 2.097152 MHz / 256 = 8,192 S/s exactly.

Option B (if I really want OSR = 128): (I'm trying with this one)

• Lower the modulator clock to fM = 1.048576 MHz (e.g., adjust SD24PDIVx and/or SD24DIVx),

• Keep OSR = 128, which also yields fs = 1.048576 MHz / 128 = 8,192 S/s.

• Without changing fM, OSR=128 would land me at ~16.384 kS/s, which I don’t want.

In the code I’m planning to:

• In emeter-setup.c:

  • Set SD24BOSR to 256-1 (or keep 128-1 but then reduce fM per Option B).

  • Confirm the SD24_B clock source/prescalers (SD24SSELx/SD24PDIVx/SD24DIVx) match the target fM above.

  • Use single-channel conversions (not group) during raw capture to simplify timing and buffering.

  • Consider SD24INTDLYx if I do start/stop to let the SINC settle.

• In emeter-structs.h (and anywhere it’s referenced):

  • Set #define SAMPLE_RATE 8192 and #define SAMPLES_PER_10_SECONDS 81920ul so any block counters/timers in the metrology code track the new rate.

Operationally (not real-time streaming):

• Capture one channel at a time, 1 second (8,192 samples) of raw data (I’ll store 16-bit to reduce size).

• Buffer in RAM and flush to flash in page-sized chunks; total is ~16 KB for 1 s @ 16-bit.

• Then download those samples over my existing DL/T645 link in blocks (I’m reusing the existing flash-upload command and chunking logic), and process FFT/THD/FP on the PC/RPi.

• I’m aware the SINC passband attenuation will slightly bias higher harmonics; I’ll park that for now and correct later if needed.

Could you (or anyone) confirm the above is the right approach on this platform?
Specific questions:

1. Are SD24SSELx / SD24PDIVx / SD24DIVx indeed the only knobs I need (besides SD24BOSRx) to nail fM (and thus fs) for the SD24_B?

2. Any other SD24_B registers I should revisit when changing fs (alignment, PGA gain, reference, interrupt delay, start-of-conversion mode)?

3. On the TI demo stack, are there any FIR/phase-correction tables or assumptions tied to the original sample rate (e.g., 4,096 S/s) that I should regenerate when moving to 8,192 S/s?

4. For the DL/T645 upload, is there any best practice to increase payload per frame or is sticking with small fixed blocks the safest route?

Thanks a lot for any guidance!

Hi David, thanks for the heads-up on the SINC passband not being flat. For now I’m not focusing on that attenuation; I’ll quantify it later and decide whether I need to compensate.

What I’m trying to achieve is ≥6 kS/s, ideally 8,192 S/s to comfortably analyze up to the 50th harmonic (3 kHz) on a 60 Hz system. From what I understand, on the MSP430F6779’s SD24_B the sample rate is set by:

• fs = fM / OSR, where
  fM (modulator clock) comes from SMCLK using SD24SSELx / SD24PDIVx / SD24DIVx, and
  OSR is set per channel via SD24BOSRx.

My plan is to get fs = 8,192 S/s in one of two ways:

Option A (minimal changes):

• Keep the existing modulator clock (typical demo setup has SMCLK → SD24_B prescaled so fM = 2.097152 MHz).

• Set OSR = 256 on the channels I use (i.e., SD24BOSR = 256 - 1).

• That gives fs = 2.097152 MHz / 256 = 8,192 S/s exactly.

Option B (if I really want OSR = 128): (I'm trying with this one)

• Lower the modulator clock to fM = 1.048576 MHz (e.g., adjust SD24PDIVx and/or SD24DIVx),

• Keep OSR = 128, which also yields fs = 1.048576 MHz / 128 = 8,192 S/s.

• Without changing fM, OSR=128 would land me at ~16.384 kS/s, which I don’t want.

In the code I’m planning to:

• In emeter-setup.c:

  • Set SD24BOSR to 256-1 (or keep 128-1 but then reduce fM per Option B).

  • Confirm the SD24_B clock source/prescalers (SD24SSELx/SD24PDIVx/SD24DIVx) match the target fM above.

  • Use single-channel conversions (not group) during raw capture to simplify timing and buffering.

  • Consider SD24INTDLYx if I do start/stop to let the SINC settle.

• In emeter-structs.h (and anywhere it’s referenced):

  • Set #define SAMPLE_RATE 8192 and #define SAMPLES_PER_10_SECONDS 81920ul so any block counters/timers in the metrology code track the new rate.

Operationally (not real-time streaming):

• Capture one channel at a time, 1 second (8,192 samples) of raw data (I’ll store 16-bit to reduce size).

• Buffer in RAM and flush to flash in page-sized chunks; total is ~16 KB for 1 s @ 16-bit.

• Then download those samples over my existing DL/T645 link in blocks (I’m reusing the existing flash-upload command and chunking logic), and process FFT/THD/FP on the PC/RPi.

• I’m aware the SINC passband attenuation will slightly bias higher harmonics; I’ll park that for now and correct later if needed.

Could you (or anyone) confirm the above is the right approach on this platform?
Specific questions:

1. Are SD24SSELx / SD24PDIVx / SD24DIVx indeed the only knobs I need (besides SD24BOSRx) to nail fM (and thus fs) for the SD24_B?

2. Any other SD24_B registers I should revisit when changing fs (alignment, PGA gain, reference, interrupt delay, start-of-conversion mode)?

3. On the TI demo stack, are there any FIR/phase-correction tables or assumptions tied to the original sample rate (e.g., 4,096 S/s) that I should regenerate when moving to 8,192 S/s?

4. For the DL/T645 upload, is there any best practice to increase payload per frame or is sticking with small fixed blocks the safest route?

Thanks a lot for any guidance!

First up, duplicating your post doesn't help. The lack of replies isn't because no one can see it.

Juan Manuel Arboleda Orozco said:

I’m aware the SINC passband attenuation will slightly bias higher harmonics;

-12dB at Nyquist is "slight"?

Combine that with truncating the results and I predict that most of the harmonics will vanish.

I have no idea what the DL/T645 protocol is or its limitations. But by using DMA, capturing the data should require almost no CPU cycles. Leaving them to stream the data out. So long as that channel is fast enough, you should be able to do this continuously.

Hi David, apologies for the duplicate post. I mistakenly thought I was replying to myself, not to you.

Following your note about the SINC passband not being flat, I plotted the SINC³ frequency response. With OSR = 32 the attenuation across the band of interest looks quite low. However, I did this assuming the modulator clock is set as fM=fs×OSR. In the current setup I took fs=4096 S/s and OSR = 256 (just like it is in emeter-structs and emeter-setup), so fM=1,048,576 Hz. What I can’t seem to find clearly in the slaa577g demo code is where fM is definitively configured (i.e., SD24SSELx / SD24PDIVx / SD24DIVx path), so I’m not 100% confident that my assumption is correct. If you can point me to the exact spot where the modulator clock gets set in that codebase (or confirm the expected fMf_MfM​), I’d really appreciate it.

Also, after discussing with my advisor and teammate today, we decided to use DMA to move samples out for exactly the reason you mentioned (minimize CPU and stream continuously). I’m a bit unsure about the cleanest way to wire this on the MSP430F6779 though. If you have guidance, I’d be grateful — e.g., which DMA trigger to use from SD24_B, whether you recommend a ping-pong (double-buffer) scheme from SD24BMEMx into a ring buffer, and any pitfalls you’ve seen when pushing data out over UART/RS-232 at ~8 kS/s × 16 bits.

Thanks again for the push on the SINC response — I’ll quantify the passband loss and decide if I need to compensate after I lock down the exact fM​/fs​ path in this code.

OSR is directly related to SINAD/ENOB performance. (Figure 5-17 in the data sheet.) OSR=32 is a horrible idea if you are interested in harmonics which are going to be small.

I have no experience with pushing the performance of the MSP430 SD24/DMA. I have done high rate capture from a MPU9250 (32KSPS) and record to an SD card. Same idea but very different details.

(Edited to reference the data sheet instead of the guide.)

Hi David — quick follow-up, and thanks for your time.

1. Could you elaborate on why it’s a bad idea in practice? I get that low OSR hurts SINAD/ENOB and the sinc³ droop doesn’t help, but I’d like your take on the key failure modes you’ve seen (e.g., where harmonics actually “disappear” vs just read low).

2. If I fix OSR at 128, do you think that’s adequate for capturing small harmonics, or would you strongly recommend jumping to 256?

3. Assuming I keep a high OSR and instead raise the sample rate by increasing the modulator clock fMf_MfM​, where exactly is fMf_MfM​ configured in the slaa577g code? I’m looking for the specific lines that set SD24SSELx / SD24PDIVx / SD24DIVx (and I’ll set SD24BOSRx to 128−1 or 256−1 accordingly). Is that split between emeter-setup.c (SD24_B init) and hal_UCS.c (clock tree), or is it concentrated in one place?

4. Lastly, do you know of a good DMA example/thread for MSP430F6779 SD24_B → DMA → UART/SD? A link that shows the DMAxTSEL mapping for SD24_B and a simple ping-pong buffer would help a lot.

Really appreciate the guidance — your notes have helped me steer away from the wrong trade-offs.

As for #1, the harmonics generally decrease in amplitude with increasing frequency. By the 50th, your goal, they are tiny. But you know, or should know, what levels you need to measure. (I certainly don't.) That requirement sets the required SINAD.

Okay, thanks.

I have another problem, David.

I'm following the steps outlined in the document "Implementation of a Three-Phase Electronic Watt-Hour Meter Using the MSP430F677x(A)," and when I try to open and compile the base project, I get the following error for several files. I've already compiled this file on another computer and it worked without any modifications. I don't know why it won't let me perform the Rebuild All on this computer.

What should I do?