Support different locations (multi identities)

[hbeni]

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.

• For that we introduce "identities". Each identity can have the currently known state (a callsign, location, radios, ...)
• Identities are bound and identified by a numeric ID.

This needs a huge rewrite of the plugin code, however:

• [x] local state must be an array of identities instead of a plain single struct
• [x] Remote states must be redesigned so each mumble client-id can have several identities
• [x] UDP input server must be altered:
  • A new Field is introduced: 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.
  • plugin spec must be enhanced to reflect current state (callsign beeing mandatory if one want to select other identities)
• [x] the internal plugin-i/o protocol (notification sending/receiving) must be enhanced to differentiate between the selected identity (a good place would probably be the dataID field, we are doing something similar in the COM-selection alredy)
• [x] The radio signal checks need to be recursive on all local and remote identities.
• [x] The server side bots must support this new structure as well
• [x] RDP RDF output must be reconsidered too: RDF-ID field must be enhanced, Callsign should be declared mandatory, protocol scheme must be changed to "ordered": probably the easiest one is to make one line per identity (so if several identities receive in parallel, the output is multilined)
• [x] statuspage needs to handle multiple locations per client (statusbot writing proper data should be enough for this, i think)

This will break backwards compatibility in the internal plugin-io-protocol, so a new version number is needed.

[mickybadia]

Hi, thanks for following up on this. If it were me, I would listen on only one port, the included callsign being enough a distinction when you need one. It will be a lot more parsimonious, and would allow for a muuuuch easier config on the ATC-pie side: users choosing a port for the plugin in the settings and NOT dealing with it any more afterwards when turning on/off locations, at least for as long as the plugin is running. The feedback port (RDF) will not be a problem as it is now being requested by each client with RDF_PORT (and these would be different for each instance; this is already managed by ATC-pie).

[hbeni]

It's a good idea to bind "virtual instances" to the callsign! [edit] we also could default UDP commands to the first identity, if callsign was not given in the message. With that we can stay downward compatible to the FGCom protocol for flightgear.

Internal plugion-i/o must reflect that however, especially in the notification routines.

