DIY Test Stand to Measure Thrust

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

jbeuckm

Member
Joined
Jan 12, 2017
Messages
12
Reaction score
0
I'm planning to build a test stand for F-I range PVC/candy motors. My plan as of now to to use a HX711 with a cheapo 100kg load cell to read 80 thrust measurements per second into an arduino and save those to SD card. I understand that it needs considerable mass to stay put during the firing but I would like to make it somewhat portable to get out away from the neighborhood for tests. Is there a standard recommended design for this type of stand? Did I miss a thorough discussion about building this?

Thanks!
 
Subscribed. Thanks for asking this question. I really want to learn from the responses.
 
I'm planning to build a test stand for F-I range PVC/candy motors. My plan as of now to to use a HX711 with a cheapo 100kg load cell to read 80 thrust measurements per second into an arduino and save those to SD card. I understand that it needs considerable mass to stay put during the firing but I would like to make it somewhat portable to get out away from the neighborhood for tests. Is there a standard recommended design for this type of stand? Did I miss a thorough discussion about building this?

Thanks!

What are the safety measures you plan on using?
Do you have a LEUP (low explosives user permit) for transporting the rocket candy?
Have you simmed your motor, such as with burnsim?


I'm not necessarily trying to dissuade you, however, I don't want you to get into legal or medical trouble either.

Best of luck!
 
There are some threads in the research forum that discuss thrust stands and measurement tools. Aerocon has a page with pictures that various people have sent in over the years as well. They show a simple one that's a 5 gallon bucket filled with concrete that has a metal I-Beam embedded in the concrete. The load cell is attached to that. They act like everyone has metal I-Beams just floating around the garage, but I sure don't. :) I was considering using metal square tubing, something like you might use for a receiver hitch on a truck.

Mine are likely to be smaller, so at the moment I'm leaning toward 2x4 construction with some weight and tent stakes holding it down. The motor will point down, so keeping the unit in place is more about preventing it from tipping over than anything else.

I considered the HX711, I'm curious what your data looks like when you get some. I went with an Analog Devices eval board which has the ability to run the load cell and a pressure sensor. The down side is software sucks so I'm working on that as well. I was also wondering if I thought 80 samples/sec would be sufficient. For thrust it probably is, it might miss short pressure spikes though. With sugar, it might not be as important. It seems people usually run sugar motors at lower pressures anyway.

Be careful with PVC. If it goes, it makes plastic shrapnel, doesn't show up on X-rays.

You really need a LEUP for sugar motors? ppffftttt... How stupid.
 
Last edited:
Last edited by a moderator:
I put together mine using in Openscale. Connects right to your load sensor and also has a USB port for connecting to a tablet or laptop for logging

The Openscale board looks really interesting, but the info on Amazon says it was designed for static loads. Did you have to change anything to make it work for highly dynamic systems like a motor burn? What software are you using to log the data?
 
we use a $30 DataQ unit that attaches to a PC via USB. We also have two USB to Ethernet adapters and 100 ft Ethernet cable so the test stand sits away from the PC. The DataQ unit can take 4 inputs so we have the load cell and a pressure sensor wired into it. That way we get the thrust and internal motor pressure at the same time. It's then easy to plug into spreadsheets and get the a & n numbers for the propellant.

We use the same size motors (2g 38mm) for all tests since the a & n numbers can be plugged into burnsim and any size designed from there.
 
That DataQ board looks pretty decent. I wouldn't have thought that 10bit 240Hz would be sufficient, but if it works for you I won't argue it. I may well have succumbed to spec inflation. :)

I'm trying to avoid having a windows box present all the time though. That's one annoying thing about the Analog Devices eval board. It uses a custom USB Windows driver that won't work on newer Windows versions. I couldn't get it to load at all on Windows 10, even with driver signature checks disabled. And it doesn't work under Virtualbox. So I had to dig out an old laptop with XP installed. That works, but it's clunky. I did get a load cell wired up and can draw graphs of the weight, so I know the hardware works at least. I'm playing with getting it working on a Raspberry Pi Zero ($5!) over SPI. If I get it to work, I'll document it here for everyone. The long term plan is to do a web-based UI kind of like the Eggtimer Quantum, super simple and phone/tablet friendly, to record/retrieve the data and fire the motor. Then I can get a cheap USB WiFi dongle to connect up with. But that's a ways out. The same WiFi module Eggtimer uses could probably do it as well, but there's a driver for Linux I'm going to try to use so I can take advantage of the built-in buffering code and such.
 
The Openscale board looks really interesting, but the info on Amazon says it was designed for static loads. Did you have to change anything to make it work for highly dynamic systems like a motor burn? What software are you using to log the data?

