Motor Thrust Test Bench

So, what to say. I can’t just build and fly quadcopters. As usual I have to create something that makes me gain knowledge or create almost the same solution but based on my idea how it should work.  So I couldn’t really help my self when I did not really understand why one ESC-Motor-Propp setup would be better then an almost similar setup. And there is a lot of information “as usual” on the Internet, but most is based on the writers opinion.
So I figured the best solution is to build a solution that really test all of this together, so I can get hands on real data to analyze 🙂

So I did a lot of research on similar solutions, but the ones that I did find was not in the same standard or gave the functionality as I was after.
So put together a few PCB boards that holds the functions that I need to test the “beta solution” before a real solution can be made.

So the specifications/functions I am going for is.
Minimum 1000Hz sampling rate from Voltage/current and load cell (strain gauge) and accelerometer.
RPM will update as fast as possible, and will be based on pulse duration instead of number of pulses/time.
All data is transfered to the computer so analyses can be done afterwards.
Simple ramp , step and oscillation/wobble response analyze.
Efficiency curve, and optimal efficiency range calculations.
And a lot more.

First a overview

I tough that the best way is to create a sensor module that only holds the most basic functionality, and separate the specific functions to a separate module.
So if I decide to redo a module, I don’t need to redo the whole solution.  And I can reuse the modules for future tests/solutions.

BenchTest Controller Structure Overview2

Main module is based on the STM32F4 32bit MCU that has plenty of power, so there will no problem to implement the functions I would need.

BenchTest Controller Structure Sensor Module

Each Sensor module holds two high-speed SPI buses that will be used for transferring data between sensors and the computer.
I did some calculations at first on the data-rate if I only would have used one processor to do all sensor data collection and transfer to the PC.
The problem with that is the data rate trough the UART/USB bridge is precisely at its limit. So by separate them it will be easier to send at the rate I would like (min 1000 Hz) and still have bandwidth left. And the system will be more modular, so if I wouldn’t be a problem to add sensors later on.

BenchTest Controller Structure Modules

Each module I have made so far.

PCB that holds the modules

F3 F2 F4 F2

Boards are ordered and are  on the way back.

PC Software

As usual I have a lot of different ideas.
Basically each test run will hold data for everything, but it will be done so I can sort by Motor/ESC/battery/propeller/Ncells later and can be compared with all other runs that holds the same criteria as you are interested in.
It will be written in C# and I have a lot code that has already been done with data sampling and graph plotting (see Modular Data Acquisition System)

Modules soldered.     Update 2015-12-26

Had some time over to solder togheter a few modules so I could start with some tests.

Modules1 (Large)


Serial Driver (UART/USB).     Update 2016-01-26

I am using the FTDI FT230X Serial to USB bridge on my sensor module. And I decided to totally rewrite my serial/FTDI driver with threading in mind. The last serial driver was one of the limits when handling a lot of data.  So the decision to spend a fair amount of time on the serial driver was not hard to make. And it paid of. Right now I do not have any USB/serial bridge that is faster then the 3 Mbaud then the FT230X can handle. I am working on a new board that can handle 12 Mbaud, so I have to wait until I can test the driver in a bit higher speed then right now.

But so far it looks promising.

Driver Structure

FIFO Structure

Result with 3Mbaud in FTDI Mode


It only consumes 0.02% CPU and uses 12 threads when the CPU is running at 760MHz.
29ms per pack gives 34 packs/sec, so in total we get 34000 values/sec (32bit value)

UART/DMA timing


It takes 29ms to send one package, each package holds CRC, package ID, address, command, ACK request, and 1000 32bit values (sent value is 0xFFFFFFFF)

And the UART DMA is double buffered so there is no delay between each package on the serial stream


So it looks really promising, I cant wait until I can test with 12Mbaud .

More to come


Get every new post delivered to your Inbox

Join other followers: