my 2 cents....

One key feature of CAN is the lack of a single point of failure (minus
a physical failure). In USB, you have the host controller. If it
fails, all communications stop. With CAN, if any node fails,
communications can continue among all remaining nodes. In reading I've
done in the past that discuss high-reliability aviation systems, the
designs have been such that no single point can take out the whole
system, and in many systems, the capability's of one component are
also available in another component such that when the system as a
whole notices the failure of the primary, the secondary can take over
the functionality. One of the thing it depends on though is a
communications mechanism where all devices on the communications
system can work with or without the other devices.

I'm in agreement that for large quantities of data transfer (large
quantities being our high sample rate sensor data streams) CAN is not
the best choice. But for controls, which need "high" speed, low
latency and high reliability, CAN is more appropriate for these
situations.

thoughts?

-dave

On Sun, Feb 1, 2009 at 9:42 PM,  <rq1...@q7.com> wrote:
> This is my understanding CAN vs USB,
>
> USB wins for bulk and high speed data transfer.
> USB wins for compatibility w/ standard hard/soft ware
>
> USB as a control bus
>  Minuses
>    Complex driver developed for a different application suite
>    Driver is often tweaked
>    Millisecond latencies
>    Hard latency bound is hard to come by
>    Interrupts from node to host are almost unsupported
>
> CAN wins for allowing daisy chaining
> CAN wins for electrical reliability
>
>
> (2009.02.01) saharabe...@gmail.com:
>> 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.
>
> _______________________________________________
> psas-avionics mailing list
> psas-avionics@lists.psas.pdx.edu
> http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
>

_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics

Reply via email to