Messages

1

General Discussion / EASA GA equipment survey – transponder, GPS & collision avoidance/warning system

« on: December 03, 2016, 07:05:23 pm »

A short survey by EASA on your transponder, GPS, traffic, etc, equipment.
If you have a minute or two (for most of you, I'm sure that is all it would take), please can you complete and send back?

Instructions here:
http://fasvig.org/easa-ga-equipment-survey-transponder-gps-collision-avoidancewarning-system

Thanks,
Steve

2

General Discussion / Re: What's the status of FLARM ?

« on: June 22, 2016, 11:51:20 pm »

If my understanding of FLARM is correct, it is not a like-for-like comparison with PAW.

PAW detects other suitably electronically conspicuous aircraft and passes information about them to another device so that second device can display that information. So PAW is a traffic detection system.

FLARM seeks to be a collision avoidance system. FLARM seeks to detect and analyse the position and trajectory of other FLARM-equipped aircraft and compare that, using algorhythms suited to the manner in which gliders fly/are flown, with the position and trajectory of the user's own aircraft and determine if there is a conflict. Gliders often tend to fly in gaggles close together circling in thermals so the pilots of those gliders are often well aware of the presence of the other gliders but FLARM is providing that extra layer of protection against misjudging your own flight path relative to the others around you.

What I am trying to say is that FLARM and PAW are similar but were not actually designed to do exactly the same function.

And then there is PowerFLARM, which adds in detection of ADS-B/Mode C/Mode S, but that is a whole other story.

Steve

3

General Discussion / Re: PilotAware plus Mode S

« on: May 28, 2016, 09:31:53 am »

Only other PAW devices will see both your transmissions. If you have configured both your Mode S ES and PAW correctly to use your ICAO hex code then those other PAW devices ought to recognise that you as a P3I target and you as an ADS-B target are one and the same aircraft.

4

General Discussion / Re: Ground Based Transponders

« on: May 28, 2016, 12:15:21 am »

Hi Alan/Peter,

Sorry, I was not intimating that these currently identified ground targets were ADS-B. I was just pointing out that this scenario will be repeated at some point in the future once ground vehicles with ADS-B out start to become commonplace.

So, PAW and PAW users will need to decide how they should be handled. When that day comes, I am not sure that simply trying to filter them out will always be the best option. This will need a bit more careful consideration. There is no reason why a GA aircraft shouldn't benefit from a warning of a vehicle on the runway, just the same as is the intention for CAT systems.

Regards,

Steve

5

General Discussion / Re: Ground Based Transponders

« on: May 27, 2016, 09:56:49 pm »

Don't forget that ADS-B is also designed for use by airside ground vehicles to aid collision aviodance while taxying, or to help ensure the runway is clear just prior to take-off. Maybe there is a flag in the ADS-B messages that indicates these are ground vehicles. I have not looked.

I also recall some discussion about NATS putting an ADS-B Out device on a crane as a trial. Don't know whether that actually happened.

Steve

6

General Discussion / Re: Distinguishing PAW, ADS-B and Mode S

« on: May 23, 2016, 11:19:58 pm »

See definitions in Part 3 here:
http://www.icao.int/APAC/Meetings/2016%20ADSB%20SITF15/IP08_USA%20AI.4%20-%20ADS-B%20Avionics%20Performance%20Report-2.pdf

SILs - Source Integrity Level Supplement
This is a one bit field that informs the system if the SIL is being given on a per hour or a per sample basis, assigned as 0 or 1 respectively

There are two reason I know of why SIL or SDA may be empty:
1) ADS-B is not just one single message. It is a set of discrete messages with differing content sent at different times. For a given aircraft, your PAW may not yet have seen the message from that aircaft that contains the SIL or SDA.
2) ADS-B version 2 is the most recent version. I am struggling to remember the detail (I have posted it here previously) but if I remember correctly v0 does not support SIL or SDA. V1 does not support SDA but does support SIL, though the v1 definition of SIL is different to the v2 definition of SIL.

Steve

7

General Discussion / Re: Installation with Garmin mode S transponder

« on: May 14, 2016, 06:18:35 pm »

As Paul says, a PAW-To-Transponder connection is nothing to do with picking up other traffic.

To get an ADS-B capable Mode S transponder to output ADS-B you need to feed the transponder with GPS position data.

