Thrust Meter/Test Rig Prototype Ver1.0

[lloyd]

'Seems like multiple effective ways the separate the dermal tissue from the carcass of a feline!

 

Lloyd

[Peret]

"We end up with 2.1 kg/sec for the total impulse."

 

Newton seconds, or kilogram meters per second. The units of impulse are the units of momentum.

[stix]

. . . Newton seconds, or kilogram meters per second. The units of impulse are the units of momentum.

 

Yeah fair enough, thanks. If you look at the graph, under the titIe you will see that I've included the total impulse as 20.6 newton-seconds. I should have just stuck to newton-seconds. I am aware that newton-seconds is the standard for altitude calculations, so all good. What about pound-seconds, or should it be pound-feet-seconds?

 

In any case, for this test the main point of interest was that the number 2.1 was consistent over the four calculation methods. The units may well have been "cats carcasses" for all I care. Now, lets see... 4 tests x 2.1 cats carcasses = 8.4. That leaves 0.6 of a carcass unaccounted for. Well that makes a lot of sense because when I arrived home from work this afternoon I noticed a horrifying stench emanating from my residence.

 

I'd better go off and sort it asap out otherwise the neighbours may become suspicious, and think that it has something to do with the sudden disappearance of some cats in the area recently. I certainly don't want that happen because I've got another series of tests coming up.

 

My apologies if I've offended any cat-lovers

 

[EDIT] "If only he put as much effort into learning correct terminology as he does into his ridiculous and stupid stories - he may well have gotten somewhere by now."

 

That's weird - I think one of my old science teachers has hacked into my account!

Edited April 26, 2016 by stix

[Peret]

Well I'm a pedantic bastard and I particularly like people to understand and express properly the units they work with. It's not immediately obvious that Newton seconds is momentum, but once you grasp that, it becomes immediately clear that dividing the impulse by the weight of the motor tells you how fast it should be going, or would be going if it didn't have to fight against gravity and air resistance.

 

N.s is kilograms meters per second. The imperial equivalent is pounds feet per second, or tons furlongs per fortnight if you prefer.

[stix]

"tons-furlongs-per fortnight" I like it but not very practical.

 

Yes, I accept that it's important to understand and express properly the units one works in otherwise it does make it difficult to communicate a result - I'll try to stick to the correct units in future.

 

As you've already pointed out in a previous post "When you present the output of your rig measurement it needs to be expressed as impulse, in Newton-seconds (kg.m/s), otherwise the rocket guys won't be able to use it". Yes, N.s seems to be the standard unit of impulse to input into altitude calculations. It's been a while since I've done altitude calculations, the last time I took the easy way and used some open source software called "OpenRocket".

 

Is it agreed that the STIX-T1000 graph shows a total impulse of 20.6 N.s?

[dagabu]

Well I'm a pedantic bastard and I particularly like people to understand and express properly the units they work with. It's not immediately obvious that Newton seconds is momentum, but once you grasp that, it becomes immediately clear that dividing the impulse by the weight of the motor tells you how fast it should be going, or would be going if it didn't have to fight against gravity and air resistance.

 

N.s is kilograms meters per second. The imperial equivalent is pounds feet per second, or tons furlongs per fortnight if you prefer.

 

Pete, you say that like its a bad thing?!?

 

This is one of the things I lack almost completely and I love to read these conversations unfold so i can learn more about this hobby. Thanks for all of your input to this thread, fascinating stuff!

[OldMarine]

I've been reading this thread and WSM's adventures in perchlorate production and though I understand little of it I've learned much. Keep it up long enough and we'll get it!

[stix]

 

Pete, you say that like its a bad thing?!?

 

This is one of the things I lack almost completely and I love to read these conversations unfold so i can learn more about this hobby. Thanks for all of your input to this thread, fascinating stuff!

 

 

I've been reading this thread and WSM's adventures in perchlorate production and though I understand little of it I've learned much. Keep it up long enough and we'll get it!

 

Thanks guys for your interest.

 

I know what I'm doing has all been done before. By myself 25+ years ago and by many others at the same time, and years before that.

 

I like to get to the bottom of things and I can assure you that I'll take things to the "nth degree" to get there.

[stix]

. . . N.s is kilograms meters per second . . .

 

I'm confused about that statement. I'm not saying it's wrong. There must be a piece of the jigsaw puzzle that's missing - I don't have it.

 

Looking at this: http://whatis.techtarget.com/definition/kilogram-meter-per-second

"a kilogram-meter per second is the equivalent of a newton second."

 

and This: https://www.google.com.au/#q=convert+kg+m%2Fs+to+newtons+seconds