(has todo with #23/port config)

[edit] updated the ticket description with new draft.

[hbeni]

@mickybadia, i updated the ticket's description with a brief draft, can you please review it? For identifying different identites I think we better go with a distinct new value. This will ease callsign switches and allows for easy backwards compatibility.

Most important, will there be a problem when the RDF output will be one line per identity (ie. "separate location with its own callsign and radios")? For example, three radios on two locations (loc1 has one, loc2 two radios here) all receiving RDF will output two lines like:

RDF_5-0-0_CALLSIGN=Test-1111,RDF_5-0-0_FRQ=118.7,RDF_5-0-0_DIR=326.000000,RDF_5-0-0_VRT=-2.854930,RDF_5-0-0_QLY=0.999933
RDF_5-1-0_CALLSIGN=Test-2222,RDF_5-1-0_FRQ=118.7,RDF_5-1-0_DIR=326.000000,RDF_5-1-0_VRT=-2.854930,RDF_5-1-0_QLY=0.999933
RDF_5-1-1_CALLSIGN=Test-2222,RDF_5-1-1_FRQ=118.7,RDF_5-1-1_DIR=326.000000,RDF_5-1-1_VRT=-2.854930,RDF_5-1-1_QLY=0.999933

(The syntax of the ID field will probably change to something like <mumbleID>-<IdentID>-<RadioID>; or would be a new field ID=<identID> be better?)

It will be no problem to separate the records using , like now, however for clarity and parsing on your side it may be easier with newlines?

[mickybadia]

Tbh I don't really care what the format of the packet is, but if you use one line per live signal, I don't think you need to repeat its ID in every field. You could go for something like:

RDF_5-0-0:CALLSIGN=Test-1111,FRQ=118.7,DIR=326.000000,VRT=-2.854930,QLY=0.999933
RDF_5-1-0:CALLSIGN=Test-2222,...
etc.

To me this would look somewhat more elegant, but it is your choice.

Then in my mental picture, the RDF packets sent to a client (on their requested RDF_PORT) only contain the live signals to which the client is sensible (i.e. client monitoring RDF and signal strong enough). So, if radios are used conventionally without blocking each other's transmissions, one would normally receive one line at most with the same frequency at the same time. I am saying this because if your code extract is a single multi-line packet, I interpret it as three radios transmitting over each other.

[hbeni]

@mickybadia Uploaded current draft to the branch multiIdentity. In short:

• supply IID=<number> to switch consecutive fields in the UDP message to the identity given (0 is the default identity)
• i adjust the RDF protocol to our proposal above, so: each signal is spit out to its own line, the ID is in the first field followed by colon :, and the fields for the RDF signal are without prefix now.

See client/plugin.spec.md for details.

[mickybadia]

Great to see this happen all so fast!

I feel an improvement is possible, which follows. But before I explain it I'll say that your proposal would technically cover everything ATCs would need as it stands. So at least in that respect, thank you. :-)

The thing is, I don't see why CALLSIGN is not your way of identifying COM sets, in other words what IID brings that CALLSIGN would not already offer in our context. Moreover, you are thereby compelling network clients to decide on a unique ID for themselves, which is typically something one would try to avoid in a distributed system. Fortunately in this specific case, the clients already must pick a port number to join FGMS uniquely from the local host so as long as your plugin restricts its use to localhost clients I can use that port number as IID. But it is still a redundancy I would personally get rid of. The same goes for the word "identity", which could simply be collapsed with "callsign" (a callsign precisely serves as the unique radio identity in real life). The whole spec will gain in simplicity, and your architecture get rid of superfluous/repeated data.

[hbeni]

Good morning, the reason i did it this way is downward compatibility to the fgcom protocol. There a changed callsign would rename that clients callsign and without iid we cannot detect which identities callsign should be renamed.

The IID is not a global unique number, but bound to the mumble session id and thus always local to the client. So each client justs needs to gracefully count upwards starting from zero.

For your purposes (differentiating rdf source signals) just use the callsign 😁 And for registering new locations, just Index them starting from 0 and remember which location is what id locally.

[hbeni]

... thinking about that i see an issue in the current rdf identifier: currently there is no info that allows you to correlate the info to local identities. I will again change the rdf output: the prefix will be just the senders callsign and the local IID.

[mickybadia]

I honestly don't understand why callsign+radio would not be enough for your plug-in (or any program on the network) to safely identify a signal in all circumstances, whether receiving from an old FGCom, a new ATC-pie, or a mix thereof. Nor what the added value of IID is, nor why you would ask for sim clients to provide extra numbers which is not ideal design if they are separate processes. But I don't mean to get back in a tug war here. I will let you propose the scheme you want, and if ATC-pie can work with you it will.

[hbeni]

As i said above: with only callsign, the UDP input interface could not detect if you want to register a new callsign or change a previous one. FGcom defined „new callsign“ => rename.

So if i relied on callsign alone, we could only ever create new identities, and never rename existing ones, breaking FGcom compatibility in that API piece. If we find a solution for that, it is true that callsign+radio would be enough, given that there is an info for other clients to detect callsign change (which won’t happen in real life, but will in simulator space, for example if i switch to another plane).

[hbeni]

So, tchanged RDF spec. You just need to supply the IID to the UDP input message to create/update new locations in the plugin.

This is the result:

[mickybadia]

To confirm I understand correctly, we have now lost signal ID, so I will have to rely on the (SRC, FRQ) pair to identify new/dying signals... with the consequence of collapsing two signals if one callsign emits two on the same freq (more of a theoretical comment, will never be a problem in practice).

What is the purpose of TGT? Does this imply that if I am A, I will now be receiving information like "B currently receiving a signal from C"?? If so this is less than ideal, especially if connection count grows on a server. And as far as I can think, the whole list of who receives what everywhere in the world is never useful. But if you double down on this bulky protocol, I can always filter on my side.

Last piece of advice, but almost a repeat of the RDF reply port problem: get your own IID from the sender's address (port is enough if everything is localhost). This need is planned and built in the UDP protocol; it is quite weird (and could be either impossible or subject to human errors) to have to uniquely identify yourself as a client inside the data payload. But as I said, not my code, and in our case I can just send that same port number as IID so if you like the redundancy, at least the users will not be creating discrepency.

[hbeni]

To confirm I understand correctly, we have now lost signal ID, so I will have to rely on the (SRC, FRQ) pair to identify new/dying signals... with the consequence of collapsing two signals if one callsign emits two on the same freq (more of a theoretical comment, will never be a problem in practice).

No, you got something mixed up here. (OK: yes, if that signal is sent from two radios tuned to the same freq and from the same callsign/identity/location; BUT you would nonetheless get two lines for that on the output! I traverse all remote radios for received signal info and ouput a line for that). If this is a problem, i can re-add the remote radio id as field. Should i?

What is the purpose of TGT? Does this imply that if I am A, I will now be receiving information like "B currently receiving a signal from C"?? If so this is less than ideal, especially if connection count grows on a server. And as far as I can think, the whole list of who receives what everywhere in the world is never useful. But if you double down on this bulky protocol, I can always filter on my side.

The plugin models a set of radio devices which are each bound to a "identity" (with its own callsign and location information). If an RDF enabled radio detects a signal, RDF information for that signal is output to the UDP port. It is therefore possible that a given radio detects several signals on the tuned frequency. I this is the case, for each signal an UDP line is generated. Because you can have several identities at different locations, it is possible to receive signals on both identities in parallel, even possible on the same frequency. This is the reason for CS_TGT and CS_SRC: it lets you detect which signal was received from which location, by resolving the CS_TGT values. To aid in distinguishing further which callsign was the sender, i decided to include that info as well, but you may also ignore it if you don't need it (what seems to be the case). It is NOT the case, that the RDF info includes ANY signal on earth, just the ones that can be received from your locations and its radio configurations (so you never get "B receives C" unless you are "B"). Should i rename TGT/SRC to something more telling (like CS_TX/CS_RX)?

---

Last piece of advice, but almost a repeat of the RDF reply port problem: get your own IID from the sender's address (port is enough if everything is localhost). This need is planned and built in the UDP protocol; it is quite weird (and could be either impossible or subject to human errors) to have to uniquely identify yourself as a client inside the data payload.

Thanks for pointing that out so clearly, i think i understand it better now. I will do the following, and we will have the best of the two worlds:

• [x] default behaviour at UDP input interface will be changed: the senders port from the packet will be used to establish the default identity.
• [x] subsequent new detected client ports to the UDP interface will be establishing new identities
• [x] the IID= field will remain in place, so clients handling it like implemented 'till now can switch identities while remaining on the same client port
• [x] The RDF UDP output port will be defaultet to the client port given in the UDP input datagram per identity, so effectively bind to the identity source port.
• [x] RDP_PORT=will remain functional, so the client can switch the identities output port by request.
• [x] RDP_PORT= will honor client source port and IID= so one can change the port of an arbitary identity.
• [x] setting the rdf=1 for a COM will enable rdf output for that identity on its configured port

This will preserve flexibility, but offer (i hope) the functionality you proposed:

• Your client sending port will define "identity" ID
• Your client sending port will define the port the plugin sends RDF info to
• ATC-Pie therefore just needs to send UDP config messages to the plugin port, and can distinguish identities by sending from different client ports. No more need to invoke RDP_PORT or IID anymore (unless you want to override)!

Did i got it all right now, or do i still misunderstand something?

PS: You see i'm not that familiar with network coding, i'm doing this the first time and want to come up with something good but flexible. I appreciate your input alot and i thank you very much for your patience with me.

[mickybadia]

No problem if you need help with the network arch, I really more importantly appreciate that you proposed the features. More than one of us have been talking of the need for an FGCom "neo" for a while. As I told you right from the start, taking the time to find a neat way and propose something is really the only safe way to make it happen, and we will all be grateful that you did.

Back to the architecture, my general feeling from the start is that you have basically been making things harder for yourself by defining unnecessary notions and providing for inexistant use cases. For example, the level of the person operating the multiple locations, and the list compiling all corresponding RDF signals (which you considered sending as a whole) is irrelevant. In other words, there is no relevance to the "you" in the sentences below:

Because you can have several identities at different locations, it is possible to receive signals on both identities in parallel, even possible on the same frequency. It is NOT the case, that the RDF info includes ANY signal on earth, just the ones that can be received from your locations and its radio configurations (so you never get "B receives C" unless you are "B").

With a more standard approach, which virtually any dev/app will later expect, you should make the simulator client, identified by its UDP source address/port and nothing else, as the only relevant working unit for your plug-in service. Each of these clients already comes as its own "identity" (which incidentally becomes a superfluous term), and each should be sent only the signals that you find it picks up. With this filter applied, no more need for TGT. Without it, clients will be receiving "B receives C" while being neither, and have to refilter.

Should i rename TGT/SRC to something more telling (like CS_TX/CS_RX)?

RX would indeed be semantically more appropriate given the radio context where there is no "target", the wave propagating in all directions and being possibly picked up by many stations. But given what I said above, it will probably simply disappear instead. Signal "source" however is perfectly fine.

To aid in distinguishing further which callsign was the sender, i decided to include that info as well, but you may also ignore it if you don't need it (what seems to be the case).

Since you dropped signal ID, I will need the source callsign to identify signals. So good thing that it is in there, I will no longer be ignoring it.

I take the liberty of responding to each item below, regardless of if it brings repetition. The hope is that I make myself clearer by being responsive to your proposal (as per request); no attitude to be interpreted from the terse syntax.

I will do the following, and we will have the best of the two worlds:

What second world?

* [x]  default behaviour at UDP input interface will be changed: the senders port from the packet will be used to establish the default identity.
* [x]  subsequent new detected client ports to the UDP interface will be establishing new identities

Superfluous mechanism: each sender's port is its identity, and remains such (not a "default").

* [x]  the `IID=` field will remain in place, so clients handling it like implemented 'till now can switch identities while remaining on the same client port

Do not tie yourself to your own trials and errors of a development phase (in which we still are). No backward compatibility required by anybody at this point.

* [x]  The RDF UDP output port will be defaultet to the client port given in the  UDP input datagram per identity, so effectively bind to the identity source port.

Did you mean "send" instead of "bind" here? Also, superfluous mechanism: sending back to requesting source is the only behaviour one will ever expect from you (not a "default").

* [x]  `RDP_PORT=`will remain functional, so the client can switch the identities output port by request.

Superfluous mechanism: if a client ever wants the data to be read elsewhere, it will itself forward it, with the responsability of the target port. Caution as you remove: to know if RDF data should be sent to a client, you will need either to replace with a "REQUEST_RDF=0/1" or to look for a "COM_RDF=1" in any of the radios yourself.

* [x]  `RDP_PORT=` will honor client source port and `IID=` so one can change the port of an arbitary identity.

Not fully unserstood but I suppose I can ignore since both mentioned fields would be given up following the above.

* [x]  setting the rdf=1 for a COM will enable rdf output for that identity on its configured port

This will preserve flexibility, but offer (i hope) the functionality you proposed:

• Your client sending port will define "identity" ID
• Your client sending port will define the port the plugin sends RDF info to
• ATC-Pie therefore just needs to send UDP config messages to the plugin port, and can distinguish identities by sending from different client ports. No more need to invoke RDP_PORT or IID anymore (unless you want to override)!

Quick comment on the third item: different clients will necessarily send you their packets from different ports, so no worries about distinguishing clients. Maybe your thinking otherwise brought you into the mess of IIDs in the first place?

Did i got it all right now, or do i still misunderstand something?

It seeems that this last list of yours does indeed recap the way it should work. I hope any pain suffered in the discussion is outweighed by the perceived progress on your side :-)

