SeaBass80

This seems to be the same issue reported by me and before by others, see here. It was marked as "reported before" and locked, but has not yet been resolved. It is great though that you included the real-life videos on this to convince the team to tackle this soon. I still consider this a very awkward problem that takes lot away from the beautiful hands-on functionality of the F-16 switchology.

At the moment, it is really hard to fly the Ka-50 trough rain. The raindrops do not seem to be affected by the rotor downwind at all, and the wiper has no effect. This results in very bad visibility in hover. Are there any plans to update this before the planned BS3 release?

As ED is always really focused on getting the subsystem modeling as correct as can be based on public data, I was also wondering about the roadmap for the ground mapping (GM) radar modes. We have essentially the same problem in the F-16. Based on public data and physical intuition, the real-beam-mode "RBM" ground scan use a standard radar beam emitting from the radar dish antenna that (for the F-16) has a cone angles of ~4°. This angle defines the azimuth resolution of the radar image (in F-16 improved to ~1° by software magic "EDM" enhanced mode). In the vertical plane, the 4° defines the scannable patch of ground, while the resolution in this direction comes from measuring pulse echo delays and is thus much higher. As the OP noticed, there are a few deficiencies in the depiction of GM radar modes at the moment, both in the F-18 and the F-16: The vertical plane beam size after a single scan (1-bar) for the radar dish extends from right below the aircraft to the horizon... this is impossible. It should be 4° in the vertical plane. This is a severe limitation in real life when flying at large altitudes: the radar will still map the +-60° in azimuth, buth only a tiny slice of the terrain ahead (vertical scan plane or distance direction on the radar map). The antenna height orientation is not referenced to the airplane. A plane going vertically up cannot map the ground with a front-facing radar. Both of these issues should be straightforward to correct as they don't require recoding of the actual radar-mapping code. The "only" thing to do is to correctly implement the real-world pointing and scanning limitations. This is independent of how the actual radar map is calculated (ray tracing or some logic based on the 2D map). There is another limitation that I haven't seen being discussed anywhere: There are no radar returns whatsoever from above the horizon line. I found references for the F-16 of pilots being instructed to use the narrowest sideways scan pattern with the antenna pointed into the sky straight ahead of the aircraft in order to check for weather conditions ahead. Seeing rain on the radar would be the next step in realism. This last thing might indeed require more work on the radar code, though. Everyone focuses on the A-A radar implementation for obvious reasons, but I would love to see ED getting back to improving the realism on this fundamental part of technology. I would say these are lower hanging fruits than dealing with dropped radar lock issues and any of the hundreds of posts complaining about radar lock range and stuff.

I think that the effect of changing the antenna elevation while in ground radar mode is modeled incorrectly. Expected behavior: when moving the radar antenna up, the nearest radar returns should vanish first (for small upwards elevations), those furthest from the plane last (for largest upwards elevations). When tilted towards lower elevation (downwards), the furthest radar returns should vanish first. Observed behavior: when tilting upwards, the radar image gets dimmer overall. When tilting downwards, also the full radar map stays on the screen. At sufficiently large downwards elevation of the radar antenna, the radar map starts to look through mountain ranges and suddenly is able to display valleys on the other side (F16-GM radar elevation.trk) F16-GM radar elevation.trk