I have been contacted by one Garmin 330ES owner who has had a VERY hard time getting ADS-B out sorted and it is still not resolved. First he upgraded the 330 to a 330ES. Then connected his Garmin 496 to the 330ES to enable ADS-B Out but it did not work (having previously been told by the supplier that it would). So..... He was then advised to buy a Garmin GPS20A (a non-certified GPS) which he did. That finally worked.

HOWEVER, he then discovered it was not possible to configure the Garmin 330ES to broadcast the required SIL=0 and SDA=0 parameters that are required for use by LAA & BMAA aircraft using a non-certified GPS ADS-B Out setup. He found the lowest possible SIL setting on the Garmin 330ES is SIL=1. As of now this is not compliant with the requirements for ADS-B Out using a non-certified GPS

So..... Beware the Garmin 330ES.

Steve

8

General Discussion / Re: When willl the PAW be ready?

« on: May 06, 2016, 10:39:50 am »

Hi Ian,

Started this reply before Alan and Moffs responded but have posted anyway as it adds a little more info.

The key thing is that most Mode S transponders out in the field today (in GA aircraft) were not design to broadcast ADS-B , i.e. are not ES capable (Extended Squitter). And of those that are ES capable, the vast majority of those will not currently have a connected GPS to provide position data to the transponder and so will not be broadcasting ADS-B data. So, right now there are relatively few GA aircraft which are broadcasting ADS-B data.

The main reason why basic Mode S was introduced was to reduce the rates of transmission. With Mode S the ground station can interogate individual transponders by including the ICAO hex code of the target transponder and only that target will respond. With mode A/C the problem is that all Mode A/C transponders respond to every interrogation.

So.... PAW needs to calculate threat distance for non-ADS-B Mode S transponders based on signal strength plus can see relative height separation from the target's broadcast altitude. PAW also calculates threat distance and bearing and relative height from Mode S that is broadcasting ADS-B data but that is far simpler using the broadcast GPS position data. PAW can ignore any 'pure' Mode S broadcasts from the ADS-B broadcasting aircraft because it can correlate the same ICAO hex ID in the ADS-B messages and the 'pure' Mode S messages. I also believe that same Mode S transponder also outputs some  'pure' Mode A/C style messages (with no ICAO hex) and these are ignored too.

The difficulty as I understand it with trying to assess threat distance based on signal strength for Mode A/C broadcasts is to do with trying to correlate the Mode A/C data and Mode S data from the same aircraft, which I have been advised is almost impossible and hence presents the problem of systems showing two discrete threats when there is actually only one.

Steve

9

General Discussion / Re: When willl the PAW be ready?

« on: May 05, 2016, 04:46:48 pm »

Ian,
Extended Squitter (ES) is the function of transmitting ADS-B data from a Mode S transponder. Not all Mode S transponders are ES-capable. And ES-capable Mode S transponders need to have the ES function switched on plus be in receipt of valid position data from a connected GPS device.

It is also possible to have devices that only do ES, i.e. ADS-B Out, without the rest of the non-ES Mode S conventional transponder functionality. That is what the demo NATS LPAT (Low Power ADS-B Transceiver) does, as per CAP1391 (plus ADS-B In and very basic Mode C&S range detection).

Steve

10

General Discussion / Re: NMEA output to autopilot

« on: April 26, 2016, 06:18:55 pm »

According to this post on the TT customer forum, you have to return the 380 for upgrade to a 385.
http://trutrakap.com/forum/forum/autopilots-and-instruments/vizion-series/760-vizion-380-or-385-for-my-ctsw

Interestingly, both the TT website and Aircraftspruce are only listing a single price. Did you check with TT that they still do the 380 version?

I agree with you. There are thousands of the Vizion APs and predecessors in use in the field. It will cost more than an Eco but it is proven technology that is relatively straightforward to install.

I know someone that has a TT Vizion installed in an RV-9 and last time I talked to him he was happy with it.

And, if you have space for a 3 ^1/8th inch unit, there is the option of the TT Gemini AP. Does the same as the Vizion with the addition of a builtin digital attitude/ASI/Altitude display but for a bit more money.

Regards,
Steve

11

General Discussion / Re: NMEA output to autopilot

« on: April 26, 2016, 02:24:16 pm »

Hi Michael,

Sounds like you have not yet decided which version of the TT Vizion to buy. Is that correct?
You can upgrade the 380 to a 385 later, if desired.

If you want the AP to be able to fly a pre-planned route, e.g. to automatically execute turns, etc, then there needs to be an element in the system that tells the AP where you want to fly as well as where you are.

On its own, Pilotaware can only provide data on where you are. It has no knowledge of your planned route.

You probably know this already, but without route following capability, the AP will ordinarily, when activated, maintain the current heading and allow you to set a new heading via the AP controls. And if it is a 2-axis AP then you can also hold altitude. Some, including the 385, allow setting of climb/decent rates and even target stop altitudes.

My AP is 2-axis and is capable of automatically executing climbs and decents if you input these into the route plan AND you run the AP in the correct mode.

Regarding the NMEA sentences that Pilotaware outputs, I forget which ones they are but you ought to be able to find confirmation somewhere in this forum or in the Pilotaware documentation.

If you buy the TT Vizion 385 you ought to be able to replicate my redundant input wiring if you have access to both NMEA data and ARINC data.

By the way, if you've not had dealings with them, my experience of support from TT is excellent. Lucas has always been very helpful to me.

Regards,
Steve

12

General Discussion / Re: NMEA output to autopilot

« on: April 26, 2016, 11:17:15 am »

Hi Michael,

I have Advanced Flight Systems (AFS) kit in the plane I am building, which includes an AFS autopilot, which is a Trutrak AP with slightly customised software to allow control from the AFS EFIS. Basically a GPS feeds data to the EFIS and the EFIS feeds data onward to the AP via an intermediate ARINC module.

The above allows the AP to run in its most advanced modes. There are lower capability modes that the AP can run in where the ARINC input is not used and instead it takes input direct from an NMEA capable GPS and in these modes it just needs a couple of NMEA sentences (as you have mentioned previously).

I suspect your TT AP is relatively close functionality-wise to mine. So, if you only wish to use the lower level modes then those NMEA sentences are probably all you need. A key requirement though is that the update rate is atleast once per second for best flight accuracy.

I have built my system to to allow the AP to run on ARINC data from the EFIS but to be switchable to a direct GPS NMEA feed (utilising a different GPS) for redundancy.

Steve

13

General Discussion / Re: Audible alarm

« on: April 14, 2016, 07:35:12 pm »

Julian,

In a PAW/SD setup, to my knowledge, neither device is performing any trajectory analysis to assess which if any traffic is on a converging collision course and is thus a direct threat.

Warning on proximity alone can be problematic. The nearest traffic may not be the one on a converging collision course, so a proximity warning might distract you from other traffic that you really should be worried about.

The exiting NATS LPAT demonstrators do not do trajectory analysis either. They include Funke TM250 technology that I believe does proximity warnings.

The two GA technologies that I believe do trajectory analysis are FLARM/PowerFLARM and the various units that Air Avionics manufacture. Note that these use different algorythms for the trajectory analysis, so might give different answers when presented with the same traffic data. The FLARM algorythms are based on glider flight profiles whereas Air Avionics are based on powered aircraft flight profiles (at least that is what I was told by someone that works for Air Avionics).

Steve

14

General Discussion / Re: New CAA low power portable ADS-B device spec

« on: March 28, 2016, 11:22:14 am »

John,
See very first post on this thread.
Steve

15

General Discussion / Re: New CAA low power portable ADS-B device spec

« on: March 25, 2016, 04:50:39 pm »

Hi Alan,

I very much put PilotAware in the category of 'manufacturers'. They have already announced they will be selling complete devices. See here: http://pilotawarehardware.com/product/pilotaware-complete/. And they can provide feedback to the CAA via the manufacturer survey if there are any aspects of the proposal that they feel need improving.

There has not been a sudden rush to produce the CAP 1391 proposal. It has been under development for a significant time and the related Project EVA work has been ongoing for a long time now. Just google LPAT and Project EVA. You can even read about them on this very forum. Nothing has been hidden.

I do take exception to you questioning my honesty. I have never sought to undermine PilotAware. You are free to search my posts here and on the Flyer Forum. I was asked by Lee if I would join the PAW Technical Committee and I politely declined on the basis that I supported a standards-based approach to electronic conspicuity so I have been very straight. I have focussed my involvement in PilotAware on the parts of PAW that support the ADS-B standard. And On that score I am pleased that PilotAware have been able to provide benefit to the GA community.

EDIT
I see you have amended your post Alan, but saying "more honest" is still not saying "honest" so I still take exception I am afraid. I have never acted other than what I see is in the best interests of the GA community.

Regards,
Steve