Yet another staging with Easy Mega question

The Rocketry Forum

Help Support The Rocketry Forum:

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

JEtgen

Active Member
TRF Supporter
Joined
Dec 6, 2021
Messages
33
Reaction score
58
We are feeling a bit frustrated having now gone 1 for 5 using Altus Easy timer / Easy Mega for some 2 stage projects we have been trying and are looking for pointers / help. Out first attempts were with the Easy Timer. On the first attempt, we did something pretty close to what the manual says to try. It seemed pretty clear that the Easy Timer called motor 1 burnout about .5 seconds early which caused the booter to ram the sustainer and apparently dislodge the igniter in the sustainer (a CTI motor). So, for the second attempt we added a dependency on time since launch to make sure we didn't prematurely detect burnout again. On that flight neither the separation charge nor the sustainer igniter fired. We were using the Wildman ematches that time and suspect the default latch time was not long enough to light those, so we increased that to .25 seconds from the default .05. Third time was a charm with Easy Timer and got both the separation charge and the sustainer igniter to light and had a successful flight. To improve the chances of sustainer ignition, I glued a pyrodex pellet to the sustainer ematch (CTI motor again, so this was presumably overkill).

Because of the lack of data logging, we wanted to switch to using the Easy Mega for the staging function. Maybe mistakenly. from our previous experience with the Easy Timer, we added/ selected a dependency on time since launch on both separation charge and sustainer ignition, as well as an altitude lower limit. On the first attempt Neither charge fired even though the flight was within 5 degrees of vertical well after booster burnout. The flight data graph seems to show it never tried to fire either charge. We thought the issue in this case came to some confusion around having the dependency being after "motor 0". which we selected instead of "motor 1". (Don't ask, Jenni is a C programmer and John is a Fortran programmer, so if the source code is in C or C++, motor 0 is the first motor, right???). Second attempt flew the sustainer with its motor lit from the pad and the staging gear attached to ematches but just along for the ride. Switched to human logical Fortran mode and assumed motor 1 is the correct definition of the first motor. Again keeping the dependency on time since launch and an altitude floor. Neither igniter fired. The flight data graph shows that it never tried.


When looking at the eeprom files the time windows looks suspect. it looks like instead of seconds its in a different scale.




Attaching the the flight data for both easy mega flights.

We are going to try again this coming weekend planning on the following configuration:

channel A:
after motor number: 1
delay after other conditions(s): .5



channel B:

angle from vertical less than 45


after motor number: 1
delay after other conditions(s):


Any thoughts/questions/directions to take would be appreciated.


Jenni and John Etgen
 

Attachments

  • Easy Mega 5-6 configuration.jpg
    Easy Mega 5-6 configuration.jpg
    3.1 MB · Views: 0
  • Easymini configuration.jpg
    Easymini configuration.jpg
    2 MB · Views: 0
  • 2023-05-06-serial-5538-flight-0001.eeprom
    214.9 KB · Views: 0
  • 2023-04-22-serial-5567-flight-0002.eeprom
    202.9 KB · Views: 0
45 degrees sounds like way too large for ignition inhibit. I ran a two-stage flight a couple of years back and had the ignition to occur no greater than 12 degrees off vertical, with overall complete lockout of ignition at 20 degrees. You can very easily bust your airspace cylinder with ignition at excessive tilt.
 
Yes 45 is too large, we use 25 when actually staging. We are just setting very permissive conditions when testing on a single stage. The problem is nothing is firing.
 
Last edited:
Yes 45 is too large, we use 25 when actually staging. We are just setting very permissive conditions when testing on a single stage. The problem is nothing is firing.
Good to know.

It is relatively easy to get sustainer ignition wrong on the Tele product. It is not entirely intuitive IMHO. I think there are a lot of ways to get it wrong.
 
Still a mystery to me. On the one screen, there is time < 0, which would prevent anything from happening. I also wouldn't select the delay box unless I was using one.

The only thing I can think of is a battery problem. If you're using one battery, then two of the terminals need to be connected together. If separate batteries, then not connected together. Have you tried just doing a bench test and firing an igniter just to verify the electrical side?

A few years back, I got two EasyMega's where the terminal strip was not fully soldered to the circuit board. I couldn't see the voltages I was expecting on the two battery options, and I eventually figured out that the terminals were not actually connected to the circuit. You might inspect the solder connections.

Jim
 
May I suggest doing a screen capture rather than trying to photograph the screen. It's much easier to read.
 
I've been doing 2 stage for a couple of years using a Telemega and can share your frustration. I find their instructions can be somewhat confusing so I have developed the habit of using as few options as possible. 20 degree inhibit, 3 seconds after motor 1. Keep it simple.
 
I like the "keep it simple" plan. Next launch opportunity we will send the sustainer alone off the pad with the staging gear along for the ride like last weekend with AARG and do something like Ric says. I am also going to make it try to fire the ematches that did not fire last time on the bench (well a cinderblock bench in the yard), just to make sure they will go when commanded. Jenni thinks I'm crazy but I want to rule that out. It was 2 wildman ematches this last time, not the smaller MJG ematches that come with the CTI motors.

Maybe one more thing that I am not sure we asked / informed correctly... In the actual data file from the flight, the "time since launch > " field and the "time since launch < " field had numbers like 350 and 600. Given that we are asked to input numbers in seconds, and I think we did that, it is surprising to see numbers which I suppose are in 1/100th of a second. I think all the other units that come from the user interface are consistent in that file.

Sorry for the crappy pics above, we were headed out of town immediately after the launch last Saturday and just threw that together. If anyone wants a deeper dive into this mess, just let us know.

-John
 
I like the "keep it simple" plan. Next launch opportunity we will send the sustainer alone off the pad with the staging gear along for the ride like last weekend with AARG and do something like Ric says. I am also going to make it try to fire the ematches that did not fire last time on the bench (well a cinderblock bench in the yard), just to make sure they will go when commanded. Jenni thinks I'm crazy but I want to rule that out. It was 2 wildman ematches this last time, not the smaller MJG ematches that come with the CTI motors.

Maybe one more thing that I am not sure we asked / informed correctly... In the actual data file from the flight, the "time since launch > " field and the "time since launch < " field had numbers like 350 and 600. Given that we are asked to input numbers in seconds, and I think we did that, it is surprising to see numbers which I suppose are in 1/100th of a second. I think all the other units that come from the user interface are consistent in that file.

Sorry for the crappy pics above, we were headed out of town immediately after the launch last Saturday and just threw that together. If anyone wants a deeper dive into this mess, just let us know.

-John
Ya know..........Rather than launching the whole rocket you can make an inexpensive vacuum chamber using a piece of abs pipe hooked up to a shop vac. Just put your ebay inside. It's not precise but good enough to check ematchs.
 
Great minds think alike? Anyway, while I was at work today, Jenni did exactly that. We have a vacuum pump and chamber, so no need for shop vac and we can pull a fairly strong vacuum.

The results were, well, let's say, interesting. Since the accelerometers are essentially measuring noise, this is a very unconventional circumstance for a flight computer that is fusing the inputs of the accelerometers and the barometer to determine various phases of flight and resulting actions. I thought that the easy mega would come to some kind of conclusion that launch had not in fact happened. But, no, it does detect a "launch". However, it has a very hard time figuring out a decent motor 1 burnout. In fact what seems to happen is that at some point after lowest barometric pressure (presumably what would be apogee in the real world), the accelerometer, which is just sensing noise, switches to a coarser sample rate, which is perfectly logical to do in a real flight. That sample rate change causes the statistics of the noise to change slightly, which then triggers motor burnout detection. I guess I would have to see the code, to see what happens exactly, which I have not yet done. Anyway, with a purely barometric data-stream (say like with an early inflight failure of the vertical accelerometer), burnout detect is problematic and seems to happen after barometric apogee. So, something timed to happen at or after burnout, it might happen then. In her tests, the proxy for the separation charge (an x-mas light) did fire when given a simple "fire after motor 1 with X second delay.

In a second test, the easy mega was initialized vertically and then tipped over on its side for the "flight", again a very abnormal thing for a real flight. Anyway, then a barometric flight is created with the vacuum pump. I'm not totally sure why she did this test, other than to test tilt inhibit. But similar to the first case, motor burnout was detected after barometric apogee at the sample rate change on the now totally noise dominated vertical accelerometer (which due to being on its side was actually a horizontal accelerometer). The X or the Y accelerometer was vertically oriented and was being processed with the nonsensical vertical accelerometer to compute tilt. VERY strange things happened and the computed tilt was basically a sinusoid with a period of ~ 30 seconds (IIRC, not looking at the data ATM, anyway, long period sinusoid with amplitudes covering all possible tilts). Even more interestingly, the supposedly tilt limited channel B (acting as sustainer igniter) FIRED when the tilt was WAY OUTSIDE the limit.

I am not sure what these tests mean, other than to say one probably cannot use a vacuum chamber alone to simulate a flight with the easy mega. However, I think it is somewhat disturbing that tilt inhibit is not as rock solid as I might have thought. We have the data, an aux channel with tilt limit fired outside the limit in an exceptional circumstance. I don't really "blame" Altus for that as other than a failure of the sensors mid flight, maybe coupled with an improper installation of the unit, what we did in the vacuum chamber is not a realistic scenario for the real world.

It would be neat if there was a way to "play back" a recorded flight into the runtime software to see what happens with the logic with a change in settings. Has anyone tried that?

-John
 
It would be neat if there was a way to "play back" a recorded flight into the runtime software to see what happens with the logic with a change in settings. Has anyone tried that?
AltOS does have a flight replay function. I think you can add all the logical functions to the graph to see when they go active. Been a long time since I have used that.
 
Back
Top