kevinfirth

Short answer to all these is no, yes, yes. (We will add Directs to the development list) This is a great juncture to mention the difference in operating modes. If you look back up a few posts, you can see at the top right the prompt/expert mode indicator. VoxATC will work in two different modes, which, as Ronseal will testify, do what they say on the tin. 1. Prompted mode - VoxATC will give you prompts for what would be an appropriate pilot input for that phase of flight. You don't have to follow these, but if you deviate from them too far, things might get complex. The menu button will give you a context appropriate list of options which you can select, and Vox will give you a prompt for the appropriate comms. 2. Expert mode - For hardy (or should that be foolhardy? 🤣) pilots, you can 100% rawdog the ATC experience. VoxATC will give you no prompts whatsoever, and you will have to wing it to the best of your ability. Get it wrong? Sorry, there's no help button... In expert mode you can say whatever you like, whenever you like, so brush up on your CAP413 uk pilots please... If you expect to be doing a lot of the examples above, expert mode will probably suit you best.

Claude cannot at the moment access Google Earth itself to map holding points - I tried! What you can do is drop your self created kml files containing an airport's holding points created in Google Earth to me over at our discord and I can AI generate bespoke xml files for VoxATC with that 😁 I've created an automated tool that will generate them this evening.

To add to my previous post - despite being a bit of an AI luddite only a short while ago, I'm a paid up subscriber to Anthropic now. I've been using Claude to create workflows to automatically generate more detailed .xml files for VoxATC that specify up to date comms information and (where data is available) VRP's. Claude seems to be able to access data direct from official Pooley's charts, which bodes well for the future... Where data is available I can auto generate VRP information for Vox. Holding point data is far less available and even Claude threw out a warning that whilst it could approximate a position based on an airfield ARP and reviewing satellite imagery, it wouldn't likely be accurate enough. What I've done in the past is create kml files in Google Earth specifically identifying holding points. I'll have to play around with some workflows to see what exactly is and isn't possible as far as AI application goes here. One thing is clear, if anyone creates a kml file with specific holding point geo-data, it's absolutely possible to automate AI incorporating such information into xml files to be freely available to improve accuracy in Vox.

I'll cover where we are with VFR and VRPs a little later, like I said above 👍. Leveraging community support is absolutely a great idea. You will be able to create customised airport specific profiles in XML yourself straight away, and this functionality is already flagged for future further development.

You do not have to speak exactly as the prompts display, but they do contain all the necessary information and structured in a professional comprehensive manner. SO, treat them as a recommendation, something that would in most cases be real world acceptable. As Ive covered before: Vox ATC uses a locally installed neural processor working in conjunction with windows speech recognition. VoxATC therefore takes two inputs, one from speech recognition and the other from the neural processor and determines the output it works with. This vastly improves accuracy over simple speech recognition alone. It requires no internet connection, no external AI and no subscription costs. It does require a little training by the user and some continued developer tweaking of the local neural processor rules to massage out edge cases - a process of continual improvement. (and last but not least, which specifically answers your question -->>> ) The voice recognition system is also as a result much more flexible. It intelligently expects and looks for certain types of responses in different phases of flight. It recognises keywords independently, so for example, rather than having to read back a controller instruction strictly verbatim, you can successfully read it back correctly, but in any order. If you make one element of the readback improperly, VoxATC will repeat only that element back to you for correction. In short, you don't have to speak exactly as the VoxATC prompts display, but get it wrong and you should expect the controller to pull you up on it.

Here's the interface for VoxATC in-sim.... The panel display above can be displayed and interacted with in several different ways. You can have the panel open in the simulator on screen as shown above. If you have a microphone connected you can speak instructions to Vox If you don't have a microphone connected, or don't wish to speak, you can use the prompt mode (as shown above.) When there's an input required from you as a pilot it will be shown in the prompt line, along with a 'Say it' button. Just click on the say it button and Vox will speak your input for you. You can have the panel open in a second monitor so it doesnt take up any of your screen. You can have the panel open in a networked device such as your phone or a tablet. the buttons that are clickable on screen are useable in touch sensitive devices.I often use the panel on an ipad and select any input with a finger. It's also worth noting that the menu button allows you to quickly and easily change comms frequencies when needed. Vox will instruct you to change frequencies where required in the instruction/prompt line. You can do this manually in your aircraft, or you can just press the menu button to automatically change comms without having to look down and fiddle with cockpit systems. I find this incredibly useful when either in a high demand environment (for example on approach with busy vectors) where you are a single pilot managing everything, or where I'm using head tracking and it gets really awkward trying to keep the view centred on awkward little clickspots.

