NMEA Output..

R

Royerm

Member
Official iFly Beta User
Joined
Apr 20, 2023
Messages
12
Reaction score
5
EDIT: This feature is incorporated in iFly v13.1

I'm sure I'm not the only one as I remember from the old forum.
NMEA output would be great to have just like the old 740b to drive for example
our autopilot and not having to switch to the iLevil..
Regards
 
Last edited by a moderator:
Upvote 27 Downvote
No "smoke," the Trio Autopilot does not use any RC parts or glue. If I recall each of the two servos are $700 each. The head unit which is the interface control is an additional $1,400. TRIO is an experimental and certificated Auto Pilot builder amoung other items. It does use a NMEA string from your course planner ie ifly course , to drive the Trio control head unit and none of that is glue or RC related.
 
Sorry, I was referring to the iLevel unit
 
Sorry, i thought that you were referring to the iLevel unit
 
Then, would it be possible to output from the iFly EFB the NMEA course data via a Bluetooth connection? Most of us already use the wifi for wx and traffic. and have no need to duplicate that equipment and antenna installation. I see the EFB already has options for sending that data to a iLevil wifi connection.
 
Just clicked on the up arrow to upvote the need for NMEA output. The number went from 21 to 20.
 
PA28-140/160 said:
Just clicked on the up arrow to upvote the need for NMEA output. The number went from 21 to 20.
Click to expand...
I believe that means that you may have already up-voted for it. Using the up-arrow again removes your previous up-vote. Try clicking the up-vote arrow once again to restore your original vote. The voting interface on this forum product seems "odd" imo.
 
Gatormyk, thanks...just tried that and it went back to 21. I don't remember voting it up in the past but maybe I did. Anyway, I'll leave it alone now. Don't want to cause a meltdown. ;)
 
I did not know that, Thanks. (I was going to jokingly ask PA-28 to not vote on any of my requests.)
 
This is pretty normal behavior for any site that allows upvotes, likes, or stuff like that. Click to "activate", click again to "deactivate".
 
Chiming in here -- thanks to the forum poll, this feature is getting light on our end.

Since we *already* have this feature in our code (which resides on the tablets as well) - the only obstacle in our way for implementation is "plumbing". The other obstacle in our way is "business case" (payback for work done, and support cost risks).

I'm brainstorming here, so here are some thoughts for you to comment on:

1. Collaboration with avid Beta Testers -- we'll rely upon you, mostly for testing/validation. This saves us the work.
2. State (inside iFly itself) that this is feature is NOT OFFICIALLY SUPPORTED, except on forums by other users.

This approach reduces our cost upfront, and our risks on support. And so becomes a "use at your own risk" feature and with support mostly coming from other pilots using it. Then Adventure Pilot will unofficially continue support for it, handling change requests/bugs, where validation/testing will come from the beta testers.

This approach could allow me to "squeeze this in", and then "see how it works" -- it could go very easily, as from a programmer's standpoint, since the feature "already works on the 740" - the only implementation I have to work on is "plumbing" (our software ports to the serial port). This could be as easy as a few days worth of work on my end.

ADDED: As @Cobra noted above, the support of NMEA is difficult/costly - because there are so many uncontrolled parts involved in each configuration, and duplication of bugs here in the office, is also hard. And lastly, this feature is niche, not used by many -- so the folks we are serving are fewer in number. So becomes high cost for little payback, unless we're careful how to control these costs/risks, to keep this profitable or at least break-even (which is a requirement).
 
Last edited:
Although I doubt I will ever have use for the NMEA output, it seems to me a useful feature of iFly. The post by Brian brings up a few questions.

Why would this feature, that (it seems) the programmers must have intentionally designed and included in the software, not be considered as officially supported?

What is the benefit of a feature that is continually unofficially supported?

Am I missing something? Is the NMEA output a coincidental offshoot of one or more features intentionally designed by iFly programmers, and accidentally discovered and used by the experimental community without the knowledge of iFly/AP staff?