[hbeni]

Good morning, and thank you. Very well commented!

I will work trough that but from first read it looks like the code now does what we need 👍 Documentation should be changed but currently i would rather leave the technical support for the fields in. If they aren’t supplied they do no harm, but may come in handy later.

One quick word about the IID and RDP_PORT issues: part of this stems from the problem of switching sessions in fgfs while leaving mumble open. We would have two fgfs instances registered in mumble so we have zombie radios that work. Yesterday i figured out how this can be dealt with (new ticket #32 to time out old data) So should not be an issue anymore.

[hbeni]

Hi there, three commits should fix the open issues:

• 9a06832 Updated readme: IID and RDP_PORT fields of the UDP input interface ar…
• fa3996e RDF: Removed superfluous CS_TGT, renamed CS_SRC to CS_TX
• 1afc9e3 Implemented garbage collector

[hbeni]

@mickybadia: If you have code ready for testing, let me know. For what i see, this side here should be working now as expected :smile: :small_airplane:

[mickybadia]

I can push something real quick but confirm there is nothing to declare or request for RDF, other than having one of the radios with an "_RDF=1"?

[hbeni]

I can push something real quick but confirm there is nothing to declare or request for RDF, other than having one of the radios with an "_RDF=1"?

copy that!

[mickybadia]

* [1afc9e3](https://github.com/hbeni/fgcom-mumble/commit/1afc9e3ed7f9e536413706d07813381733ed50d8) Implemented garbage collector

Does this make the requirement for ATIS recording and echo testing to end with a PTT=0 also obsolete?

[hbeni]

No, because this is currently (due to mumble plugin hooks) the only way for the plugin to see that the transmission was ended.

[mickybadia]

confirm there is nothing to declare or request for RDF, other than having one of the radios with an "_RDF=1"?

copy that!

Haha, I had hidden a question in there. Anyway, I have assumed the answer was yes, and pushed accordingly.

No, because this is currently (due to mumble plugin hooks) the only way for the plugin to see that the transmission was ended.

Oh OK I thought you meant short time-out, i.e. of the sub-second order to detect ends of packet streams. Using those is somewhat more risky but would enable radios, ATIS and test to stop automatically.

[hbeni]

Oh OK I thought you meant short time-out, i.e. of the sub-second order to detect ends of packet streams. Using those is somewhat more risky but would enable radios, ATIS and test to stop automatically.

Can you elaborate a little more what you mean? I can’t understand, sorry. Do you want to say it would be cool to reset ptt in case Stream is cut off? If yes, i would expect mumbles plugin api to tell me that via a callback, but that’s not available in the api. That said, the current ptt implementation is reliable because it’s transmitted with TCP between the clients, and if there are no more voice packets arriving, there is nothing to check against so no problem.

[hbeni]

And a second question: How do i register a ctr instance in atc-pie, besides a twr session?

[mickybadia]

Oh OK I thought you meant short time-out, i.e. of the sub-second order to detect ends of packet streams. Using those is somewhat more risky but would enable radios, ATIS and test to stop automatically.

Can you elaborate a little more what you mean? I can’t understand, sorry. Do you want to say it would be cool to reset ptt in case Stream is cut off?

I think the answer here is yes. My understanding of "time-out", given that the added piece was a "garbage collector", was that you would detect when enough time had passed without a certain input from a (sim) client, in which case you'd destroy its data, assuming they have gone. I was just wondering if this was a long-term time-out, i.e. one that serves only to clear memory from old left-overs, or a short-term one, i.e. meant to be responsive to the end of a ~10Hz packet flow, and stop PTT and destroy deleted radios immediately. I now understand it is the former only, so I will keep the added PTT=0 at the end of the special ATIS and test packet flows.

How do i register a ctr instance in atc-pie, besides a twr session?

When you start the program with no location argument in the command, the welcome launcher offers you the choice between AD and CTR modes. You can define your CTR position right there. To do it by hand, edit the CONFIG/CTR-positions.ini file (see Notice).

[hbeni]

How do i register a ctr instance in atc-pie, besides a twr session?

When you start the program with no location argument in the command, the welcome launcher offers you the choice between AD and CTR modes. You can define your CTR position right there. To do it by hand, edit the CONFIG/CTR-positions.ini file (see Notice).

Ah ok, so two ATC-Pie clients needed. I just tested and found you are hard coding your client port to 5000. This now results in ATC-Pie overwriting each others session in the plugin (because both send on 5000, there is no distinguishing between them)

From our conversation i assumed you would send a random client port (which is stable between ATC-Pie sessions). So either you send different ports per session or you need to supply IID with your desired session id...

[mickybadia]

Definitely not hard coded, or there is a serious bug on my behalf :-) I confirm you should identify the client by its source address (incl. port). Definitely not random either! The port ATC-pie sends you its control packets from is the same one that it uses for the FGMS network it has joined (except if echo testing outside of a running session). This port must be different to that of all other running clients, which is the responsibility of the user, and chosen at connection time with the callsign (start session dialog: "local UDP port"---maybe you missed that?).

[hbeni]

start session dialog: "local UDP port"---maybe you missed that? oh yes, i did!

Just tested OK:

• one mumble instance serving FGFS
• one mumble instance serving two ATC-Pie sessions (ports 5000=EDDM, 5001=CTR at a fix to the south)
• I chosen the EMG frequency
  • sending/receiving worked
  • RDF worked on both locations, however at the CTR the line was not printed to the radar screen (the info in the status line was OK, however!)

This looks really good now. I think i can merge this down now...

[mickybadia]

* I chosen the EMG frequency

I recommend you test with other freq combos of TX, RX, and RDF monitored, including with 8.33 channel names such as "122.005" which do not correspond to a MHz value (manual input is possible in the freq boxes). Indeed we each have frq comparison/matching code in several places, which should be thoroughly tested. :-)

  at the CTR the line was not printed to the radar screen (the info in the status line was OK, however!)

