I've posted before that I'm a bit of a minimalist when it comes to flight computers...

Well, partly to show that I'm open to different views.

Partly to give y'all an insight into another aspect of rocketry in Australia

But mostly in the spirit of "My flight computer is better than your flight computer"

Here's the second version of a flight computer for a team of students at UNISA.
Last year's flew on a Sighter to about 16K'


The ultimate aim is to use it to stage two Zuni's to allow scramjet research without needing to go cap in hand to NASA for motors..



Features:
Magnetometer for apogee detection.
Barometric pressure.
GPS
Telemetry downlink
DTMF telecommand uplink
Three pyro chanells,
3 Analog inputs
3 digital inputs
2MB ram for onboard logging of everything.

PK

What transceiver are you using for the telecommand link ?

How much gain are you running on the amp for the baro sensor ? They look like the ones I sent you once yes ?

CS

Something like this http://cgi.ebay.com.au/5W-UHF-CB-OMDI-T ... 2eab52fcd3

26.978

I think so. They're MPXM2102's, I went on to buy quite a lot of them that I'll now probably never use. The Bosch digital ones look great so far..


PK

Happy to take the transducers of you.

That gain seems low, I'm running at about 280V/V or so.

Lemme get the digital ones in the air a few times first.

As you know I haven't been doing this for very long and resistor codes are new to me

How does 224.78 V/V sound....

PK

Got the firmware reasonably well sorted now.

This chart shows the apogee baro detection working using artificially generated vacuum ie sucking on a tube

http://picasaweb.google.com/lh/photo/Elpmzz0jv6H4eaQCVGyqug?authkey=Gv1sRgCPy34NLE_K3wqgE&feat=directlink

After a lot of stuffing around/debugging, I'm resonably happy with the result.

Also have got the launch detection and pre launch logging to a ram buffer so that data prior to liftoff is not lost. This data stays in RAM intill the flight is over then it is committed to the bottom page of flash memory below the rest of the flight data.

http://picasaweb.google.com/lh/photo/ZDuXa63mt-bIVlNxNlPhCA?authkey=Gv1sRgCPy34NLE_K3wqgE&feat=directlink

100Hz execution is no problem and with some fat taken out 200Hz will be possible.

Hope to fly these a number of times this weekend on a few different types of vehicles.

CS

So just the data immediately prior to liftoff is stored in RAM and added to the memory later? I guess this means if you lose power in flight you'll lose that data (but then also a lot of other bad things happen if you're using it for deployment, so you'd want to minimise the chance of that anyway). How much pre-liftoff time is buffered?

At the moment it is only the 20 scans at 100Hz ie 0.2s. However, all parameters are logged during this time, hence a longer buffer with a lower accel threshold at a higher scan rate could be implemented with just logging acceleration.

CS

It turns out that almost all of the time being consumed each scan in some states was due to debug serial messages.

I've made it optional for these to be sent now (ie debug mode) and when turned off the unit can safely run at 500hz whilst logging everything. The sample rate is cut back after apogee to 50Hz or so.

Since the sensors (accel and baro) don't have that sort of bandwidth and this is probably overkill for most uses, the sample rate during boost phase is set to 250Hz ie 4ms sample time.






Note that the filtering on the apogee detection is very short in this example and will be set to a time constant of approx 0.5 to 1sec instead of the 0.2 or so shown.

AirCommand, this should give you much better resolution on the acceleration data to compare with the simulation models. It is likely high enough to see the instabilities in most hybrid motors except the very small.

Looks like some good barometric data is happening. 250Hz sample rate also sounds great. Will you be using it for deployment on your flights this time around or are you still collecting flight data?

Will run it again this weekend as a passenger/payload and make sure that the apogee and main deployment detection works properly before running in dual deployment mode.

CS

I've got the 'known' bugs out of the firmware now but unfortunately due to a miserably flu virus I couldn't make it to the NSWRA launch this Sat just passed.

