Board index FlightGear Support Tools OpenRadar

Transponder over network

OpenRadar is a standalone radar screen which connects to the FlightGear multiplayer servers. It is currently being developed.

Re: Transponder over network

Postby Johan G » Sat May 11, 2013 1:12 pm

wagnerw wrote in Fri May 10, 2013 7:44 pm:How does it work in real live? Flightplan filed under Callsign and Flightnumber => Contact identifies itself => ATC tells Contact Squawk code and assigns it to flightplan?

In real life the aircraft type is required information in the flight plan. In the flightplan it is represented using ICAO DOC 8643 - Aircraft Type Designators, and if one is not available for the aircraft type (e.g. if it is a prototype or a rare aircraft) it will be written as "ZZZZ" in the aircraft type field and instead added in field 18 (other information) after a preceding "TYP/" tag.

wagnerw wrote:Do we really want to force everybody to file a flightplan, before he can fly at your airports? Or do we alternatively accept anything flightplan like be it per chat or voice. In the later more beginner friendly way, we could keep it more simple...

I would personally prefer if there at some point in the future will be a central flightplan database (accessible to anyone), and that filing a flightplan would not be mandatory unless required by e.g. a virtual airline or flight club (i.e. not required for any geographical area), and that they could be done in a simple way as in some places today (i.e. departure time, arrival time, route, cruise speed and cruise altitude) and as a full flight plan for the few who would wish to do that (would probably only be done by virtual airlines and a handful of others, and will require a "wizard" to help filling the form).

F-JJTH wrote in Sat May 11, 2013 10:15 am:In this screenshot I transmit sqwak -9999 from one aircraft (which is totally impossible in real world... so not realistic) and the other aircraft receive -9998 (which is certainly a bug) Also the first aircraft is transmitting sqwak -9999 even if the transponder is OFF or SBY... I need to talk with James about all of this.

Eum, the squak code for all the "legacy" modes (1, 2, 3A and 3C) are octal numbers (0-7). (See for example Aviation transponder interrogation modes at Wikipedia)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5452
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Transponder over network

Postby zakalawe » Sat May 11, 2013 2:24 pm

FG support for transponder props over MP is in Git now, thanks to some work by Clement and Vivian. Additional modes besides S, C and A can be added if anyone requires them - best to ask by email on the devel list. I'll be updating the wiki soon with some docs on the transponder instrument.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Transponder over network

Postby zakalawe » Sat May 11, 2013 3:58 pm

zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Transponder over network

Postby Omega » Sat May 11, 2013 5:02 pm

wagnerw,

Here is an example pof file for all langen radar positions and below: http://nav.vatsim-germany.org/files/edg ... c/EDGG.pof
A bunch of others for all german facilities are published here: http://nav.vatsim-germany.org/

About the licensing, that would mean that you'll have to ask 100+ vACC's in vatsim before pof files can be available to the OpenRadar user...
These pof files can be used in multiple radar clients even if 'vrc' is written on them, the creators of Euroscope or even ASRC didn't need to ask for permission to use them, simply because they are just giving support for the file format (.pof) and coding structure within their software, but they are not republishing or modifying these files in any way. Same goes for sector files which are used in a far wider number of applications within vatsim.
The engine is the heart of an aeroplane, but the pilot is its soul.
User avatar
Omega
 
Posts: 594
Joined: Sun Oct 10, 2010 1:46 pm
Callsign: Star,EHAA_CT,MIA0176
IRC name: Omega
Version: GIT
OS: Vista,7,Ubuntu 10.04

Re: Transponder over network

Postby wagnerw » Sat May 11, 2013 7:34 pm

Hi,
downloading them in background should be no big issue, but currently I see only the German Pof files. What is the general structure? How do the vrc clients know from where those files have to be downloaded? And is there a documentation, how this format works? We should ask somebody who is an expert for open source and licences... There is a copyright mentioned in the file.