Had you turned it on in the radar "Opts" menu? If so, probably a bug. Note though that I am not sure RDF makes much sense to CTRs anyway, especially centred with the radar like this...

[hbeni]

I will retest this soon :)

For the frequencies: i will test that too again, but as long as the client supplies a frequency, it should match. Numeric frequencies (aka everything tunable wich results in a number) are normalized, so should always match (i did torough tests on this important part of the plugin code already)

[hbeni]

When clicking "silence radios" i got a segfault in ATC-Pie:

Traceback (most recent call last):
  File "/home/beni/Dokumente/FGFS/work/atc-pie-fgcom-mumble/gui/panels/radioCentre.py", line 235, in toggleSilenceRadios
    self.radioBox(i).setVolume(0)
AttributeError: 'RadioBox' object has no attribute 'setVolume'

---

Your hint with the RDF show line Option was correct! But there also seem to be an issue with the RDF reception on the 8.33 channels: 122.005 did not seem to recognize the given RDF signal. 118.700 did however.

RDF debug output for working case:

FGCom: [DBG] [RDF] client sending msg for iid=0 to port=5005: 'RDF:CS_TX=D-EBHX,FRQ=118.700,DIR=216.871567,VRT=1.858750,QLY=0.986351
FGCom: [DBG] [RDF] client sending OK (70 bytes of data)
FGCom: [DBG] [RDF] client sending msg for iid=1 to port=5002: 'RDF:CS_TX=D-EBHX,FRQ=118.700,DIR=338.253510,VRT=2.647895,QLY=0.993272
FGCom: [DBG] [RDF] client sending OK (70 bytes of data)

