Protocol interface specification available?

[mickybadia]

Hello forum,
I met a JoinFS user group in November at the last FSweekend in Lelystad, NL. I was happy to find them as I never knew about JoinFS before, although it seems to be a good software solution for multi-player simulation.
We talked about the ATC interfaces, they are using a hack involving Euroscope to join their network, but ATC communications (strip exchange, chat, etc.) are apparently not supported and a lot could be improved.
As the developer, I suggested an extension to ATC-pie, a free ATC simulation software which they could try out as I was presenting it at the event. It would appear to be an excellent solution, provided I could get hold of the network protocol specification for a first step. Does this exist anywhere?
I was told that the JoinFS developer has discontinued working on it. Is this correct? In either case, is he still reachable, or anybody here able to help with this?
Thanks to everybody.

[ATC Roo]

Hi and welcome to the forum.

As far as I know Peter (The Developer of JoinFS) has not made his code available to the public.

Could ATC Pie gain traffic information another way?

Maybe by using UIPC or SimConnect to gain the data from a sim?

[mickybadia]

Hello,

Thanks for the answer, and the warm welcome. Happy new year to all.

I am not sure what you are proposing because I do not know what either of these modules would allow me to do at best. If all they would allow is to obtain traffic positions, I fear this would get ATC-pie no further than where Euroscope+hack users have managed to get. And my intention is not so much to compete with existing solutions or gratuitously promote one of my own, as to propose a solution to integrate all ATC functionalities on a JoinFS network. I was told the problem was that ATCs cannot presently exchange strips, text chat or manage flight plans jointly, whereas a lot of the ATC fun is the coordination work happening backstage, invisible to pilots ATC-pie would allow all of that with very little infrastructure: being able to exchange/broadcast messages between clients would be enough for a good start!

So I would rather have access to the protocol specification so I can study it and eventually propose a solution. This does not necessarily mean access to the code if the author chooses to withhold it. Although in this case and if he decides to drop out and leave the program grow out of maintenance, I would fear things will simply die out of use, so will probably not push things beyond the easy features.

I realise this is both theoretical and rather vague but I very honestly have no idea of what the dev status is, nor the liveness of the user base.
Is the Peter you are referring to the one active on this forum? Maybe he will append to this thread and shed some light on this.
In any case, cheers to all simmers and dev's that make it possible

[ATC Roo]

I am not sure what you are proposing because I do not know what either of these modules would allow me to do at best. If all they would allow is to obtain traffic positions, I fear this would get ATC-pie no further than where Euroscope+hack users have managed to get. And my intention is not so much to compete with existing solutions or gratuitously promote one of my own, as to propose a solution to integrate all ATC functionalities on a JoinFS network.

I've not had a look at ATC-pie yet but I assume it displays traffic from Flight Gear on a scope?

To display traffic on the scope you can use both SimConnect an FSUIPC/XPUIPC.

SimConnect is built into FSX and P3D sims, so all that is needed is for ATC-pie to connect to the sim and then it can send or receive data to and from the sim.

FSUIPC (XPUIPC for XPlane) does the same thing but needs the user to install the uipc module into their sim.
Your app is then able to talk to the UIPC module and send/receive data that way.

You could also write an XPlane specific plugin to do the same thing.

All of the above would enable ATC-pie to connect and gain the traffic data currently in the sim, which you could then display on your scope.

I was told the problem was that ATCs cannot presently exchange strips, text chat or manage flight plans jointly, whereas a lot of the ATC fun is the coordination work happening backstage, invisible to pilots ATC-pie would allow all of that with very little infrastructure: being able to exchange/broadcast messages between clients would be enough for a good start!

That maybe the case.
In order to communicate flight plans, text chat etc you would need to connect the clients (ATC-pie) somehow as I'm sure you're aware.
In a client server scenario this would mean some kind of 24/7 server hosted somewhere, that all the clients knew the address to and could connect.
ATC-pie could then send the messages (Text FlightPlan etc) to the server and other clients that then connect to the same server could pickup those messages.
This is how VATSIM and IVAO work for example.
They have custom FSD servers which pilots and ATC connect to.
The ESJFS tool only reads data from a sim.
It doesnt send anything to a sim and is not connected to a server.
This is why messages cant be sent as there is nowhere to send them too and nobody would pic them up.

JoinFS does already have a chat system if that was of any use?

And to be honest in my experience, (with the exception of Area controllers) the majority of coordination within ATC is done over the landline and not with on screen messages.

I know ATC units are slowly bringing in EFPS but that still doesnt normally operate between units.
Ground, Tower and Radar at the same airport could pass strips for example but EGPF wouldn't normally pass a strip to EGPH.
It would be a phone call "Hello Edinbourgh its Glasgow radar. Do you see that 1234 squawk south of TLA by 5miles? Well that's GABCD inbound to you.... etc etc".
So a voice option where controllers can speak to each other would be the way to go in my opinion.

I would rather have access to the protocol specification so I can study it and eventually propose a solution. This does not necessarily mean access to the code if the author chooses to withhold it. Although in this case and if he decides to drop out and leave the program grow out of maintenance, I would fear things will simply die out of use, so will probably not push things beyond the easy features.

JoinFS transmits data over UDP and only Peter would be able to say if he wanted to allow other developers the ability to send data direct into his app.

If Peter does stop development totally (hes not released a new version for a while, as the latest is stable and working well) this wouldn't stop people using JoinFS in anyway.