All flight-ops are suspended during the daytime here. Temperatures are high enough to make my rig creak unfortunately. 40deg C doth not make a happy CPU! 😢

While interesting, the numbers themselves don't have any bearing on which runways are usually allocated in any given conditions. I've updated my understanding of how things work at EHAM based on your and others input thanks!. I'll use that to create a more up to date ruleset that gets as close as reasonably possible to the real life restrictions and allocations. That will be over the coming weeks though. So for now, thankyou for everyone's input on EHAM - I think the discussion about the tool has shown how powerful it can be (and that there are improvements to it that can still be made). Tomorrow, I'll start to go into a little bit more detail on the interface and options you will find. After that, I'll look at an overview of some of the VFR capability. then we'll circle back round to consider some of the IFR, then VFR intricacies. Any questions on those - I'm happy to field them - pass your message!

Sorry, just not going to happen. Supporting one moving target with Asobo is challenging enough!

Lots of things have delayed and interrupted getting to where we are now. Enough said. I'm sure you will be quietly content with the price-point of Vox. 🙃 ...and I haven't covered any of the VFR functionality yet. 🤫

So here's my sources for EHAM 😉 Peak/off-peak/night runway combination counts (1+1, 2+1, 1+2) EHAM eAIP AD 2.1/AD 2.22 (LVNL) — Netherlands eAIP, current AIRAC cycle, https://eaip.lvnl.nl Night curfew closures (18R/36L, 18L/36R, 04/22, 09/27, 18C/36C timings) EHAM eAIP AD 2.1 (LVNL) — Netherlands eAIP, https://eaip.lvnl.nl Gust threshold (gusts <10kt ignored) and ATC discretion on extreme wind EHAM eAIP AD 2.22 §4.3 (LVNL) — Netherlands eAIP, https://eaip.lvnl.nl Preferred combination: 36L departures / 24 landings under northerly wind; 36C added at outbound peak; 18L added at inbound peak. Pairing fully reverses under southerly wind (24 departures / 18R landings, with 36R and 18C as the swapped helper runways). Schiphol official site, 'Noise and runway combinations', https://www.schiphol.nl/en/schiphol-as-a-neighbour/noise-and-runway-combinations 06/24 (Kaagbaan) preferred for arrivals, 18R/36L (Polderbaan) preferred for departures — noise rationale Schiphol official site, 'Noise and runway combinations' (as above) Runway lengths and identifiers Public EHAM AIP/chart data, cross-referenced with Jeppesen EHAM airport briefing pages 04/22 restricted to single-engine propeller <5700kg MTOM for training EHAM eAIP AD 2.1 (LVNL) Numeric crosswind/tailwind thresholds per named combination (AIP §4.3.3) NOT VERIFIED from public sources at time of writing. [Estimated]

deleted - duplicate post

I got there in the end (see edited post above), but thought it was some kind of slang or regional thing as you repeated it 4 times 🤣

IAP most commonly stands for In-App Purchase, Identity-Aware Proxy, or Internet Access Provider. Or Instrument Approach Procedure (IAP)?

I'm lost as to what IAP means - we are clearly a different generation 🤣

We're not going to be using AI for this, but if you want to for your app go fill your boots! 😁 The rulesets are laid down pretty strictly, for quite obvious and proper reasons. If you depart from those (apart from exceptional circumstances) then you won't replicate reality IMHO. AI might have some application potentially in edge cases, where in real life a controller has to exercise some discretion outside of the rules, but at what cost to the user? I think most people want something that caters to 90-95% of real life as cheaply, efficiently and effectively as possible. That's what we're aiming for [to start with.] That said, I'm cool with you commenting (thankyou!) and super-cool if you decide to take a different approach. Maybe you'll achieve something much better and best of luck to you 👍

