[REPORTED] RWR not showing locked radars in Search mode - Page 8 - ED Forums
 


Notices

Reply
 
Thread Tools Display Modes
Old 08-10-2018, 02:17 AM   #71
Rex854Warrior
Member
 
Join Date: Nov 2016
Location: France
Posts: 361
Default

Quote:
Originally Posted by lunaticfringe View Post
Might help if you knew how NATOPS are written. Would make your argument look ridiculous, but it would keep you from continuing to make it.

"Squadrons" don't write NATOPS; program offices do. Offices that deal directly with the manufacturers and contractors who are designing hardware to Navy specification, and specify updated requirements to those suppliers as they come to pass. The authoring is coordinated with test and acceptance crews assigned to those offices who confer with those writing the technical publications that the details are exact, with multiple sets of eyes confirming the material every step of the way.

Your belief that these documents are authored by end users is likely only predicated on the understanding that updates can be suggested from the Fleet up. Fleet-side corrections are generally through Safety Officers for operational issues- not just some LT that got told to write up the handling of a section.

Corrections, which are intended to be distributed to all commands that deal with a given type as quickly as possible, every individual in the chain- from the Captain in the respective office at NAVAIR, to the authors, the test pilots, and the fleet-side representatives who are part of the annual board review of the document, sign off. Even in the event of a safety of flight update, most of that chain is still reviewing the material- and in most instances, testing it directly, prior to sign off and release to the respective units.

As such, when you state as a matter of opinion that the end user "squadrons" who are writing these documents are wrong, you're not simply incorrect on the basis of their production, but are stating that a long series of SMEs- every one of them who has direct professional experience with the hardware, software, and the operational requirements in question for the material they're responsible for, are full of it, because of uncorroborated opinion.

Following your recent Dunning-Kruger episode over the functionality of the F/A-18C's RWR having changed at least twice over its lifetime, I wouldn't exactly suggest that is a position of strength from which to operate. There is a world of difference between knowing how the radar equation works, how received power is interpreted by an analog system for which you have documentation or a video, and how a piece of software-driven hardware- which is coded for a specific role, and an operational environment you may or may not be considering (and may ultimately be the underlying cause for argument in this specific case), works.

Until you can provide later dated documentation for the software load in the F-5N versus that from the material Belsimtek worked from, you're demands are unsubstantiated. Doesn't matter how you feel on the matter- those feelings aren't supported by fact, but instead how you think the system should work as represented in this particular application of the type.

And that just isn't enough to be making demands without material support more substantial than a YouTube clip here, or an unrelated picture there.
Yeah you would have gotten more if you didn't come by after the 1.16 wipe, there was an official manual about the Swiss version of the same RWR, which proved that the tones are not realistic, and alot more, the interesting posts were removed from this thread, also ED has a single piece of document that says the functionality is as it is in game, the YouTube clip shows otherwise, so does a video on the F-4E RWR training video, and also a piece of documentation about the B-52's RWR showing that the search button is just used a declutter, to remove the "S" spike, not a hidding vital information to the pilot when engaged button, on top of that use your brain, can you think OF ANY reason why a button, not on the hotas, that deteriorates situational awareness by removing all emitting radars except the ones tracking you when engaged (you could literally turn into another ennemy while defending) and lastly when in search mode, hides radars tracking you ??? Add that and a flawed tone logic and you get a misleading piece of equipment.

EDIT : I'm sure Beamscanner will correct me and detail what I've said, without manuals because posting them now is forbidden, so much time wasted.
__________________


http://veaf.org/fr/

Last edited by Rex854Warrior; 08-10-2018 at 02:25 AM.
Rex854Warrior is offline   Reply With Quote
Old 08-10-2018, 02:26 AM   #72
lunaticfringe
Senior Member
 
lunaticfringe's Avatar
 
Join Date: Sep 2012
Posts: 1,010
Default

Quote:
Originally Posted by Rex854Warrior View Post
Add that and a flawed tone logic and you get a misleading piece of equipment.
No, you don't. You get a piece of equipment that has been programmed to operate in a specific environment, for a very specific purpose, and the documents they worked from represent that specific nature.

So as I've said previously- document later, or document a different implementation. But move beyond saying that the SMEs that authored the manuals Belsimtek worked from were wrong, because they aren't.
lunaticfringe is offline   Reply With Quote
Old 08-10-2018, 02:45 AM   #73
Rex854Warrior
Member
 
Join Date: Nov 2016
Location: France
Posts: 361
Default

Quote:
Originally Posted by lunaticfringe View Post
No, you don't. You get a piece of equipment that has been programmed to operate in a specific environment, for a very specific purpose, and the documents they worked from represent that specific nature.
I'd very much like to know what that environment was, that wasn't the same for the B-52H operating at the same time and I think we had a document describing how the search button works on the B-52H (exact same RWR), which showed again that there is a problem.

