Let's see your Arduino-based flight computers!

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
If it is a PVC cap you can use a section of tube the same size an just stuff it in there. My successful flight was with 0.4 grams of pyrodex fffg in a centrafuge vial packed with dogbarf. that was a enough for a BT60 body tube.
 
@Aeva --

Interesting experiments !

@JimJarvis50 wrote an article about high altitude ejection charges.

High Altitude Deployment Article

While you're not doing High Altitude Deployment, the T-shaped charge holder Jim invented might work for Pyrodex because of the specific physical config of the T-tubes ... maybe ???

And then again you might continue to sprinkle unburned Pyrodex throughout your recovery tube ...

HTH

-- kjh
 
Alright, I don't know if I will get to test it tonight, but I found some long aluminum tubing that 1/2" on the outside and about 3/8" inside. It's long so I need to cut it down, but will have plenty for other projects. I can probably make it work with that and not worry about heat at all.
 
Smokeless powders burn much more slowly, especially when not developing the kind of pressures seen in firearms. So they tend to not be as effective in developing the nice, quick rise in pressure in the comparatively very large volume of a rocket that fine-grained 4FG black powder does. Contained in a firearm's chamber and barrel, smokeless generally has quite a bit more energy released/mass, and can develop much higher pressures than black powder.
I've been using Triple Seven 3FG for years. It works just as good as BP (in fact, I tend to be on the "blow it up" side...) but YOU HAVE TO CONTAIN IT TIGHTLY for it to work properly. You can't just put it in the charge well and put one piece of tape over it. For charge wells, after putting in the Triple Seven and packing any space with dog barf, I put eight pieces of masking tape over the top, criss-crossing them, then a perimeter wrap to hold it on. Yes, it's more work than BP. And yes, your vehicle won't smell like burnt BP on the way home from the launch, and the residue (what little there is) wipes off easily.
 
Ok here are two tests. Both used one gram of pyrodex P fffg. The first one used a centrifuge vial packed tight with barf and the cap snapped. Nothing else. Also instead of a chute I packed the protector with a wad of paper towels and they were not attached to the nose cone attachment point.

As you can see in that one it did a lot like yours, just the nose cam out and the laundry stayed in.

In video two I used the same charge, attached a real chute correctly and wrapped the centrifuge vial in a layer of paper tape. I did one bit of taper closing the top and then another around the middle of the tube, on top of the first tape.

And here is a picture of the two vials at the end.
IMG_2101.jpeg
 

Attachments

  • IMG_8627.mov
    38.9 MB
  • IMG_8628.mov
    19.7 MB
I've been using Triple Seven 3FG for years. It works just as good as BP (in fact, I tend to be on the "blow it up" side...) but YOU HAVE TO CONTAIN IT TIGHTLY for it to work properly. You can't just put it in the charge well and put one piece of tape over it. For charge wells, after putting in the Triple Seven and packing any space with dog barf, I put eight pieces of masking tape over the top, criss-crossing them, then a perimeter wrap to hold it on. Yes, it's more work than BP. And yes, your vehicle won't smell like burnt BP on the way home from the launch, and the residue (what little there is) wipes off easily.
Really that little residue? My tube ended up a mess. Maybe I needed to wrap it more and use less powder.

(that is an eggtimer quark by the way)
 
Follow up on the 1/2" aluminum tube! I basically used jbweld to put a small bolt in it, and then replaced the PVC cap with it. I put in the ejection charge igniter first, measured out 0.8g (consistency), packed it as tight as I could, and taped it twice over with painter's tape. It worked spectacularly... not only did the parachute come out, but it had enough force to also obliterate my test frame rigging the legs, and the top of my avionics assembly. I MAY have forgotten to put in the screw to hold it to the test frame, but I think it's safe to say it was successful. I was detonating it via launch controller instead of through the computer, so I will have to double check that there wasn't damage to the electronics. Thanks for the advice!! Now to start over with a smaller charge lol

Check out the slow mo though!!

 

Attachments

  • IMG_5813.JPG
    IMG_5813.JPG
    3 MB · Views: 0
  • IMG_5814.JPG
    IMG_5814.JPG
    1.9 MB · Views: 1
