Talk:MIL-STD-1553

Untitled
Thanks for adding the links -- red stucco 09:29, 1 December 2005 (UTC)

There has been some discussion as to WHAT European (Western), Russian and Chinese avionics buses look like. I was told informally that the Russians cloned the 1553. Information on Russian and Chinese stuff is scant! It would be good if readers could contribute to this area and provide a link to it.

Inconsistency
The last paragraph seems to imply that the bus is only (or primarily) used for fly-by-wire systems, but the rest of the article does not discuss this, and maybe contradicts it. What is right?

Bus controller paragraph is jumbled up
Could the author take a look and fix it up?

"Messages consists of one or more 16-bit words (command, data or status)...."

I believe this section needs to have some ambiguity removed.

The "message" consists of 20 bit times: three bit/clock times for sychronization and to indicate of the type of word contained in the data bit times (command, data, or status), followed by sixteen  bit/clock times for a 16 bit word, and finally a parity bit. The first three bit times are the only ones allowed to hold a constant voltage level for one and one half bit times. The voltage transition in the middle of the first three bit times (1½ clock clycles)starts the timing for self synchonization of the data bits at the receiving end. The direction of transition (low to high) or (high to low) indicates the type of word to follow (command, data, or status).

The remaining 17 bits are required to make a voltage transition within one bit/clock time. If there is a change in a data bit from one to zero (10) or vice versa (01), the transition between polarities happens in the middle of the bit time. If a one is followed by a one (11), or if a zero is followed by a zero (00), the transition happens at the biggining of the bit time.

The direction of the voltage transition (high to low or low to high) durring the last 17 bit times is a function of the current bit value and the preceeding bit. The initial voltage transition direction is a function of the last transition of the sychronization signal and the value of the first bit.

If the transmitted data stays all zeros (0000000000000000) or all ones (1111111111111111), the resulting signal durring the 16 bit/clock times will be a square wave that is the same frequency as the clock (a full cycle in each bit time). A data pattern of alternating ones and zeros (1010101010101010) or (0101010101010101) will produce a square wave one half the clock frequency.

The parity bit follows the same rules as the data bits.

This can be better understood by a carefull reading of MIL-STD-1553B or by seeing the diagram under Manchester line code[] here[]

207.5.226.145 01:59, 6 January 2007 (UTC) 207.5.226.145 02:13, 6 January 2007 (UTC) 207.5.226.145 00:37, 9 January 2007 (UTC)

new_user (5/15/12): If there is someone who manages this page, I would like to note that the block diagram of the BC and BM is a bit misleading. It would appear upon first glance that the BC acts different from an RT as it's block is at the end of the bus, instead of offset as is the RTs and BM. In fact the BC should look just like the other blocks OFF the bus, with arrows pointing towards the bus. Additionally, it could be enhanced by listing a BC, BBC, RT, RT..., BM. — Preceding unsigned comment added by 96.254.199.114 (talk) 13:57, 15 May 2012 (UTC)


 * I've replaced the offending image with Figure 1 from the standard, and ammended the text to suit. This article still needs loads of work, though. Graham.Fountain | Talk 10:37, 20 May 2012 (UTC)

1553C (1553B Notice 5)
Would like to see something on 1553C. —Preceding unsigned comment added by 192.91.173.36 (talk) 20:27, 17 July 2008 (UTC)

Conflict in Bus Protocol section
Refer to the following snipits from the Bus Protocol section:

Issue #1

...This means during the RT to RT transfer, communication is done via the Bus Controller. The data is first written into the buffer of the RT who initiates the communication (e.g. RT1). The Bus controller reads the data from the RT1 buffer and writes it into the destination RT buffer (RT2).

...and...

5. RT to RT Transfer. The Bus Controller sends out a Receive data command followed by a Transmit data command. The transmitting Terminal sends a Status Word followed by 1 to 32 data words to the Receiving RT. The receiving Terminal then sends its Status Word.