Then switching my COM breaks RDF reception (edit: note only the FRQ value changes):

FGCom: [DBG] [RDF] client sending msg for iid=0 to port=5005: 'RDF:CS_TX=D-EBHX,FRQ=122.005,DIR=216.871567,VRT=1.858750,QLY=0.986351
FGCom: [DBG] [RDF] client sending OK (70 bytes of data)
FGCom: [DBG] [RDF] client sending msg for iid=1 to port=5002: 'RDF:CS_TX=D-EBHX,FRQ=122.005,DIR=338.253510,VRT=2.647895,QLY=0.993272
FGCom: [DBG] [RDF] client sending OK (70 bytes of data)

---

Other than that: comms worked fine! :ok:

[mickybadia]

When clicking "silence radios" i got a segfault in ATC-Pie

Thanks for spotting the bug. Should be corrected now.

But there also seem to be an issue with the RDF reception on the 8.33 channels: 122.005 did not seem to recognize the given RDF signal. 118.700 did however.

This shows that you are not dealing with 8.33 channel names, but considering only real wave frequency values. I actually think this is better, and I thought I had understood or assumed that from you already but it seems that I have implemented otherwise. So I have now changed to resolving the frequencies for you in the _FRQ fields. 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 :-)

[hbeni]

The plugin just checks if the provide FRQ values match. There is currently no further logic, but i agree, some small „misslignment“ should be supported, but i think I’ll leave that to the advanced radio model ticket #15.

