I have tried to do the calculation with the example of Julian, adding a final negative value to the dataset.
What I have done is incorrect (you can see that the cumulative weight loss goes above the final weight loss, which is of course inorrect). The problem with the method I used is that the weight loss is calculated using the measured thrust, not the actual thrust. That gives negative weight losses at the end of the measurements. Even for this preliminary/incorrect calculation I used solver in excel to get the final cumulative weight loss to be zero (by varying the proportinallity constant, K).
Maybe a second correction step could be done using the corrected thrust to recalculate the cumulative weight loss. And you could add more iterations to the process, but I don’t know if that would converge to the actual solution.
I am not a differential equation expert, not even close. Many years have gone since I did any serious differential equation solving, so I might be wrong. Anyway your problem requires more numeric methods than standard differential equation solving ones since you have (discrete) experimental data that can’t be expressed analytically.
My point here is that I wouldn’t do this using Xojo.
Here you go, answer is in BOLD and as long as the two values in RED are the same, the calculation will be correct.
You can pick up the final weight by using entry J3, absolute it and use that in the calculation if you dont want to enter start weight and end weight. If you do it that way, matching values is irreverent and the calc will work on their own without any user input but you wont be able to calculate a running Mass (obviously as you’ve not entered the initial mass value)
No, you are calculating the weight loss with your “bumped” thrust, but that bumped value is not correct. The thrust is 0 initially, not 200, and close to 100 next, not close to 300. You are doing a correction to the entire baseline of the data with a constant, but the baseline of the data is not even linear (as mentioned in the first posts). That’s the difficulty of the problem here.
Just a thought but if you oriented your load cell so that you could mount your rocket engine perpendicular to gravity, you would not have to worry about weight loss and lots of hard math. And because you are not accelerating a mass (except as exhaust) force would be proportional to thrust.
You would need to mount it on something that was capable of handling a sidewards force up to 32kg (this load cell) or even up to 100Kg. You also need an independent device - some sort of friction-less sliding rail which holds the motor. Therefore you would have to secure everything to the ground - a lot of work. Or have a permanent installation, which is not viable for most people as testing rocket motors in your back yard is frowned upon
Rocket motors for amateur rocketry or pyrotechnics are best tested in a safe location away from buildings, trees and people, therefore the simplest design is like the one I’ve made - this is a common design and very portable. Therefore I would like to account for the loss of burned fuel weight programmatically.
Those motors have a deliberate short hole bored into the fuel at the nozzle end and therefore expose a greater surface area of fuel. This ensures the rocket leaves the launch rail at a good speed to ensure stability. Regardless of the burn profile, weight loss should be able to be compensated for.
Robert, I apoligise that I took your comment the wrong way. Sometimes the “tone” of written text can be viewed differently depending on the mood of the reader ~_-
A special thanks to Julen and Julian for their efforts. Julen, I don’t have an up to date version of excel, is it possible that you could export as and *.xls file or better still, use these set of numbers (although a very small sample) and see if you get the same results I did.
250
225
200
175
150
125
This burn profile is linear, meaning a constant burn rate and although it does not include an initial zero or the final negative value of 125grams, I think it should make no difference to the final result and should reveal something.
I’ve neglected to point out, which may be of interest to know is the “Average Force” or average thrust number. You’ll see it displayed in the preceding graph in red text, in the yellow panel bottom left (187.5 grams) which of course is incorrect.
This average is the main number used to determine the predicted altitude. It’s also used to calculate the “Specific Impulse” of the fuel. Meaning the efficiency of the fuel compared to its weight. That “Average” is very important.
There is a very easy way to compensate for the average being incorrect due the to weight loss. We simply add half the fuel weight to the average. In the preceding graph, that means 187.5+(125/2) = 250. Which is exactly what it should be. You may well ask, then why bother to go down this long, tedious and sometimes painful road ? Well, even though the average is correct, the actual numbers in the graph will not be.
My software enables the user to scrutinise every single sample of the recorded data. Regardless of my physical recording device, my software should be able to be used by others with other devices. I want it to be correct (or very close to).
I’ve actually come up with a formula for fuel loss compensation that works perfectly with the preceding graph. Although it’s a straight line, it can be applied to curves as well but not in the way the it needs to be. This is what I called Step 1.
So then we come back to this statement I made “the amount of fuel consumed is directly proportional to the thrust produced” I think this is a reasonable assumption and better to apply that, than nothing. - you don’t have to be a rocket scientist to understand it.
Yes, this post is long, but don’t forget, you only had to read it - I had to write it!! So to finish on a lighter note, this is a good one by Larson:
Steve, I can only apply the method I proposed above if the final weight loss is known and the thurst is 0 in the end (which you would get in an exprimental measurement). Here is the excel file in an older format: https://dl.dropboxusercontent.com/u/3800071/Forums/RocketThrust.xls
Anyway, your example is a simple one and it doesn’t require my calculations. Can you share an experimental curve the actual thrust is known for? We can check the method with it.
I understand it is not practical to mount the rocket horizontally but that way not only you could masure your thrust, but if you added a second (vertical) load cell you could also measure the weight loss simultaneously.
What is the price of the load cell you are using? Where can I get information about it? Thanks.
A second load cell would also require a second load cell amplifier. Too much messing around. The user should measure the weight before and after firing. This weight is then input into the program, or use the negative weight as calculated by software.
The Arduino converts the analog signal to digital and streams it to the usb/serial port, which is then connected to the usb port of a computer and read using my program.
I don’t have dropbox or similar so I’ll just post the data in code (sorry) fortunately there is only 101 lines. This test is 1 second, recorded at a sample rate of 100Hz with a resolution of 1 gram.
Download again the excel file, it contains the new data. Check the second sheet.
Two thoughts on this:
1- You are trying to correct for a 1% error. Is your load cell that precise? Do you calibrate it? For different weights? Maybe a linear correction is enough and you don’t need to bother with further precision. Check the big graph on the picture.
2- The weight loss is not linear, so the average of the weight loss is not equal to half the weight loss (the 40/2 correction you are using). Check the small graph on the picture.
Sorry, I have been meaning to add (and forgot every time) that I am using Solver in excel to get to the correct value of the proportionality constant between thrust and weight loss. You don’t have that in xojo, and I don’t know of nay third party class/plugin that provides that functionality.
These last few days I’ve been mucking around with an old version of FileMaker (2002) in order to come up with a way to verify my data, or any other data - it’s all working good. That version of FM can’t draw graphs, but calculations can easily be done.
I’ve download your new excel file and compared Tcorrected data to my normalised version which was a basic linear correction and they aren’t too far different for any concern. As you suggested, no need for further precision. This is good news.
The averages are close enough: Tcorrected at 2936.4 and Linearised at 2941. A difference of 0.16%, I can certainly live with that. Also the Peak Thrust was very very close: 7403 compared to 7405. Not bad at all - very very good
The load cell and amplifier are calibrated via two potentiometers on the amplifier. One for span, the other for zero. A known weight is used and between span and zero, adjusted accordingly. The reality is that this so-called “known weight” was measured on my el-cheapo semi-pro scales. I’m sure they’re not perfect. There are also other variables like wind or inconsistent fuel burn, also ±2.5gm coming from the device itself.
I forgot to mention that if you didn’t do your tests, then the question would have lingered unresolved like sharp splinter digging it’s way into the back of my mind, and therefore sidetracked me from finishing my software.
