> 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 -- ------------------------------------------------------- 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 psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
