Transmissions unreceived when using callsigns without registered transceivers

[19wintersp]

When using callsigns with infixes (EGCB_I_TWR, EGKK_T_GND), transmissions from aircraft can be heard, but transmissions made are not received by aircraft. This does not happen with any other callsigns, including equivalents omitting the infix (tested EGKK_GND, which worked normally).

Relevant log sections (edited)

``` Starting VectorAudio... // audio device setup Loaded 28891 airports in 266ms Detected VATSIM client connection Found client position from slurper at lat:51.14806, lon:-0.19028 // audio device setup [afv_native] APISession API Token Expires in 3600 seconds [afv_native] afv_native::ATCClient Connected to AFV API Server [afv_native] ATCClient Need to fetch transceivers for station EGKK_T_GND [afv_native] afv::ATCClient Voice Session Connected [afv_native] afv::ATCClient Speaker device already exists, skipping creation // audio device setup [afv_native] APISession got 108 station aliases. [afv_native] APISession got error from API server getting vccs: Response Code 404 [afv_native] APISession got error from API server getting station transceivers: Response Code 404 [afv_native] Client Opened PTT // "can anyone hear me" [afv_native] Client Closed PTT [afv_native] afv::ATCClient Voice Session Disconnected [afv_native] afv_native::ATCClient Disconnected from AFV API Server. Terminating sessions ``` The log regarding EGCB is essentially identical, aside from obvious substitutions.

I'm not nearly familiar enough with AfV and its accomplices to offer useful counsel, but would just reiterate that whilst the infix is typically meaningful in designating the position, it is sometimes only used for disambiguation within a single position, as in the case of KK. However, this should not be the same issue as with CB, where the _I_ infix is part of the designated position.

Many thanks for this project and your time, and sorry if this has been reported and fixed already :)

[pierr3]

What is your connection type to VATSIM? This is likely to occur because you did not set a frequency in EuroScope or connected as an observer, which does not allow you to transmit. There does not seem to be an issue with other positions with an infix.

[19wintersp]

This was connected as a controller via EuroScope, with primary frequency correctly set.

[pierr3]

Could you please triple check your audio settings and try again? if on macOS, check that there is sufficient permissions for your microphone. Does the TX button turn yellow/did you click the TX button so that its status is green?

[19wintersp]

Every other callsign works flawlessly, including the version without the infix (as mentioned). It may well be something else, but it's so far a perfect correlation and one to which I can find no other coincident.

[pierr3]

Interesting, any chance you can try with a position that has a definition within the AFV database? Still not sure what would cause this issue

[19wintersp]

Sorry, I'm afraid you'll have to clarify what you mean :sweat_smile:

[pierr3]

Haha sorry, trying logging on as EGKK_I_GND, but then manually add EGKK_GND as a station, and using that for TX

[19wintersp]

I did try that when attempting to fix the issue initially, to no avail. I did also try deleting stations and restarting, as well as refreshing them.

[pierr3]

And you can receive but not transmit? Which platform are you on?

[19wintersp]

Receiving works fine, yes; Linux/Ubuntu

[pierr3]

Pulse or alsa?

[19wintersp]

I believe VectorAudio is using Pulse

[pierr3]

Alright, I am about to push a new version, please give it a try and then we will see if we can reproduce this

[19wintersp]

Thank you for your time on this. I'll try it out as soon as possible, but this will be dependent on when I'll be able to next use the problem callsign.

[19wintersp]