Here are my versions. The first is a dual deploy altimeter with XIAO ARM Cortex M0 processor,
MPU-6050, MMA2202KEG 50G acccelormeter chip (switching to H3LIS333) and BMP280 and SD card. Flown many times in my rockets.
I modified Bryans Arduino code for my altimeters. I wrote my own R-studio programs to analyze flight data such
as roll, pitch, yaw, angle from vertical, velocity etc. and derive CD and motor thrust curve (similar to the old ARTS altimeter).
The second is two-stage/airstart and SAMD21 ARM Cortex M0 (same as XIAO but more pins) using tiltometer function
with maximum degrees of vertical, altitude and velocity thresholds. Flown twice airstarting motors. I will try in a two stage next.
A couple of years ago I started with the Nano ATmega328 processor but it had limited memory and speed. I still fly those also in my other rockets..

-John
 

Attachments

  • Altimu10.png
    Altimu10.png
    394.4 KB · Views: 0
  • Altimu10b.png
    Altimu10b.png
    394.6 KB · Views: 0
  • Altimu4.png
    Altimu4.png
    5 MB · Views: 0
  • Altimu4b.png
    Altimu4b.png
    5 MB · Views: 0
Attached are three of my DIY high speed flight computers that I have been flying for the past four years. The center and left systems are Arduino Pro mini systems recording 3-axis accelerometer data at 400 Hz interleaved with temperature, air pressure, and altitude at 16 Hz. The right system uses the Adafruit SAMD21 Adalogger recording 3-axis accelerometer data at 500 Hz interleaved with temperature, air pressure, and altitude at 20Hz.
 

Attachments

  • 20230813_140813.jpg
    20230813_140813.jpg
    2.5 MB · Views: 0
Wow @Aeva !

I hope your sled and Arduino gadget are OK.

Thanks for the images !

-- kjh
Amazingly, it survived! I think I'm gonna remove the electronics for now and just use my launch controller to trigger the charges for tests until I'm confident the charge won't destroy the sled lol.
 
IMG_20230904_075823_111.jpg

Current status of my Arduino Nano based altimeter. I'm working on building it out incrementally, so the current code uses a BMP180 for altitude measurement and then displays the maximum altitude on the OLED once it begins to descend.

I also have 4 pyro channels called out for use with the N-MOSFET breakout boards. I have 2 channels coded already, for apogee and secondary deployment, and the other two channels are just place holders for now.

I'm still waiting on proto boards to arrive to solder everything together for flight. Phase 1 testing will be the altimeter function, then the pyro channels, then integrating data logging. I have some sd card breakouts and flash chips to play with for that.

For Phase 2 I'm planning on adding the MPU-6050 into the mix.

At some point I plan to break away from the Arduino and start playing with the RP2040 chipset. I have a Pico and an Adafruit Feather with several Feather Wings. This one will be where I start to integrate GPS and radio features.
 
View attachment 601959

Current status of my Arduino Nano based altimeter. I'm working on building it out incrementally, so the current code uses a BMP180 for altitude measurement and then displays the maximum altitude on the OLED once it begins to descend.

I also have 4 pyro channels called out for use with the N-MOSFET breakout boards. I have 2 channels coded already, for apogee and secondary deployment, and the other two channels are just place holders for now.

I'm still waiting on proto boards to arrive to solder everything together for flight. Phase 1 testing will be the altimeter function, then the pyro channels, then integrating data logging. I have some sd card breakouts and flash chips to play with for that.

For Phase 2 I'm planning on adding the MPU-6050 into the mix.

At some point I plan to break away from the Arduino and start playing with the RP2040 chipset. I have a Pico and an Adafruit Feather with several Feather Wings. This one will be where I start to integrate GPS and radio features.
A good start. The display is nice to have during development, but most of us have our flight computers encased in our avionics bay that is out of sight. I found that tone sounds worked better at the launch site. Communication with your smartphone is the direction for the future.

The addition of the 6 channels from the MPU-6050 will slow down your Nano sampling speed. Transferring to the RP2040 will give you other options for increased sampling speed, which you will need for the long sentences of GPS.

There are a number of very knowledgeable DIY flight computer people here to help when needed.
 
A good start. The display is nice to have during development, but most of us have our flight computers encased in our avionics bay that is out of sight. I found that tone sounds worked better at the launch site. Communication with your smartphone is the direction for the future.

The addition of the 6 channels from the MPU-6050 will slow down your Nano sampling speed. Transferring to the RP2040 will give you other options for increased sampling speed, which you will need for the long sentences of GPS.

There are a number of very knowledgeable DIY flight computer people here to help when needed.
Thanks!
My general idea starting out was to make something like the little Estes or Jolly Logic altimeter for about the same cost, but with expansion capabilities. It can fit into LPR/MPR flights and could serve long term as a backup for a HPR flight. I have been thinking about the buzzer aspect as well. Conceptually the requirements were/are to calculate altitude, field display apogee, and fire at least two pyro channels. I had an OLED, Nano, and BMP180 already on hand so that's where I started. Looking forward to getting to the RP2040 stuff soon.
 
