glidernet / diy-tracker

Do-it-Yourself OGN Tracker software
GNU General Public License v3.0
27 stars 18 forks source link

GPGGA/GPRMC from an external source #12

Closed kicune closed 6 years ago

kicune commented 6 years ago

Not an issue, rather a polite question: do you have any plans (or better yet, any progress?) to receive NMEA GPS coordinates from an external source, say, on RX3/TX3 UART?

There is a note mentioning "read NMEA user input" in main.cpp, but I am not quite sure what it should comprise.

And if there is indeed some plan to implement this, how high a priority that one is (meaning: should I wait patiently, or would you recommend me to start hacking instead)?

Anyway, this one is a fantastic project - thank you a lot for your effort & keep it up!

pjalocha commented 6 years ago

What external source do you have there ? You can feed this source into UART2, simply instead of the GPS. The only thing is the timing. Ideally you provide the PPS, if not the tracker get get less precise timing from the UART2 data arrival. Why don't you try with the source you have already ?

kicune commented 6 years ago

Oh, you are right! I don't know why I got the idea that the GPS module is connected via SPI, silly me. :|

The NMEA data would come from existing logger installation. The logger publishes a bunch of other stuff in addition to GPGGA/GPRMC, but as I checked the source, this should not pose a problem. There is no PPS available, though, sadly.

In addition, there is also PGRMZ altitude information available in the logger NMEA stream, but it's probably not worth digging it out - these BP180/280 works quite nicely and they have no special needs regarding orientation and signal reception as GPS does.

I'll check it out, many thanks for your suggestion!

pjalocha commented 6 years ago

I can read the PGRMZ, no problem. I just hear that the PGRMZ has double definition: it can send pressure altitude or pressure altitude corrected for QNH.

The important thing is the timing: we need to know the delay from the start of the second to the start of the GPS data, and hopefully this timing is stable. This can be worked out. I think you can try already: just connect the GPS data source to the OGN tracker and see what comes out on the console, it should as well start transmitting.

kicune commented 6 years ago

Well, I have to say it worked rather nicely! I connected the TTL outputs to UART2 and was able to see GPGGA/GPRMC sentences right away. It wasn't even necessary to recompile the tracker without gps_pps support. I yet have to test it with GPS lock and RF transmit, but at the moment I am still waiting for my RF modules to arrive. It will be also necessary to test it with direct logger output, as my test setup just utilized the "NMEA output" device in XCSoar. But - it's a promising start!

Why it is necessary to know the pps delay anyways? Is it something with synchronization between various connected devices?

Yes, PGRMZ can be a pain in the ass, if I understand it correctly - for Garmin it's baro altitude, for others (eg. FLARM) it's pressure altitude. Make your pick. Just another reason to use a dedicated sensor, fwiw...

One other question, if I may: How does the PFLAA support works? It seems to me that it is hidden behind WITH_PFLAA ifdef; this is however not published as an option in the makefile. Will the "standardized" FLARM-like output work, if I enable it manually?