So, maybe I'll try a three-stager

JimJarvis50 said:

Well, we did get to fly on Sunday, but only the first stage lit. Seemed like a common problem.

There is still a lot of data to review, but my preliminary assessment is that one of the servos failed. Easily seen in the video. That led to drag separation of the second / third stages and no stabilization. Roll control for the first three seconds was good and the spin can worked very well.

I suspect that the second stage was inhibited due to tilt. I had that setting pretty tight, but from the video, it looked pretty vertical. Haven't looked at the file yet.

Again, much thanks to Chris Harris, Steve Shannon and Dale Emery for helping me out - twice as it turned out.

Everything recovered fine, so maybe I'll do a three stager next year. Maybe.

Jim

Click to expand...

I'd volunteer to be a pad slave again. It was very educational seeing how you do everything.

I was happy to help Jim. Bring your data to the next local launch if you can, I'm curious.

Random Flying Object said:

I was happy to help Jim. Bring your data to the next local launch if you can, I'm curious.

Click to expand...

Before too long, I'll post any relevant data from the flight. It's just going to take a little time.

As usual, there is interesting video.

Jim

JimJarvis50 said:

As usual, there is interesting video.

Jim

Click to expand...

So, here is a composite of the video from my flight.

https://youtu.be/G-Iwi-UF2ck

There is a lot of stuff happening in the video, so I've tried to annotate the events as best as I can. A few notes ....

The main problem associated with the flight was a failure of one of the servos in the stabilization system. The servos were set for roll control only during the time period covered by the video. Therefore, they should all only be turning in the same direction. Thus, when the canards start going in different directions, it is obvious that there is a problem. You can also see the canard "chattering" just before the failure. The offending servo is clearly broken now, although it still functions. What I don't know is whether this happened during the current flight or a previous one.

Once this servo fails, the drag and torque created by the canarads causes the second/third stages to drag separate. The stabilzation section and the 2nd/3rd stages were keyed together and shear pinned, but that was not enough to avoid separation. Steve, you may find it ironic that this was the joint where we could only insert 2 of the 3 pins, naturally. The strength of this connection needs to be optimized a little more. On the one hand, things need to stay together to handle the turning forces provided by the canards. On the other hand, if things malfunction, as in this flight, maybe it is better if the connection fails. This will require a bit more thought.

I haven't looked at the the EasyMega tilt value yet, but I suspect it will be above my 12-degree setting. It would have been a great flight to stabilize back to vertical (crap). I'm not sure why it tilted to this extent, and downwind at that. I think there were some videos taken, and I hope they can be posted - I'd like to see how the rocket came off the rail.

Jim

Jim, sorry to see it was not successful. Conversely, you proved the spin can works.

I wonder if there is a good method to test the servos before flight? Especially under load to check torque capacity.

It was tilting. What was the wind, the velocity off the rail, and how long was the rail?


Sent from my iPhone using Rocketry Forum

Ahhhhh, It didn't do what you wanted it to do but at least it was a safe flight, you got all your pieces back and I have a feeling the next flight will be a "keeper". Do you think there is a reliability issue with the servo or was it a fluke event?
It may seem empty but congratulations are in order here. That spin can was doing it's thing and seemed like it was
flying nice before the separation. Kurt

If you had some feedback on servo position you could perform a power on self test but while servos use position feedback internally they don't make that information available.

It is possible to modify servos to get position feedback by tapping the output of the potentiometer. (example)

markkoelsch said:

It was tilting. What was the wind, the velocity off the rail, and how long was the rail?

Click to expand...

