GPS Question..Please help

[ATCast]

Slight thread drift here, but I have to correct some inaccuracies.

Originally Posted by FlightPathOBN

What I find humourous, that in the same document, they mention rollout beginning in 2008, most in 2010, and the rest by 2013...then later in the document, they say that FAA will define the strategy for ADSB by 2012, with full implementation by 2020! (This doc was from 2009) Now the deadline is to first tier ADSB by 2020, with ADSB out by 2030...
Put this right along side of the microwave landing systems, byt the time it gets sorted out, the technology is hopelessly outdated and wont be used...

I won't deny anyone's right to be skeptical but if you read carefully you'll see that the 2008-2013 time frame refers to the deployment of the ground infrastructure by ITT.
The 2012 date is when the FAA would define its strategy regarding ADS-B IN, that is the capability of an aircraft to receive ADS-B signals from other aircraft.
The full implementation (2020) refers to the ADS-B OUT rule, mandating aircraft to broadcast ADS-B.

[FlightPathOBN]

Right, I get that, but that is why I found in humorous, that they would have all of the ground equipment in place without the signal specs sorted out.

I think we are talking about the same thing on the deadlines, and now the 2020 deadline is for ADSB out, and ADSB in is 2030...

I am not skeptical! I am cynical! The ADSB system is already over 50 years old. A 'new' system of ADSB in and out is still based on the same signal, protocal, and syntax. That is why I feel that by 2020, the system will be hopelessly outdated in terms of software, electronics, and the aircraft that use it. We already know that a passenger with an internet connection, can see all of the ADSB aircraft on flight aware, while the crew cannot?

A 2020 aircraft electronic system will look like what....and will have to be downward compatible to the ADSB system?

[aterpster]

FlightPathOBN:

I am not skeptical! I am cynical! The ADSB system is already over 50 years old. A 'new' system of ADSB in and out is still based on the same signal, protocal, and syntax. That is why I feel that by 2020, the system will be hopelessly outdated in terms of software, electronics, and the aircraft that use it. We already know that a passenger with an internet connection, can see all of the ADSB aircraft on flight aware, while the crew cannot?

Have you written about this to the FAA Administrator, Congress, Aviation Week, and the Washington Post?

[twistedenginestarter]

Airbourn gps aims to acquire 4 satelites to triangulate lat, long positions and also altitude. Ground based gps such as cell phones obviously dont require altitude hence will acquire 3 satelites.

I don't think that is true. Three satellites will fix your position and therefore will give you altitude (although remember this is altitude above a notional earth surface). You need the fourth satellite to resolve the time. Without knowing the time, you can't use GPS. If you had an atomic clock, you'd be alright but without one of those handy, you need to get an extra satellite so the GPS can work out what the exact time is.

Of course, typically nowadays your GPS is magically picking up way more than 4 satellites, and thereby averaging out errors.

[FlightPathOBN]

Sorry twisted, but that is not correct, it may help for you to read the entire thread.

Have you written about this to the FAA Administrator, Congress, Aviation Week, and the Washington Post?

I am sure they are well aware, or this system would be in use already, not 2020 or 2030, when all of them will be just a repressed memory...

It is best to let them flail around, while working 'off their radar', and profit from the aftermath.

[FlightPathOBN]

this is an interesting document... that details how some of the different systems work, depending on manufacturer..

Review result of ADS-B Working Group Meeting

On Airbus aircraft, the HIL (Horizontal Integrity Limit) parameter is provided by the GPS (MMR – Multi Mode Receiver- or GPSSU –GPS on Airbus aircraft) through the IRS (Inertial Reference System) bus.
Indeed, current transponders are not able to receive information directly from the GPS system, so the IRS is used as a “mail box” for GPS parameters (position, velocity, and HIL).

Honeywell:
“The answer to your question is that we follow Arinc 718A. Thus, for calculating the NUCp value used in BDS 05 and 06, if HIL label 130 is unavailable, then the transponder will use HFOM label 274.”

Honeywell and Collins:
Rockwell Collins also answered to Airbus query by indicating that the transponder TPR-901 822-
1338-021 uses HIL (label 130) as an initial source for computation of NUCp, and HFOM (label 274) if HIL is not available. Honeywell and Collins transponders have the same behaviour concerning the encoding of NUCp.
HIL is the primary source, HFOM is used if HIL is not available. This is compliant with Arinc 718A and OACI, annex 10, amendment 77.

ACSS:
“The XS-950 -10005A transponder sets the "Type Code" based strictly on the received value of HIL (Label 130). For airborne position extended squitters (BDS 0,5), if Label 130 is not received, the "Type Code" will be set to 18. This "TypeCode" = 18 corresponds to a NUCp= 0.
For surface position extended squitters (BDS 0,6), if Label 130 is not received, the "Type Code" will be set to 8. This "Type Code" = 8 corresponds to a NUCp = 6

On a side note, even though Honeywell provides the GBAS system, their MMR cannot receive the signal, only the Collins MMR can.

[twistedenginestarter]

Sorry twisted, but that is not correct, it may help for you to read the entire thread.

Well FlightPAthOBN, in may not be correct but it's consistent with Wikipedia:

Three satellites might seem enough to solve for position since space has three dimensions and a position near the Earth's surface can be assumed. However, even a very small clock error multiplied by the very large speed of light[37] — the speed at which satellite signals propagate — results in a large positional error. Therefore receivers use four or more satellites to solve for both the receiver's location and time.

[ATCast]

I am not skeptical! I am cynical!

Ah,you must be working in the industry for a while then!

Right, I get that, but that is why I found in humorous, that they would have all of the ground equipment in place without the signal specs sorted out.

