Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Damian Suarez (RIT Student) Natalia Sokolov (RIT Student)

DeploymentMod

Its the mod that deploys the things

Guiding principles

You cant make all the biscuits at once without burning the house down

More Info

Presentation Notes

  • Do we want to make the 2 P-IO pins on i2c pins or PWM pins (routing)

  • Old temperature Requirements (10F-110F) were silly

    • 0C-50C is prolly good

  • Pick requirements for sensors more betterly

    • Gyro: Small angular random walk

  • How would it work if we lost power? -dean

    • Altimeter boost detect would probably still work

    • IMU boost detect wouldnt

    • Just dont loose power lol

  • Configurability in field

    • really vague requirement (telling aaron to reflash them is configurabililty in field)

    • has a console to reconfigure - better way to say that

  • Don’t need arming switch

  • Make boost detect requirement verify by test

  • Conops was not a conops

    • wiring was a little nasty

  • DE9 Pin shenanigans

    • 2x ematch
      2x rs48
      2x PIO
      5v
      GND
      ematch bypass

    • breaking out kinda sketchy

      • but we need to break it out anyways so

  • BMP388 vs 390. which one is available

  • board space might be tight

  • make a harness diagram for a de9

  • Little plane whats the deal with that

    • image-20241002-223257.png

    • sketchy header thingy to power mod would work

  • stlink cut first

    • takes up a lot of space

    • dont have compatibility with jlink

    • is convenient tho

  • Leds should run at 3.3V

  • Double check buzzer stuff

    • can it actually make music

History

The first era. Deployment Mod

Originally, we were under the impression that Brain Board was non functional. We know now that it was untested.

Design Goals

  • Use known working MCUs and sensors from the Grim Reefer to increase the chances of everything working first try. Basically, a Grim with charge deploying capabilities and ethernet connectivity.

    • Grim had a super set of the features of an RRC3. Had enough inputs to do phase detection but that was not developed as we did not need it.

  • Be backplane compatible with the ability to act as the charge deployer for a backplane rocket. Have a backplane compatible interface.

  • Be able to take battery power as a secondary source. This would allow testing on L1s and L2s that could not support an entire backplane. We saw testing as a vitally important aspect because if we are trusting this thing to deploy charges we want it to be proven many times

TLDR; a more flexible RRC3 that could also act as a backplane module.

The second era. Brainsor Mod

At the beginning of the 2024-2025 school year, the project was brought up to the powers that be.

The main points of the first meeting with the wider Avi community brought about the following thoughts:

  • Brain Board exists, why are we redoing this?

  • Standalone Test Flights (L1 grim flight) are really important

  • Since last year, talks of moving Brain Board away from VoCore to one of the bigger STM32s. The idea was that originally, VoCore was chosen because it would be more powerful and flexible compared to launch_core on an stm32f4 like all the other modules. However, the larger stm32h7 series has chips that are quite powerful (some of them exceeding the clock rate of the VoCore even) and Zephyr solves a lot of the complexity that using a linux based board would solve.

  • A brain board is pretty useless without a sensor module. While modularity is great, we are taking away a slot that could be used for something more interesting (live video board, things like that that)

From there, we decided to sort of combine the ideas of Deployment mod and Brain Board v2 into Brainsor Mod

Design Goals

  • Use tested sensors - As of Irec 2024, all of sensor mod sensors were working from Aarons assesment and theres a good overlap there with grim sensors we were already planning on using

  • use an stm32h series chip. Allows us to use new launch libraries w/ zephyr but with greater power and dual cores.

  • Keep the ability to deploy charges

  • Drop the dual power sources from the board itself. They provided a lot of complication and with more sensors (sensor mod has more than grim) and the components for deployment, space was at a premium on the board.

    1. In order to still have the ability to do test flights in L1s and L2s, "little plane" was to be developed. It has not yet been decided what form that would take

    2. Biplane: Aaron brought this up as something he'd been working on but it was not discussed much. I don't know what form this takes

    3. Payplane. Still a thought experiment at this point but it also has the ability to fit into a smaller rocket as it will have to fit into a payload

    4. Power Module Passthrough: A double sided board that has brainsor mod on one side and power mod on the other. W/ or w/out a switch. We know powermod works and if we don't require a switch (for a test flight of brainsor mod, we don't necessarily need to record power telemetry), could be incredibly simple - just headers and a little but of routing

    5. Powered Plane: Put electronics to supply the power required by the backplane standard onto the board onto which brainsor mod mounts. Would basically be what the original design of Deployment Mod but on two boards to simplify brainsor mod. Wouldn't need a switch since theres no one to talk to.

We hope to give a PDR at the Avionics meeting by end of September or first week of October

  • No labels