What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Docs on wire protocols?

sbalmos

sbalmos

Well Known Member
I have to say, the article in May's Experimenter by Bill about rolling your own glass panel has to be one of the more interesting articles I've read. Being a software guy myself, and a bit of a wire protocol wonk, I immediately started to think "how/where the heck did he get all the protocol data to interface to the outside systems?".

That's the basic question. I know I've read here about various data words (not) being in data streams, talking to a 430W, ADS-B In box, etc. But are there protocol documents somewhere that a curious outside engineer could look at? What incantations should I be submitting to the Google gods to uncover this info? Thanks!
 
i'll have to read that experimenter article yet...

a few protocol basics of what i learned/figured out over the years so far...


ARINC-429
http://en.wikipedia.org/wiki/ARINC_429

ARINC-429 is an aviation version of RS-485 along with message sets specific to aviation. lots of certified avionics "talk" over it, as well as experimental avionics wanting to interface with them.
the standard is commercially available and stems from the beginning of the digital age, the first document has "floppy disk" in the title ;-)
standards can be bought here:
https://www.arinc.com/cf/store/catalog.cfm?prod_group_id=1&category_group_id=1

unfortunately, the whole set of 429 standards is prohibitively expensive for any non-commercial/private purpose. maybe doug could approach ARINC to sponsor the community somewhat ;-)
also, dedicated 429 hardware interfaces/ICs seem to be just as expensive and rare, that's why most experimental implementations are throwing nowadays cheap processing power with some software emulation at the problem instead...
the good thing about arinc429 is that it covers almost any imaginable application from weather radars to autopilots.
unfortunately, there appears little to no open source documentation and google will not turn up much useful stuff either. no sample logs, no reverse engineering etc...
but the good news is, arinc429 is about as advanced as you need to get at the moment (rs-485 serial, is inherently quite simple if you know the data formats etc... no complicated protocol stacks and layers really.).
more advanced technologies like CAN bus etc... are only starting to appear and within closed ecosystems, IIRC garmin g3x is using some CAN bus setup within their platform, dynon is rolling their own 2-wire DSAB in their platform, all only internally. Advanced flight systems uses ethernet to share all data among screens, but again only within it's own perimeters.



most other common interfaces are using RS-232 uni- or bidirectional communication, mostly at 9600,8,n,1 with different message sets.
likely of most interest are the messages related to GPS.
there are two formats, NMEA0183 and Garmin Aviation.

NMEA0183
http://en.wikipedia.org/wiki/NMEA_0183
comes from the marine world, covers everything gps and some steering but limited to 2D mostly. almost all cheap/affordable gps bugs/chips, even the usb ones in one way or another end up delivering this format.
in contrast to arinc429, you will find lots of documentation, reverse engineering, sample datalogs etc... on the internet without having to buy the standards documents. also, quite a few tools, utilities and libraries are available to work with data, generate sample data etc...
one specialty is that there is a provision for manufacturer "proprietary" messages. Garmin as a big player obviously managed to establish some of it's proprietary messages as de facto standards. it's in the details, standard NMEA starts with
Code: 
$GP...
while garmin proprietary are
Code: 
$PG...
.
some interesting and openly available documentation from garmin:
https://www8.garmin.com/support/commProtocol.html
https://www8.garmin.com/support/pdf/NMEA_0183.pdf


Garmin "Aviation" serial
Garmin Aviation is a format that lies somewhere between NMEA0183 and ARINC429 and very little documentation can be found openly (probably needs NDA etc.. with garmin?!). it's transmitted through rs232 but i believe may contain binary data and not just ascii cleartext and run at higher speeds. most notably the message sets are much improved over NMEA, allowing e.g. for transmission of multi leg flightplans.
as said, documentation is very sparse. its roots seem to lie in the old appollo -> upsat -> garmin ancestry and some install manuals from e.g. the Apollo GX50/GX55/GX60/GX65 that google can dig up in the depths of the web do contain at least a starting point regarding the format. Unfortunately, the newer the units, the less technical information is in the documentation (garmin documentation being particularly poor on the technical side and more of brochure/user manual quality, sorry.)