Another thought just occurred to me. Does unsupported mean that AP/iFly will offer no official support as to how to hook up the iFly NMEA feed to Brand X, Y, or Z autopilot, or whether the NMEA feed will accommodate various different features of those same autopilots?
 
This is the best news that I have heard yet. I do not know how much support was required from A/P, but in my case the same USB breakout wire has been used since 2010 with no issues, in three different airplanes. It is basically a "one wire" install with a very intuitive setup for the required GPS sentences and baud rate. Aside from the auto pilot, fuel computers and EFIS units require this data.
 

Attachments

  • IMG_2670.jpeg
    IMG_2670.jpeg
    3 MB · Views: 9
@Brian great news. I am happy to help test. On your thoughts to ponder, it would be great to understand the initial constraints you are working with. For example, you are interfacing with a FTDI chipset on the USB side. This will help to make sure we have what we need to test. Will also help with the community support of the feature.
 
MDreger said:
Why would this feature, that (it seems) the programmers must have intentionally designed and included in the software, not be considered as officially supported?
Click to expand...
Keep in mind that when this feature was first developed, iFly only existed on a dedicated WinCE device (the original iFly 700), with a USB Type A port using WinCE drivers. Thus, AP had full understanding of the hardware and OS it was running on, and they sold a specific USB-to-serial cable that they had tested and understood. One platform, one cable. That's about as easy as it gets.

Now, we're talking about a universe of tablet/phone devices, using any of several Android versions (which can have very different levels of USB support, from what I understand), with either a USB-mini, USB-micro, or USB-C port, and who-knows-what USB-to-serial cable/adapter. If they're also going to open this feature up on the Windows platform, then add in all the jillion new variables there, as well.

The number of variables involved in supporting this feature has exploded, and AP doesn't have every possible tablet/phone, every Android version, or every USB cable/adapter to test the myriad combos possible. There are probably more possible configurations than there are potential customers for this feature.