Hi, a few perceived bugs have already been reported concerning slewing of the GM radar. Running the risk of overreporting, I would like to mention these bugs that are very "annoying" and seem to break with the otherwise smooth "clickology" of the F-16 cockpit/MFDs. In ground-mapping modes with A3 or A1 azimuth settings, the radar map generated during a prior sweep will move along with the cursor when slewing it around, until the radar image gets replaced on the next sweep (F16-A3 slew.trk). This is likely a bug, as it temporarily produces wrong coordinate to radar map relations when hitting the freeze button at the wrong moment. It is also very likely related to how the freeze mode itself is implemented, as it is very similar to this already-reported bug. In the expanded radar modes, the radar image only gets updated when the finger is off the slew axis (F16-DBS2 slew.trk). There are actually two updates to the radar map that is being displayed: The first update occurs the exact moment that the finger leaves the slew axis and essentially returns the ground map to the position it had before the start of slewing. At this moment, the map displays a cursor/map combination that does not equal the SPI coordinates, as those are already slewed to the new position. The second update finally occurs when the next radar frame/sweep is started and overwrites the image with the new, correct one. This behavior was reported before, though marked "correct-as-is" for lack of written documentation. The only reference I can provide is the publicly available HAF -34 for the F16C/D Block 50 (1997), which states that in DBS1/DBS2 "refinements in cursor position take effect only at the start of a frame" (p. 1-148). I take this as meaning that the DBS1/DBS2 ground map should be refreshed once per radar sweep, regardless of whether the cursor is in the process of being slewed around. Circumstantial evidence that the current implementation is wrong is mainly that due to the long update time in DBS2, there is a high probability that FZ mode is used to freeze the radar map in-between the "first" and "second" radar map update described above. In this case, the radar would display a ground map and a targeting cursor at the position before the slew started, but the SPI coordinates would already have been slewed to the new coordinates. This simply cannot be right for the real-life aircraft. Very likely related to the above problems: The "update" of the radar GM mode ground map display is handled quite differently in A6 and A3/A1 azimuth settings. In A6 setting, the ground map is static and only refreshed when the radar beam passes on its sweep. This means that in a turn, the SPI cross temporarily moves across the display map before the map is updated. In A3/A1 modes, the ground map is (presumably correctly) rotated based on the INS information so as to have the SPI cursor always on top of the correct ground map point (F16-GM radar map updates.trk). I actually presume that the ground map should behave just like the air-to-air modes of the radar, in that the radar return image is correctly shifted and rotated based on aircraft INS data in-between radar sweeps. This is the only way that a SPI cross that is fixed with respect to the MFD frame will always stay on top of the designated ground point: the radar map needs to reflect the INS-derived aircraft movement even between updates. Obviously, none of this is described in the public documents, but this is true for either interpretation of what is correct and what isn't. F16-A3 slew.trk F16-DBS2 slew.trk F16-GM radar map updates.trk

@cofcorpse Yes, we are only talking about the calibration marks. During the DX/DY and roll calibration steps, the JHMCS helmet should project calibration marks into the field of view that are "stabilized on the HUD", i.e. they will not move relative to the HUD symbols if the JHMCS is moved (X,Y,Z) or rotated (yaw, pitch, roll) in any way, as long as the HUD stays in view. The calibration consists in moving these symbols into the correct DX/DY position and the correct roll orientation by the slew cursor only. Head movement should not move them at all during the calibration step. The fact the HMCS calibration marks move with head roll likely indicates a problem in how the roll and roll calibration is implemented in the DCS JHMCS - at the moment, it cannot produce a calibrated helmet if roll axis is not zero, which contradicts the purpose of the calibration.

The -34 manual for the F-16 has some details on this in the "Preplanned weapon delivery modes" section. It recognizes the need to update the bombing geometry prior to the attack run. The standard methods for doing so are (1) direct sighting of target by GM radar (2) offset sighting using GM radar or (3) visual sighting using VIP/VRP. (1) does not require explanation. (2) would mean that the flightplan includes an IP steerpoint which has clear radar returns (e.g. a bridge in the target approach). When this is the selected steerpoint and the radar is slewed to the actual ground return, the system will remember the offset from the steerpoint. This is the functionality that everyone wonders about what it is for. Normally, we don't care and always "cursor zero / CZ" before doing anything. Actually it is quite smart. If the next steerpoint after the IP is the target, the offset found by the GM radar slewing will directly carry over to the target position and the system will point you to the correct position as the INS drift during the long approach to the IP does not matter any more. The early F-16 was designed to operate without targeting pod, and the CCRP bombing modes provide no mechanism to "visually" set the offset between where the system thinks the IP should be and what the real world says. This is where the "visual" IP mode comes in: it allows you to visually identify the IP, slew the HUD marker over it and then do the attack run. This would be method (3) In the modern F-16 with the targeting pod, you can also use that to "visually" do the offset correction. You would just have an IP steerpoint and a target steerpoint. Overflying the IP steerpoint it can be identified and marked with the targeting pod... this also creates the correct offset correction for the following target steerpoint. Maybe it is harder though to use the targeting steerpoint in nap-of-the-earth terrain masking conditions, so the VIP/VRP modes are still preferable there. Just my two cents on how I *think* this tool was meant to be used.

