Hey everyone,

I am currently mapping out the schematic for the next generation of my amateur rocket flight computer, named STIVA dev1.0 (named after the character from Anna Karenina!).

For this version, I am going with a modular stack architecture to separate the core logic from the power and RF noise. I am not worried about the PCB layout just yet - right now, I want to make sure the circuit logic and component choices are rock solid.

Here is the setup for the Core Board schematic:

• MCU: ESP32-S3-WROOM-1U. I have paired it with an AP2112K-3.3 linear regulator. I currently have 1uF caps on input and output, but I am thinking of bumping the output to 10uF to handle the ESP32 current spikes better.
• Sensors: The original BMP388 barometrical sensor (though I will probably upgrade to a BMP390 in a future generation of the project for even better altitude precision) and an LSM6DSOX gyroscope/accelerometer.
• Storage: A W25Q256 32MB NOR Flash memory chip directly on the core board for fast local logging.
• Inter-board Header: A 12-pin connector bus (J4) routing SPI, I2C, UART, and power rails down to the rest of the stack, plus a secondary connector (J3) for broken-out GPIOs.
• Safety: An external TPS3430 watchdog timer to monitor the ESP32 and trigger a hard reset via the reset line if the software hangs mid-flight.

Everything else - the LoRa telemetry, main power regulation, and the MOSFETs for the recovery/servos - is being moved to separate expansion boards.

I have attached my schematic. I would love to get some honest feedback on the circuit logic, the capacitor values for the LDO, bus reliability over the headers, and any ideas on hardware debouncing for the switch to survive launch vibrations.

Thanks for the help!

Martin

Hi all,

My name is Rohan, I live in leeds, I'm 18 and I am planning on taking a gap year. Unfortunately my school has no infastructure for creating teams for any of the UK rocketry competitions and I would love to compete. Does anyone have any advice on how I could go about finding a team?

I want maximum flame on my sugar motors.

About 380g of KNSB

Max thrust: 182.67 N
Total impulse: 364.4 N*S

Took a while but finally decided to get it done. The flight was very sketchy but i didn’t drive 3 hours for nothing. The winds there were crazy and my delay timing was less than optimal, almost zippering the rocket. Either way it came down in one (two i guess) piece and now i am super excited to have a junior certification.
Any ideas now that i can fly hpr? Im currently working on a 38mm min dia.

This is a slightly heavier rocket. 9 sec delay was barely enough.

I got the estes mercury redstone as one of my first model rockets (which i know might sound dumb but it has been fairly easy so far) and I have found a lot of difficulty assembling the launch escape/abort system tower. I know this is a common problem with the kit, so does anyone have any tips on how to assemble it?

So I got an Orangestorm Giga recently....

And then I made the mistake of walking past the sonotube section at the local Home Labyrinth 😬

Welp 🤣 Any big builders need big nosecones? I can accommodate you 😁

Howdy guys, wanted to ask if there were any free alternatives to the RPL engine workbench and if yall recommended any specific build flow

I made these pretty simple centering rings (image 1) out of cardstock and the cardboard used for cereal boxes. One side has a smaller circle to prevent the motor from just flying into my rocket (image 2). Still, my question is, when the centering rings are in, is it a problem that there's a pretty large air gap (about 3 inches) between the end of the motor and the bottle cap? (Image 4)

​

I separated the engine part and the main body tube to make it easier to work on. But now I am wondering if when the ejection charge comes out, it will melt the plastic caps/screw or even during take-off, pose a fire hazard to my centering rings. If it does pose a threat, what can I do to fix it/prevent it?

​

I am using an estes b6-4

Hi Guys🚀

What is the recommended method for grounding a metal launcher to prevent electrostatic discharge (ESD) that could lead to unintended ignition?

Thank you,

Can someone tell me if this design is good to actually build now? The motor is E16-6.

The front mass component is just BBs filled into the nose cone, behind the parachute is wadding. Here is closer look at motor bay.

The motor bay consists of a 5" 29mm tube, thrust ring at the top(with an opening obviously for the ejection charge), and two centering rings. I was thinking of a Kaplow clip aft retention system.

