K.I.S.S. Flight Computer Development.

[Mason T]

Hello everyone,

Lets get introductions out of the way, My name is Mason and work professionally designing circuit boards. I started in industrial automation and have moved into consumer electronics. There are over 1 million of my boards out in the wild. I have been in HPR for a couple of years now.

Now for the inspiration. I had an electronics bay assembled and tested and ready to go. I came back to it a few months later to fly and the electronics are acting goofy. I believe this was related to ESD. Looking around at the options available and nothing has ESD protection. I find flight computers that you have to add an external resistor to keep from burning traces. I am not saying what's out there doesn't work. It just doesn't meet my personal expectations.

What's the plan?
It is called K.I.S.S. (Keep it simple stupid) I want something simple and very hard to screw up.

• Power 1S-3S Lipo.
• header with power input and separate inputs for switch for pyro power.
• Drogue and Main pyro outputs.
  • 3A output current. short circuit safe.
• Dipswitch for configuration
  • main
    • 1000ft
    • 800ft
    • 600ft
    • 500ft
  • Drogue
    • Apogee
    • +0.5 second
    • +1 second
    • +1.5 second
    • +2 second
• Sensors
  • Barometric
  • Accelerometer
    • 16G
    • possible 200G option
  • Gyroscope
  • fast polling rates 100's of hertz to kHz unknown yet
• Audio
  • speaks settings on boot
  • speaks results of self test
  • speaks results of flight
• USBC connector to update firmware and collect logs.
• Every unit will be individually tested on an automated test fixture.
  • Test results will be send with each unit.
• Size will be kept small. I am trying to limit the board to 0.75in wide to give it room to fit in a 29mm.
• 4-40 mounting holes
• Protections
  • ESD protection on all inputs
  • Cover to protect the components on the board.
  • output short circuit protection

I have already made my REV 1 and several improvements made for REV 2. I wanted to reach out to the community to see what you think about the feature set. Is there something you think is missing? Does this sound useful?

I am looking forward to hearing your feedback.

 

[mikec]

Seems like a lot of features to be called "simple".

FWIW, I've never had a problem with an altimeter that was traceable to ESD.

 

[jderimig]

Sounds like a nice project. I suspect most of the input you will get will be around the 16g accelerometer.

 

[Mason T]

Seems like a lot of features to be called "simple".

FWIW, I've never had a problem with an altimeter that was traceable to ESD.

A lot of features yes. but a very simple interface and very difficult to configure in a way that parachutes won't come out.

 

[Mason T]

Sounds like a nice project. I suspect most of the input you will get will be around the 16g accelerometer.

I agree, I haven't been able to get my hands on any IMU's until today that would go to 32G. So it looks like I will be able to bump that to 32G which will cover 99% of the flights from what I've seen playing in open rocked with light thin rockets with high thrust motors. Thanks for the feedback.

 

[OzHybrid]

What's your target price?

 

[SolarYellow]

If it's going to be 0.75-in wide, pay attention to the height of components vs. location and fit it in BT-50. Doesn't need to fit in a coupler, necessarily. If it's going to fit "29mm," it better fit inside a coupler. I would like to see the high-g accelerometer in addition to the 16 or 32 for accurate velocity measurement of mach-capable rockets.

Don't need that many choices for drogue.

I like metric mounting holes. All the hardware I've ordered for rocket stuff is metric.

I'd really like to see something that would fit cleanly in BT-20 without costing what Adrel stuff costs.

 

[Mason T]

What's your target price?

That's a great question. Nothing is firm yet. I have to see where BOM, assembly, and packaging costs end up but I would expect around $100 give or take. I am not looking for massive margins.

 

[Simon Auty]

Sounds good, keep us updated

 

[jhill9693]

That's a great question. Nothing is firm yet. I have to see where BOM, assembly, and packaging costs end up but I would expect around $100 give or take. I am not looking for massive margins.

I’d love a cheaper self assembly option. Many of us actually enjoy the process and can use the cost savings.

 

[jhill9693]

I like the speaking output. I don’t like counting and decoding beeps.

 

[jhill9693]

If you’re interested, there is a gap in the market for staging electronics.

The Eggtimer Proton and Apogee Simple Timer are the main ones out there but they are either unavailable or too expensive.

