MIL-STD-1553 bus

[crelf]

Hi All,

Has anyone worked with the MIL-STD-1553 bus before? Specifically, is it possible/practical to convert between 1553 and RS-232, or between 1553 and Ethernet?

[Michael Aivaliotis]

Hi All,

Has anyone worked with the MIL-STD-1553 bus before? Specifically, is it possible/practical to convert between 1553 and RS-232, or between 1553 and Ethernet?

What would be the benefit? Why not just buy a card or some other PC hardware that talks 1553? What are you trying to do with this device? Test it?

[crelf]

What are you trying to do with this device?

You're so nosy! (and I like it ) I have an application that would mostly be excellent for the NI CVS except that I might need to do 1553 as well (I'm pushing for 422 as it might be an option). The application has very strict space and mass requirements so netwroking out to a PC who's function is just to talk 1553 isn't an option. That said, maybe we can go out to a PC-104 implementation...

[TerryS]

A 1553 card is pretty expensive; ranges anywhere from $3k to $15k (USD).

We used a Condor (GE Fanuc) card on a project and it was not too difficult to use; it came with LV drivers. There are plenty of other companies. Could you please provide more information on what you mean by converting?

See these links/docs for more information:

http://www.condoreng.com/about/lit/index.shtml#other

and specifically:

http://www.condoreng.com/about/lit/pdfdata...cture_Guide.pdf

[Michael Aivaliotis]

TERRY?!! Ti kanies megale? How are you? Long time no hear. Are you gonna be at NIWeek this year?

[Nico]

Hi,

I'm also using a Condor PXI 1553 card. It costs around 8k$. Stubs, cables and accessories are expensive too. LV driver is not very hard to use and LV real time support is available.

I don't think that is possible to convert 1553 from or to another protocol. It's a complex protocol with lot of handshaking, time checking, error handling...

If you have more accurate question, I will try to answer.

[peteski]

You're so nosy! (and I like it ) I have an application that would mostly be excellent for the NI CVS except that I might need to do 1553 as well (I'm pushing for 422 as it might be an option). The application has very strict space and mass requirements so netwroking out to a PC who's function is just to talk 1553 isn't an option. That said, maybe we can go out to a PC-104 implementation...

Crelf,

If you have the option, RS422 would be MUCH cheaper and easier. 1553 has a whole host of considerations, and as others have said here, the hardware is expensive. Now, that being said, it is a very robust interface designed to work no matter what. If you are designing for a system that must deal with a lot of RF interference and/or a rough and tumble environment, 1553 was designed with all of that in mind.

For what its worth, I worked on a test setup for ground testing of an instrument that is presently in low earth orbit. The actual instrument itself used 1553 for its housekeeping data and RS422 for its science data. Over the last 3+ years in orbit, I don't think we have seen any significant problems with either interface as far as data integrity.

If you are required to use 1553, I don't see why you couldn't take the data gathered by the 1553 card (do you know whether your role would be as Bus Controller, Remote Terminal, or Bus Monitor?) and

[crelf]

:thumbup: Thanks for all the info folks - once again, the breadth of knowledge here on LAVA has made it well worth the miniscule premium subscription price! Terry - thanks especially to you for the links to the comprehensive 1553 resources.

It's just as I'd thought - I'll be pushing our client toward 422. Unfortunately, as we need to use the CVS, there isn't any practical way to do 1553 coms (unless we write our own FPGA driver and download it into the CVS's FPGA, but there's only half a million gates to play with there, and I figure that 1553 would be more comprehensive than that). Thanks again for a little clarity

[peteski]

:thumbup: Thanks for all the info folks - once again, the breadth of knowledge here on LAVA has made it well worth the miniscule premium subscription price! Terry - thanks especially to you for the links to the comprehensive 1553 resources.

It's just as I'd thought - I'll be pushing our client toward 422. Unfortunately, as we need to use the CVS, there isn't any practical way to do 1553 coms (unless we write our own FPGA driver and download it into the CVS's FPGA, but there's only half a million gates to play with there, and I figure that 1553 would be more comprehensive than that). Thanks again for a little clarity

Crelf,

