Frequency limitations due to old Standarts

[Sebastian Kramer]

Hello,

 

right now we face yet another stupid limitation due to outdated software. Within the VACC-Germany we have multiple frequencies that are beyond the limit of 134.900 which is caused due to the old standart of FS9 in combination with FSInn. Will there ever be any way to drop those old products?

 

I'm asking this due to the fact that we want to be "as real as it get's" and therefor require the official frequencies used.

[Randy Tyndall 1087023]

I could be very, very wrong...I usually am when I step in to something I don't fully understand...so hopefully someone who knows will chime in here also and set me straight.

 

Isn't the radio frequency limit a function of the simulator aircraft's radio and not the pilot client? Additionally, I use both FSX and FS2004 and both "roll over" when you reach the "134" range. So are you also suggesting we ditch FSX as well and make this a P3Dv4 and XP11 64-bit only network? That is going to cause the loss of a lot of pilots and then all those extra frequency ranges won't seem so important when no one is flying.

 

Are aircraft developers building radios for their addons that allow the use of the extra frequency ranges? If not...who is going to talk to you on them? vPilot seems to be the "client to have". Does it allow you to reach the frequencies above "134"?

 

I don't know the answer to any of these questions, but hopefully someone who does will answer. The only issue I was aware of was pilots trying to set, for example, 133.525 on their radio and couldn't...usually... not realizing 133.52 reached the same "channel"...or so I thought?

 

There was some trouble at one time reaching NDBs in the "thousand" range because the aircraft's ADF didn't have that capability...and some couldn't dial in the decimal frequencies either on the ADF. That's not a function of the simulator, though...can't be, because I now possess addon FS2004 aircraft with updated ADFs that let me dial 1234.5 all day long and, if I have added the NDB to the default database, receive a signal from it. So isn't it the aircraft's limitation and not the platform? Maybe not...I don't know.

 

I will use FSInn and FS2004 until "hell freezes over" or VATSIM kicks me off for trying. Then, I'll just find a VA or a Group that lets me fly with them without a "VATSIM Flight" requirement...and they do exist. VATSIM has been my first and only choice for on line flight simulation since 2008. I'll miss it...truly I will...but I won't look back at what is gone either.

 

Randy

[Trent Hopkinson]

The simulators in use (and in some cases, specific aircraft in them) have varying displays. Many aircraft will only display 2 digits after the decimal point, so when someone is asked to tune 133.525, they will see 133.52 on their radio panel. Others will see 133.525. If someone's asked to tune 133.520, then tuning 133.52 is the same thing.

 

Interesting to note, is FSlabs' A320 shows some more frequency options compared to say, the LDS 767. 8.33khz spacing being available on the former, and not the latter.

 

FSinn will tune whatever frequency the aircraft has tuned in to its radio. 133.525, 133.52(blank) or 133.530 (8.33 spacing)

 

It seems that 133.52(0) is considered to "just be" 133.525

[Bradley Grafelman]

It seems that 133.52(0) is considered to "just be" 133.525

FWIW, that's likely a Simconnect-driven consideration. Whether your aircraft radio's display shows "133.52" or "133.525", SimConnect will only reveal "3352" to FSInn, vPilot, etc. - it's up to the pilot client software to add the [Mod - Happy Thoughts]umed "1" in front and the correct decimal digit at the end (or, as vPilot does, ignore the 3rd decimal digit altogether and tune a controller's frequency if the first two decimal digits match).

 

I'm asking this due to the fact that we want to be "as real as it get's" and therefor require the official frequencies used.

In that case, are all controllers required to obtain real-world controlling licenses/ratings/etc. and are then likewise paid a realistic salary for controlling on the network? If not, then you're already making some concessions... perhaps using different frequencies should be another you consider.

[Johnny Coughlan]

I will use FSInn and FS2004 until "hell freezes over" or VATSIM kicks me off for trying. Then, I'll just find a VA or a Group that lets me fly with them without a "VATSIM Flight" requirement...and they do exist. VATSIM has been my first and only choice for on line flight simulation since 2008. I'll miss it...truly I will...but I won't look back at what is gone either.

 

Randy

 