that should cover about 90% of a "roll your own panel" need...
google glass implementation comes to mind, as has been discussed on another thread....

more to follow...

have fun hacking away!
regards, bernie

p.s. i truly feel this info should openly be out there for the benefit of all, as more great stuff could be developed.
 
Last edited:
some more data formats:

Vertical Power
a very good example of how things should be! no wonder, the company has made serious inroads in the market with excellent products (and so far great reputation, i can vouch for our case!).
Everything needed to interface to the current model electronic circuit breaker system is here:
http://www.verticalpower.com/vpx/devkit/

just for reference, here's an excerpt from the what Advanced Flight Systems EFIS currently supports as serial in/outputs:

Ext. AHRS External AHRS input
Format unknown, maybe proprietary, maybe crossbow AHRS? http://www.moog-crossbow.com/ in typical aviation fashion has nothing publicly available...

NMEA @ 4800 External GPS with NMEA @ 4800 baud
Covered in the NMEA part in the other post.

TRFC Garmin Traffic
TRFC refers to the TIS-B traffic format as delivered by garmin transponders through RS232. some other ads-b in/flarm combined boxes offer an emulated TIS-B TRFC stream to deliver their data. google will come up with a GTX330 install manual, that has some more details on the ARINC and TIS config, however in typical garmin fashion no real documentation on the traffic data.

ICARUS Out
ICARUS is a format for serialized altitude information sent to transponders for the mode C/mode S altitude transmission. appears to be originally coming from a 3000 series altitude serializer made by www.icarusinstruments.com (yet another product that no longer seems in production, and as usual no documentation to be found)

SL-30 Garmin SL-30 radio connected
SL30 has an awesome serial interface for navigation data (localizer, vor, glideslope) as well as remote tuning. technically based on the NMEA format. as a positive, there is complete documentation of the features in the installation manual Appendix E:
http://www.aeroelectric.com/Installation_Data/SL30 Installation Manual.pdf
even though it's now garmin, i would bet the documentation is only in because it was developed by IImorrow / apollo / ups aviation technologies ;-)

ARINC AF-ARINC module connected to port
AFS uses their own ARINC429 connector box that handles all the ARINC429 stuff. it in turn is wired to the efis through a normal rs232 port running i suppose at as high a speed as possible. proprietary format and workings. does also contain some kind of bootloader/upgrade capabilities for firmware updates.

CHELTON Chelton Engine Data Out
a popular engine data format that quite a few systems adopted, coming from the former chelton flight systems efis which was one of the first full-featured top-of-the-range experimental efis systems. as seems the case for quite a few avionics companies, it changed hands a few times. now cobham.s-tec.whatever, and as usual no real free and public documentation. http://sharepoint.s-tec.com/default.aspx

AVTN/ARNAV 430W/530W or GPS with Aviation format
The garmin aviation format as expanded in the other post.

FADEC SBC-100 FADEC Data In
FADEC SBC-250 Do Not Use
Engine Data from the Aerosance FADEC for lycoming engines. Unfortunately things have become very quiet on that front/never took off... there is a yahoo groups community. no documentation apparent, however not really important either unfortunately.

OP TECH OP Engine Data Out
Another EFIS/Engine Monitor from a company that was/is called OP Technologies then Aerosonic... There was some chatter and grief at one time, spruce seems to still list their system between 20k$ and 34+k$! yet the aerosonic.com website does not enlighten much. and yes - you guessed it - certainly no documentation available ;-) ok, doesn't matter much in that case...

SHADIN ALT
Another altitude encoder output format for transponders/baro vnav etc....
congratulations shadin! there's actually something like documentation: http://www.shadin.com/service/manuals/OP8800TC.pdf

Garmin AT
IIMorrow/Apollo/UPSAT Format. appears to be in the transponder section, so most likely an install manual for the "old" transponders would spec here.

