Silly question. GPS and time.

Joined
Nov 15, 2014
Messages
347
Reaction score
6
Location
Melbourne, Australia
I have been wondering where the camera in my V+ gets its time stamps from.
Then it occurred to me, it probably comes from the GPS data.
Would this be true?
 
What do yo mean? Like recording time? Mine doesn't 'stamp' as much as just shows recording time, until I xfer it to the comp, then it stamps it> Is that what you mean?
 
Prylar Bek said:
What do yo mean? Like recording time? Mine doesn't 'stamp' as much as just shows recording time, until I xfer it to the comp, then it stamps it> Is that what you mean?
Huh? He's asking how the file's creation time is generated on the filesystem when the images/videos are saved.
 
First let me say I don't have a V+.

But are you sure you're not talking about the file's time/date/etc when you up load to your PC?
That has nothing to do with GPS data from your a/c.
 
N017RW said:
First let me say I don't have a V+.

But are you sure you're not talking about the file's time/date/etc when you up load to your PC?
That has nothing to do with GPS data from your a/c.
Yep.. I'm sure.
The file time stamps match the time of recording, not the time of uploading to the pc. Also, the uploading takes only a couple of minutes, but each file is stamped as being about 20 min apart - the life of each battery.
 
The GPS clock is UTC I beleive thus requiring some addtional input (offset) to convert to your local time.

My guess is it (the Naza) is sync'ed with your PC clock during upgrades, calibrations, etc.

Curious to see what others may think.
 
N017RW said:
The GPS clock is UTC I beleive thus requiring some addtional input (offset) to convert to your local time.

My guess is it (the Naza) is sync'ed with your PC clock during upgrades, calibrations, etc.

Curious to see what others may think.
I read Wikipedia regarding GPS. It said something like this: The receiver must get 4 GPS signals, from which it calculates the actual time, based on angles and time stamps from the satellite telemetry. (Something like that anyway.) :p
 
Separate issue.

True, GPS is time based.

However local time is irrelevant to positioning.
 
Tell me if I'm reading this wrong.

http://en.wikipedia.org/wiki/Global_Positioning_System#Non-navigation_applications

In typical GPS operation as a navigator, four or more satellites must be visible to obtain an accurate result. The solution of the navigation equations gives the position of the receiver along with the difference between the time kept by the receiver's on-board clock and the true time-of-day, thereby eliminating the need for a more precise and possibly impractical receiver based clock. Applications for GPS such as time transfer, traffic signal timing, and synchronization of cell phone base stations, make use of this cheap and highly accurate timing. Some GPS applications use this time for display, or, other than for the basic position calculations, do not use it at all.
 
GPS systems broadcast UTC time. They also broadcast their position. The combination of the two can be used to determine how far you are from the satellite which combined with other satellites can determine your location (oversimplified).

GPS signals do not help with determining what UTC offset applies to your location or if any daylight savings functions are in place. Therefore they will need ground based information to determine the local time.

That ground based information could be held in the Naza firmware as it doesn't change often. Make all this information available to the controller that writes files to the SD card, it should be able to apply a localized date and time stamp.
 
Yes, it is included with GPS data, as was stated earlier.
 
ianwood said:
PhantomFanatic said:
Yes, it is included with GPS data, as was stated earlier.

Local time is not included with GPS data.

From the same page I linked earlier:

The GPS navigation message includes the difference between GPS time and UTC. As of July 2012, GPS time is 16 seconds ahead of UTC because of the leap second added to UTC June 30, 2012.[109] Receivers subtract this offset from GPS time to calculate UTC and specific timezone values. New GPS units may not show the correct UTC time until after receiving the UTC offset message. The GPS-UTC offset field can accommodate 255 leap seconds (eight bits).
 
I assume that the UTC time is derived from GPS. What other options are there.

This really is a question about where does the Phantom get its timezone info from. This could be done as has been suggested based on the PC clock that the assistant is on. I would be interested to see if in addition to timezone, the daylight savings time (DST) profile is taken account of. These can be fiddly to apply on an international product. Even where DST is defined it can still have exceptions. For example Arizona I believe has regions which do their own thing.

Great question - not silly.
 
Narrator said:
ianwood said:
PhantomFanatic said:
Yes, it is included with GPS data, as was stated earlier.

Local time is not included with GPS data.

From the same page I linked earlier:

The GPS navigation message includes the difference between GPS time and UTC. As of July 2012, GPS time is 16 seconds ahead of UTC because of the leap second added to UTC June 30, 2012.[109] Receivers subtract this offset from GPS time to calculate UTC and specific timezone values. New GPS units may not show the correct UTC time until after receiving the UTC offset message. The GPS-UTC offset field can accommodate 255 leap seconds (eight bits).


GPS to UTC offset is different than the offset for UTC to local time.
 
GPS to UTC offset is different than the offset for UTC to local time.

Yes a completely different beast. All this needs doing :

GPS ->UTC (using GPS offset)
UTC->Local (using timezone)
Local->Wallclock time (using daylight savings for local region)
 
Hughie said:
I assume that the UTC time is derived from GPS. What other options are there.

This really is a question about where does the Phantom get its timezone info from. This could be done as has been suggested based on the PC clock that the assistant is on. I would be interested to see if in addition to timezone, the daylight savings time (DST) profile is taken account of. These can be fiddly to apply on an international product. Even where DST is defined it can still have exceptions. For example Arizona I believe has regions which do their own thing.

Great question - not silly.

More easily and accurately implemented in Naza firmware using very simple business logic and polygons as has been done with no fly zones.
 

Recent Posts

Members online

No members online now.

Forum statistics

Threads
143,066
Messages
1,467,352
Members
104,933
Latest member
mactechnic