Desired specs:

• SMALL (.75”x1.25”) board
• Acceleration-based launch detection
• Tilt detection with failsafe
• Two or three pyro channels activated by individual timers from either launch or from burnout (Eggtimer doesn’t count from burnout)
• Runs on a 1s LiPo
• Bonus: baro altitude
• Bonus: high res data logging
• Bonus: wireless arming

 

[cerving]

FYI, the new version of the Proton will be available this Summer. Details to follow... but not in this thread. BTW, the Proton DOES trigger on burnouts... up to six of them.

There's a reason that we don't make a dedicated staging device... there are already some nice ones on the market. Your wish list includes a baro, accelerometer, IMU with tilt lockout, and two outputs... this is a pretty hefty sensor package, and if that accelerometer is a high-G device (> 16G) it's going to be expensive. Relatively few rocketry hobbyists actually need a package like that... so we aren't going to be making one anytime soon.

 

[OzHybrid]

Making a flight computer is tougher than you might think. A rocket is a tough environment for electronics. There are some good flight tested products that are less than half your proposed product price. When you get to multi stage rockets, I'm not sure who would choose a new unproven design. It's just too much effort and. cash that someone would have expended to risk it on an unknown. ( regardless of gow good a designer you are).
There is already a Russian manufacturer that does spoken voice over Lora wan. The price is US$60 ish.
Respectfully, I don't think you have researched the market to figure out where you could add something to it. What's your unique selling point Why should we choose your product?

 

[Mason T]

I’d love a cheaper self assembly option. Many of us actually enjoy the process and can use the cost savings.

That would be nice but this wouldn't work for self assembly. Due to size taking priority almost all of the resistors and caps are 0402 and FET's are SOT-323 The audio amp and Microcontroller are fine pitch. I'm not saying someone couldn't hand solder it. It would require high soldering skill and nice equipment.

 

[cwbullet]

I subscribed and I am interested in following the project.

 

[jhill9693]

FYI, the new version of the Proton will be available this Summer. Details to follow... but not in this thread. BTW, the Proton DOES trigger on burnouts... up to six of them.

There's a reason that we don't make a dedicated staging device... there are already some nice ones on the market. Your wish list includes a baro, accelerometer, IMU with tilt lockout, and two outputs... this is a pretty hefty sensor package, and if that accelerometer is a high-G device (> 16G) it's going to be expensive. Relatively few rocketry hobbyists actually need a package like that... so we aren't going to be making one anytime soon.

I’m a big fan and fly Eggtimer almost exclusively I still would like to see you come up with your own take on an accel+gyro staging timer similar to Apogee’s

And to the OP, I eagerly await to see what you come up with and consider me a volunteer for test flights if you need one.

 

[Mason T]

Making a flight computer is tougher than you might think. A rocket is a tough environment for electronics. There are some good flight tested products that are less than half your proposed product price. When you get to multi stage rockets, I'm not sure who would choose a new unproven design. It's just too much effort and. cash that someone would have expended to risk it on an unknown. ( regardless of gow good a designer you are).
There is already a Russian manufacturer that does spoken voice over Lora wan. The price is US$60 ish.
Respectfully, I don't think you have researched the market to figure out where you could add something to it. What's your unique selling point Why should we choose your product?

As with any project there will be unexpected challenges. I know I am up any challenge that it throws my way. This is far from my first product design. Yes there are some cheaper options out there. I am not trying to start a race to the bottom. I believe what I am creating will be a great value. And if others disagree that's okay because I am getting exactly what I am wanting. Just for clarification this is not designed for staging. Just for normal dual deployment. And no one should trust something completely untested. That Is why I am building some mid powers as a test bed to get the kinks worked out. I already have a couple of HPR frequent flyers that have already offered up Electronics Bay space for collecting data. Flights will be logged and results will be made available. It will not be made available until it has a good track record.

What makes me unique:

1. Fully assembled and tested via automated test fixture with results included.
2. Speaking instead of beeping.
   1. Will tell the results of self test on boot
   2. Will tell you how it is configured
   3. Will tell you if it detects a intermittent connection on the pyro output
   4. Will tell you when it is ready to fly
   5. Will tell you the stats of the flight on the ground.