The first paragraph indicates that RTs can never talk directly to each other. The second section (#5) indicates that as long as the BC initiates the transfer between two RTs, the data is transferred directly from RT1 to RT2.

Which is it? — Preceding unsigned comment added by 98.233.45.116 (talk) 20:13, 30 September 2011 (UTC)


 * I have had a go at editing the page to clear up this issue.


 * Unfortunately, I haven't currently the time to do a proper job on this page, but there are a number of issues that still need to be addressed. Specifically, I think the section needs to be re-ordered: I'd start with BCs and RTs, etc.; then detail data, status, and command words; then detail transaction formats; and finally cover transaction scheduling - cyclics and acyclics, etc. Just before I looked at the RT to RT transfer issue, I did redo the list of transactions to be like the standard in sections 4.3.3.6.1 to 4.3.3.6.7.4, so the drawings from the standard (Figure 6 and Figure 7) will fit in. I think I'd loose the CSP like bits, in favour of the drawings from the standard - there's no copyright statement in the standard, and as a US doc, I take that to mean no copyright (and I'm sure I've some original artwork versions somewhere anyway). It might also be useful to include a full list of mode codes from section 4.3.3.5.1.7, and the table (Table 1) what says which have a data word and which can be broadcast, and a full list of the status bits from sections 4.3.3.5.3.3 to 4.3.3.5.3.11. Also, the use of capitals for Bus Controller, Remote Terminals, is certainly not consistent, and is probably well wrong in regard to proper noun usage (the 1553B standard itself should be used as the definitive source here, whatever anyone else might think). There are other issues, like the emphasis on polling, which doesn't reflect how this is done in the military avionic systems I know of. I've put a bit in on transaction schedules and invoking acyclics, but the polling stuff's still not right. However, when I might have time to do this is an issue. So if anyone else cares enough, do have a go. Graham.Fountain | Talk 14:35, 5 April 2012 (UTC)

Stanag 3910
as now http://en.wikipedia.org/wiki/STANAG_3910 redirect to MIL-STD-1553, suggesting this is the same as http://en.wikipedia.org/wiki/MIL-STD-1773#Physical_layer but the two optical standards are not the same. I.E. EfaBus/STANAG_3910 20 Mbps optical bus is different than MIL-STD-1773 Probably need a dedicated article like in .de Wiki: http://de.wikipedia.org/wiki/Stanag_3910 — Preceding unsigned comment added by Efa (talk • contribs) 09:08, 10 May 2012 (UTC)
 * How can we break the redirection?--Efa (talk) 09:58, 14 May 2012 (UTC)

I've added a footnote on STANAG 3910 as a start, but this is necessarily rather short. So I've also started a page on STANAG 3910 here. I started with a Google translation of the German WP page, but have already changed it a bit, though there are (as of 8 July 2013) no refs or pics. In the highly unlikely event there's any actual interest in this subject, please feel welcome to edit this page at will. Comments on the talk page will be gratefully accepted as well.

Note: I was UK representative (as chairman of BSI ACE-6/9 at the time) on C2 GT9, the AECMA committee that was trying to issue the EN3910 standard, so I've some background. However, much of what I know on the standardization process may not be referenceable - some of what I think (Serge and Dominique) may not even be printable. Graham.Fountain | Talk 14:03, 8 July 2013 (UTC)

I have put content on the STANAG 3910 page. It needs some figs, etc., and probably further edits. Graham.Fountain | Talk 11:08, 3 September 2013 (UTC)

Problem in Figure 6 for mode command with data word (receive)
In figure 6, the last transfer [mode command with data word (receive)] seems not correct. "Status word" and "Data word" are swapped.

The correct sequence should be:
 * Mode Command
 * Data Word
 * * * (Response time)
 * Status Word
 * # (Intermessage gap)
 * Next Command Word


 * I've now fixed the drawing and the adjacent text, which had the recieve and transmit descriptions swapped. Glad someone's reading this.Graham.Fountain | Talk 14:48, 15 April 2013 (UTC)

Thanks for the quick reaction. It seems that the figure shown in the article has still the problem. Looking at the figure history I see that the correct figure has been uploaded on 14:32, 15 April 2013, but it is not the one shown in the article. Is it only my problem? — Preceding unsigned comment added by 194.15.215.205 (talk)


 * Sorry, I've no idea what went wrong with that update process, but I seem to have managed to get there now.Graham.Fountain | Talk 10:45, 16 April 2013 (UTC)

In response to the notation on Figures 6 and 7, I've created the following two illustrations in Inkscape as SVG files and uploaded them for consideration:

These illustrations add color coding to distinguish the source for each word. They are SVG files that I created using Inkscape, and I'm sure others can improve on them. Filker0 (talk) 14:44, 14 August 2014 (UTC)


 * These do look to be improvments on what I did. The only problems I see with these are the rather large border and I would differentiate the src and dst status words by colours as well, but unfortunartly, I can't deal with SVG files on this machine.
 * Graham.Fountain | Talk 15:40, 14 August 2014 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 2 one external links on MIL-STD-1553. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive https://web.archive.org/20130313162407/http://www.saabgroup.com:80/en/Air/Gripen-Fighter-System/Gripen/Gripen/Technical-specifications/ to http://www.saabgroup.com/en/Air/Gripen-Fighter-System/Gripen/Gripen/Technical-specifications/
 * Added archive https://web.archive.org/20090206112407/http://assist.daps.dla.mil:80/quicksearch/basic_profile.cfm?ident_number=275874 to http://assist.daps.dla.mil/quicksearch/basic_profile.cfm?ident_number=275874

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers.—cyberbot II  Talk to my owner :Online 05:23, 10 January 2016 (UTC) - As I look today the link to http://assist.daps.dla.mil/ is listed as being a dead link. I suspect this web site/ link is not dead, just not dead to the general public. I think the link is still accessible if proper DOD related credentials are presented. Wfoj3 (talk) 00:29, 13 January 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 2 one external links on MIL-STD-1553. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive http://web.archive.org/web/20090206112407/http://assist.daps.dla.mil:80/quicksearch/basic_profile.cfm?ident_number=275874 to http://assist.daps.dla.mil/quicksearch/basic_profile.cfm?ident_number=275874
 * Added archive http://web.archive.org/web/20120205092101/http://assist.daps.dla.mil/quicksearch/basic_profile.cfm?ident_number=36973 to https://assist.daps.dla.mil/quicksearch/basic_profile.cfm?ident_number=36973

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 00:46, 29 February 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on MIL-STD-1553. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive http://web.archive.org/web/20090206112407/http://assist.daps.dla.mil:80/quicksearch/basic_profile.cfm?ident_number=275874 to http://assist.daps.dla.mil/quicksearch/basic_profile.cfm?ident_number=275874

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.—cyberbot II  Talk to my owner :Online 02:30, 21 March 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on MIL-STD-1553. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20140714174407/http://www.adas.fr/cartes-digibusus.htm to http://www.adas.fr/cartes-digibusus.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 16:32, 10 January 2018 (UTC)