I've had another look through this just now, and—bearing in mind prior notes regarding inexperience—it seems to me that the issue is simply that there are no transceivers defined for these positions (the voice server returns 404), and AFV-native doesn't handle this (https://github.com/pierr3/afv-native/blob/c692be5b3dd49d62b6cfe9f4a2a6d7dbfbc3d0aa/src/afv/APISession.cpp#L495). From the AfV documentation, it seems like the intended behaviour is for the ATC client to select a default transceiver setup based on the location and position type (https://audio.vatsim.net/docs/faq/atc). Whilst I haven't been able to test the new release yet, I don't see any changes within AFV-native that would affect this.

[pierr3]

Indeed, but this should already be the case, as a transceiver is created if none are found using the client position, see: https://github.com/pierr3/afv-native/blob/c692be5b3dd49d62b6cfe9f4a2a6d7dbfbc3d0aa/src/afv/ATCRadioStack.cpp#L438 as well as https://github.com/pierr3/VectorAudio/blob/79759dcc0f83e293a2c6a36e060c62e6dd89651e/src/application.cpp#L595C26-L595C26 and https://github.com/pierr3/VectorAudio/blob/79759dcc0f83e293a2c6a36e060c62e6dd89651e/src/application.cpp#L616

One issue I can see is that if the slurper is available, it will use 300ft as elevation, which in some cases might not be appropriate ? Although since there is no terrain simulation in AFV that should not be an issue. That I am now thinking is that the slurper is not returning your correct lat/lon, but your log file shows Found client position from slurper at lat:51.14806, lon:-0.19028 which seems correct.

In any case, when you log into those positions, you should be able to manually add, say, EGKK_TWR and then use "XC" to use the transceiver from that defined location, or just simply use that definition position, which is the way you should be doing it in any case if it is the same frequency.

Let me know if you spot any errors around the code in this, I will try to dig a bit too

[19wintersp]

Thank you for the thorough explanation. The elevation and location provided should be absolutely fine for this position; I think I will just try to have a more in-depth look whenever I next get the chance.

[19wintersp]

Hello, I've been able to log onto Gatwick since and adding the EGKK_GND station separately worked, bizarrely, perfectly; thank you. However, EGCB_I_TWR still does not work.

Whilst I'm sure you'll prove me wrong quickly, I've unfortunately had another look through the code and believe I have found an issue:

The transmission data sent to the network is contained in the AudioTxOnTransceivers DTO, which includes the list of transceivers to transmit on. This DTO is populated in the callback from the audio processing/compression pipeline, ATCRadioStack::processCompressedFrame:

// ...
dto::AudioTxOnTransceivers audioOutDto;
std::lock_guard<std::mutex> radioStateGuard(mRadioStateLock);
// ...
for (auto &radio : mRadioState)
  for (auto &trans : radio.second.transceivers)
    if (radio.second.tx)
      audioOutDto.Transceivers.emplace_back(trans.ID);
// ...

...such that the transceivers field contains all transceivers (as defined by mRadioState) where the associated radio is in transmit mode. However, the issue lies in that the default transceiver is created in the ATCRadioStack::makeTransceiverDto function:

// ...
for (auto &state : mRadioState)
  if (state.second.transceivers.size() == 0)
    // If there are no transceivers received from the network, we're using the client position
    retSet.emplace_back(i, state.first, mClientLatitude, mClientLongitude, mClientAltitudeMSLM, mClientAltitudeGLM);
// ...

...the result of which, the Transceiver DTO, is only used to send to the network, and does not update mRadioState. The only instance I can find of the mRadioState transceivers being updated is in the stationTransceiversUpdateCallback function (via ATCRadioStack::setTransceivers), which is only called with the "200 OK" response when fetching transceivers from the API. Thus, it seems that no transceivers will ever be sent with the AudioTxOnTransceievers packet even if a default transceiver based on the client location has been registered with the API.

[pierr3]

I think you found the issue, and I have nothing to correct about your findings haha. Thank you for identifying this, it's a pretty big issue. I will proceed with a fix and hopefully that should be solved.

Thank you again

[19wintersp]

After pulling the latest changes from the afv-native repository and building VectorAudio with the new binary, EGCB_I_TWR now definitely works, and other stations remain functional as before. Thanks so much for your responsiveness and for making these changes :D

[pierr3]

Thank you for testing this, great that it works.