RRC3 Data Agreement

[Sailfish1957]

I tested a new AV-bay with an RRC3 in a vacuum chamber to check altitude ejection charges. The RRC3 was flawless - having checked drove and main release altitude data via blue tooth module to mDACs on my pc. Data was awesome and also coincided with a Jolly Logic altimeter that I put in the vac chamber. The only issue was that the RRC3 “beeping” audible altitude readout was under indicating by about 1000’.

Anyone have an explanation for that?

 

[Steve Shannon]

So are you saying that the RRC3 beeped out one altitude, such as 2502’ and the recorded altitude on the same RRC3 was about a thousand feet more, such as 3512’?

I would write customer service at Missileworks.

 

[kalsow]

Is it reporting meters instead of feet? There's a setting to control that

 

[user 30299]

What was the altitude per mDACS, and what was the altitude per the beeps?

 

[Sailfish1957]

So are you saying that the RRC3 beeped out one altitude, such as 2502’ and the recorded altitude on the same RRC3 was about a thousand feet more, such as 3512’?

I would write customer service at Missileworks.

First, we are talking about high altitude tests at or above 13k, so the percentage of disagreement is less.

I emailed Jim Amos (missleworks). He said vacuum tests can create anomalies as follows:
“Vac testing in a chamber often times defies physics. Gen 3 units rely upon velocity displacement integration, so you must pull and hold the vacuum until the drogue/apogee event has fully integrated and been activated before restoring ambient equilibrium. If you wanted to retry the test, this simulation method should achieve more consistent results.”

Makes sense to me when pulling the vacuum, there is a bit of vacuum instability at vacuum pump shutdown and valve closure. I noticed that the Jolly Logic will waver slightly at that point a bit.

 

[Sailfish1957]

What was the altitude per mDACS, and what was the altitude per the beeps?

12344 on mDACS, 11434 on beeps.

 

[Sailfish1957]

Is it reporting meters instead of feet? There's a setting to control that

No, I have all feet set on the system.

 

[cerving]

Vacuum chamber tests are not necessarily quantitative, they're basically good for checking your output channels but not a whole lot more. The problem is that the vacuum tends to be drawn (and released) much faster than the pressure would change in an actual flight, so you can have things like what you have seen occur, plus it's not uncommon for the main and drogue to appear to fire simultaneously because of the fast pressure change. This is especially true for "flights" of only a few thousand feet. If your "altitude" seems reasonable and both channels work, your altimeter is good to fly.

 

[Sailfish1957]

Vacuum chamber tests are not necessarily quantitative, they're basically good for checking your output channels but not a whole lot more. The problem is that the vacuum tends to be drawn (and released) much faster than the pressure would change in an actual flight, so you can have things like what you have seen occur, plus it's not uncommon for the main and drogue to appear to fire simultaneously because of the fast pressure change. This is especially true for "flights" of only a few thousand feet. If your "altitude" seems reasonable and both channels work, your altimeter is good to fly.

I agree. I am able to release the vacuum back toward ground level/ambient very slowly with my rig. The main went at exactly 500’. The apogee/d rogue and main flight events are very well graphically represented in mDACS as well.

 

[wonderboy]

So if I understand the problem you have, it is the same as one that I complained about also. This issue is independent of how you test the altimeter, either real life or in a vacuum chamber.

To restate the problem: the altitude beeped out by the altimeter does not correlate to the data downloaded from that flight onto a PC and plotted in mDACS. The peak altitude observed for the SAME flight is different.

This is the case for every real flight of my RRC3 as well, so it's not a vacuum chamber effect.

I contacted Jim Amos at missile works about this, but unfortunately I can't find the e-mail exchange about it.

If I remember the gist of the explanation correctly, it's that the time history data saved to the internal memory are processed by the mDACS software in a different way than the live altitude calculations the RRC3 performs. The beeped out altitude is based on the live RRC3 calcs, but the mDACS data on the PC is (obviously) processed by the PC. This answer didn't completely make sense to me (EDIT: I thought you'd just use the exact same atmosphere model for both and crunch the same data and get the same result, but perhaps it's due to math limitations of the embedded processor versus a PC), and I may be recalling it incorrectly, but I just gave up on trying to understand it and decided to just not worry about it.

I also noticed another discrepancy related to the arming altitude. I noticed on the PC graph instances where the landing altitude is lower than the launch altitude. I don't know that this is related to the problem noted in the original post, but I found it to be moderately annoying as well. This was explained as being due to how much data can be stored "pre-trigger", where the trigger event is the rocket hitting the arming altitude. The system only saves X number of data points prior to the launch detection event (tied to the arming altitude). A rocket that accelerates slowly and takes a while to hit the arming altitude may experience loss of the early on-the-pad pressure data points. As a result, the graph is treating the first data point found as the launch pad elevation, when in reality the rocket was already in flight at that time. It isn't anything super troubling, but it just triggers my OCD a bit when post processing flight info.

 

[Sailfish1957]

So if I understand the problem you have, it is the same as one that I complained about also. This issue is independent of how you test the altimeter, either real life or in a vacuum chamber.

To restate the problem: the altitude beeped out by the altimeter does not correlate to the data downloaded from that flight onto a PC and plotted in mDACS. The peak altitude observed for the SAME flight is different.

This is the case for every real flight of my RRC3 as well, so it's not a vacuum chamber effect.

I contacted Jim Amos at missile works about this, but unfortunately I can't find the e-mail exchange about it.

If I remember the gist of the explanation correctly, it's that the time history data saved to the internal memory are processed by the mDACS software in a different way than the live altitude calculations the RRC3 performs. The beeped out altitude is based on the live RRC3 calcs, but the mDACS data on the PC is (obviously) processed by the PC. This answer didn't completely make sense to me (EDIT: I thought you'd just use the exact same atmosphere model for both and crunch the same data and get the same result, but perhaps it's due to math limitations of the embedded processor versus a PC), and I may be recalling it incorrectly, but I just gave up on trying to understand it and decided to just not worry about it.

I also noticed another discrepancy related to the arming altitude. I noticed on the PC graph instances where the landing altitude is lower than the launch altitude. I don't know that this is related to the problem noted in the original post, but I found it to be moderately annoying as well. This was explained as being due to how much data can be stored "pre-trigger", where the trigger event is the rocket hitting the arming altitude. The system only saves X number of data points prior to the launch detection event (tied to the arming altitude). A rocket that accelerates slowly and takes a while to hit the arming altitude may experience loss of the early on-the-pad pressure data points. As a result, the graph is treating the first data point found as the launch pad elevation, when in reality the rocket was already in flight at that time. It isn't anything super troubling, but it just triggers my OCD a bit when post processing flight info.

Its a complicated matter - According to Jim, the altitude in the RCC3 logic is "uses velocity displacement integration, so you must pull and hold the vacuum until the drogue/apogee event has fully integrated and been activated before restoring ambient equilibrium", I take to mean do not "ease off" on the vacuum in the chamber until the apogee is recognized and the drogue event takes place.

I had very close agreement between the mDACS data regarding altitude and a Jolly Logic One that I placed in the vacuum chamber to have a visual on the actual altitude (particularly the Main deployment.

Sooooo, I'm going with the mDACS info, as it is in agreement and I can record a higher flight. ;-)