Quote:
Originally Posted by lunaticfringe View Post
But move beyond saying that the SMEs that authored the manuals Belsimtek worked from were wrong, because they aren't.
Well I don't think the data they have is wrong, I think it has been misinterpreted, because in a way, the switch we have now is a declutter, just everything instead of just "S" spikes. And you could prove us that the current logic is correct, we've got plenty of data, alot more then what belsimtek showed and talked about, if you get something that's undeniably a proof that the AN/ALR-46 or enough data to prove us wrong then we'll shut up.

P.S. : Also Belsimtek might not have had good information on the RWR, the activity and launch lights don't work at all, could indicate that.
__________________


http://veaf.org/fr/
Rex854Warrior is offline   Reply With Quote
Old 08-10-2018, 02:52 AM   #74
lunaticfringe
Senior Member
 
lunaticfringe's Avatar
 
Join Date: Sep 2012
Posts: 1,010
Default

Quote:
Originally Posted by Rex854Warrior View Post
I'd very much like to know what that environment was, that wasn't the same for the B-52H operating at the same time and I think we had a document describing how the search button works on the B-52H (exact same RWR), which showed again that there is a problem.
Ask yourself a question:

What doesn't a USN/USMC F-5E/F/N do that a B-52H, or any other configuration of the F-5, does?

Then ask yourself the reciprocal question:

What does the USN/USMC F-5E/F/N do that a B-52H, or any other configuration of the F-5, don't do?

It spends its days doing something very specific- and its software loads are going to be optimized for that.

Last edited by lunaticfringe; 08-10-2018 at 02:54 AM.
lunaticfringe is offline   Reply With Quote
Old 08-10-2018, 03:14 AM   #75
Rex854Warrior
Member
 
Join Date: Nov 2016
Location: France
Posts: 361
Default

Quote:
Originally Posted by lunaticfringe View Post
Ask yourself a question:

What doesn't a USN/USMC F-5E/F/N do that a B-52H, or any other configuration of the F-5, does?

Then ask yourself the reciprocal question:

What does the USN/USMC F-5E/F/N do that a B-52H, or any other configuration of the F-5, don't do?

It spends its days doing something very specific- and its software loads are going to be optimized for that.
What is a RWR supposed to do ? Warn from potentiel threats and give proper situational awareness to the pilot about what is emitting around his aircraft, you are engaged by an SA-2, you set search mode off by releasing the stick while a missile is flying at you and pressing the button because like this you see where from and what is launching at you isn't that great ? You break left and start notching the SAM, suddenly you hear the new spike tone, probably no big deal right and anyways you're evading so no time to press the button and since the tones aren't correct, you won't know when the missile has been defended because the tones only play right after lock or right after launch. You've defended the SAM so you press the button again and you have another SA-2 in front of you that you have been flying towards for the last minute with full throttles. You might say that you could have gone back in your lines, and you could have certainly, but with the way the RWR should work, at least how the data we found says, you wouldn't have this problem, it would have warned you, if shit goes down, how the hell do you expect this search button to help, the F-5 is an interceptor/fighter, at that time airborne radars were just starting to get effective. In a dogfight, you hear a tone, you might not have any idea where or what is shooting at you, I'll repeat my question :

What environment was this logic made for ?
__________________


http://veaf.org/fr/

Last edited by Rex854Warrior; 08-10-2018 at 03:37 AM.
Rex854Warrior is offline   Reply With Quote
Old 08-10-2018, 03:18 AM   #76
NineLine
Community Manager
 
NineLine's Avatar
 
Join Date: Feb 2011
Location: BC, Canada
Posts: 22,176
Default

Guys, this is a bug reporting thread, report what is wrong, and data from the game about what is happening or not. This isn't a thread to debate on how things should work or to argue with each other.

It's been reported, and ED is looking at what to do to fix it.
__________________
Nick Grey - "I have had the privilege of flying most marks of Spit, the I, V, IX, XIV, XIX and enjoyed working with Eagle to make this simulation of the IX the 'mutt's nuts'."
Artist formerly known as SiThSpAwN
Forum RulesForum Rules Guidelines
ED Facebook PageED YouTube PageWags YouTubeMy YouTube • My Discord - NineLine #0440
**How to Report a Bug**
NineLine is offline   Reply With Quote
Old 08-14-2018, 07:30 PM   #77
Beamscanner
Member
 
Beamscanner's Avatar
 
Join Date: Jul 2015
Location: tatooine
Posts: 490
Default

Quote:
Originally Posted by lunaticfringe View Post
Might help if you knew how NATOPS are written. Would make your argument look ridiculous, but it would keep you from continuing to make it.

"Squadrons" don't write NATOPS; program offices do. Offices that deal directly with the manufacturers and contractors who are designing hardware to Navy specification, and specify updated requirements to those suppliers as they come to pass. The authoring is coordinated with test and acceptance crews assigned to those offices who confer with those writing the technical publications that the details are exact, with multiple sets of eyes confirming the material every step of the way.

Your belief that these documents are authored by end users is likely only predicated on the understanding that updates can be suggested from the Fleet up. Fleet-side corrections are generally through Safety Officers for operational issues- not just some LT that got told to write up the handling of a section.

