> My question (before we jump into CAN or anything else) is, "What nodes
> need to talk to each other if the flight computer goes down?"

While Tim and I were writing requirements for the capstone team, we took
a very, very careful look at the LV2 package (well, ok, what's left of
it ;) and discussed what we liked and what we didn't like from a
functionality point of view. And we came up with some "back channels"
that we very much want to support:

1. The first is that we want the pyrotechnic node to talk with the
avionics power system node. There are a bunch of reasons for this,
including the possibility of launching without the flight computer, and
also letting the cute little 400 MHz radio on the pyro node wake up the
APS node and let us turn on power to this and that remotely. This was a
huge feature for testing things, and since it's almost free, we'd like
it again. Using our HTs to sequence and arm the rocket was just... easy.
And even better, our cute new radio can support both DTMF tones (e.g.,
it's got signal out) and it's got a FSK radio in it, so we can also send
the pyro node UART to barf over the back channel. Not that we'll
actually do this, of course, but it's a cool future feature to use.

2. Second, down the road (the long road), we think that there's going to
be a ton of reasons to have a back channel. From the GPS giving
microsecond-accurate time stamps to all the different nodes, to having
an ultra reliable actuator bus, to... well, lots of future stuff. We
have a lot of ideas here, and luckily, none of them have to ever be
implemented to launch, besides having some wires in place :)

For the record, the goal here is that we integrate this back channel in
such a way that it doesn't slow down the capstone team in any way.
"Working Hardware by June" is our motto here. Tim and I just want to
make sure we've got everything we want in that working hardware :)

> If it turns out that only two nodes need to talk to each other, why
> bother with CAN?  Why not just run one serial connection between the
> two?  I'm concerned that we're adding too much complexity for what
> should be a really simple backup system.

If Tim and I just had to deal with *just* the microcontrollers, then we
would have chosen CAN for the back channel because CAN *is* a simpler
bus to work with than a star topology serial bus. And it's safety
critical, and has lots of nice features like data identified packets
instead of node addresses, etc.

But CAN adds a lot of complication to the flight computer, and
theoretically we don't necessarily need all the features - and
constraints - of CAN, so we agreed with your sentiment, sarah, and just
chose a star-topology serial bus.

But then Dan and Dave had to go muck everything up, and suggested that
we try getting CAN to work on everything and just go that route. So I
told them they have three weeks to get everything going, and if doesn't
work great, we go ahead with plan A which is the serial bus. And if they
get CAN going on the FC, and it talks flawlessly to the LPC23xx (which
already talks CAN just fine) then we'll consider going that route.


Andrew Greenberg

Portland State Aerospace Society (http://psas.pdx.edu/)
and...@psas.pdx.edu  P: 503.788.1343  C: 503.708.7711

psas-avionics mailing list

Reply via email to