Even if they specified a particular USB adapter/cable (though they'd probably have to specify multiple ones since older devices might have USB mini or micro ports) to reduce those variables, there are still the myriad device/OS version combos to deal with. Restricting the feature to only newer devices could help improve the situation, but there will still be a lot of variables and more combos than AP could practically test.

It is perfectly understandable to me why AP views this situation with trepidation, and is unwilling to commit to officially supporting this feature under these conditions.

MDreger said:
What is the benefit of a feature that is continually unofficially supported?
Click to expand...
For those users who want/need it and can get it to work, the benefit is tremendous. For those who have trouble, the benefit is zero, which is no worse than not offering the feature at all.

MDreger said:
Am I missing something? Is the NMEA output a coincidental offshoot of one or more features intentionally designed by iFly programmers, and accidentally discovered and used by the experimental community without the knowledge of iFly/AP staff?
Click to expand...
You're missing the original use case: Only the iFly 700 existed when this feature debuted. There was no such thing as an iPad or Android tablet at that time, nor did iFly support Windows devices then either. (Well, okay, technically the iPad came out before the iFly 700, but only by several months, and it was years before iFly became available on it and other phone/tablet devices.)
 
Last edited:
MDreger said:
Although I doubt I will ever have use for the NMEA output, it seems to me a useful feature of iFly. The post by Brian brings up a few questions.

Why would this feature, that (it seems) the programmers must have intentionally designed and included in the software, not be considered as officially supported?

What is the benefit of a feature that is continually unofficially supported?

Am I missing something? Is the NMEA output a coincidental offshoot of one or more features intentionally designed by iFly programmers, and accidentally discovered and used by the experimental community without the knowledge of iFly/AP staff?

Another thought just occurred to me. Does unsupported mean that AP/iFly will offer no official support as to how to hook up the iFly NMEA feed to Brand X, Y, or Z autopilot, or whether the NMEA feed will accommodate various different features of those same autopilots?
Click to expand...
The ability to send NMEA messages from an iFly hardware device (7xx) over USB to Serial has been around since I started using the product. Recently the ability to send that data over WiFi to a Levil device was added to the tablet version. Both of these have been well supported features by AP.

NMEA 183 is an older industry standard, actually from the marine space, to send position and track information via structured sentences. Most autopilot install manuals will specify the baud rate and sentences required for specific functionality. In the current hardware devices you can pick both the baud rate and the sentences to be sent from the device.
 
Cobra said:
Keep in mind that when this feature was first developed, iFly only existed on dedicated WinCE devices, with a USB Type A port using WinCE drivers. Thus, AP had full understanding of the hardware and OS it was running on, and they sold a specific USB-to-serial cable that they had tested and understood. One platform, one cable. That's about as easy as it gets.

Now, we're talking about a universe of tablet/phone devices, using any of several Android versions (which can have very different levels of USB support, from what I understand), with either a USB-mini, USB-micro, or USB-C port, and who-knows-what USB-to-serial cable/adapter. If they're also going to open this feature up on the Windows platform, then add in all the jillion new variables there, as well.

The number of variables involved in supporting this feature has exploded, and AP doesn't have every possible tablet/phone, every Android version, or every USB cable/adapter to test the myriad combos possible. There are probably more possible configurations than there are potential customers for this feature.

Even if they specified a particular USB adapter/cable (though they'd probably have to specify multiple ones since older devices might have USB mini or micro ports) to reduce those variables, there are still the myriad device/OS version combos to deal with.
Click to expand...
@Cobra , there are a few widely used standards in this space. While they will not solve for every scenario they will solve 90%+. Take the USB to Serial adapter. The connectors on both sides do not matter. What matters is the chip set and driver. Most adapters are FTDI compatible and run using any one of 4 or 5 standard drivers. Which, btw, is the same adapter type AP uses today. So I can hit Amazon and have hundreds of choices to pick from that will all work.

Yes, there are going to need to be a few minimum requirements that are probably going to need to be defined to streamline the development process for the AP team, but if widely used standards are used it will make it easier to find devices that meet them.

When I was heavily playing with stratux and contributing there, it was not uncommon for a list of community tested / recommended products to be shared on the forum. I would imagine that is where this enhancement would evolve to.
 
MDreger said:
Although I doubt I will ever have use for the NMEA output, it seems to me a useful feature of iFly. The post by Brian brings up a few questions.

Why would this feature, that (it seems) the programmers must have intentionally designed and included in the software, not be considered as officially supported?

What is the benefit of a feature that is continually unofficially supported?

Am I missing something? Is the NMEA output a coincidental offshoot of one or more features intentionally designed by iFly programmers, and accidentally discovered and used by the experimental community without the knowledge of iFly/AP staff?

Another thought just occurred to me. Does unsupported mean that AP/iFly will offer no official support as to how to hook up the iFly NMEA feed to Brand X, Y, or Z autopilot, or whether the NMEA feed will accommodate various different features of those same autopilots?
Click to expand...
@Cobra - answered this pretty well.

I'll restate most of what he said, in my own words, in case it's helpful.

For something "officially supported" we're obligated to "take support calls" which can be lengthy -- and if the expectation of the customer is "this is supposed to work" - then there can be frustration/anger/bitterness we're dealing with, which puts pressure on us to stay-on-the-phone, escalated, and handle these issues.

By making it "not supported", we can simply apologize to the customer for the inconvenience, and get off the phone. It's about managing expectations here, and controlling support costs/burden.

We'll do our best to in general get "most people working" (or working on some known combinations of devices and cables) -- so that the feature "generally works for some/most". And so if it works for some/most -- then we've done our job. The rest, for whom it does not work, simply need to figure out how to get it working like the "some/most" who do have it working. Community support will be helpful.

If it turns out that there is a big gap, that is proving inconvenient for many - then AP can respond with a bug fix that closes that gap. (e.g. if for some reason it begins to fail for all Android devices on a new Android OS -- then we'll need to make a fix for this new OS, so that we won't force NMEA users to use "old Android devices").

NOTE - I'm still just brainstorming here. I'm just the developer -- I don't control the purse strings or priorities. But I do have some influence, and that's where my powers end. No commitments are to be implied by my proposals here.
 
Brian, I believe the only component of control/ output that most are talking about on autopilots is the x y Course tracking function. Not talking altitude or anything related to altitude control which somewhat crosses the line into the IFR certified equipment. And maybe that other line of portable gear used for IFR flight. So that may be the line in the sand. The best way to remain isolated and separated from that association is of course wifi. I think the Bluetooth com method might could be the answer However it does envolve something at the other end that can "read" Bluetooth and provide that DB9 TX and Rx wire ... a stand alone simple box 12vdc powered would be t
he answer. Is there such animal? i don t know that equipment but That might be easier to market and establish as a separation than a USB c plugged in. Just my thoughts
Most computer techs seem to say that the software for NMEA output over wifi or Bluetooth is not much of an issue. And either way does provide for the separation.
 
Also still brainstorming here: And Still thinking on the Bluetooth option for data, that's kinda the way that "G" inc got to where they are by exclusively marketing a code that only their equipment has the ability to connect . All the codeing, done in the software and then providing the hardware ( tightly controlled) which can communicate with that . Thru this method they are able to control both the software and hardware which allows them to be the sole supporter. Yes, I understand they are big and have the resources to do that .
 
Last edited:
DRRhodes said:
Most computer techs seem to say that the software for NMEA output over wifi or Bluetooth is not much of an issue. And either way does provide for the separation.
Click to expand...
The current "officially-supported" iFly NMEA output method from tablet/phone devices IS via wifi, using the iLevel 3 AW as an intermediary between iFly and the autopilot. That solution is available today.
 
Chad said:
@Cobra , there are a few widely used standards in this space. While they will not solve for every scenario they will solve 90%+. Take the USB to Serial adapter. The connectors on both sides do not matter. What matters is the chip set and driver. Most adapters are FTDI compatible and run using any one of 4 or 5 standard drivers. Which, btw, is the same adapter type AP uses today. So I can hit Amazon and have hundreds of choices to pick from that will all work.
Click to expand...
Maybe. But at the tablet side, there are variables.

I'm not a devdloper and I don't code to USB ports so I don't have a comprehensive understanding of what's possible and what's not, but as a user I had plenty of USB issues with older tablets. Back when I had a Nexus 7 2013, I thought, "Hey, I want to move files back-and-forth between my tablet and my PC. Let me get a USB mini-to-type A adapter and plug in a USB thumb drive to copy files across." Except...that didn't work. Plug in a thumbdrive to an Android device, and...nothing happens (at least back then).

This seemingly simple and basic function (thumb drive support)--something that has always "just worked" on any Mac or PC since USB 1.0 ports first appeared--for the first many years of Android tablet existence was actually impossible, because Android didn't support that type of USB connection. Later, it became possible, but only on some devices (it needed both the right OS and the right device chipset, as I recall), and only with a special "USB On-The-Go" adapter. (When Google Drive came along, it offered a much easier way of moving files between devices, so I abandoned the attempts to use a thumb drive and have no idea whether that's easy today or not.)

But the point is, even stuff that seems like basic USB capability that ought to be obvious or simple...isn't necessarily.

As I said above I'm not a developer and I don't know if the USB limitations I've experienced on some Android devices come into play in this iFly NMEA output application or not, but I doubt most of the other users here do either.
 
Last edited:
Cobra said:
The current "officially-supported" iFly NMEA output method from tablet/phone devices IS via wifi, using the iLevel 3 AW as an intermediary between iFly and the autopilot. That solution is available today.
Click to expand...

Understand that wifi is the A/P supported method, but all tablets that run EFB ALSO support Bluetooth. That would run at the same time that the EFB is running wifi. Most who are upvoting probably have wifi already tied up with wx and Traf. Having that second paired connection at the same time allows for one additional sentence to be TX to the autopilot. Agree, that then limits the "conservation" to only one more output wire. But it does allow for the separation with that sensitive device the autopilot and allows for a more easier accepted business decision. You might be considered crossing the line when you hard wire tie these two devices together legally. That's why most other Generic EFB choose not to do this. And I think that's why the wifi is an easy decision to make.
 
Brian: Thanks for your efforts and count me in as a beta tester! Current tablet is a Samsung Galaxy Tab S2 (8") 32GB, WiFi, with a micro-USB socket. I'd be willing to upgrade the tablet if the beta testing were to be with more current USB connectivity, bluetooth, etc.

While I don't have an autopilot, I do have two AV-30-C's that I have connected to my 740 for the NMEA stream. Given the fact that Adventure Pilot is currently selling the uAvionix AV-30s (at a discount), doesn't it make sense for AP to provide NMEA from the EFB? After all, one of the key benefits the AV-30 in DG mode is that two of the four selectable "screens" available are HSI and ARC. I use the HSI for virtually all my x-country VFR flights. Without the NMEA stream, HSI and ARC modes are unuseable (useless) and as such, much of the utility of the AV-30 is lost. I understand that this will never be an IFR approved tool but there are plenty of VFR and EXP guys out here! The AV-30-C's are IFR approved instruments, and I still have an IFR airplane, it's just that the NMEA output does not provide IFR compliant lateral or vertical guidance. But a big plus for situational awareness.

BTW, The AV-30-C's work well, especially with the 740, and they also control my tailBeaconX transponder. Also, I got to take 15+ lbs of vacuum pump, plumbing, aging AI and DG, aging AT-150, encoder, etc. out of the plane.

Rob
 
  • Like
Reactions: Laz
I agree, a USB/serial output makes the most sense. It is simply a one wire connection with no interference or drop outs. It is as reliable as you can get. I have been running my equipment this way since the 700.
 
Currently, I have the USB output from the 740 to a DB-9 connector (Sabrent adapter wire, $10) and the DB-9 to the AV-30 DB-15 backshells. You're right Smoke...one wire (paralleled to both AV-30's)...fairly easy to do and pretty bulletproof. Now all I would have to do is change the adapter wire from the old school USB plug to one that fits the tablet and...bingo! I would guess that the autopilot interface wouldn't be much different a change if you're already hardwired?
Rob
 
Last edited:
  • Like
Reactions: Laz
It's been years since I've given NMEA output any attention, so I'm risking sounding ignorant here. My barely educated (at this point) guess is that an adapter like this might work.. Is RS232 output what we want for hard-wired?



Regarding BlueTooth - on iOS, they make this difficult. The Dual-GPS190 is bluetooth, and we had to go through a special approval process just to talk with that one device. So if we opt for the BT method, I'm not sure how we'll go about this -- is there a "generic device type" that we can register for? Right now, we're only authorized for the DualGPS190 pairing. It's been almost a decade since we went through this BT approval process with iOS -- so it's a fuzzy memory for me atm.
 
Brian, yes, this serial adapter will work fine.
 
Brian,
Here is the one I use for the serial output on my 740:

USB 2.0 To Serial DB9 Male (9 Pin) RS232 Cable Adapter
sabrent.com/products/cb-db9p

Same thing, but mine is the old school USB plug. Good ole RS-232. As per page 55 of the iFly manual:
"2. Wire the USB-to-Serial cable to the external device, using PIN 3 for data, and PIN 5 for ground."
NOTE: That's pin 3 and 5 on the DB-9 connector.

BTW, with the AV-30's, the ground is not required.

The AV-30's work great with the "standard" serial sentence:
From the manual - "Standard = 4800 Baud, Basic GPS location data (GPRMC and GPRMB) sentences will be sent"

Rob
 
The experience with the USB A plug and data from the 720 and 740b GPS units is without question , It works and very reliably. I would like to hear from someone who has tried the same adapter Rs232 plug or other maybe with an OTG adapter into the USBc plug running the iFlyEFB on say a Galaxy Tablet. Now that would be some news worth info. o_O
 
POLL: iOS vs. Android. If we only did one (or did one first) -- which is more important?

Since the work to be done here is mostly about "plumbing" (enabling our software to transmit via the USB port) - for something like this, the code for Android is completely separate (and often very different) from that of iOS. So for just over half-the-work, we could do just one. The other would be almost the same amount of work, again.
 
Android.

Brian: how does this jibe with what Jaydon said in this post? He's saying Bluetooth (wouldn't that work on both Android and iOS?) and you're saying USB.
Jaydon Beacham said:
We are trying to get a working Bluetooth to serial output device that way you can get NMEA data from iFlyEFB to an autopilot. I don't have a timeline for this, but it is something to expect in the future.
Click to expand...
 