The ADSB system is already over 50 years old. A 'new' system of ADSB in and out is still based on the same signal, protocal, and syntax.

That is not really consistent is it? .

Version 2 of the ADS-B Transponder MOPS was published in 2009. The FAA ADS-B implementation is based on that MOPS (the Australians use version 0 (published in 2000), Europe will also be on version 2) .
Things that still needed sorting out at that time were system integration aspects like the maximum allowable latency between the GPS and the transponder (ADS-B OUT) and between the transponder and the CDTI (ADS-B IN

We already know that a passenger with an internet connection, can see all of the ADSB aircraft on flight aware, while the crew cannot?

Yes, it is sometimes frustrating to see that technology outside aviation advances so much quicker than inside. However, the internet applications don't care about accuracy, integrity, availability, continuity. Being involved in GBAS, you probably do. But I see how people become cynical after spending some time in this business.

A 2020 aircraft electronic system will look like what....and will have to be downward compatible to the ADSB system?

The problem with ADS-B, or any surveillance application, is that it doesn't really help to have only one or two aircraft equipped. It's very nice to see a couple of other aircraft on your screen, but it doesn't really help if the one you're about to fly into is not visible.

A 2020 aircraft electronic system, when starting from a blanc sheet, will integrate all on board systems so that they all communicate with each other and all data can be shared with external parties. Those parties (e.g. other aircraft) can for example upload suggested trajectory changes to the aircraft and negotiate more efficient routing. Of course all very secure, and it does never fail.

By the time the 2020 system is certified it will be 2030 (if we're lucky) and then it will go into production. Unfortunately our first 2020 technology aircraft, when coming of the production line in 2030, will not be able to use this technology to its advantage because the other aircraft, designed before 2020 are not forward compatible. But this will change; over time more and more A2020 and B2020 aircraft will fly and you'll start to get the first small advantage after 10 years (by this time the operators that bought the multi million 2020 package are really wondering why they spent so much money, ask the early FANS adopters).
Now while these model 2020 aircraft roll of the production line, the 2015 model is also still being produced, and it turns out to be a huge cost to retrofit them with the 2020 package, it's uneconomical to do it.
Typically an aircraft systems design is produced for 15-20 years, and an airframe lives for 30 years until it is retired. So the 2015 model, which went into production in 2020, will be produced until at least 2035 and the last one will not retire before 2065.
So when we are in 2070, finally all aircraft will be compatible with the 2020 package, which then can finally be used to it's full advantage. Of course someone will then come here on Tech Log and ask why they don't use 2070 technology.

If not dead, I'll be cynical by then

[FlightPathOBN]

AT,

Concur!

I unfortunately am in the business, primarily with RNP and GBAS procedure design, so I have to know the inner working, because the design criteria, is well...unusable.

As I have tried to show in the posts, the different flight management systems, use data differently. This hasnt helped in moving this forward, as everyone wants their system to be the standard.

In reality, the FMC is an 8 bit system, and due to the liability and certification issues, it is very difficult to change, thus we are locked into 8 bit protocols, and still doing crazy things like following a magnetic compass direction.

All of the capabilities you are talking about, are already there, trust me.

[ATCast]

FP, glad to see we share some frustration!
Don't get me started about the FMS!

As I have tried to show in the posts, the different flight management systems, use data differently. This hasnt helped in moving this forward, as everyone wants their system to be the standard.

Being involved in standardization myself, I know what you are talking about. It's a dreadful slow process to get things aligned, especially when the FMS is involved.

All of the capabilities you are talking about, are already there, trust me.

I know! But because everyone is doing it their own way there is no interoperability. Not between different aircraft and not even between different systems onboard an aircraft. You want to design a new application that needs access to (not changing, just looking at) the current FMS flight plan? Can't be done. You want to extract a published route from the database? Can't be done either.

If we want to make progress in air traffic control with respect to flight path optimization, the FMS needs to be interoperable with the outside world. Otherwise we will be stuck to static routes forever, meaning that CDA's / OPD's can not take into account the traffic picture. That means either no optimized descent, or a lower throughput on the airport. Or a CDA until 3000ft and then some 30 odd miles vectoring at low altitude and low speed (preferably so slow that at least some flaps have to be selected) while pouring the fuel overboard just to re-achieve a nice approach spacing that was screwed up because the unpredictability of the speeds during the CDA.
I would love to see the ability to code an approach path with some waypoints that can be placed freely (within a constrained area) by the FMS in order both optimize the descent profile and meet time constraints (e.g. spacing from another aircraft) at the same time by stretching or shortening the route. And when the systems is redesigned for that anyway, please make planned final approach speed, current wind speed / heading and minimum clean speed or any inside data for that matter available to an external interface as well.

[FlightPathOBN]

AT,

Well, there are concepts, mostly on my machine only, that do much of what you are saying.
I know that idle descent doesnt work in a queue, and you cant optimize the spacing or even get close to radar sep with that.
Then there is the wake sep restraint, which must have been created by the same people who calc global warming, because there is about as much real time science in both.

Given what you said about 3000 feet, and you are with ASA, you may have an idea of some of what I am alluding to.

The concept has gone far from what we originally talked about, in several ways. One doesnt need to create floating waypoints, you just need to let the waypoints float in the system, which is currently easy to do.

If the aircraft has a Smiths box, well, there is some architecture there that can be used very effectively. Others it a bit more of a challenge, but still currently capable.

This is all available right now, and procedures to take advantage, that are within existing criteria (using the inner workings of the calcs in the criteria)

As I said in a previous post,
It is best to let them flail around, while working 'off their radar', and profit from the aftermath.

Perhaps it would be interesting to introduce ourselves.

[FlightPathOBN]

AT,

EHRD? guess you are not with ASA....