Dynon gray code converter
the "old" method of transmitting altitude information to the transponder to send out was through an analog "gray code" format via several wires.
http://en.wikipedia.org/wiki/Gray_code
for gray-code-only transponders to still work with modern digital efis baro sensors, dynon must have come up with a converter that then produced the "old" analog signal. obviously this is outdated as all new/state of the art transponders take serial baro information which is also much less susceptible to erroneous data from interference.

MAGELLAN Transponders set to MAGELLAN format
hard to find any info on that...

NORTHSTAR Transponders set to NORTHSTAR format
appears to be way outdated, little info.

AFS GPS
in principle just a preconfigured and "rebranded" garmin gps18-5hz puck delivering a subset NMEA stream at high frequency/low latency.

VPX Vertical Power VP-X Interface
as described above

COGUARD CO Guardian Interface
co guardian carbon monoxide alerter/sensing. another case of not documenting the actual data.

ADSB NavWorx ADS-B Interface
ADS-B in remote box for traffic and weather. no info on interface to be found.


so you see, apart from Vertical Power and UPSAT (which was way ahead of its time!) the internet/digital age hasn't really arrived yet...
 
summary

now for the potential
  • HUD
  • google glass
  • class II or III EFB
  • UAV/RPA
type developers, it would be beneficial not having to wire directly to all these kinds of serial protocols. first of all, the central efis platform will always be needed (unless you try to replace that with yet another efis, which really nobody needs and the established companies already do a great job at).
also, having to wire with lots of Y splits makes the wiring more complicated and intransparent and replicating several serial input ports in parallel on hardware is a waste of energy.
ideally, one would tie into the underlying can-bus (garmin), DSAB (dynon), ethernet (AFS), etc... which obviously needs cooperation with the manufacturers as they are not documented and much harder to reverse engineer. no hardware inputs/interfaces would have to be doubled and whatever data including efis internal stuff like active nav mode, whatever is available could be displayed.

IIRC, there was at one point an initiative here on the forums to try to get everybody to agree on a universal efis format output for exactly these kinds of applications, but i don't think it got very far unfortunately. it may have to be reactivated. google glass application may be a convincing driver.
actually, a wifi or bluetooth host would probably be the right and most flexible way into these bus systems. just don't forget to secure it (at least lightly) ;-)

unfortunately i'm just too busy with life to get involved any deeper myself, as one could guess from the interest ;-)
we already came up with a hardware flight control unit years ago, which is successfully in use on our advanced efis ("afcu" serial config) setup. never made it into a product, however. i'm in for the fun, not the business.
the many more buttons and knobs on the newer AFS units and especially the new garmin GMC305 control panel for the G3X prove however that we were right on the money and ahead of the time.

this was 2009:
IMG_0743.jpg

:)

kind regards,
bernie "the buttons guy" as rob hickman would call me ;-)
 
flyvans.com said:
ARINC-429
...unfortunately, the whole set of 429 standards is prohibitively expensive for any non-commercial/private purpose. maybe doug could approach ARINC to sponsor the community somewhat ;-)
also, dedicated 429 hardware interfaces/ICs seem to be just as expensive and rare, that's why most experimental implementations are throwing nowadays cheap processing power with some software emulation at the problem instead...
the good thing about arinc429 is that it covers almost any imaginable application from weather radars to autopilots.
unfortunately, there appears little to no open source documentation and google will not turn up much useful stuff either. no sample logs, no reverse engineering etc...
Click to expand...

The GAMA subset of ARINC 429 is easily obtained...http://www.gama.aero/industry-standards
 
He used equipment that is literally all RS-232 serial data, with every box he used being a device that has a published protocol. There aren't industry or common protocols for the devices he used, each one has it's own data format, but each one is also publicly documented. So the simple answer is that he found the data in the manual for each device he bought.

He didn't use ARINC-429 to talk to the 430. He made an analog converter box to get the old-school analog signals to the CDI and convert them to his own format. This avoided him needing to deal with ARINC-429 from a software or hardware protocol standpoint, but also really limits what you can do with the 430. He does appear to talk to the 430 over serial, probably using one of the published protocols it supports. Not sure what he gets out of sending data to it over serial.

