 |
||
|
 |
Larry's Flight Computer StuffOK, I haven’t changed any of this in awhile. Why? Because I went commercial. Another rocketeer (Rob Briody of Ignitor Man fame), who happens to be a professional EE and I teamed up to make commercial flight computers, and offer them for sale through retailers. If you are interested, see the G-Wiz site. End of commercial. I was asked to give this presentation on Altimiters, on behalf of G-Wiz, at the 2001 NARCON in Texas. I've been playing with Paul Campbell's 'Taniwha' flight computer. This is a small computer suitable for flying in HPR rockets, recording flight data, and maybe someday staging, and ejecting parachutes at appropriate times. This is a very flexible computer, with hardware details like what sensors to use left up to the builder (yes, it's a kit). Software is also in a rather primitive stage. Paul has supplied a ROM based monitor, BASIC, Forth, and some code for dealing with a 10bit ADC and such. He has also supplied cross assemblers for major host machines. Take a look! good stuff. I've done a lot with this system. You can browse through all the boring details, or skip to what you might be interested in:
Also, Doug Steinfeld has made some interesting modification on my latest version (especially nice, as I have been working on another project so haven't added anything here recently. I will though, promise!). Look at Doug's chages!.
Taniwha Computer #1 hardware:
Taniwha Computer #2 hardware:
This unit, with version 2.0 of my software (below) successfully controlled duel deployment at BALLS '97!!!
Flight Computer Software
Disclaimer: I make no promises about any of this software, so please, do your own tests, and take responsibility for your own decisions. I refuse to take any responsibility for any damage that may occur from use of my software. It is provided for example purposes only!For those of you with Java capable browsers, I have a page with a little Java applet that will graph the data I've collected from various flights. Take a look! Source for reading a MAX186 12bit, 8 channel ADC. Source for reading an LTC1298 12bit, 2 channel ADC. Source for reading and writing NVRAM. The write/read routines now return with carry set if the memory is not present (or responding). This source now also has a simple test program. Source for a quick, accurate baro-output to altitude routine. This code assumes a MPX4115A and a 12bit ADC, but there should be enough information given in the comments to modify the code/data for other configurations. Basically, the routine works by using a table of pre-calculated altitude values at selected intervals, and uses linear interpolation to calculate the values in between. The altitudes generated by this code will generally be within a foot of the normally calculated value, but rarely more then 2 feet off (those at the higher altitudes). Of course, this code should be used to generate altitude by taking the difference in altitude between a given sample, and pre-liftoff. When using with a 10 bit ADC, the baro reading should be multiplied by 1.2 before passing to this routine. The SRAM data logger mentioned below does this. Source for an integrated Monitor / Flight computer (v2.0), And ROM image, or both, zipped. This contains complete sources for launch detection, data logging into NVRAM, stores multiple flights in NVRAM, burnout, apogee, and low -altitude detection, end-of-flight maximum altitude beep-out, and optional triggering of pyro ports. Also has monitor commands for getting NVRAM information. This has been used to fire a pyro ports at apogee and low altitude! The data dump does show when it thinks it fires a pyro port. This code does assume my hardware config (LDC1298 ADC, accel, baro, beeper), but the source can be assembled to work with the ADC1034 or MAX186. Source code for data logging and event handling and Memory image. This code is designed to run in SRAM. It should be loaded as a code block in NVRAM, and the FC configured to autoload it at power up. This is a new feature in Paul's monitor source version 2.20. This code will record acceleration and baro data 16 times per second, detect burnout, apogee, and return to low altitude (255 feet), and can trigger pyro charges upon detection of those events. It will also beep out maximum altitude if a beeper is connected to p1.5. This code does not yet deal with multiple data blocks per NVRAM, so it will overwrite its own image in NVRAM. I haven't yet updated this code to v2.0 because of a bug in the ROM monitor (which I fixed in my version). My software needs to figure out how big the NVRAM is for the multiple data set feature, and the code that detects timeouts during NVRAM access will hang in v2.3. I have sent Paul a message about this, but I haven't seen an update yet. Source code for functions to read and display flight data in NVRAM as recorded by the above autolog code. Also RAM Image. This code can display the header information (base altitude and acceleration readings, configuration, etc.) and dump acceleration, baro, and state data in decimal, as comma separated values. This dump can be captured to a file and graphed by my Java program or imported to spreadsheets like Excel. A data dump of NVRAM looks like this: :-) dn 0
The output data format is: 1st (Acceleration) column: ADC units of acceleration, normalized so that a reading of 0 is sitting on the pad, ready for lift off (ie 1 gee). This number is in units of 1/40 G (for 12bit data, 1/28.57G for 10bit data). 2nd (Baro) column: ADC Units, barometric sensor output. This will be a number in the range 204 to 4095. The 3rd (state) column shows where the computer thinks it is in the flight profile. This is an 8 bit number that will show in the range 7-255. Here is what the bits mean:
The state byte is only written once per nvram page (each 5 ADC entries).
CalculationsThere are many things that affect how you convert from 'ADC Units' to something more understandable, like feet per second, or altitude. The first thing to be aware of is the 'full scale span' of your ADC. This can be just about anything, but for use on the flight computer, we would like it to be in the range of 5v. Look in the datasheet! For some devices I have worked with, these are: ADC1034 - 5v
This span. when divided by the numeric range will give the 'ADU', i.e., the value of the 'analog-digital unit' in volts. So, for the above devices: ADC1034, 10bit ADC. 5v / 1024 = 4.88mV = 1 ADU
The next thing to look at is the datasheet for the sensor. It will also have a 'full scale span', which is the range of voltage it will put out, as well as an offset. The offset is the lowest voltage it puts out, and corresponds to the bottom of its measurement range. The datasheet will also state what voltage output corresponds to what more conventional units the data can be read in, as well as the measurement range of the device. Again, for some devices that I have on hand, here is the relevant data: Sensor Full Scale Span Offset Units Measurement range
As you can see, none of the sensors exactly fits the ADC range. That means that we will be 'wasting' some bits. They are close enough though. Also, these are nominal values! Don't trust them! They will be close to correct, but you shouldn't make assumptions like: "Gee, based on this, 0g should be 2.5v, which on my ADC1034 would read as 512. I'll use that as a base value". Just don't do it. You do need base values, but do them as measurements. Hold the board sideways for 0g, or read it on the pad for 1g. It will give much more accurate results. We now have all the information we need except for conversion from the conventional units given in the datasheet to the conventional units we want. Below, there is a table of conversion values for different units or pressure. For acceleration, 1G = 32.2 ft/sec/sec = 9 m/sec/sec. To convert from an acceleration reading to ft/sec/sec, this is what we do: As = Acceleration sensor reading
Altitude is similar, though taking a base reading on the pad is even more important, because barometric pressure is affected by weather as well as altitude. Unlike with acceleration though, we need to calculate altitude based on measured pressure, then subtract base altitude to get the altitude difference from pad to rocket. So, to get altitude in feet: Pkp = Pressure in KPa.
Not so hard at all! Now, the altitude code I actually use in my logging software doesn't actually do all this. Instead, I've used the above equation to generate a table of altitudes for 64 equally spaced ADC readouts, as well as some interpolation coefficients. So to calculate altitude, I just do a table lookup, and some simple interpolation. Another shortcut I make is to treat the 10bit data from the 1034 as 12bit data. Notice that the ADU is .00488, which is exactly 4 * .00122, the ADU for a 5v, 12bit device. As the reading is 0 filled, it will look like a 12bit ADC that always seems to change in units of 4ADU. 12 bits is also easier to manipulate. If anyone sends me an appropriate EPROM + return postage, I will be happy to burn in Pauls' current monitor version with my latest data logger version. Be sure to specify what size NVRAM, and what type ADC you are using. Send to: Larry Lynch-Freshner
Coming:
Table 1. Pressure Unit Conversion Constants(Most Commonly Used - Per International Conventions)
NOTES: 1. PSI - pounds per square inch; 2. at 39°F; 3. at 32°F; 4. at 4°C; 5. at 0°C
|
| [Home] |