I’ve started working on my next flight computer, after hitting a brick wall with both memory capacity and logging rate on the nano.

I picked up a couple of ESP32 dev boards for dirt cheap on AliExpress and boy, those a really capable little units! I managed to get up to a logging rate of 100hz with a bmp390 and mpu6050 while on a breadboard, and, I’ll be able to start working on wifi connectivity and offloading that to the second processor core.

Also picked up a couple of LoRa modules to start working with but I really want to get this version on to a pcb first.
 
Thanks!
My general idea starting out was to make something like the little Estes or Jolly Logic altimeter for about the same cost, but with expansion capabilities. It can fit into LPR/MPR flights and could serve long term as a backup for a HPR flight. I have been thinking about the buzzer aspect as well. Conceptually the requirements were/are to calculate altitude, field display apogee, and fire at least two pyro channels. I had an OLED, Nano, and BMP180 already on hand so that's where I started. Looking forward to getting to the RP2040 stuff soon.
Pictured is my 7 channel 400Hz High G flight computer and my proto version of the Jolly Logic Altimeter. The Uno R3 is there for size reference.
Never question the durability of DIY flight computers and sensors. The semiconductor industry standard is 10,000 G's of shock. The High G flight computer has endured 900 G's for 16 ms during a ground impact. It recorded the impact duration, which was vital to determine the max impact load, plus the off axis torque and vibration ringing after the impact. When things go wrong take lots of pictures, document everything no matter how trivial it may appear.
 

Attachments

  • 20201103_044618[1].jpg
    20201103_044618[1].jpg
    2.8 MB · Views: 1
Damnnn 400hz is incredible! Are you logging everything at that rate or just the acceleration and logging the baro data at a different rate?
That system originally recorded Millis() time and the 3 accelerometers at 400Hz with altitude at 4Hz. Today, it is 4 channels at 400Hz and 5 channels (altitude, pressure, temperature, battery voltage, & roll) at 20Hz, but that is about the limit for the 16Mhz Atmeg 328. My friends that use the ESP32 claim 7 channels at 800Hz with 8 channels at slower speeds and I believe the ESP32 can do 1000Hz.

What are your goals? Do you want to understand the dynamics of your rocket flight in high definition? Or, the inner workings of Coding? Either way, fly what you have as often as you can. The data will open new ideas.

If you are curious as to what a 900 G impact looks like to a 200 G sensor.
 

Attachments

  • 900 G Impact.png
    900 G Impact.png
    78.6 KB · Views: 0
What are your goals? Do you want to understand the dynamics of your rocket flight in high definition? Or, the inner workings of Coding? Either way, fly what you have as often as you can. The data will open new ideas.

Well, it started off with the goal just being “cheap altimeter”, since off-the shelf electronics are sparsely available here, and importing them from the US is crazy expensive due to shipping and exchange rates.

Now I’m doing it simply to see how much I can do with it and what I can learn. The next big goals are WiFi connectivity mainly for starting the logging instead of having it sit on the pad running, WiFi flight summary, GPS tracking, and maybe PID control for controlling spin/weather cocking.

I do fly all the time on micro hybrids, and this whole thing has taught me so much though, even small stuff like understanding how the rocket behaves with different fins, how different fuel grains perform, if/when an ejection charge fires etc. Understanding what did and didn’t go well after each flight is super valuable for every future flight imo.
 
Last edited:
The Arduino Nano you already have is capable of recording 200Hz of accelerometer and gyroscope data from the MPU-6050 with an additional 50Hz of altitude, pressure, and temperature from the BMP180 plus pyro activation and max altitude displaying. If you want to see a commercial flight computer/altimeter made from the same modules, search for "InSight200+ Altimeter".

You can direct message me your IDE version, the libraries you use, and your main Void loop(). I'll review them for speed issues.

Since you are flying micro hybrids, you might be interested in my nitrous hybrid work with Kory Kline back in 1988-89. In YouTube search for "Nitrous Oxide Hybrid Tests" by Spacedog49.

Attached is a graph of data captured with a similar system to yours.


Mini Mean G40 Launch Data.png
 
I'm going to be doing one of these projects soon. I picked up a couple of these mosfet drivers for ejection charge firing off Adafruit. I haven't tested them yet but I did do a test with darlington transistors on a breadboard and it worked a-ok so i think turning one of these on for a half second and then turning it off will work just fine for popping an e-match.