"1 (kg m) / s = 1 newtons seconds"

 

If that's the case then the STIX-T1000 graph calculates to 2.1 kilogram meters per second = 2.1 Newton Seconds. Which I know is incorrect. I've always just multiplied the number (2.1 in this case) by 9.81 to convert to Newton Seconds which calculates to 20.6 N.s.

as per: http://www.convertunits.com/from/kg-m/s/to/newton+meters+per+second

 

The calculated number that I incorrectly called 2.1Kg/Sec - what unit is it then? I do know that I've always used that number because I use Kilo's in the force scale. If I convert the force scale to newtons then It also works out to 20.6 N.s - all good.

 

Ahhhhhh, hang on, I've had a revelation - as I'm writing this down and going through the process again, I think I see that lost piece of the jigsaw puzzle partially emerging. 2.1Kg/Sec is not incorrect and not the issue. Peret was simply pointing out that it was not the correct units of momentum and 1 Kilogram meter per second does = 1 Newton Second.

 

Perhaps instead of "bullshit baffles brains" it's a simple case of "truth enlightens ignorance", I think

Edited May 8, 2016 by stix

[Peret]

It's just unfamiliar units. I don't think in Newtons myself - I regard the Newton, and other derived units like it (Pascals, anyone?) as abominations thought up by committees with a list of names they want to honor and nothing better to do. I'm much more comfortable with fundamental units like kg.m/s^2. But here's the derivation -

 

P = mf, or force = mass times acceleration

1 Newton is that force which accelerates a mass of 1 kilogram at 1 meter per second per second ----------- (1)

 

Momentum = mass times velocity, and velocity is meters per second, not meters per second squared.

So if you multiply both sides of equation (1) by "second", one of the "per second" terms on the right hand side cancels and we get -

 

1 Newton second is the momentum of a mass of 1 kilogram moving at one meter per second.

Edited May 19, 2016 by Peret

[stix]

It's just unfamiliar units.

 

Appreciate the clarification Peret. It did bamboozle me for a while.

 

I get the part regarding acceleration as in meters per second per second and velocity being meters per second. The rest of it I'll have to take some time to understand it.

 

My level of physics & math isn't that good - I flunked both subjects in year eleven, but I've always had a great interest in science and math - go figure. My usual mode of operation is via the "Empirical Evidence" method, using some bizarre measuring contraptions, then worked back from there. Arse-about I know, but it's enabled me to make some successful rocket motors.

 

Cheers.

[kramrocket]

Great to see you on here edbrown, really cool indeed !!!

I phoned you guys at Estes in the early nineties to ask about your nozzle formulation, and you guys gave me so much info, thanks again !!!

[Baldor]

Sorry if I'm resurrecting an old thread.

 

What about this as a data logger? https://www.sparkfun.com/products/13261

 

It can only log at 80Hz, but it's a plug and play solution. Will it work? I have no problems building a more capable data logger from scratch, but for now I like to play with rockets, not electronics.

 

I'm planing on testing 15, 19 and maybe 25.4mm BP core burners (Sorry, I'm European, so metric for me). I will make my own tooling, and will like to characterise it. What will be an adequate load cell for this motors?

[dagabu]

Two things:

 

-Software

-Loadcell

 

The data logger you link to is a great tool, I used something very similar last year when making an auto loader but it lacks in all the stuff that matters. BTW- Peret offers the software for free...

[Baldor]

-Software: If I can dump the colected data to a text file, is enough for now. As I said, I have no problem working with microcontrollers and analog circuitry, but I'm a little tired of electronics for now and prefer to work in the mechanic aspects of this. I will take a look at Perets schematics, seems prety strightforward.

 

-Loadcell: This was one of my questions. What will be an adequate max weight for, say, 1" BP core burners? I made a few 12mm core burners with a very rudimentary tooling (Just a 6mm steel rod and wood ramers). Now I want to make some more refined tooling, and characterise it. (Test different compositions, different nozzle diameters, different paper tubes..., just for the pleasure of doing things with my hands.)

[stix]

A 20kg (44lb) load cell should do nicely for testing. You can buy them pretty cheap ($15-20) off Ebay. The sparkfun amplifier should work fine.

 

Creating the contraption that mounts the load cell is the fun part. There are many ways of doing this - just make sure it's strong and sturdy. In any case, a good design can always be up-scaled to suit a larger load.

 

I almost can't believe that it was 15 months ago that I started this post. I'm still mucking around with writing software - the basis is using an Arduino development board - that project started in June 2015. More than two years back. With the software and data acquisition, I've taken a different approach.

 

