Controller build

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

max_crack

Member
Joined
Jan 4, 2016
Messages
19
Reaction score
0
Hello,
I though I would share my current project. There are plenty of altimeters and what not and it would be cheaper and easier just to buy one already done. But I like doing layouts while i'm stuck on conference calls.

So far I got a AVR Atmega MCU, SPI barometer, and flash for storage. I have an aux SPI port that I can read other sensors with. Looking at 6 or 9 DOF SPI/I2C accelerators / gyroscopes, they tend to have very poor bandwidths but it something to experiment with.

The build in ADC is also tied out to a header so I could also use analog sensors if I wanted to get into serous $.

Power is simple, only tricks here is a big storage cap and blocking diode. If the power browns out while firing an ignitor hopefully the it keeps the micro up and running. On the firmware side if write the code to be a bit statefull is should be able to recognize if the power did brown out and do some thing about it.

The ignitor outputs are pretty basic Just a fet to ground. Just typing this out though I think I could support using higher voltages if i protect the MCU's continuity tester inputs... Hmmmmmmm....

altimiter_pcb.pngaltimiter.jpg
 
My phone doesn't pull up the detail well enough, what size cap are you using for brown out protection? I was lucky enough to score a decent account of 5V 1F super capacitors that do the trick real nice for my setup and I'm curious
 
Last edited:
Hello
Its a 10mm squarish. It should fit up to a 2200 uf with out modifications. I was really lazy and just picked the biggest SMT footprint in work's parts data base. I had been "working" on this one for a while. I bought the sensors in July ~ish. I know i'm going to want a second version. I didn't get it done for my first high power launch last weekend. After that I definitely want a gps with the thing. when I get the boards back i will just scope the power rails and use some low value resistors to see what it looks like. I don't think this board will ever really get used for anything other than a data logger.

Edit> I have some 5V 1F caps now that i think of it, though they were quite old by now and even new they had pretty bad ESR. They were pretty much only good for a RTC batt back up.

This is about the 3 or 4 time I have come back to rocketry. This is the fist time messing with the high power stuff and having a job to pay for stuff.

I'm starting to dig into the firmware, writing the drivers for the barometer.
 
Last edited:
Besides GPS, adding in a wireless transceiver and 9DOF IMU is fun also, it's good to be able to get flight data after the launch, but real time streaming data is always really cool.

I have mine coming in and I recreate the NMEA stream and feed it into Google Earth for real-time tracking.

My 5V 1F caps will run everything for about 10 seconds before browning out. Aerogel super caps. I'm using them in my pyro channels too (to avoid possible brown outs, and to add safety by not charging the pyro caps until on the pad) because the current needs of my ematches makes it doable.

Like most things in rocketry, doing it yourself is always more fulfilling for me (rockets, parachutes, electronics, etc)
 
Last edited:
So you suing the caps in the pyro channels? Do you know which caps? What is you primary battery?
 
These are the caps: https://www.mouser.com/Search/m_Pro...GAEpiMZZMuDCPMZUZ%2bYl4aIGdoxlGZcmHuYc/u76lk=

Primary battery pack is lipo, regulated down to 5VDC.

I charge the caps via a switched transistor from the battery through a diode and current limiting resistor, once charged the FETs (again controlled by the uC) discharge the caps through the ematch.

So the battery it's never never on any strain, you could use whatever battery you want pretty much. The microcontroller also has a 1F cap on the main dc bus to avoid brownout issues.

The mouser source is way more expensive than weekday i got mine for, but that was 5 years ago when I ordered 50 or so.


//edit
Didn't want to hijack the thread..... Any who, I look forward to seeing it soldered up :)
 
Last edited:
These are the caps: https://www.mouser.com/Search/m_Pro...GAEpiMZZMuDCPMZUZ%2bYl4aIGdoxlGZcmHuYc/u76lk=

Primary battery pack is lipo, regulated down to 5VDC.

I charge the caps via a switched transistor from the battery through a diode and current limiting resistor, once charged the FETs (again controlled by the uC) discharge the caps through the ematch.

So the battery it's never never on any strain, you could use whatever battery you want pretty much. The microcontroller also has a 1F cap on the main dc bus to avoid brownout issues.

The mouser source is way more expensive than weekday i got mine for, but that was 5 years ago when I ordered 50 or so.