I hope the above is of some help.

[mickybadia]

I've not had a look at ATC-pie yet but I assume it displays traffic from Flight Gear on a scope?

It can do that, but it is a lot more generic. It accounts for any type of facility and equipment combination: with or without a look-out view from the tower (controlled view of a 3d scene), a radar (of any A/C/S capability), a surface radar (GND modes), a primary radar, RDF, CPDLC, a strip printer, and more... at any position in the world, whether for a CTR set-up or an airport position. Also, it does not just do FlightGear multi-player: solo sessions are possible (AI traffic), and tutorial connections (teacher-controlled traffic for a student).

To display traffic on the scope you can use both SimConnect an FSUIPC/XPUIPC. [...] the above would enable ATC-pie to connect and gain the traffic data currently in the sim, which you could then display on your scope.

I understand these solutions all use a flight simulator program running in the middle to relay (at least) the traffic. The problem I see is that they require owning the program and whatever add-on if required (costly solution if only interested in ATC), and they add a dependency on third-party proprietary software which may be discontinued. I think there is a better case made for connecting directly if possible.

JoinFS does already have a chat system if that was of any use?

Depending on what it can do, it can well be enough to work some features out. This is what I meant by: "being able to exchange/broadcast messages between clients would be enough for a good start". For example, if it can do private posts, implementing strip exchange between ATCs becomes easy with no changes.

And to be honest in my experience, (with the exception of Area controllers) the majority of coordination within ATC is done over the landline and not with on screen messages.

Sure, text chat here is only a fall-back substitute for when voice is not possible or enabled. The same goes for the radio text chat with pilots in some sessions. But passing strips between workbenches/racks and controllers without a voice call is a must for realistic ATC sim. That is the major piece of coordination I would like to address, which I was told was missing (although this remains TBC to me).

JoinFS transmits data over UDP and only Peter would be able to say if he wanted to allow other developers the ability to send data direct into his app.

Of course!
Alternatively, JoinFS could extend its compatibility and accept FGMS connections (the native FlightGear multi-player protocol), like I understand it has done for P3D, FSX, X-plane. But that would be work on the other end.

If Peter does stop development totally (hes not released a new version for a while, as the latest is stable and working well) this wouldn't stop people using JoinFS in anyway.

Well I am no fortune teller, but with time it seems that even the most useful piece of software ends up replaced if unmaintained, especially when strongly depending on multiple separate programs, each with a life of its own.

[ATC Roo]

Ok I now understand why you wanted to talk directly to JoinFS.

I dont believe it's possible at the moment, but who knows Peter might introduce some way to abstract the data JoinFS transmits or create some kind of plugin feature in the future.

The JoinFS chat probably wouldn't suit your needs as youd need ATC-pie to be able to read it.

For now JoinFS does output a whazzup style file.
This is updated frequently enough to use the outputted data on a scope.
The whazzup file does give you access to various useful data for this type of project, like arrival and departure airports although not the aircraft routing.

It would be possible for you to create a webpage for pilots to file their flight plan and for ATC-pie to read that data periodically.

For handovers you would need to put some kind of client server solution together for your ATC-pie clients to communicate, maybe a web api?

I hope that's of some help?

[mickybadia]

For now JoinFS does output a whazzup style file. This is updated frequently enough to use the outputted data on a scope.

Is this what you are talking about?
If so, it would indeed, coupled with other parallel systems covering the stuff going on backstage between ATCs, start to look like a solution, although not a very efficient one in terms of run-time cost. The first few questions that come to my mind are:

• How frequent is the update? In the description they exemplify with a 2-minute cycle, which would be too long, but you seem to say it is acceptable. Is this a parameter when running JoinFS and if so what is the shortest reasonable usable update period?
• Is the list of details dumped in the data exactly that shown on this page? i.e. no more, no less?
• I understand this would be working "outside" of the network (bypassing connection to JoinFS), hence remaining invisible to pilots in the system wherever ATC presence would otherwise be notified. What kind of pilot-ATC interaction does this prevent, if any? I guess text chat is ruled out, but if I get voice to work on the side I am ready to consider this a blessing in disguise because it is not realistic to have that anyway
• Is the regular dump pipe-able or will this mean reading a physical file every new second?
• [EDIT: added] Not much else than "transponder code" describes the XPDR status, whereas it is what the radar is looking for. I guess we'll have to go with assuming a mode for each of them (e.g. none for microlight, C for prop's, S for airliners), and that geometric and pressure altitudes match. Correct? [/EDIT]

The whazzup file does give you access to various useful data for this type of project, like arrival and departure airports although not the aircraft routing. It would be possible for you to create a webpage for pilots to file their flight plan and for ATC-pie to read that data periodically.

That is what is done here for FlightGear already. Maybe something similar can be provided eventually. Otherwise never mind, FPL filing can always be disabled in the mean time, what matters more is what ends up on the strips in my opinion.
[EDIT: added] Related question though since many details in the Whazzup thing are named with "FlightPlan": how do they normally get a value and how do they normally get changed if at all ? [/EDIT]

For handovers you would need to put some kind of client server solution together for your ATC-pie clients to communicate, maybe a web api?

I would certainly have to get some sort of ATC communication system working, either through the audio system if any text is supported (e.g. Mumble) or through IRC or something. The latter is already implemented for FG so that should be fine.