Yeah, if a 1553 implementation had to share space with the CVS control on an FPGA, it could be rather painful. Doing 1553 like this would probably be a huge time sink, which is probably part of the reason the available vendor solutions tend to be so expensive. What little I know about 1553 tells me enough that I would not want to have to build something to do it from scratch!

-Pete Liiva

[crelf]

Yeah, if a 1553 implementation had to share space with the CVS control on an FPGA, it could be rather painful. Doing 1553 like this would probably be a huge time sink, which is probably part of the reason the available vendor solutions tend to be so expensive. What little I know about 1553 tells me enough that I would not want to have to build something to do it from scratch!

Thanks Pete - I figured as much. Implementing a more simple comms protocol in FPGA might be less frightening, but I totally agree with the time skink comment - trying to get 1553 into FPGA could take up half of the project, and I don't think it's worth it.

[TerryS]

I too would advise against implementing your own 1553!!!! (think 1.21 gigawatts in 1955) It is a tough call to build what you can buy. Also, Condor is not the only company; see NI's site for some of the other companies that make 1553 cards.

The higher cost 1553 cards are for testing your code and running various simulations. A production card is in the lower end and will cover most applications.

Also, I think the high cost of the cards may be that there is a lower sales volume compared to say the run of the mill serial buses that we more commonly use.

Also, glad to help; I have gotten a lot out of reading these forums and from the OpenG stuff; feels good to reciprocate.

[udai]

I have a problem regarding the working of MIL1553B...

how do i check, the data that is coming from some RT to BC is a fresh data or the same old data that i received earlier.

please do reply.. this is urgent.

[Dan DeFriese]

QUOTE (udai @ May 27 2009, 07:32 AM)

I have a problem regarding the working of MIL1553B...

how do i check, the data that is coming from some RT to BC is a fresh data or the same old data that i received earlier.

please do reply.. this is urgent.

Assuming that you've purchased a COTS board from Condor, AIM, DDC or whatever. You should be able to check an IRIG time-tag when poping messages off the receive FIFO. Check your manual for details.

[udai]

QUOTE (Dan DeFriese @ May 27 2009, 07:14 PM)

Assuming that you've purchased a COTS board from Condor, AIM, DDC or whatever. You should be able to check an IRIG time-tag when poping messages off the receive FIFO. Check your manual for details.

Thank you :thumbup: Dan DeFriese for suggesting this solution, I'm really to grateful to you.

But i was just curious to know that if there any other way to do it? :question:

[Dan DeFriese]

QUOTE (udai @ May 27 2009, 11:58 PM)

Thank you :thumbup: Dan DeFriese for suggesting this solution, I'm really to grateful to you.

But i was just curious to know that if there any other way to do it? :question:

I can't think of any "universal" ways to do this other than the time-tag. Some Driver APIs (AIM) may have bit in the receive data block that can be set during the read operation. What device are you using?

[udai]

QUOTE (Dan DeFriese @ May 29 2009, 08:30 PM)

I can't think of any "universal" ways to do this other than the time-tag. Some Driver APIs (AIM) may have bit in the receive data block that can be set during the read operation. What device are you using?

Thanks for the reply...

By looking at the time tag how come we'll come to know that this is the fresh data that is present in the Receive queue, as a blabbering RT will be sending the same data most of the time. By the way i am using the condor card.

[Dan DeFriese]

QUOTE (udai @ May 31 2009, 11:08 PM)

Thanks for the reply...

By looking at the time tag how come we'll come to know that this is the fresh data that is present in the Receive queue, as a blabbering RT will be sending the same data most of the time. By the way i am using the condor card.

A time-tag will only tell when the messages arrive at the test card. There's no way for your test software/equipment to know the "freshness" of the data being aquired and transmitted by the RT unless, of course, this information is encoded in the 1553 data stream.

[thezeek]

hi,

I have to make an RS232 to MIL STD 1553 converter using FPGA.. i m starting form the scratch and seriously have knw idea where to begin..

Can anyone help me out, plz???

[Dan DeFriese]

hi,

I have to make an RS232 to MIL STD 1553 converter using FPGA.. i m starting form the scratch and seriously have knw idea where to begin..

Can anyone help me out, plz???