Brian,

OK...I'm not a programmer (other than Basic, Algol, Fortran, dBase, C+, a lot of CNC G code and other old school languages...gee, guess my age) but I did stay at a Holiday Inn Express last night! :)

I would humbly suggest that getting the data stream to a USB terminal would be much easier than going bluetooth, wifi, etc. given all the different platforms and that getting the RS-232 data stream to a USB point could be the common denominator. There are inexpensive RS-232 to Bluetooth converters and R-232 to WiFi converters out there for those who need/want them.

To answer your question, Android. Be the competitive option. iFly EFB runs really well on my older Samsung tablet and lots of others. Plus, FF (iOS, overpriced IMHO) has told me that they have no plans to go NMEA out because it would never be IFR. I think that iPads are what everyone thinks they need because of the current market. I disagree. iFly EFB should be the spoiler.

Disclaimer: I am a long time 720/740 user and I love the user interface. I have recently "upgraded" to EFB on a tablet and think it it has all of the best of the 740 with a bigger screen. The only two downfalls are, no NMEA output for my instruments (huge issue) and (believe it or not) the remote control. When reaching across the cockpit to the GP/tablet in turbulence, my fingertip goes up and down with every bump. I find the remote control allows me to do many of the basic responses (acknowledgments, zooming, plane position, etc) to be much easier in the bumps.

