Hey, let's take this altimeter for a spin!

[JimJarvis50]

So, the altimeter in question is the Altus Metrum EasyMega. I've learned a few things about this altimeter recently that are a little surprising. For one thing, Keith has confirmed that the "Time of Flight" timer resets after each new boost. So, if you have a time trigger set, and then have a second stage boost, the timer will reset to zero at the start of the second boost. Also, a burnout setting of 1, for example, means "exactly" one burnout and not "at least" one burnout. Thus, if you have something set to happen after one burnout, it will not happen after a second burnout if there is one. These things aren't documented very well at present, but they will be in the next version of the operating manual.

At any rate, I do a lot of staged flights and I have a three-stage flight planned for Balls again this year. Therefore, I would like to be able to understand - and demonstrate - exactly how this altimeter works. So, I set up an apparatus to do some spin testing (it's easier than spinning your arm, which starts to hurt after a while). In my initial spin testing, I have not been able to perform a valid test. The altimeter recognizes the boost state, and will fire channels based on that event. However, the altimeter doesn't seem to transition into the coast state, even with the altimeter held upside down to generate negative acceleration. That is, the altimeter doesn't seen to recognize a "burnout". I note also that the data file from the testing doesn't indicate any increase in altitude or velocity (so the altimeter is not using acceleration alone to calculate those values). I suspect that this is why the "flight" is not happening during the swing test. My question is, has anyone been able to do successful spin testing with the Altus Metrum altimeters?

Jim

 

[UhClem]

The best way to validate altimeter operation is by sending it fake data. This requires removing the sensors and providing suitable data from outside. Kind of hard on your altimeter hardware.

On the other hand, since the code is available, it should be possible to compile a special version that runs on the host PC and takes its data from a file or other controlled source. But the code is quite complicated since it supports many different hardware configurations.

Looking at the code in ao_flight.c I see that the transition to the coasting state requires both an acceleration of less than 1/4G and an altitude of greater than 100m.

 

[JimJarvis50]

Looking at the code in ao_flight.c I see that the transition to the coasting state requires both an acceleration of less than 1/4G and an altitude of greater than 100m.

That's going to be a challenge. Thanks for looking.

Jim

 

[UhClem]

That's going to be a challenge. Thanks for looking.

Jim

Something else you could try is to modify the firmware. Grab the code, remove the 100m requirement, and recompile. Then program the firmware into the altimeter.

 

[JimJarvis50]

Something else you could try is to modify the firmware. Grab the code, remove the 100m requirement, and recompile. Then program the firmware into the altimeter.

Hmm. Last time I recompiled code was after I dropped a deck of punch cards. Maybe I can get Keith to help me out on this.

Jim

 

[Nytrunner]

Very interesting investigation.

I'm guessing you're trying to avoid doing a half dozen G flights for real condition testing?

 

[JimJarvis50]

Very interesting investigation.

I'm guessing you're trying to avoid doing a half dozen G flights for real condition testing?

A G-powered three-stager would actually be pretty expensive!

Getting our consumer-quality electronics to cooperate for multi-staged flights is one of the most difficult aspects of what I do. Over the years, altimeter bugs and a less-than-complete understanding of the actual function of the flight computers have cost me tens of thousands in equipment and wasted time and travel, and safety is degraded. It is very frustrating. So, I try to do what I can to test the various electronics under the conditions that will exist in the flight. The situation with the EasyMega is particularly frustrating because it is one of the few altimeters that can be used for high-altitude, multi-stage flights. Unfortunately, the documentation doesn't reveal key aspects of how the altimeter works and it is not possible (for me) to test it short of actual flights. Every now and then, someone learns something from a flight and passes it along to others (thanks Kip).

Jim

 

[Nytrunner]

Ah, my thoughts were in the line of a 2-stage subscale for data purposes, but if you're looking for the logs of how it handles multiple burnouts and accelerations, I see then that you would need all those motors going in the test flight. Although short of rejiggering the code, simulating all this at >100m is, as you say, "a challenge".

 

[UhClem]

Hmm. Last time I recompiled code was after I dropped a deck of punch cards. Maybe I can get Keith to help me out on this.

Even after you get past that hurdle, there is also the Kalman filter to consider. The values used to control events are the filtered versions of acceleration, velocity, and altitude. The problem is that the pressure sensor keeps insisting that the altitude isn't changing. The accelerometer can push them some but the pressure will keep dragging them back.

Which means that any events depending on velocity and altitude are going to be badly warped if they happen at all.

HWIL (HardWare In the Loop) is the best way to test this but requires a board without sensors and connected to something else to provide simulated data.

 

[mikec]

Unfortunately, the documentation doesn't reveal key aspects of how the altimeter works...

Amen. Altus Metrum should, IMHO, be embarrassed by the state of their documentation.

 

[AdAstraPerAspera]

A G-powered three-stager would actually be pretty expensive!

Getting our consumer-quality electronics to cooperate for multi-staged flights is one of the most difficult aspects of what I do. Over the years, altimeter bugs and a less-than-complete understanding of the actual function of the flight computers have cost me tens of thousands in equipment and wasted time and travel, and safety is degraded. It is very frustrating. So, I try to do what I can to test the various electronics under the conditions that will exist in the flight. The situation with the EasyMega is particularly frustrating because it is one of the few altimeters that can be used for high-altitude, multi-stage flights. Unfortunately, the documentation doesn't reveal key aspects of how the altimeter works and it is not possible (for me) to test it short of actual flights. Every now and then, someone learns something from a flight and passes it along to others (thanks Kip).

Jim

I'd think that before you do your O/N/M or whatever, three stage flight, you would want to do a K/J/I or smaller three stage fight with the exact same electronics. It is the only true test...

Economical? Maybe not, but what in this hobby is? Plus, how much do you stand to "lose" if two 98 or 76mm motors light and the third doesn't? If a sub scale version can work bugs out, I'd do it. Maybe even if you can do the spin or fake data test first...

Plus, with the right design, you may be able to prove to yourself you can light three stages at a smaller, more local, feild with a lower waiver. A test bed for electronics doesn't have to be carbon fiber, minimum diameter, or go M2... And if it works, it only cost some time, cheap materials, and a few smallish motors. No new electronics needed. If it fails, it's still a much cheaper fail than your large CF bird would have been.

 

[mikec]

I'd think that before you do your O/N/M or whatever, three stage flight, you would want to do a K/J/I or smaller three stage fight with the exact same electronics. It is the only true test...

You know that Jim probably has more experience with three-stage amateur rockets than anyone else on the planet. Even a subscale flight test is not a complete test of altimeter behavior, as the people who have found various bugs in commercial altimeters over the years can attest -- bugs related to altitude, speed, time, etc.

Solid, unambiguous documentation of electronics behavior would be a great start. After many years of using them, I'm pretty sure I know all the ins and outs of the Raven, but the Telemega still holds some mysteries.

 

[JimJarvis50]

I'd think that before you do your O/N/M or whatever, three stage flight, you would want to do a K/J/I or smaller three stage fight with the exact same electronics. It is the only true test...

My experience is that flight testing sometimes reveals bugs but sometimes doesn't. Not to beat up on altimeter suppliers, but I had a Raven issues a few years back where the bug was that the calculated altitude would go negative at 60K feet. I believe it was a sign error in the atmospheric model. I was the first to fly the altimeter above 60K, so I got to find the error. I should have found that error through ground testing, but two-stage G flights were not going to reveal it.

The EasyMega "reset" bug is another example of something that might or might not have been caught by flight testing. That bug was caused by testing firing the channels. The bug was that the next "real" command to fire the channel after a test firing wouldn't fire the channel. It just happened that I was test firing the EasyMegas to test a shunt design before the flight last year. As a result of the bug, the second stage didn't light. I would have had to be pretty cleaver to find that one through testing, but I could have done a hundred test flights and not run into that problem.

I could share additional examples of things I've found through test flights, but only by dumb luck. In the testing of my stabilization system, I did "two-stage" tests but with no sustainer motor in the second stage. Just required one N motor and not two, and I didn't have to travel quite as far to do the test. Just by coincidence, I found a bug in the stabilization program that revealed itself when the spin rate exceeded a certain value. If it had not done that, the bug would not have been found.

Other bugs I've found through ground testing. The Raven accelerometer calibration problem was one of those (found by side-to-side spin testing of multiple altimeters). So, what I think it that you have to do whatever you can to find the bugs, including ground testing, semi full-scale flights and actual flights (unfortunately). Since I have done three NNM three-stage flights to date, I'm not sure G flights would help me much, but they would certainly not be the only true test. It's just unfortunate that with the EasyMega, some aspects of the operation of the altimeter can't be ground tested.

Jim

 

[JimJarvis50]

I should add that the problem with the Raven at 60K was found by Adrian, who went and reviewed his code due to the outcome of my flight. I would have had no clue what happened without him finding that since only the nosecone, with the tracking equipment, was found. Adrian immediately published the error, which likely saved others from the same problem. Well done.

Jim

 

[pendrin2020]

I'm currently doing an internship at a company that makes software for pharmaceutical packaging centers. In fact, a fair amount of my code is going to be distributed nationwide across a chain of centers.

So here's my two cents. thorough, real-world testing is very often not possible. This is a pretty standard problem. Because of limited access to hardware, I spent several days last month writing a program that did nothing but feed raw information into another program. A well-designed "sim" like this should be able to inject errors as well. The beautiful thing about these kinds of programs in the context of our little microcontroller-based altimeters, is that most all of the sensors can be spoofed easily using other microcontrollers. In fact, the investment in building these testing tools can pay dividends for years. This is due to the highly standardized com interfaces they use (spi, i2c, etc). You can even build data sets that are inconsistent to see what the system does in different failure modes.

At Marshall Space Center, there is a room with two complete sets of ALL ELECTRONICS that go into the SLS booster stage, and all they do, all day long, is feed data into those electronics for testing purposes. They even go so far as to use the exact cable lengths that will be in the actual booster.

My team did a lot of this kind of work for the Midwest competition this year. Sadly, I made a mistake that cost us the rocket, and one of my programmers decided a last minute change to the software was "OK" (he broke everything and it cost us all of our data). For giggles, I'm building my own GPS/Baro/Radio Tracking system for my L3 flight at airfest. It's for telemetry purposes only.

The issue with multiple boosts resetting timers and interrupting the program is the kind of issue that should have been found in testing.

I think I'm just going to stick to extremely methodical flight planning and timers for my Boost related stuff and all of my high altitude apogee events. The kinds of sensors used in our commercial altimeters aren't really precise enough to make a difference at high speed anyway.

 

[FredT]

Jim,

I've had three successful 3-stage flights this year with a TeleMega controlling top stage separation, ignition and deployment. I can send data files from the flights along with screen shots showing configurations.

I have run into the 100m issue with sensing burnout when using a short burn H550ST in the booster. Keith verified the issue and sent me a firmware file with that condition removed. A subsequent test flight verified the fix. I can send that to you too.

Send a PM with your email address and I'll send this stuff your way.

I have three flights, a 2-stage, a 3-stage, and a 4-stage. planned for AirFest. All different rockets but with a TeleMega handling top stage events. We can chat if you're there.

...Fred

 

[JimJarvis50]

Jim,

I've had three successful 3-stage flights this year with a TeleMega controlling top stage separation, ignition and deployment. I can send data files from the flights along with screen shots showing configurations.

I have run into the 100m issue with sensing burnout when using a short burn H550ST in the booster. Keith verified the issue and sent me a firmware file with that condition removed. A subsequent test flight verified the fix. I can send that to you too.

Send a PM with your email address and I'll send this stuff your way.

I have three flights, a 2-stage, a 3-stage, and a 4-stage. planned for AirFest. All different rockets but with a TeleMega handling top stage events. We can chat if you're there.

...Fred

Now, you're someone who will understand my pain! Yes, I'll send you a PM regarding your flight files. I don't think I can use your Telemega file for my EasyMega's, but maybe I can get Keith to make such a file for me, and then I could do my testing. It's odd that he didn't recognize the problem I was having. Maybe it's just because I was doing a spin test rather than a flight.

I'm tentatively planning to go to Airfest, but maybe only for Sunday/Monday. I'm sure weather conditions won't be right for a 4-stage until one of those two days.

Jim

 

[JimJarvis50]

At Marshall Space Center, there is a room with two complete sets of ALL ELECTRONICS that go into the SLS booster stage, and all they do, all day long, is feed data into those electronics for testing purposes. They even go so far as to use the exact cable lengths that will be in the actual booster.

The issue with multiple boosts resetting timers and interrupting the program is the kind of issue that should have been found in testing.

It would be very cool to be able to "feed in" the sensor data to see how everything responds. I think this is beyond my capabilities, but it would be fun to try.

The issue of the resetting timers isn't a bug, per se. It's just the way the altimeter was intentionally programmed. It needs to be documented more clearly that this is what it does, and I'm doing my best to convince Keith that a timer from the initial boost (that doesn't reset) is a more valuable feature. Making this change may not be a simple as it sounds.