However, I was well enough on the Sunday for us to go on a drive up to Wentworth Falls, so I put one of the units into 'logger' mode with a sample time of 5s and put it in the car for the whole trip.

It is important to note that the altitude had been 'zeroed' previously at home (Blaxlands Ridge, alt 135m) and hence due to subtle pressure changes/fluctuations
home started out at 117ft.



We drove to near Wentworth falls (closer to Leura at about 2330ft) and stayed for about 1.5hours. It seems during this time in the car, either the barometric pressure increased about 20mbar (unlikely ?) or the significant increase in temp in the car (could be > 25deg) caused about 50ft of drift.
We then drove continuously west on the GWHwy to Mt Victoria (3008ft) and then accross to Bell (2995ft) and home along the Bells Line.

When we arrived at home the reading had 'changed' to 279ft from initial reading of 117ft. A 162ft change is equivalent to a 0.6kpa or 60mBar pressure change, this is also unlikley. However, since the unit was on the floor with the aircon on, it is likely that this reading change is due to a significant temperature drop. The datasheet for the MPX2102 indicates a 4% of full scale change for a 0 to 80deg range. This means a 1degC change will give a 0.05%fs or approx 0.05kPa reading change. This means that 12degC would account for the 0.6kPa/162ft difference between the start and end reading differences.

All in all it was an interesting test and shows that the lookup table and calibration constants aren't far off, assuming the zeroing is done properly

Managed 2 more flights at Doonside NSWRA launch today. Weather was pretty lousy with reasonably strong wind.

Flight computer was along for the ride again with deployment being done by motor pyro delay mechanism. Data was logged at 250Hz during the boost phase ie launch -> apogee.

http://picasaweb.google.com/cstrudwicke/NSWRA1142010?authkey=Gv1sRgCLKq5cP0pcXo2QE&feat=directlink

A few things were not as I would hope. Firstly I forgot to set the main deployment altitude parameter and it defaulted to a maximum of 3000ft hence the main deployment occured immediately after the apogee pryo dwell.

Secondly, the altitude calculation is not working as I'd hoped ie the resolution is much coarser that it should be. I thought this was sorted out previously On the charts the 'altitude post' curve was generated from the raw baro data stored. As you can see this is better resolution that the altitude calcuated in realtime within the flight computer. There is obviously a significant issue with my lookup/interpolation routine....

Even with these two issues, I'm happy with the operation. Hopefully I'll have the electronics bay etc sorted out fully for next time and run actual dual deployment from it.

Well I finally resolved the issue of the 'coarse' altitude calculation result ie steppy looking altitude data.

Turns out the lookup and interpolation routine was working absolutely fine. I had arbitrarily chosen 1mBar resolution for my pressure variable ie it is an integer where smallest unit is 1mBar. unfortunately 1mBar is not low enough pressure resolution to take advantage of the high resolution ADC result, hence the "large" steps in altitude (30ft).
Of course this is plenty of resolution in reality but not what I knew my system was capable of.

So after changing to a pressure resolution of 0.1mBar, the altitude resolution has become 2ft and hence the velocity derived from baro based altitude is a lot nicer.

The data in 'test' charts below are generated by me sucking on a tube pushed onto the pressure transducer. Of course the extremely rapid changes in altitude are not likley in any of the vehicles we are flying...







The velocity term has an adjustable filter time which had been set quite long for the purposes of these tests.

Here are a few charts from the flights at Doonside on 24-4-2010. Note these were done before the resolution improvement (should be obvious).

http://picasaweb.google.com/cstrudwicke/NSWRA2442010?authkey=Gv1sRgCMOai7iAwvfQNg&feat=directlink

That's great news you found the issue. The data looks a lot nicer. Is it possible to download the new firmware in the field? It would be good to update the one we'll place on the big fiberglass rocket. I can make sure any programming connectors are accessible.

In the plots from this weekend there seems to be quite a significant 0-offset for the altitude. Is this something you will correct in the firmware, or something that is done as a post processing step? We'll be flying your computer along side the Z-log altimeter we use so it will be interesting to compare the measurements.