Not to derail this topic but I'd just like to say Randy that your attitude when it comes to someone questioning legacy software(even if they're wrong) is one of the many reasons VATSIM won't progress past 2020.

 

Your bully tactics and threats are that of a toddler throwing their toys out of their crib.

 

You and your fellow legacy users try and hold this network to hostage against change that upsets your legacy sim/client useage on VATSIM.

 

I've been an member since 2003, have used FS2004, FSX and now P3D, why?, because each one has offered an upgrade of the other, the exact same with pilots clients/ATC clients pro controller, ASRC, VRC, Euroscope, each one improved on the previous.

 

im sick to death of people jumping on threads if there is even a whiff of harming legacy clients by people who only use bully tactic and threats of leaving, you're a minority except it but unfortunately a very vocal on one these forums.

[Christoph Reule 1379750]

IVAO uses real-world frequencies beyond the 136 MHz range and 8.33 kHz spacing, why can't do VATSIM the same?

 

And yes, they still have FS9 users, too, and they use real-world frequencies, either.

 

It's technically possible.

 

Any (valid) reason not to move forward in this matter?

[Pierre Ferran]

 

Not to derail this topic but I'd just like to say Randy that your attitude when it comes to someone questioning legacy software(even if they're wrong) is one of the many reasons VATSIM won't progress past 2020.

 

Your bully tactics and threats are that of a toddler throwing their toys out of their crib.

 

You and your fellow legacy users try and hold this network to hostage against change that upsets your legacy sim/client usage on VATSIM.

 

im sick to death of people jumping on threads if there is even a whiff of harming legacy clients by people who only use bully tactic and threats of leaving, you're a minority except it but unfortunately a very vocal on one these forums.

 

I cannot express how much I agree with this.

 

Regarding frequencies above 135MHz, If I remember correctly, Squawkbox for FS9 was the culprit there. This frequency range was introduced in 1990, similarly, IVAO already uses 8.33Khz frequency spacing, which in the real world has been used by Eurocontrol since 1999, is now mandatory above FL195, and soon to be mandatory below FL195 starting this year in Europe. Manufacturers have not been allowed to sell non 8.33 radios for years now.

 

It's incredible that in 2018, despite many attempts by the community to change the standards, we still run on concepts from the 1990, a time where a lot of VATSIM users were not even born yet!

 

The same goes for the ICAO flight plan, which would not require much change to the network protocol, but just deciding on what information goes where.

 

It all comes down to lack of willingness to change, no matter the expression of good intentions we keep hearing every time a new board is appointed.

[Randy Tyndall 1087023]

Johnny,

 

I apologize if I seemed to be "bullying". I honestly was not. I would have questioned the OP's comment even if it had been referring to vPilot and P3D because I honestly think it is a function of the aircraft addon the party's are using and not the clients or platforms.

 

...when it comes to someone questioning legacy software (even if they're wrong)...

 

But if they are wrong shouldn't we question the direction their finger is pointing? Is the OP wrong in pointing the finger at FSInn and FS2004? I have no idea. I simply suggested it was another cause, not to defend either FS2004 or FSInn but to find the cause if it is not them.

 

...You and your fellow legacy users try and hold this network to hostage against change...

 

I cannot speak for my "fellows" but I certainly am not holding anyone hostage over my use of FSInn and FS2004. I will be the first to admit that change is inevitable. I have never said, "If you do that I will leave", but I have said "If you do that I will have to leave". The first is hostage holding. The second is an admission of the inevitability of change.

 

Your bully tactics and threats are that of a toddler throwing their toys out of their crib.

 

Ah, but you see, I'm not throwing my toys out of the crib nor taking my ball and going home. Someone else is taking my toys out of the crib and I'm being told to either take my ball home or get a new ball. What you confuse with me bullying and threatening is actually me being bullied and threatened.

 

...used FS2004, FSX and now P3D, why?, because each one has offered an upgrade of the other...

 

Oh Johnny, I would love to be able to afford the latest and greatest super techno gee whiz state of the art computer system offering 16 million gigs of processing power, GPU capabilities, and endless storage capacity. Likewise, moving to P3Dv4 would be at the top of my list were I able to reach in to my pocket anytime I needed a specific amount of cash and finding that exact amount in my pocket each and every time my hand reached in. Unfortunately I cannot. I would also like to buy a brand new vehicle every year, but I cannot do that either. A new refrigerator each year. Yep, would do that too. What the heck, why not just raze my house and bulldoze it to the ground every year and build a new one in it's place, only to bulldoze it to the ground next year. I'm getting facetious here and listing extreme examples, but the sad fact is not everyone can afford to get a newer higher performing system, then a newer higher performing platform, then replace all the higher performing addons each time progress is made. Some of us have to keep our 1971 Ford 4X4 because A) It still works, B) it's easier to work on if it breaks, and C) the new ones are $60,000 and change.

 