My software can be used to record data (via a tethered device) or can import data from other devices, and export files. Recording and analysis is all done in the same window.

 

I'll report back in another two years when it's all finished.

 

http://i.imgur.com/9YZyDJ8.jpg

 

 

 

 

[Baldor]

This screenshot looks fantastic!!

 

And also the reason I want to do something as simple as possible in the electronics and software side. I'm currently a little tired of designing, making and programming electronics. I know that if I start something serious in electronics, I will never end tweaking it, there will always be something that can be done better, some function to add, you know... So an spreadsheet and a text data dump should be enough for me for now.

 

Only testing the water for now, before I start with the test stand I must finish the paper rolling machine, make some nice tooling, some static tests just to find the right composition, ....

[stix]

I'm pretty sh*t at electronics. That's why I've always looked for a solution that doesn't require too much of it.

 

The Arduino board is not too hard to set up. It has input/output digital and analog channels. It's like a building block where a person with limited knowledge (but great ideas) can assemble a solution.

 

My software is the interpretation of that data. I've done some programming in the past, so I have an idea of what I think is required to record the testing of rocket motors.

 

Lots of fun

[stix]

I probably should have asked the question in this post instead of creating another:

 

http://www.amateurpyro.com/forums/topic/12500-rocket-motor-software-testing-need-test-subjects-files/

 

If someone has some data, that would be much appreciated.

 

[Baldor]

Quick user review:

 

 

Easy and straightforward. I think I cant say anything better.

 

I can't test the data acquisition part of the program, since the openscale board outputs a little weird format that the program can't handle. No big deal, since I acquire the data in a Linux system. 30s editing in notepad and the data is ready to load.

 

After loading the data, input the weight and the propellant weight, trim the curve if needed (Also very easy), and you have all the data you need. (Stix promised some more usefull data in the future). The attached graph have been done in less than a minute.

 

As I said, easy and straighforward.

 

The problem with openscale should be addressed in the openscale side, is not a problem with the impulse recorder.

 

And a suggestion, but only related to my workflow: I like to tare my stand without the motor, and record the weight of the motor before and after with all the rest of the data. Could it be possible, as an option, so subtract the motor weight to the imported data?

 

Edit: Image temporary removed. Edit: Reloaded image.

Edited March 15, 2018 by Baldor

[stix]

The problem with openscale should be addressed in the openscale side, is not a problem with the impulse recorder.

 

And a suggestion, but only related to my workflow: I like to tare my stand without the motor, and record the weight of the motor before and after with all the rest of the data. Could it be possible, as an option, so subtract the motor weight to the imported data?

 

To All: Firstly, I designed the data acquisition part of the software with one main thing in mind, that is it to be able to read the incoming data from the usb/serial port in the most simple format, and that is, a basic stream of decimal numbers (in grams) with a line feed between each number - simple. The reason being that there are many contraptions out there, so there is no way I can predict what other people have.

 

So I decided, that in order to to capture the data, it must conform to at least a basic standard. That's it really. The only other requirement is that the sample rate of the attached device needs to be known. Which you should already know. If you don't know what it is, then I suggest, perhaps you take up knitting classes.

 

Neverthless, if and when I post the software on the forum, I'll be open to suggestions.

 