The serial devices he talks to that he didn't make are:

GRT engine monitor, data stream documented in the manual
Crossbow gyro: Documented in manual
Navworx: Uses GDL-90 protocol, owned by FAA and easily available
Garmin SL-30, protocol in install manual

This looks like a neat project for someone that is really into it, but his ability to do it was based on carefully choosing his equipment to devices that support this kind of interface.

And as an FYI, the serial protocol for Dynon's equipment is all in the user manual(s) too. Check out page 20-1 of our install guide for our serial protocol. It includes almost everything our system knows about, down to transponder code, autopilot mode, and wind speed.

http://dynonavionics.com/downloads/Install_Guides/SkyView_System_Installation_Guide-Rev_N_Software_v5.1.pdf

--Ian Jordan
Dynon Avionics
 
cool, congratulations and hats off to Dynon in that case, never studied your manual in detail!

would definitely be a nice starting point for such a project, then!
obviously, sooner or later, the interface will have to become bi-directional, but for now one way but complete is already great!
you know, when we eventually get to eyetracking input devices or something along these lines *G* ;-)

also just completed reading the experimenter article. another hats off to bill de rouchy. doing such a project besides building the actual plane is a monumental task. simply wow. and mostly all by himself. especially considering he decided to do all kinds of converters and low-level boxes by himself as well..
one thing missing from the article is how he managed autopilot integration, especially in the vertical axis. also flight mode annunciation/flight mode management is not touched. would be interesting, especially since he specifically refers to delegating a lot and monitoring only.
but, it's a good example of how it looks when an engineer is going at the task with strong principles and primarily a mathematician/engineering approach. very solid foundation, interesting functionality but let's say the graphics and HMI do not take full advantage of the capabilities of the platform ;-) 1990 era windows 3.1 comes to mind. also, dogmas like going with as little buttons as possible by principle etc... just simply are not good HMI design.

another point i never get is when developers try to reinvent the wheel regarding symbology/color coding (as appears to be the case here as well, including the patent re the traffic threat analysis). this stuff has been studied and developed to perfection in the airline/commercial world with excellent results.
i guess it comes down to lack of crossover access, with the airline/bizav people being end users and not involved in the early conceptual stages. also not many graphics artists seem to hang around in such a technical field...

the (my opinion only!) leading three experimental platforms (Advanced Flight Systems, dynon skyview, garmin G3X) all have made extremely positive progress in recent months/years, i'm sure not the least through advisors and looking at best practice, not dismissing eye candy where it improves the look and feel.
Antialiasing is fortunately standard these days, some alpha blending, speedtapes are filtered and smoothed, heading bugs animated, sometimes with inertia, flight mode annunciation and mode control moving closer to airliner handling, dedicated buttons/knobs for the main functions like heading, qnh, selected altitude and so on.

watch out for some latest gen flight decks like FA7X, B788, Bombardier C-Series, A35X, they will set the new HMI standard to aspire to.

interesting times!

rgds bernie

p.s. shutting up now, promise ;-)
 
Wow. This has taken on a nice life of its own. Major thanks Bernie, thanks Ian for the Dynon take on things, and everyone else. There more I started finding things myself, before they were posted here, I started figuring that the vast majority of Bill's communication was by serial. As for the Navworx ADS-B and a few other things, I guess Bill just did some old-fashioned reverse-engineering and wire sniffing on his own.

Bernie's got me pegged - this is purely out of curiosity and maybe a little hacking eventually. First thing's first - I have to finish building the plane. :p Then I have to rub off the mental rust that's accumulated since the last time I've touched C/C++ (over a decade).

At the very least, this'll give me quite a bit to chew on and read over on the next few lunch breaks.

Don't know if Rob is watching this and can chime in, since I'm almost definitely an AFS guy when I get to that point. Either that, or I'll put it on the list of things to pester him with at Oshkosh. :D
 
Garmin Aviation Format

Garmin Aviation Format aka Mapcom is described in detail in the GNS480 installation manual. The Garmin/Apollo support people are more than happy to provide it to owners of experimental planes as long as they promise not to give it to anyone else. I am trying to find details of the Chelton engine data format if anyone can provide them. Thank!
 
