FGCom-mumble

[benih]

That all sounds good to me

What I am planning to implement is a way for ATCs to call each other, so I think it is rather different.

I had that in mind too for the future. Basicly it could be like this:
- User presses PTT on landline connection. This initiates a ringing tone to all tuned on that same line.
- One of the other clients presses his PTT on that line to accept the call.
- Now a connection is established, and both can talk as long as PTT remains active.
- As soon as one party releases the PTT, the connection treats this as hang up.

For now i wanted it to keep it simple, so i did not implement the call establishing.
Also i'm not so sure how intercomms really work nowadays...

[Johan G]

I split this off from the other topic (see first post in this topic). Also named this topic after the name in readme file of the GitHub repo.

Some things for the wish list if you would at some time find interest in them:

• HF frequencies (2.1 - 28.0 MHz [1]) for military and some civilian long range aircraft
• VHF frequencies limited to 118-137 MHz [1]
• UHF frequencies (225-400 MHz [1][2]) , the "NATO UHF Band" for people liking military aircraft
• More advanced, but still approximated, noise and radio propagation modeling. Can be challenging for HF coms. [3]

If you later on (in essence not now) feel for taking a really deep dive into aviation radio, The US FAA Order 6050.32B - Spectrum Management Regulations and Procedures Manual (Nov 2005, 22 MB PDF file) and ICAO Doc 9718-AN/957 - Handbook on Radio Frequency Spectrum Requirements for Civil Aviation (draft?, 2009, 1.5 MB PDF) seem to be good resources.
____
[1] See FAA Spectrum Engineering & Policy - Radio Frequency Bands Supporting Aviation
[2] Channels are 25 kHz. See also MIL-STD-188/243 Rev. A - Department of Defense Interface Standard, Tactical Single Channel Ultra High Frequency (UHF) Radio Communications (May 2014).
[3] See Wikipedia article https://en.wikipedia.org/wiki/Radio_propagation (permalink)

[benih]

Thank you for cleaning the topic
And also thanks for the follow up reeading. That sounds very interesting!

Regarding your ideas, they are really good, I will shortly add an issue ticket for that.
However, any frequency you can think of will currently work, there is no limit anymore.
Ok, currently we have only the simple VHF radio wave model, so even HF and UHF are subject to those simple models, but they work and are tunable (if so by the aircraft).
Noise and radio propagation follows currently a simple model where the signal is lost at the radio horizon (which depends on the altitude) or when the transmitting power is not enough. This is not perfect but radio horizon calculation is pretty good already and the signal-power-loss should be somewhat in the correct ballpark already. On eproblem is that no aircraft currently adjusts the default output power of 10W.

[edit] issue is here: https://github.com/hbeni/fgcom-mumble/issues/15 Volunteers welcome

[Johan G]

Thank you for cleaning the topic

You are welcome!

• HF frequencies (2.1 - 28.0 MHz [1]) for military and some civilian long range aircraft
• VHF frequencies limited to 118-137 MHz [1]
• UHF frequencies (225-400 MHz [1][2]) , the "NATO UHF Band" for people liking military aircraft

[...] any frequency you can think of will currently work, there is no limit anymore.

That (a continuous radio spectrum) is very likely the better way to do a generalized radio system (provided the radio controls themselves know that they are a VHF or a UHF radio and only can be tuned within some limits).

On eproblem is that no aircraft currently adjusts the default output power of 10W.

If this get some traction that will likely change over time. Consider how more and more aircraft ave adopted optional rendering features avilable with ALS and later with composite.

