Squelch

[MariuszXC]

Readme.architecture.md, line 48, lists an exception:

• silence-threshold: same, is not depending on the radio in question (but is not needed in fgcom-mumble anymore because of mumble taking care of that itself)

If the silence-threshold property represents the squelch setting of a given radio receiver, then the comment about 'mumble taking care of that itself' raises a question: how can the squelch setting - which is the radio operator's choice/preference - be handled without considering what the user had set?

Modeling radio ability to receive can be compared to modeling the first stage of a real radio receiver. Simplifying: if (after taking propagation into consideration) the antenna signal level is higher than input stage's own noise level, then there is some useful output signal from that stage; if not, there is always noise from the first stage. The signal after the first stage has a property known as RSS (Received Signal Strength). In real life it is frequently represented as a DC voltage representing the strength of the signal.

This output signal of the first stage is fed to the second (IF - intermediate frequency) stage for further demodulation. However, the end product is not always delivered to the speaker/headphones. It depends on how the user (radio operator) set the squelch.

Simplifying again:

• if the squelch is fully open, everything (noise and all) is delivered to the operator,
• if the squelch is set to some value (voltage), then the sound is delivered to the operator only if the RSS (voltage) of the received signal is highet than the squelch (voltage). In real life it is frequently implemented as a simple analog comparator, comparing RSS to squelch voltages.

I mention this as an issue because there is a considerable attention already paid to modeling radio propagation to keep user experience as realistic as possible. Respecting squelch setting seems therefore only natural (and, having some form of RSS calculated and knowing the user preference seems to be quite straightforward).

[hbeni]

I think this is just a misconception caused from my not perfect english skills :). The old FGCom did not honor the radio's squelch, thats what is different to the old FGCom protocol (the context of the sentence in question is about what is different to the old FGCom protocol - thus describing what will not work if you don't use the new protocol file).

The new protocol file already transmits the squelch value: https://github.com/hbeni/fgcom-mumble/blob/e01a2ab430bae7db175904d24acce720bb8d182f/client/fgfs-addon/FGData/Protocol/fgcom-mumble.xml#L83-L86

And that value is honored properly by the plugin: https://github.com/hbeni/fgcom-mumble/blob/e01a2ab430bae7db175904d24acce720bb8d182f/client/mumble-plugin/fgcom-mumble.cpp#L1019-L1026

[MariuszXC]

I see :) Better a misconception than lack of support.

I don't know if such level of realism is desirable, but in real life there is usually some hysteresis built into the squelch comparator. The reasoning being, that within one transmission signal level (RSS) may fluctuate a little, so if (a part of a) transmission was strong enough to open squelch barrier, then it is assumed that the radio operator is interested in listening to the rest of the transmission, even though parts of it may be a bit degraded due to variance in propagation.

pseudo-code wise:

if squelch is closed then: if signal_RSS > squelch_setting then: { deliver_signal = true; squelch = opened; }

if squelch is opened then: if signal_RSS < (squelch_setting - hysteresis) then: { deliver_signal = false; squelch = closed; }

[hbeni]

I don't know if such level of realism is desirable

This may be a cool addition to some much more refined radio simulation. Currently , we lack this detail of simulation tough.

I close it for now, OK, the initial topic is resolved.

(Ref #15 )