Heheh Pete. Enough to make your eyes glaze over? :) Some people like to tinker with airfoil designs, some with engines, some of us (like this thread) love to hack around the avionics.

Dragging this thread back out, I also came across some old projects that act as starting points. Google for "PC EFIS" or such, there's one company that has a Windows-based one with a full package. There's the abandoned OpenGC project (Open Glass Cockpit), which looked to be leaning more towards Flight Sim / X-Plane than a real cockpit, but it's a start. And a few others.

Actually, with all the wire protocol info, I'm now also interested in what the format is for databases. I know Jeppesen, there's also Seattle Avionics. But those would have to be proprietary format, no? And though I've thought about doing it, I doubt I can just go up to the Jeppesen booth at Oshkosh, say to someone that as a side project I'm developing an EFIS, GPS, or something of the sort, and figure out how to get a copy of their nav data in a "neutral" file format for me to start playing with.

Any ideas here on the nav data front, or even approaches, etc?
 
hehe, another interesting subject ;-)

there is an "official" database format, namely arinc 424 http://en.wikipedia.org/wiki/ARINC_424
by definition this is a vector database made up of individual flight segments and definitions, no bitmaps possible AFAIK.

however, that navdata is highly focused on the commercial sector and in use on the upper end of flying / IFR SID, STARs etc... with 28day AIRAC cycles but normally doesn't show airspace classification etc...

according to the wikipedia article, some countries apparently now offer their data directly in coded arinc-424. but to my knowledge there is really only 3 significant data providers worldwide.
Jeppesen, LIDO (Lufthansa Systems) and EAG (European Aeronautical Group).

there is at least 2 outfits, one called "navigraph" www.navigraph.com and the other aerosoft with a product called "navdatapro",
which deliver more or less the same data to be used for the hobbyist flight simulation community at obviously much lower cost. there it runs in the fms's of high-end addon aircraft.
it used to be slightly outdated data from a month ago, not sure what it is today, but at the end of the day it was more or less the same data sourced from the pro suppliers.

google for "fms database providers" and you will find quite a few interesting presentations and links. namely a presentation by jeppesen to an ICAO event this spring... data quality and integrity is a huge topic with a very large importance to flight safety.

now, we are mostly more interested in airspaces and basemaps like roads and rivers. these can be in bitmap (like a zooming/scrolling foto) or vector (lines being drawn in realtime) format. or a combination of both with several layers.

for the vector data on the airspaces, there is only 3 sources to my knowledge...
- roll your own, gathering all AIP's from the regions you'd like to chart. the coordinates are published there, however mostly in cleartext and on paper only.
- jeppesen
- pocketfms (which essentially does option 1 with a small team)

there is definitely no open-source publicly available nav database at the moment.

basemaps can be anything from purchasing a digital version of the icao charts from various sources up to generating basemaps from openly available data such as openstreetmap or google maps or similar.
i'm not going into any of the commercial aspects / licensing / liability / terms and conditions topics.

regards,
bernie
 
Dynon said:
He used equipment that is literally all RS-232 serial data, with every box he used being a device that has a published protocol. There aren't industry or common protocols for the devices he used, each one has it's own data format, but each one is also publicly documented. So the simple answer is that he found the data in the manual for each device he bought.

He didn't use ARINC-429 to talk to the 430. He made an analog converter box to get the old-school analog signals to the CDI and convert them to his own format. This avoided him needing to deal with ARINC-429 from a software or hardware protocol standpoint, but also really limits what you can do with the 430. He does appear to talk to the 430 over serial, probably using one of the published protocols it supports. Not sure what he gets out of sending data to it over serial.

The serial devices he talks to that he didn't make are:

GRT engine monitor, data stream documented in the manual
Crossbow gyro: Documented in manual
Navworx: Uses GDL-90 protocol, owned by FAA and easily available
Garmin SL-30, protocol in install manual