my $.02

Rob
 
Brian said:
It's been years since I've given NMEA output any attention, so I'm risking sounding ignorant here. My barely educated (at this point) guess is that an adapter like this might work.. Is RS232 output what we want for hard-wired?



Regarding BlueTooth - on iOS, they make this difficult. The Dual-GPS190 is bluetooth, and we had to go through a special approval process just to talk with that one device. So if we opt for the BT method, I'm not sure how we'll go about this -- is there a "generic device type" that we can register for? Right now, we're only authorized for the DualGPS190 pairing. It's been almost a decade since we went through this BT approval process with iOS -- so it's a fuzzy memory for me atm.
Click to expand...
@Brian they key is using a FTDI compliant model so you can just go with a standard library protocol and driver. That way you won’t have to bitbash to get the sentences out. To your specific link, that one will work fine. As will many others. When we build mock ups and eventually go to final version, I normally have the team grab a certified version as opposed to a generic model just so we know the are using the full spec of the chipset or the driver. Most generics do, but sometimes you get a knockoff that just threw out a bunch of words on their products. The one you all sell or used to sell is a certified version.

As for Bluetooth it becomes tricky. Some of the profiles like audio (A2dp) are extremely standardized. You can buy any old headset and bluetooth in. There is a serial profile (spp) but since it is not used that much it is not included in many Bluetooth device stacks. The other challenge is the SPP profile was originally created to act as a device remote control emulator, (think change the channel on my tv). That means most of the functions this profile offers are not optimized for An rs-232 stream. Frankly GPS is one of the worst items to attempt to connect with Bluetooth because of the dozens of ways that you can implement it.