Jim

 

[JimJarvis50]

Christmas has come early this year in the form of Version 1.8.6. Woohoo! I can now do my spin testing. I'll report back.

Jim

 

[plugger]

Christmas has come early this year in the form of Version 1.8.6. Woohoo! I can now do my spin testing. I'll report back.

Jim

How'd you go with the Firmware upgrade Jim? I attempted to upgrade my EasyMega from firmware v1.8.5 to v1.8.6 last night and the process kept crashing my flight computer. Just before attempting the EasyMega upgrade I did a TeleGPS upgrade which worked flawlessly and I was able to confirm it's running firmware v1.8.6 post upgrade. So it appears that the issue is solely around the EasyMega firmware.

Moving forward I'm planning on flight testing my EasyMega for staging purposes in the next few weeks. My hope/plan is to fly with just an ematch on the channel I chose to use for staging pyro and then (if it burns successfully) dump the flight into CSV and confirm my staging programming "logic" worked as intended. Would any of this testing be valuable to you? Is there any testing I can do in conjunction with my testing that might be of benefit to you?

 

[JimJarvis50]

How'd you go with the Firmware upgrade Jim? I attempted to upgrade my EasyMega from firmware v1.8.5 to v1.8.6 last night and the process kept crashing my flight computer. Just before attempting the EasyMega upgrade I did a TeleGPS upgrade which worked flawlessly and I was able to confirm it's running firmware v1.8.6 post upgrade. So it appears that the issue is solely around the EasyMega firmware.

