RC4ever:
What is the right way to set up a GPS wirelessly?
Many of your questions are worded in a way that implies the solution: reading GPS data over the air. This is called the X-Y Problem. Yes, this happens often enough that it has its own website. 
From what you've described so far, I think you want a transponder on the aircraft. In order to aim the base station camera at the aircraft, you need to know the base station's position and orientation. Then you can calculate the gimbal angles to aim the camera.
To get the base station's position, you could do (at least) two different things:
* "Survey in" the base station at start-up. Orient some kind of registration marks on the base or aim the camera to to true north. That will establish the base station's orientation. Then hold the aircraft over the base station and use the aircraft's position for the base station's position (push a button on the base?). Or...
* Use a second Arduino at the base to get the position (from a GPS device) and orientation (from a compass) and send it to the master, wirelessly. This is a kind of transponder, but it seems silly to call it that when it's a transponder for "myself" (the master).
The first approach seems easier to me, because you are simply using the aircraft's capabilities. It avoids using a compass, which can be affected by the metal in the base station... or the table it's sitting on. It also avoids a 2nd Arduino, a 2nd wireless link, a GPS module, and the increased possibility of transmission collisions. This would save you a lot of hardware, a lot of software, and a lot of system integration and testing.
Regardless of which approach you choose, you must implement a wireless link to send positions from the aircraft to the station. Here is the difference between "GPS data" and "position". First, here's the raw NMEA data from the GPS module:
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
That's 65 bytes, and it has to be parsed into 3 numbers by extracting 5 fields, skipping about half the characters. Here is a simple text representation of those 3 numbers:
48.11730,11.51667,545.5
That's 24 bytes, and the fields have to be converted to numbers for calculations. And finally, here is a binary representation of those 3 numbers:
1CAE1E086DD4DCBD516
That's only 10 bytes (displayed with 20 hex characters). I think this addresses your latest comment: "store the GPS coordinates as a byte, then send them over to the main board". It's obviously more than a byte...
And when sent as a binary message, no parsing or conversion is required, because it can be directly mapped onto a structure:
struct Position_t
{
int32_t lat, lon;
int16_t altitude;
};
void send( Position_t &pos )
{
radioSend( (uint8_t *) &pos, sizeof(pos) ); // send the 10 binary bytes
}
With the correct configuration, NeoGPS can parse the raw GPS data into this structure for you, exactly one time per second (or whatever update interval you select). When NeoGPS tells you there's another fix structure ready, just read it and send it:
if (gps.available( gpsPort )) {
gps_fix fix = gps.read();
send( fix );
This is more accurate than sending the floating-point lat/lon/alt, and it's easy to use the fix structure on the receiving end to aim the camera:
if (radio message received) {
float cameraAzimuth = baseFix.location.BearingToDegrees( receivedFix.location );
float distance = baseFix.location.DistanceToKm( receivedFix.location ) * 1000.0;
float dAltitude = baseFix.altitude() - receivedFix.altitude();
float cameraElevation = someTrig( distance, dAltitude );
As discussed above, the receiving end may or may not have a GPS module for setting the baseFix structure. If the base has a compass module for setting orientation, it would offset the cameraAzimuth (see Azimuth and Elevation).
So far this is completely independent of the wireless module you need to select: Xbee? nRF? LoRA? srnet has lots of experience with LoRA. Robin2 has posted a nice nRF tutorial. There must be a bajillion xBee tutorials.