So currently the test case will fail. The plugin assumes all logic for channel to frequency stuff is already taken care of from the client, so yes, the FRQ is „wave frequency“. But i assumed that don’t matter: if there is some advanced logic, all radio clients will implement that and supply the same FRQ values (which may or may not be „real wave“, it’s just important that both clients agree on what to set. FGFS obviously does not currently, at least not with the c182s or default radio implementation)

[mickybadia]

Regardless of my comment labelled [*] (this indeed is one level up), you should still replace the float equality test (which incidentally is a persistent red flag in programming) and give a margin because with new 8.33 channels, decimal representation will eventually throw you distinct things like 122.00833333 and 122.008, both valid, and the two should still match.

[hbeni]

Already handled: They do match, i compare formatted strings currently with a three decimal precision.

But i agree for the range match.

Let me dig into current fgfs code how the 8.33 spacing is modeled.

[edit] see c172 commit https://github.com/c172p-team/c172p/commit/bf6313d7ea24ecb80835c2f4ded851b74e92f561

[mickybadia]

i compare formatted strings currently with a three decimal precision.

I would advise against that at this point. For example channel "123.015" has a real frequency of 123.016666..., which even when enforcing a minimum of 3 decimal digits might get you either 123.016 or 123.017 if you just strip the strings, and they will fail the equality test.