Moving forward I'm planning on flight testing my EasyMega for staging purposes in the next few weeks. My hope/plan is to fly with just an ematch on the channel I chose to use for staging pyro and then (if it burns successfully) dump the flight into CSV and confirm my staging programming "logic" worked as intended. Would any of this testing be valuable to you? Is there any testing I can do in conjunction with my testing that might be of benefit to you?

On the firware upgrade, I have trouble uploading from my Windows 10 machine. I'm sure there is an easy fix, but I don't know it, so I upgrade from an old XP computer. No problems.

Sure, any data on the new firmware would be of value. I am making some progress in my spin testing. It's a bit difficult due to the transitions between the flight modes that I can't stop from happening, but I've been able to work around this for the most part. One thing I have seen is that when I spin the altimeter, the reported velocity goes down. I reloaded version 1.6.8 just to see how it behaved (I had a good flight on that version), and the velocity goes up withe acceleration as you would expect. This is a bit confusing. I recall that Keith made a change to the calculation of speed that used both barometric and accelerometer readings (I think). This was version 1.8.1, and since I'm not getting any change in barometric altitude when spin testing, this may be why I am seeing this behavior. In any case, it would be helpful to see that the altimeter indeed sees speed values that make sense.

It might also be helpful to try barometric apogee deployment on one of the A-D channels. There is no longer a choice of ascending and descending. I believe the idea now is to select "speed < 0" for apogee detection. However, in the past, as with the Raven, I have selected descending and then V< xxx, which is how the Raven does Mach lockout. It is no longer possible to do that, since the speed < parameter would have to be set to zero (and can't be used for Mach lockout). Is that clear? So, I'm not quite sure how barometric apogee should be performed.

Otherwise, I think I have verified that time of flight is indeed time since launch. I haven't verified the burnout logic change yet. I did look at the tilt values in a few tests and there are some observations there that will require more testing. It'll take another evening or two.

Jim

PS - One other odd thing I noticed. Per the above, I changed the firmware back to 1.6.8 (using my XP computer). When I downloaded the "flight" on my Windows 10 computer, the altimeter changed the operating interface back to an earlier version. I had to reload the 1.8.6 onto my Windows 10 computer. I have no idea how that happened.

 

[plugger]

On the firmware upgrade, I have trouble uploading from my Windows 10 machine. I'm sure there is an easy fix, but I don't know it, so I upgrade from an old XP computer. No problems.

Heh. Tried that, but my wife's ancient XP "TV laptop" didn't recognise my EasyMega over USB. In the end I moved the 1.8.6 firmware to my Win10 box with Altos 1.7, ran the firmware upgrade and it didn't crash. BUT, the Serial and RF Calibration values were all zeroes. So back to the Win10 Altos 1.8.6 box, choose 1.8.5 to downgrade, take note of the values, cancel, power down, and back to the 1.7 box. I was then able to successfully upgrade the firmware to 1.8.6 with AltOS 1.7 and self supplied config values. Phew...

Sure, any data on the new firmware would be of value...
It might also be helpful to try barometric apogee deployment on one of the A-D channels. There is no longer a choice of ascending and descending. I believe the idea now is to select "speed < 0" for apogee detection. However, in the past, as with the Raven, I have selected descending and then V< xxx, which is how the Raven does Mach lockout. It is no longer possible to do that, since the speed < parameter would have to be set to zero (and can't be used for Mach lockout). Is that clear? So, I'm not quite sure how barometric apogee should be performed.

Here's my current planned config. Comments?

Also, instead of burning e-matches for the test I was considering using grain of wheat bulbs as my expectation is that the data would still be valid with them used in the test. Do you think that would work?

PS - One other odd thing I noticed. Per the above, I changed the firmware back to 1.6.8 (using my XP computer). When I downloaded the "flight" on my Windows 10 computer, the altimeter changed the operating interface back to an earlier version. I had to reload the 1.8.6 onto my Windows 10 computer. I have no idea how that happened.

That's really bizarre.

 

[JimJarvis50]

Heh. Tried that, but my wife's ancient XP "TV laptop" didn't recognise my EasyMega over USB. In the end I moved the 1.8.6 firmware to my Win10 box with Altos 1.7, ran the firmware upgrade and it didn't crash. BUT, the Serial and RF Calibration values were all zeroes. So back to the Win10 Altos 1.8.6 box, choose 1.8.5 to downgrade, take note of the values, cancel, power down, and back to the 1.7 box. I was then able to successfully upgrade the firmware to 1.8.6 with AltOS 1.7 and self supplied config values. Phew...


Here's my current planned config. Comments?

Also, instead of burning e-matches for the test I was considering using grain of wheat bulbs as my expectation is that the data would still be valid with them used in the test. Do you think that would work?



That's really bizarre.

It looks like your channel A would fire at burnout and B would fire at Apogee. I would probably include T>1 on both channels so that they don't fire on the ground. Not sure if that would happen, so just cheap insurance. I presume you're expecting greater than 1500 meters at 3 seconds (i.e., the 1500 meters is your altitude check). I've never heard the term "grain of wheat bulbs". Had to google that one. I think using them would be fine. The file will tell you if the channel fired.

Jim

 

[plugger]

It looks like your channel A would fire at burnout and B would fire at Apogee. I would probably include T>1 on both channels so that they don't fire on the ground. Not sure if that would happen, so just cheap insurance. I presume you're expecting greater than 1500 meters at 3 seconds (i.e., the 1500 meters is your altitude check). I've never heard the term "grain of wheat bulbs". Had to google that one. I think using them would be fine. The file will tell you if the channel fired.

Fair comments on Channel A and B. Basically my thoughts are along the lines of "configure every pyro channel differently, fly the thing in ride along mode, and compare the results of config vs actual results post flight". I'll go through and make those mods tonight. As for my presumptive altitude for staging, thanks for pointing that out. I think I inadvertently read that as in feet, not meters. I think what I'll instead do is configure Channel C with the same config as Channel D and then modify the "Height above pad greater than" and set it to 250 meters. Then I'll mod Channel D to set the "Height above pad greater than" 3km. Basically I'd like to see and confirm that it does indeed fire Channel C as it should successfully pass the config criteria and it should NOT fire Channel D as there's no way I'd be at 3km AGL in under 3 seconds.

Also I too didn't know what a grain of wheat bulb was until I got down here. They're great for simple confirmation/bench testing use, both with the Raven test flight feature as well as using them to demonstrate how the magnetic apogee detectors I fly work to people on the ground.

All going to plan I'll have data for you by the end of the weekend.

drew

 

[JimJarvis50]

Fair comments on Channel A and B. Basically my thoughts are along the lines of "configure every pyro channel differently, fly the thing in ride along mode, and compare the results of config vs actual results post flight". I'll go through and make those mods tonight. As for my presumptive altitude for staging, thanks for pointing that out. I think I inadvertently read that as in feet, not meters. I think what I'll instead do is configure Channel C with the same config as Channel D and then modify the "Height above pad greater than" and set it to 250 meters. Then I'll mod Channel D to set the "Height above pad greater than" 3km. Basically I'd like to see and confirm that it does indeed fire Channel C as it should successfully pass the config criteria and it should NOT fire Channel D as there's no way I'd be at 3km AGL in under 3 seconds.

Also I too didn't know what a grain of wheat bulb was until I got down here. They're great for simple confirmation/bench testing use, both with the Raven test flight feature as well as using them to demonstrate how the magnetic apogee detectors I fly work to people on the ground.

All going to plan I'll have data for you by the end of the weekend.

drew

Actually, since you're using T>, D would fire if you got to that altitude. It might be quite a bit after 3 seconds though. If you want to use an altitude check, you need to include a T< value. You might set T>3 and T<3.2, or something like that. In this case, T>3 is where you want the ignitor to fire, but T<3.2 closes the window if the altitude check altitude is not reached by that point. You have to use a T< value.

I have lots of those bulbs that I use for testing. Just never knew that name. Fits though.

Looking forward to your data. Good luck.

Jim

 

[OverTheTop]

If you make the firing time customisable for each channel they can be used for other things, like controlling a Vertical Trajectory System or similar . They just get used as a digital output.

 

[plugger]

So I was able to fly yesterday with the EasyMega in "ride along" mode. Good news is that I've got data. The suboptimal news is that I had a flight anomaly during boost at ~2k' AGL. So at around 9 seconds you'll see a pretty big spike in the data where I suspect I had a deployment event during coast. From the ground the rocket went from vertical to horizontal quite quickly and violently. I'm uncertain as to whether the "backup" motor eject fired early or my StratoLogger CF fired the apogee charge early. I'm leaning towards the motor being at issue but I won't know until tomorrow night at the earliest. The motor in question was a newish AeroTech I357T with a 14 second delay. Unfortunately I left my USB to serial adapter at work and my PF Data Transfer Kit is the old serial based model.

Anyway, here's the final EasyMega config that I flew with.

And here's a link the flight data file.

https://drive.google.com/open?id=1FbiwcMry9rUfZOwZRjJEvKPM6tLB1KaG

From my perspective the test was successful despite the anomaly. Channel C fired when required and configured as I hoped. Channel D didn't fire, which was expected and good. And you're correct, Channel A fired after burnout and Channel B fired at apogee.

I reckon I'll have another test flight in a couple/few weeks. If you have any other configs/options you'd like me to configure just let me know.

Finally, I should mention that the night before the flight I manually tested/fired all 4 pyro channels on the bench to ensure the grain of wheat bulbs worked and would light up. I thought it was a good test to run given your previous experiences with bench testing causing pyro channels to not fire the next time they're called upon to do so.

 

[JimJarvis50]

So I was able to fly yesterday with the EasyMega in "ride along" mode. Good news is that I've got data. The suboptimal news is that I had a flight anomaly during boost at ~2k' AGL. So at around 9 seconds you'll see a pretty big spike in the data where I suspect I had a deployment event during coast. From the ground the rocket went from vertical to horizontal quite quickly and violently. I'm uncertain as to whether the "backup" motor eject fired early or my StratoLogger CF fired the apogee charge early. I'm leaning towards the motor being at issue but I won't know until tomorrow night at the earliest. The motor in question was a newish AeroTech I357T with a 14 second delay. Unfortunately I left my USB to serial adapter at work and my PF Data Transfer Kit is the old serial based model.

Anyway, here's the final EasyMega config that I flew with.

And here's a link the flight data file.

https://drive.google.com/open?id=1FbiwcMry9rUfZOwZRjJEvKPM6tLB1KaG

From my perspective the test was successful despite the anomaly. Channel C fired when required and configured as I hoped. Channel D didn't fire, which was expected and good. And you're correct, Channel A fired after burnout and Channel B fired at apogee.

I reckon I'll have another test flight in a couple/few weeks. If you have any other configs/options you'd like me to configure just let me know.

Finally, I should mention that the night before the flight I manually tested/fired all 4 pyro channels on the bench to ensure the grain of wheat bulbs worked and would light up. I thought it was a good test to run given your previous experiences with bench testing causing pyro channels to not fire the next time they're called upon to do so.

Thanks for posting this information! It is good to see that both speed and tilt angle behave as expected. In the spin testing, I can't get speed to behave (I think it is calculated from both baro and accel data), and I can't get tilt to behave either. For some reason, the spin process causes tilt to go 180 degrees out of phase. I don't know why, but I can't get around it, so, it is good to see that there is not some issue with this in your flight.

Jim