Last night at the pacsat developers meeting, we had a good conversation about what we were aiming for.  This started out with the question "what is our power budget", and the answer seems to be pretty tightly bound to the satellite that is hosting us, and what else that satellite is carrying.

It seems to me that thinking about it this way gives us a round and round series of thoughts: What is our power budget?->What satellite will we fly on->Unknown but we can guess how much power is available on a 3U or a 1U->But that depends on what else is in the satellite, is it only us?->What is our power budget :-)

My (current) thought is that pacsat is in the ASCENT program, which is specifically designed for "trying things out" without necessarily having a flight in mind for them.  So I would suggest that our first job is to just get SOMETHING that works with a TMS570 and 4 AX5043s.  Then we will have a very good idea how much power we use under different circumstances (fewer TMS570s, slower processor, etc) and for that matter whether we would be better off with an STM32L lower power processor.

In all cases, we should design for flexibility.  As an example, don't do anything that absolutely REQUIRES 4 AX5043 chips and don't do anything that REQUIRES unique capabilities in a TMS570.

Then we should of course be prepared to make the required modifications for a specific flight.  (Example:  We are Jonathan's 5043 Pi boards; the RT-IHU is the specific implementation of those and the TMS570 for Golf.)

This is quite different from a typical approach where initially software is given many requirements and a date, and then (usually) the requirements turn out to be unachievable within the given time and cutbacks have to be hacked out.  But I think it is appropriate for the organization and the program we are in.

73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software