Of friend of mine and I have an ambitious rocket telemetry/flight computer in the works. But it's been slow going
and I'm to the point now where I need a system working. About a month ago I pulled one of my Basic Stamp 2's out
and started thinking. With every new idea I ran into road blocks with the BS2, it just wasn't powerful enough.
So I searched the net for a similar product, only more powerful. I found the Basic Atom from Basic Micro. For starters, I ordered an Ultimate OEM Module - Atom
Version from Beginner
Electronics. The nice thing about the OEM module is that I can plug it right into
my bread board and it has a DB-9 connector for RS 232 comms built on the board.
The Basic Atom is very similar in form and programming to the BS2, but it is faster, has a lot more RAM, has built in ADC's and will do 32 bit math. I wanted the MCU to be able to calculate altitude, the BS2 math is limited to 16 bits, or an integer no larger than 65,535. While the Basic Atom will do floating point math as well as integer math to over 2 billion.
Here's a list of functions I wanted the unit to perform:
I may add an accelerometer as well. But I've been leaning towards barometric sensors as my primary means of determining apogee. Most commercial altimeters are limited to about 42,000' peak altitude simply because the sensors available are limited to a minimum pressure of 15 kPa. Of course the resolution gets worse the higher you go. Atmospheric pressure is not linear. The drop in pressure gets less and less per foot the higher you go.
I found a new pressure sensor from Honeywell that reads absolute pressure from 0 to 15 psia,
and outputs an amplified signal, the
ASDX series. Here's a link to the part from Digi Key.
There are a couple of problems I can see with high altitude deployment. First, with resolution on any sensor being poor at high altitudes, the rocket velocity is likely to be high at deployment. Couple the probable high deployment speed with the thin atmosphere which won't slow down the deployed nose very quickly, you're setting yourself up for a nasty, high shock event. The safest way I can think of to deploy will be to use separate chutes on both the nose cone and the rocket body. That really allows you to shoot the nose cone off the rocket and not have to worry about it. So I believe a deployment event that is even significantly late, would be fine under these conditions. Think of it more as a re-entry than an apogee event...
The Basic Atom on chip ADC's are 10 bit, that concerned me a little with regard to the pressure sensor. I looked at the data sheet on the sensor, it has a quantization step of 3 mV. So 3 mV is the smallest change in voltage from a pressure change that can occur. Divide the 3 mV by the 4 volts span, and you have 1,333 possible values full scale. A 10 bit ADC has 1024 possible counts full scale. So going with a higher resolution ADC won't gain you much. That said, I did try my MCP3201 12 bit ADC on the Basic Atom. For whatever reason, I can't seem to code it to get the proper ADC values returned. It's consistent, but wrong. The Basic Atom supports I2C comms, so I ordered a 16 bit I2C ADC to play with as well. I also ordered a couple of HC 4051 8 channel ADC multi plexers, just in case I want to use more than the 4 ADC channels the Basic Atom offers.
I'm using a formula to calculate altitude, and an IF/Then statement to use the formula relevant to the altitude range that's being sampled. For lower altitudes I'm linearizing the data every 1,000'. For higher altitudes the data is linearized every 5,000'. That should give me good accuracy at lower altitudes, and fair accuracy at higher altitudes. This is simply data that is sent to the ground via radio, and logged on the ground PC. For accurate apogee determination I'll save the peak altitude data in raw kPa format, where later I can accurately translate that number to altitude. I'll get into the code for altitude later.
Now to some of the other data sources. To gather battery voltage data, I need to input a voltage into the Atom of between 0 and 5 volts on an ADC channel. Of course my voltage will be greater than 5 volts, likely I'll use a large 10 to 12 volt battery pack. So I need a voltage divider. You can make a simple voltage divider with 2 resistors. I wanted to read voltage between 0 and about 15 volts, so I chose a 5k ohm and a 9.8k ohm resistor. The formula to calculate Volts out is: Vout= R2/ (R1 + R2) * Vin Using my resistors that gives me an output voltage of 5.07 Volts at an input Voltage of 15 volts.
Here's the code snippet:
adin AX3, 0, AD_RON, Voltsadc
voltsex = Voltsadc * 100
voltsx = voltsex * 151
volts = voltsx / 10240
Notice I'm using integer math, and I simply increased the resolution by multiplying the ADC count value by 100. I left the 100X in the output, that give me an integer number that needs the decimal moved left two places. For example, a voltage output of 1241 would be 12.41 volts, 853 would be 8.53 volts.
Schematic of the very simple voltage divider.
The pressure sensors for N2O pressure and chamber pressure are very simple to implement. The transducers I'm using output an analog 0 to 5 volt signal, which feeds directly into an ADC input pin on the Basic Atom.
Here's the code for the transducer input:
adin AX2, 0, AD_RON, N2Oadc
N2Opsix = N2Oadc * 976
N2Opsi = N2Opsix / 1000
Again, integer math used to keep the resolution up.
For the nose cone deployment sensor, that's just a simple break wire on the nose cone. I'll tap 5 volts off the
Basic Atom regulator and feed it to a digital input pin on the Basic Atom, I'm using a 10k resistor to keep the
pin pulled low after the break wire is broken.
Here's the code:
IF (IN3 = 1) THEN
apogeesensor = "N"
elseif (IN3 = 0)
apogeesensor = "Y"
endif
This very simple code stores the letter "N" or "Y" in the variable apogeesensor. Later the variable is transmitted and is read as "Apogee Y" (yes) or "Apogee N" (no). I could have stored a string variable with the full word yes and no in it, but it just wasn't needed. The simple Y and N do the trick.
Here's the code I'm using to input commands:
serin P8, i9600, 740, Out, [Dec X]
If X = 1 then
high 1 : pause 1000 : low 1 : goto Out
elseif X = 2
high 2 : pause 1000 : low 2 : goto Out
endif
Using the serin command and pin 8 as input on the Basic Atom. The 740 is a time value to wait for data to be input, that's 740 milli seconds or .74 seconds. I'm using this input delay to time the transmit frequency to 1 transmit per second. I could go much faster, and I may change the timing down the road. Right now I'm only using this code to accept two commands, send a "1" and pin 1 goes high, which will be apogee deployment, send a "2" and pin 2 goes high, which terminates thrust. This is where the format I'm using gets a little clunky. I have written code in visual basic to send these commands through a GUI by clicking on a button. The problem I'm having with visual basic is the time required to learn all the features of comm port communication and logging of that data. So I decided to take the easy way out and use a third party software on the PC end of things. I found some free software called CommSniffer from KnightSoft.net. It really does everything I need it to expect one thing, it doesn't time stamp the logged data. I found another possible good program that does about the same thing and it time stamps the data. It's $60 and called Advanced Serial Port Monitor from AGG Software. It works fine, but I'm not sure how important the time stamp is. I suppose it would be handy to have the time stamp, the time increments down to the thousandth of a second so it would be useful in calculating some aspects of the flight.
Here's the code used to send the data from the Basic Atom to the application:
Out
serout p9,i9600, [" Altitude ", dec altitude, "' ", " Pc ", dec Pcpsi, " N2O
Psi ", dec n2opsi, " Volts ", dec volts, " Apogee ", apogeesensor, " ",13]
goto main
One rather odd thing I found was that the built in serial in and out pins don't work with the MaxStream radios.
When the Basic Atom is connected to a serial cable to the PC, the data flows into the application just fine. So
I used pins P8 and P9 for serial communication through a Spark Fun shifter board and the radio's worked fine. When
I go to build this all on a PCB, I may just use a Basic Atom interpreter chip and a Max 232 serial convertor. I'd
be able to install the interpreter chip in my OEM board for programming, then move the chip to a socket on the
telemetry board and only need communication then between the Basic Atom and the application.
Here's an image of a prototype schematic using the Basic Atom OEM board.
I've got most of the parts ordered to make a board using just the interpreter chip, which will save a lot of room on the PCB, but I decided to do a quick homemade PCB using the OEM module so I'd have something I could test a little easier. I'm not comfortable flying a bread board, so this quick early board is intended to be test flown. I don't have my new pressure sensor yet, so I really hope I made the PCB pattern with the proper pin layout... The transducer came in today, alas my PCB wasn't the proper layout. But I managed to make it work with a little careful copper removal and soldering.
One problem I ran into after installing the transducer on the board was that it uses a slightly different voltage span than the MPX 5100 I had been using in the past. That means the formula for calculating pressure is off. I think I got the conversion pegged, but I'm not sure. I think I'll test this altimeter against another altimeter and see how close they are. I'll probably end up buying a good quality vacuum gauge to get some definitive measurements done. So again, I'll wait with posting any altimeter code until it's tested and known to be good.
Another little problem I had was the ADC resolution was very low. The smallest change in an ADC value was nearly 30, that's not good resolution at all. So I changed the code in the ADC_in line to set the speed to (3) which means the ADC speed is set by the internal resonator. That solved the problem, and I switched all the ADC_in code lines to the 3 speed.
After installing the pressure sensor, I bundled up the transmitter and MTS (Mini Telemetry System) board and did a run in my vacuum chamber.
Here's a screen cap of a portion of the data I recorded on the ground PC.
This screen cap shows the peak altitude reported at 59,632' and the altitude dropping as I started slowly releasing the pressure. This software doesn't show the time stamp, but I increased the speed of sampling to about 5 per second. The peak altitude would correspond to about 7.2 kPa or 1.044 psia. That's pretty close to what I was expecting going by what my cheap vacuum gauge was reading.
Here's a link to a text file saved from the test. If you look at the data, close to ground level the resolution is around 30', up close to 60,000' the resolution drops to around 90'. That's exactly what I was expecting to see. You can also see the system battery voltage drop from 7.94 to 7.91 volts during the test. I was using an old 9 volt battery to power the MTS board, in a real flight the system will be powered from a larger battery pack. The Pc and N2O channels were not connected, so the data on those lines just indicates the floating voltage of the Basic Atom pin.
I've flown the MTS four times in a series of deployment tests for the Ganymede rocket. While these were very, very low altitude tests, it did give me a chance to test the system under actual flight conditions. The system also held up under one failed deployment and one landing under just the drogue. So it seems the system is rather robust and should handle a nominal flight very well. My next step is a check of the calibration of the altitude reporting. Below is a series of tests I performed in my vacuum chamber using a Missile Works altimeter as the bench mark.
| Test Number | Time Under Pump | Missile Works | MTS | MTS AGL | Variation |
| AT1 | 7 | ||||
| AT2 | 10 | 11,110' | 11,911' | 10,863' | -247 |
| AT3 | 15 | 13,555' | 14,227' | 13,179 | -376 |
| AT4 | 20 | 17,857' | 19,757' | 17,709' | +852 |
| AT5 | 25 | 19,995' | 21,967' | 20,919' | +924 |
| AT6 | 35 | 22,319' | 25,307' | 24,259' | +1,940 |
| AT7 | 45 | 24,869' | 30,756' | 29,708' | +4,839 |
| AT8 | 55 | 25,706' | 31,420' | 30,372' | +4,666 |
As you can see from the table, the MTS was pretty close to the RRC2x up to around 15,000', then they really differed. I think what I'm going to have to do, is to buy an accurate vacuum gauge and record the ADC values at known pressures. I can use those values in a look up table to correlate pressure to altitude. That should give me a much more accurate reading than the formula I'm using now. It will take a good deal of time to implement, but once it's done I'll have the data and table I can implement in later units.
I've been trying to locate a high quality vacuum gauge for a couple of weeks now. I'm not having any luck unless I wanted to spend nearly $1,000. So in lieu of the proper equipment, I decided to wing it and calibrate my barometric sensor to my Missile Works altimeter. So I ran a series of vacuum chamber runs with my MTS sending the ADC values with the RRC2x along side it in the chamber. Since I can record the data from the MTS, all I had to do was check the peak altitude from the MTS file on the PC, and correlate it to the peak altitude the RRC2x reported. After over 40 runs, I decided I had enough data points.
After I had all the data points, I had to figure out how to apply those to a formula and linearize the output between the data points. What I did was to get the altitude difference between the ADC data points, then get the number of ADC values between those data points. Divide the ADC values by the altitude and you get ADC values per foot of altitude. In the code I use an If/Then/ElseIf statement to determine which formula to use, for example. If the current ADC value is 721 it goes to this line of code and executes it:
elseif (baroadc >= 717) and (baroadc <=726)
altitude = 6784+((((726-baroadc)* 1000000))/16071)
The first line of code ask if a value is between 717 and 726, if it is, it executes the next line of code. That next line of code is what calculates the altitude. The 6784 is the starting altitude for the ADC range of 717 to 726, and is added to the rest of formula which is used to determine how much higher we are than the 6,784' the code started with. We take the low end altitude ADC value and subtract the current ADC value. That tells us how many ADC bits we are above the starting point of 726. If our current ADC value is say, 720, we are 6 ADC values higher than 6,784'. Now I multiply by 1 million, that's simply a way to use integer math to keep the end result within 1 foot. Now divide that number by the decimal (which was multiplied by 1 million to bring it back to even feet), that gives you the increase in altitude you are over the starting point of 6.784'. Now it goes back and adds on the starting altitude and you've got your current altitude for the current ADC value.
This is the approach I was going to take with a good vacuum gauge. And I still plan to acquire a good gauge in the future. This isn't the most accurate way of doing things. I'm relying on the RRC2x for data points, and it's not perfect either. So there is going to be more variation and loss of accuracy. While not quick and easy, it was a cheap was to do it, and will give me very good "ball park" numbers.
Here's a few tests I did after running the new code in the MTS.
| RRC2x Altitude | MTS Altitude | Variation from RRC2x |
| 5,922' | 5,944' | +22 |
| 6,202' | 5,944' | -258 |
| 11,110' | 11,026' | -84 |
| 14,104' | 14,388' | +284 |
| 21,124 | 21,257' | +133 |
| 34,303' | 35,068' | +765 |
Not bad all things considered. I've seen commercial altimeters farther apart than that. I'll have to do more data points in the future, but I'm pretty much spent after a day of running all these tests.
I've been working on a new MTS system based on just the Basic Atom 28B interpreter chip, that is, not using the OEM board but just integrating the PIC16F873 on to my own PCB. Not only does that save a lot of room in the electronics bay, but it's cheaper to implement. I really debated just using a bare PIC16F873 and getting set up to program the PIC's myself. The problem with that is I'll need to buy and learn to use new software, then buy a programmer and software as well. That might be fine if I was going to sell a lot of something. But the 28B interpreter chip is only about $10 more than a bare PIC 16F783, and I really do think programming with the Basic Atom software is pretty easy, well worth the extra cost of the interpreter chip. And, the software from Basic Micro is free, and I'm familiar with it.
One problem I had with my first board design was that I laid out the circuit based on the 28A chip. Only after I had made the PCB and had it running (with some odd problems) did I discover the pin outs were changed on the new 28B chip I was using. Fortunately the changes weren't great and I was able to rewire the board I had made. But I had another problem, the unit was running intermittently. It ran fine for a while, then would shut down. I could move the board around, or wave my hand over it and it would start up again. So I posted a question on the Basic Micro forums, and quickly received a reply that I needed a 10k pull up resistor on my reset pin. Once the resistor was in place, the unit ran rock solid.
This new design has a couple of extra features I really wanted to implement on the flight unit. I added circuits for testing the continuity on both upload pyro channels. It also has more logical terminal output locations, and I added the traces to hook up daughter boards and extra terminal block pads for future upgrades. I'm seriously considering adding an accelerometer to this unit. Not that I need it, but it would be nice to be able to generate a thrust profile. As it stands now, I'm not going to use the MTS for stand alone deployment. The only deployment from the MTS will be the upload commands. This winter I plan on starting a new flight computer based on the Basic Atom 28B MCU. This will be a more conventional, stand alone flight computer.
I've been looking at the data sheet on the baro sensor I'm using. I see they offer the unit in three pressure ranges; 0 to 15 psia, 0 to 5 psia and 0 to 1 psia. I'm using the 0 to 15 psia unit now. But, the lower range units offer better resolution at lower pressures. I think it would be fairly easy to code a program to switch between sensors during flight. That would give me much better altitude resolution from ground level all the way to vacuum. That can wait for now though, but might be another fun project for the long, cold winter months.
Here's a diagram of the board. The light blue lines are jumper wires on the component side of the board. Those 3 jumper wires eliminated the need for a two layer PCB.
Parts List:
R1, R2: 100 Kohms
R3: 1 megohms
R4, R7: 3 Kohms
R5, R6, R8, R9, R10, R12: 10 Kohms
R11: 5.1 Kohms
C1: .1 uF
C2, C3: 10 uF electrolytic
U1: ASDX 15A24R Honeywell Pressure Sensor
U2: Basic Atom 28B (PIC16F873)
U3, U4: IRF 510 Transistor
U5: L7805CV Regulated Power Supply
Y1: 20 mHz Oscillator
Notes: The IRF510 transistors go in opposite directions. With the Atom pin 1 at the top. The left transistor has the metal back towards you, the right transistor has the metal back away from you. The two 10 uF capacitors are polarity sensitive, make sure the labeled negative lead is on the ground side of the power supply. The oscillator (Y1) and the rest of the components are not polarity sensitive and can go either leg in either hole.