[hbeni]

But that would always round to 123.017 so match...

[mickybadia]

OK so you are converting from string and back to string, I was not expecting such move. ^^ Then you better hope nobody sends a fixed "123.016" string! :-p Anyway, you have the formula in case you want it, what I wanted was to raise the flag. You now have have my implementation, so you can deal with this in your own way and run concrete tests. You are really close to a fully functional radio system!

[hbeni]

Then you better hope nobody sends a fixed "123.016" string! :-p

Haha i really hope so! Let’s follow up on this in the other ticket 😄

[hbeni]

Did a test again with ATC-Pie commit 9bb529b and it does not match, but it should.

Your commit 7db65517 does work indeed, so i think we misunderstood each other (sorry). I propose you revert that piece back, so we have support for 8.3 frequencies again :)

[edit] The FGFS c172p already supports tuning those from the insim panel, cool :)

[hbeni]

Ah, and to add: The initial problem was the RDF UDP packet. So starting from commit 7db65517 (which support comms) ATC-Pie just need to treat the RDF frequency as "selected" and not actual wave frequency. Then all would be nice.

[hbeni]

eh, maybe we should just merge the current branch and tackle that in a new issue, so there is less to scroll and the location-theme is not mixed with frequency topic.

(comment moved to new ticket: #34 )

[hbeni]

@mickybadia so, i created a new issue ticket for the frequency handling with my noted down conclusion.

Do you feel we can merge the location-stuff of this ticket here now?

[mickybadia]

Do you feel we can merge the location-stuff of this ticket here now?

Sure, I think that issue is solved.