It suits my purpose for crude sugar motor profiling. The report rate is 500 ms (I think it was 470 ms, but I'm not in front of it right now), so yes, it's probably too slow for really accurate thrust curves. But it works ok.

The board comes with build in software called Openlog. Has all the features needed to tare, calibrate, and report. Then, I just connect to it over USB using Putty (or any other telnet app) with serial connection to the right COM port. Save the output to a text file and use Excel or Google sheets to create the plot.
 
Argh... Just realized I can't run both sensors from the same ADC. Kinda my own fault, one is millivolt scaled the load cell, the other is full scale 0.5-4.5. And the gain amp isn't selectable per channel. pffttt... So I can do one at a time, or switch one of them to something else. Since those HX711 boards are cheap, I might try one of those for the load cell when I want both, and maybe use the AD board for thrust only tests if I want a more accurate thrust curve.

I guess I could try to scale down the pressure sensor just to amp it back up, but that just seems like a lot of work to add a ton of noise.
 
That is where the 4 channel DataQ works so well. We actually have an amplifier board between the load cell and the DataQ to up the signal to a 0-10V input to meet the +- 10 V input that the DataQ uses. The pressure sensor is already 0-10V so it plugs directly in. The software supplied with the DataQ allows you to configure everything, save the files and then view them in a waveform viewer. That allows exporting the data to various file formats including Excel spread sheets.

I understand you want to be able to use simple devices, android, iphone, etc. for capturing the data, but you might want to consider sticking with a laptop and just worry about making the connection to the stand simple and/or wireless. The data manipulations and formatting can be very important and it's hard to beat an actual computer for that. Especially if you aren't going to be writing software and apps for the devices.
 
It's not so much to do the actual capture on the small devices. The capture would be on the onboard machine, in this case the Raspberry Pi. It would just buffer and save to SD card. The phone/tablet would be more of a remote control than anything else. My plan was to capture raw ADC data, then use a real computer or custom app to convert to real units etc after the fact. If I know the conversion curve from calibration testing, that shouldn't be a big deal or use much CPU. The pressure sensor is a bit of an unknown, I don't have a way to generate a verifiable pressure above about 175psi as that's as high as my compressor goes. Oh wait... My Nitrous tank... :) But the info the seller provided shows a pretty linear curve, so I should be able to calculate the rest of it. I fully expect to write custom software, that's my day job, so no big deal there.

What amp are you using for the load cell?

Part of my exploration here is to attempt to create an inexpensive, reproducible electronics package that can manage most of what we would need for small motor propellant characterization testing. Once you know a/n and kn, you can design for larger motors without having to do a lot of test burns. The idea being to get testing into the hands of more would-be motor builders. I mean, a PiZero at $5, HX711 2/$4 in the US, about $1/ea from China.. I found another ADC that might work well for pressure as well, another $5 or so. The catch is making it work reliably and easily. My more expensive ADC board can serve as a baseline test to make sure the cheaper ones do a decent job. I could probably whip up a simple AD7190 breakout too... I'm kind of surprised nobody seems to have done it...
 
Why do you think this is needed? The ATF has nothing to do with transportation.
"In the United States, rocket candy motors are legal to make, but illegal to transport without a low explosive users permit."