3. Pyro short circuit safe. (I know there are some others that are Eggtimer for example but some popular ones are not)
4. ESD protected.
5. Small form factor.

 

[Cape Byron]

A rocket is a tough environment for electronics.

Sounds like something Elon would say. "RUD is hard on electronics."

 

[Mason T]

Hello All,

It's time for an update. I want to the forum get caught up to where I am at. I am 3 versions of hardware deep.

Below is my REV 1



This was just to prove some features out. It came to an end quickly when I got to the end of writing the barometer driver and I had to divide the output by 100 and that put me over the program memory size. I quickly realized how much bloat the STM32 HAL introduces. I have 64k of FRAM. I have introduced some scope creep and want to increase my sample rate so I will need more data storage space. I am using current limited high side switches for the pyro outputs. These later ended up as a victim of the parts shortage and I needed to go a different path. This has a buzzer and after playing with this for a bit I realized I wanted to speak instead of beep data.

Lessons learned

• I need a MCU with much more program memory.
• In order to get the data rate I want I need to move from I2C to SPI.
• The DIP switch is easy to cook.
• I need more memory for data storage.

On to REV 2


This has many improvements and is completely unrecognizable from my REV 1. The biggest change being the addition of the USB C connector. This can power the flight computer for getting flight data off and for firmware updates. There is reverse voltage protection in place to prevent back feeding the battery from the USB power or from the battery to the computer. The most effort went into figuring out the pyro outputs. I needed current limiting of some kind to prevent browning out the MCU on small batteries or causing damage on larger batteries. I initially was looking at MOSFETS with a current limiting resistor. The problem was with the input voltage range I want to be able to accept it was impossible to find a satisfactory solution. The problem is if I select a resistor small enough to allow enough current at 3V then the current at 12.6V is excessive and causes crazy heat. If I find a resistor that works with 12.6V then I get a trickle at 3V. This led to going down the path of a constant current switch mode supply to provide 4A no matter what the input voltage is. This is also great for those that are insistent on using 9V batteries. To get 4A out it only pulls 0.36A at 9V. This minimizes the voltage drop on the battery. After lots of fidgeting with the DIP switch it lost the tactile positioning. This one also was soldered with a reflow oven and still was cooked. I am not satisfied with the DIP Switch. The footprint I got for the flash memory was the wrong size so that limits what I would be able to do with this hardware. I can still validate the sensors, outputs, audio, and USB. I was unable to get USB working. I believe it is related to not having a stable enough clock source.
Improvements

• Changed to a larger MCU with much more program memory.
• Added the USB C connector. This will be used to collect flight logs and update the firmware.
• Added the push button to enter programming mode for firmware updates.
• Changed from a buzzer to a speaker.
• Changed the pyro output to a switch mode constant current supply

Lessons learned

• I need to find a different solution to the DIP switch
• Need to fix the footprint of the flash memory.
• Add a crystal to support USB
• The barometer has 2 pins that are chip selects and tied internally. one of them was tied to GND. Need to correct in next revision.
• I thought I had updated the radius of the speaker on the PCB layout which is larger than the speaker. This caused the speaker to overlap some components on the PCB.

I will follow up with REV 3 shortly.

 

[cerving]

FRAM would be a good front-end buffer for flash memory, especially for high-speed sampling. I've been waiting for the price to come down close to the price of EEPROM's for 10 years... no bueno. Not enough demand, too few suppliers, it's still a specialty part.

 

[Mason T]

It certainly would be. It has the fast write speeds. They certainly are not cheap and are quite limited in size. I am finally wrapping my head around my flash part. I have written the driver from scratch and it is my first time writing software to talk to a flash chip. My part actually has a buffer in it that you write to and then send a command to send the buffer to the page. Not understanding that and the maximum partial writes per page caused some serious headaches.

 

[Mason T]

Rev 3 of the K.I.S.S. Flight computer is shown below.


With REV 3 things are getting exciting. I replaced the DIP switch with two tactile switches. One will cycle through drogue settings and the other will cycle through main settings. I am no longer limited to just 4 options for each. This is also far easier to actuate. the switches on the DIP switch were so small and close together that they were not the easiest to actuate. I am also able to reuse one of these switches to enter programming mode for firmware updates.