But, to get back to the topic...and I [Mod - Happy Thoughts]ure you I want to know the culprit as much as the next person...and you.

 

No one has said for fact with data and specifics that FS2004...or any platform...is the reason Sebastian cannot use controller frequencies above 134.90 MHz...other than Sebastian.

 

No one has said for fact with data and specifics that FSInn..or any client except perhaps Pierre's statement about SB for FS9...is the reason Sebastian cannot use controller frequencies above 134.90 MHz...other than Sebastian.

 

Now, I don't know near enough to state with conviction what is the reason Sebastian cannot use the very high frequencies his vACC wants to use to be "as real as it gets".

 

Sebastian says it is FSInn and FS2004...based upon what? We have someone else saying IVAO uses Very High Frequencies and they have FS2004 users. Anyone can come in here and say anything they want and never back it up with a thread of proof. It doesn't help anyone until someone who genuinely knows why Sebastian cannot and what or who the culprit is speaks up.

 

I offered only a "smidgeon" of proof, a suggestion of fact that it may not be the platform or the client, but rather the user's aircraft, by offering the NDB frequency issue. Most of FS2004 aircraft and many of FSX aircraft do not offer an ADF that allows you to dial in a frequency of more than 3 positions or decimal frequencies. This became painfully aware to me when I was testing for my P2 Pilot Rating through VAT-UK. One of the NDBs I was expected to track to had a frequency of 332.5 and my little FS2004 Cessna would only let me dial 332 or 333, but not 332.5 on the dial. I came across this issue again when I discovered a new NDB that had a frequency of 1750. Couldn't dial in 4 digits in my FS2004 aircraft.

 

Obviously the problem is FS2004!

 

But wait...then I bought an FS2004 payware aircraft that had an ADF that allowed me to dial in both decimals and 4 digit frequencies. Then I added the new NDB to my FS2004 NavData. Suddenly, I could dial in and receive NDBs using 332.5 or 1750...in FS2004. So the platform was not the culprit...the aircraft was.

 

I want the answer as much...or even more now...as Sebastian does and know who or what the culprit is because someday I may be under the control of vACC Germany, or any other area, using a Very High Frequency?

 

Randy

[Martin Loxbo]

8.33Khz frequency spacing, which in the real world has been used by Eurocontrol since 1999, is now mandatory above FL195, and soon to be mandatory below FL195 starting this year in Europe. Manufacturers have not been allowed to sell non 8.33 radios for years now.

 

VATSIM really needs to start looking into how to provide 8.33 kHz channel spacing ASAP, OR face the fact that it will not be possible to use realistic frequencies on VATSIM. This year most TWR/APP in Europe are changing over to 8.33 and the change is coming fast. Until now, for most ATC frequencies it has been possible to check the frequencies on a real world chart and use them on VATSIM, but at the end of 2018 that will no longer be the case. All frequencies (with very few exceptions) would have to be "fake" and adapted for VATSIM use.

[Bradley Grafelman]

Until now, for most ATC frequencies it has been possible to check the frequencies on a real world chart and use them on VATSIM

No, it hasn't.

 

If you want to talk to Clearance Delivery on VATSIM, you don't just tune in the real-world frequency of that position wherever you are. You first check to see which ATC is online. Because of the top-down hierarchy, you might need to tune to DEL, GND, TWR, APP/DEP, CTR, or perhaps even FSS. For each of the positions, there may be multiple frequencies in use in the real world but combined into a single position on VATSIM. Once you find the appropriate controller, the frequency [Mod - Happy Thoughts]ociated with that controller is already given to you in the pilot client. As such, real-world frequencies are irrelevant to the virtual pilot.

 

