Launch rail velocity - simulated vs actual

[jqavins]

Nice rig. Two comments.

I think you're right that the aerodynamics of the two rockets don't matter for rail exit speed. I don't think you said that their masses are the same, and that matters a whole lot.

The speed on the drop test is not so known, because friction between the rail and the buttons will make it lower than the calculated freefall value. How much? Probably not much, but it's hard to say.

Come to think of it, if the RS and OR predictions turn out to be high, that may well be the reason, or part of it. They try to predict aerodynamic drag, but I bet the don't consider launch guide friction.

 

[Alan15578]

I created a set-up using an IR break beam sensor and Arduino. The code is done and seems to work. There's a lot involved with this project, but basically looking at simulated vs actual rail exit velocity. Using a 1010 rail (1") which accommodates rockets with 1/4" rail buttons first. Data collected will be mass of the rocket, distance between buttons, motor, and the rail length. And, a basic description of how the rocket flew off the rail. I would like to have a corresponding photo sequence of the rocket exiting the rail, but I would need some help with that. I'm thinking of using a new 6' rail for these tests.

I uploaded the Rocksim file for a couple Madcow rocketry kits and tried some motors. The two kits for example sims I'm using are the Tomach and the Patriot. Both are 38 mm motor mount, but different in airframe diameter, length, and number of fins. For the same motors, I obtain the same rail exit velocity, which makes sense because it's at launch, so different aerodynamic forces are not significant. Correct?

Here's some rail exit velocity data for the Tomach as a 6 lb. rocket (without motor):
I154J 40 fps
I211W 57 fps
I600R 94 fps

If the buttons were 24" apart, the elapsed time would be 50 ms, 35 ms, and 21 ms.

I'm going to get a 8' rail and drop a block of wood with rail buttons 12" apart and see what the measured vs. known free fall velocity is. The break beam sensor will be at the bottom of the rail of course. Maybe electromagnetic release of the block at the top of the rail; that would be fun. This is also where using a camera with elapsed time would be useful. I'll look into the app for my phone.

I did run into an issue with measuring outside in direct Sun because it uses an IR sensor. But, I'm working through that problem. I added some short plastic tubes on the IR source and detector and will try again tomorrow.

View attachment 427426View attachment 427427View attachment 427428View attachment 427429

Guys, just put a small rubber wheel on the rail or rocket and run it through a tachometer.

 

[Richard Dierking]

Nice rig. Two comments.

I think you're right that the aerodynamics of the two rockets don't matter for rail exit speed. I don't think you said that their masses are the same, and that matters a whole lot.

The speed on the drop test is not so known, because friction between the rail and the buttons will make it lower than the calculated freefall value. How much? Probably not much, but it's hard to say.

Come to think of it, if the RS and OR predictions turn out to be high, that may well be the reason, or part of it. They try to predict aerodynamic drag, but I bet the don't consider launch guide friction.

Thank you.

Yes, I forgot to mention that I made the two sim'd rockets with identical mass at liftoff.

Good point about the drop test. How about, I drop the object without the buttons inserted in the track too. I could measure how long the beam is broken for the velocity on that one. For both, do it a bunch of times.
Keeping in mind that dropping the test object with the rail buttons is not the same as hanging a rocket on a rail with buttons, or say conformational rail guides.
I'm sure you have inspected rail buttons after even one launch. Whether they can spin or not, doesn't seem to make much difference. It's interesting. Maybe some motors force the guide into one side of the rail? Or, the blast deflector forces the attached pad one direction and the rocket is forced against one side of the rail? And, how about leaning rockets on rails?
There's a lot of implications for this. That's why I want to create this set-up and see where it leads.
I've seen too many rockets where the exit velocity seemed low compared to what was expected. Or, maybe this is just perceptual? It seems to me that as soon as that rocket goes over 1 to 1 it's going to start moving up and I don't think the pressure up and this initial movement is completely taken into account.
If I get lower actual exit velocities, the next thing I would like to do is place a small break line between my rocket and the pad that would release at a predetermined load.

Mechanical means of measurement, even roller type microswitches, are out for me in these first tests. I don't want to have anything touch the rocket except the rail during launch. For one thing, most of these rockets will belong to other people.

 

