search

swift-project / pilotclient

Cross-platform cross-simulator pilot client for virtual air traffic networks
https://swift-project.org
GNU General Public License v3.0
91 stars 26 forks source link

VHF 131.800 not connecting to HF 6.547 #200

Closed FlyingFoxVATSIM closed 1 year ago

FlyingFoxVATSIM commented 1 year ago

Several pilots reporting that 131.800 does not connect them on voice with HF 6.547.

PS: other swift pilot reporting issues with other Oceanic frequencies, too, e.g. 131.550.

Have we re-introduced old code in place of the revised type of code? We had tested and corrected this more than a year ago, if I am not mistaken on the date.

FlyingFoxVATSIM commented 1 year ago

Further feedback.

Testing right now 132.000 and it does resolve HF 13.306 correctly. The same applies to 130.000 ==> resolve correctly as HF 5.550. Have we started cutting off frequencies again and that's why only these freqs work, but 131.550 not?

ltoenning commented 1 year ago

With

CFrequency freq1(131800000, CFrequencyUnit::Hz());
CFrequency freq2(131.8, CFrequencyUnit::MHz());

freq1 == freq2 evaluates to false with a diff of 1.4901161193847656E-8 in CPhysicalQuantity::equals(...). Same happens with equal diff for 131.550 MHz but not for 132.000 MHz caused by double precision. The default epsilon for physical units is 1e-9.

With the 8.33 kHz update CComSystem::isSameFrequency (previously called isWithinChannelSpacing) depends on operator== for physical quantities. Previously isWithinChannelSpacing likely (unintentionally?) bypassed the problem here: https://github.com/swift-project/pilotclient/blob/a85905532efc4b7eed2edd43a0789e075add577b/src/blackmisc/aviation/comsystem.cpp#L149-L154

Hence finding the alias frequency and switching to the HF frequency does not work in all cases here as getOnlineStationsForFrequency(f) uses CComSystem::isSameFrequency: https://github.com/swift-project/pilotclient/blob/6dc2492d29814d14efa0671bb7c3e2204902a709/src/blackcore/afv/clients/afvclient.cpp#L1355-L1370

We could increase the epsilon but this might introduce new issues elsewhere... Any other idea?

FlyingFoxVATSIM commented 1 year ago

Just tested it with NAT_FSS and LPPO_FSS with a partial success only.

124.850 no voice, but text okay 131.700 no voice, but text okay 131.800 no voice, but text okay 131.900 ALL OK 132.075 ALL OK

MSFS swift 0.12.109 64bit

Phil7789 commented 1 year ago

As of today

132.075 no voice, but text okay

After restarting the client I wouldn't receive text messages that contained my callsign on that frequency. Other message were fine for some reason.

MSFS swift 0.12.103 64 bit (I assume .109 is a dev build)

ltoenning commented 1 year ago

Should be fixed with b43d093b6743121bd417dc7cb5ea598197897334 and published with 0.12.111.