But also without that: The less people doing ATC right now, can agree non-overlapping ranges between each other. For the start there is even no need to have an "assign next free id" in OR.

I have implemented to read squawk information as indicated in MP protocol. I still don't know how I can detect if a user has no transponder at all, or if it is not transmitting data. Maybe FG can transmit an empty code, if it is disabled, to let me know, there is one, but disabled.

Also I have reworked the data block display, to be able to display information dynamically and in more than 2 lines.

Omega has once proposed to implement something like this: http://www1.metacraft.com/VRC/docs/doc. ... adar_modes

I suggest to implement only a few for the moment. Up to now, we have lived with the simple data block and I have not heard, that anybody had problems to understand it.
Should OR really implement so many different modes? Many different modes mean a high count of feature combinations and bring us to an un-testable application.
I suggest, we start with one mode at first. Later someone may add something different.

How is about adapting closer to the tower mode? Currently one ATC acts mostly in all roles at once... And it is pretty close to our current implementation.
As long as we have no inter-OR communication, we cannot show who is controlling a contact, but we can indicate additionally:
  • Identing
  • Emergency
  • Radio failure

I have more questions: What is displayed if an unknown contact arrives, with or without transmitting an ID? Is there the dot only? How do you want the process of defining an ID should be: Mark it and hit a key => Select flightplan => Squawk code? Data and flightstrip appear as soon as the squawk is being transmitted?
Under which circumstances can I reuse a squawk code?

Wolfram
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Re: Transponder over network

Postby Omega » Sat May 11, 2013 8:58 pm

In VRC sector and pof files are never downloaded in the background, they have to obtained via a download link manually and then imported to the client.
AFAIK, in Euroscope there is a choice to download sector files in the background through a repository, but then Euroscope doesn't make use of .pof files...

The tower mode in VRC is just something made-up, I don't think it really exists in reality. There is a million of radar systems out there and it's really hard to keep track of them, but one of the best known system used in towers across the US is old d-brite: http://www.airport-data.com/images/airp ... 007337.jpg .
The colors feel kind of awkward but the data tags is the most important thing here...

What I would suggest if you don't want to make up different modes and you just want a "Default" one would be to simply borrow a small piece of every mode and then combine them to make your own.
From D-brite we can of course borrow the way callsign, altitude and speed are displayed but then this is pretty much how it is also displayed in ARTS and STARS. Then, there is the aircraft type which can be simply displayed on a third line (like DSR) or next to the callsign which resembles some European radar systems out there...

The aircraft type, sounds like the hardest feature to implement, so you can still keep the flight strips in case it is nearly impossible to show correct aircraft type.

The thing that mostly distinguishes one radar mode from the other though, is the colors. The current OpenRadar version looks almost like a copy of the flightgear map.
So some new colors would be nice :) .
I have more questions: What is displayed if an unknown contact arrives, with or without transmitting an ID? Is there the dot only? How do you want the process of defining an ID should be: Mark it and hit a key => Select flightplan => Squawk code? Data and flightstrip appear as soon as the squawk is being transmitted?
Under which circumstances can I reuse a squawk code?

If the aircraft is squawking standby, there is a dot only. If the aircraft was radar contacted by a previous controller then the identification of the target will be passed to the new controller through a hand off. If the aircraft is arriving from uncontrolled airspace it should be squawking a non-discrete code (e.g. 1200,2200,7000) and mode C which allows the new controller to see the callsign and aircraft's altitude until the a/c is assigned a new squawk code.

For the squawk code assignment, we can do it like vrc through the flightplan window:
http://www1.metacraft.com/VRC/graphics/ ... editor.png

Otherwise, we can do it through right click on the aircraft and then clicking "assign squawk code" (or something similar).
The squawk code can then appear on the flightplan window or in a field in the flightstrip.

Then it's only the data that is updated, flightstrips should exist from the beginning pretty much.

In case you want to go really in-depth with this then we can discuss it somewhere else, IRC perhaps? I just don't think I'm doing a good job explaining all this without direct input :P .
The engine is the heart of an aeroplane, but the pilot is its soul.
User avatar
Omega
 
