Feature request: Output NMEA sentences on Telemetry2 port

[nicksargeant]

Many devices that are carried on UAV supplementary to the autopilot require a GPS Input and it seems redundant to have to carry multiple GPS units. These devices can Include OSDs, specialist sensors and camera payloads. I am aware that it may well be easier to just use a Y-cable from the GPS but given that the Pixhawk has a second telemetry output and FrSky telemetry is now possible, outputting GPGGA and GPRMC sentences is possible with a software patch. Would this functionality be useful to any other users?

[iskess]

Yes! +1
Amazing timing, I was just googling this morning on how to utilize the onboard GPS for an Arduino board that will be used to manipulate a camera gimbal. I'm not sure if I will have issues with the GPS protocol since the Pixhawk doesn't use the standard NMEA at 9600 baud. I'm not the one programming the board and I'm ignorant to what is feasible.
Using Telem2 more useful would be great. It is easy enough to split the telemetry cable for the OSD like we did with the APM2.x. If the Telem2 pot could be configured to send out different data, it would be better utilized.
Thanks for bringing this up.
In the meantime, can anyone can tell me how simple it is to tap the gps data going into the PH for use on an Arduino board?

[jpkh]

One main reason that why we are not using NMEA is due it's rather inefficient way of delivering data. On early days when APM group worked with MTEK GPSes we already had to start to use their more compressed binary data and nowdays we use UBX binary protocol from uBlox modules. 38k speed what is commonly used on GPSes used now days would be over filled with ASCII data (NMEA is ASCII) 9600 baud is way out of the question as it would jam all serial communication.
Ok can we have UBX converted to NMEA inside PxH??
Then again, if you really need that 9600 baud NMEA. How difficult it is to make arduino sketch to do that and piggyback GPS rx/tx lines for it.
just my two cents...

[nicksargeant]

Thank you for the responses. I remember the days of EM406 then LS20031, Ublox, MTEK and now back to Ublox. While it would be easier to create an a splitter then an arduino adapter, this is no more elegant than just having a separate GPS (arguably now creating more points of failure). Ideally the peripheral device would speak mavlink but this obviously required it to be designed to do so. My idea would be that the Pixhawk generates the NMEA stream (providing that this doesn't have too much CPU overhead.)

[JSGordon]

Some Ublox units support output on multiple ports which can be configured for separate communication protocols. APM is now using UBX at 38400 with no NMEA because of the bandwidth issue with getting 5 hertz data out. But pulling two protocols from a GPS with multiple Uarts could do what you need I think.

[rmackay9]

I think it might be possible to force the ublox to use the nmea mode by setting the GPS_TYPE parameter to "5". Then you could split the tx cable coming out of the GPS and feed it into whatever other system you'd like to use.

[rmackay9]

By the way, we have a SerialManager being added for AC3.3 which will allow more flexibility in terms of how the UARTs are used and it's technically possible to add a driver that outputs the nmea streams but what devices in particular would this be helpful for?

[iskess]

Randy,
What would be the negative side effects of changing the GPS_TYPE to 5?

Perhaps one could keep GPS1 (primary) set to Auto so it puts out UBX, and set GPS2 to 5 so it outputs NMEA.
Do you think the failover to GPS2 would still operate normally if it's protocol is different than GPS1?

[rmackay9]

@iskess,
I'm not sure what the side effects would be. The worst thing i can imagine is that the NMEA messages don't include velocity. That would have an actual negative impact if you were using the EKF but probably no impact if using AC3.2 (which defaults to using DCM+inertial nav).
The HDOP seems to be reported differently if you use NMEA. The NMEA number appears lower.
I believe you could disable the auto failover of the GPS. There's another GPS_ parameter for that as well. Of course if you're going to do all that, then some might argue you might as well not even feed the NMEA gps into the autopilot 'cuz it's not using it.

[iskess]

Randy,
I think what you are saying is that having GPS2 output NMEA would likely make it the primary since it will report a better HDOP? I certainly don't want to loose the gps auto failover, I want that redundancy. My gps1 is an M8N, so it should remain primary with all the extra Glonass data. My thought is that this would leave the old 6M GPS2 just sitting on the bench waiting for a chance to be put in the game. Might as well give it a job to do outputting NMEA to an Arduino board that controls a gimbal. As long as it can still guide the aircraft home safely if GPS1 croaks.
BTW, this is for a plane.

[rmackay9]

@iskess,
The GPS selection logic is not super sophisticated, it uses the number of satellites (and not the HDOP). Luckily for your setup the M8N will have a really high number of satellites so it's pretty much guaranteed to always be the primary. So yes, i think what you're looking at doing will work ok.

[jmachuca77]

A NMEA output would be a great addition, TetraCAM cameras for example take a NMEA input to geotag the images as they take them. You could save 200 USD by not buying their GPS. Also there are some antenna trackers that take NMEA input on the video transmitter and encode the signal to send to the ground tracker.

Jaime

On Jan 28, 2015, at 7:56 PM, Randy Mackay notifications@github.com wrote:

By the way, we have a SerialManager being added for AC3.3 which will allow more flexibility in terms of how the UARTs are used and it's technically possible to add a driver that outputs the nmea streams but what devices in particular would this be helpful for?

—
Reply to this email directly or view it on GitHub #1774 (comment).

[IdefixRC]

I'm also looking at this.
If this can not, or will take some time, be integrated maybe someone would someone be keen and able to write a mavlink to NMEA converter which could run on a small Arduino or Teensy similar to the FrSky telemetry converter?

[k5njm]

One application that can benefit from NMEA output is using a Pixhawk as a datalogger in a high altitude weather balloon (or glider payload). The NMEA output can be fed into an APRS logger to transmit a redundant position to the ground. This would save from having an additional GPS receiver on board.

[rmackay9]

in case someone wants to take on this development request - it could be done by adding another protocol to the AP_SerialManager class. A new class should be created called something like AP_NMEA_Telem (or whatever) that is similar to the AP_FrSky_Telem class except that it outputs a nmea format string which includes the vehicle's position. The vehicle's position (and velocity?) should be pulled from the ahrs object.
In the main vehicle code a new nmea_output function should be added to the scheduler so that it runs at 5hz. That function should just call the new AP_NMEA_Telem classes's update function.

[k5njm]

Thanks Randy!
I'll update this issue if we attempt to undertake this for our project
--Nick

[magicrub]

This is a discussion in the issue's thread, his post was to "update" the issue :) This is why it's great to have specific tasks/jobs/bugs discussed under an issue.

[gmorph]

@kd5ftn - Hi Nick. Any progress on this?
Thanks, Grant.

[WickedShell]

This was done a while ago by @OXINARF in #10859