I laugh when I think how much serial we still use at work. If it is life safety or production related we hardwire. Next option is proprietary wireless where we own the frequency spectrum license. After that it is WiFi because of the ease of encapsulation of most payloads.
 
Android

I would suspect that many/most? of the existing users who have iFly sourcing the GPS data to their autopilots are using either Trio or TruTrack hardware. (I could be completely wrong here but I will continue.) Keep in mind that, to my knowledge, both units require a hardwire for the data input. My Trio has no BlueTooth or Wifi interface but has worked with no ussues for the last 5 years hardwired to the 740b. Introducing BT/WiFI into the data stream only seems to add another failure point and potentially less reliable communication. KISS rules!

Shout out to PA28-140/160: Hello FORTRAN brother! Yeah, I'm retired too!

Best, John

​

 
ANDROID

I use both but am starting to lean more toward using my Android more as the tablet I mount on my yoke.
  • My Android tablet seems to handle the heat of direct sunlight so much better than the iPad.
  • The cost of many Android tables is lower than the iPad for similar performance.
  • Android appears to have a more open architecture allowing developers to take advantage to integrate other third party devices with their app.
 
I don't really have a dog in this hunt, and the consensus seems clear so far, but I'll throw out one more thought:

I suspect that most pilots who fly with an iPad are already using the 800-lb gorilla in the market (FF). It might be to AP's advantage to first cater to those who are actively looking for alternatives to FF *because* they don't use an iPad.

