Silly question. GPS and time.

[Hughie]

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.

Yes good point, though this is a lot harder to do with DST.

 

[ianwood]

Yes good point, though this is a lot harder to do with DST.

That would be handled in the very simple business logic.

 

[Hughie]

Yes good point, though this is a lot harder to do with DST.

That would be handled in the very simple business logic.

Possible to approximate this sufficient for something like a drone.

But whilst the algorithms are simple, the problems arise in two ways 1) They are in flux and can be changed by a nation or state as it pleases, 2) The bounds of the area affected by a DST profile are not necessarily convenient to calculate using simple business logic (see the Russian timezone areas pre 2014)

Could be dealt with with firmware updates, but if I was supporting this product I would not want that overhead for little benefit.

 

[ianwood]

Not that we need to play solution architect but the entire solution can be encapsulated in one small table:

timezone_ID (pk), timezone_area (polygon), UTC_offset(byte), start_DoY(uInt), end_DoY(uInt)

Changing that table would be trivial and could be done once a year or less.

 

[Hughie]

Oh dear it feels like we are all back at college doing relational algebra.

No that solution would not cut it in practise. No project manager worth his salt is going to burn that many MCU cycles calculating what the daylight savings is in order to work out the filestamp time which could be invalid seconds later.

My point was not that a conceptual solution could not be arrived at, simply that it is more complex than you suggest to arrive at one which can be accomodated in practise. Adding complexity to an engineering solution carries all kinds of costs and risks. Much better to just say you cant do it - manage customers expectations and say it doesnt do it. What happens when you fly 5 yards and actually cross into a different DST profile to the one you spent time working out at startup. What happens if you take off and the time passes the point at which the DST stays in force. What are you going to do calculate the DST every 30s? or something.

What you would probably do is log in UTC (most things on logging systems get "logged" in UTC) or apply an approximate timezone offset.

 

[N017RW]

Does the Naza have a real-time clock?

You get the idea.

 

[Hughie]

Does the Naza have a real-time clock?

You get the idea.

It would need perpetual power. Are you saying it has this ?
And if it does, how does it synchronise with timezone and DST?

 

[N017RW]

No knowledge, it was a question.

Backup battery, super-cap, etc.

It get's the current/local time from the PC/Mac when calibrating, etc.

A stretch for sure but a simple explaination. No?

 

[N017RW]

Further pondering ask's: What about getting it [time data] from the cellphone used as a monitor?

Afterall that's how the dynamic Home Point gets the position data.

 

[ianwood]

No that solution would not cut it in practise. No project manager worth his salt is going to burn that many MCU cycles calculating what the daylight savings is in order to work out the filestamp time which could be invalid seconds later.

We're well off piste at this point, but given that I actually design solutions of this nature, I'll share some insight. Maybe someone will find it interesting. Firstly, a project manager wouldn't make that decision. A product owner and solution architect would jointly make that decision.

My point was not that a conceptual solution could not be arrived at, simply that it is more complex than you suggest to arrive at one which can be accomodated in practise. Adding complexity to an engineering solution carries all kinds of costs and risks. Much better to just say you cant do it - manage customers expectations and say it doesnt do it. What happens when you fly 5 yards and actually cross into a different DST profile to the one you spent time working out at startup. What happens if you take off and the time passes the point at which the DST stays in force. What are you going to do calculate the DST every 30s? or something.

What you would probably do is log in UTC (most things on logging systems get "logged" in UTC) or apply an approximate timezone offset.

No, it's actually not complex at all. And UTC is not user friendly. Most people have no idea what it is or their offset to it. Your edge conditions don't need to be catered for. Any sensible product owner would accept that it's not worth the effort. Other portable things adapt to local time automatically but aren't thrown off by the exact point and time at which they do so. And a number of GPS enabled devices adapt to local time automatically. My four year old car does. You can even buy watches that set themselves automatically by GPS.

Ignoring that you only need to do it once at startup, an 8 bit system could do it repeatedly with ease. The Naza could determine the time zone offset 5 times per second and still do everything else it needs to do. DJI's no fly zones are recurring proximity lookups against a table of almost every major airport on the planet. With a rudimentary geospatial index, it's really easy.

Finally, any GPS system is a precision timing instrument often with localization output built-in. GPS time is broadcast on the Phantom's CAN bus several times per second.

 

[Hughie]

No that solution would not cut it in practise. No project manager worth his salt is going to burn that many MCU cycles calculating what the daylight savings is in order to work out the filestamp time which could be invalid seconds later.

We're well off piste at this point, but given that I actually design solutions of this nature, I'll share some insight. Maybe someone will find it interesting. Firstly, a project manager wouldn't make that decision. A product owner and solution architect would jointly make that decision.

You are right that this discussion is well off piste. Not sure how we got here.

The name of the role of who decides these things depends on the size and structure and culture of the business. So I am sorry to tell you that not all design houses even have "solution architects". However what they will have is someone who carries the design authority for the solution. In some software houses in the UK this *is* a project manager, whose role includes reconciling conflicting objectives - precisely what I was explaining. You shouldn't get so hung up about the name of a job role.

Also you have not mentioned daylight savings explicitly - I think you may have morphed timezones and daylight savings into one entity. They need to be modelled distinctly. Because they can change indpendently of each other.

EDIT: Sorry I missed your comment about UTC. Yes UTC is not user friendly. That is why it is a good thing for logging in global IT systems (I have designed more than one over the years). In cases where the data needs to be logged but you want it displayed in the time context of the reader this is the way to go, and is ordinary layering and architecture, applying presentation of the data closest to the user. I agree this is a moot point for aircraft though and turns out to be irrelevant to this discussion. An independant machine might as well work out the wall clock time and use it.

Interested to learn how you can predict a finite cost for finding a coordinate within a polygon which may have an infinite number of points?

 

[Narrator]

I decided to ask the question on the DJI forums, to see if DJI responded.
They didn't, but a dev wrote the following:

When you connect the cell phone to the Phantom the Vision app syncs the time to the Phantom (I know this because the SDK documents the call that syncs the time to the Phantom and documents that it must be called (it doesn't say what happens if you don't sync it).

 

[Hughie]

I decided to ask the question on the DJI forums, to see if DJI responded.
They didn't, but a dev wrote the following:

When you connect the cell phone to the Phantom the Vision app syncs the time to the Phantom (I know this because the SDK documents the call that syncs the time to the Phantom and documents that it must be called (it doesn't say what happens if you don't sync it).

Thanks for posting Narrator. Good one.

 

[Narrator]

Thanks for posting Narrator. Good one.

Cheers

 

[N017RW]

I decided to ask the question on the DJI forums, to see if DJI responded.
They didn't, but a dev wrote the following:

When you connect the cell phone to the Phantom the Vision app syncs the time to the Phantom (I know this because the SDK documents the call that syncs the time to the Phantom and documents that it must be called (it doesn't say what happens if you don't sync it).

Cool. It seemed like the easiest way to me.

 

[ianwood]

Interested to learn how you can predict a finite cost for finding a coordinate within a polygon which may have an infinite number of points?

I do that several times a week. DST can be expressed in terms of offsets, start and end days. We solved time back in 99.

 

[Hughie]

Interested to learn how you can predict a finite cost for finding a coordinate within a polygon which may have an infinite number of points?

I do that several times a week. DST can be expressed in terms of offsets, start and end days. We solved time back in 99.

Yes DST can be defined in those terms, but you missed out the important one - position. Timezones and DST regions are not analogous.