Getting started
Client setup, your first session, and a typical arrival from the entry fix to short final.
What you need
- Aurora. It is the only client the server supports. Other FSD clients speak the same protocol on paper, but none of them is tested against this server and parts of it are written specifically for Aurora, so treat anything else as unsupported.
- An IVAO account that has been let in. Aurora is already signed in with your IVAO credentials, so there is nothing to enter when you connect: the server checks the account Aurora presents against a list of permitted ones. That list is an invited group at the moment, and there is no public route onto it.
Connecting
Open Aurora's built-in sector file manager and download the sector file for the area you want to work. The server flies traffic into Frankfurt, Munich, Berlin, Düsseldorf, Hamburg, Cologne, Vienna and Friedrichshafen, so for Munich that is EDMM, the Munich FIR. Then, in the connection settings:
| Field | Value |
|---|---|
| Server | aurora.schwingenschloegl.online |
| Callsign | the position you are working, e.g. EDDM_APP |
| Connect voice | off |
The port and your login are not among them. Aurora holds both itself, so there are no credentials to type in here.
Voice must be off. There is no voice server behind this, and a client that tries to reach one will sit and wait.
Then connect. You should see an empty scope. That is correct: nothing flies until you start a session.
Check the whole path in one line
Type session status on any frequency. An answer on the same frequency means your client reached
the server, the server understood you, and the reply came back. With nothing running it says so.
If nothing comes back, check your spelling before you suspect the connection. A line addressed to an
aircraft is always answered, even when it cannot be read, but a server command the server cannot
place produces no reply at all: sesion status is silence, not an error.
Talking to the server
Two kinds of message, and the difference is only what you type first.
To an aircraft, lead with its callsign and a comma:
DLH123, t 270
DLH123, c 100 s 250To the server, the command on its own:
session status
pauseEverything is case-insensitive, and every command has exactly one spelling. The rules that apply to all of them, including how several fit on one line, are on how commands work.
Frequency does not matter. Aircraft are not tuned to anything: a line reaches whichever aircraft its callsign names, from any frequency, and the answer comes back on the frequency you typed it on. If you write to an aircraft directly rather than on a frequency, the answer comes back the same way. The callsign you logged in with makes no difference to the simulation either, so work the position you would work.
Starting traffic
Run a continuous flow:
session start eddm random 26 60 rush26 is the operating direction and 60 the rate. It draws from real flights seen landing in that
direction, with the flight plans they filed. It spreads the rate across the active gates by how many
of those flights came through each, and runs until you stop it. The last word shapes the rhythm and
can be left out.
If the airport has no traffic seen in the direction you name, the start is refused and the reply says why. Where it does start, the reply also names any gate it leaves out, and any gate that will send fewer aircraft than you asked for, and gives the reason.
There are no recorded replays at the moment. session list <AIRPORT> is for those, and it answers
that none are bundled.
You can also name the gates you want traffic from, each with its own rate, and the ones you leave out stay quiet:
session start eddm random 26 rokil 20 betos 10 rushEvery value these take, and what each rhythm feels like, is on running a session.
A typical arrival
- The aircraft appears shortly before the point it is handed over to you at, on its way in, and
calls you naming the fix it is flying to:
ITY452: FL160, inbound BETOS. ITY452, sq 2345(every command is listed in the overview)ITY452, clr star BETO1B rwy 26L, or take it off procedure and vector it.ITY452, t 220andITY452, d 4000onto the intercept.ITY452, clr ils 26L- It configures itself, decelerates, and is taken off the scope on short final, about 200 ft above the runway and still short of the threshold. Nothing past that point is simulated: there is no landing, no rollout and no traffic on the ground.
What the aircraft say
An aircraft calls you once without being asked, as it enters your sector, and that is the callup in step 1. Everything after that is an answer to something you typed.
Every clearance it accepts is read back to you, in the aircraft's own name rather than as a server message, so the frequency reads like a real one. The readback is immediate; the aircraft acts a moment later, as a crew would, and instructions you type one after the other are carried out in that order however long each moment turns out to be. A go-around is the one exception: it is acted on at once. A clearance it cannot read is answered by naming the part that stopped it, and one it understood but cannot carry out is answered with the limit that got in the way. What you will not get is an aircraft reporting established, or field in sight, or unable on its own initiative.
Handing it on
Instead of vectoring off the STAR you can hand it to a published approach transition:
ITY452, clr trans 26R via ROKIL flies the feeder route to the point where the procedure hands over
to radar vectors, then holds that heading and waits for you.
While it runs, and ending it
session status reports how long the session has run, how many aircraft it has spawned and how many
are still airborne, and says so when the simulation is paused. pause freezes everything and
resume picks up exactly where it stopped; both act on the whole simulation, for every controller
connected, and while it is paused an instruction, a session start or a spawn is refused with a reply
naming who paused it.
session end eddm is the clean wind-down: no new traffic, but everything airborne stays and is
yours to work down. session delete eddm is the hard stop. Both are described in full under
running a session.
Working with someone else
More than one controller can connect at the same time and split the position. What that gets you:
- Handoffs work. Offer an aircraft to another controller and accept it on the other side, and ownership actually moves.
- Everyone sees the same assigned values. The level and speed you gave an aircraft show in every controller's labels, including for somebody who connects halfway through a session.
- The pause is shared. It stops the traffic for everyone, and it is announced on the frequency it was typed on.
- Two people cannot work the same callsign. The second login is refused. Reconnecting with your own account after a drop is different: that takes your own position back over. If you are back within five minutes, the aircraft you held are yours again a moment after you log in, and their labels show what you had set. If your connection drops or Aurora freezes, the server signs you off after about 45 seconds of silence, and the same five minutes apply. If the server drops everyone's connection at once, for example during an update, the aircraft you held are still yours when you reconnect, but their labels start empty.
- You read each other on the frequency. What you type reaches the others working it, the same way an aircraft's readback does. Somebody on a different frequency does not see it.
- A private message reaches the position it names. Send it to a callsign rather than to a frequency and it goes to that station alone. Between two control positions, to an observer, or from one. A private chat with an aircraft is different: only trainers can steer an aircraft there, see Trainer.
Watching without working
Connect with a callsign that ends in OBS or ATIS instead of a position (EDDM_OBS) and you get
the full picture without taking any of it on: the other positions, the flight strips, the assigned
values in the labels, who currently owns which aircraft, and what the controllers type on their
frequencies. That last part is the point of the position, since you are there to watch somebody
work and half of working is what they say. Everyone working sees you in their ATC list for as long
as you stay connected, and you can write to any of them privately and be written to.
What an observer cannot do is transmit on a frequency, give a clearance, take an aircraft or change what is in a label. Try one and you get a line back saying which position you are on and why it was refused, so a mistyped callsign explains itself instead of looking like a broken connection.
Two things worth knowing before you need them: what to do when something is not working, and how to file a report while the problem is still in front of you.