[Richard Dierking]

I tried the newest set up in direct Sunlight this morning and it seems to work well. This time, the IR LED and Sensor have a carrier frequency of 38 kHz. I used a brass rectangular tube for the sensor and also placed a round plastic tube around the 5 mm IR LED (photo). I can install the set-up on any 1010 rail. Next, I'm going to test the set-up and programming with drop test using an 8' rail and also video the drop to confirm the velocities are the same.

Here's the code:
/*
Rail_Exit_Velocity
Richard Dierking
Version 08-12-20
Using a I2C LCD (4 wire) for display
Result is displayed in microseconds
*/

#include <IRremote.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 16, 2);

// the IR sensor is connected to pin 2 on Redboard/Uno
#define SENSORPIN 2

// the IR LED is connected to pin 3 and modulated to 38 kHz
#define PIN_IR 3

// status HIGH is tripped, LOW is unbroken
int sensorState = 0;

// how many times the sensor has been broken
// Trip is 1 at the start saved in microseconds
int Trip = 0;

// s is start, e is end, d is difference
float d = 0;
unsigned long s = micros();
unsigned long e;

IRsend irsend;

void setup()
{
// initialize the sensor pin as an input
pinMode(SENSORPIN, INPUT);

lcd.init();
lcd.backlight();
lcd.setCursor(0, 0);
lcd.clear();
lcd.print("Ready");

Serial.begin(9600);

irsend.enableIROut(38);
irsend.mark(0);
// Delay a couple seconds for the sensor to stabilize
delay (2000);
}

void loop()
{

sensorState = digitalRead(SENSORPIN);
if(sensorState == HIGH)
{
Trip ++;

if (Trip < 2)
{
s = micros();
lcd.clear();
lcd.print("Start");

sensorState = 0;
delay (1);
}
if (Trip = 2)
{
e = micros();
d = (e - s)/1000;
lcd.clear();
lcd.print("Time ");
lcd.print(d,0);
Serial.println (Trip);
}
}
}

 

[Chad]

Good point.
There's a dispersion of flight off a rail. I've seen it. That's when I starting thinking the sim velocity off the rail wasn't what was happening. I'm thinking the dispersion is greater the shorter the rail. I kind of came to this conclusion for leaning pads away from spectators like we should do (at institutional types of launches). Anyway, if you lean the pad away and rockets still seem to go over the crowd, the dispersion is too great and you have to lean the pad farther to account for the dispersion. Correct? What if you could use a longer rail and lean the pad away less? Or, would it make no difference?

See, I'm getting better Steve, I loaded your message while I was typing this one.
Being retired, my time is priceless. The problem is my capabilities.
I appreciate the help on this. It really helps me.

i've seen this too, at a launch i was asked to point the rail away from the crowd by the RSO despite my whining. I did and wound up right over the crowd as i expected. What I think happens is if you launch at an angle a stable rocket will weather cock back the other way as soon as enough airflow gets over the fins. An over-stable rocket will probably just keep on going and gravity turn away from the crowd as expected.

What i prefer, but not my call, is always launch straight up and just keep enough distance between the crowd and pad. All my rockets are designed to correct themselves to go as straight as possible. Launching at any angle isn't accounted for in my designs and so all bets are off IMO

edit:i could be wrong here, i've seen this documented but can't find it

 

[UhClem]

d = (e - s)/1000;

Make that divide by 1000.0. If you are going to end up as a float you really ought to do the calculation that way. Unless you are happy with 1ms resolution after measuring with 1us...


But you are making some assumptions about what your sensor data will look like and if you are wrong you get nothing. Better would be to simply record the sensor state at whatever sample rate meets your needs. Then you can process the data later, removing those pesky glitches that always seem to turn up.

You don't mention any part numbers but the 38KHz IR receiver I looked at doesn't seem to be designed for long continuous pulse bursts. So may not work as well as you like.

 

[UhClem]

edit:i could be wrong here, i've seen this documented but can't find it

Probably https://www.nar.org/wp-content/uploads/2014/08/launchsafe.pdf

 

[Richard Dierking]

Make that divide by 1000.0. If you are going to end up as a float you really ought to do the calculation that way. Unless you are happy with 1ms resolution after measuring with 1us...


