K.I.S.S. Flight Computer Development.

[Mason T]

I would agree with Chris on a single sensor solution. I looked back at digikey and this appears to be the best option availible from ground "to" 10mbar. As you have pointed out the accuracy there isn't spec'd.

 

[Adrian A]

AFAIK, there are no digital baro sensors that will resolve to 85K or more, because at that altitude any pressure change goes below the single-bit resolution of the digital output. From a practical point of view, they're good to about 60K, 70K is pushing it.

https://www.te.com/usa-en/product-325540009-50.datasheet.pdf

This one is spec'd for 10 mbar and has good looking test data down to about 50 mbar. I was using it in the Raven and Raven2. The gel membrane gets gunked up over time.

 

[kjhambrick]

https://www.te.com/usa-en/product-325540009-50.datasheet.pdf

This one is spec'd for 10 mbar and has good looking test data down to about 50 mbar. I was using it in the Raven and Raven2. The gel membrane gets gunked up over time.

Adrian --

Not your issue, the link resolves OK, but the linked .pdf is an empty file for me ...

-- kjh

 

[Adrian A]

Adrian --

Not your issue, the link resolves OK, but the linked .pdf is an empty file for me ...

-- kjh

https://www.te.com/usa-en/plp/Xoye8p.html

 

[AlexBruccoleri]

I saw this today and think it is great. I like the accelerometer being included. IMHO do not be discouraged by other vendors selling similar and possibly cheaper boards. It is fun to try new things and being a vendor is fun. Simply doing that "for fun" is plenty good of a reason. My only cautionary note is people use electronics for primary recovery which is critical for safety so please test whatever you sell thoroughly.

 

[Spacedog49Krell]

FRAM would be a good front-end buffer for flash memory, especially for high-speed sampling. I've been waiting for the price to come down close to the price of EEPROM's for 10 years... no bueno. Not enough demand, too few suppliers, it's still a specialty part.

I miss my engineering career years. Ramtron gave me all the FRAMs I wanted. They brought potential customers over to my lab to observe my latest project using FRAMs. The price and memory size never matched EEPROMs or Flash.

 

[rocket_troy]

https://www.te.com/usa-en/product-325540009-50.datasheet.pdf

This one is spec'd for 10 mbar and has good looking test data down to about 50 mbar. I was using it in the Raven and Raven2. The gel membrane gets gunked up over time.

Thanks Adrian.

TP

 

[rocket_troy]

Define 'good'. You can get sensors that are monotonic down to a vacuum. But the error in altitude estimation becomes very large down there.

To me, something like the MS5540CM accuracy plot that Adrian linked to extending down to 10mbar I would class as "good" or at least good enough ie +-1.5mbar.

TP

 

[kjhambrick]

https://www.te.com/usa-en/plp/Xoye8p.html

Thanks Adrian !

You got me looking at 'the latest' sensor packages.

A lot has changed in 25 years

This DIGIKEY > TE Connectivity Measurement Specialties - MS860702BA01-50 is interesing ...

Pressure, Temperature and Relative Humidity in a 3mm x 5mm package.

I wonder how accurate Humidity readings would be from within an Av-Bay ?

Air Density varies a little with RH and I usually factor in a number for the ground level relative humidity when converting Pressure and Temperature to Air Density for Drag and Thrust studies

Plot stolen from: ELDRIDGE > Air Density Impacts on Fan Performance Part One: What Affects Air Density?

Might be an interesting plot ...

Thanks again.

-- kjh

 

[jderimig]

To me, something like the MS5540CM accuracy plot that Adrian linked to extending down to 10mbar I would class as "good" or at least good enough ie +-1.5mbar.

TP

Again my opinion: Accuracy at such low pressure is not needed, as long as the response is monotonic (which most are) you can use the response to detect apogee reliably even in the absence of good accuracy.

Trying to deduce altitude at the limit of the atmosphere using a pressure reading is pointless. Dead reckoning from an earlier more accurate baro reading and speed will be more accurate.

 

[rocket_troy]

Again my opinion: Accuracy at such low pressure is not needed, as long as the response is monotonic (which most are) you can use the response to detect apogee reliably even in the absence of good accuracy.

Trying to deduce altitude at the limit of the atmosphere using a pressure reading is pointless. Dead reckoning from an earlier more accurate baro reading and speed will be more accurate.