Eventually, it might make sense to also add this capability to iPad, if possible/practical (will the current OS/Lightning port even allow it? If not, will that change when Apple eventually transitions to USB-C?), to more directly compete with FF and maybe pry away some users.

Whether this feature will really attract that many new customers to make this rationale relevant, I dunno. I'm not sure how loudly AP will choose to tout this feature if it's not going to be officially supported.
 
As John said, I'd want hard wire to the AP, and to re-iterate, on Android. Our first tablet running iFly was a first or second generation iPad Mini. hated it. Gave it to the grand kids. it's been Android since and I won't go back.
 
Just received the new Tripltek 9, which is Android, so that's my vote.
 
Has anyone investigated the use of a Raspberry Pi or Arduino device as an NMEA interface? There are a couple of NMEA software references on GITHUB.

My $.02 worth this morning
Steve
 
Steve said:
Has anyone investigated the use of a Raspberry Pi or Arduino device as an NMEA interface? There are a couple of NMEA software references on GITHUB.

My $.02 worth this morning
Steve
Click to expand...
Adding in a DIY interface is not going to make AP any more comfortable with / willing to / excited about supporting this feature.
 
Brian said:
POLL: iOS vs. Android. If we only did one (or did one first) -- which is more important?

Since the work to be done here is mostly about "plumbing" (enabling our software to transmit via the USB port) - for something like this, the code for Android is completely separate (and often very different) from that of iOS. So for just over half-the-work, we could do just one. The other would be almost the same amount of work, again.
Click to expand...
Brian, about your iOS vs. Android poll: For me, it's complicated--and my answer is a messy one.

I'd be happiest if you'd just dump Android and Windows altogether and go with iOS. I'm a refugee from Windows (or WindWoes, as I think of it now). So I'd be delighted--because with iOS I no longer have to futz with all the variations inherent in anything remotely open-source.

(I'm inherently an open-source person, by the way. That's one reason why I built my own airplane--so I could customize it. But there are other considerations: For most users, iOS is simpler and safer overall, mainly because it's so tightly controlled by Apple.)

However, I've also put up with the clumsiness of Windows CE in iFly 740 and 740b, which have proven to be reliable and bulletproof, and they output NMEA for my Dynon autopilot. Reliability is more important to me in flight than all the clever innovations in any aviation GPS. iFly GPS already has more clever innovations than I need to fly from here to there. GPS simplicity and reliability are what I count on in flight.

So if you remove hope of NMEA output from iOS iFly, I'll be very unhappy. But if necessary I'll buy an Android tablet to get it back.
 
+1 for me two. I know several guys who use the NMEA output to drive their AP.
 
As far as which tablet, I really don't know much about android systems. But after a little research, it appears that every major airline, every charter operator and the US Airforce all use the IPAD for their EFB equipment. Is there a reason for this? Something to ponder.
 
You must log in or register to reply here.
Back
Top