Posts: 594
Joined: Sun Oct 10, 2010 1:46 pm
Callsign: Star,EHAA_CT,MIA0176
IRC name: Omega
Version: GIT
OS: Vista,7,Ubuntu 10.04

Re: Transponder over network

Postby wagnerw » Sun May 12, 2013 6:56 am

Hi Omega,
The most important thing in our discussion is that you are not alone, and the users have very different opinions about the features that are needed and should come next. I face that, by trying to implement it extent-able, so we that we can try a feature and remove or extend it as it is accepted.
If I cannot act at once, I might work on something else, might need to change bigger parts of code, to make it extent-able, or simply have no time to work on OR right now.
Generally spoken, I have no problem, if OR does not look like a specific real-world application, and I see no reason to re-implement VRC completely. My interest is to create something that is a good tool for the virtual ATCs and has a good usability. I have no problem, when OR becomes better than the real tools in some aspects...

Omega wrote in Sat May 11, 2013 8:58 pm:... one of the best known system used in towers across the US is old d-brite: http://www.airport-data.com/images/airp ... 007337.jpg . The colors feel kind of awkward but the data tags is the most important thing here...

Huh... Looks like in the late seventies... But it has graphics at least...

What I would suggest if you don't want to make up different modes and you just want a "Default" one would be to simply borrow a small piece of every mode and then combine them to make your own.
From D-brite we can of course borrow the way callsign, altitude and speed are displayed but then this is pretty much how it is also displayed in ARTS and STARS. Then, there is the aircraft type which can be simply displayed on a third line (like DSR) or next to the callsign which resembles some European radar systems out there...

You mean
callsign
ALT GS
Aircraft

The aircraft type, sounds like the hardest feature to implement, so you can still keep the flight strips in case it is nearly impossible to show correct aircraft type.

The third line was impossible to draw until yesterday. Now you can have 20 if 'everybody' agrees....

If the aircraft is squawking standby, there is a dot only.

In this situation, the flightstrip should be almost empty, as we get no data from the plane.
But we still will have planes without transponder... Seen the FG reality right now, they need to be displayed as "squawk assigned" for the next time. Otherwise OR would not be usable from one day to the other.
If the aircraft was radar contacted by a previous controller then the identification of the target will be passed to the new controller through a hand off. If the aircraft is arriving from uncontrolled airspace it should be squawking a non-discrete code (e.g. 1200,2200,7000) and mode C which allows the new controller to see the callsign and aircrafts altitude until the a/c is assigned a new squawk code.

In the examples the first line shows: UAL1918 What does it mean? I would display the plane for instance in a different color and display the current squawk code instead of the callsign. Because you assign the code to a callsign/flightplan and until the contact did not the tuning the contact must be considered as unassigned.

Before we blow up this features, we need a flightplan server or something similar and we need the transmitter in the planes. Currently I cant even do tests...
So there is time to prepare things.

In case you want to go really in-depth with this then we can discuss it somewhere else, IRC perhaps? I just don't think I am doing a good job explaining all this without direct input.

I haven't used IRC lately, but I am often in Mumble now.

Question to everybody:
Is it Ok for you to change with next update the data block:
Currently:
callsign heading
FLAltitude Aairspeed

D-W794 154
FL050 A110

To:
(optional first line) Special notifications: 7700:EM (red) or 7600:RF or 7500:HJ otherwise omitted
callsign vertical_ speed_arrow FGCOM_indication)
three_digit_altitude two_digit_groundspeed
Aircraft_code

D-W794
050 11
C172

Later, with the assign id feature, this feature will be extended to support unassigned ids and transitions. But for that we need flightplans and working transponders in the wild...

Wolfram
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Re: Transponder over network

Postby Omega » Sun May 12, 2013 3:51 pm

wagnerw wrote:Huh... Looks like in the late seventies... But it has graphics at least...

