On 14 Jun 2004 08:56:27 -0700, (David Harper)
wrote:

"Simon Robbins" wrote in message ...
"David Harper" wrote in message
om...
Does the C-130 have two 1553 buses onboard? One for flight control
and one for EW/mission systems?

I don't think 1553 is used for flight control since the latency and speed
isn't sufficient. Mission systems may well use it though. I think by nature
1553 is dual-redundant so that's where you might get the idea of two from.
Not familiar with the C-130 personally though.

Si

Thanks for the info. So none of the flight controls interface with
the 1553 at all? I'm just now getting familiar with Mil-HDBK-516
(airworthiness criteria) for my new job and not sure if some of the
equipment we are installing on the 1553 bus would affect/cause latency
for flight control. From what you've said, apparently that's a
non-issue then...

First thing to think about is that it isn't a peer to peer networking
system like Ethernet ... it's tightly controlled by a Bus Controller.
The RT to RT (receiver transmitter) communication is handled through
command response. BC tells RT to transmit, RT needs a response from
the destination before it is sure that the message passed ok. The
latencies are reasonably strict ... The BCs can also be
multi-redundant. There's even scope for every RT to have BC
functionality (getting into gold-plate territory there).

On the flight controls - there will be data passing around the bus,
but I'd expect it to be measurement type information. IAS, Altitude,
pressure, Mach type information. I wouldn't want to see
joystick/throttle control data being passed around on 1553B. It's only
a 1MHz bus ... with performance that isn't 1Mbit/s. Just make sure
that the RTs are up to the job of buffering data.

I guess on a non-related note, how exactly does equipment on the 1553
bus manage communications to prevent them from overlapping / "stepping
on" each other? Is there something in the data sentence once a unit
begins transmitting that puts all other equipment on "hold" until it
is done sending data? Wouldn't there be interrupts needed for
critical equipment to override less critical sentences?

RTs will only transmit on a command from the Bus Controller. Each RT
has a unique ID on the network, so transmit commands are only actioned
by one RT. The transmission is done with a command - response -
senddata - response protocol that makes sure that something will
happen on command. After the end of a data transmission sequence, a
status word must be sent back to acknowledge receipt. All the bits
should be anticipating that status bit. (or they are non-compliant).

For contrast, the Ethernet protocol works on the Aloha principle.
Anything on the network can transmit at any time, collisions are
detected instead of being prevented. For a time critical bus, the
1553B command-response protocol works much better.

Unfortunately my knowledge has eroded a fair bit ... I produced a
generic model of 1553B about 6 years ago on a 3 month placement but
have only touched it once since (conditions of the placement mean I
don't own the model). I've also dropped out of contact (about 6 years
ago!) with the people I did the model for. The model is out there
though and if you have the right to see it :-) then you should be able
to track down the people in control of the model. Alternately, the
MIL-STD-1553B handbook is pretty decent, when you break into the
mindset required to read it. Just try to decode the order in which it
does things and how it does its stuff.

PS This placement is where I helped the local team in the organisation
win the cricket trophy for that year :-) I had fun in that 3 months.
Produced something of use ... and won a trophy :-)

Pete Lilleyman

(please get rid of ".getrid" to reply direct)
(don't get rid of the dontspam though ;-)