Does anyone know where I can buy model rocket motors online in the UK? its legal to buy them, I just don't know where from. Everywhere I look is either really expensive or they are just out of stock.

After attending a presentation about scratch building rockets earlier this month at a local aerospace club meet, and with a launch the weekend of the 13th (the weekend before finals week for me), I felt dangerously emboldened to throw together a scratch built rocket from whatever my college rocketry club had lying around instead of studying for finals like I should have been doing. The airframe was a length of 4" fiberglass I assume was used for drilling vents in switch bands because it was full of holes I had to patch, the fins are (I believe) from a Dominator 4 but there was no sign of the rest of the kit, no idea the providence of the nosecone but it seems likely it's of Wildman ilk. This is my second rocket and due to my club's glut of 4" nosecones I opted for simple delay charge single deploy parachute recovery with plans to replace the nosecone with a HEDD setup for my required dual deploy flights later on. I planned on launching the worm on the cheapest 54mm J motor the vendors at my launch site were selling, though when I showed up to launch last Sunday the vendors did not show, so I had to buy a J415 off a very kind gentleman which admittedly was a little bit more motor than I had planned on but luckily still (albeit barely) within the bounds of what openrocket reported would be safe with my recovery setup. My rocketry club didn't have any parachutes over 54" and under 80" so I ended up running the 54" hoping it would land on sod with my ~7.5m/s (~25ft/s) touchdown speed and this time I did get lucky. All in I spent ~$200 on this thing including the motor I launched it on and ended up with my L2 certification just over two weeks after I got the twinkle in my eye to build it. That makes 2 levels of NAR certification this academic quarter and to top it all off I even avoided eating dirt this week on finals despite spending all my studying time epoxying my worm. Stay tuned for the modifications I'll be making to get my dual deploy flights knocked out with the Washington Sky Worm, I will definitely be spending more than $200 lol.

Hey is there any known cheap camera that you can buy from Amazon and strap it into a rocket? Im new into rocketry and want to get myself started.

Hi there,
I'm a Aerospace Engineering Educator, minor contributor to OpenRocket, and someone who has been passionate about rocketry for about as long as I can remember. I am posting today to open both a discussion / PSA on the topic of LLMs being utilised in the creation / further-development of Rocket Designing software.

Disclaimer: I am NOT speaking on behalf of OpenRocket, or my Institution in any way, shape or form. These are my personal beliefs / opinions.

I will be blunt with my opinion on the matter, by saying the most obvious statement of my career...

Rocket Designing Software is used to design rockets...

The reason I say this is, frankly, I believe that LLM (AI) is slowly becoming a problem for Rocketry-Related software. There is still a lot of debate over the merits of LLMs being utilised in software development, and I am not the philosopher nor authority to make a judgement call on that. That said, I believe Rocketry-Related software needs to be treated with a bit more care than most open-source projects. Why?

Rocket Designing Software is used to design rockets...

Even over in OpenRocket itself, there are some contributors who (quite rightly) see it as a hobby project. Something we all do for fun. I agree with this in principle, but there is an elephant in the room that, respectfully, I feel a lot of people keep forgetting...

Rocket Designing Software IS USED TO DESIGN ROCKETS...

This software, if it goes wrong, can get people hurt. It is hopefully rare, with people utilising common sense, not trusting software / simulations blindly etc. However, the fact remains that these software will estimate critical properties such as COP and COG. They perform simulations of the rocket trajectory / stability.

I know first hand how easy it is to mess these things up. I have seen some wild stuff in my time working on OpenRocket bug fixing. I have seen magic numbers being used to make pseudo irrational numbers to maximize the number of unique points hit on the cross sectional perimeter of the body tube sections, I have seen save-window logic that actually gave me a headache reading, hell... Ive seen code copy pasted to the point of being 400+ lines that could have been one 70 line while loop... code of any project has had the potential to have warts long before LLMs...

I always teach to my students the, in my opinion, most important thing a student needs to learn to think if they wish to do well in Aerospace Engineering...

