Jump to content

Karon

Members
  • Posts

    903
  • Joined

  • Last visited

  • Days Won

    2

5 Followers

Personal Information

  • Location
    EU
  • Website
    http://flyandwire.com/

Recent Profile Visitors

10470 profile views
  1. I can't check the bible right now, but I don't recall limitations about the mode. IIRC, it said that the AHRS has freedom of movement minus something, and precesses when pitch > 82° and over prolong easy turns with AoB leading to 6°/min. EDIT: had a quick and I think what I said it's correct. I'd take longer to thoroughly check. I noticed that the COMP knob looks weird on the displays. I could swear this was fixed a long time ago, or perhaps I'm just wrong. I raised it to the devs, though.
  2. You sure it's not precessing? The AHRS doesn't like prolonged turns with rate < 6°/minute. Another cause of precession is pitching > 82°, but this is of course not the case. If nothing else is going, then this should fix the problem. Obv there are situations where the de-sync occurs again post fix, the RIO should maintain awareness.
  3. Hey folks! I have spent some time studying the basics of the INS mounted on the F-14. It's definitely not brand-new technology, and it suffers from a few quirks but, generally speaking, is an outstanding piece of kit. One of the issues affecting the avionics is related to the Naval employment of the Tomcat (and not only the F-14, definitely the A-6, probably the F-4 too). A recent bugfix was recently released that sorted out the primary method of addressing this problem. Thus, I took the occasion and put some stuff together, something that I hope you can find interesting. Rather than go too much into the technical details of the problem, I'll keep this short and straight to the point. At the end of the posts, there are a bunch of links to a more in-depth look at the issue, and a study of the AN/ASN-92 INS. So, where do we start? Carrier. Big carrier. A lot of metal. The carrier causes some parts of the avionics to go nuts, namely the ones that should indicate the aircraft's direction. Let's call it "compass". This causes issues to the relatively rarely used non-INS navigation (DR & pilotage, Aerodrome charts, specific instructions, etc) and, especially, Air-to-Air. As mentioned, until recently, the only reliable fix was flying straight and unaccelerated (even non-continuously) until the AHRS re-synchronised. The ratio was ~9°/minute. This is why many never noticed the problem, but sometimes this is not a sufficient solution (especially if you YOLO from the catapult). The dedicated function to address the de-sync of the "compass" is located in the front seat, in the Compass Control Panel: the HDG Pushbutton. Now that the HB devs sorted it out, it can sort out the "compass" in a matter of a few seconds, rather than minutes. A lengthier article is available here; it provides a few more details. A more in-depth short study about the INS is here. This article contains the tests I made and a few other observations. I hope you can find this stuff interesting. Feedback is always welcomed. PS: fun fact, this is probably my first post in this subforum
  4. As per many other recent articles on the website, the discussion about the AN/ASN-92 INS was created with the book in mind, and then ported to the web. I recently added a new video and Chapter/Article to complement and, hopefully, close the topic. The occasion is the recent bugfix deployed to sort out the HDG Pushbutton that was affected by a nasty bug in some conditions; the quickest way to sort out a desynchronised AHRS when operating from a carrier. This is something every F-14 crew should be aware of, as it can drastically impact the efficiency of the aircraft in a mission. Related article: https://flyandwire.com/2022/08/09/must-know-fix-an-f-14-departing-from-a-carrier-an-asn-92-bugfix/
  5. If you mean which contact appear, that's due to the AI logic. It'd be great if the assignments could be made via LotATC by a human. It would make the LINK4A meaningful. Atm is kind of useless due to the limited ROE and classification.
  6. @The_Tau and @Northstar98 have already answered, so I'll add just a quick note. Check your TID, when discrepancies greater than (IIRC) 5° are detected, the VM acronym appears, and it alternates with the current nav mode. At this point, the crew can switch to a mode that bypasses the vC, thus offsetting the problem, at least partially. On a general note, be careful when INS and related devices start acting funny because, although you can bypass or fix most of the issues, not all your displays are fed by the same systems. Namely, the BDHI is fed directly by the AHRS, whereas the info for other displays are provided by another piece of avionics (CSDC perhaps, I need to check). Therefore, depending on what you do, you may still have deviated indications here or there.
  7. Another brief video hastily put together to close the discussion about simplified the intercept by covering the last step: the stern conversion turn. As in the previous part, the techniques use the TID to place the target in a certain position, before starting the turn. No manuals involved!
  8. I'd read these sorts of posts for days. Thank you, Sir!
  9. I see your points @Exorcet, disagreeing is perfectly fine My only "concern" (for the lack of a better word), is how much effort would this require from Heatblur. I have the feeling a less-cheaty-more-realistic implementation requires a series of structural changes that only ED can make. Perhaps a common framework accessible via API. At the end of the day, the number of multicrew aircraft is growing fast, and a solution provided from ED would help every third party (but the discussion should happen in a different channel).
  10. I'm not even going to open the can of worms that is the usage of flaps. That's something for you lads in the front. I'm more than comfortable in the backseat That being said, @IronMike is this something feasible, in your opinion? Thanks for replying. Other observations: Q1 - you almost lost me at cheating... Who would tell you those parameters? A human controller cannot interface himself with Jester. The AWACS is in ED's hands, and I doubt they will ever implement anything like it. Q2 - I was referring to the transport / fighters example. Again, no way even for a human RIO to sort this out besides working on the geometry. Q3 - More cheats? Humans don't cheat, they guess based on experience and factors. This is not really something you can code easily. Unfortunately, I disagree with your answers, and these are just common and simple scenarios. I'm afraid there is little way to mimic a human without cheating or rolling dice (although, in a sense, humans ponder options and do roll dice). I think @Bremspropeller's point is much more feasible tbh. However, HB's working on Jester 2.0, and I'm looking forward to being surprised by the final implementation
  11. What if there was a sort of hook function for the pilot, active on the TID repeater, to tell Jester to centre the radar on a particular track, either datalinked or from the radar (RWS and TWS)? Would that work in your opinion? The radar would be still subject to all its limitations (e.g. centering on a Datalinked notching target in TWS won't make it magically appear), but most of the micromanaging would be removed. About the first sentence, I guess it's just a case of adding a condition where callouts are limited to hostiles within X nm if the landing gear is down (I wouldn't use the flaps as a condition, tbh).
  12. You understand the logic is a script, right? I'm talking about coding here. For the sake of the discussion, let's assume that the biggest problem (how would you brief Jester on mission parameters, timelines and so on) is already solved. Let's see now some common situations Jester would have to deal with. There are dozens of similar situations, but I'll stick to 3 to keep this brief: Question #1, how would Jester identify the correct contact? A RIO collects "clues", but there are situations where he cannot really figure it out what is going on. A much more realistic alternative would be having a controller either datalinking or committing the fighter (but the controller we have is absolutely rubbish and one of the worst aspects in DCS at the moment). Question #2, Jester sees some targets, perhaps multiple RWS tracks, but a single clustered TWS. How would he handle this? Question #3, Jester knows which one is the target, but the track is lost, then the target is found again, but now he does not know which one it is or if the target is still there in the first place (exactly the same issue the WCS has). A human can guess, should Jester guess too? Based on what percentage? Like, press 30%, reset 70% and roll a die? I don't mean to be rude, but I have the feeling you are not familiar with the work in the virtual backseat. There is a lot of guesswork and intuition to figure out what is going on, compared to any modern aircraft in DCS, where building SA is elementary, RWRs are precise to the nanometre, and you even know what is what. But please, try answering my questions, and perhaps I'll better understand what you have in mind.
  13. @Exorcet I wrote a lengthy reply and then deleted it because I think it did not convey the message: Jester, is the interface between the human pilot and the AWG-9 WCS and the avionics. It is not a virtual RIO. The number of tasks the RIO performs is long, very long and most of them happen in background and they are all based on proactivity, the ability to interpret information, communicate with the controllers and build SA. Scripting them is simply not worth it because the AI does not know fundamental parameters such as the mission tasking, ROE, conditions for mission complete or failed and so on. Also, as you said, this won't even be a core feature, rather something that can be toggled off, making this even less worth it. Don't get me wrong, I'm happy if Jester is improved. I think HB did a terrific job with it, but the more I think about the thousands of conditions that should be scripted, the more I'm convinced that only simple and straightforward features should be implemented (see the collision calls / AWACS calls we mentioned). I'm more than happy to write a flow chart of the basic operations a RIO performs, but I'm worried about how long and how big it will be.
  14. A short video to complement the discussion about bombing present in the upcoming Draft 5 of my book. In particular, level toss bombing and self-lased dive toss bombing are demonstrated. Although these elementary procedures and primarily the Pilot's bread&butter, the RIO is still involved in a monitoring position, offering guidance, and help to manage the flight parameters, countermeasures, scanning for threats and so on. Something that clearly misses in this video.
  15. My .02 here. What really puts aside Jester compared to a human is the proactivity: depending on which phase of the mission you are flying, it should tell the pilot what to do and when. I suppose this is not hard to implement per sé and, besides the "guts" or "two steps ahead" decisions a human can make, an AI is perfectly capable of assessing a couple of elementary angles. What I'm wondering is: how many players would follow the instructions of an AI? The same AI should also call the intercept off if the player won't follow its instructions, making the intercept disadvantageous. Would players get frustrated and deactivate it, or RTB / reset as instructed? Considering that I fly only as RIO and get quite annoyed when my pilot does not fly at the values I tell him (happens very rarely and only when I used to fly with random free pilots on a server), I wonder how you would script the AI to react. As a human, I simply moved back to spectators and call it a day. Would the AI simply carry on giving instructions? What would be the point? It sounds like a cubic ton of work on the scripting side for something most players won't appreciate. Something that can be done, perhaps, is adding a menu to request a certain geometry on a target, or a collision course. For instance, command Jester to press the Collision button on the TID, and a commentary to it. Example: Select "Collision Course" from the Jester menu; Jester replies something like: "ok, come left, steady 320 for collision intercept"; When the player gets to 320: "steady up". It's like a button, but it sounds better in Single player, I suppose. You can even do that for a Timeline, with Jester calling the range and where to turn to centre the T or the centroid. Actually, it'd work better with STT, TWS is too temperamental for that, probably. What do you think?
×
×
  • Create New...