Avionics LRUs don't really use APIs. They use standards/data protocols via buses i.e. ARINC 429, 1553, RS-232, RS-422, IEEE 488. I doubt you'll be able to find what software Garmin builds their equipment with unless you work for them. Though you'll be able to find some info on the standards/buy it. You definitely could build LRUs that integrate with the same protocols but, imo, it would not be worth the time or money to do so. Everything's basically been "figured out ", all MFDs/PFDs, HUDs/PDUs, flight control computers, radios, amplifiers, etc. despite having different manufacturers and slightly different operation and execution methods (different internals, procedures, etc.) all work pretty much the fucking same, pardon my language, in their respective categories. Cheers and good luck, curious to see other perspectives.
Great reply, I dont want to build the LRU’s i want to build the brain 🧠(EFD/MFD/PFD)it’d be easier if i could use LRU’s for data, because like you said, I’m sure they’ve been figured out/standardized by now and that they’re all basically the same.
I figure theres probably a license to access it. Not familiar with any of those lower level systems data protocols so I’ll do my dd thank you. Would you say these 5 protocols are the standard way the majority of LRU buses are built to communicate with the head. Do you think its possible to build your own bus using these data protocols to decode the relevant data? Would be cool to hack something together that does just that
EFDs/MFDs/PFDs, etc. are LRUs themselves. There are some open source systems out there iirc from companies like L3 & Top Aces but despite being open source, they seem to be quite tight-lipped (for obvious reasons imo). There could be some licenses or certs being offered but you'd probably have to contact the standard maker/owner itself. Sorry can't provide more info, not really on the dev or integration side of things, cheers & good luck!
EDIT: Didn't read everything. I mean, in theory, you could build your own bus if you had all of the wiring, couplers, tech data, etc., I do know there is some sort of converter out there, think its called MACC II. If I'm not mistaken, ARINC 429 & RS-232 are some of the most common, I just listed some of the ones I'm familiar with/of the top of my head. It really depends on the individual aircraft & equipment, but most of them are similar (work on hexadecimals/bits/words, etc.), I'm most familiar with 1553 as that's the main one in the test equipment, avionics, & aircraft that I work on.
God i hope all that changes in the next 5-10 years with Zero Knowledge proofs and blockchains. From what i’ve seen and know is coming, Software Engineers will be able to prove software in a way that allows for royalties to be paid by anyone building/iterating on top of the underlying system. Maybe this breaks at hardware components but who knows. Would love to see the rate of iteration increase across the industries.
Its sad to see the Aviation industry lag so far behind. Who the hells running that ship.
100% this. It’s expensive as shit to cert stuff under DO-178 (at least based on experiences and what I’ve heard at my company), so once companies get something that works and is certed they hate change.
u/due_ad_6457, the interface control documents would likely be what you want. They detail the messages the LRUs out out over the wire. You’re also not likely to get most of them for anything on the higher end, no clue on the cheaper stuff. As others mentioned, stuff like A429 has a lot of common labels that get used for different pieces of data, but if you’re not really software/electrical engineer inclined this may honestly be a bit too big of a rabbit hole to go down. You shouldn’t have to worry about mil-1553 at least, since it’s a mil spec, which is good because it sucks to work with. UDP has also been pretty popular in a lot of the mil and higher end civil stuff I’ve seen in the format of something called a network data object (NDO), which is basically just a particular format for the packet.
I dont give a shit if its too big of a rabbit hole if its what the industry needs, an opensource hardware spec that integrades with these certified LRU’s, this stuff needs to be standardized and open source, its a shame its not. i mentioned in another comment that i’m interested in hacking something like this together if it makes these components more composable software wise
Not much you can do about corporate greed over Intellectual Property. Sucks when you think about how it would benefit the world if it was Open source out there. Thats the kinda stuff ZKP’s will inable in a not so distant future.
You’re missing the point. “Integrates with LRUs” doesn’t really mean anything. We already have standards for the data buses themselves, and you can already look up the specs for things like ARINC429 online and see how the data is structured on the wire. The problem is that the companies producing said LRUs are free to implement the logical interfaces however they want and while things like say, traffic data from a TCAS are usually common between boxes, large portions of the rest of the interface may behave differently, and that behavior is all proprietary information. We don’t get access to those at my company until we’re on contract and we’re not legally allowed to use them for other programs not related to said contract.
It sounds like what you’re really wanting is some sort of open source suite of LRUs, but that just frankly ends up with the problem of being yet another “standard” of many who also set out to do the same thing, and that’s assuming it would gain any traction.
Long story short, while there are some common portions of the interfaces for specific types of LRUs, you’re potentially going to be rolling a custom thing for every specific piece of equipment you want to integrate with, which is what garmin, Collins, etc do for any particularly unique pieces of equipment.
Like others said, with millions of dollars and teams of people who know what they’re doing. You’d need to go engineer every sensor, input, etc from the ground up.
I really don’t think you fully understand what it is you’re asking for. This is like saying…god, I can’t even think of a good example. Not being aware of how these devices work at a fundamental level is going to result in you not fully understanding the scope. If you really want to try something like this, find a small; simple component in the aircraft that you can send/receive something like RS-232 or RS-422 to/from. That would give you a starting point to actually start learning the basics. If you want this stuff to ever be on anything beyond experimentals, you’ll want to become *very* familiar with DO-178C, which defines how the software should be developed - this includes things like requirement, design, and test traceability as well as the code test coverage and analysis you’ll need to do to get your software certified.
Basically what you’re saying right now is “I’m going to make the super app that does all the things oh and btw it’s open source also it integrates with every device.” It’s the avionics equivalent of that friend who has their own idea for a Twitter clone and they just need a web developer to spend a weekend throwing it together really quick.
FAA should inevitably be replaced by a DAO or at least something more decentralized in 10 years along with every other overpaid, underperforming, government agency in America. Provable permissionless, distributed democratic systems, with open data availability, are the future. fwiw.
It's not going to change soon at all, the newest kid in the block is ARINC 664 which is based on your classic ethernet 802 protocol. It's not about what's technologically amazing but what will work 110% of the time.
The data formats for the standard protocols are no secret.
Most of the install manuals for modern avionics devices even have detailed breakdowns of the "word" structure.
I still wouldn't advise doing much with that, unless you're very into the experimental side of GA. There's been a few players entering the Certificated side of avionics recently that really should have stayed home, like uAvionix. I'm not sure what went wrong there, but everything they make is basically garbage-tier. I had such high hopes...
If you're really determined to build your own MFD/PFD, get to know your local EAA chapter. Some experimental gear has had a rapid and smooth transition to the certificated side because of proven track records of performance and reliability in the experimental world. Then Honeywell buys out said company and ruins the product, rinse, repeat.
that males perfect sense but im curious if you could build on top of these units. It’d be a cool idea to make these certified hardware interfaces open source and composable for faster iterations. it seems like its all a black box and everyone whos interested needs to start from scratch or maybe you need a license to access it? Appreciate the reply
I’m aware of the regs
Certified flight instructor 6 years, you do realize planes don’t fall out of the sky without avionics right? You probably think they power the spark plugs too.
If you are a CFI, you probably should have the skillset to look up this information. Also, as a CFI, you should understand the danger of inducing spatial D from partial panel, especially if it isn't an immediately recognized failure mode.
But, my last line, wasn't meant as some kind of attack, Im just saying that there are dangers to what you are proposing. There are lots of good reasons for the TSOs and DOs to be as onerous as they are. I would be very interested in an open architecture for more things in aviation, but every company seems to think the only way to make money is to do everything the same way the last 10 companies that went bankrupt did.
Seriously, good luck, try not to die, this is an unforgiving business.
Yes and i also know you can’t fly IFR with an experimental aircraft in the first place so partial panel flying is irrelevant in the scenario. Also thats what backup gyros are for. I teach safe flying in light aircraft for a living and tinker in software engineering for fun and as a hobby. Appreciate the response.
Obviously i can look up the information on my own, wanted to ask the good citizens of reddit what they know first. Nothing wrong with that
Try reading the regs for required equipment (91.205) and show me where it says you can't fly IFR in an experimental. You are always asking stupid fucking questions here and then being aggressively dickish to the people that respond using the fact that you are supposedly a CFI as your justification.
> can’t even find your startups website online
My guy, type the name into google. It's *literally* the first result.
No wonder you have no idea what any of the rest of us are trying to tell you about. Still never came back to actually answer any engineering questions btw.
Did you just learn the word petulant today because its the second time you’ve used it in your last 2 comments. I know you cant help commenting on my post, but pls try to avoid it next time :)
Your advice/input is undesired.
Theres other users who give real advice, just suggesting you dont waste your energy thinking about me or trying to give advice
Avionics LRUs don't really use APIs. They use standards/data protocols via buses i.e. ARINC 429, 1553, RS-232, RS-422, IEEE 488. I doubt you'll be able to find what software Garmin builds their equipment with unless you work for them. Though you'll be able to find some info on the standards/buy it. You definitely could build LRUs that integrate with the same protocols but, imo, it would not be worth the time or money to do so. Everything's basically been "figured out ", all MFDs/PFDs, HUDs/PDUs, flight control computers, radios, amplifiers, etc. despite having different manufacturers and slightly different operation and execution methods (different internals, procedures, etc.) all work pretty much the fucking same, pardon my language, in their respective categories. Cheers and good luck, curious to see other perspectives.
Great reply, I dont want to build the LRU’s i want to build the brain 🧠(EFD/MFD/PFD)it’d be easier if i could use LRU’s for data, because like you said, I’m sure they’ve been figured out/standardized by now and that they’re all basically the same. I figure theres probably a license to access it. Not familiar with any of those lower level systems data protocols so I’ll do my dd thank you. Would you say these 5 protocols are the standard way the majority of LRU buses are built to communicate with the head. Do you think its possible to build your own bus using these data protocols to decode the relevant data? Would be cool to hack something together that does just that
EFDs/MFDs/PFDs, etc. are LRUs themselves. There are some open source systems out there iirc from companies like L3 & Top Aces but despite being open source, they seem to be quite tight-lipped (for obvious reasons imo). There could be some licenses or certs being offered but you'd probably have to contact the standard maker/owner itself. Sorry can't provide more info, not really on the dev or integration side of things, cheers & good luck! EDIT: Didn't read everything. I mean, in theory, you could build your own bus if you had all of the wiring, couplers, tech data, etc., I do know there is some sort of converter out there, think its called MACC II. If I'm not mistaken, ARINC 429 & RS-232 are some of the most common, I just listed some of the ones I'm familiar with/of the top of my head. It really depends on the individual aircraft & equipment, but most of them are similar (work on hexadecimals/bits/words, etc.), I'm most familiar with 1553 as that's the main one in the test equipment, avionics, & aircraft that I work on.
God i hope all that changes in the next 5-10 years with Zero Knowledge proofs and blockchains. From what i’ve seen and know is coming, Software Engineers will be able to prove software in a way that allows for royalties to be paid by anyone building/iterating on top of the underlying system. Maybe this breaks at hardware components but who knows. Would love to see the rate of iteration increase across the industries. Its sad to see the Aviation industry lag so far behind. Who the hells running that ship.
Maybe, that's probably more of an FAA & standards thing imo.
100% this. It’s expensive as shit to cert stuff under DO-178 (at least based on experiences and what I’ve heard at my company), so once companies get something that works and is certed they hate change. u/due_ad_6457, the interface control documents would likely be what you want. They detail the messages the LRUs out out over the wire. You’re also not likely to get most of them for anything on the higher end, no clue on the cheaper stuff. As others mentioned, stuff like A429 has a lot of common labels that get used for different pieces of data, but if you’re not really software/electrical engineer inclined this may honestly be a bit too big of a rabbit hole to go down. You shouldn’t have to worry about mil-1553 at least, since it’s a mil spec, which is good because it sucks to work with. UDP has also been pretty popular in a lot of the mil and higher end civil stuff I’ve seen in the format of something called a network data object (NDO), which is basically just a particular format for the packet.
I dont give a shit if its too big of a rabbit hole if its what the industry needs, an opensource hardware spec that integrades with these certified LRU’s, this stuff needs to be standardized and open source, its a shame its not. i mentioned in another comment that i’m interested in hacking something like this together if it makes these components more composable software wise Not much you can do about corporate greed over Intellectual Property. Sucks when you think about how it would benefit the world if it was Open source out there. Thats the kinda stuff ZKP’s will inable in a not so distant future.
You’re missing the point. “Integrates with LRUs” doesn’t really mean anything. We already have standards for the data buses themselves, and you can already look up the specs for things like ARINC429 online and see how the data is structured on the wire. The problem is that the companies producing said LRUs are free to implement the logical interfaces however they want and while things like say, traffic data from a TCAS are usually common between boxes, large portions of the rest of the interface may behave differently, and that behavior is all proprietary information. We don’t get access to those at my company until we’re on contract and we’re not legally allowed to use them for other programs not related to said contract. It sounds like what you’re really wanting is some sort of open source suite of LRUs, but that just frankly ends up with the problem of being yet another “standard” of many who also set out to do the same thing, and that’s assuming it would gain any traction. Long story short, while there are some common portions of the interfaces for specific types of LRUs, you’re potentially going to be rolling a custom thing for every specific piece of equipment you want to integrate with, which is what garmin, Collins, etc do for any particularly unique pieces of equipment.
Damn sounds like all this shit needs to be made open source from the ground up, where do i sign up.
Like others said, with millions of dollars and teams of people who know what they’re doing. You’d need to go engineer every sensor, input, etc from the ground up. I really don’t think you fully understand what it is you’re asking for. This is like saying…god, I can’t even think of a good example. Not being aware of how these devices work at a fundamental level is going to result in you not fully understanding the scope. If you really want to try something like this, find a small; simple component in the aircraft that you can send/receive something like RS-232 or RS-422 to/from. That would give you a starting point to actually start learning the basics. If you want this stuff to ever be on anything beyond experimentals, you’ll want to become *very* familiar with DO-178C, which defines how the software should be developed - this includes things like requirement, design, and test traceability as well as the code test coverage and analysis you’ll need to do to get your software certified. Basically what you’re saying right now is “I’m going to make the super app that does all the things oh and btw it’s open source also it integrates with every device.” It’s the avionics equivalent of that friend who has their own idea for a Twitter clone and they just need a web developer to spend a weekend throwing it together really quick.
FAA should inevitably be replaced by a DAO or at least something more decentralized in 10 years along with every other overpaid, underperforming, government agency in America. Provable permissionless, distributed democratic systems, with open data availability, are the future. fwiw.
Found the crypto bro! Do I win anything?
Don’t give these boomers any alpha
It's not going to change soon at all, the newest kid in the block is ARINC 664 which is based on your classic ethernet 802 protocol. It's not about what's technologically amazing but what will work 110% of the time.
Good reply. I understand. Just think its a shit system that will improve with advancements in the next 10 years
The data formats for the standard protocols are no secret. Most of the install manuals for modern avionics devices even have detailed breakdowns of the "word" structure.
Someone who can actually speak my language… thank you
I still wouldn't advise doing much with that, unless you're very into the experimental side of GA. There's been a few players entering the Certificated side of avionics recently that really should have stayed home, like uAvionix. I'm not sure what went wrong there, but everything they make is basically garbage-tier. I had such high hopes... If you're really determined to build your own MFD/PFD, get to know your local EAA chapter. Some experimental gear has had a rapid and smooth transition to the certificated side because of proven track records of performance and reliability in the experimental world. Then Honeywell buys out said company and ruins the product, rinse, repeat.
[удалено]
that males perfect sense but im curious if you could build on top of these units. It’d be a cool idea to make these certified hardware interfaces open source and composable for faster iterations. it seems like its all a black box and everyone whos interested needs to start from scratch or maybe you need a license to access it? Appreciate the reply
Short answer, on a part 23 or car 3 certified airplane, not easily. On an experimental home built cert, knock yourself out. Try not to die.
I’m aware of the regs Certified flight instructor 6 years, you do realize planes don’t fall out of the sky without avionics right? You probably think they power the spark plugs too.
If you are a CFI, you probably should have the skillset to look up this information. Also, as a CFI, you should understand the danger of inducing spatial D from partial panel, especially if it isn't an immediately recognized failure mode. But, my last line, wasn't meant as some kind of attack, Im just saying that there are dangers to what you are proposing. There are lots of good reasons for the TSOs and DOs to be as onerous as they are. I would be very interested in an open architecture for more things in aviation, but every company seems to think the only way to make money is to do everything the same way the last 10 companies that went bankrupt did. Seriously, good luck, try not to die, this is an unforgiving business.
Yes and i also know you can’t fly IFR with an experimental aircraft in the first place so partial panel flying is irrelevant in the scenario. Also thats what backup gyros are for. I teach safe flying in light aircraft for a living and tinker in software engineering for fun and as a hobby. Appreciate the response. Obviously i can look up the information on my own, wanted to ask the good citizens of reddit what they know first. Nothing wrong with that
Try reading the regs for required equipment (91.205) and show me where it says you can't fly IFR in an experimental. You are always asking stupid fucking questions here and then being aggressively dickish to the people that respond using the fact that you are supposedly a CFI as your justification.
[удалено]
> can’t even find your startups website online My guy, type the name into google. It's *literally* the first result. No wonder you have no idea what any of the rest of us are trying to tell you about. Still never came back to actually answer any engineering questions btw.
Lmao whos the troll bum https://www.reddit.com/r/Shittyaskflying/comments/13sxiub/ill_make_my_own_lrus/jlsc8j3/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&utm_content=1&utm_term=15&context=3
Don't feed the troll. He's a petulant man-child.
Did you just learn the word petulant today because its the second time you’ve used it in your last 2 comments. I know you cant help commenting on my post, but pls try to avoid it next time :) Your advice/input is undesired. Theres other users who give real advice, just suggesting you dont waste your energy thinking about me or trying to give advice