Yes, they are now replacing it with new systems, which I don't have any visual references of... At least there are no shrimp boats :) .
You mean
callsign
ALT GS
Aircraft

Yes, but AFAIK in some systems the GS indication stays for about 2-3 secs then flashes to display the aircraft for 2-3 secs.

The other way I suggested is the more European style (I guess you'd call it that):
callsign aircraft
(anything else maybe between here)
ALT GS

wagnerw wrote:In this situation, the flightstrip should be almost empty, as we get no data from the plane.

You are right, in real life the flightstrip will be pushed from one controller to the other upon hand off, but I prefer to have magic flightstrips instead :lol: .
I don't know what's my opinion on this really since the flightstrips in OpenRadar are just different...

wagnerw wrote:In the examples the first line shows: UAL1918 What does it mean? I would display the plane for instance in a different color and display the current squawk code instead of the callsign. Because you assign the code to a callsign/flightplan and until the contact did not the tuning the contact must be considered as unassigned.

UAL1918 is the callsign and that is a tracked target on that example there, you can change the color display to a slightly lighter color something that blends in with the background a bit...
The "uncontrolled" target should appear more like this:
Image
The engine is the heart of an aeroplane, but the pilot is its soul.
User avatar
Omega
 
Posts: 594
Joined: Sun Oct 10, 2010 1:46 pm
Callsign: Star,EHAA_CT,MIA0176
IRC name: Omega
Version: GIT
OS: Vista,7,Ubuntu 10.04

Re: Transponder over network

Postby wagnerw » Sun May 12, 2013 8:17 pm

Hi Omega,
Omega wrote in Sun May 12, 2013 3:51 pm:The other way I suggested is the more European style (I guess you'd call it that):
callsign aircraft
(anything else maybe between here)
ALT GS

What is anything else? Do you mean scratchpad, target airport, etc.?
Callsign and aircraft in one line will be long....

The "uncontrolled" target should appear more like this:
Image


Why is there no ground speed?

About the aircraft codes: I could need help! Could someone create a collection of a mapping from our aircraft models (without path, you may use regex) to the ICAO aircraft codes? I want to use it to show the aircraft codes instead of the models...
Thank you!

Wolfram
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Re: Transponder over network

Postby Omega » Sun May 12, 2013 9:02 pm

What is anything else? Do you mean scratchpad, target airport, etc.?

yes
Callsign and aircraft in one line will be long....

There is actually a bunch of info you can get in one data tag, as long as you are able to move it around:
Image

Why is there no ground speed?

The aircraft is not tracked by us, which probably means it is outside of our airspace, the callsign does not appear either so it doesn't allow us to instruct it to maintain a certain speed.
Therefore, even if a GS indication was present, it would be of no use. Once the aircraft is squawking a good code and we have it tracked, only then the GS will be indicated.
The engine is the heart of an aeroplane, but the pilot is its soul.
User avatar
Omega
 
Posts: 594
Joined: Sun Oct 10, 2010 1:46 pm
Callsign: Star,EHAA_CT,MIA0176
IRC name: Omega
Version: GIT
OS: Vista,7,Ubuntu 10.04

Re: Transponder over network

Postby wagnerw » Mon May 13, 2013 6:22 am

Omega wrote in Sun May 12, 2013 9:02 pm:The aircraft is not tracked by us, which probably means it is outside of our airspace, the callsign does not appear either so it doesn't allow us to instruct it to maintain a certain speed.
Therefore, even if a GS indication was present, it would be of no use. Once the aircraft is squawking a good code and we have it tracked, only then the GS will be indicated.

I am not sure if I can follow this argument... If someone is doing something bad or his transponder is broken, transmits, but cannot be tuned for instance, it should be interesting to see the groundspeed to evaluate potential dangers for other contacts... Anyway...

In steps: Most of the 'other information' is not available at the moment. So before it can appear, there must be some effort to create something that delivers it:
=> flightplan database/exchange
=> inter OR - communication either peer to peer or via the flightplan server

What i can do now, is to add the aircraft codes mapping, set up an temporary squawk code range definition (mismatch in callsign length in POF files...), add a squawk code assignment. I guess that the notification over the new squawk code is sent via chat automatically after assignment right? In case, the ATC can tell via voice too..

After that we have a basic squawk support and can wait for the first transponder enabled planes:
=> no transponder built in / transponder off (I cannot distinguish between those two states)
=> transponder tuned to a foreign (unknown, not assigned) code
=> transponder tuned to a specific code (VFR, Hijack, radio failure, emergeny)
=> transponder tuned to the assigned code
We can assign the squawk codes and see if the contacts obeys...

The next update will bring two additional data block layouts as base for optimizations (prototype): Both are squawk enabled: Show the transmitted altitude and the display changes depending on the cases above. The difference between them is when no transponder data arrives. One displays dots without any information, the other displays data as if the assigned squawk code is tuned in. The later exists, because currently there is no aircraft with a transmitting transponder.
The current data block is still available. So users can choose.

Wolfram
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Re: Transponder over network

Postby Johan G » Mon May 13, 2013 6:23 am

wagnerw wrote in Sun May 12, 2013 8:17 pm:About the aircraft codes: I could need help! Could someone create a collection of a mapping from our aircraft models (without path, you may use regex) to the ICAO aircraft codes?

I have started on it. To what would you like the ICAO codes to be mapped? The aircraft type used in the command line --aircraft=<this>?
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5452
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Transponder over network

Postby wagnerw » Mon May 13, 2013 6:35 am

Good question. I guess so, but I am not completely sure, source data is the model, that is transmitted via MP protocol:
It looks like that:
Aircraft/777/Models/777-300.xml
Aircraft/ATC-ML/ATC-ML.xml
Aircraft/A330-200/Models/A330-243.xml

Currently I strip the path and the ".xml" from it and display the rest.
777-300
ATC-ML
A330-243

The atcs will be displayed differently in close future...

So we need
regex => ICAO code

I think the list aircraft option shows the name in the xml content?

I am very happy to get help here! Thank you!
wagnerw
 
Posts: 283
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Re: Transponder over network

Postby Omega » Mon May 13, 2013 9:44 pm

wagnerw wrote:I am not sure if I can follow this argument... If someone is doing something bad or his transponder is broken, transmits, but cannot be tuned for instance, it should be interesting to see the groundspeed to evaluate potential dangers for other contacts... Anyway...

As I said in my previous post, we are not tracking the aircraft so MOST LIKELY it is outside of our airspace, therefore no need to worry about it. The altitude indication and the bleep are more than enough to evaluate potential conflict. Now, if the aircraft does bust the ATC's airspace without any contact, then it is up to each country's own regulations on what to do with the pilot/controller...
And I can tell you that in every radar system that I've seen, GS will not be displayed unless the aircraft is squawking assigned and is tracked.

wagnerw wrote:I guess that the notification over the new squawk code is sent via chat automatically after assignment right? In case, the ATC can tell via voice too..

I can tell you from experience that I've clicked that "Assign squawk code" button in vatsim quite a few times just by mistake. So this wouldn't be such a good idea :D .

wagnerw wrote:=> no transponder built in / transponder off (I cannot distinguish between those two states)

I'm sure Clément did mention that a generic transponder will be implemented within the GUI allowing every aircraft to have a working transponder.

wagnerw wrote:We can assign the squawk codes and see if the contacts obeys...

I'm sure it would take some time for the flightgear pilots to understand the meaning of the transponder, but there is way around this:
In VRC, by default you can see all the information of the data tag EXCEPT the GS even if the aircraft is not squawking your assigned code. The way to do this is just start track on the target.
There is of course a "realistic data tag" option in the vrc menu that makes you unable to track the aircraft unless it is squawking correctly... just like in real life.
So, we can always do something like this and it will also allow us to view data from targets that squawk standby. Even if it's not realistic it gives us an operational advantage, that is for sure.

wagnerw wrote:I think the list aircraft option shows the name in the xml content?

That is included in the set.xml file but it's not necessarily the same as the name of the FDM file.

BTW, new aircraft will be developed in FG everyday so the a/c list has to be updated every now and then. One of my suggestions would be just to indicate the 'ZZZZ' aka ICAO code for unknown aircraft...
Of course we can obtain the aircraft type from the flightplan, if that feature is ever going to be available. (I assumed that none has thought of this yet so I couldn't resist :mrgreen: ).
The engine is the heart of an aeroplane, but the pilot is its soul.
User avatar
Omega
 
Posts: 594
Joined: Sun Oct 10, 2010 1:46 pm
Callsign: Star,EHAA_CT,MIA0176
IRC name: Omega
Version: GIT
OS: Vista,7,Ubuntu 10.04

Re: Transponder over network

Postby Michat » Tue May 14, 2013 6:45 am

My idea if the user don't have squawk or if he doesn't know how to use it, in order to make easy the control contact and to improve the learning curve. My idea was create a protocol for first contact.

Example of first contact.

Avoiding the horrible work to repeat always the same song: "welcome to my airspace do you wana be controlled+then have to explain how the squawk work+etc etc.
In order to make better experience for users and for controllers. Avoiding on air strange discusions-situations, but promoting a learning experience. I created a protocol....

Example. I'm the tower Of EDNY. I can send an automatic message to a pilot that is flying my airspace with out control assignement (no sqwak, no initial contact) ( I see all traffic data in the Flightstrip, speed too, gs is needed ) maybe the pilot want to be controlled maybe not, maybe is nooby and he doesn't know how to do it, but we can help him and help us.

My automatic first contact message is Good Evening "callsign" this is EDNY. If you want to be controlled send edny@. So the program can assign sqwak, and send all first contact information (has non sense to assign squawk on middle air, with no flight plan, it means new problems for the controller) Metar etc. My idea is that after first contact, we can stablish and easy protocol.

Example user can send edny@metar and receive the info he wants.

But my idea is that after first contact with string edny@, user could receive some options using fg automatic atc chat where just pressing a number he could say us if is visual, ifr, vector, ils, or newbie. So the idea is that we can reproduce a complete protocol, user just have to press some key, but he can read the well formed message that FG send back to us, reporting automatic position, etc (all first contact info we need to know from the user, fgcom, etc). So the user can be included in the list, with automatic squawk, what ever is dep or app.

If by contraire we repeat the VAtsim usability errors, result will be too much protocol, inverse learning curve, no fun, bad humor and so on. A controller living in a list where nobody has squawk, no FP. I want to have fun controlling, I don't like have to explain nothing to the user, if protocol can do it. Either want to be the squawk-fp police. We can use FG atc chat for the learning curve.

Other examples of the protocol.

edny@a arrival info.
edny@d departure info (complete)
edny@m metar.

Even if there is no controller, this protocol can be used too.

I wish- prefer a good information box with to modes, resumed and extended flighstrips (with units) pressing space bar . GS always for every pilot and lists with direct vectors management.

Be careful the model of EU you are looking is about to change for the sactaII. Anyways is good software, but sometimes horrible. The policy of VS turn people unhappy. Avoid pyramid structure and to much compartments.

However, we should be ready. VS ivao and other networks are now on big troubles, still their users don't know about it's vulnerability. I read that MS is very very unhappy because MS flight is a flop. They attempt to change the status market with the cloud (cloud=money for flight) First attempt have failed. I now that the so called markets are doing leverage with the futures of those flight simula networks, martin L have launched prepar3d. The exodus to x-plane after closing MSX, vatsim and ivao going to start receiving offers if not sabotage.

We have to be ready for new users.

Good luck all.
User avatar
Michat
 
Posts: 958
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

PreviousNext

Return to OpenRadar

Who is online

Users browsing this forum: No registered users and 2 guests