So I tweaked the ruleset a little in one part, and for those times/conditions, the test part of the tool now gives the runways you said were actually used.... Creating a proper profile as real as can be for most conditions will as I said before require a LOT more input. But this shows it can be done - and I chose EHAM specifically because its an absolute b@st@rd of an airport for this - so if we can get it right here we can do it anywhere with a high degree of confidence. Just don't underestimate the complexity of researching, analysing the data and preparing the ruleset creation to arrive at what appears to be a simple result please! 😇

Thankyou! Again its good to get a little feedback that the comms is appreciated - no-one likes talking to a brick wall 🤣

It's also worth noting that the tool already contains some test facility, so you can create some rules, put in your parameters and see what data output you get. Makes it quite easy to see whether the ruleset works correctly or still needs tweaking. So now I'll go and try that specific metar and see what I get... It throws out rw 06 according to my ruleset. A super accurate ruleset is clearly going to require much more finesse. I note here that at 18:25 departures were using 36L, which requires the longest taxi out, approx 20mins. Obviously that wouldn't be appropriate for the whole day when it is busier. Its possible to do it really accurately but like AI token use, the more accurate you want to get, the more time and number of rules you have to create and test! My example served its purpose, it showed what we can do with the tool and sparked a discussion which illustrates how much more complex it can get!

Interesting - those conditions are relatively calm, bit of fluctuating wind direction, good visibility, but nothing that would significantly affect flight operations at 7kts? My Claude research on which that ruleset is based included this....so its not surprising vox didnt include rw27. Wonder if there was some special case that the controllers used 27 for? Do we have any data on what/how many a/c landed using 27? Strong crosswind (>15kt component) from SW/NW 09/27 brought into use

Thank you for your feedback. It's always motivating to know that I'm not communicating to a dark void! 😁

As the traffic is generated it is assigned to the runway that satisfies the selection criteria and has the least traffic ahead. Same happens when the user arrives / departs

It's worth noting that this profile I did for EHAM is NOT intended to be a 100% faithful reconstruction of real world ops. It is intended to demonstrate the kind of capacity VoxATC will have and develop further. It is possible to get a lot closer to real world ops, but that will inevitably involve getting more data, and setting up and testing much more finely tuned rules based on real world crosswind limits for individual aircraft types. This demo was never intended to go that deep, it would require a lot more research time and effort than I had available this morning I'm afraid! Factoid To do this is I asked Claude to compile a database of runways and useage patterns based on published rules and available actual data. It did a pretty good job, but on the first pass Claude got confused between departures and arrivals and started mixing runways up 🙄 It actually produced a look up table for windspeed/direction. But, while AI is great at a lot of things, its results needed fine tuning and checking!

Do you by any chance know what the metar was at that time please? That historic data is only available for paid subscriptions :-( With some reference data it would be possible to more closely calculate the crosswind limits and fine-tune rules to get closer to them.

There will always be some additional edge cases that can be added. This was something I knocked up in a couple of hours research so I am not trying to say in any way that it covers every possible eventuality! But, it does cover some of the major ones and demonstrates how capable VoxATC can be. The rules don't as yet accept dates. I've already suggested that days of the week should be added, because as I was creating this it was apparent that the additional arrival and departure runways are only available on the weekday peak times, for example. The tool is fairly self explanatory - just a couple of programming bugs to be worked out - so yes, "+" and "-" signs add and delete runways. Maintenance plans for runways aren't supported at this point. Aircraft type is already covered, allowable selections include superheavy, heavy, medium, and light jets, medium and light props. I used those to restrict 04/22 useage to those aircraft types. Not entirely confident I could answer the algorithmic question on multiple runway use. I'll come back to you on that. I think it's going to heavily depend on what AI is approaching from where and how it gets sequenced by VoxATC. That's some of the hardest part of creating an ATC app and I'll be honest, in that I cannot explain that to you easily here. 😆 You can of course take any airport profile and customise it to your specific needs at any point. It would be just a file switch and backup.