https://learn.adafruit.com/adafruit-mosfet-driver
For the board, I'm using one of Adafruit's Feather boards with an esp32 and built-in pressure sensor. I also have a Feather RP2040 and another pressure sensor on a breakout connecting over i2c that will run the same code. My goal is to write very simple, well commented, and approachable code to run a dual deploy baro based altimeter on multiple boards. I want to produce a simple, easy to understand, but functioning and extendable codebase for HS and college teams to take and run with.
 
The Arduino Nano you already have is capable of recording 200Hz of accelerometer and gyroscope data from the MPU-6050 with an additional 50Hz of altitude, pressure, and temperature from the BMP180 plus pyro activation and max altitude displaying.
Haha after reading the thread yesterday that’s exactly what I tested at home last night. Seems my side of the code was definitely capable but the bmp libraries I’m using have a fair bit of overhead. by not reading from the bmp every single cycle, it does allow much higher rates from the mpu.

I also got data display happening over wifi with the ESP module last night, that was really cool. I’ll likely set the web handle stuff to run on the second core though, so that later on it has no impact on the loop.

I found the hybrid video you mentioned as well, that was *really* cool! Especially the 4th test haha. I’m leaning more and more towards building my own hybrid now. I originally wanted to just buy a Contrail motor system but the Aussie dollar exchange rate, shipping costs and cost of living here has put that squarely on the back burner for now.
 
Haha after reading the thread yesterday that’s exactly what I tested at home last night. Seems my side of the code was definitely capable but the bmp libraries I’m using have a fair bit of overhead. by not reading from the bmp every single cycle, it does allow much higher rates from the mpu.

I also got data display happening over wifi with the ESP module last night, that was really cool. I’ll likely set the web handle stuff to run on the second core though, so that later on it has no impact on the loop.

I found the hybrid video you mentioned as well, that was *really* cool! Especially the 4th test haha. I’m leaning more and more towards building my own hybrid now. I originally wanted to just buy a Contrail motor system but the Aussie dollar exchange rate, shipping costs and cost of living here has put that squarely on the back burner for now.
Several commonly used libraries have excessive overhead. SD is one of the worst. I recommend the SdFat library for datalogging speed.

The BMP180 is spec'd to 120 Hz, but friends that use it limit readings to 60-80Hz. I limit the BMP280 to 100Hz and the BMP390 is spec'd correctly at 200Hz. All of the BMP sensors operate at 3.4MHz I2C clock. About 90% of the MPU-6050's can be clocked at 1MHz. Increasing the I2C clock to 1MHz will increase data throughput 20%-25%. The Wire library runs at 1 MHz with all M0+ and above CPU's.

Utilize the 2KB-4KB internal buffer in 16GB-32GB SD micro cards. I send 50-100 data strings of data to the SD card before I "flush" or "close" the file. This increases data throughput and reduces the memory buffer requirements during the SD write latency. Operating with the ESP32 gives you the faster 4-bit data SDIO over the 1-bit SPI.
 
Several commonly used libraries have excessive overhead. SD is one of the worst. I recommend the SdFat library for datalogging speed.

The BMP180 is spec'd to 120 Hz, but friends that use it limit readings to 60-80Hz. I limit the BMP280 to 100Hz and the BMP390 is spec'd correctly at 200Hz. All of the BMP sensors operate at 3.4MHz I2C clock. About 90% of the MPU-6050's can be clocked at 1MHz. Increasing the I2C clock to 1MHz will increase data throughput 20%-25%. The Wire library runs at 1 MHz with all M0+ and above CPU's.

Utilize the 2KB-4KB internal buffer in 16GB-32GB SD micro cards. I send 50-100 data strings of data to the SD card before I "flush" or "close" the file. This increases data throughput and reduces the memory buffer requirements during the SD write latency. Operating with the ESP32 gives you the faster 4-bit data SDIO over the 1-bit SPI.
i was thinking about data logging the other day, i was contemplating like a ring buffer that stores 2-3 seconds worth of data in memory and then, once liftoff is detected, started writing to disk. That way you're not sitting on the pad writing a lot of useless data but I'm not sure how to implement that in an MCU, normally it would be a couple of threads. Another thing i was thinking is keep writing to the file but after every couple seconds reset the file pointer back to the top of the file and overwrite what you had written previously, when liftoff is detected don't reset the pointer and just keep going.

as for flush, i was thinking never flush until ground impact detection but that's probably a bad idea in case something goes wrong midflight or "ground impact" is never detected.
 
