app_gps: Code updates and documentation

[KB4MDD]

This updates app_gps with the following changes:

Update the code to use the asterisk coding guidelines. Added documentation to all functions.
Added documentation to gps.conf.
Added functions: GPS_READ and APRS_SENDTT.
Added the cli command gps status.
Added the ability to select the primary or alternate symbol table. Replaced depreciated ast_gethostbyname.
Addressed issues with module unload not completing timely.

GPS_READ() function replaces the need to create the gps.dat file stored in the /tmp directory. The application previously wrote to the disk once per second, which included a system call to rename a temporary file.

app_rpt and chan_echolink have been updated to use GPS_READ to retrieve the gps data, instead of reading a data file.

APRS_SENDTT(stanza, overlay) = callsign, function replaces the pipe that was used by app_rpt to send APRStt requests to app_gps.

APSTAR is now used as the tocall for both APRS an APRStt posts. This is being registered as the tocall for AllStar Link.

If elevation is available, it is included in the APRS post.

The cli command 'gps status' will allow the user to check the status of the attached GPS device. It tells the user if the GPS device is connected, if it is locked to the satellites, and the current and default position.

The unlocked warning message is now only printed when it first occurs. The message is turned back on when we receive a lock on the satellite.

The gps.conf file now has an entry for icontable. The default is '' primary or '/' for the alternate symbol table.

For APRStt to work, the aprstt entry in app_rpt needs to be enabled. That option has been added to rtp.conf and commented out.

There were a number of refinements to the code, along with fixes for memory leaks.

[mkmer]

Nice work! This should really help save the memory cards on PI's.
Just a few comments around format stuff.

[KB4MDD]

@InterLinked1 @mkmer

Regarding adding warning messages if the new functions cannot be found. I will be glad to add that. I will note that if I don't check for the function and app_gps is not loaded, the core function handler will send a warning message that the function does not exist. (I ran into this and decided to add the check.)

I will note that this is really only an issue if the enables a dtmf command that uses one of the functions. If they are doing that, I would like to think they would have enabled app_gps.

What is the preference - leave as is, add a warning message that the function is not there (preserving my if), or removing my test and allowing the core function handler to report the problem?

[InterLinked1]

@InterLinked1 @mkmer

Regarding adding warning messages if the new functions cannot be found. I will be glad to add that. I will note that if I don't check for the function and app_gps is not loaded, the core function handler will send a warning message that the function does not exist. (I ran into this and decided to add the check.)

I will note that this is really only an issue if the enables a dtmf command that uses one of the functions. If they are doing that, I would like to think they would have enabled app_gps.

What is the preference - leave as is, add a warning message that the function is not there (preserving my if), or removing my test and allowing the core function handler to report the problem?

In this case, keep as is (checking before call). We don't want to emit spurious warnings either.

[Allan-N]

I'm making one of my last passes over these changes and, again, want to raise the issue of using a monotonic clock. I have observed a bunch of places in the code where we are still comparing the time returned by the GPS_READ function and comparing that to what's returned by a call to time(&t). In these instances I think we really want to get away fro time(&t).

Here's a thought. When we are saving the current time for future calls to GPS_READ we should store TWO timers (e.g. extend the position_info struct to have both values). One would be epoch based and one would be monotinic. The calls to GPS_READ should return BOTH time values. Then, if the code needs to report when the data was captured it will use the epoch value. But, if the code is checking the elapsed time it would use the monotonic value.

And, as an aside, you might want to think about having a single/shared function to check for the availability of the GPS_READ function, to make the call, and to return the results (or an indication that the data is not available).