Jump to content

MIL-STD-1553 bus


crelf

Recommended Posts

What are you trying to do with this device?

You're so nosy! (and I like it :D ) 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...

Link to comment

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

Link to comment

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.

Link to comment
You're so nosy! (and I like it :D ) 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

Link to comment

: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 :)

Link to comment
: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

Link to comment
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.

Link to comment

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.

Link to comment
  • 3 years later...

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.

Link to comment

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:

Link to comment

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?

Link to comment

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.

Link to comment

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.

Link to comment
  • 3 months later...

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.. rolleyes.gif

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

Link to comment
  • 3 weeks later...

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

Link to comment
  • 4 months later...

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? :P

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 by paloncho
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.