On the controller side, are there areas where so many controllers are online in a given area such that the current frequency bandwidth is exhausted and we've got extra controllers wanting to connect but not having an open frequency to use? Although I don't have definitive evidence to point to, I feel safe in making the [Mod - Happy Thoughts]umption that no, we don't. As such, real-world frequencies are irrelevant to the virtual controller.

 

TL;DR: Real-world frequencies are irrelevant.

[Martin Loxbo]

That's a very tiresome attitude... With this logic I suppose real life callsigns, navaids, routes, SID/STAR, taxiways, parking stands, runways are also irrelevant?

 

Sure, VATSIM can be a place where we fly and control in a virtual space that's totally detached from reality, but that's not really what we do here. We keep most of our procedures, airspace etc up to date with the real world as far as it is practicable. Why should frequencies be any different?

[Bradley Grafelman]

Ah, yes, the numbers in a virtual radio stack not matching real-world charts (once again, somehow ignoring the fact that VATSIM's top-down hierarchy can already render the frequency-finding process unrealistic) is definitely "totally detached from reality." Likewise, I was clearly advocating the "logic" that you can't only work on simulating the things the matter and it must be an all-or-nothing approach.

 

You're definitely not bringing ignorance and straw man arguments into the mix. Definitely. Disregard all I said - carry on!

 

[Martin Loxbo]

I don't see why, just because you think this issue is irrelevant, you have to work against people bringing it up. Sure, we can live with old, unrealistic frequencies, but it would be nicer to be able to simulate the real world frequencies.

 

Of course we are not always able to use the real frequencies, mostly this is true in the area control (top-down) environment. At most airports however, the TWR/GND/DEL and APP frequencies are exactly as they are in the real world. They might not all be open - which is also a common occurrence IRL - but I fail to see how that is an argument against using the real frequencies.

 

It also makes the job of maintaining a FIR more complex if we cannot simply copy the real frequencies but have to come up with different ones for VATSIM use, that do not generate conflicts with frequencies in adjacent airspace. At least if we use the real frequencies, there is a good chance of frequencies not conflicting in the first place.

[Christoph Reule 1379750]

Why not contact the Board of Governors directly about a request to allow real-world frequencies (from 118 to 137 MHz and with 8.33 kHz spacing)?

 

Further discussion here doesn't seem to make sense (reason: see above ).

[Randy Tyndall 1087023]

Okay Everyone,

 

I am trying to come to grips with the issue here. First off, Sebastian stated he wanted to use frequencies above 134.90 MHz to be "as real as it get's" and said the reason he couldn't was because of the legacy platform and clients FS2004 and FSInn.

 

I started up FS2004 and used the default C172 aircraft. Then I tuned my radio and it went to 136.97 MHz and then "rolled over" to 118.00 MHz, so his initial premise is incorrect. Then I started FSInn and opened the VVL tab to see what frequency I was tuned to when my aircraft radio said 136.97 MHz. VVL said I was also tuned to 136.97 MHz, so that premise is wrong as well.

 

So now it comes down to the Eurocontrol program to change frequencies below FL195 (delivery, ground, tower, approach, departure) from 25 kHz spacing to 8.33 kHz spacing. So to come to grips with the issue I looked up the proposed 8.33 kHz frequencies. See the screenshot below for an example of the 118.00 to 118.100 MHz range...

 

 

The frequencies circled in red are the old 25 kHz possible tunings on both an FS2004 C172 aircraft and an FSX C172 aircraft. A total of 5 between 118.00 MHz and 118.10 MHz, inclusive. The frequencies circled in green are the new 8.33 kHz spacing frequencies. A total of 17 between 118.00 MHz and 118.10 MHz, inclusive. The ones circled in blue can be tuned either with the radio tuner (for 25 kHz frequencies) or by typing ".c1 XXX.XXX" in the FSInn client chat box. A total of 11 frequencies between 118.00 MHz and 118.10 MHz. The ones that cannot be tuned end in a 5, such as 118.035 MHz. Typing ".c1 118.035" results in 118.030 MHz being tuned. A total of 6 frequencies between 118.00 MHz and 118.10 MHz, inclusive.

 

Yet I wonder, as with the existing tuners and 25 kHz frequencies, tuning 118.02 on your tuner actually reaches 118.025 MHz. Will typing ".c1 118.030" actually reach 118.035 MHz. If it does, then the issue becomes one of tower on 118.030 MHz and approach being on 118.035 MHz, doesn't it?

 

Surely those "new" 6 frequencies will help get Europe and VACC-Germany closer to "as real as it get's" and nothing needs to be changed or s[Mod - lovely stuff]ped. And that is just in the 118.00 MHz range. Considering all from 118.00 MHz to 136.00 MHz that's 108 new frequencies...if the command tuning of 8.33 kHz spaced frequencies work.

 

And, I go back to my original suggestion that it is neither the platform nor the client that is "limiting" the use of the new 8.33 kHz spacing...it is the aircraft used by those platforms. Although I do not own either P3Dv4 or xPlane 11 I would be willing to wager that none of their aircraft radios will allow you to tune 118.035 MHz either. If that is the case, do we just quit using VATSIM because controllers want to use 8.33 kHz spacing? No, we use what we can and accept it until developers create aircraft that have the XXX.XXX capability in their aircraft radios.

 

Randy

[Simon Kelsey]

Just to expand on Randy's excellent explanation...

 

The limiting factor for 8.33 is, really, neither the sim platform, nor the client, nor the aircraft actually -- it is Simconnect, which AFAIK only p[Mod - Happy Thoughts]es two digits after the decimal point.

 

This is why tuning 119.725 at the moment results in the client seeing 119.720 -- because only "119.72" is visible via Simconnect.

 

In the same vein - the FSLabs A320 is equipped with 8.33 radios. However, you are still limited to the frequencies outlined by Randy, because only the first two digits are visible to the pilot client and therefore it is unable to distinguish 118.000 from 118.005 (for example). Again, not a client issue -- a Simconnect limitation -- the data just isn't there.

 

So unless some clever person could come up with a way of reading all three digits -- or radio tuning is somehow taken out of Simconnect (not necessarily impossible, I imagine -- my imagination suggests that radio tuning of sorts could be incorporated in to the client in a more visible way that ".c1 xxx.xx" is at the moment, thus providing everybody with an 8.33 radio by default which could then be driven outwith Simconnect by third-party gauge developers -- almost certainly a lot more complex than it sounds on paper though) true 8.33 support is going to be very difficult (I don't know what the deal is with XPlane).

[Randy Tyndall 1087023]

Thank you for the kudo Simon. That means a lot coming from you. Reading is definitely fundamental and I did a lot of reading and jumping from Sim to Sim and client to client to see how things worked, rather than just throw some words down.

 

I would love to test my command 8.33 kHz spacing theory online, just need to find someone controlling using a frequency in the 8.33 kHz range at a time when I have time to log in. With Europe being the driving force behind the switch (the FAA does have a "paper" explaining their 8.33 kHz spacing intentions) and me living clear out in Idaho in the USA it kind be hard to find a time that meets the need.

 

First I would try voice...or even text...on one of the XXX.030 or .040 or .060 MHz frequencies that aren't tunable by conventional FS2004 and FSX radios. Then, if the controller can switch his or her "prime" to something like XXX.035 MHz I'd like to see if tuning XXX.030 MHz will let you communicate the way tuning XXX.02 MHz will let you communicate with a controller who is using XXX.025 MHz.

 

We are all throwing words back and forth, but I haven't seen where anyone is trying to sort out what works and what doesn't. You are the first who has put forth a definitive reason behind why the 8.33 kHz spacing is such a problem...Simconnect. And yet I wonder, FS2004 doesn't use Simconnect, so what and why is the issue there...aircraft?

 

Randy

[Christoph Reule 1379750]

About Simconnect... may I quote Ross Carlson who made this statement over a year ago...

 

SimConnect conveys your radio frequency using BCD16, ignoring the hundreds and the thousandths position. In other words, for the imaginary frequency 123.456, the value retrieved via SimConnect will be the hexadecimal value 0x2345 (123.456).

 

So, no, it's not possible to use SimConnect to achieve 8.33 kHz spacing, because frequencies 123.010 and 123.015 would both be represented by the value 0x2301 with no way to distinguish between the two.

 

You can also request the frequency as a 32 bit integer, in which case you get all six digits.

[Ross Carlson]

While it's true that you get all six digits when you READ the frequency from SimConnect, as far as I can tell, there is no way to SET the frequency with more than two digits, because setting the value can only be done using BCD16 format.

 

Maybe there's a way to set the frequency with all 6 digits, perhaps byp[Mod - Happy Thoughts]ing SimConnect completely, but I haven't come across it.

[Christoph Reule 1379750]

While it's true that you get all six digits when you READ the frequency from SimConnect, as far as I can tell, there is no way to SET the frequency with more than two digits, because setting the value can only be done using BCD16 format.

 

Maybe there's a way to set the frequency with all 6 digits, perhaps byp[Mod - Happy Thoughts]ing SimConnect completely, but I haven't come across it.

 

Is there a way to allow to enter the frequency with all six digits (e. g. ".com1 118.155"), use this value internally to tune in the channel and send the frequency in BCD16 format to the sim (e. g. "118.15") ? Just a thought, you know best what is possible or not.

[Simon Kelsey]

First I would try voice...or even text...on one of the XXX.030 or .040 or .060 MHz frequencies that aren't tunable by conventional FS2004 and FSX radios. Then, if the controller can switch his or her "prime" to something like XXX.035 MHz I'd like to see if tuning XXX.030 MHz will let you communicate the way tuning XXX.02 MHz will let you communicate with a controller who is using XXX.025 MHz.

 

Things might have changed, but from the last time I tried it (which was MANY years ago) I don't think any .xx5 frequencies will 'work'.

 

The network certainly recognises all three digits. This is why controllers, though they may say "119.725" verbally, will actually have 119.720 set as their frequency -- because if they set 119.725, the client will see this as a separate frequency to 119.720 (which is what the client will be tuned to). Certainly in the Squawkbox/Pro Controller/VRC days the result was no communication -- as I say, that may have changed.

 

And yet I wonder, FS2004 doesn't use Simconnect, so what and why is the issue there...aircraft?

 

FSUIPC I believe p[Mod - Happy Thoughts]es radio frequency data in the same format via offsets 043E/3188:

 

COM1 frequency, 4 digits in BCD format. A frequency of 123.45 is represented by 0×2345. The leading 1 is [Mod - Happy Thoughts]umed.

 

Where 'legacy' clients may well be a barrier is that if, for example, Ross were to come up with some way via vPilot of supporting 8.33 spacing, there would be an issue with the unsupported clients. This is (IMO) a reason why there is an issue with continuing to support at a network level all manner of clients (sim platform per se is not in itself the issue), most of which are long dead and buried in terms of developer support -- it means any changes/improvements from current developers are limited to what will play nicely with the old clients. That is actually quite restrictive if you think about it. Compare with IVAO who, AFAIK, have one official client and therefore any improvements are instantly global and there's no discussion about "how can we bodge this so that it also works for..."

 

The issue with the VATSIM model is that whilst it allows any interested developer to go out and create some software (good) it also places strict limitations on what can be done in the interest of supporting, seemingly indefinitely, outdated clients no longer supported by their developers (not necessarily so good). We're quite a long way down the road now and so any changes would cause quite a bit of upheaval; however, a more meritocratic approach would be to allow a loss of functionality for old clients as things are updated, which would arguably a) allow for more creativity and progress and b) if there is demand for full-functioning clients with FSUIPC support then you never know, it might inspire someone to create/support one!

 

While it's true that you get all six digits when you READ the frequency from SimConnect, as far as I can tell, there is no way to SET the frequency with more than two digits, because setting the value can only be done using BCD16 format.

 

Maybe there's a way to set the frequency with all 6 digits, perhaps byp[Mod - Happy Thoughts]ing SimConnect completely, but I haven't come across it.

 

My wild imagination was to effectively byp[Mod - Happy Thoughts] the FS COM radio infrastructure altogether and have a separate VATSIM COM radio as part of the client. Then provide a means for 3rd party gauge developers to interface their COM radios to drive that, rather than the other way around as is the present situation.

 

There's probably about a million holes in that idea though