Jump to content
Join the POSCON Public Discord Server! ×

Andrew Heath

Network Directors
  • Posts

    1492
  • Joined

  • Last visited

  • Days Won

    145

Blog Entries posted by Andrew Heath

  1. Andrew Heath
    Back in September of 2019, I was browsing through X-Plane community downloads in order to find additional models to enhance the POSCON X-Plane Pilot Client model distribution. During the course of my search, I came across the X-CSL model package and reached out to the X-CSL team via their Contact form to obtain authorization to use their package in our software. The X-CSL team granted POSCON permission back then, but as of January 2022, they have unilaterally revoked that permission.
    The main reason for this blog post is to inform POSCON users that the X-CSL package is in the process of being removed from our distribution and should be fully removed by the end of the week. Once this package is removed, the next time you reinstall your X-Plane Pilot Client via the Launcher Client, the models will be automatically deleted from your computer.
    An equally important reason for this blog post is to shed light on what transpired to get us to this point, a point where we are taking a drastic step backwards regarding user experience. The reason for this decision is because the founder of the X-CSL model package, a man named Aleksandr (Almik) Mikitas, revoked permission to use these models after our "Out of Beta" announcement was made public. He wrote to me shortly after the announcement and claimed that permission was never granted to use these models, even though a senior developer from his team clearly granted us permission over two years ago (see the email exchanges). As mentioned earlier, I originally wrote X-CSL via their Contact form in September of 2019 to ask for permission and Aleksandr responded and handed me off to his senior developer who subsequently granted permission to use the models with the stipulation that we give credit to X-CSL, which we did: https://forums.poscon.net/docs/support/manuals/acknowledgements/
    Despite my best efforts to convince Aleksandr that the lack of communication was isolated internally within his team and not at all POSCON's fault, he has decided to take punitive action against POSCON members by requiring us to remove the models. This action only serves to hurt you, the user, by making it more difficult to use the X-CSL package (i.e. you now have to go download it from their website and use scripts to get it to work with POSCON, which is hardly worth the time). While I have many theories about the timing and reasons behind this new requirement, I want to stick to the facts here as much as possible.
    Speaking of facts, here is an important one: Aleksandr Mikitas now works as the MTL Designer and Membership Assistant Coordinator - Eastern Europe and Northern Asia for the International Virtual Aviation Organisation (IVAO). To my knowledge, Almik did not hold this position with IVAO at the time I approached X-CSL in September of 2019.
    I have put together an evidence package in case POSCON users want to dig deep into what was said and by who. Publicly releasing my personal correspondence is not something I take lightly, but I find it entirely relevant to the current situation. An important note about the email exchanges is that all respective parties were always CCed on every email so anything said was guaranteed to be seen by both Almik and myself.
    Based on the email exchanges with X-CSL, my lawyer concluded that X-CSL and Almik implicitly allowed POSCON to distribute these models. Why else would Almik have referred me to his developer in order to give us technical information which would enable POSCON to include these models in our software? Our intentions were clearly outlined from the very first email sent to X-CSL. Almik and his developer never said, “yes include the package in your installer” directly, but they also never said “no.” Even though Almik was CCed on all the emails from the beginning, I recently reminded him that he was the one who referred us to his developer and as a result, his developer told us how to include the model package in our software. The POSCON developer programmed software based on this representation. The X-CSL developer's role in this was perpetuated by Almik — Almik referred POSCON to his developer, so it implies that Almik knew what this was about, and approved of it.
    What's also interesting to note is that Almik says he created this package for the benefit of all X-Plane users, "Each our model is a our free time, effort and even money to give the best results for all XP users as free," but by revoking POSCON's authorization he actually has made it harder for X-Plane users to use the X-CSL package on their preferred network of choice, unless of course that network is IVAO.
    At the end of the day, POSCON will comply with X-CSL's demands, but I think it is important to shed light on what sometimes happens behind the scenes in this "community" and why we can't have nice things.
    Reflecting back, this whole situation seems eerily familiar to the recent debacle between AIG and FLAi (click here for additional reading material). Bottom line, this type of behavior in our community needs to be called out and more importantly, it needs to stop.
    What Happens to the POSCON X-Plane Model Package?
    To be honest, this doesn't really affect our model package too badly. There was approximately 70% overlap between BlueBell and X-CSL, so there will be a few unique models that will disappear in addition to some liveries. If you are interested in helping the POSCON model project recover from this loss, please reach out to Jeffory Beckers, our Model Asset Manager.
  2. Andrew Heath
    CAPTAINS,
    (if you have been in the flight simulation community long enough, you will understand the "Captains" reference)
    The last technology blog post was published in May of 2020, and what a long journey it has been for our team since then! Thankfully that long arduous development journey has come to an end and users will be able to benefit from our hard work.
    I want to start off by answering some common questions and clearing misconceptions.
    Is POSCON dead?
    Absolutely not! We are very much alive and well!
    We may not seem like a major player in the online flight simulation network arena right now, but rest assured that our technology is far superior to that of our peers and we will be a significant force to reckon with in the near future.
    So, where have you been?
    The short answer is, we have been here all along. . . quietly developing.
    As a result of feedback from early beta testers, we took the drastic step of essentially shutting down POSCON's forward progress in order to rewrite the voice software. This decision was made when we realized that the voice software was not going to be able to sustain our projected growth using the protocol it was developed to use. Making a change to the protocol basically required a complete rewrite, which I am pleased to report is now complete.
    The good news is that the rewrite only occupied one developer for past last year. While he worked tirelessly to bring users a better voice experience, our other developers have been making significant feature upgrades to their components. I am going to take some time to highlight those major developments later in this post.
    Why haven't you posted development updates over the past year?
    To answer this question, we need to address two major issues in the flight simulation community: the hype train mentality and the copying problem.
    The hype train mentality. A very common tendency in the flight simulation community is to over-hype a product. Some developers do this on purpose by dropping little nuggets of information or photos on social media regarding a new and exciting product they are working on in order to build hype, then one of two things happens; either the product never gets released (it was vaporware all along) or the product is released, but does not live up to the hype. This community loves to ride the hype train and it is not something that the POSCON team thinks is a professional approach to software development and marketing. We don't want to build up hype around a product that doesn't live up to expectations. We feel it is better to stay quiet and develop rather than to make promises we cannot keep. The copying problem. No, I am not referring to the people who like to pirate software (and yes, that is a problem too). What I am referring to the issue of other developers/networks (you know who you are) taking our great ideas and benefiting from them. This is something Robert Randazzo of PMDG actually brought up in his recent interview with Jeff Turner over at Sky Blue Radio in regards to Global Flight Operations. I couldn't agree more. Competition is a great thing, but competition means being innovative and developing new ideas. Anyway, enough of my rant. . . but those are the main reasons we are careful not to provide too many details about what we are working on now.
    Okay, so what are you willing to share?
    First, I think it is important to point out that all recent updates to our software can be found in the changelogs which are located on the POSCON HQ. I certainly have no intention of covering everything that has changed over the past last year, so I encourage all users to browse through the logs if you are interested in learning more.
    Having said that, there are some main points I want to cover in this blog post.
    Let's first talk about the voice software, since this is what has been the major barrier to our forward progress. The voice software is now using a new protocol which will prevent a lot of the issues that users were experiencing with the previous iteration such as issues with wireless headsets, sample rates, garbling, etc. In addition to changing the protocol, we moved all the voice settings (push-to-talk, audio device selection, volume control, etc.) from the Radar Client and Pilot Clients into the Launcher Client in order to centralize these settings. This means that users will now only need to modify the voice settings once for all POSCON clients. This integration of the voice software into the Launcher Client enables us to expand the capabilities of the voice software in the future to perhaps support web-based pilot and ATC clients. You can find all the new voice settings by clicking cog wheel in the bottom right-hand corner of the Launcher Client:

    Here are the new settings that you will see after clicking on the cog wheel:

    Under the "Volume Controls" setting, we now allow users to control squelch which adds an extra layer of realism to the VHF simulation. You can adjust the squelch by moving the slider left (lower) and right (higher).

    The Launcher Client also incorporates a new voice status icon located in the upper right-hand corner of application which gives users an indication of the microphone and the radio configuration. Here are the different states:
    "No Radio" - Red Mic Icon
    You are not connected to POSCON (or the voice server) or your airplane radios are not powered (perhaps your avionics are turned off).
     
    "Radio Ready" - White Mic Icon
    Your radios are configured correctly, but you are not currently transmitting.

    "Transmitting" - Green Mic Icon
    You are transmitting and listening on a frequency.

    "No Reception" - Yellow Mic Icon
    Your radios are set up to transmit, but not to listen.

     (push-to-talk button/key pressed)
    "No Transmission" - Yellow Mic Icon
    Your radios are set up to listen, but not to transmit. This can happen when you are in Ghost mode or if you don't have your radios configured to transmit on a frequency.

     (push-to-talk button/key pressed)
    In all cases, remember you can use the Pilot Client Web UI ("RADIOS" page) to get better insight into what is happening with the configuration of your radios.
    Other changes to the voice software include:
    Upgrades to the radio-frequency physical model which helps to better simulate real-world radio interference Antenna position now varies by aircraft type and thus improves ground effects near the airport surface Server-side memory optimization and multi-threading New stuck-mic protection (35 second timer, then mic cuts out) The Launcher Client itself has been re-versioned to 1.0.0 and is officially out of beta testing. We upgraded it to the latest dot NET framework and changed the cloud location where it downloads client software from. The long term goal (version 2.0.0) for the Launcher Client is something we are referring to as the "Unified Launcher Client". The Unified Launcher Client will integrate the SimConnect (FSX/P3D/MSFS) Pilot Client, voice software, and authentication all into the same code-base so that multiple applications need not be opened simultaneously to run POSCON.
    One important user-experience note about the new Launcher Client (version 1.0.0) is that when you click the "X" in the top right-hand corner, it will now minimize the Launcher Client to the system tray. In order to completely quit the Launcher Client, you must right-click on the icon in the system tray to quit.

    The HQ has undergone a significant number of upgrades and improvements over the past year. . . far too many to mention here so I encourage you to go view the HQ specific changelog. Our most recent changes (i.e. in the past month or so) include the addition of a brand new Virtual Operators section. Virtual Operators are essentially organizations that are commonly referred to as "virtual airlines" in the community. These organizations can join POSCON and benefit from an integrated connection that will ensure members only fly with approved aircraft, callsigns, routes, and more!
    Also, the HQ development team has been slowly improving the ATC Division pages including a re-design of the Overview and Members pages to offer a better user experience to view information and activity in the division. Speaking of re-design, your User Profile has also been re-designed to offer a better user experience that compliments all your activity!
    The Radar Client has had many updates and improvements as well, please see the Radar Client specific Changelog for more details.
    The Pilot Clients and Radar Client have been stripped of all voice-related items. The software should still work normally, but the voice now is handled by the Launcher Client.
    Wow, that's amazing stuff, but how do you plan on attracting more users?
    Sorry, but this is a Technology blog! Can't answer that!
    In all seriousness, we will be sending out marketing materials soon. We plan on making 2022 a big year for POSCON and we want to thank those who have kept the faith throughout the years. Without you and your encouragement, this wouldn't have been worth it! 
    Happy Holidays to all!

  3. Andrew Heath
    Have you ever approached an airport too high or too fast and as a result you had to dive bomb the runway in order to land? Have you ever landed halfway down the runway in an attempt to squeak out that perfect landing rate? If the answer is yes to either of these questions, then you are the victim of an unstablized approach and in the POSCON world, you lose points for that type of flying. One of the biggest operational challenges for a virtual pilot is how to successfully accomplish a stabilized approach in the simulator. In fact, flying stabilized approaches in the flight simulator is difficult for even the most experienced real world pilots because of the inherent limitations of flight simulators such the limited FOV (field of view) compared to the real world. In this post, I am going to attempt to tackle the reasons why stabilized approaches are such a challenge and offer some techniques on how to ensure your approaches remain stabilized.
    For our example scenarios, we are going to John Wayne - Orange County Airport located in Santa Ana, California (KSNA). This airport has two parallel runways:
    Runway 20R/2L - this is the larger of the two runways at 5,701 x 150 feet with all of it available for landing.
    Runway 20L/2R - this is the smaller of the two runways at 2,887 x 75 feet with all of it available for landing.
    Runways 20L and 20R from X-Plane 11: 

     
    This is an old real world photo when the runways were previously named 19L and 19R.


    Not sure if you noticed, but there are two very important differences between the two photos other than the runway naming.
    The first difference is that in the X-Plane photo, the runway touchdown zone markings extend the entire length of the runway which gives the flight simulator pilot a false sense of where the touchdown zone is located. In the real world photo, there are only three touchdown zone markings (not including the threshold markings). Each touchdown zone marking indicates 500 feet. You might ask, why are there only three in the real world? For that, lets define the term "touchdown zone".
    Touchdown zone = the first 3,000 feet of a runway or first third, whichever is less.
    In the case of KSNA, that means the touchdown zone is defined as the first 1,900 feet (5,701 divided by 3). 
    So at KSNA, the runway painters only painted 3 markings to indicate the touchdown zone (3 x 500 = 1,500). Anything more than that would give the pilot incorrect information.
    The second major difference between the two photos is the fact that the X-Plane runway is simply too long. You can tell this because of the location of the third touchdown zone marking in relation to the taxiway. In the real world photo, the taxiway is located in the same position as the third marking, but in the X-Plane photo, the taxiway is located in the same position as the fourth marking.
    These types of scenery inaccuracies present a significant challenge to flight simulator pilots because landing in the touchdown zone is a requirement of every landing and the expected outcome of flying a stabilized approach. If you estimate that you will NOT land in the touchdown zone, a go-around MUST be initiated. POSCON will automatically deduct points from your score if you fail to land within the touchdown zone because it is indicative of an unsafe landing.
    We now know what the touchdown zone is and why it is important, but to achieve a safe landing in the touchdown zone, it first starts with a stabilized approach. Significant speed and configuration changes during an approach can complicate aircraft control, increase the difficulty of evaluating an approach as it progresses, and complicate the decision at the decision point (i.e., DA, DDA, DH, MDA). Assess the probable success of an approach before reaching the decision point by determining the requirements for a stabilized approach have been met and maintained. Normal bracketing is defined as small corrections in airspeed, rates of descent, and variations from lateral and vertical path. Normal bracketing is a part of any instrument or visual approach procedure. Frequent or sustained variations are not normal bracketing excursions and are not acceptable. POSCON will automatically deduct points from your score if you fail to conduct a stabilized approach; however, you will only be charged points if the approach results in a landing. If you realize you are unstable and go-around without touching down, no points will be deducted. Let's review the criteria the POSCON grades on:
    Stabilized Approach Requirements
    On any approach, the following is required:
    Below 2,000 feet above field level, do not descend at a rate greater than 2,000 FPM for more than a few seconds. Below 1,000 feet above field level, or inside the FAF, do not descend at a rate greater than 1,000 FPM for more than a few seconds. EXCEPTION: At special airports such as Lukla (VNLK), Telluride (KTEX), Aspen (KASE), Paro Bhutan (VQPR), etc. OR if you are simulating an emergency, you can "dispute" the point deduction in order to be exempt from the above criteria. We also are considering exempting certain aircraft types as well such as general aviation.
    At 1,000 feet above field level:
    You must be in a landing configuration (gear down and final landing flaps), no exceptions. On the proper flight path. At stabilized thrust (spooled). Minimum speed: target speed minus 5 knots. Maximum speed: target speed plus 10 knots. EXCEPTION: In VMC, the requirements at 1,000 feet can be delayed until 500 feet above field elevation, except landing configuration.
    These requirements must be maintained throughout the rest of the approach for it to be considered a stabilized approach. If the stabilized approach requirements cannot be satisfied by the minimum stabilized approach heights or maintained throughout the rest of the approach, then you must execute a go-around. The decision to go around is not an indication of poor performance, but rather good judgement.
    Main Causes of Unstabilized Approaches
    Visual approaches. Poor descent and speed planning from cruise. Unreasonable ATC speed or altitude restrictions. Techniques to Flying a Stabilized Approach
    Here are some tips on how to achieve a stabilized approach:
    Stabilized approaches start with good descent and speed planning. The total flying distance required for a normal descent to landing can be calculated by factoring 3 miles per 1,000 feet or 1 mile per 300 feet (3 to 1 ratio). Sometimes, however, a 3 to 1 ratio cannot be maintained due to high tailwinds, engine anti-ice activation, or ATC assigned speed restrictions. If you are flying jet aircraft, make sure you are not afraid to use speed brakes when necessary as they are a very effective tool to "go down and slow down" simultaneously. If you are in variable pitch prop aircraft, you can push the prop lever full forward which will use the blade of the prop to help slow the aircraft. The best way to slow an aircraft in the descent is to level. It is not always possible, but when it is, it is good practice to build in a few extra miles prior to a speed restriction to level just to make sure you can achieve the desired speed. If the act of leveling gets you off your desired descent path (i.e. too high), you can always add flaps to maintain a high descent rate while maintaining a slow speed. Speed brakes can also help, but avoid using speed brakes below 180 KIAS. Extending your gear is your trump card... play it when necessary. The gear is the biggest drag device you have on your aircraft. If the choice is between going around and dumping the gear early, the gear is always the best option. 1,000 feet is just a minimum. You should target 1,500 feet to ensure you are stable by 1,000 feet. In general, plan to be stabilized on all approaches by 1,000 feet above field level in both IMC and VMC. Use electronic guidance when available. This does NOT mean you need to request to fly the instrument approach, you can simply tune and backup your visual approach using an ILS or RNAV for the vertical guidance that these approaches provide. A good technique on visual approaches is to intercept the vertical path, even if not established on the lateral guidance. If ATC assigns you an altitude or speed restriction you are unable to maintain, then simply say "unable". Know how to properly manipulate the the mode control panel (MCP) or guidance panel (GP) on your aircraft. Knowing what the different modes do will help you make good decisions during the descent phase. Also, it is important to understand how each mode interacts with your auto-throttle system. The last thing you want is the auto-throttles to increase power when you are not ready for them to do so. Here is an example of what to do when you recognize early that a 3 to 1 ratio descent path is not going to work: 

    Okay, now lets say you have tried ALL of the above and you are out of options, what now? Do you have to go-around?
    There is one more option... increase the flying distance to the runway. You can do this a number of different ways, but it depends on how far away you are from the runway. 
    Early recognition of being unstable: If you realize early that you are going too high and/or fast on approach, you can ask ATC for "vectors for descent". 99% of the time ATC will be happy to accommodate this request because they rather give you a chance to make a stabilized approach than have to deal with your go-around. 
    Late recognition of being unstable: If you realize that you are going to be high and/or fast and you are on final approach, then things become a little bit more complicated. With the exception of the C172-type aircraft and their ability to forward slip, the only option is an S-turn... yeah, that thing from the private pilot training. If you are flying into a controlled airfield, you need to request to conduct this maneuver from ATC. If you are flying into an uncontrolled field, you can simply perform this maneuver on your own.
    CAUTION: Some people may suggest a 360 degree turn for stabilization on final as it is common practice at uncontrolled fields. I personally do not recommend this maneuver as it can lead to bad things if aircraft are behind you. If you feel that the S-turn technique will not work, it is better to just level at pattern altitude, fly upwind and then re-enter the traffic pattern.
    The S-Turn Technique
    The shortest distance between two points is a straight line, thus if you want to increase the distance to a runway (i.e. the time to descend and slow), you need to add a bend in your flight path. In order to do this, first make sure you are above 1,000 feet above field level and in VMC. If not, you need to go around and try the approach again. If you are, I recommend the following technique:
    Turn 30-45 degrees off course. Maintain throttles to idle. If you are too high: pitch for maximum vertical descent rate based on height above field level (e.g. do not exceed 2,000 FPM below 2,000 feet AFL or 1,000 FPM below 1,000 AFL). If you are too fast: pitch for desired airspeed. Evaluate your glide path using visual or electronic means. When you feel comfortable with the stability of your approach, turn back towards the airfield and intercept the straight-in final. CAUTION: Do not let the maneuver deviate more than 1 mile from the straight-in lateral track, otherwise you might as well go around and re-enter the pattern.
  4. Andrew Heath
    Earlier this year, we created an MVP (or Minimum Viable Product) list of features that need to be completed before our first public release. Since defining these specific objectives, our development team has been laser focused and, as a result, we have made tremendous strides in POSCON's technological development. In June 2019, we attended FSExpo where I was interviewed by Callum Martin from FSElite and we revealed our roadmap to release announcement. This announcement had a significant impact on our development team because it assigned a series of deadlines as to when the MVP objectives need to be completed by.
    Here are some additional interviews I took part in during FSxpo:
    Flight Simulation Addon Developers Panel Ground_Point_Niner Interview Lets first talk about the voice client, since voice quality seems to be the hottest topic in network development spheres. The truth is, we have only pushed one or two revisions to our voice code since my last update in April 2019. The reason for the lack of updates is not because we have given up working on it, but because we are done. The POSCON voice system was one of the very first projects we worked on and because of that, it has been stable and ready to be released for the past 6 months. We have an update to the voice infrastructure planned before public release, but the update is not a no-go item and can be delayed if it were to prevent our release. The current features of our voice communication system include:
    Low latency. Realistic VHF distortion. Line-of-sight simulation including both curvature of the earth and terrain modelling. Blocking simulation. The ability to add custom transmitter locations for ATC through our website. Full integration into all of our clients. Second, lets talk about the server... and the first word that comes to my mind is "wow". The server update rate (15 Hz) is absolutely phenomenal and extremely smooth. I find myself bugging our testers to join me in VFR group flights constantly because the update rate makes these types of flights extremely enjoyable. If you haven't seen some of our demos, you can can view them on our YouTube channel. Other than the update rate though, the server has had a lot of work performed on it. Here is brief summary of recent changes:
    The server can now determine what FIR and sector an airplane is in by analyzing known lateral and vertical airspace stratum. Below are two images showing our custom Discord bot reporting: The active aircraft on the server, shown with their Mode-S hexadecimal readouts (first column), The FIRs the aircraft are currently in (AOR column); and, What FIRs the aircraft are in the vicinity of (APD column).
    We have also extended this capability to sector level granularity. The image below shows what sector the aircraft is currently in and also what sector the aircraft is projected to be in the next 180 seconds based on the current aircraft trajectory. Why on earth is this important? Well this core functionality can be used for many different applications such as ATC scheduling, traffic management, auto-handoffs, auto squawk code assignments, and auto "contact me" messages... just to name a few.

    Speaking about auto-squawk code assignments, the server can already do this! When you file an IFR flight plan on POSCON, regardless of whether ATC is online or offline, the server automatically sends you a squawk code assignment. This is important so that your flight plan and target are properly correlated because on POSCON, your callsign is not tied to your actual connection. Another recent update to our server is that ghost mode has been re-enabled. Earlier this year we disabled our ghost mode code while we worked on other aspects of the server because the feature was interfering with our testing. I am pleased to announce that we have finished those peripheral updates and have re-enabled ghost mode. Ghost mode allows members to remain connected and enjoy the server, while not being a bother to other users. While on the topic of ghost mode, we recently added runway definitions and buffer zones to the server so that when an aircraft spawns to a runway, instead of interfering with traffic, they are automatically ghosted. This server functionality can also later be used for Runway Safety Area (RSA) alerts in the Radar Client.
    In addition to automatically ghosting for spawning on a runway, the server will also automatically ghost aircraft that slew or that connect in the vicinity of another aircraft (e.g. at the same gate as someone already connected). In regards to server infrastructure, we are utilizing the Google Cloud Platform. Some features of our server infrastructure include:
    Automatic server selection and negotiation. Memory-only flight servers (no need to read from disk). Multi-gigabit network uplinks per server. RAM-based databases for our core services. Next, lets discuss the pilot clients. Like the voice system, most of the work on these clients has been finished for a few months. Right now, our main focus is sorting through bugs and working on the Pilot Client Web UI, which I will discuss later in this post.
    The X-Plane Pilot Client was recently updated with better model matching logic. The new logic closely emulates the logic that most people are already familiar with on other networks. In addition to this new logic, we also added a new ground clamping algorithm. As a pilot approaches or departs from the ground, the client will now evaluate the terrain underneath the aircraft and intelligently chose from one of two methods to display an aircraft in your sim. This will prevent models from making unrealistic movements during the takeoff or landing phase of flight. I have personally tested this extensively and I can tell you, it works very well when you are flying with people using different sims and/or terrain meshes. As with all things pilot client related, we will ensure feature parity, so the FSX/P3D client will soon have the same features that have been added to the X-Plane client.
    Since FSExpo, the website (we call "HQ" or Headquarters) continues to be updated to the new design. We currently have a fully functional ICAO 2012 flight plan form with an integrated tutorial for users who are not completely familiar with how to fill out the form. Some additional features of the HQ include:
    The ability to view your profile, statistics, and change account preferences. View training documentation and modules. Submit support requests. View upcoming events and bookings. Browse available Discord servers. Schedule ATC sessions. Submit airline and aircraft ICAO codes to be approved for inclusion in the global database. If you were at FSExpo, you will be familiar with our Live Map which consists of a globe, continents, and FIR boundaries. Currently it displays airspace and aircraft with the ability to view activity in a 3D perspective. We have included a live weather radar on this map as well that covers most major areas around the world.



    By clicking on an aircraft on the map, a sidebar appears which displays some basic flight data and a series of options to choose from including:
    "Leave Feedback" "Report Issue" - in other networks, this is the same as the "Wallop" command. "Message" - this is restricted to Moderators only.
    Because our map is derived from OpenStreetMap, users are able to update their home airport and make it as detailed as they want. Here is EHAM:

    The Pilot Client Web UI, which is part of HQ, is coming along nicely. The Web UI is already capable of:
    Changing VHF radio frequencies in your sim. Changing squawk code, transponder mode, and identing. Changing the active radio transmitter and receiver in your sim. Requesting and displaying weather reports (METARs, TAFs, etc.). Changing your connection mode (ghost or live). Disconnecting from the network. Sending PIREPs to the server. Communicating with Moderators. We are currently working on implementing CPDLC via the Web UI. This will be the only way users are able to use text to communicate with ATC.
    Last but not least, lets discuss the Radar Client. Development on this software is coming along nicely as well. One of the unique things about our Radar Client is the way you log in and choose what position you are going to control.
    The first step is to pick the authority in which you desire to work in. In this case "FAA", which is the USA. Then pick the enroute facility. In this case "ZNY", which is New York ARTCC. Then pick the sub-facility. In this case "N90", which is New York TRACON (Apporach/Departure). Then pick the sub-facility area. In this case "JFK", which is of course Kennedy International Airport. Then pick the sector or position. In this case "2G", which is a sector of the Kennedy Area. Pick the configuration. In this case I picked "Default".
    After clicking "Login", the server automatically downloads all the proper sector and voice communication data. Why is this important? It makes the setup process extremely seamless. With our software, all a user needs to worry about is basic preference settings. Right now, the login menu exists in the Radar Client itself, but eventually we will move it, along with a lot of other things, to the Launcher Client software which will automatically download and keep POSCON files up-to-date.


    Another feature of the Radar Client worth discussing is our VSCS (Voice Switching and Control System). The VSCS panel data is automatically populated from the server based on the position you select at login. No extra configuration is required other than selecting which transmitters you want to activate. In the example below, we have set up a single frequency with multiple transmitter locations. I have activated the transmitter located at Matawan (MAT), New Jersey and I am transmitting on 125.325. I am also monitoring Guard on both VHF and UHF frequencies.

    The Radar Client also gives the user the ability to change the rate at which targets update. This is important because different air traffic control positions use different types of radars that update at different rates. We wanted to give the user the ability to control this variable.

    Here is an image from our WX and ALTIM SET panels. These can be setup using the "WR" and "QD" commands respectively.

    Well, that about sums up our technical development progress. I am sure I left out some points but there is just so much to cover! I want to stress the point that we have accomplished the majority of this work in just over a year. Imagine where we will be at next year.
    I also want to take this opportunity and remind everyone to follow us on our Twitch channel! You can expect that to become active in the VERY near future! 
     
  5. Andrew Heath
    On April 1st, 2020 we officially began approving invites to the POSCON Invite-Only Beta. We are now almost two months into our release and it still brings me great excitement every time I see a new user experience POSCON features for the first time. We learned a great deal in the first few days and weeks after the initial release. One thing that became abundantly clear was that we need to have a central location to refer users to in regards to what features are functional, what features are still in development, and what features are planned for the future. In addition, there still seems to be some confusion surrounding the invite process, so I am going to attempt to clarify all these items in this development update.
    Before I began, I think it is worth mentioning that we created a Frequently Asked Questions (FAQ) area that may contain answers to some of the questions that may not be answered in this blog post.
    While there is no doubt that we have deviated from the FSExpo 2019 Roadmap to Release timeline, we are doing our best to keep on track. Right now, I think it is safe to say we are in Invite-Only Beta, Phase 2. Here is a quick recap on the original plan for Invite-Only Beta, Phase 2 and what may or may not have changed since the announcement was first released:
    Pilots will require an invite code and subsequent approval in order to participate Status Update: This is still the case. Currently, any approved member with access to the network also has the ability to invite two additional registered users to the service by clicking here. Once invited, those members will be placed into a holding pattern until they are approved by the POSCON staff. There is no set time frame on when these approvals are distributed - we approve people when the team feels comfortable to receive additional members. This two-step process was designed to meter the flow of incoming members and minimize the amount of support requests we receive. More information on the invite process is discussed below.
      ATC will be hand-picked by POSCON staff and will be required to sign an NDA Status Update: This is still the case. We have been testing ATC regularly now, but we rarely advertise when or where we will be conducting these testing sessions. This strategy is employed on purpose in order to not overwhelm the controllers as they test new features. On a few occasions, we have given some advance notice of when ATC will be online, but right now those instances are rare.
      Operating times will be schedule limited Status Update: This is no longer true. Before we released, we separated the network into a development environment and a production environment which enables us to minimize interruptions to the users as we add new features. With the exception of a few hot-fixes in the early days after releasing, we have made considerable effort to inform all beta testers of scheduled maintenance well in advance of a server restart. In order to facilitate this, we created a System Status Monitor page which can be used to view the status and scheduled down times of our applications: https://status.poscon.net/
      ATC coverage will be limited to areas selected by POSCON Status Update: This is still the case. ATC testing has been limited to the areas where the facility data is most developed; however, our Facility Data Team has been tirelessly working on other areas around the world as well. Here is just a brief overview of what they have done: 170 FIRs have been worked on. 7856 independent ATC sectors have been created. 7053 independent VHF transceiver sites have been located and entered into our database. 1801 independent radar sites have been located and associated with 73 different radar types. In addition to the above, below are just a few images of the FIRs that have been worked on:





     




     
    Number of users was planned at between 1000-2000 Status Update: This is still the case. As of May 23rd, 2020 we have invited and approved 1278 registered users.
      NDA is not required for Invite-Only Beta, Phase 2 Status Update: This is still the case. You are not required to sign a non-disclosure agreement (NDA) unless you are hand-picked to be an ATC. We will continue to maintain a select group of NDA pilot beta testers to test new features in our development environment.  
    Invite Process - How does it work?
    As mentioned earlier, the invite process consists of two steps: INVITED and APPROVED. Here is how it works:
    Lets assume you joined the POSCON Public Discord first and then realize you are interested in joining the network. If this is the case, you are considered an "Enthusiast" and will be assigned that tag automatically in our Discord server. Now you decide to register at https://www.poscon.net and complete the checklist items which include: ensuring your birthday is set correctly and your Discord ID is connected to your POSCON account. At this point, you are now considered a "Registered User". If you are lucky, you may be invited by an approved member as their guest and you will receive an email from POSCON. If this happens, you are still considered a "Registered User". Please wait patiently until you are approved by POSCON staff. When approved, you are now a "POSCON Member" and have access to our HQ website and are able to download the Launcher Client. This is the point at which you can now connect to POSCON. The time between steps 3 and 4 is an unknown. It could be a matter of days, weeks, or even months. It all depends on where we are at with our development and whether we are ready to accept new members.
    If you find yourself in limbo, the best thing you can do is join our Public Discord and participate in the discussions until you are invited and/or approved.
     
    What is working, what is in development, and what are the future plans?
    Voice System
    Working Features:
    Ground-based transceiver locations have been added for most ATC facilities. Auto gain control. Propagation of transceiver locations to the Radar Client. Our voice library supports the option for separate PTTs per radio (e.g. VHF #1 and VHF #2), separate volume controls per radio, and separate audio devices per radio. NOTE: The pilot clients do not currently support this yet. Full VHF simulation including: 8.33 kHz and 25 kHz spacing. Terrain line-of-sight processing. Beat simulation. End-of-transmission popping tones. Wavelength simulation. In Development:
    ATIS, AWOS, and ASOS automatic audio broadcasts on the proper frequencies. Future Plans:
    HF and UHF. There are many more features planned, but we are going to keep those a secret for now. Website, Training, & Administration
    Working Features:
    Fully GDPR compliant. Integrated support system. Basic flight statistics. ICAO 2012 formatted flight plan form includes: An integrated help tutorial provided on the page. The form validates while entering data. Auto-fill from SimBrief output. Feedback and generic points system works. Live Map used to view online traffic (updates every 2 seconds). Users can leave feedback about each other using the map. Moderators can initiate ghosting, disconnects, and bans using the Live Map interface. Pilot Client Web UI, which can be accessed on any device with an internet connection (see below for more details). In Development:
    Converting HQ to a new language and framework. Moving elements of the ICAO 2012 flight plan to the server. Live Map version 2.0 will use custom tiles and our own tile server. The map will also contain a 2D option for performance reasons. Various upgrades to user-interface and user-experience throughout the HQ. Future Plans:
    Upgrades to the user profile, including notifications. Pilot and ATC scheduling system. Advanced statistics center. Additional ways to earn and lose POSCON points. Additional CBTs with progression quizzes. Airport Advisory Page system. This system will allow Divisions and Sub-Divisions to create informational pages about their airports that will be viewable by all pilots. Pilot Clients & Web UI
    Pilot Clients
    Working Features:
    Both pilot clients support a high refresh rate. Models will update 15 times a second for a smooth visual experience. Enhanced ground-clamping using various methods for a smooth experience regardless of differences in terrain. Model matching. Here is how we handle model matching with the various platforms: For X-Plane, the models are distributed with the pilot client itself and contain custom model matching logic. For FSX/P3D, we have integrated the FLAi model set through our Launcher Client application (see below for more details). ICAO equipment and airline code validation. Accurate ground speed monitoring (X-Plane Only). VHF push-to-talk activation indications. VHF volume sliders on the native user-interfaces. AI model sounds and controls (X-Plane Only). The ability to control the maximum number of AI planes that will be displayed. In-game notification of ghosting and disconnects with explanations. The ability to manually toggle ghost mode or request to unghost. Automatic detection of change in aircraft. X-Plane 11.50 Vulkan support. Moderator messaging directly into the pilot clients. Automatic ghosting for: Sim rate increase, entering slew mode, using replay mode, or deliberate pausing (this can also sometimes be triggered by accessing a sim menu). If you are on the ground and not moving, pausing is allowed. Connecting on or re-positioning to a runway (through a menu) will prevent connection or disconnect the user as applicable. In Development:
    We are fixing various issues with models and model matching (X-Plane). A new multiplayer library is being integrated (X-Plane). A new native user-interface is being added (X-Plane). Future Plans:
    We plan to make full use of the voice system by adding separate PTTs per radio (e.g. VHF #1 and VHF #2), separate volume controls per radio, and separate audio devices per radio. HF and UHF integration. There are many more features planned, but we are going to keep those a secret for now. Here is an Easter egg for those who have gotten this far in the blog: If you can name all the FIRs (the colored ones) depicted above correctly, then you can get an instant invite and approval to use POSCON. DM your answers to me directly. Offer expires May 27th at 2359 UTC.
    Web UI
    Working Features:
    Some functions of CPDLC (Controller-Pilot Data Link) are operational such as the login function and automatic squawk code assignment. Real-world FAA D-ATIS (Digital Automated Terminal Information Service) broadcasts are integrated and can be requested in real-time by pilots. The voice portion of D-ATIS is not working yet, only the text portion. METAR and TAF reports can be requested in real-time by pilots. Radio syncing. Ghost and unghost toggle. Disconnect. Future Plans:
    Additional CPDLC functions, including heading, speed, and altitude changes. Full pilot report functionality. Approaching online ATC awareness messages. Launcher Client
    Working Features:
    The ability to download, install, launch, and update all available network software. Token authentication. Once you enter your username and password once, the Launcher Client will take care of the rest.  We added some new functionality to these buttons. The button on the left refreshes the Launcher Client, the middle button minimizes the Launcher Client, and the button on the right will send the Launcher Client to the system tray. Once in the system tray, right-clicking on the Launcher Client icon will bring up a menu that will allow users to: reload, clean temp files, and quit the application. In Development:
    Adding libraries that will utilize a new content delivery method through a download server. Converting the application to a different framework. Working on moving away from our web dependent set up. User-interface changes such as adding a download progress bar, information display, and a direct link to Discord from the title bar. Working on integrating Live Map version 2.0 through the Launcher Client. Future Plans:
    The plan is to embed the Pilot Client native user-interfaces directly into the Launcher Client. There will be no need to launch a the Pilot Clients anymore after this is completed. Once the back-end work is completed for the above, a new user-interface will be needed to accommodate the integration.  
    Next steps?
    The next step for the POSCON team is simple: we will continue to work hard on bringing you the next-generation flight sim network.
    While we do that, we encourage you to join our Public Discord and participate in the discussions there. Typically, the most up-to-date information about the project is released on our Discord first.
    That's it for now! If you have any questions that have not been answered in the FAQ or in this blog post, feel free to comment below.
     
  6. Andrew Heath
    The Invite-Only Beta is almost upon us, so it is a great time for another development update!
    Pending final bug fixes, we will be sending out the approval emails to the invited users soon. If you are lucky enough to get one, you will be authorized to access our software at the time you receive the email. Those who make it into Phase 1 will receive invite codes for Phase 2 to distribute at your discretion, but those codes will not be immediately available. We will keep you posted on when they become available to distribute.
    Here is a quick recap on the original plan for Invite-Only Beta, Phase 1 and what may or may not have changed since the announcement was first released:
    Pilots will require an invite code and subsequent approval in order to participate Status Update: This is still the case. All available invites have been distributed and those who received an invite are patiently waiting for the approval email, which will come soon.
      ATC will be hand-picked by POSCON staff and will be required to sign an NDA Status Update: This is still the case. One thing to note, however, is that we will most likely be very slowly implementing ATC. In fact, the first couple of weeks will most likely see little to no ATC coverage on the network as it still requires some additional dev work.
      Operating times will be schedule limited Status Update: This is no longer true. We plan to have the server up and running 24/7 as we have separated our development and production environments. We will inform everyone of scheduled down times when we make updates to the production servers.
      Number of users was planned at between 500-1000 Status Update: This is still the case; we have invited between 600-700 users to Phase 1.
      NDA is not required for Invite-Only Beta, Phase 1 Status Update: This is still the case. You are not required to sign a non-disclosure agreement (NDA) unless you are hand-picked to be an ATC. We will continue to maintain a select group of NDA pilot beta testers to test new features in our development environment. Having said all that, now I want to take some time to outline features that made it into this phase. I think outlining these features is an important part of the process of managing expectations.
    Voice System
    One of the main blockers that prevented us from releasing POSCON sooner was the decision to completely rewrite our voice system. Six months ago we were using the TeamSpeak 3 SDK for our voice infrastructure, but we decided using TeamSpeak 3 would limit our technical growth into the future.  As a result, we opted to get rid of TeamSpeak completely before any sort of public release. Over the past few months we have worked tirelessly to develop our very own custom infrastructure and I am happy to report that it is now completed. Our voice will have the following features at Invite-Only release:
    Voice Server Supports:
    Many simultaneous connections. Ground-based transceiver locations; there are currently 4,667 locations entered into our database. Propagation of transceiver locations to the Radar Client. Option for separate PTTs per radio (e.g. VHF #1 and VHF #2), separate volume controls per radio, and separate audio devices per radio. The server supports this, but the pilot clients do not support this yet. Voice Effects Supported:
    Full VHF simulation including: 8.33 kHz and 25 kHz spacing. Terrain line-of-sight processing. Beat simulation. End-of-transmission popping tones. Wavelength simulation. Website & Administration
    Another factor that prevented us from releasing POSCON sooner was the decision to build out a custom Single-Sign-On or SSO. It became apparent, as we added new products and technologies to our software suite, that the generic open-source or even payware services would not meet our needs. I am happy to report that our custom SSO has been completed and is fully functional. Here are some additional web features we will release with:
    GDPR compliance. A support system. Basic flight statistics. ICAO 2012 formatted flight plan form: An integrated help tutorial is provided on the page. The form validates while entering data. Feedback and generic points system. Live Map used to view online traffic (updates every 2 seconds). Users can leave feedback about each other using the map. Moderators can initiate ghosting, disconnects, and bans using the Live Map interface. Pilot Client Web UI, which can be accessed on any device with an internet connection (see below for more details). Pilot Clients, Pilot Client Web UI, & Pilot Server
    The Pilot Clients are by far the most completed products that we have in our software suite. They have been closely designed in parallel so that the features remain consistent across the various platforms. Once you have logged in to the network, the Pilot Client will send information about your plane’s location, altitude, attitude, as well as a number of the plane’s parameters such as gear and flap deployment, engine RPM, state of various beacon and navigation lights, transponder mode and code, etc. The Pilot Clients also receive similar information from the network about aircraft that are within range of your plane. This information is used to draw 3D models of the aircraft at their correct position and orientation. The information is also used to populate various datarefs so that your aircraft’s TCAS system will be aware of nearby planes.
    In addition to the aforementioned features, the Pilot Clients also feature:
    Enhanced ground-clamping using various methods for a smooth experience regardless of differences in terrain. Model matching. Here is how we handle model matching with the various platforms: For X-Plane, the models are distributed with the pilot client itself and contain custom model matching logic. For FSX/P3D, we have integrated the FLAi model set through our Launcher Client application (see below for more details). ICAO equipment and airline code validation. Accurate ground speed monitoring (X-Plane Only). VHF push-to-talk activation indications. AI model sounds and controls (X-Plane Only). The ability to control the maximum number of AI planes that will be displayed. In-game notification of ghosting and disconnects with explanations. The ability to manually toggle ghost mode or request to unghost. Automatic detection of change in aircraft. The Pilot Clients will automatically ghost for:
    Sim rate increase, entering slew mode, using replay mode, or deliberate pausing (this can also sometimes be triggered by accessing a sim menu). If you are on the ground and not moving, pausing is allowed. Connecting on or re-positioning to a runway (through a menu) will prevent connection or disconnect the user as applicable. Pilot Client Web UI Features:
    Some functions of CPDLC (Controller-Pilot Data Link) will be operational such as the login function and automatic squawk code assignment. Real world D-ATIS (Digital Automated Terminal Information Service) broadcasts are integrated and can be requested in real-time by pilots. The voice portion of D-ATIS is not working yet, only the text portion. METAR and TAF reports can be requested in real-time by pilots. Radio syncing. Ghost and unghost toggle. Disconnect. Pilot Server Supports:
    Many simultaneous connections. A variable update rate based on range. When in close proximity to other aircraft, models will update 15 times a second for a smooth visual experience. Airspace awareness. The server can determine a planes position in relation to defined airspace boundaries (both vertical and lateral). This is a very unique feature not implemented on any other network. In the future, this will enable POSCON to build many other features using this core server functionality. Launcher Client
    The Launcher Client is the centralized hub to keep you up-to-date on everything related to POSCON. This product was designed around the idea of "platform software" similar to what Origin, Steam, and other gaming platforms offer. The POSCON Launcher Client mirrors the content contained in the POSCON HQ, but with enhanced functionality: 
    The ability to download, install, launch, and update all available network software. The ability to switch between development and production environments (for NDA testers only). Token authentication. Once you enter your username and password once, the Launcher Client will take care of the rest. That's it for now, we hope you enjoyed this update. In the near future we will post a list of frequently asked questions that should help first-time users when accessing the network. If you have any questions you think would be a good addition to this list, feel free to comment below!
    Thanks for all the support over the last few years, it continues to keep us motivated!
×

Important Information

By using this site, you agree to our Terms of Use, Privacy Policy, and Guidelines.