How to measure energy distribution

Question

I want to evaluate the energy flow in a battery powered system. So when the system runs a specific task the energy distribution between the different loads can be obtained ( similar to a Sankey diagram). For this a timescale in the range of [100..10] ms in the processed data would suffice.
Electric energy can be calculated as \$W = \int_{t_{0}}^{t_{1}}u(t)\cdot i(t) dt\$. Thus measuring voltage and current at a given sample rate will provide the necessary data. For further processing on a PC voltage and current should be logged.

As can be seen in the image the power supply converts the input of the batteries to a steady 24V. The motor drivers use a 40 kHz pulse-width-modulation (PWM) to control the brushless direct current (BLDC) motors. Up to 9 motor/driver combinations can be in such a system. There are more loads supplied by the power supply which show only slow changes in energy "consumption". The measuring will be controlled by an Arduino Due (84 MHz). The ADCs will likely have multiple channels and will be connected via SPI.

My concern is to measure with good accuracy whithout hitting a bottleneck in the processing:
Speed of the bus (SPI) to the ADCs, data processing ( both limited by microcontroller ), and especially the write speed to SD card ( limited by the Arduino lib <700 kB/s? )

The voltage of the batteries only changes slowly under load and thus the sampling rate can be low. However the motors show multiple harmonics in response to the 40 kHz PWM.
Considering the nyquist criterion measuring frequency would need to be more than twice as large then the fastest signal of interest (here the n-th harmonic with significant magnitude). Other signals need to be low pass filtered to prevent aliasing.

Question 1: Which steps for measurement and processing can be taken to maintain accuracy while reducing demand on the bottlenecks?
My thoughts are:

• Using arithmetic averages over a set interval \$\Delta T\$ to reduce data to log: \$\overline{W}=\overline{u}\cdot \overline{i} \cdot \Delta T\$
• Writing binary data to the SD card instead of plain text.
• Measuring only one phase per motor, assuming phases are driven equal while maintaining constant speed at constand torque. Thus this approach is limited by the conditions.

Question 2:Is it possible to get a good approximation by measuring slower than the PWM frequency?
I get that undersampling is not applicable here, as it uses the alias of a higher frequency band in an empty lower frequency band.

Answer 1

To measure the power consumption of each motor, you'd need to measure the voltage and current, before the motor driver.

(the 3 phase power after the driver will be very hard to measure).

Both voltage and current measurements will need to be filtered to remove the 40 kHz signal, which will otherwise cause all sorts of trouble, as you correctly anticipate.

Fortunately, 40 kHz is far away from your likely sample rate of about 50 Hz. A first order RC filter with its knee at 40 Hz will attenuate the 50 kHz ripple voltage by about 30 times, which might be enough. An inductor and two capacitors will be much better.

Voltage is fairly easy to measure - as a nice low impedance source, you can build a simple filter and feed it to your ADC. You only need one voltage measurement after the 24 V power supply. The ripple in the voltage should be fairly small anyway.

Current is a bit more tricky. You could use a sense resistor in the ground wire, and an op-amp to amplify the small voltage, then the filter. At some torque settings, the current might really be a square wave at 40 kHz, it'll be hard to measure and filter. It might be an idea to filter the power line itself with one LC, just to remove some of the ripple, and then filter the sense output again before the ADC.

One last digital idea would be to sample faster than you need to, perhaps at 1 kHz, and average these in the Arduino. The aliasing will still be a problem, however if you randomise the time of the samples, you may be able to average out the 40 kHz signal, preventing it from being properly aliased into your band of interest. Some experiments here would be valuable.