search

phase4radio / mission-design

Phase4 Satellite Mission Design Portal
3 stars 1 forks source link

Flight Software Trade Study #4

Open yrrapt opened 3 years ago

yrrapt commented 3 years ago

A trade study of flight software is required to select a main framework for the mission.

Possible option is F' but there are many other options available.

n3rdx commented 3 years ago

as we have a minimum of 6U (right?) can we please use primary flight software/control and also include a secondary flight software/control architecture for redundancy? If a second option is available, I would like to propose use of the smallest computer module that I found worked well, with lots of digital I/O and different onboard networking interfaces that is supplied with a RTOS from a major vendor included in the license, and guaranteed support for 15+ years. I utilized it (and will again utilize it for 2021+ flight hardware) . I didn't make it, but it was a life saver. Perhaps include it in the review process?

n3rdx commented 3 years ago

If anyone is interested, the comment of 5 days ago referred to https://www.netburner.com/products/development-kit/som-dev-kits/nano54415-development-kit/ which I have in my collection as it is what I am using for a next-generation radar/propulsion/comms control subsystem. To aid in its adoption, I can contribute the actual Eagle PCB editor library footprint, schematic and (now, 3D part picture) of the stuff that I included in two cubesat missions. Datasheet-NANO54415-200IR (1).pdf

The great thing I found was the RTOS support (licensed! supported!) is built into the price of this system as long as the user doesn't modify the system as-sold. Let me know if a discussion can be hand on this being part of the spacecraft mission control framework (e.g., auxiliary or backup C&DH processor). I actually had written flight software for my system in two modes, "ground" for lab testing and "flight" for you know ... flying -- and that can be seen (earlier version)

The thing that saved the mission was that the flight software version had a stripped down lights-off approach, assuming the C&DH would do as it was supposed to. But the C&DH system (not our teams responsibility) was not finished, I2C serial was not able to be used, and during integration some clever person accidentally left out the supplied EMI/RFI shield and thus a lot of interference was produced that prevented ground to space communications from the electric propulsion system. To alleviate it, the "ground" mode was made permanent, "flight mode" was deactivated, and that allowed lower level test routines to be accessible by the C&DH system through regular TTL Serial and thus the commands could be given to actuate the system with a few extra features - notably, a failsafe timeout timer feature - that was intended only for using the laboratory based "ground" testing mode. Thus the system would automatically shutoff after 10 firing events regardless of commands being sent/or not. :-)