The Flash memory finally fits on the board. I am writing the driver to talk to it from scratch and it has been a headache. This is my first time writing software to talk to a Flash memory part so there is a learning curve learning all about pages and blocks and partial write limits.

The current sense resistor gets hot. It doesn't shut down or break when driven continuously. On a one second pulse it wouldn't be a problem. I just want to make sure I don't burn anyone so I am looking at a couple of ways to resolve this.

This is the first board I have been able to fly and attempt to collect data to use for algorithm development. It turned into a crazy week trying to get the flash driver working correctly and I finally got it working at the bench the day before launch. I unfortunately didn't have time to perform an integration test with the KISS in the rocket powered from the shared battery with the primary flight computer for the flight. I was looking for a single reading above 3.5G to start recording for 5 minutes. The noise on the power or RF would cause an occasional blip of a single reading above my threshold and causing a premature trigger. I managed to get some data but I think it is written over a previously written page where it is much jumpier than it should be. If you did a max rolling filter you can clearly see the motor thrust curve and it matches the simulated acceleration and burn time. I knew I need to sample more than one reading over the threshold but I had to have a code freeze to get some bench testing in. Next time.

Improvements

• Replace DIP switch with two tactile switches.
• Fixed FLASH memory footprint.
• The speaker no longer overlaps any components.
• Added a much cheaper barometer. Good to ~33,000 feet. but ~$10 cheaper. Cost savings will be passed on. Still have the pads for the 100K foot barometer where a "PRO" model could follow if there is demand. I would guesstimate 95% of the flights fall under 33,000 feet.
• USB is working.

Lessons Learned

• Triple check symbols. The MCU has the reset line and the external crystal out flipped.
• My current sense resistor gets HOT in a hurry. It can run continually without turning off. But I don't want to burn anyone. I am looking at a couple options to solve this.
• The FETs are on the high side of the current sense resistor. When the FETS are on the source of the FET is raised to 0.6V this lowers my VGS and when I go to lower supply voltages the FETs don't turn all the way on and limit my output current.
• More that one sample above the threshold to detect a launch.

 

[rocket_troy]

I'm curious, what baro sensor is good for 100Kft?

TP

 

[Mason T]

I'm curious, what baro sensor is good for 100Kft?

TP

My bad 85k feet. down to 10 mbar. MS5607-02BA03.

 

[rocket_troy]

My bad 85k feet. down to 10 mbar. MS5607-02BA03.

Well, is it even 85k feet? The specification in the datasheet states it's *accurate* to 450mbar and that 10mbar is in the linear range of the ADC, but there's not much mention of how accurate the sensor is below 300mbar. Like, can someone explain to me what the purpose is of saying your ADC is linear to 10mbar but not mentioning a damn thing about the accuracy of the sensor below 300 mbar? Just seems a bit disingenuous to me.

TP

 

[Mason T]

well 85k ish I haven't dived to deep into the data sheet because the part is on the back burner for me. That is very interesting that it doesn't spec below 300mbar. if you take the +- 2.5mbar accuracy. that turns into a +-~6k foot spread. though I'm sure the 2.5 opens up or they would have included it. You would probably be better using GPS or a second more sensitive near 0PSI sensor.

 

[rocket_troy]

well 85k ish I haven't dived to deep into the data sheet because the part is on the back burner for me. That is very interesting that it doesn't spec below 300mbar. if you take the +- 2.5mbar accuracy. that turns into a +-~6k foot spread. though I'm sure the 2.5 opens up or they would have included it. You would probably be better using GPS or a second more sensitive near 0PSI sensor.

Which brings us back to my original question: what baro sensors are actually good for 85kft or more? Are there any?

Agreed on the GPS.

TP

 

[cerving]

Which brings us back to my original question: what baro sensors are actually good for 85kft or more? Are there any?

Agreed on the GPS.

TP

AFAIK, there are no digital baro sensors that will resolve to 85K or more, because at that altitude any pressure change goes below the single-bit resolution of the digital output. From a practical point of view, they're good to about 60K, 70K is pushing it.

 

[jderimig]

Which brings us back to my original question: what baro sensors are actually good for 85kft or more? Are there any?

Agreed on the GPS.

TP

Define 'good'. You can get sensors that are monotonic down to a vacuum. But the error in altitude estimation becomes very large down there.