This looks like a neat project for someone that is really into it, but his ability to do it was based on carefully choosing his equipment to devices that support this kind of interface.

And as an FYI, the serial protocol for Dynon's equipment is all in the user manual(s) too. Check out page 20-1 of our install guide for our serial protocol. It includes almost everything our system knows about, down to transponder code, autopilot mode, and wind speed.

http://dynonavionics.com/downloads/...em_Installation_Guide-Rev_N_Software_v5.1.pdf

--Ian Jordan
Dynon Avionics
Click to expand...
Hi Ian,

I read your post (above) in Van's Forums. I have recently installed a Dynon Skyview HDX in my Harmon Rocket and connected it to an Avidyne IFD440. I researched the configuration settings for the interface and they seem to be correct, but more flights are needed to improve my proficiency. I also installed a Garmin G5 as a backup attitude indicator (switchable to HSI mode). However, the configuration settings for the HDX are different than those for the G5 (and I get an error message on the G5 that reads "Not receiving ARINC429 data"). Specifically, on the IFD440 configuration page 2/15 (Main ARINC 429 Config), the HDX works with "Out 1: High (speed) / GAMA 429 Graphics" and the G5 wants to have "Out 1: Low (speed) / GAMA 429". Similarly, on configuration page 10/15 (VOR/LOC/GS ARINC 429 Config), the HDX works with "Speed: High / High" and the G5 wants to have "Speed: Low / Low". When I configure the IFD440 to EITHER the HDX settings OR the G5 settings, the instruments seem to work properly, but only with their preferred settings. Is there a workaround that might allow BOTH instruments to work simultaneously?

Thanks in advance,
Randy Sage
[email protected]
 
