On Sun, Feb 1, 2009 at 1:43 PM, Daniel E. Heinlein
> Adding on to Dan's comments, if no one minds my two cents...
> If the flight computer goes down, we have no way of logging data using
> USB because the other nodes can't communicate to the wireless node,
> which provides our only other source of data. Therefore, we will not be
> able to determine causes of failures if and when they happen. That's
> why we need to have ALL the nodes talking.
> Look at NASA: When Columbia (God rest her soul) broke up on this day
> six years ago, all of the flight controllers in Houston stayed in their
> seats and SAVED THEIR DATA so they could replay it later to help
> determine what happened.
Let's examine what data we actually need to determine what happened.
If the flight computer fails, the only way to bring the rocket back
down safely is for the pyrotechnic charge to deploy at the right time.
The flight computer can't tell it to fire, so the timer on the
recovery node will have to fire it. At that point, the only data we
need is (1) whether the pyros fired, (2) whether they were fired at
the right time (perhaps so we can reset the timer to different time),
(3) were the parachutes successfully deployed, and (4) where did the
rocket land so we can recover it.
(3) is easy to determine from the rocket state. We could tell from
the wreckage of the last rocket that the pyros had fired, but the nose
cone hadn't popped up. So no back up logging is necessary for that.
(1) We would need the pyro node data to determine if it tried to fire
the pyros, so we would either need a compact flash card at the pyro
node, or a back channel to the communications node.
(2) is impossible to determine from pyro node data. We need at least
one sensor to provide acceleration or altitude measurements to
determine where in flight the parachutes were deployed. I propose it
be the GPS node, since that also satisfies the need for (4) finding
out where the rocket landed.
So, if you really want to log data to find out what caused the rocket
to crash, you need two one-way back channels: one for the pyro node
and one for the GPS node to send data to the wireless telemetry link.
> It's all about the data, people.
No, really, it's all about getting our rocket back. We have data from
the 2005 flight, and the flight computer worked perfectly. If we
suffer from another rocket crash because we over-engineered the rocket
and didn't take time to test the basics, then it's worse than if our
simple rocket failed.
> -----Original Message-----
> From: psas-avionics-boun...@lists.psas.pdx.edu
> [mailto:psas-avionics-boun...@lists.psas.pdx.edu] On Behalf Of Sarah A
> Sent: Sunday, February 01, 2009 1:01 PM
> To: Dave Camarillo
> Cc: psas-avionics; Andrew Greenberg
> Subject: Re: [psas-avionics] CAN on the MPC5200 FC: T-3 weeks until a
> 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?"
> If the flight computer is down, the goal should be to get the rocket
> to the ground safely. I don't think there's much point in trying to
> use CAN to log data. Given the goal of a safe landing, what nodes
> *really* need to talk to each other?
> 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.
> On Sun, Feb 1, 2009 at 12:07 PM, Dave Camarillo
> <dave.camari...@gmail.com> wrote:
>> Hi All, it looks like Denx does have drivers for the CAN hardware on
>> the 5200. It appears to be a derivative work of Peak Systems
>> (http://www.peak-system.com) PCAN software. I skimmed the source code
>> and they have a driver that hooks the PCAN driver (they also support
>> devices such as the SJA1000 chip and a couple other products from
>> peak-system). The include in the source tree a command line app for
>> transmitting and receiving messages as well.
>> Based on skimming the source code and looking at the pcan web site it
>> appears to support 2.4 and 2.6 kernels, and the peak site indicates
>> that they support the PF_CAN (SocketCAN) stuff built into newer
>> I'm wondering, maybe Josh/Jamey could bring the flight computer on
>> tuesday and maybe we can play with this a little?
>> On Sun, Feb 1, 2009 at 5:58 AM, Andrew Greenberg <and...@psas.pdx.edu>
>>> We've looked a bit at our schedule for the capstone, and the decision
>>> between CAN and a UART backchannel really, really, really have to be
>>> made in the next three weeks.
>>> To even consider CAN as a backchannel, we have to have the MPC5200
>>> CAN on its native CAN peripheral. That means digging up Denx's
>>> CAN peripheral drivers and actually seeing them work, and testing
> them a
>>> We'll talk about this more on Tuesday, but I just wanted to warn
>>> software folks - I guess mostly Dan and Dave here - that we need to
>>> stuff, soon. We'll have the MPC5200 FC at the next meeting for you to
>>> play with, and I'll bring my CAN2USB adapter.
>>> 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 mailing list
> psas-avionics mailing list
psas-avionics mailing list