//edit
Didn't want to hijack the thread..... Any who, I look forward to seeing it soldered up :)
Those super caps store 5 Joules and will source a minimum of 10 amps into a short. Compare to the older hobby rocketry CD altimeters, the super caps have a much higher capacity than the old MAWD conventional capacitors which stored 0.19 Joules.... You could easily use 0.1 Farad super caps which would still be 0.5 Joules and will fire a standard e-match which should require not more than 0.05 J to activate and have a factor of 10 reserve....

FWIW, 2 supercaps weigh 4 grams each, in total as much as a 2S LiPo battery https://www.hobbyking.com/hobbyking/store/__10915__turnigy_138mah_2s_10c.html that doesn't need super caps. The 1 F super caps are not compact either, so if you still want to use them, (2) 0.1 Farad super caps which together would weigh less than 1 gram.

Bob
 
Bob, all great info.

The reasons for me picking capacitors (vs battery) are as follows:
1) Seperate uC power from ignition power (brown out protection)
2) Extra safety by not charging the caps until the flight computer is armed with a pass phrase (over wireless connection)
3) I had these caps on hand
4) They're strong enough for my homemade igniters if I were brave enough to use them vs purchased igniters in an actual rocket.

I wasn't too concerned about 8g weight as this is being launched in a payload project (several pounds of gear getting lofted) but if I were to go as small and light as possible I'd redesign (or probably just use my quark)

Also, I just weighed a cap with clipped leads, 3.1g, not that it matters, but just for reference. The amount of zip ties, solder, over building, battery clips, cameras and threaded rod in most AV bays makes this nearly negligible (in HPR payload rockets)

It all depends on your design goals I suppose.
 
Last edited:
PCBs are in the mail....

b89.gif
 
PCB are in, I have soled what components I had on hand and the boards are up. The micro controller is up and running form its own internal oscillator.

Some how I made a botch in ordering the micros, apparently atmega 328p and atmega 328pb are two different chips though a quick squiz at the data sheet, I could not see what the difference was.

I have not mounted the sensor yet. They are sensitive to contamination and should not be washed. The plan is to fet the last bits i need and after everything is working wash the PCB and tack it on as the very last thing.

Also made progress on the nose cone ebay for my 4" cowabunga. I have to make the sled and epoxy the mounting ring in. Thinking about the mechanical part of the build, I'm not sure where the best place is to drill sensing holes. no mater what I see some kind of less than ideal airflow or expoture to ejection gasses. Oh well, will have to build another rocket.
IMG_3781.JPG
 
Rest of the parts are on the way..

Looking at the firmware side of things. I have a program to wake up the barometer and spit out its calibration data and stream temperature / pressure data. I'm interested to see how noise the sensor is. Depending on the over sampling setting, the MS5607 has a sample rate of 110 Hz to 1.6KHz. It has two channels, temperature and pressure. Until I get some data on how useful the temperature is i will just plan to record it as well.

The flash chip is organized in 256 byte pages, that is one write command can take 1 to 256 bytes. Data has to be written to a blank page so you can't over write a individual byte like you can with EEPROM. Current chip is a 8 Meg bit flash or just under 4100 pages, what ever aligns to a base two address.

if each sample eats 8 bytes, 32 sample per page, 580 to 40 ms per page depending on sample rate. The Flash will hold form 40 minuets to 150 seconds worth of data. I'm interested in see what launch looks like . Rather than trying to detect launch event. I'm planning to do the DSO / logic analyzer trick; once set to record, the device is recording full tilt, treating the flash as a circular buffer until an event is detected where it will record for X cycle and stop.

In order for that to work at the higher data rates, that means I have to erase pages in advance. The flash can also be erased in 4, 32 and 64kb blocks. 4Kb erase takes 70ms during that time the Flash chip is busy so sensor data has to be buffered. At the fasted conversion time of 600us, the processor will have to buffer 117 samples or 468 bytes. so If I set my ring buffer to two pages, 512 bytes erasing blocks on the fly should work.
 
Ok, barometer up and running, next to bring up is flash. I also picked up a 9 DOF sensor from sparkfun, If I have time before the next launch.
 
Hello,
So I got the MS5607 sensor up and running and have collected data overnight. I have run it through some software that is used to look at clock stability. This will sort of show how stable the sensor is. I say sort of because the measurement conditions are not very controlled but it will work for what I'm interested in. Also the titles of the graphs will not really be descriptive of what is show but I will explain in the text.