Corrections, which are intended to be distributed to all commands that deal with a given type as quickly as possible, every individual in the chain- from the Captain in the respective office at NAVAIR, to the authors, the test pilots, and the fleet-side representatives who are part of the annual board review of the document, sign off. Even in the event of a safety of flight update, most of that chain is still reviewing the material- and in most instances, testing it directly, prior to sign off and release to the respective units.

As such, when you state as a matter of opinion that the end user "squadrons" who are writing these documents are wrong, you're not simply incorrect on the basis of their production, but are stating that a long series of SMEs- every one of them who has direct professional experience with the hardware, software, and the operational requirements in question for the material they're responsible for, are full of it, because of uncorroborated opinion.
1. Small communities write their own NATOPS and send them up to NAVAIR to be approved. The F-5N community is very small.

2. The NATOPS is not a good source for detailed descriptions of tactical systems like the RWR. Especially when the squadron doesn't even have an RWR.

Quote:
Originally Posted by lunaticfringe View Post
Following your recent Dunning-Kruger episode over the functionality of the F/A-18C's RWR having changed at least twice over its lifetime, I wouldn't exactly suggest that is a position of strength from which to operate. There is a world of difference between knowing how the radar equation works, how received power is interpreted by an analog system for which you have documentation or a video, and how a piece of software-driven hardware- which is coded for a specific role, and an operational environment you may or may not be considering (and may ultimately be the underlying cause for argument in this specific case), works.
3. You're suggesting I'm an idiot because I came forth with documentation on a system that showed it work contrary to the DCS simulation?

4. I work with digital and analog EW systems so I understand the differences..

5. Instructor Pilots who write the NATOPS don't have the luxury of being EW experts.

Quote:
Originally Posted by lunaticfringe View Post
Until you can provide later dated documentation for the software load in the F-5N versus that from the material Belsimtek worked from, you're demands are unsubstantiated. Doesn't matter how you feel on the matter- those feelings aren't supported by fact, but instead how you think the system should work as represented in this particular application of the type.

And that just isn't enough to be making demands without material support more substantial than a YouTube clip here, or an unrelated picture there.
6. Documentation on the ALR-87 istelf (besides the NATOPS) cannot be found ATM. However, I've provided much documentation on the ALR-46 which the ALR-87 is derived from. Note how the ALR-46 document is many pages long, while the NATOPS has but half a page worth of text covering the ALR-87. Also, nothing beats video evidence

At the end of the day, if you think that the NATOPS description of the ALR-87 isn't missing anything, then you'd have to believe that the ALR-87 has no lock tone (PRF based or synthetic)...


Truth is, older RWRs didn't need synthetic lock tones because older fire control radars used lower PRFs (audible frequencies, usually between 600-3000Hz) and a mechanical antenna that stared at the target when locked on..

audible tone (low PRF) + steady tone (staring antenna) = natural lock tone (unique to each radars PRF)



I'm willing to bet that the synthetic tones were added to things that system couldn't produce naturally.

1. Missile Launch - Most old school Fire Control Radars used CW illumination for guidance. CW signals produce no tone, and thus cannot be heard.

2. New Guy audio - A pilot may not recognize a new PRF tone as being much different from the others. Especially if its a duplicate emitter (ie two MIG-21s). Thus a synthetic tone informs the pilot of a new contact.

Last edited by Beamscanner; 08-14-2018 at 10:05 PM.
Beamscanner is offline   Reply With Quote
Old 08-17-2018, 02:06 PM   #78
al531246
Member
 
al531246's Avatar
 
Join Date: Jun 2015
Location: North Wales, UK
Posts: 299
Default

Quote:
Originally Posted by lunaticfringe View Post
Ask yourself a question:

What does the USN/USMC F-5E/F/N do that a B-52H, or any other configuration of the F-5, don't do?

It spends its days doing something very specific- and its software loads are going to be optimized for that.
Dude, it's quite obvious you're out of your depth here.

There exists a multitude of documents, videos, images and books all confirming what we believe to be true, that the simulation within DCS is incorrect. A few were posted in this thread but removed under rule 1.16. You haven't cited a single source for your hypothesis and you will struggle to ever find one.
__________________
[spoiler=PC SPECS]
Intel i5-3570k @3.40GHz
EVGA GTX 970 4GB
Windows 10
Asus P8H61-MX MoBo
8GB RAM
250 GB Samsung 850 SSD
2TB Seagate SSHD
Some cool LED fans that light up
[/spoiler]
al531246 is offline   Reply With Quote
Old 08-17-2018, 02:48 PM   #79
nessuno0505
Member
 
Join Date: Jul 2017
Location: Italy
Posts: 464
Default

Moreover, NineLine has said it's reported and will be fixed, so ED itself is convinced it's a bug. This puts and end to the discussion.
nessuno0505 is offline   Reply With Quote
Old 08-29-2018, 09:51 PM   #80
nessuno0505
Member
 
Join Date: Jul 2017
Location: Italy
Posts: 464
Default

Is It fixed in the last open beta?
nessuno0505 is offline   Reply With Quote
Reply

Tags
bug, rwr

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT. The time now is 06:13 AM. vBulletin Skin by ForumMonkeys. Powered by vBulletin®.
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.