WhiteRabbit

Thank you for the reply! So what I'm taking from this is: When TWS (or TWS-A) running, the WCS only updates the weighting and scan parameters at the end of every 2 second scan You do consider the beam position in the scan pattern, but that doesn't affect the timing for whether a track has missed a frame. In other words: if the contact seen at the start of one scan (T = 0.1 seconds) and is seen later in the pattern in the second scan (T = 2.2 seconds), it has been 2.1 seconds between detections, but the WCS only cares whether the contact was detected anytime in each consecutive scan Firing a Phoenix, which changes your track to a TMA, should not instantly change weights or cause the scan volume to change Switching from TWS to TWS Auto should not cause a dropped track. I assume when you switch to TWS-A the scan pattern is restarted in the new mode but the unfinished previous scan isn't counted against you. We'll wait until the TMA weighting is fixed and then we'll try to isolate examples of any other weird behavior.

This is something I'm really curious about. I know I've seen cases where TWS-A will have a TMA track, then adjust scan volume slightly to include a new contact, and almost instantaneously drop the TMA even though it seems to be inside the scan limits. I say I suspect it's still inside the scan limits because on the next pass the system will immediately place a fresh contact right on the broken/held track (and fail to associate them). I think a similar phenomenon is the dreaded "I dropped your track the instant you foxed on it". Maybe because changing to a TMA caused the WCS to readjust weights which caused it to reset the scan volume which caused it to drop the TMA due to a refresh timer error or the like? It raises a few questions for me: What level of abstraction are you using to model the AWG-9's raster scan? Do you keep track of where the array is steered and check for aircraft within the limits of the main beam when it's "physically" steered there, or is it a more abstract (possibly more generous) "as long as it's in the scan volume I'm checking the object every 2 seconds post-detection and comparing against the predicted track position"? Similarly, what level of abstraction are you using for the scheduler? When does the TWS-A mode decide to adjust the scan volume and when does that take effect in the AWG-9? Two seconds is an awfully long time in a radar timeline so I assume the WCS is scheduling a series of short jobs that make up the entire two second TWS-A scan. At what point is it actually able to interrupt the pattern and restart the TWS scan to cover a different scan volume? When would it decide to do that - would it at least complete enough of the pattern to update all existing targets before resetting to start a new scan using the adjusted az/bar limits? Obviously the pilot or RIO can interrupt the timeline to change modes, but while TWS-A is in control it should be "greedy" and not bump jobs that are intended to update an existing track. How do the answers to my first two questions affect when the WCS decides a track has been lost? Is there a timer (either based on raster scan position or an abstract timer) that is being reset on a scan volume change before a track has been updated, which causes the track to "time out" because it was due to be refreshed in 0.1 seconds but the scan restarted? I'm only familiar with modern radar timelines so modeling the real-life limitations of a mostly analog, mechanically scanned system controlled by the world's earliest microprocessor is totally foreign and totally fascinating. TL; DR: As a radar guy, I'd love to talk to your radar guy about how and when TWS-A changes the scan volume and how that affects the refresh rate of tracks, especially TMA tracks.

Thanks everyone! DeltaMike, I've changed my setup a few times now and I find it really helps laying things out roughly where they are in the cockpit, even if it isn't 1:1. I have a mental image of the in-plane control panels in my head from staring at the screen so long, which makes it way to easier to instinctively reach to roughly the right place on my setup. I can see how it would be necessary in VR. But as for what I've got mapped there, I use the tank jettison, target size selector, and next target switches/buttons every flight. And I use Phoenix active, MLC, and the aspect switch most flights. I used to fumble around with a mouse for most of those until my pilot and I really started working on our timeline. Mimicking the cockpit setup isn't necessarily faster than any other button box (or Xbox controller) but it's definitely faster than a mouse and easier to remember where things are if I've been out of it for a week or two. The Sparrow aspect selector knob is just there because it's cool, and that's worth it to me. The station select switches would be really useful, except it doesn't look like we can bind them! Get on it, guys! For now I use one of them for TCS slave and one for FOV wide/narrow.

Welcome to the club, Mike. I fly almost exclusively as a RIO and it's a totally different flight sim experience from anything else I've done. I've built a few custom button boxes/enclosures, and I have the excellent CAP input panel from TekCreations on Etsy. I highly recommend it. I have an armament panel that includes Next Launch, Phoenix Active/Sparrow PD, Launch, and tank/weapons jettison, as well as some AWG-9 functions from the left side of the DDD (MLC, Target Size, Aspect). It's something I'd like to put up for sale but haven't gotten around to it. My armament panel up top, TekCreations CAP panel on the bottom: I also have a center console with mode and DDD range buttons and a warthog stick + HCU selection buttons (DDD, TID, RDR, ICS), and it has a built in monitor for a TID/DDD repeater. That one needs some refinement before I could sell a version of it. Here's the center console mounted on a folding cockpit frame (made to fit in a 22" wide closet!) with the TekCreations panel. The pit is interesting to fly in - from the numbers I have it's close to the dimensions of a real Tomcat cockpit and it's very tight: TID and DDD in action, with the CAP panel all lit up: Karon, that setup really is sick, and I love your site! I've got your kneeboard pages printed and inserted into a real kneeboard I strap to my leg. Very dorky but surprisingly helpful.

I've been using Kneeboard Builder to move my kneeboards off my third monitor (which provides the displays for a custom built RIO pit) but the latest patch seems to have broken the latest Kneeboard Builder. Why in the hell can we not move our kneeboard? The game is basically unplayable for me right now because my kneeboard is showing up behind a piece of the RIO pit.