First the raw data, The X axis is time, the Y should be pressure in pressure. so 1.03k is 1030.00 mbar. This is recording the natural variation of pressure in the lab. Now the line is quite thick. This is caused by some high frequency noise and limited resolution (relative to noise) of the sensor.
9ArDRHK.png



For the first metric I want to look would be Maximum Pressure Interval Error. (not really a thing, see note at end) That is to say for a given interval, what would be the maximum error given a fixed pressure. So if you had a sensor in a jar what is the peek error if you look for 10 second? how much more error will you see if you look over 100 or 1k second. The results for this specific data is not terribly useful because the sensor was not at a constant pressure. So the best I can do is restrict the data to a relatively flat section of the data.

data selected :

KZunxdw.png


What I am calling MPIE: X axis is observation window, Y is peek difference in pressure. Over the data set, If our controller holds onto data for 100 seconds the peek delta would be 160 mili mili bar or micro bar.

rRPx6Nl.png


So not all noise types can be removed from a signal, It the noise is characteristic of "white noise" we can average it out, If the noise is more like random walk, averaging dose nor reduce the power of the noise. Now with these calculations, the uncontrolled environment dose not really affect what I am looking for.

Taking a, well I guess PDEV since we are dealing with pressure. What is interesting here is the graph starts with a negative slope, then the is an inflection point and the graph starts to rise again. The left had side of the graph should be dominated by noise inherit to the sensor. Noise shown on the right side of the graph will be caused by the testing environment ( in this case). The inflection point shows that if we average over a window of just over 100 second we will get the best accuracy for the sensor.

Now the flight of a rocket is a dynamic event to say the least. but what this tells us is while the rocket is sitting on the pad, if you wanted to get the most accurate start pressure there is no benefit to holding onto data that is older than, say 150 seconds.

Mkt0XWo.png


Now to prove the point that:
1. The left had side of the graph should be dominated by noise inherit to the sensor.
2. Infection point is not affected by experimental setup.

This is the PDEV for the entire data set not just our cherry picked flat section. The resulting graph is the same out to 500 seconds which is well beyond anything of interest.
Fg5CV40.png


It will be interesting to repeat the test with the sensor running at an update rate that will be used in the altimeter. For that I will need to get a binary transfer working. As well as a suitable test chamber to get a reasonable MPIE.

*NOTE: MPIE and PDEV are not real metrics but a bastardization of TDEV and MTIE.
 
I'm somewhat confused on what you are attempting to do as the sensor performance is well documented in the data sheet so I would think you could duplicate the specs in a straightforward manner. https://www.meas-spec.com/product/pressure/MS5607-02BA03.aspx#

The conversion of real pressure to altitude is quite simple as the conversion values can be obtained from a standard atmosphere calculator such as https://www.aerospaceweb.org/design/scripts/atmosphere/ . At sea level and 15 C, the pressure is 1013.3 mbar, and at 10 M MSL and 15 C, the pressure is 1012.0 mbar so the inherent sensitivity of the physical measurement is -0.13 mbar per meter. The RMS resolution of the sensor is specified as 0.13 mbar or 1 Meter for an OSR = 256 and 0.024 mbar or 0.2 M for an OSR = 4096. (OSR = Oversampling Ratio) As this is a digital sensor, I assume you are using the internal DPS to do your measurements, as the noise on an individual sample can be fairly high, but not necessarily relevant if the noise is random as it is averaged out.

A temperature change of 1 C will result in a 3.5 mbar pressure change in a fixed volume which is equivalent to 27 meter change in altitude. This will not be an issue in an open system, however 24-bit measurements are extremely sensitive to temperature coefficients unless compensated for. I assume the internal DSP handles this but if you are using the raw data, then you have to do this in your analysis. The sensor is quite sensitive so drafts could influence the noise as well.

Bob
 
"I'm somewhat confused on what you are attempting to do..."

Don't worry about it to much, same reason a dog licks him self... I was trying to dig not into the accuracy but rather what makes up the measurement noise of the sensor and really just on a lark.

Right now I have a firmware that is strictly a peek reading. I hope to be able to get the ebay put together for a launch beginning of march...
 
Back
Top