Beamscanner

Is the SPO-10 supposed to provide PRF audio? The OPs link mentioned "sound signal"

idk.. but its not an only f-35 thing

All the issues below are interrelated. As previously posted, this is not about low update rates for the sensors. This is about the TD box and RWR symbols not tracking a position as I move my aircraft. Even if using a low update rate sensor (like radar in LTWS), the HUD TD box should continue to follow the last known position. Please read below. Tracks are attached. Radar TD Box issue: HARM TD Box issue: RWR Symbol issue: Regardless of track updates from the sensor, the display for the: Radar TD Box should continue to track the last known target position in azimuth, elevation and range. HARM TD Box should continue to track the last known target position in azimuth and elevation. RWR should continue to track the last known position in azimuth. i.e. My own maneuvers should not move the TD Box off the target. IMO, these issues make the Radar, HARM and RWR 'feel' choppy and scatters the target data. I believe fixing this would lead to a smoother, more realistic and enjoyable experience using these systems. Not just on this aircraft but on other upcoming modules as well. RadarHUD.trk HARMandRWR.trk

You dont understand what were saying. We're not talking about the radar or radar tracks. Were talking about the HUD and RWR symbols. The displayed symbols should move smoothly across their given display if I turn the aircraft. ie even though my Radar track or RWR only updates once in awhile, the HUD/RWR symbol itself should move continuous (or near continuously) because it is associated with a azimuth (and elevation for the TD box) and not a relative clock position. Meaning the TD box should be able to move if the radar track hasnt updated yet. The TD box should smoothly to follow that last known position in azimuth and elevation. Right now, it gets locked in position relative to the display window. Meaning that if the TD box is in the upper right corner of the HUD, and i make a hard turn, the TD box will still be in the upper right corner of the HUD. Same is true for the RWR.

I agree. The HUD TD box should follow the last known position of the target. So if I turn left the TD box should move right, following the last known position even if it’s old. Instead, it currently follows an X and Y position on the HUD. Meaning ownship movements make the TD box lie to the pilot about the targets last known position. Also, this isn’t just for LTWS, it occurs with the HARM as well. And probably anything else added with a low update rate. EDIT: After doing some test flights, I've come to realize that the RWR symbols have the same issue. Instead of associating the RWR symbol to a azimuth relative to the aircraft, it associates the RWR symbol to a clock position. Thus, when you turn the RWR symbol doesnt continue to follow the bearing. Example: - My heading: 270; Nails 12 oclock on RWR. Thus, the enemy radar is bearing 270 from my aircraft. - Hard bank left. My new heading is 180. Nails is still 12 oclock. Thus, my RWR is trying to lie to me and tell me the enemy radar is 180 from me. It eventually corrects itself, but only after re-detecting the emitter. Instead, what it should be doing is associating the RWR symbol to a bearing of 270 and not a relative clock position. Thus, when I turn the RWR symbol follows the 270 position on the EW page/ADU. Considering that the RWR data is sent to the mission computer and used with other sensors and the HARM, it makes sense that it would follow a bearing and not a relative clock position.

I think OP is confused. The 3.3 beam gets overlapped in its bar to bar raster scan. (About halfway) meaning a 2 bar scan would only cover 4.95 degrees in elevation

real life is on by default

[21:28]

Could a member of the ED team please respond. I think most of us agree that incorrect RWR logic should not be filed under "wish list".