Baldor, you probably already know (but for others who don't), you should easily be able to edit the code that you downloaded for the openscale board.

 

Using the Arduino IDE you should see in part of the code, this:

void loop() {
Serial.print("Reading: ");
Serial.print(scale.get_units(), 1); //scale.get_units() returns a float
Serial.print(" lbs"); //You can change this to kg but you'll need to refactor the calibration_factor
Serial.println();

You can temporarily disable part of the code using the 'comment' code: //

 

This is what I would do:

void loop() {
// Serial.print("Reading: ");
Serial.println(scale.get_units(), 1); //scale.get_units() returns a float
// Serial.print(" lbs"); //You can change this to kg but you'll need to refactor the calibration_factor
// Serial.println();

Serial.println(scale.get_units(), 1);

This is the only line you really need. "println" will insert the line feed.

 

That way, instead of this:

0,kg,

1020,kg,

2500,kg,

3531,kg,

500,kg,

0,kg,

 

You will get this:

0

1020

2500

3531

500

0

 

Which will now allow the impulse recorder software to capture the data correctly (hopefully).

 

Could it be possible, as an option, so subtract the motor weight to the imported data?

 

That is possible, but I'll try to persuade you in another direction. My view is that the thrust profile curve should start at zero - it always should, like an object at rest, which it is before you ignite the fuse. A vertical test stand should behave much like a horizontal test stand - in that it should start at zero, otherwise there is something really wrong and will cause an issue if you want accurate results. That is my philosophy, and it would be hard for me to change it unless someone has a very compelling view or valid reason to do so.

 

If you already have recorded data that starts with the motor weight then you could (in excel etc) subtract that weight, but then you have to adjust for the amount of fuel burnt as well - not an easy task. Doable but I can't think of an easy solution at the moment.

 

I do understand your main concern in that you would like to measure the motor weight first whilst it's on the test stand. Agreed, of course you should be able to do that!!, after-all it IS just a fancy set of electronic scales, so why not?

 

My software will allow you to do that. This is the method:

• start the software
• power up the recording setup panel
• set sample rate (will auto show value from last known)
• set com & baud rate (will auto show value from last known)
• connect
• check (reads real-time incoming data)
• mount the motor
• read the weight
• insert the weight number into the Launch Weight input field
• TARE (ie. back to zero)
• DONE
• RECORD
• STOP RECORD

 

Seems like a lot of steps, but the software takes you through them in logical order, meaning that all preceding steps MUST be completed before continuing. Also there is a large blue arrow that points you at what to do next. There is also a "current status" reading (small blue arrow) that tells you where you are now. Not much can/should go wrong.

 

 

 

So, when the recording is complete you will/should see negative numbers at the end of the graph. Of course you should - that is the fuel lost, or the fuel consumed. You can enter that number into the propellant weight input field or use whatever you've previously weighed.

 

Now we manually trim the graph. You'll have to determine where it started and ended. Zero at the start, and negative weight at the end (fuel loss). Then after trimming we must account for the fuel lost and integrate that back into the graph, otherwise the results will be incorrect. A keyboard combination (ctrl+up arrow) will apply the "fuel loss compensation" function.

 

Now the graph will show correctly, ie. correct force at any chosen time/sample point, and all the performance & results will show correct, and everyone will be happy (well, at least I will be)

 

Baldor, your method of starting the test with the motor weight already there is flawed, it means that you are adding extra (positive) data to the overall results. Perhaps that's why in your posted example it shows a specific impulse of 88. The best black powder would normally deliver around 80. So there is something going on there.

 

Anyway, this is the longest post ever... I think I'll crack a beer or two, I hope I didn't leave anything out

 

Happy to discuss ideas, agreements, disagreements, or anything else.

 

Cheers.

Edited March 15, 2018 by stix

[Baldor]

I will try to modify the openscale as you pointed out, and try the capture.

 

If you substract the starting weight from the data acquired, you should have the same data than taring with the motor. This is what I did in an spreadsheet before importing the data. I like to have all the info possible in the captured data, so I can compare with the measurements done while making the motor. What I'm planing to do is to capture raw data from the load cell and postprocess all the data in the computer. Capture 1s of data without weight for taring. Capturing 1s of data with 500g calibrated weight for calibrating. Then mount the motor and capture raw data. All this data should be imported to an spreadsheet for normalising. I don't like the idea of losing useful data for practicality.

[Baldor]

BTW, next two tests will be done taring the stand with the motor, just to validate the results.

[stix]

. . . If you substract the starting weight from the data acquired, you should have the same data than taring with the motor . . .

 

Yes you're correct - I should have remembered because that's exactly what my software does when tare is selected. It remembers, then subtracts that number from all the incoming data.

 

If you've already recorded a datafile which included the motor weight, then you need to subtract the motor weight from each datapoint/sample. In the end, you should end up with a negative number which will be your fuel weight. The fuel loss compensation function will then adjust the graph by adding the fuel weight back in to the data and therefore ending at zero.

[stix]

. . . Could it be possible, as an option, so subtract the motor weight to the imported data?.

 

Yes, consider it done

 

After thinking about the whole scenario for a while, and doing a few worked examples, I came to the conclusion that it is worthwhile being able to tare/re-zero the data as per your "possible option". It can be easy to forget to tare (or not wish to), and although no data is lost, it would be a pain having to export the file then run through a normalizing procedure, then import the file. A real pain.

 

So now you can tare the data after recording or importing a file. The taring is done in the graph window by selecting the value with the cursor. Then CTRL+SHIFT+Z (or click the little 'Z' icon top r/h corner) and it's done in a matter of seconds.

 

Here's a 'mock' example:

 

 

The data is tared using the previous selected value and the graph redrawn.

 

You'll now notice near the bottom r/h corner of the graph a red ? warning symbol and "negative force value detected: -111gm". That's the fuel weight (theoretically). Now all that needs to be done is the graph trimmed left & right, then "propellant loss compensation" applied.

 

whoops!! btw. I just realized I made a mistake in that little message window - I left out the word "to".