i was thinking about data logging the other day, i was contemplating like a ring buffer that stores 2-3 seconds worth of data in memory and then, once liftoff is detected, started writing to disk. That way you're not sitting on the pad writing a lot of useless data but I'm not sure how to implement that in an MCU, normally it would be a couple of threads. Another thing i was thinking is keep writing to the file but after every couple seconds reset the file pointer back to the top of the file and overwrite what you had written previously, when liftoff is detected don't reset the pointer and just keep going.

as for flush, i was thinking never flush until ground impact detection but that's probably a bad idea in case something goes wrong midflight or "ground impact" is never detected.
My first high speed flight recorders did run continuously so I could detect ignition patterns for a future launch detection algorithm. I had to scroll through MB of data to find the launch, but a 16GB SD card can hold 27 days worth of continuously recorded data at 400Hz. Compared to 32 seconds of data on a 16KB EEPROM in 1999. Today, I can detect launch in as little as 2ms, but normal is 4-6ms. The vehicles have just started to move up the rod or rail which takes another 100-200ms before they are in free flight.

Why store 2-3 seconds of data in any buffer? The data can be lost, and I have experienced data loss several times. The maximum time I went between flushes was 200ms. As I've gone to higher clock speed CPU's and my programming skills have advanced, my buffer needs have changed.

Buffer needs and launch detection will depend on what types of sensors you are using to detect launch. In previous posts you were mentioning barometric altimeters. The buffer and detection requirements are different from the accelerometer systems which are my primary focus.
 
Ahoy! So, for the last 12 months I've been slowly teaching myself how to code and have been working on my own flight computer utilising an Arduino Nano, BMP280 barometer, MPU6050 imu, and a micro SD card reader on the back side for data logging. It's also got a buzzer and a single ignition channel for an ejection charge. So far, it's done around 30 flights and I'm getting some great data back from low and mid power flights, but I want to take it a little further.

So, let's see some other Arduino flight computers! What does yours do? What sensors are you using? Are you doing any onboard calculations for velocity or other things? Do you think there's things I can do better? Whatever it is, I think they're pretty rad and I'd like to learn from you!

View attachment 596735
Hi, This is just what I am trying to build, I also am using an Arduino Nano, BMP280 and MPU6050.
But then I try to use an small OLED Display just to show the max altitude and speed.
I can't code, but I try to use ChatGPT to make the code
data logging on SD card sound like an good idea to add
Here is my test setup :)
1708384533640.png
 
Here is my test setup :)

That's an awesome start! wouldn't take much to turn that in to a usable flight computer. I find ChatGPT fairly good for quickly finding errors in code or to write a chunk of code for me to work from and tweak, and a lot of the time it'll give you some really good new breadcrumbs to learn more about, but it does have it's limitations, partly because the questions you ask of it are based around your current knowledge - there's a lot of little things that you won't know to ask about yet and ChatGPT won't know to tell you about those things because you haven't asked.

If you want to learn more I highly recommend toptechboy.com Arduino tutorials - he has a way of teaching that I found incredibly helpful and covers a lot of the core basics of programming Arduino projects. You'll have a wicked level of knowledge in no time.
 
The Arduino Nano is capable of recording the 6DoF MPU-6050 at 200Hz to an SD file plus the Altitude, Pressure, and Temperature from the BMP280 at 50Hz. If you find you need more speed you can use the Arduino MKR Zero. It has an on-board SD socket and can record the MPU-6050 data at ~500Hz.
 
That's an awesome start! wouldn't take much to turn that in to a usable flight computer. I find ChatGPT fairly good for quickly finding errors in code or to write a chunk of code for me to work from and tweak, and a lot of the time it'll give you some really good new breadcrumbs to learn more about, but it does have it's limitations, partly because the questions you ask of it are based around your current knowledge - there's a lot of little things that you won't know to ask about yet and ChatGPT won't know to tell you about those things because you haven't asked.

If you want to learn more I highly recommend toptechboy.com Arduino tutorials - he has a way of teaching that I found incredibly helpful and covers a lot of the core basics of programming Arduino projects. You'll have a wicked level of knowledge in no time.
Hi, I know that ChatGPT is not the way to go, but I just need some code idea to get started. I think I will learn something from it and then lookup/read the rest I need to get it to "work" and then start to tweek it over time. I just need to learn my self how to code.
Have started to watch the toptechboy.com that you recommended, Thanks :)
I got an ESP-32 that is a bit faster to run the code from later, if I understand that right ;-)
I just wanted to start with the Arduino to learn.
Thanks
 

Latest posts

Back
Top