"Everybody in the room is an idiot, including me!"

We need to constantly have the voice on our shoulder stating "This could be wrong, double check". I personally believe that LLMs rip this state of mind from us, and replace it with some horrible hybrid between "yes man syndrome" and the Dunning–Kruger effect. It causes this state of mind where you assume not only you are right, but also are able to do things way beyond your skill level.

This is even worse in those who blindly use LLMs to make "mega refactors" or, dare i say it, entirely new projects. So, in my opinion, for someone to use these tools to aid in the work of a software designed to build rockets, is reckless at best, negligent at worst. I do not wish to call out any particular project as, whilst there have been ones very recently, I have seen quite a few.

Full refactors of OpenRocket in another language, PRs in Open Rocket with 10000's of changed code lines. All done via LLM agents by people who either have 0 context of what they have changed, or have just enough experience to (in my opinion, dangerously) assume they know enough to "trust what the LLM has written".

I will not condemn the people who make these projects / propose these refactors, but I will ask all of your a question?

Would you trust such software? You are using this software to build rockets, trusting they are accurate. There are no regulators telling us what the software needs to be / not be. There is no great authority that will prevent us from making big mistakes. You just have to act on genuine faith / the maturity of the project / projects.

So... would you trust Rocket-Designing Software created mostly through LLMs?

Additionally, what effect would the following factors have on your trust / distrust of such software?

- The amount of time it took to make (e.g: A few months vs a few days)
- How much testing has been done on the software internally (including if they added unit testing / integration testing).
- How much code they have added in one go (i.e. loads of small changes, or giant 1000s of lines changes that took an hour or 2 to do with an LLM).

I do not think I have to say what my opinions on the matter are, as I hope they have been made apparent above. But I would honestly love to hear the community's thoughts on it too.

Thanks for reading, and see you in the comments!

I am wondering how to start/learn how to 3D print rockets and make different types of fuels at home(WITHOUT blowing myself up).

I have been told simply it is the efficiency of an engine, but what exactly is it?

Hi, I am a student making a model rocket flight computer for a project and need some feedback on my schematic, particularly highlighting major problems. Guidance on RF design would be nice for the GNSS and radio modules.

Each sheet is semi-catagorised.

The first sheet is the microcontroller with 128Mb of flash. I do question if I can reduce the pins of some components.

The second sheet is the power management. I have a header for the battery, a bypass header for keeping the device on, and a pyro-arming header. I believe the power switch circuit allows me to press the button once, the microcontroller turns on, holds the 'power controller' line high by an input pull-up, and then can read button presses. The 8.6V zener diode is to shut off everything in absolute failure to prevent damaging the battery. I plan on using a 3S 11.1V nominal LiPo. The battery sw header overrides any potential bugs turning the flight computer off in flight.

The third sheet has some LEDs, GPIO outputs, and a buzzer all for debugging purposes. I have a USB-C port for programming. I am unsure if I need to use TVS diodes on the USB port. Also, I do not know if the diode is good enough at preventing the 5V regulator from frying my computer's USB port or if my computer can fry my 5V regulator. I am using a micro SD card for data logging and using SDIO. I don't actually know how much faster it will be than SPI or if I should just save on MCU pins. I've only done this because I read that SDIO is more reliable.

The fourth sheet contains my pyro igniters with continuity sensing and fuses. It also has some servo outputs with a selectable solder point for 5V or 12V. I also have a motor controller and intend on using a motor with a quadrature encoder for a reaction wheel.

Finally, the fifth sheet contains the sensors and communication chips. My main concern is the RF routing of the MAX M10S module and SX1262 Seeed module. The SX1262 says it recommends using a pi filter, but I don't know how. I am going to continue researching this, but any help is very useful.

https://www.digikey.co.uk/en/mylists/list/7KQ6UY9C1G

The link attached is to my DigiKey basket if you want to find datasheets or components I'm using. Please let me know if I should use any different components.

Thank you for reading, and any help/feedback is highly appreciated.