Callsign conversion again, suffixes, etc.

[Deadcalm]

No doubt this has been covered elsewhere before (I've even posted on it, but have received no satisfactory explanation thus far), but I'm intrigued nonetheless...

It seems that many callsigns do not display departure and destination locations in the information block, and in particular ALL those with one or more letter suffixes.  Often 30% or more of my live targets behave in this way. Is there a reason for this, and can it be addressed?  I know someone has suggested in another thread that this was due to crew laziness, or faulty GPS sytems, etc., but I suspect that there is a more fundamental reason.

Can you shed any light on this, Airnav?

[Roadrunner]

It is a problem with SBS1 and PlanePlotter as well as RadarBox. However one of the add ons available for the latter two systems Flight Display - latest version FD6 - uses some sort of mechanism in the programming that trims off the suffix and the result is a lot more call signs get picked up. Just watched call signs NJE477B and  EMX82L be converted using FD6 program but not by RadarBox so a solution is available if AirNav could follow it up ? :-(

[EINN-07]

Outside of the crew neglecting to input the flight number in the transponder another issue is the use of alpha numberic callsigns as opposed to alpha numeric flight numbers.

There are numerous instances of this such as Ryanair 9C4D, Speedbird 9D, Midland 9EV and the like. These callsigns ( which are usually a mouthful ) are presumably deliberately made up to avoid mixups between similar sounding flights in the same airspace.

There is usually a fixed tie up between the callsign and the 'correct' flight number. From what I can see the crew often input the callsign as opposed to the flight number which would require the flight number to be replaced by the callsign in the database in order to get the routing to appear on the map or log.

With regards to bizjets, Net Jets along with a significant number of other executive operators operate both a flight number system and a fixed callsign, the latter of which ties into the aircraft registration ie NJE 6VL = CS-DFR.

In Net Jet's case the the first digit of the fixed callsign ( after Net Jet ) indicates the aircraft type - examples such as 1 or 7 for Citation 550, 2 for Falcon 2000. From what I have been able to observe the fixed callsign ( with Net Jets ) is used for a/c positioning whereas the flight number is used for revenue sectors.

Again, presumably this sytem was adopted initially for busy airspace around airports like Luton where 20 % of the aircraft would have been calling - CS-D**

A good listing for fixed callsigns for bizjets is to be found at :

http://www.antonakis.co.uk/acars.php?page=callsigns

So far though I haven't seen any Net Jets with either the fixed callsign or the flight number showing on RB.


Gerry

[AirNav Development]

So please confirm to us what needs to be done: do you want the program to for example:
- BAW54B: extract the origin/destination data for BAW54?
- DLH544A: extract the origin/destination data for DLH544A?

That can easily be done. For our experienced users, we presume that not always the above is correct. For example callsign BAW54B could be used by any flight, ie, BAW5664.

Let's discuss it here and as usually we are here to turn the application into a better one, always.

[Roadrunner]

AirNav

I think this is duplicating the thread on using the FD6PP prgram in PlanePlotter as discussed by Allocator with referrence also to Tarbat  :-)

[EINN-07]

AirNav

I think this is duplicating the thread on using the FD6PP prgram in PlanePlotter as discussed by Allocator with referrence also to Tarbat  :-)

Roadrunner,

It's not duplicating the thread.
A callsign ( or transponder flight number ) does not have to be the same as the airline's flight number. There is a subtle difference. If the callsign = transponder flight number but does not equal airline flight number you cannot extract route information by stripping the last alpha character and doing a look up elsewhere :(

The only real solution to Deadcalm's problem and the instances of alphanumeric flight numbers such BMA 9EV or RYR 9C4D is to decode the alpha numeric flight number and add a duplicate record to the routes database.

[Deadcalm]

Well, with such a high percentage of callsigns which don't display departure/destination airfield information in the datablock, it should be worth taking a serious look at whether or not this can be remedied.  I am aware from my previous occupation that callsigns often do not bear any resemblance to the flight number (for example, BA shuttles) - is there no way in which this information may be extrapolated and displayed?

Also I refer to my previous post where I asked that a network screenshot be compared with the live Sao Paulo feed where the correct callsign and data was displayed in one instance, but not the other.  Maybe there is a relationship.

Either way, I'd like to know if there is a possible solution which can be integrated into the existing programme without individual user recourse to third party databases...

DC