I guess I can't really argue with any of those points.

Saying that, the sensor most likely being a strain measurement on a diaphragm(?) perhaps could provide some analogies to the image quality of CCD/CMOS sensors insofar as size matters. Unfortunately, size matters (inversely) for 99.9%+of the typical applications for these sensors (phones?) where there are serious packaging and footprint constraints, so perhaps (given that phones don't typically provide their baro readings in rarefied air) provide far less emphasis on performance at those extremes.

TP

 

[Mason T]

I saw this today and think it is great. I like the accelerometer being included. IMHO do not be discouraged by other vendors selling similar and possibly cheaper boards. It is fun to try new things and being a vendor is fun. Simply doing that "for fun" is plenty good of a reason. My only cautionary note is people use electronics for primary recovery which is critical for safety so please test whatever you sell thoroughly.

Thank you very much, Oh I'm not discouraged at all. I am aiming for a feature set that doesn't exist as far as I am aware. Will it be the cheapest? Most certainly not. I believe Chris will hold on to that title for quite some time. It will be a good value in my opinion. Even if it doesn't sell it makes for a great resume piece that can be taken to interviews. Though I am quite happy in my current position it never hurts to be prepared.

I share the same feelings feelings on testing it thoroughly.

The current plan is to:

• Fly it in only a data collecting role across many kinds of flights from low and slow to mach+ and high to gather data for algorithm development.
• Create the algorithms for apogee detection and main deployment and run it through all of the collected flight logs (shooting for 30+ flights) to ensure it works as it should with no false detections.
• It will then transition to flying with no connection to ejection charges and verifying that there is no false triggering over several flights
• it will then transition to flying as the primary with other commercial flight computers acting as a backup
• Once all of that is successful it can move into the role of a sole flight computer.

I have a list of people that are going to work with me on collecting this data and running these flights to help keep the locations and setups diverse to catch any issues as early as possible.

 

[Spacedog49Krell]

A friend flew a BMP280 on a balloon flight to 27 km and he sent me a copy of the barometric altitude data file. The data might be relevant to your question of accuracy at extreme altitudes. The BMP280 is spec'd as accurate to 10km. This flight data shows a constant slope to 13 km, where there is a noticeable slope change. The slope remained linear to the final reading of 22 km. Sorry I can't show the complete flight. The file is millions of rows of data and my Excel only loads half of it. The Bosch calibration algorithm appears to provide accurate altitude readings to 13 km. Altitudes above 13 km are inaccurate, but have a linear slope. Characterization of the slope change would improve the accuracy.

 

[Adrian A]

Thanks Adrian !

You got me looking at 'the latest' sensor packages.

A lot has changed in 25 years

This DIGIKEY > TE Connectivity Measurement Specialties - MS860702BA01-50 is interesing ...

Pressure, Temperature and Relative Humidity in a 3mm x 5mm package.

I wonder how accurate Humidity readings would be from within an Av-Bay ?

Air Density varies a little with RH and I usually factor in a number for the ground level relative humidity when converting Pressure and Temperature to Air Density for Drag and Thrust studies
View attachment 636420
Plot stolen from: ELDRIDGE > Air Density Impacts on Fan Performance Part One: What Affects Air Density?

Might be an interesting plot ...

Thanks again.

-- kjh

Thanks for that. It looks like at normal atmospheric temperatures, relative humidity is a small effect. Temperature, however, is a first-order effect, causing under-reporting of rocket altitude on hot days summer days on the order of 10%. The standard model used to convert pressure to altitude is based on an assumption of a sea level temperature of around 50F IIRC, and colder at higher altitudes above sea level. And before anyone asks, the temperature of the altimeter inside an av-bay is not representative enough of the outside ambient temperature to provide useful compensation, since it can easily be 10F-40F hotter inside than outside depending on the color of the rocket, whether there is a breeze, etc. GPS is going to beat barometric sensing of altitude for accuracy for pretty much any flight we're interested in.

But barometric sensing is still useful for apogee detection, main deployment etc. because it's more reliably available. Transient measurements (sometimes very large transients) from leaky av-bays, sunlight through vent holes, etc. have to be ignored, though.

 

[Alan15578]

You don't actually need good baro altimeter measurements to 100k or whatever. After burn out you start an extended Kalman filter to estimate time to apogee. Let the filter converge, and even after the sensor drops out, the clock still runs.

 

[kjhambrick]

Thanks for that. It looks like at normal atmospheric temperatures, relative humidity is a small effect. Temperature, however, is a first-order effect, causing under-reporting of rocket altitude on hot days summer days on the order of 10%. The standard model used to convert pressure to altitude is based on an assumption of a sea level temperature of around 50F IIRC, and colder at higher altitudes above sea level. And before anyone asks, the temperature of the altimeter inside an av-bay is not very representative enough of the outside ambient temperature to provide useful compensation, since it can easily be 10F-40F hotter inside than outside depending on the color of the rocket, whether there is a breeze, etc. GPS is going to beat barometric sensing of altitude for accuracy for pretty much any flight we're interested in.

But barometric sensing is still useful for apogee detection, main deployment etc. because it's usually more available. Transients (sometimes very large trasients) from leaky av-bays, sunlight through vent holes, etc. have to be ignored, though.

Adrian --

Yes, the effect of Relative Humidity on Air Density is a very small effect compared to the 1st-order effects due to Temperature and Pressure ( a few percent at realistic launch site temperatures and pressures ).

And yes, the integrated Temperarure Sensors flying in an Av-Bay are not able to measure true air temperature.

But I wonder if a Relative Humidity sensor in an Av-Bay might work better than a Temperature Sensor in the Av-Bay ?

My guess would be ... probably not ... for all the same reasons you mention that the air temperature cannot be measured ...

But if one were able to measure the real-time Relative Humidity for a flight ( either going up or coming down ), it might be fun to see what a rocket flying through a cloud looks like

-- kjh

EDIT: P.S. thanks for including raw air pressure in atm in your low_rate file ! It makes my air density calcs much easier than in the olden days !

 

[Spacedog49Krell]

You don't actually need good baro altimeter measurements to 100k or whatever. After burn out you start an extended Kalman filter to estimate time to apogee. Let the filter converge, and even after the sensor drops out, the clock still runs.

The Kalman algorithm will only work if the vehicle remains in the same attitude after the last valid data input. Kip Daugirdas MESOS second stage started coning and tumbling above 40 km. That additional drag profile prevented the vehicle from surpassing 100 km. An extended Kalman algorithm clock approach predicts a higher apogee and longer time to apogee than what might be attainable.

 

[cerving]

Humidity sensors are likely to be even slower to respond to changes than temperature sensors. It would be a fun experiment, but I'm guessing that the data would show that it's not useful in flight.

 

[Alan15578]

The Kalman algorithm will only work if the vehicle remains in the same attitude after the last valid data input. Kip Daugirdas MESOS second stage started coning and tumbling above 40 km. That additional drag profile prevented the vehicle from surpassing 100 km. An extended Kalman algorithm clock approach predicts a higher apogee and longer time to apogee than what might be attainable.

Nothing will save you from a disaster like that; forget apogee and implement the safest flight abort.

 

[cerving]

If you're really lucky, tumbling at that altitude "might" subside once the air gets thick enough for the fins to cut in... if they don't shear off first.

 

[rocket_troy]

The Kalman algorithm will only work if the vehicle remains in the same attitude after the last valid data input. Kip Daugirdas MESOS second stage started coning and tumbling above 40 km. That additional drag profile prevented the vehicle from surpassing 100 km. An extended Kalman algorithm clock approach predicts a higher apogee and longer time to apogee than what might be attainable.

That's one of the concerns I have with the advocates of using similar extrapolation for peak altitude attainment for, say, loss of GNSS lock. Particularly if it's a Karman Line shot - and it's not something to be ruled out as an exceptional event in near vacuum conditions.

TP

 

[OverTheTop]

This one is spec'd for 10 mbar and has good looking test data down to about 50 mbar. I was using it in the Raven and Raven2. The gel membrane gets gunked up over time.

or the mice eat the membrane once the rocket has landed.

 

[cerving]

That sounds like a story worth hearing about...

 

[Spacedog49Krell]

That's one of the concerns I have with the advocates of using similar extrapolation for peak altitude attainment for, say, loss of GNSS lock. Particularly if it's a Karman Line shot - and it's not something to be ruled out as an exceptional event in near vacuum conditions.

TP

Troy,
You bring up a very valid issue. What other options are available to accurately determine altitude should GNSS lock be lost? Ground based radar has been used in the past. Ground based radio transponders could also be used. I have extensive experience with lasers, but laser based LIDAR is still futuristic. The best option now is high speed IMU data, but that requires the recovery of the vehicle.

2 DoF & 3 DoF attitude control would allow for extrapolation of the altitude. Joe Barnard's latest 3 DoF fin tab guidance flight looked very promising. I also have algorithms for pitch/yaw control of a spinning rocket using a single cold gas nozzle. We need to get more flight time above 30 km to test new ideas.

After the latest Starship flight, I'm wondering if 100 km is a good space demarcation line.

 

[rocket_troy]

Troy,
You bring up a very valid issue. What other options are available to accurately determine altitude should GNSS lock be lost? Ground based radar has been used in the past. Ground based radio transponders could also be used. I have extensive experience with lasers, but laser based LIDAR is still futuristic. The best option now is high speed IMU data, but that requires the recovery of the vehicle.

John,
I can't see any fundamental reason why it would necessitate vehicle recovery - okay for purely IMU dead reckoning there are bandwidth issues with telemetry, but, for me, I'd fuse that IMU data in real time with GNSS for an *INS* solution, then send the inertially generated/augmented GNSS packets as telemetry as per lock conditions. Ublox already offer GNSS modules with INS support as do many other GNSS module manufacturers. The problem with off-the-shelf already fused solutions is they often are limited to a 16G accelerometer, although I think there are 'affordable' solutions that provide more.
Yes, it would be far preferable to retrieve the electronics for a proper dissection of the inertial data, but I (as an external critic) would likely accept INS telemetry with quality and duration provisos.

Of course, I wrote all that under the tunnel visioned utopian world of nice (reasonably) straight flight all the way to the line. Whether an onboard INS fusing at dunno... 100hz? can cope with a (dunno... 2hz?) flat spin is a question well beyond me.

TP

 

[Spacedog49Krell]

John,
I can't see any fundamental reason why it would necessitate vehicle recovery - okay for purely IMU dead reckoning there are bandwidth issues with telemetry, but, for me, I'd fuse that IMU data in real time with GNSS for an *INS* solution, then send the inertially generated/augmented GNSS packets as telemetry as per lock conditions. Ublox already offer GNSS modules with INS support as do many other GNSS module manufacturers. The problem with off-the-shelf already fused solutions is they often are limited to a 16G accelerometer, although I think there are 'affordable' solutions that provide more.
Yes, it would be far preferable to retrieve the electronics for a proper dissection of the inertial data, but I (as an external critic) would likely accept INS telemetry with quality and duration provisos.

TP

I'm currently at 2 ms IMU data moving to 1 ms IMU data. Fusing GNSS to the IMU data is still a future project.

 

[rocket_troy]

I'm currently at 2 ms IMU data moving to 1 ms IMU data. Fusing GNSS to the IMU data is still a future project.

Yeah, that's doozy of a project. I know precious little about the math involved, but looking at the pricing difference between say an Xsens MTi1 which does internal & mag fusing to an MTi-7 or MTi-8 that also fuses that with an external GNSS feed suggests it's no trivial exercise.

TP

 

[OverTheTop]

That sounds like a story worth hearing about...

I flew my Velociraptor quite a while back and for whatever reason didn't find it after it had landed. It sat in the field for 11 months, eventually being found by the farmer. I got the rocket back and emptied it out. Evidence of ants, cockroaches and other assorted insects. Also evidence of mice, and the membrane on the pressure sensor on the Raven2 had been chewed out. I did replace the sensor but never quite trusted it for flight after that. The fincan was still relatively good but the cardboard airframe was a bit "under the weather", so I rebuilt the rocket with fiberglass airframe. Still flying.

 

[cerving]

ST Micro has some GNSS chips that do dead reckoning, I attended a presentation on them a few months back. Not sure if they'd handle rocketry flights, though... I think they're primarily for automobiles, the dead reckoning takes over when you go through a tunnel and lose the GNSS feed.

 

[OzHybrid]

The majority of flights would be below 10000ft. That's where the market is for a KISS computer. The scope discussed here is already well beyond KISS.
So KISS or build a full blown 100k capable flight computer. What is it you want to make?