GPS V2

[J V R]

I popped round to my local park with the Fun Cub today although I did not fly as they were cutting the grass, so I scooted the cub around the car park as it was empty. Looking at the logs the longitude & latitude do not relate to where I was, dose the GPS V2 have to calibrated before its used.........

[John Privett]

How far out is the location it is reporting?

I know nothing about the GPS V2, but other GPS devices I've used "just work" and have no facility for calibration by the user.

The only slight GPS 'issue' I've ever noticed was with the GPS receiver on a phone I had about 5 or 6 years ago. If it was switched on after moving a long way from it's previous location (eg. flying to Canada and switching it on on arrival) then it would take 10 or 15 minutes to download the "emphemeris data" and be able to work out where on earth (literally!) it was. But whilst it was doing that, it wouldn't try and tell me I was somewhere that I wasn't - it just wouldn't tell me anything!

Maybe somebody who is familiar with this device may have a better answer!

[J V R]

Hi John

51°26'00.6"N 0°02'19.3"E is the location where I was, and this is the log report

002.9803E

5125.8961N

[John Privett]

Hmm, assuming 5125.8961N is meant to be 51.258961N then it thinks you're on the beach just along the coast from Oostende in Belgium! The location you stated however is in Mottingham - is that correct?

On the other hand, as the N coordinate seems to be too high by a factor of 100 in the log, I wonder if the E coordinate is too. That would make it 0.029803E rather than 2.9803E. That keeps you in this country at least! But it's on the edge of a field just south of the M25, about a mile from Clacket Lane Service Station.

[J V R]

Yes John thats the same results I got ( roughly ) & I was in Mottingham. I must admit that this subject is something that I know nothing about........

[Ben B]

Probably the US army knackering GPS in case Russia invade

[Chris Bott - Moderator]

Are you using C9X to look at the data? If yes, and you also have Google Earth installed on the PC, try this:

Once the path to your Google earth PC installation is entered in settings, go back to the log and click the big earth picture bottom left.

This opens your co-ordinates in Google Earth and plots the path of the flight in 3D.

[Chris Bott - Moderator]

A picture off the screen doesn't do the 3D rotatable view justice at all.

[J V R]

I will try that after work thanks.......

[David...]

Has anyone figured what 'Dist' is? If I fly overhead, it just about correlates with GAlt, then when I fly out, it increases, so it appears to be distance from GPS lock point.

Altitude is in Metres and speed units are Km-Hr/100, my average flight speed is 0.45 or 45Km/Hr, which sounds about right to me.

 

BTW, mine takes about 45-60 secs to get a lock.

Edited By David... on 04/05/2014 21:33:03

[Biggles' Elder Brother - Moderator]

I think that "Dist" is what in the trade is called "the Euclidean distance" i.e. the absolute distance by the shortest straight line from initialisation point to current position. So generally this will be a "diagonal" line (a sort of 3D hypotenuse!) but if the model is directly overhead then it would be approximately it altitude.

Notice though that altitude on GPS is not so accurate - the vario (especially the "posh" one!) gives a far more accurate result for altitude.

BEB

[David...]

Hi BEB,

Yes it's definitely the Euclidean Distance; which I determined through experimentation and now by checking on Google Earth because I can see the reading at any instance from the log and know where the model was and where I was and using a simple triangle was able to confirm the reading given by measuring me to the model over the ground and using the altitude and a bit of Pythagoras (Euclidean). BTW I notice when in-flight, the GPS update rate is quite slow, perhaps every 2-5 secs.

I've just been checking the TX source code, noting found by way of calculation, then I think it dawned on me it was done in the receiver, which is getting standard GPS Sentences (e.g. $GPGGA) from the GPS V2 module, then sending that data to the Tx, so no processing/mathematics involved, the GPS does it. Then on closer examination of the standard GPS sentences, I could not find one that gave lat, lon, alt, speed and distance and bearing, so conclude they must use two and combine the results before sending. There are pending source code changes to improve this feature.

[Biggles' Elder Brother - Moderator]

This question of exactly where the system is doing the calculations to derive secondary information from primary measurements has interested me as well.

In my case I was curious to know where the calculations are done for the current sensor's output. The sensor itself obviously measures current and voltage, but it then these primary measurands are multiplied together to calculate the power in Watts. Further the current is integrated with respect to time to derive the mAh's consumed figure. So where is this done?

First thoughts were it done in the Tx - Taranis has a pretty powerful processor on-board that could certainly do that. This would also have the advantage that only two pieces of data would need to be transmitted back.

But on the other hand it would be "neater" from a systems point of view if it were done locally, in the aircraft. But then you'd have to transmit four items of data.

Chris Bott and I discussed this and came to the conclusion that its probably being done in the sensor - as there does seem to be some hardware there that could account for it. But no firm conclusion was reached. Personally, I doubt that its being done in the Rx, but that's just a view I have no evidence to back that!

One thing we have figured out that might be of interest. It appears that "SmartPort" (the system for connecting sensors on the X-series receivers) seems to be just another use of the S-bus protocol! This makes sense of course - if you already have the hardware to deal with a particular comms bus - why replicate the function with something different? Clever.

BEB

Edited By Biggles' Elder Brother - Moderator on 05/05/2014 10:49:29

[David...]

Hi BEB,

I had not considered the sensors, which is highly feasible and note there are firmware updates for some sensors, so yes they could be reconfigured to change the calculations and it might explain why the units currently can't be changed, doing this Tx side would have been a better solution in my opinion though as you say there is plenty of processing capacity available.

Ive just ordered a vario to see what the altitude differences are, yes GPS height calculations are poor, isn't that why most car based GPS units have a pressure sensor too, well Garmin use one anyway. That's made me think, I wonder if it's calculating speed correctly in a climb or dive when the vectors in the horizontal plane get reduced and you need to resolve Z too to get an accurate reading.

Ill check my log files to see what it's sayIng.

Edited By David... on 05/05/2014 19:09:44