But you are making some assumptions about what your sensor data will look like and if you are wrong you get nothing. Better would be to simply record the sensor state at whatever sample rate meets your needs. Then you can process the data later, removing those pesky glitches that always seem to turn up.

You don't mention any part numbers but the 38KHz IR receiver I looked at doesn't seem to be designed for long continuous pulse bursts. So may not work as well as you like.

Thank you, I'll reformat the number. I want to see what the drop tests show along with the video analysis before I go much farther. I have to see the accuracy and precision of this set up.
I've had one unexplained glitch so far.
I will be taking out some lines of code that are unnecessary, like displaying "Start" which I used for development but only displayed less than a second during actual use. And, I had variables displayed on the serial monitor at times. I would appreciate hearing how to improve the program because I only have a little experience coding with Arduino.

When I use the set up, I'll turn on power when the rocket is loaded and upright on the rail, the program will initiate with "Ready." Then, immediately after launch, I'll read the display and turn off the power until the next rocket. Or, if they are being launched quickly, I can hit an external reset button on the enclosure to reinitiate the program.

Rails will be 6' or 8' long. And, they are 1010 (1/4" rail buttons).

Before launch, I'll collect the mass of the rocket, distance between the rail buttons, and what motor is being used. Take a photo of it loaded on the rail, and hopefully, also have video at 240 fps at launch.

About 20 years of amateur rocketry has tempered my expectations.
Also, I have already ordered a laser break beam sensor.

Thank you for the link to the document! I'll read it this weekend.

 

[jqavins]

If you're able to get 240 frames per second video, that's about 4.17 ms per frame. Expected rail exit speed in the ballpark of 50 feet per second means (in the ballpark of) 20 ms per foot, or 4.8 frames per foot. With marks 2 feet apart you've got 9.6 frames to cover that distance. For a range of frame counts, you would get these results.

Frames	Speed (fps)	Approximate precision (fps)
7	68.6
8	60.0	8.6
9	53.3	6.7
10	48.0	5.3
11	43.6	4.4
12	40.0	3.6

(Pardon me, I don't know how to better format the table.)

Isn't that good enough?

The greater the speed the worse the precision. Precision can be improved by spacing the markers further apart, but since the rocket is continuing to accelerate that would hurt the accuracy.

I don't mean to knock your work. It's a nice setup you've built, good work. I just think it's overkill.

 

[Blast it Tom!]

I dunno, I find it all kinda fascinating. I just spent a month on a job in Montana, much of it on standby, swapping "war stories" with my data acquisition engineer, who spent a lot of his career in high speed data acquisition, where you're acquiring photos and other data an 10,000 fps or more for crash analysis, airbag deployment, performance, handling etc. Now THAT would be something to see! (Side note, he was amazed I needed data points only every 15 minutes, and even that was a bit extravagant on my part!)

When I first started into rockets over 50 years ago, as a (dim memories...) maybe 10 year old or so, the idea that we'd be launching digital video recorders, GPS sensors, and so on in our rockets was of course completely unheard of. Recall the old Estes Camroc with the disc of film you had to attempt to mount in complete darkness by feel in the field with some sort of bag over your arms?

One thing that I really liked as a youngster was discovering how you could design these things using mathematics. But transients are difficult! So what we want to do is draw the youngsters in, and I think there is no better way than to give them a very exciting demonstration of F=ma. See how close the measured weight and the thrust curve matches those first few feet, etc. Do two, three or four flights using the same engine compare well? Always, the better we can calculate and predict, know our "scatter", etc. the better off we are.

Then you can get into all sorts of things - rod bending & whip, the possibility of rail chatter, esoteric things like that that may be moot or seemingly useless, and may well turn out to be so... is it overkill? You bet! But as various folks among us ferret out these little things pursuing the application of their passions, we all benefit.

 

[Richard Dierking]

I appreciate all the info on using video. I'm not offended at all. I appreciate the time people have spent helping with this. Back when this thread started, I wasn't going to use video but was convinced to give it a try.
Also, please do not forget the entertainment factor; which is so important for many topics here on TRF. So, creating the IR set-up and using it amuses me greatly. Developing it has allowed me and others to think of other related things.

Maybe a good fairly recent example is the person that posted about using titanium all-thread. I initially posted on the subject and said that 6061 aluminum worked fine and why use expensive titanium. Well... but how many times do some of us get the opportunity to use titanium? There's a cool factor you can't deny.
I ended up getting some titanium hardware and looking forward to working with it.

I'm waiting to receive the 4 conductor cable to complete the setup. Already got the 8' rail for the drop tests. Switching to working on a small test stand for now.

 

[neil_w]

There is a lot to be said for doing things in a way that you find satisfying or entertaining or whatever, given that this is a hobby. That certainly drives a lot of my own build strategies and techniques. Also good to know when you're doing something somewhat above and beyond what is strictly necessary. All in balance.

 

[jqavins]

Also, please do not forget the entertainment factor; which is so important for many topics here on TRF. So, creating the IR set-up and using it amuses me greatly. Developing it has allowed me and others to think of other related things.

There's absolutely no denying that, nor would I dream of trying.

 

[Richard Dierking]

lso good to know when you're doing something somewhat above and beyond what is strictly necessary. All in balance.

Yes, and then there is the issue of how much money spent on a project. Fortunately, you can tinker a bit with hobby level electronics and the components aren't expensive.

 

[Ez2cDave]

Despite all of the "technology", the one variable you cannot control or adjust for is Motor Performance. The innate differences, from motor to motor, or "sluggish ignition" ( i.e. - possibly caused by an igniter shifting position ) simply can't be predicted.

Dave F.

 

[Richard Dierking]

Good point Dave. I had considered the affect of different ignition methods and motors.
Perhaps we'll see some interesting results. I should also record the type of igniter used.
What if results are all over the place? Don't know.

And, hey, this may not work out. I'm always very candid about results. Good, bad, happy, or sad, I'll post it.

I realize that there are people that aren't exactly embracing the method I'll be using. That's cool. However, if I determine the set up is reliable, I'll be able to get the info very quickly.
Rail exit velocity (fps) = Rail button distance/(Time/1000).
Time in ms, and rail button distance in feet. Might also be a correction factor, but currently, I don't know.
There's a couple of things, like how much abuse the sensors at the top of the rail will be able to withstand. Keeping in mind that there will be some blast from the motors as the rocket passes by. I will not be starting out by measuring rockets that have sparky motors!
Will the radiation from the burning motor affect the sensor?

 

[Ez2cDave]

Good point Dave. I had considered the affect of different ignition methods and motors.
Perhaps we'll see some interesting results. I should also record the type of igniter used.

What if results are all over the place? Don't know.

And, hey, this may not work out. I'm always very candid about results. Good, bad, happy, or sad, I'll post it.

I realize that there are people that aren't exactly embracing the method I'll be using. That's cool. However, if I determine the set up is reliable, I'll be able to get the info very quickly.
Rail exit velocity (fps) = Rail button distance/(Time/1000).
Time in ms, and rail button distance in feet. Might also be a correction factor, but currently, I don't know.
There's a couple of things, like how much abuse the sensors at the top of the rail will be able to withstand. Keeping in mind that there will be some blast from the motors as the rocket passes by. I will not be starting out by measuring rockets that have sparky motors!

Will the radiation from the burning motor affect the sensor?

If results are "all over the place", and your measuring gear is accurate and consistent, you will be able to demonstrate how consistent or inconsistent the performance of various motors / igniters really are.

In the interest of safety, only use the lowest average figures ( for recommended liftoff weights ). If the speed off the rail is too slow, a safety issue exists . . . Anything faster than the target Ft/Sec is just a "bonus".

As for the "electronics" questions, I have no idea . . . I'm an "Old-School" Rocketeer, who shuns Rocksim !

I still use graph paper, pencil, protractor, compass, and a hand calculator to do all my designs ( over 50 years ) . . .

Dave F.

 

[jqavins]

It's a fair point about the abuse the equipment will take at the hands of hot, smokey, and acidic exhaust plumes. Please consider protective measures something like this:

1. Place heavy duty cling wrap over the open ends of the tubes that you've got over the LED and sensor.
2. Wrap everything else in aluminum duct tape.

If that's not perfect protection, and it isn't, it should help a bunch, I think. And you can tell just how supremely confident I am in this. (Also, if the wraps don't hold up, they're replaceable.) And you might want to avoid smokies as well as sparkies, if for no other reason than that they'll deposit soot all over everything.

 

[UhClem]

I would appreciate hearing how to improve the program because I only have a little experience coding with Arduino.

I can't help much with Arduino since I am more bare metal in my programming. (I think that the editor here has code tags which would probably help with the formatting of posted code.) The one time I have worked with something which used the Arduino IDE, I rather pointedly avoided it.

 

[jqavins]

1. Place heavy duty cling wrap over the open ends of the tubes that you've got over the LED and sensor.
2. Wrap everything else in aluminum duct tape.

On reflection, better yet, put the equipment in project boxes. Which you may have been intending anyway. (I have this tendency to overcomplicate things at first and then simplify them in stages.) Plastic boxes may hold up better against the acid than aluminum. If you want to really all out, cover any exposed aluminum with copper tape; copper holds up well to hydrochloric acid, where aluminum gives in to it like France to the German army. And do put clear plastic over the optical openings.

 

[UhClem]

Here is a different approach. I looked at some data I captured a while back using a stretched Aerotech Initiator flying on a G64. The data rate and bandwidth is high enough so that you can see when the rocket departs the rod.


Comparing that to a sim shows that the real G64 (admittedly a well aged G64) didn't come up to full thrust as quickly.

 

[Dan Griffing]

I see some threads concerned about simulated launch rail exit velocity but none about measured velocity. Has anyone compared simulated launch rail exit velocity with what was actually measured?

I have some vague ideas about how to measure exit velocity, but I'm curious about ways people think this could be measured. Probably the Myth Busters high speed video with the background grid would not work well because frequently there's too much wind for something like that and the set up would be difficult. It would have to be set up pretty easily, accurate, and of course not potentially interfere with the launching rocket.

Also, I mentioned rail, but it could be a launch rod or even a tower

There are indirect ways of "measuring" the rocket velocity, such as measuring the rocket's acceleration with the Jolly Logic Altimeter3. Plotting the Altimeter3 acceleration curve and measuring the area under the curve at every point in time yields the velocity at every point in time. Alternatively, if you plot the rocket's Altimeter3 altitude versus time, the slope at any point in time is the velocity, These two should match to the measurement precision of Altimeter3's accelerometer and altimeter, which arguably are going to be comparable to photographic methods, or using some instrument mounted on the launch rail for measuring velocity.

On the other hand, the iPhone has a slow motion video rate of 240 frames per second, and so does GoPro. And a GoPro can be mounted on a tripod close to the launch rail to get a clear view of the rocket as it goes past the end of the launch rail. So any frame grabbing software package that can process these video outputs might be used to analyze the time when parts of the rocket with known distances apart clear the end of the launch rail. 240 frames per second should be ample resolution to detect whether the rocket is going 44fps as it leaves the rail. At the 240 frame rate a rocket traveling at 44fps will have traveled only 2.2 inches per frame. So if it takes about 5 frames for a rocket's 12inch base fin cord to go past the end of the rail, its going faster than 44fps.

But this whole issue seems to imply that there's something wrong with the RockSim's use of the rocket's weight and published rocket motor thrust data to calculate how fast the rocket is going by the time that it reaches the end of the launch rail. Is there any evidence to suggest that this basic function of RockSim is not working correctly? RockSim has been accepted and relied on for decades by thousands of high power rocketeers to perform successful launches.

While there is a real need for concern about the launch rail exit velocity, I doubt that the value of this number is seriously off, since its primarily controlled by Newton's Second Law of motion. But there might be other significant factors, such as where the Cd of a specific rocket really is, and whether the minimum velocity for a specific rocket to attain a stable launch velocity is really 44fps with the rocket's specific fin design, moments of inertia, and drag, and the current wind conditions as it hits the launch rail.

 

[Richard Dierking]

On reflection, better yet, put the equipment in project boxes. Which you may have been intending anyway. (I have this tendency to overcomplicate things at first and then simplify them in stages.) Plastic boxes may hold up better against the acid than aluminum. If you want to really all out, cover any exposed aluminum with copper tape; copper holds up well to hydrochloric acid, where aluminum gives in to it like France to the German army. And do put clear plastic over the optical openings.

Thank you. I appreciate the advice on this. I'm wondering how this set-up is going to hold up. And, perhaps the motors will have a profound affect upon the sensor as the go by during the burn. One way to find out is to do it. I might end up trying another set-up.

Here is a different approach. I looked at some data I captured a while back using a stretched Aerotech Initiator flying on a G64. The data rate and bandwidth is high enough so that you can see when the rocket departs the rod.

And, that's a good approach. For my rockets, that's exactly what I'm going to do.

BTW: Has anyone used VLC Media Player for 240 fps video?

But this whole issue seems to imply that there's something wrong with the RockSim's use of the rocket's weight and published rocket motor thrust data to calculate how fast the rocket is going by the time that it reaches the end of the launch rail. Is there any evidence to suggest that this basic function of RockSim is not working correctly? RockSim has been accepted and relied on for decades by thousands of high power rocketeers to perform successful launches.

Please keep an open mind about this.
Yes, this is based on my observation that sometimes the exit velocity seemed a bit low. May be it isn't. Maybe occasionally it is. Get the info and if it is, start asking why.
I think many people believe that actual exit velocity can be lower than simulated. Maybe I will obtain some data and someone else will pick it up from there.

Today, I've been working on installing the 8' rail for the drop tasting. Going a bit slow because it's so dang hot. Once I get it set up and collect some data, we'll go from there.
Sound OK?

 

[jqavins]

Once I... collect some data, we'll go from there.
Sound OK?

Yup. When there's even a reason to suspect an unknown phenomenon, gather data.

 

[Richard Dierking]

So, I've made some progress and encountered some interesting problems. I'm going to include some photos. If anyone wants me to elaborate on anything, please let me know.

I installed the 8' rail for the drop test with the sensor set-up on the bottom of the rail. I used a good 2' long level to assure it was vertical. (I haven't revised the Arduino code yet. I wanted to get this going first.)

Last night, I tried the set up and the time reading was going on and off and totally freak'n out. I even noticed when I put my hand over the Arduino board the time would stop. What the heck! I gave up and went to bed.
This morning I started thinking about what could be happening. I think the sensor may be getting a lot of interference from the 4 security cameras I have in the front of my house. I had the garage door open and the door is insulated on the inside using Reflectix. I think all the IR used to illuminate for the security cameras was being bounced off my cars in the driveway and then in my garage. The set up is working mostly fine today without the cameras on night vision. I'll check again tonight.

Second problem is more interesting. I set up a 5 volt 50 N electromagnet at the top of the rail so I could get a clean drop. When I turn off the magnet, the sensor set up trips and reads 12 ms. Not when I turn it on, only when I turn it off. Wow, I could use some help figuring this one out! How would a collapsing magnetic field be transferred down a 8' long piece of aluminum and trip an IR sensor? The Arduino and power supply for the magnet are not even on the same circuit.

Now, if I manually drop the wood block (mass 508 grams) with the two rail buttons, I get 71 ms (average, min is 70 and max is 73 ms). The buttons are 1.5 ft apart, and I calculate 21.13 fps. The distance from the center between the two rail buttons and the sensor is 7.125'. The drop velocity calculates to 21.41 fps. Difference is 0.28 fps and measured is less than calculated.

 

[jqavins]

To put that another way, calculated is greater than measured by a factor of 1.0133. So the difference is in the third significant digit. Your time measurements have only two significant digits. So the difference is insignificant. Perhaps with the change of that scaling factor from 1000 to 1000.0 the difference will become meaningful.

Dinner is ready; I may have a bit to add later.

EDIT: Dinner was yummy, and now I'm back.

As for the probable IR interference from the security system, how long is the tube you've got over the sensor? Sunlight is going to give you way more IR than the camera illuminators, and you need to have the tube long enough to narrow the field of view A LOT.

For the weird effect turning off the magnet, it's weird. Weird stuff usually comes down to either ground loops, bad grounds, or EMI.

Having the magnet's supply on a different circuit from the Arduino's supply is good, but the two circuits' neutrals do come together at the breaker panel. Unlikely to be the cause? Yes. If you want to be sure, run the Arduino on a battery.

As you probably know, a changing magnetic field produces an electric field. As you also may know, turning off the current in a coil produces a spike of voltage trying to keep the current going, unless you do something prevent it. That something, fortunately, is very simple: you put a diode in parallel with the coil. Be sure the diode is oriented so that it doesn't conduct in the same direction that you're expecting coil current. In other words, it needs to be reverse biased when the magnet is on. I think there's a good chance, if you don't now have that diode, that adding it will make the weird go away.

What is the wire path from the sensor to the circuit board? I have no idea how suceptable to EMI that circuit is. To be on the safe side, the wires should be neatly twisted together. And using shielded cable wouldn't hurt. Or shielding may be completely irrelevant, as the need for it depends on the stuff I don't know. But the twisting is always a good idea and costs nothing.

 

[Richard Dierking]

Thank you! I had the Arduino running USB power from a laptop on battery. That didn't solve the problem today. But, after I read your message, I reconsidered how the magnet was mounted on the rail and added a nylon washer between the magnet and the aluminum bracket holding the magnet. It was already secured with a nylon bolt but was still metal to metal at the base of the electromagnet. Now, it's electrically insulated.

I'll twist the connection wires from the sensor.

The brass tube to the sensor is only 8 mm long. But, I can't have it any longer because the set up must not interfere with the rocket w/fins passing by.
The laser break beam is sounding better and better, but I would like to get this working.

Switching gears a bit. I don't know much about the history of using rails and buttons. I wonder how the typical button dimensions came about. It seems that the inside of commonly used buttons is a bit large for a 1010 structural rail (photo). If the rocket twists a bit on the rail, it seems like the button would bind. I looked at some previously used buttons and there seems to be a notable amount of wear at one spot on the button spacer. So, I wonder if reducing the length of the spacer about 1 mm and maybe increasing the diameter of the inner washer would show reduced wear and therefore a decrease in binding.

I got some new rail buttons from Madcow Rocketry and waiting for the ones from Rail-buttons.com. I also found some aluminum rail buttons. Aluminum rail buttons and rail guides are not real popular with some clubs. But, I'm interested in how they will compare with plastic ones.

And, received the GoPro 8 Black today!

 

[jqavins]

If you stand the sensor off from the rail on a bracket, would that let you extend the tube and still avoid fins? It would help if you limit the tests to three fins rockets, as that will be easier to clear than four. (Please forgive the crude drawing.)

Also, brass is a rather good reflector of IR (copper is better). Paint the inside matte black. (A Q-tip should make a good brush for the purpose.)

As for rail button wear, does anyone make polyoxymethylene (Delrin®) rail buttons? It's very slippery, but tougher than PTFE (Teflon®).

 

[Richard Dierking]

Actually, I don't even have a drawing, so I appreciate the effort on that Joe!

I believe the rail buttons I got from Madcow are Nylon and the ones coming from rail-buttons.com are one piece Delrin. I'll provide dimensions when the Delrins are received.

The current set-up would clear rockets say with 3" diameter and 4 fins. Not sure about 2.25" airframe; I'll check on that. The major problem is the play from side to side. Hopefully, someone will provide some reasoning on the present dimensions of typical rail buttons. Maybe they are sized with so much play to accommodate dirty rails?

I need to keep focused on the velocity measurements but I'm also thinking a potential redo for the design of rail guides.

I would like to have the set-up fit 4 fin rockets. I believe most of the kit rockets are 4 fin. And all the rockets I'm currently building are 4 fin.

I picked brass for the sensor tube not realizing that it would be that much different than copper. Darn. I didn't use the aluminum tube I had because I thought that brass would be better. I did paint the inside of the tube with black high temp (advertised as 2000 F) paint.

Wish I was good at CAD because it would be a lot easier to create different designs for the IR LED and Sensor holder.

 

[manixFan]

This is a great project. While it could be done with video analysis, that's kinda beside the point. One of the reasons I got into rocketry was because I wanted to push my limits in many areas, and this hobby certainly allows us to do that. The OP is learning all kinds of new stuff and collecting some interesting data. If we all stuck to stuff that was easy and we already knew how to do, the world would be a very boring place, and we'd all be flying 3FNC rockets.

And to the OP - sounds like a good excuse to pick up some CAD skills!


Tony