hbeni / fgcom-mumble Goto Github PK
View Code? Open in Web Editor NEWA (flightsim) radio communication simulation based on mumble
License: GNU General Public License v3.0
A (flightsim) radio communication simulation based on mumble
License: GNU General Public License v3.0
When receiving radio signals, the radio_model should calculate the direction.
This information should be made available to flightgear (and other clients) via UDP interface so RDF is possible.
The data format needs to be designed yet, but already identified is:
Introduce a new COM-bound field at the UDP inbound server, so clients can request RDF-data for each radio. Default to off
This reduces network spam.
We need a PoC; it should be developed with the following features:
echo "..." | netcat -q1 -u localhost 16661
really is good enough for now. A standalone radio client may be useful in the future tough! followup=Issue #4 @mickybadia and I just had a talk about the 25/8.33 frequency stuff and i just want to note down briefly what i had taken from it.
We just had a talk about the 25/8.33 frequency stuff and i just want to note down briefly what i had taken from it.
This is a raw reminder for me, so i probably need some time to digest the links and info provided.
Infos:
Needed changes:
RECORD_<tgtFrq>
-> needs to convert too, so replay will happen on the correct real frequencyIn essence, we get an proper actual real frequency internally that can serve as base for future simulations. Mikey stated truly, that this is the only unambiguous identifier we should use. A strong argument was, that the officials may change the channel naming scheme in the future. With the changes outlined above, we then just need to introduce new conversion rules; or even better, do nothing, because all clients already supply >= 4 decimals (aka real frequencies)
Tests:
The mumble client will probably be able to download newer plugins in the future from inside the client.
For this, the two functions mumble_hasUpdate()
and mumble_getUpdateDownloadURL()
should be implemented.
Mickybadia made a proposal regarding ATCing.
Some ATC people are running different ATC clients in parallel (eg. two Airports and on route ATC in between).
Currently one has to run parallel mumble clients, one for each location, as the plugin only supports one location per session.
Many users indeed start more than one ATC-pie instance to control or monitor multiple airports, or have a separate CTR window connected between airport hops, and presumably soon each with its own radio set-up. This generates more than one stream of FGCom-Mumble control packets in parallel, and your replying to all of them on a single fixed port makes it impossible for the RDF requesters to receive the respective RDF data.
We may enhance the plugin so that it supports multiclient usage.
This needs a huge rewrite of the plugin code, however:
IID=<number>
. This switches the ID context. Following Commands are to be applied to the selected ID. If absent, the default identity will be used.This will break backwards compatibility in the internal plugin-io-protocol, so a new version number is needed.
James Turner was so glad to provide some comments on the code:
<STL container>.empty()
over <STL container>.size() > 0
pluginDbg
is efficient (noop when debug is not active)mumble_onAudioSourceFetched
is too long (break down into helper functions; rel #122)if
clausesA live testing session using the C182S from FlightGear resulted in lots of dropped plugin messages (with me being the sole client, next to the statusbot and recorder):
from murmur.log:
<W>2020-12-05 20:45:12.285 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.396 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.609 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.690 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.913 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.028 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.238 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.291 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.533 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.721 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.792 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:14.016 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:14.091 Dropping plugin message sent from "BeniH" (56)
Those messages appeared reliably over the entire session.
The cause for this is to be found, because such high message bursts are not to be expected from the design.
Messages should only occur on a fixed rate from location updates; other updates trigger new messages but should not yield in such bursts because its not fast changing information.
This is about the UDP packets that you send. All of your recipient clients will almost certainly be reading them in parallel with traffic packets coming from the FGMS network relay, and presumably on the same socket. These traffic packets all start with a "magic" byte sequence "FGFS" which is useful for separating them in their own queue.
I recommend that you also prefix all of your packets in a way that identifies your service, for cleaner operation on the client side. It will avoid assuming that everything unidentified or junk is from you, and allows for yet more services to be added cleanly.
For example, start all of your packets with "FGCom" on a first line (prettier on its own line since you do multi-line plain text). The equivalent byte sequence if you need it is, in hex: 46 47 43 6f 6d
, plus 0a
for a new line.
It would be good to give users the option to disable radio audio effects in case hearing is not so good.
Describe the bug
While debugging #78 we again got some messages reporting memory leaks:
FGCom [2021-02-16 12:44:11.327]: Shutdown plugin
FGCom [2021-02-16 12:44:11.327]: [DBG] stopping threads
FGCom [2021-02-16 12:44:11.327]: [DBG] sending UDP shutdown request to port 16661
FGCom [2021-02-16 12:44:11.327]: [UDP-server] shutdown command recieved, server stopping now
FGCom [2021-02-16 12:44:11.327]: [DBG] waiting for threads to finish
FGCom [2021-02-16 12:44:11.327]: [DBG] [UDP-server] thread finished.
FGCom [2021-02-16 12:44:11.372]: [DBG] ---------DEBUG THREAD FINISHED---------
FGCom [2021-02-16 12:44:11.372]: [DBG] [GC] thread finished
FGCom [2021-02-16 12:44:11.427]: [DBG] mumble_shutdown() complete.
<W>2021-02-16 12:44:11.429 PulseAudio: Forcibly disconnected from PulseAudio
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
This does not happen always.
This needs further research, where the memory is not freed.
When starting mumble with active plugin and joining the channel from the command line (mumble:// url) the client crashes with segfault
Right now it is theoretically possible to force a remote plugin instance to flood the plugin-io of murmur for that client by sending too many NTFY_ASK
packets to the attacked client.
Incoming NTFY_ASK
packets provoke an answer to the client with the current state of the local instance. If too many of those answers are sent, murmur will drop excess plugin-messages and thus potentially force murmur to drop important ones, like PTT or frequency changes etc.
Therefore, answering NTFY_ASK
packets should be limited per recipient.
Several ideas already exist to make this happen:
The windows build DLL cannot be loaded.
Mumble says Non-plugin found in plugin directory: "<dir>Mumble/Plugins/fgcom-mumble.dll"
Suggestion from Johan G (see https://forum.flightgear.org/viewtopic.php?p=370416#p370416)
See also: http://wiki.flightgear.org/Radio_propagation
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 8MIL-STD-188/243 Rev. A - Department of Defense Interface Standard, Tactical Single Channel Ultra High Frequency (UHF) Radio Communications](http://everyspec.com/MIL-STD/MIL-STD-0100-0299/MIL-STD-188_243A_50938/) (May 2014).
[3] See Wikipedia article https://en.wikipedia.org/wiki/Radio_propagation (permalink)
Those have all to do with an advanced radio wave model where frequency is an additional input parameter for calculation signal strength.
Currently with the poc-branch the plugin cannot be built with mingw for windows.
There are some library issues, and i have no clue how to fix it (all the fixes in the internet seem to not work anymore or on my machine).
make clean-all; make all-win
to build
g++ -fPIC -c -o lib/radio_model.o lib/radio_model.cpp -I. -I./lib -pthread
g++ -fPIC -c -o lib/plugin_io.o lib/plugin_io.cpp -I. -I./lib -pthread
x86_64-w64-mingw32-g++ -o fgcom-mumble.dll lib/radio_model.o fgcom-mumble.cpp --shared -static-libgcc -static-libstdc++ -I. -I./lib -pthread
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccHQPJAy.o:fgcom-mumble.cpp:(.text+0xd5): undefined reference to `void pluginLog<char const*>(char const*)'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccHQPJAy.o:fgcom-mumble.cpp:(.text+0x151): undefined reference to `void pluginLog<char const*>(char const*)'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccHQPJAy.o:fgcom-mumble.cpp:(.text+0x22a): undefined reference to `void pluginDbg<char const*>(char const*)'
[... to be continued ...]
There is an issue with the direction finding code. It gives some off values in certain situations, most notably if the target points longitude is western of the base position.
The functions and formula is already checked and yielded nothing obviously wrong.
More details can be found in #8 (@hbeni in #8 (comment))
Affected code starts at lib/radio_model.cpp, line 65.
Angles can be measured easily using openseamap Törnplaner.
Testacase: Munic Tower to Treshold of RWY 08L.
Test tool can be built using make test
.
Actual:
./test/geotest 48.35303 11.78616 20 48.36263 11.76609 20 |grep "posA <direction>"
posA <direction> posB = 326.00°
Expected:
./test/geotest 48.35303 11.78616 20 48.36263 11.76609 20 |grep "posA <direction>"
posA <direction> posB = 306.00°
The botmanager should keep neccessary bot instances alive, resp restarting if they are killed/terminated.
Currently the plugin uses a simple radio model that checks a perfectly round geoid. It would be cool to check line of sight against a digital height model, so mountains will prevent vhf communications.
Maybe we can incorporate the SRTM/ASTER files for this.
Terrain data should be used to check line of sight obstruction by mountains/hills etc.
Probably some changes to the UDP fields HGT
and ALT
will be needed. the plugin should (remain to) operate internally on AGL[1].
ALT
therefore needs to be converted to AGL by querying the terrain model, if possible.
For LOS-Checks both values then firstly need to be converted to real altitude (or the terrain model path values corrected for the difference).
has also todo with #15
See also links there!
[1] For two reasons: 1. because this gives better radio horizons when no terrain data could be obtained; 2. to keep backwards compatibility to previous plugin versions
The mumble client is able to show comments, and recently the plugin API got new functions that exposes that comment to the plugin.
It would be good, if the plugin would show the following information in the plugin comment:
☝️ ⛔ Note that we only should show relatively stable data, so no fast changing data like position should be shown here.
Currently radio limits apply for landlines too.
We may treat the reception on signals on landlines differently:
For this to work, we need to establish a special common frequency syntax.
When the new SDK is released, we could (easily?) add support for MSFS 2020.
What is needed is just an interface that takes the simulators plane position and radio configuration and generate UDP packets to the mumble plugin (as per specification).
A quick google said, that maybe msfs2020 is compatible to SimConnect.
That said, it's still open if this compatibility could be reached by this project here, or if it better would be a separate project by its own.
I do not own MSFS2020 so probably will never be able to implement this (Help wanted!)
Useful ressources:
It looks like we need:
Field | Comment |
---|---|
ATC ID |
is this the multiplayer Callsign? |
PLANE LATITUDE |
lat |
PLANE LONGITUDE |
lon |
PLANE ALT ABOVE GROUND |
altitude AGL |
COM ACTIVE FREQUENCY:1 / COM ACTIVE FREQUENCY:2 |
to get the active frequency |
COM TRANSMIT:1 / COM TRANSMIT:2 |
is this the PTT state? |
COM STATUS:1 / COM STATUS:2 |
to get the COMs status: Radio status flag : -1 =Invalid, 0 = OK, 1 = Does not exist, 2 = No electricity, 3 = Failed (i.E. we could map 0 to COM_PWR=1 and everything else to COM_PWR=0 and leave the serviceable etc at default, which should handle all cases "powered/failed/not-present") |
There is a limit of eight radios currently.
That limit is arbitrary and an undefined number of radios should be supported.
Currently each update to LOC data (LAT/LON/ALT) triggers a notification to remote clients.
This may yield spamming the server, because for example FGFS updates that data several times per second, and in motion aircraft will change LAT/LON/ALT every time, but in tiny fractions.
Radio distribution model depends not so much on very exact numbers here. As long as the local client data is precise, it is not so important if remote senders are perfectly accurate; especially in normal flying conditions.
Thus, we may implement a throttle that only sends notification if:
Reported by mill-j:
Identified mumble branch state:
commit 9a4b659f4242e892f5686185e78fd18fcc93f84a
Author: Robert Adam <[email protected]>
Date: Fri Dec 25 18:50:22 2020 +0100
Fix copy&paste error
FGCom-mumble commit is 4b3ed22
I could not reproduce this here on my box (on mumble commit deb74a66348 "FIX: C&P error in API implementation" with 4b3ed22).
maybe this is a side effect of client version mismatch?
(This may have been introduced by mumbles commit c7ebe95030 "Synchronized API calls")
may be related to #58 as there are restructuring tips
Some aircraft may define a squelch value. according to http://wiki.flightgear.org/index.php?title=Common_Aircraft_Properties&mobileaction=toggle_view_desktop#Comms it is the property /instrumentation/audio/squelch-recv
.
Note: There is no such property at the old fgcom protocol.
The squelch should be mapped to a new generic squelch value, so we leave room for later addition of per-radio squelch values (which should then overwrite the generic setting, if both given).
Currently the UDP server (16661
+10) and client port (19991
) is fixed.
Once the mumble plugin framework supports plugin configuration, the plugin should support configuration of ports and hosts.
If one joins a server where a playback bot already replays its samples, they cannot ever be received: state is missing, because the bot only broadcasts this when joining.
When other users join, the bot should replay the data (ie. react on "icanhazdata" packet)
Currently the internal plugin state only grows.
It would be good if stale data would be cleaned out after some time to lower memory consumption, runtime and prevent unwanted side effects.
Currently it's good practise to restart mumble (and with it the plugin) between flights.
The FGCom-mumble plugin already supports user configuration trough a fgcom-mumble.ini
-file in the users home dir (see 0d257c6).
Once the mumble plugin framework pull request is done, Krzmbrzl wants to add a pugin config dir, where plugin configs can be placed (see mumble-voip/mumble#3743 (comment)).
Once this is defined, we should also look for a config file there, so we are standards compliant. The file there should be parsed first, so already established config files in user dirs remain dominant.
Currently, it is possible to send arbitary strings to the UDP interface, and consequentially to the plugin-io.
The current max messagesize is fixed server side to 1024 bytes, but it may be good to introduce further limits on the individual fields.
A standalone radio GUI might be useful that sets all the UDP parameters.
This is useful for testing purposes, as well as ATC'ing or making radio station broadcasts with redirected audio of a mumble client.
Especially useful would be:
The radio signal quality is already computed from the radio model.
It would be good to add static white noise depending on signal quality for nicer effects/more realism.
ACRE does this using DSP filters and that seems to be a good approach: https://github.com/IDI-Systems/acre2/blob/master/extensions/src/ACRE2Core/FilterRadio.cpp
When testing i see sporadic(!) memory leaks and segfaults.
Those need to be tracked down and closed.
I currently have a hard time reproducing this, but it's there somewhere.
Describe the bug
The mumble GUI freezes
(Maybe related to #65)
To Reproduce
a) Join the server
b) change channels
The bug does not reliably trigger, but @mill-j seem to be able to reproduce it reliably
Expected behavior
No freeze of the GUI
Additional context
Currently, if two (receivable) senders transmit on the same frequency, we can hear both in each individuals signal quality.
The signals however should overlap, like they do in real life, possibly cancelling/degrading each other.
Missing: How does that actually sound?
(for now we might just null some samples and introduce more static)
Currently we can just add new radios. It is not possible to deregister radios, because setting COM
n_FRQ
will be ignored.
therefore, implement a special setting to delete a radio:
<del>
this should be interpreted as deleted radio.The benefit of doing this is to free some bytes and save some milliseconds runtime. Long running processes like the bots may survive longer due to freeing memory.
Describe the bug
When tuning 910
and talking with PTT, the recording starts.
Once releasing PTT the recorder still is in recording mode and never releases (not even with timeout).
Expected behavior
When releasing PTT the recorder should stop recording. Replay should start.
Logfiles
None produced yet (should probably be in the recorder bot logfile
Additional context
I suspect there is an issue with the lua-mumble modue not reliably detecting the stop-speaking and thus not reliably calling the bot's hook. This should probably be reported to upstream once it is verified.
The recorder bot should however also monitor the change of PTT=on to PTT=off to trigger the end of the recording as a fallback/safeguard.
Make Flightgear able to parse the information and , if tuned to the frequency, make ADF needle move accordingly.
Note: this may be impossible if the property is tied to C++ space (which i assume); this then would need changes in the fgfs core. A Proposal could be another property that is investigated from the RDF/ADF C++ code and also taken into account.
We should look into this once mumble 1.4 is out and we have some pilot feedback on the overall system.
(Followup on the RDF feature #8)
(Followup on #28; see also: https://833radio.com/news/show/7)
Currently any frequency is supported. The plugin expects all clients to agree on a shared notion of „frequency“ however.
The radio model should however be adjusted, so slightly misaligned frequencies can be received, as could be the case with some 25khz and newer 8.3 frequencies.
From mickybadia at #28 (comment)
However note that now, you have to assume everybody with an 8.33 spacing, the way to test if two freq's (in MHz) are in tune being: abs(frq1 - frq2) < .025 / 3 / 2. Also see comment [*] below.
Good test values to combine are:
122.00 (traditional freq) 122.005 (8.33 name for the same frequency as above; both should be in tune; real freq is not the closest 8.33 freq) 122.010 (distinct 8.33 channel whose real freq is not the closest 25-spaced freq; in real life though, ACFT with older radios might hear it, slightly out of tune; do you want to simulate that? follow-up comment [*] below) record an ATIS on an 8.33 channel (e.g. the new 132.980 at EHAM); see if a flight sim cockpit can still hear it with an old radio (displaying 132.97)
[*] I think I might add a ticket for that because it is a new feature, still not discussed, but definitely part of real life and quite easy to simulate. The problem is that with real freq values only and with the current info from the clients, you have no way of accounting for the coexisting radio generations ("8.33" vs. older) in the airspace. You cannot know if a radio has a 25 or an 8.33 kHz freq spacing for its tuning. So for real simulation, perhaps a COMn_833=0/1 field would be advised, defaulting to 0 to allow the legacy FGCom integration to work. Then you would be able to adjust the "in-tune" test to know if a radio picks up a signal or not, and even the signal quality :-)
An issue arised, where ATC-Pie client and FGFS Clients could not reach each other, but used the same frequency.
Cause is that frequency is matched a string.
ATC-Pie provides 123.450
, whereas fgfs strips the last zero and puts 123.45
to the UDP server.
Solution is to strip trailing zeroes if they occur after the decimal point.
To make it more safe, leading spaces/zeroes and trailing spaces are now stripped as well.
The status page and mumble client comment currently display the real wave frequency in case it was provided as such.
It would be good, if the mumble comment and also the status page would show the 8.33 or 25 channel name instead, so users can more easily recognize and tune.
Currently if a 8.33 real wave frequency is supplied (like from ATC-Pie), the given token value from the protocol is supplied to the dialedFrq
field.
The place to code this up could be here, probably we should ask the selected radio_model
to provide a possible channel name.
fgcom-mumble/client/mumble-plugin/lib/io_UDPServer.cpp
Lines 223 to 226 in cfa1476
Currently the fgfs protocol file transmits two frequency properties in order to be able to suppor both the old 25khz and the newer 8.33 frequency selections.
I want to recheck if there is a usable common frequency property for both modes.
If fgfs transmits but this can lead to stuttering audio output because the frequency internally changes in a fast pace, potentially disrupting the incoming audio stream.
lua-mumble introduced some new API calls that break backwards compatibility in bkacjios/lua-mumble@407371a6dd6db6
The last known working version is bkacjios/lua-mumble@4856540f6cb4.
The lua bots need to reflect those changes, otherwise they won't work. This shows up by them not joining the appropriate channel and dumping a stack trace to the console like
statuspage/fgcom-status.bot.lua:292: attempt to index field 'user' (a nil value)
stack traceback:
statuspage/fgcom-status.bot.lua:292: in function <statuspage/fgcom-status.bot.lua:286>
[C]: in function 'loop'
statuspage/fgcom-status.bot.lua:333: in main chunk
[C]: at 0x5611dc3751d0
Describe the bug
See #70 #70 (comment):
So far, it appears to work reliable. I did notice something that I'm not sure is intended. If I tune RadioGUI com1 to 910 and com2 to another freq such as 123.00, transmitting on com2 will echo as well. The same is true for the RECORD bot. Is this working as intended?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Recorder bot should only record when the recording COM is PTTed
It would be beneficial if the releases would also contain 32bit binaries.
This probably can be achieved by the -m32
compiler flag.
Describe the bug
Latest mumble hangs (until manually ended with Ctrl+C) on shutdown with fgcom-mumble enabled. On my computer(Linux Mint 19.3) it's pretty well everytime. This is not a problem when the plugin is not enabled. Although disabling the plugin freezes the mumble settings dialog so I have to edit mumble's config files.
It also does not seem to be a problem with an older build that I think is 80de426
Expected behavior
Quit mumble completely without hanging.
Logfiles
Hangs at:
FGCom [2021-02-14 19:30:25.212]: Shutdown plugin
FGCom [2021-02-14 19:30:25.212]: [DBG] stopping threads
FGCom [2021-02-14 19:30:25.213]: [DBG] sending UDP shutdown request to port 16662
FGCom [2021-02-14 19:30:25.213]: [DBG] waiting for threads to finish
Additional context
Did some debugging and found if I modify the while loop in fgcom-mumble.cpp/mumble_shutdown() to:
// wait for all threads to have terminated
pluginDbg("waiting for threads to finish");
int shutdownTimeout = 0;
while (udpServerRunning || udpClientRunning || fgcom_gcThreadRunning || fgcom_debugthread_running) {
// just wait for the servers to come down. This should not take long.
// TODO: this may block forever. We probably should have some kind of timeout here.
std::this_thread::sleep_for(std::chrono::milliseconds(100));
if(udpServerRunning){pluginLog("Waiting on udpServerRunning");}
if(udpClientRunning){pluginLog("Waiting on udpClientRunning");}
if(fgcom_gcThreadRunning){pluginLog("Waiting on fgcom_gcThreadRunning");}
if(fgcom_debugthread_running){pluginLog("Waiting on fgcom_debugthread_running");}
if(shutdownTimeout > 20)
break;
shutdownTimeout++;
}
This allows us to see which bool is keeping it from exiting:
FGCom [2021-02-14 19:30:25.212]: Shutdown plugin
FGCom [2021-02-14 19:30:25.212]: [DBG] stopping threads
FGCom [2021-02-14 19:30:25.213]: [DBG] sending UDP shutdown request to port 16662
FGCom [2021-02-14 19:30:25.213]: [DBG] waiting for threads to finish
FGCom [2021-02-14 19:30:25.313]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.313]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.313]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.413]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.414]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.414]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.514]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.514]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.514]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.614]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.614]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.615]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.624]: [DBG] [GC] thread finished
FGCom [2021-02-14 19:30:25.706]: [DBG] ---------DEBUG THREAD FINISHED---------
FGCom [2021-02-14 19:30:25.715]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.815]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.916]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.016]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.116]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.217]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.317]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.418]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.518]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.618]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.719]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.819]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.920]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.020]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.120]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.220]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.321]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.421]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.421]: [DBG] mumble_shutdown() complete.
<W>2021-02-14 19:30:27.427 PulseAudio: Forcibly disconnected from PulseAudio
<W>2021-02-14 19:30:27.511 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.514 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.514 Clearing leaked memory from a plugin
A quick fix would obviously be implementing the timeout as I did above, but the indefinite loop is the likely the result of some other problem. I'm guessing another locking issue, which would make sense if something changed in mumble.
Followup on #33; related to #15
What is open here is the simulation of 25kHz radios: there the reception band is much broader (3 8.33 channels) and this also affects transmissions. Currently the VHF model simulates tuning bands of 8.33 channels only (which will work on cleanly tuned 25kHz as well as 8.33 channels, but not with overlaps between them aside from matching frequencies):
Old 25kHz Radios should receive all 8.3 channels in the tuned band, low quality (QLY one third at most)
8.33 radios should receive old broader band transmissions when their channel is in that 25kHz band
So the current band match function need to be made aware of the band spectrum of the signal involved, and that depend on the radio types.
Unless we find a way flightgear can give us that information, there is not so much point in stimulating this yet, especially as 25kHz radios are phased out already.
Related to Issue #6
Besides that, the plugin currently also expects the provided height as ASL, but treats it as AGL, which results in a further away radio horizon and thus more range than is realistic (the problem decreases with flight altitude tough). ASL can’t be converted to AGL without height model, btw.
A fix may be to enhance the UDP protocol to provide AGL too and preferring that over ASL for now.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.