This is an old thread, but for a while, I also had these big grandiose plans to build my own avionics displays along with the airplane. I'd do the hardware and software, test them, and so on. I got a small single board computer (SBC) with RS232, CANbus, and a touch display, and started writing software for it. It turned out to be obviously a huge effort, and I soon realized I'd rather be flying than add a multi-year hardware and software design project to my build. This is about as far as I got. The display powers on, boots to my software (which also includes a georeferenced map and can take GPS input, but that's it.

The only other successful project I've seen in this area was posted to VAF several years ago: https://vansairforce.net/threads/homebuilt-avionics.136041/ I had a brief E-mail exchange with the builder of this system, enough to convince me it's a pretty huge task. We really can't compete with the head start Dynon, Garmin, and friends have.
 

Attachments

  • tempImagedcCCl1.png
    tempImagedcCCl1.png
    13.4 MB · Views: 40
On the subject of aviation protocols, does someone happen to know offhand if an SL30 connection is limited by a device on either end or can a third device be on the same serial?

I have "EFIS to remote NAV/COM" with everything talking to each other via an RS232 serial. Are there any issues if I put a "read always/send only when I push enter" DIY frequency tuning head on this same RS232 line?
 
Tall_Order said:
On the subject of aviation protocols, does someone happen to know offhand if an SL30 connection is limited by a device on either end or can a third device be on the same serial?

I have "EFIS to remote NAV/COM" with everything talking to each other via an RS232 serial. Are there any issues if I put a "read always/send only when I push enter" DIY frequency tuning head on this same RS232 line?
Click to expand...
RS232 interfaces are really quite "stupid" and basically unidirectional on one wire. Once they are used bi-directionally, there is simply a separate, second wire used in the backward direction. So they are easy to split or "listen in".
Multiple transmitters on the same wire, however do not work and it is tricky if you want to inject or combine messages. That's only possible if you actively retransmit all, including your additional messages.
Common wisdom is that you can simply split the Tx Pin of a sender device and hook it up to the Rx pin of two (or maximum three) receiver devices.
However, this is not an exact science and depends a lot on the driver chip and the electrical properties of the Rx chips (how much the signal is pulled down). Add to this, wire gauge/length (resistance leading to voltage drop) and you have quite a few factors at work. There are even specialized signal splitters/amplifiers, which are capable of transmitting to mulitple devices at the same time (via dedicated wires).
Basically you don't want to overload the driver chip that's putting out the signaling voltage, at the same time, at the receiver chip((s), there still needs to arrive enough of a voltage level so as to clearly be able to distinguish "low" from "high". But also this brownout threshold voltage depends on the Rx chips properties and several Rx chips in parallel may pull down the signal for all...

SL30 is receiving remote tuning information, on the other hand it returns basically the CDI/HSI output.
 
flyvans.com said:
Multiple transmitters on the same wire, however do not work and it is tricky if you want to inject or combine messages. That's only possible if you actively retransmit all, including your additional messages.
Click to expand...
Thanks for the detailed and informative explanation! 👍

I did successfully make a proof of concept (Arduino+MAX3232 scoped at +7,-7 volts IIRC) tuning panel but that was before I bought an EFIS to share the serial. Armed with this new info, I am curious to see if the serial will potentially fail for a couple seconds... or until reboot… actually work... or reject the input altogether. I will try reacquaint myself with what I did and wire it in the next couple days 🤞
 
The arduino + MAX3232 approach should work, if you receive on one and then retransmit on the other line, without messing with the linebreaks / sentences. then you can interject your own between the linefeeds.

Garmin SL40 ATC VHF Radio Serial Protocol in Bash

The Garmin SL30 and SL40 protocols are used by most aircraft and marine VHF radios. These radios are very simple AM devices and basicall...
www.aeronetworks.ca www.aeronetworks.ca
the tuning message looks like an NMEA0183 GPS sentence. $PMRR....
 
flyvans.com said:
The arduino + MAX3232 approach should work
Click to expand...
Ok update, looks like you are right, and the serial seems to return to normal on the next loop after any disruption I introduce (y) I had a couple pins set to push new frequencies if grounded. The 25khz spacing works but still some work to do with how to display it as a proper variable. Ultimately will have a DIY CDU with radio tuning as its main feature. I like the Vega a lot except for it blinking the numbers on multiple frequency mode, so it's mounted rear cockpit.

Preliminary setup for proof of concept:

GRT Sport EX (Serial set to SL30) ------- Arduino concoction tee'd into tx/rx lines -------- MGL Vega (SL40 Emulation mode) ------- CAN network to V16, Future N16 soon?
 

Attachments

  • Mega.JPG
    Mega.JPG
    153.5 KB · Views: 9
  • Serial.JPG
    Serial.JPG
    116 KB · Views: 9
there is a newer garmin GNC255 protocol, which is 8.33KHz capable... don't have a description, though.
That would be more future proof. The trig radios also support that.
Unfortunately, what used to be quite nicely documented 20 years ago is now getting shrouded in secrecy, more and more... see e. g. the CAN bus discussions... Poor practice.
 
Draker said:
This is an old thread, but for a while, I also had these big grandiose plans to build my own avionics displays along with the airplane. I'd do the hardware and software, test them, and so on. I got a small single board computer (SBC) with RS232, CANbus, and a touch display, and started writing software for it. It turned out to be obviously a huge effort, and I soon realized I'd rather be flying than add a multi-year hardware and software design project to my build. This is about as far as I got. The display powers on, boots to my software (which also includes a georeferenced map and can take GPS input, but that's it.

The only other successful project I've seen in this area was posted to VAF several years ago: https://vansairforce.net/threads/homebuilt-avionics.136041/ I had a brief E-mail exchange with the builder of this system, enough to convince me it's a pretty huge task. We really can't compete with the head start Dynon, Garmin, and friends have.
Click to expand...
Hey Ryan….
Been there, done that! Check out https://www.huvver.tech/huvver-avi-download-version-8/
The development was documented here on VAF on an Arduino thread: https://vansairforce.net/threads/flight-instruments-engine-instruments-arduino.214037/#post-1707770

I provide source code to qualified develops, and you can even obtain the hardware from MakerPlane. Rob Prior (RV-6) and I (Rocket) have done all of the mechanical and electronics design, plus flight testing. We have also developed a tailBeaconX controller on the same platform.

Vern
 
You must log in or register to reply here.
Back
Top