Regarding radio propagation and terrain (I noted your issue #6: Implement terrain checks) there was once someone working on adding some very advanced VHF radio propagation modeling into FlightGear, but IIRC mainly due to worries about performance and that FlightGear mainly is a flight simulator, not a propagation simulator, it did not get integrated. There is still a FlightGear wiki article mentioning it that might have some pointers (Radio propagation, permalink).

[benih]

I have the recorder and playbacl bot somewhat ready now
When spawning the recorder bot, i was able to:
- record a Test message on 910.00 and have it replayed to me
- record several ATIS message and have them played looped on the target frequency.

Currently the recorder bot tries to spawn an asynchronous playback-bot process, but that somehow blocks the bot from further recordings.
When i start the recorder bot with "--nospawn", so he does not spawn and just records, and then manually starting the playback bots from my shell, everything works fine however, so this has something todo with how the bots spawn.
If someone has some idea, the code affected is exactly here: https://github.com/hbeni/fgcom-mumble/b ... t.lua#L182

Code: Select all

local handle = io.popen(cmd)

I first tried with io.execute() but that was even worse.
What i need here is to start an os command and then forget about it, having it detach completely from the calling lua process...

[benih]

To fix the spawning issue, I impemented a bot manager script. It will spawn a recorder bot and invoke playback ones when the recorder recorded something (he tells the manager process using a FIFO pipe internally).

This works quite good already: i was able to record ATIS and also to record 910.00 echotests; and they are played back automatically.

Currently mickybadia and i work on better ATC-Pie integration behind the scenes. Meanwhile, ATC can be tried using the "separate mumble instances" workaround. I just documented that in the projects readme.

Now, that the basic radio model is here and we have communications, the ECHO-Test and ATIS-recording working, i want to implement some fake pilot bots to load test all the stuff and get some supported clients numbers. I think this should be relatively good, because we mostly share mumbles bandwith limit. On top of that only the plugin data changes are sent over internet connection, possibly limiting voice bandwith; however that are usually around 110 bytes/s per pilot client (11k/s with 100 pilots flying; ATC clients usually dont update position that often). If this poses to get a problem, i already have an issue ticket for that in the list. Also, the protocol is text currently, so we can greatly improve here sending binary data.

[benih]

News flash: PoC is nearly ready, in my opinion:

• ATC Pie has (in its development version) added handling for FGCom-mumble. This was tested positively, so we have radio support in ATC-Pie and also ATIS recording support.
• Load testing with spawning radio-playback bots continuosly transmitting a previously recorded ATIS sample looped showed that 50 clients (in LAN here) and then conducting an Echotest recording yields acceptable results.
• Load testing with a bot spamming plugin location updates at 2Hz did not reveal a bandwith/latency problem with 50 clients.
  
• Load testing with a special implemented fake-pilot bot (that simulates flying around and occasionally transmitting via radio) is currently not possible because lua eats itself with more than 10 concurrent bot instances. With those numbers, there is no problem at all, however.
  HELP NEEDED: I would be very thankful if someone with C and Lua expertise could take a look at the following issue: https://github.com/bkacjios/lua-mumble/issues/14 to help resolve that.

Conclusion:

• It currently looks like assumed: the mumble backend together with network hardware infrastructure will be the main limiting factor.
• As the test with 50 continuosly transmitting clients and the plugin-io spam yielded good results, i expect the actual realistic sustainable user count to be much higher (as in radio comms i think the communication is mostly "listening" with short rare bursts of sending from an individual client perspective; this is also due to the half-duplex nature of radio comms).
• Because of the lua bot suicide problem, there currently seem to be a hard limit of about 50 ATIS messages being broadcasted in parallel. If this really poses a persistent problem, we may think of implementing that bot in C.

Open stuff / next steps
The next steps need broader community testing.
For that, the windows plugin needs to be tested. The plugin compiles for windows, but i currently have no idea, if it loads and is working (note: it's using pthreads). Feedback appreciated!

I hope i can finish some stuff and push a first alpha binary release package to github the next days. The PoC git branch was just merged into master.
To get this into broader testing, i think it would be needed that mumble 1.4 is released.

[benih]

To add confidence to the load testing, i now used the fake pilot bots.

• 50 fake pilot bots flying around in the same area and chatted randomly (25% chance that they play a 5s sample every 30 secs; 10% chance that this sample is an echotest (so more than in reallife)).
• 5 ATIS recordings broadcasting
• The recorder bot responding to random 910.00 echotests from the bots
• I picked a time slot whee the radio bot currently was recording for another bot to record my 910.00 testsample. This worked fine. the sample got recorded, the replay bot spawned and he echoed it back to me. My voice was loud and clear as expected.

So to summarize, with 50 pilots chatting and 5 parallel ATIS messages, there seem to be no problem with the plugin infrastructure. Sounds good to me.

[benih]

v0.1.0 is out! https://github.com/hbeni/fgcom-mumble/releases

Details for using are included in the release page and in the contained readmes.
Note that you need a mumble/murmur 1.4 installation to test; but for convinience i included my binary builds in a separate zip.
So if you have mumble installed trough your linux distro's package system, the binaries should run out of the box.
You should check that the plugin symlink in mumbles plugin directory resolves correctly, otherwise you will get a plugin load error.

[mickybadia]

Hi,
I am impressed and happy to see this proposed, although just a little too soon as it comes before the official supporting Mumble is even out. :-p
Indeed it made very rapid progress, all of it from somebody initially calling for programmers! Well done.
On my side most of it is already available for testers, and the last piece on RDF should follow suit.

[benih]

Well, i learned alot with that project. But im really not experienced neither in C/C++ nor in lua. It is fun that it works, but i'm not sure the code is flawless.

[benih]

Further load testing: The mumble-lua lib was updated and is more stable now.
I was able to test with 100 fake pilot bots and all was nice.

[benih]

We now also have a status page!
see https://user-images.githubusercontent.c ... 2bea07.png
(Note: Don't get irritated on the radio range. This is correct, but affects the range of the sender to objects standing on the ground. For Airplanes, which are flying, the range is much further: both radio ranges just need to intersect (i.e. there is an established line of sight)!)

Also, the RDF is implemented already. Here mikybadia and i are still working on final things.

[Johan G]

We now also have a status page!

That looks good.

I also took a brief look at the documentation on your repository and like that as well.

[benih]

I also took a brief look at the documentation on your repository and like that as well.

I think this is rather important, so others can pick this up more easily., so it tried to write down all the pieces.