I think the wind was light out of the north, and the rocket went to the south (i.e., didn't weathercock). I noticed that the bottom PML rail guide was gone. It might have snapped off right at the top of the rail, and maybe that gave it a little kick. That's why I'd like to see video of the takeoff.

Jim

ksaves2 said:

Do you think there is a reliability issue with the servo or was it a fluke event?

Click to expand...

I don't know when the problem with the servo occurred. It might have happened on a previous flight, although I think I would have noticed it if the condition of the servo was as it is now. Or, it might have happened during this flight with high torque. The system has flown previously at the speed of this flight, but I did increase the size of the canards by about 50% for this flight to get a little more control authority. I would like to upgrade the servos if I can figure out a way to retrofit them into the current spool. It should be possible to do this, but it may not be easy.

Jim

How about that!
I'm fascinated by your progress and looking forward to seeing what you come up with!

So, I recovered the second stage EasyMega file. I don't have rotation indicated in the graph, but it is easy to see the point where the servo failed. It is also easy to see the difference in acceleration that contributed to drag separation. What is interesting, sadly, is that the indicated tilt at 11 seconds is 10 or 11 degrees - under the 12 degree tilt criteria. Channel B, the separation charge, fired at that point, but the igniter ematch on Channel A did not. This channel had additional criteria of less than 12 degrees tilt and height > 2200 meters, with both criteria apparently met. It should have fired the igniter, but was obviously very close to the tilt criteria. What luck I have!

Jim

JimJarvis50 said:

So, I recovered the second stage EasyMega file. I don't have rotation indicated in the graph, but it is easy to see the point where the servo failed. It is also easy to see the difference in acceleration that contributed to drag separation. What is interesting, sadly, is that the indicated tilt at 11 seconds is 10 or 11 degrees - under the 12 degree tilt criteria. Channel B, the separation charge, fired at that point, but the igniter ematch on Channel A did not. This channel had additional criteria of less than 12 degrees tilt and height > 2200 meters, with both criteria apparently met. It should have fired the igniter, but was obviously very close to the tilt criteria. What luck I have!

Jim

Click to expand...

This very interesting data! Thanks for sharing. Do you have any speculative thought as to why the ematch did not fire?

A5tr0 An0n said:

This very interesting data! Thanks for sharing. Do you have any speculative thought as to why the ematch did not fire?

Click to expand...

It is possible that the value used to lock out on tilt is not exactly the same value that is plotted. So, it locked out even though the plotted value was below 12 degrees. Maybe Keith can review the file and see if that is the case.

Jim

Jim,

I was wondering if you have onboard video that would give you and estimate what the tilt was versus what the altimeter thought it was? I am curious of what accuracy to expect given uncertainties like cross-axis sensitivity with the gyros and other possible errors.

JimJarvis50 said:

It is possible that the value used to lock out on tilt is not exactly the same value that is plotted. So, it locked out even though the plotted value was below 12 degrees. Maybe Keith can review the file and see if that is the case.

Jim

Click to expand...

Could it be that the rocket was 1 or 2 degrees off vertical when it took its "zero point" and thus was outside the tilt lock? Though this wouldn't explain the graph not graphing the correct value.

jderimig said:

Jim,

I was wondering if you have onboard video that would give you and estimate what the tilt was versus what the altimeter thought it was? I am curious of what accuracy to expect given uncertainties like cross-axis sensitivity with the gyros and other possible errors.

Click to expand...

I have video-based estimates of 10.3 degrees at 9 seconds and 13 degrees at 12 seconds. Sort of in the ball park.

The gps lock was not good enough to get gps-based values.

Jim

My other "accomplishment" was not to have to climb the ladder to arm the staging electronics. Although the wifi switches didn't continuously stay connected to my phone/tablet, it was easy to reacquire the network as long as I was on the side of the rocket with the slot antennas. I thought these might not work quite as planned, but instead, they worked very well.

On Friday, we weren't able to fly and we had to take down the rocket. I was very releaved to be able to reacquire the networks and turn off the easymega's so that we could safely lower the rocket. No problems whatsoever.

Jim

Jim, in your video, at about 36 secs there appears to be at least one piece of something falling away. What was that?

Rocketclar said:

Jim, in your video, at about 36 secs there appears to be at least one piece of something falling away. What was that?

Click to expand...

That was the stabilization section. It's a little easier to see at 0:59 (it leaves the rocket on the right screen and then you can see it fall on the left screen). The stabilization section was supposed to be attached to the second stage at that point and continue going up, but since the second stage drag separated, the stabilization section fell away (or continued to rise slower than the first stage).

I actually got a little lucky that the stabilization section recovered (i.e., had a normal barometric apogee deployment). In that section, I was using a Raven with a (high) Mach lockout value of V<800 ft/s. In a normal application, this criteria is supposed to prevent a spoofed barometric deployment if the velocity is actually above mack. The rocket was supposed to reach about 1200 ft/s on the first stage boost, which it did, and then the idea is that the velocity will slow to around 600 ft/s during the stabilization period so that the apogee charge will fire even if the stabilization section tumbles after separation. Since the section separated early, and indeed tumbled, the velocity was closer to the 800 ft/s than I would have liked. Fortunately, when something tumbles, there is still a slow velocity reduction calculated by the accelerometer, and that was enough to get below 800 ft/s to allow recovery.

Also, I was fortunate that the stabilization section cleared and did not hit the first stage spincan on the way by. That would have been bad.

Jim

JimJarvis50 said:

That was the stabilization section. It's a little easier to see at 0:59 (it leaves the rocket on the right screen and then you can see it fall on the left screen). The stabilization section was supposed to be attached to the second stage at that point and continue going up, but since the second stage drag separated, the stabilization section fell away (or continued to rise slower than the first stage).

I actually got a little lucky that the stabilization section recovered (i.e., had a normal barometric apogee deployment). In that section, I was using a Raven with a (high) Mach lockout value of V<800 ft/s. In a normal application, this criteria is supposed to prevent a spoofed barometric deployment if the velocity is actually above mack. The rocket was supposed to reach about 1200 ft/s on the first stage boost, which it did, and then the idea is that the velocity will slow to around 600 ft/s during the stabilization period so that the apogee charge will fire even if the stabilization section tumbles after separation. Since the section separated early, and indeed tumbled, the velocity was closer to the 800 ft/s than I would have liked. Fortunately, when something tumbles, there is still a slow velocity reduction calculated by the accelerometer, and that was enough to get below 800 ft/s to allow recovery.

Also, I was fortunate that the stabilization section cleared and did not hit the first stage spincan on the way by. That would have been bad.

Jim

Click to expand...

Would your spin can approach also work for rockets staging at high altitude in near vacuum conditions by the gyroscopic effect, not because of the fins?&#65279; If so, then by staging an upper stage at 100,000 feet you could reach the 100 km altitude for breaking the Karman line for space.

Bob Clark

Rockets Magazine has their Balls videos posted, which include my flight. There are a few things of interest there, such as how I nearly toasted the bottom of the rocket upon liftoff (very bad standoff design), and a few deployment scenes are visible that are helpful to me.

https://youtu.be/q2yZ_NMkz58

I did follow up with Keith on why the second stage didn't light (it looked like it was under the tilt criterion that I set). It turns out that it should have lit, but didn't because of a bug in the firmware. It has something to do with having test fired one of the A-D channels, which then doesn't get reset for the next launch. I did test firing of the "A" channel to look at the function of the shunt last summer, and that is what did the trick. Keith has a fix just about ready to go.

For this particular flight, it is just fine with me that the second stage didn't light. It looked to be at about 10 or 11 degrees at the point where it should have lit. This is under the 12 degree criterion that I set, but it would have resulted in a very long recovery. I did "that" flight a few years ago and have no desire to repeat it. I think I need to change this setting to 9 or 10 degrees for the next try.

Jim

On your graph, is your tilt data smoothed? Do you use that exact same imput to determine staging criteria? Is current tilt, or projected tilt, used as the criteria?

Gerald

G_T said:

On your graph, is your tilt data smoothed? Do you use that exact same imput to determine staging criteria? Is current tilt, or projected tilt, used as the criteria?

Gerald

Click to expand...

My graph is just what the interface program produces. It is the only tilt data available, as tilt is not included in the exported data. Although the graph showed the tilt to be less than 12 degrees, I had the same question about the actual value as you are asking. So, I asked Keith if he could confirm that the channel should have fired. He said he ran the saved data through his flight program and from that, concluded that the channel should have fired.

I think the criteria that you set is evaluated at the instant that a trigger occurs. So, in my case, it was the tilt at exactly 11 seconds into the flight. I believe that if you set a delay time for a channel, it will look at the criteria throughout that delay period and not just at the moment of the trigger. You could use this approach if you wanted to to ensure that the tilt had not been out of spec for a period of time prior to the trigger. I think doing it that way has some advantages, but that isn't what I did on this flight.

Jim

JimJarvis50 said:

I did follow up with Keith on why the second stage didn't light (it looked like it was under the tilt criterion that I set). It turns out that it should have lit, but didn't because of a bug in the firmware. It has something to do with having test fired one of the A-D channels, which then doesn't get reset for the next launch. I did test firing of the "A" channel to look at the function of the shunt last summer, and that is what did the trick. Keith has a fix just about ready to go.

For this particular flight, it is just fine with me that the second stage didn't light. It looked to be at about 10 or 11 degrees at the point where it should have lit. This is under the 12 degree criterion that I set, but it would have resulted in a very long recovery. I did "that" flight a few years ago and have no desire to repeat it. I think I need to change this setting to 9 or 10 degrees for the next try.

Jim

Click to expand...

Just FYI, there is a new version of AltOS (1.8.3) that fixes the bugs that caused my second stage at Balls not to light and my third stage not to record a file.

Jim

JimJarvis50 said:

Just FYI, there is a new version of AltOS (1.8.3) that fixes the bugs that caused my second stage at Balls not to light and my third stage not to record a file.

Jim

Click to expand...

Weird mine worked fine with that update at Balls - igniters fired and the flight was recorded on both units. It couldn’t have been just the update...? Mine are older units (not sure if that matters) purchased in 2015.

I will however add that the altitude recorded was quite a bit lower than what was attained. By 10-15k ft estimated error - we lost GPS during apogee so not sure on the exact altitude.

Kip_Daugirdas said:

Weird mine worked fine with that update at Balls - igniters fired and the flight was recorded on both units. It couldn’t have been just the update...? Mine are older units (not sure if that matters) purchased in 2015.

I will however add that the altitude recorded was quite a bit lower than what was attained. By 10-15k ft estimated error - we lost GPS during apogee so not sure on the exact altitude.

Click to expand...

I'm speculating, but I think the channel firing bug has been there for a long time. It happens if you ground-test the A-D channels. If you didn't test fire the channels, then you wouldn't see the problem. Here's what Keith said about the update:

In addition to support for TeleMega v3.0 boards, AltOS 1.8.3 contains some important bug fixes for all flight computers. Users are advised to upgrade their devices.

Ground testing EasyMega and TeleMega additional pyro channels could result in a sticky 'fired' status which would prevent these channels from firing on future flights.

Corrupted flight log records could prevent future flights from capturing log data.

Fixed saving of pyro configuration that ended with 'Descending'. This would cause the configuration to revert to the previous state during setup.

Jim

I reckon Jim's on the money here Kip. There's only been a v1.0 of the EasyMega ever released so I don't believe it would be a hardware fault and instead a software issue combined with Jim's ground testing. Or it could have been a bug that was introduced in a firmware update that went un-diagnosed. Our of curiosity what firmware is your EasyMega running?

Curious comments as well about the lower than expected altitude recorded on your unit. Have you ever flown that unit before and if so did it also display a lower than expected max alt then?

Finally, thanks to both of you. I've landed some Carolina Composites HEI hardware in 38, 54, and 75 and plan to use them with my EasyMega to do some staging at both Williams Wildfire Westernationals out here in WA in June and then again at Thunda 2019. Not sure if I'll leverage the 75mm hardware just yet but the 38 and 54mm units will be flown in the next year and a bit.

plugger said:

Our of curiosity what firmware is your EasyMega running?

Click to expand...

I believe the firmware comes with the AltOS package. I was running 1.8.2 (developed last summer). Among other things, this version contained the capability to recalibrate the accelerometer. This addressed an issue that was preventing the unit from recognizing that it was in a vertical position, ready for launch, rather than the horizontal USB mode. I believe this was mainly an issue for older units.

Jim

plugger said:

I reckon Jim's on the money here Kip. There's only been a v1.0 of the EasyMega ever released so I don't believe it would be a hardware fault and instead a software issue combined with Jim's ground testing. Or it could have been a bug that was introduced in a firmware update that went un-diagnosed. Our of curiosity what firmware is your EasyMega running?

Curious comments as well about the lower than expected altitude recorded on your unit. Have you ever flown that unit before and if so did it also display a lower than expected max alt then?

Click to expand...

I was running the same version as Jim. My units have flown on all my high altitude attempts - 4 so far. It displayed 31k apogee for the unlit sustainer. The booster (with an interstage for a nosecone) made it to 33k confirmed by GPS.
Sustainer snapped this pic - doesn’t look like 31k. Anyways didn’t mean to hijack the thread. I will update my firmware, thanks Jim for letting everyone know.

JimJarvis50 said:

I believe the firmware comes with the AltOS package. I was running 1.8.2 (developed last summer). Among other things, this version contained the capability to recalibrate the accelerometer. This addressed an issue that was preventing the unit from recognizing that it was in a vertical position, ready for launch, rather than the horizontal USB mode. I believe this was mainly an issue for older units.

Jim

Click to expand...

Hi Jim,

You're correct, the firmware comes with the AltOS installer but it doesn't automagically update the device. You have to plug the EasyMega directly into your computer and run the process manually via the AltOS GUI. The instructions for how to accomplish this are on page 60 of the AltusMetrum manual.