Maybe the only written reference I found is here, in the F-16A/B Mid-Life Update tape 3 documentation , page 63. Obviously not the same aircraft model, though my guess is that the JHMCS is similar. The DED menu certainly has the same HMCS calibration procedure. The manual says that upon entering either the DX/DY or the roll alignment procedures, "The HMCS display stabilizes on the HUD". At the moment, this only works for the XYZ and azimuth/elevation head coordinates, but not for head roll. Maybe this helps as a reference for the development team to take a look.

I guess we were hoping for some SME to magically chip in and provide hands-on experience As far as I know, the JHMCS uses a magnetic field (three orthogonal coils with offset AC currents) projected by the MTU unit mounted to the canopy to track its position. There really is no "zero" position for any axis unless properly calibrated with closed canopy. JHMCS roll axis calibration should work regardless of the actual in-game roll-axis position. At the moment, it only produces correct roll calibration if the in-game roll axis is at zero during calibration. To bring home that point: for the JHMCS calibration in the F-16, it doesn't matter where in XYZ space you sit during the DX/DY calibration, and it does not matter whether you stare exactly straight into the HUD or tilt your head a little during DX/DY calibration. For roll calibration though, you must have zero roll on the joystick/trackir axis to a get good calibration. To non-SMEs, this just seems wrong.

Does anybody here fly the F-18? Are the roll alignment marks in its JHMCS alignment procedure also not roll-stabilized?

My understanding is that the relative IP-to-target distance and bearing could be accurately determined even in the 80s from aerial reconaissance photography. The precise targeting did not come from a foolproof, super accurate on-board GPS but from semi-reliable INS guidance. If you fly low-level under terrain masking conditions, you simply cannot visually identify the target first - you identify the known IP in the approach path, fine-adjust your steerpoint, mark it by TMS-up, and the guidance computer will then tell you exactly where the actual target is. You could use a bridge in one valley as a visual IP, and based on these coordinates pop up for an attack on a warehouse in an adjacent valley. So for the VIP case I guess this is a very useful tool. It's just looks unnecessary in the DCS F-16 as here the INS/GPS guidance is always perfect, as far as I can see.

To me, the main point is that the roll calibration should work with whatever head roll the pilot defines as his "center" position. In that regard it does not matter whether the pilot's neck is not straight or the helmet itself is slightly off. At the moment, we get an error that is proportional to how much head roll was used when doing the alignment. I *think" in the final step of the calibration (roll alignment), the helmet would need to project the two crosses in a way that the upper one always stays on the center of the HUD cross and the lower one always stays on the vertical line. This should be true for whatever head position the pilot uses at that moment. If it is off, it is to be corrected with the cursor slew axis until the crosses always fall on top of the vertical line. Yes, the symboly *after" the alignment is projected with respect to the helmet "up", otherwise this would make reading stuff really difficult. At the moment, the roll error after alignment is more or less proportional to how much head "tilt" is used during alignment. The purpose of the alignment should not be to teach the pilot how he should hold his head, but to adapt to him and the helmet. In real life, there is now tilt axis on my head that I can center, after all. Maybe somebody knows a former pilot with hands-on experience with these helmets.

Not a lot of people seem to mind this issue, given the lack of responses. Since the F-16 does not come pre-aligned when cold-started, proper implementation of the alignment is rather important, I think. @Frederf, so I get that you consider the missing "head roll stabilization" of the roll alignment marks as a bug as well, right? Can topics be shifted to the bug thread, or should I repost it there?

Very reproducibly - maybe these can be added to the error report for the team: In CCRP and DTOS, WPN REL very often leads to instant weapon release, especially when far from the solution (before the solution cue starts decending the ASL. No azimuth steering guidance after CCIP designate at all. Frederf's last trackfile shows this quite well. This at least has been missing "feature" for a long time... I think it was never working.

I am wondering about the roll-axis alignment of the JHMCS. Observed behavior (DCS): in roll alignment mode, one is supposed to rotate clockwise or counterclockwise the orientation of the two alignment crosses to make them coincide with the vertical reference line. But if the head is tilted/rolled during this procedure, the two crosses actually again form a non-zero angle with the vertical reference line, so you don't actually know whether you are correctly roll-aligned or not. Expected behavior (what I think it should work like - I don't have real-life experience): the relative angle between the imaginary line connecting the two alignment crosses and the vertical reference line should not change with head roll/tilt. During roll alignment, one merely has to bring this angle to zero by rotating the crosses manually clockwise or counterclockwise. When done so, the alignment crosses should stay on the vertical reference line independent of head rotation. The way it is implemented now I guess would make it really difficult to (re)align the JHMCS during a bank turn, as your head would likely tend to align with the horizon when sitting in the cockpit for real. If one goes through the alignment procdure under these circumstances, their is a noticeable head-roll dependent pointing error in the HMCS steerpoint cue. Does anyone have any real-life experience on how these helmets are supposed to align? Unfortunately I don't have any original written references.

On closer inspection, I might have been misled. The sound i took for the gun sound is actually the supersonic bullet noise. The actual gun sound is much more delayed (so very likely entirely correct). The reason I apparently got miseld is that at least the F-16 gun sound fades away with distance from the aircraft nicely up to some distance, and then more or less suddenly vanishes once a certain not too large distance is reached. From the distance in front of the aircraft that I tried, it just cannot be heard at all, not even faintly. I guess this is a little disappointing but only a minor issue - likely the cutoff is there to keep performance up. Consider this issue "solved". And applause to the ED team for the rather cool implementation. The doppler shift is taken into account correctly. If you listen to the gun from a stationary observer, the gun sound gets doppler shifted correctly. If you fly in front of the aircraft, you hear the gun sound at normal pitch. The bullets sound more or less the same every time, as they travel at well over supersonic speeds even for moving observers. Really great stuff. toutenglisse: only saw your posting after writing this - thanks for taking a look! I guess though the remaining issues are only minor and there are more important real "bugs" for the team to go through. Will mark this as solved.

Hi, I always thought that speed of sound was modeled more or less correctly in DCS. When watching videos of F-16 strafing as filmed from the ground, it is noticeable that the bullets fly past the observer before the gun sound can be heard. Not too surprising. I just tested this out in DCS and to my surprise found that the sound arrives way too early. My setup: F-16 flying 432kn (222 m/s) and firing SAPHEI (PGU-28A?) at 6000ft (1830m) slant range. The bullets have a flight time of 2.4s, a little faster than public data available from the manufacturer webpage. (graphics modified from here to include speed of sound as well as measured and expected time of flight for bullets) The faster flight time might be entirely correct as the gun is moving at 222m/s in addition to firing ~1000m/s bullets. Very cool to see the good match. What is suprising though is that if you stand on the ground near the target, you can hear the gun sound even before the bullets impact the ground. It should actually arrive about three seconds later. Track and Tacview attached for reference. F16-guns-bullet speed.trk Tacview-20220411-223120-DCS-F16-guns-bullet speed.trk.zip.acmi

Thanks for that compilation of problems, Frederf. I thought it might just be me as not a lot of reports can be found in the F-16 forums and I thought that CCIP/CCRP are fully implemented. Maybe something got messed up at one of the last updates? I tried around a lot with the minimal test and found that most of the times the bombs release the moment I press WPN REL... happens in CCIP, CCRP and DTOS. Sometimes though the system seems to behave more "normal" and properly delay the release. The few times when the system behaved normally, strong direction inputs actually let to premature release, just like you mentioned. And post-designate CCIP does not correctly display steering information through displacing the ASL, even when the delay cue seems to work. Maybe the developers can take a look and report some status of what's working and what's not working at the moment.

Hi, I have problems with getting CCIP post-designate to work as intended. As far as I understand from the HAF -34 document for the F-16C/D Block 50, the CCIP bombing mode provides the time-delay cue if the actual impact point is below the hud. Once WPN REL is depressed, the FCC should provide both the correct timing for weapon release as well as azimuth steering error by displacing the steering line from the flight path marker. Originally, I thought my problem was that this CCIP "post-designate" just fails to provide azimuth steering, as the steering line stayed on the flight path marker after WPN REL even when maneuvering. I just ran a quick simple test with MK82 from 5000ft without wind and it seems like the bombs actually drop the moment WPN REL is depressed. Track is attached. Has anybody got this working correctly? I thought that in the past at least the time delay was computed correctly - although I am pretty sure that in the past I also never received any azimuth steering guidance post WPN REL. Thanks for looking into this! CCIP-MK82-short.trk