The HEATBLUR ALR-67 is leaps and bounds more accurate than any other RWR in DCS. OP doesn't understand all the factors at play. It is very realistic for an RWR to trip from a SAM 40nm away. Even if its only receiving sidelobe energy. The RWR is dumb, and can only make assumptions based on what it measures. Here are some things to consider: - All antennas have sidelobes. Radar antennas, RWR antennas, all of them. No antenna is perfect, they all leak energy in unintended directions. - RF energy is light. Light scatters, reflects, diffracts, refracts, etc. - SAM radars emit very powerful signals so they can ensure target detection. Especially old SAMs - RWRs are designed to detect extremely weak signals so they can inform the pilot to emitters even far away. - RWRs have a benefit over radar receivers in that the light has only traveled one way, where as radar receivers have to detect light that traveled out and back in (two way path). Thus, compared to a radar's receiver, and RWR will more easily detect signals at range. The DCS RWRs (besides the HEATBLUR ones) do not simulate noise, amplitude comparison (AOA) and have unrealistic blind spots. They use relatively simple logic like 'When SAM XXX locks Client XXX, trigger RWR detection' A real RWR doesn't know it been locked on to. It listens to a very wide range of frequencies, detects and identifies the signal, compares the amplitude (or phase) between it's antennas, and outputs the info to the pilot. At no time does the SAM communicate who its intended target is (well besides in a secure datalink to it's allies). Enemy SAMs are non-cooperative. Thus, whether or not you're the one being targeted is unknown.

angle only tracks (ie, HARM, ATFLIR, RWR) MSI is not just LINK 16 You're correct. Just looked back into the manual (A1-F18AC-742-100, chapter 14 page 5) I must had incorrectly read "VSRWS" (a submode of RWS) as Velocity Search RWS, but looking back its "vector scan range while search".

Select LTWS from the data sub-menu first

VS is actually a sub-mode of RWS in the Hornet. And yes, MSI works in VS/RWS/TWS/STT MSI shows SURVL, PPLI, off-board F/F, RWR, HARM, and ATFLIR tracks. The ownship radar tracks, as seen currently on the SA page, are only shown via LTWS/TWS/STT logic

Here is a photo of a "29" indication on a F/A-18 in air to ground mode. Being that he isn't reacting in this case, its fair to assume there isn't a 'lock on'. Yet the "29" is still inside the "lethal" ring (based on the dashed line). Meaning that: - Lethal Ring does not equal 'Lock on'. - By process of elimination, Lethal Ring must mean 1. 'emitters that could harm you, but are not currently trying to do so' 2. 'emitters that could harm you, but are not in range to do so' 3. 'both #1 and #2. Same as Heatblur F-14 documentation'

I did. My post was pushed into this thread

I think any resolution above 1080 vertical pixels (y axis) is causing problems. Changing from 2160 to 1080 (y axis) fixed it for me. And everyone with side by side displays experiencing problems also have vertical resolutions above 1080 pixels.

I fixed mine by switching to a side by side setup. no DDI or AMPCD blur, and no mods altering the symbol stroke. Our tests clearly show a change in blur when changing monitor configuration. It very well could be that the vertical resolution must not go beyond 1080 pixels. (ie the exported DDI symbols are somehow tied to a scale related to 1080 pixels)

RWR threat ring logic Current threat ring logic in DCS F/A-18C: ---------------------------------------------------- Non-lethal = anything not locked on to you Lethal = anything locked on to you Critical = anything firing a missile at you ---------------------------------------------------- The logic above is not accurate to the ALR-67. The device already has specific ques to indicate a 'lock on' (lower half circle) and a missile launch (flashing symbol + azimuth line). The rings themselves indicate: ---------------------------------------------------- Non-lethal = threat systems deemed outside lethal range of ownship or any non-threat system (ie poses no threat to ownship). Lethal = threat systems deemed within lethal range of own aircraft but not actively tracking or engaging it. (ie no lock on or missile fire) Critical = imminent threat to ownship. Either a 'Lock on" / STT or a missile launch. ---------------------------------------------------- This is the same logic as the ALR-67 on the F-14B/D. The only difference would be threat ring placement based on time period.

"Common_page_defs.lua" seems promising. I tried changing *GetScale() to *GetScale()/2 since my dual monitor setup doubles my vertical pixel count. (2160 instead of 1080) All it did was make the font smaller. Its still blurry and unreadable. I still think "Common_page_defs.lua", or even "symbology_defs.lua" which it references, are great places to keep looking.

Excellent test! So to clarify: - No issue exists when using a side by side monitor setup. - DDI export is extremely blurred while using a top and bottom monitor setup. - DDI export is slightly blurred while using a top display and half of the bottom monitor. This should really help ED isolate the issue. Lets just hope someone at ED uses a vertical monitor setup so they can test this. In the mean time, im going to look through some of the lua files to see where the DDI symbols reference the screen x/y pixels.

APG-82 is replacing APG-70 https://www.raytheon.com/capabilities/products/apg82v1

I have a feeling that the problem is related to a ratio of the the 'X vs Y' ratio in the code. ie instead of something along the lines as 'DDI_symbols = X number / Y number' its 'DDI_symbols = Text / Text' (this is just an example, not a real line of code) I believe this because we see so many differences based on user resolution and monitor placement. I think the DDI symbols and text are being stretched based on the symbol size being some ratio of some video format.

No its not. I have two vertical 1080P displays and get this as well

Please do not call this a "fix".. its not a fix if it ruins the in game displays.. I use this modification, but now I cannot read my RWR or JHMCS. A fix from ED is required. This issue has been reported many times before. https://forums.eagle.ru/showthread.php?p=3631456#post3631456