(
https://en.m.wikipedia.org/wiki/Rocket_candy) It's in the introduction, 6th paragraph.

I know, Wikipedia untrustworthy et cetera. But unless you can find a reliable source that claims otherwise, let's err on safe side, especially pertaining to laws. (and safety, of course.)
 
"In the United States, rocket candy motors are legal to make, but illegal to transport without a low explosive users permit."

(
https://en.m.wikipedia.org/wiki/Rocket_candy) It's in the introduction, 6th paragraph.

I know, Wikipedia untrustworthy et cetera. But unless you can find a reliable source that claims otherwise, let's err on safe side, especially pertaining to laws. (and safety, of course.)

hmm, must be because of potassium nitrate...one more reason to mix AP motors instead. I'll look into this more later, I have the orange book on the shelf since I have a manufacture of explosives license.
 
hmm, must be because of potassium nitrate...one more reason to mix AP motors instead. I'll look into this more later, I have the orange book on the shelf since I have a manufacture of explosives license.

I think that it's the mixed fuel that is illegal to transport.
I can buy (hypothetically) a bottle of stump remover without one and KNO3 can be shipped without hazmat.
Same with sugar.

The issue with AP was that (if I recall correctly) it could detonate under the right conditions, even without mixing it with other compounds. The oxidizer and fuel of rocket candy are safe unmixed, but together, they pose a hazard as they burn quite energetically. (As evidenced by the usage in rocket motors.)

However, I'm just speculating. Check the book and see if it says anything about it. (Wikipedia might have misinformation)
 
Have you seen this Raspberry Pi ADC hat ( https://www.robotshop.com/en/raspberry-pi-high-precision-ad-da-expansion-board.html)? I've been pretty impressed with the hardware; up to 24 bit 30khz sampling 1 channel, multiplexing allows up to 8 channels at reduced speed/resolution. There are python libraries that work with the ADC, which when combined with a python flask app, is a really fast way to develop a wifi enabled data acquisition system.
 
Have you seen this Raspberry Pi ADC hat ( https://www.robotshop.com/en/raspberry-pi-high-precision-ad-da-expansion-board.html)? I've been pretty impressed with the hardware; up to 24 bit 30khz sampling 1 channel, multiplexing allows up to 8 channels at reduced speed/resolution. There are python libraries that work with the ADC, which when combined with a python flask app, is a really fast way to develop a wifi enabled data acquisition system.

I had not. Thanks for the info. I'm unsure if it has enough gain for a load cell, but it should work well for most pressure sensors.

I'm a little curious about the required sample rate. I will have to try a real test at a few speeds to get a better idea.
 
I had not. Thanks for the info. I'm unsure if it has enough gain for a load cell, but it should work well for most pressure sensors.

I'm a little curious about the required sample rate. I will have to try a real test at a few speeds to get a better idea.

Keep in mind that you may not need to gain the load cell if you have 24 bits of resolution. And since you control the full scale range with you reference voltage, you can end up with extremely high resolution without any analog gain. Additionally, the ADC does have programable gain settings.

All that said, it may not be the right hardware for this project....
 
I finally got to the point where I can start the data capture and press on the load cell to get some numbers.

It's an Arduino-based custom PCB and software that reads the HX711 and writes to a microSD card. The HX711 should be able to read about every 12.5ms but right now I see around 30ms due to my slow code. Here are the design and code files I am working on: https://github.com/jbeuckm/thrust_bucket

UPDATE: Removed some debug traces and the average looks like 11ms per read or almost 100 measurements per second.

Screen Shot 2017-02-13 at 2.32.23 PM.png
 
Last edited:
What do you think of this hardware setup? A pipe clamp will snug the grips to the motor and keep it from jumping off if the plug blows or something pushes up.
motor_holder.jpg
 
Here is my test controller hot glued to a scrap of plywood.
IMG_6369.jpg
I'm pretty happy with the result! Looks like I have a mid-range F class motor.
Screen Shot 2017-02-22 at 10.29.40 PM.png
 
Nice! I'm playing with ideas for mounting a load cell to my setup. I have pressure working well, then fell down the rabbit hole that is calculating a/n values etc.. :) I'd like to do thrust next, just need to come up with a setup I like for it. I kind of like your all-thread setup, adjustable for different size motors.
 
In a bunch of the posts above, I saw references to using DataQ devices. Those were my first choice for various projects back in the 1990's, but once the world went to USB instead of serial, I switched to MCCDaq products. I have a few 1208 and 1608's and really like them. In fact, I have a commercial testing machine that I got earlier this year and when going through training on it, I saw a few hints and asked the guy if it had a 1608 in it. He said yeah, that's what we. . . wait, how'd you know that? We talked about a few of the projects I'd done over the years with it and it actually made the training go much better, as he knew he could say anything and I would likely understand it vs. being totally green for control system/data acquisition projects. He also knew I was going to take the machine apart as soon as I got it to the shop and write down all of the components used so I could get spares myself if needed. He gave me the build BOM and said there are a few items we do custom, so you'll have to come back to us for those, but most of it is COTS.

Anyway, depending on the project, I think a 1208 or 1608 could be a great fit. If 12-bit data is good enough, save the cash for sure, as the 1608 isn't cheap. Note also that the 16 bit modules seem to need more aggressive signal conditioning, which isn't overly surprising, but just plan for it and solve the problem before it becomes a problem. The 1208 seems to be a bit more tolerant. Also, the analog and/or digital outputs are helpful for projects like these.

Just my opinions. I find them to be a reputable company and I find the function vs complexity of their USB products to be very approachable. I'm not a Raspberry Pi guy, so I can't speak for those, but they may be very good as well. Note that there are some limitations with their free software (or at least there used to be), so make sure the functionality you want is there or you might have to buy the expensive version and that is lame. . .

Sandy.
 
I considered the HX711, I'm curious what your data looks like when you get some. I went with an Analog Devices eval board which has the ability to run the load cell and a pressure sensor. The down side is software sucks so I'm working on that as well. I was also wondering if I thought 80 samples/sec would be sufficient. For thrust it probably is, it might miss short pressure spikes though. With sugar, it might not be as important. It seems people usually run sugar motors at lower pressures anyway.

Be careful with PVC. If it goes, it makes plastic shrapnel, doesn't show up on X-rays.

You really need a LEUP for sugar motors? ppffftttt... How stupid.
FWIW I've tried running a DATAQ at higher acquisition rates, and found that 200 Hz is just about right for my arrangement; it also gives a convenient 0.005 seconds per measurement. I get a lot of noise at anything over 400-500 Hz. However, I'm using wired hookup and it's possible that the wire is picking up a bit of noise from overhead power lines.

The DATAQ free software isn't the best in the world, but for someone who tests only occasionally it's quite adequate. And the newest version allows automatic porting to EXCEL, which is convenient.

Best -- Terry
 
HX711 is also what I am using for my teststand and those work great especially the red board with a metal cover that you can ground

teststandV2-1.jpg
 
Back
Top