I need to track down some 4FG black powder if I can.
Yes, make it easy on yourself. You have better problems to solve than this one.
I need to track down some 4FG black powder if I can.
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.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.
Really that little residue? My tube ended up a mess. Maybe I needed to wrap it more and use less 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.
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.
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.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.
Thanks!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.
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.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.
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.Damnnn 400hz is incredible! Are you logging everything at that rate or just the acceleration and logging the baro data at a different rate?
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.
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.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.
Several commonly used libraries have excessive overhead. SD is one of the worst. I recommend the SdFat library for datalogging speed.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.
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.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.
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.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.
Hi, This is just what I am trying to build, I also am using an Arduino Nano, BMP280 and MPU6050.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
Here is my test setup
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.Here is my test setup
View attachment 631479
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.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.
Enter your email address to join: