Mode A and Mode C

[dimme]

So I was wondering why Mode A and C transponders are not supported?

Given that you have an on-board GPS unit, and you know the RSSI from other Mode A and C transponders, and given that the aircraft is moving through the air, localization should be possible even for Mode A and C transponders by using a simple free-space path loss propagation model (the air doesn't have many reflectors anyway).

Slides 10 and 11 present a simple solution: http://www.eit.lth.se/fileadmin/eit/courses/etin10/2014/LectureA3_Positioning.pdf

E.g. the RSSI for the last X known positions could be used to estimate a static position, and since the other airplanes are moving through the air the next position could be estimated by adding the newest sample and discarding the oldest one (rolling estimation). Kalman filtering could also be applied to get rid of most of the errors.

/Dimitrios

[Paul_Sengupta]

There's beta software in the pipeline which does this.

Not much flying going on at the moment to give it a proper test though.

[dimme]

Sign me up for it =)

[SteveN]

If there is Beta SW it is invisible to this forum.

[dimme]

So you don't want a beta tester that has access to an airplane and is willing to fly it up for you?

[Admin]

ModeS detection is working pretty well in the Engineering Prototype.
ModeA/C is proving a little more difficult, this is due to the slightly different way that ModeA/C is transmitted.
This leads to potential sampling errors when using Software Defined Radio.

This is not a simple problem to solve for various reasons.

Thx
Lee

[Andy Fell]

There are too many variable for this to be any use, if you ask me....
Results will be unreliable and possibly more useless than no result at all! :-)

[Paul_Sengupta]

Nah, I think it's pretty good. But it should be easily turn-off-and-on-able, as an advert once said!

[Andy Fell]

How do you know it's any good?

[dimme]

There are too many variable for this to be any use, if you ask me....
Results will be unreliable and possibly more useless than no result at all! :-)

Mode A and C detection is the only useful thing in Sweden if you are flying below FL300.

[Andy Fell]

I do take your point, believe me :-)

One of the major 'issues' (if you call it that) and criticisms of these type of systems is that if the data isn't spot on reliable without introducing pilot workload, then there is an argument that this is a negative safety benefit.

So you spot a ModeC return on your screen... instead of being confident of its location (like you would a mode s return), a proportion of pilot workload time is taken trying to verify the position of the Mode C return... when this was originally conceived one of the big things from feedback was that you need untainted pilot assistance to detect traffic WITHOUT increasing pilot workload.

Mode S returns are reliable and alarms can be created based upon accurate position data, which means that pilot workload is not hindered, more that the system is offering genuine assistance and only takes your attention when it really is required..

Adding into the mix an unreliable Mode C return and now the pilot has to take cockpit time to verify the accuracy of this information (very time consuming!).  Now we have a system that is arguably not helping, more that it is increasing your workload with unreliable data.
Spend time trying to verify this and you may be victim of using a percentage of your workload time being unnecessarily distracted on something where there could be more important matters to be thinking about.

The naysayers would have a field day on this one..... Is this an assistance device where no pilot workload is used looking at the screen (which was what we were aiming at), or is it something which given a mode C return actually distracts you from what you should be doing?

It is important not to invent technology just for the sake of it "because we can".

[Paul_Sengupta]

Adding into the mix an unreliable Mode C return and now the pilot has to take cockpit time to verify the accuracy of this information (very time consuming!).

That's not a valid argument really. If you're sitting there unaware of any other traffic, is it better than having an alert that there is other traffic around, say roughly within a quarter of a mile of you? Maybe Mode A is unhelpful, but Mode C/S will be useful, and is the basis of the Zaon MRX device and a few others which only give you a height an approximate range based on signal strength.

Now we have a system that is arguably not helping, more that it is increasing your workload with unreliable data.

There's a news item on the BBC at the moment about lions who have escaped from a national park and are wandering the streets of Nairobi. Would it be better to have a news alert that there are lions in your neighbourhood or is it unhelpful as you can't pinpoint where they are accurately and it may distract you from "more important" matters?

Spend time trying to verify this and you may be victim of using a percentage of your workload time being unnecessarily distracted on something where there could be more important matters to be thinking about.

What important matters?

It is important not to invent technology just for the sake of it "because we can".

Maybe, but this isn't it. It's the only feature which many admit would convince them to buy a PilotAware. It's a very useful addition which will warn of other squawking traffic who don't have ADS-B or another PilotAware.

[Andy Fell]

Hello Paul,

I'm not trying to be deliberately argumentative here, merely challenging the thought processes :-)  From very early discussion about PAW, much of the feedback was "I don't want another bloody gadget that is going to distract me", which is after all a valid point of view... And to be fair, many of the gadgets we use can be quite a distraction.

The argument of being fixated on something which isn't actually a risk, while being completely oblivious to something else which is a significantly higher risk (i.e. "more important matters" - it could be anything) is a known attribute of human factors...  it is also a well documented and understood psychology which is manipulated by illusionists and marketers alike!

I'm not saying one or the other is right or wrong (and I do accept that a Mode C detection scheme would be very useful).. what I'm saying is the system should not be designed to include more distractions leading to a loss in "improved" safety, over and above its main intention, which was to give a reliable and accurate traffic data feedback to the pilot - without increasing cockpit workload.

By the way I was looking for that bloody lion all morning.. couldn't find it... and didn't get any of my other work done which was %^&*£"$ urgent.  Turned out the BBC got it wrong and it was actually Mr Miggins's cat seen through a telescope (they didn't mention that).  I wish I would have known that, since I wasted my entire morning and could have been much more constructive doing something more important... ;-)

Rgds
Andy

[dimme]

I see your point Wobblewing, but there are methods to verify the accuracy of an estimation. It doesn't have to be presented to the pilot unless let's say the estimation is within a 95% confidence interval.

Now I'm taking it to another level, but since radar locations are known, it is possible to listen on 1030 MHz for interrogation pulses to transponders with a second SDR and based on timing and geometry get a much more accurate position estimate of the aircraft.

There are technical solutions as long as there is a will!

EDIT: You can even run them on the same clock if you want thus maintaining phase coherence =)
http://www.rtl-sdr.com/passive-radar-dual-coherent-channel-rtl-sdr/

[Andy Fell]

Yes indeed.  like I say not trying to kill it off, but like to add some practical angle :-)  The naysayers would be worse, believe me :-)

I had thought about timing etc off the radar heads, but I'm not sure this would work because it's probably not possible to correlate the Mode C response to the radar interrogations?.. so you'd loose the timing reference in order to make the calculation... AFAIK Mode C doesn't have a field in its return transmission which describes the radar head it's responding to (unlike Mode S where reduction of "FRUIT" is one of the main advantages, so is more controlled by the radar head itself).

In any case the current PAW implementation uses the standard widely available DUMP1090 program to decode transponder squawks, so a "DUMP1030" would be required, including the associated algorithms etc.  Not impossible, but quite an undertaking. in addition you need a lot of MIPS in the DSP to be able to discriminate very small difference in the arrival time of the received signals.  Timing resolution could be a challenge, so perhaps not suitable for our low cost RPi solution.

An idea I thought of which might work is the use of multilateration, based on lots of ground based PAWs that could broadcast Mode C positions using a special format over the P3I channel.  Each of these ground stations use GPS timing for triangulation of the mode C reception, they then coordinate the measurements to calculate position.. I could envisage a ground network broadcasting P3I based packets to airborne PAW systems, which could give a more reliable Mode C detection method..... It's one hell of a lot of effort though!  I suppose you could take MLAT outputs from FR24 and broadcast on P3I.. only issue there is that FR24 adds too much delay, so we'd get the data too late!