Obviously, you'll need to read spec for MIL-STD-1553. Before that, however, you'll need to answer the questions:

1) How I'm I going to convert a 1Mbit/s interface to a 115kbit/s interface?

2) Why am I building a test interface when I could buy it? ... I'm making an assumption here that you're making test equipment since your're posting here. In any event, I assure you that you will not save $$$ doing this from scratch. 1553 is just a little less complex than ethernet.

Anyway, if you're unfamiler with 1553 you may want to check out the tutorials provided by DDC (Data Device Corparation) and GE FANUC.

http://www.ddc-web.com/Products/MIL-STD-1553/DesignersGuide.aspx

http://www.gefanuc.com/library/detail/11743

Sital sells IP Cores for 1553, if your're interested.

http://www.aerospace-technology.com/contractors/electronic/sital/

FWIW

~Dan

[thezeek]

Obviously, you'll need to read spec for MIL-STD-1553. Before that, however, you'll need to answer the questions:

1) How I'm I going to convert a 1Mbit/s interface to a 115kbit/s interface?

2) Why am I building a test interface when I could buy it? ... I'm making an assumption here that you're making test equipment since your're posting here. In any event, I assure you that you will not save $$$ doing this from scratch. 1553 is just a little less complex than ethernet.

Thankyou Dan.

I guess there are some onboard buffers available or i can use the memory available on the fpga kit which i wud be using.

Plus, i will not be using this sytem for any practical platform. you r right in the assumption that it wud be a test interface. It is for learning purposes and i m doing it as my semester project.

If there is a Verilog code already available for this utility, i can really use it for the understanding.

I m looking for some strings to start off with. It wud be really helpful if u could guide me.. i will definitely go through the links u provided and reply to u wat i cud extract from them.

Thatnks Again

[paloncho]

Hello Guys,

I am a little bit stucked with my final project at the university.

I chose to make a RS422/ MIL-STD 1553 converter on vhdl lenguage. I'm not gonna make the circuit implementation, just to make a simulation on vhdl and show that it's possible to communicate both protocols (well, if we can name RS422 as protocol, I'd name it an standard). We're using intel uC 8051 embedded into vhdl (I found all 8051 functional blocks programmed in vhdl). So, to summarize, "uC 8051" is gonna be the converter between 422 and 1553, ok?

vhdl programming was going to be very rough, so I decided to go some levels up.... I'm using keil uVision3: I'm programing BC and RT functions in C, then keil gives me assembler codes and the idea is to convert that code to get binary code (a colleague has a tool that does that).

This binary code is going to be insert into RAM module of 8051 vhdl code to try this "simulated" uC 8051 make the protocol convertion.

I have C code working ok..... I mean, it builds and unbuilds 1553 protocol well. I'm not really complaining about RS422.... I'm just gonna put 8 bits each time on a RS422 port and send them. As where I know, RS422 has an UART port that "packages" 8 bits with an start and stop bit. So, there is no protocol in fact... Am I wrong?

My HUGE question is..... Do you thing it's gonna be possible that vhdl code does the same that I obtain with C code (after making the 2 translations I mencioned before)? I mean, build and unbuild 1553 protocol doing these steps?

Do you think this is so crazy?

I'll wait for your answer...... If you don't get anything, please let me know, I'll try to be more specific.

Thanks a lot for your help and time.

BR,

Pablo.-

Obviously, you'll need to read spec for MIL-STD-1553. Before that, however, you'll need to answer the questions:

1) How I'm I going to convert a 1Mbit/s interface to a 115kbit/s interface?

2) Why am I building a test interface when I could buy it? ... I'm making an assumption here that you're making test equipment since your're posting here. In any event, I assure you that you will not save $ doing this from scratch. 1553 is just a little less complex than ethernet.

Anyway, if you're unfamiler with 1553 you may want to check out the tutorials provided by DDC (Data Device Corparation) and GE FANUC.

http://www.ddc-web.c...gnersGuide.aspx

http://www.gefanuc.c...ry/detail/11743

Sital sells IP Cores for 1553, if your're interested.

http://www.aerospace...ectronic/sital/

FWIW

~Dan

Edited February 19, 2010 by paloncho