Naquaii

In what way does it not work? Not all HUD modes show the indicators for them and they're limited in range as well. Also, using PLM might stop them from working as well as it has a higher priority.

What we've identified as possible upgrades to add to an eventual F-14B(U) if we ever get enough data on them and feel it's worth the development time are (from the top of my head): the PTID, the Sparrowhawk HUD, the new navigational system with CDNU and EGI (ring-laser gyro), the DFCS (digital flight control-system) and better weapons and LANTIRN integration. (JDAMS would be included in this.) All of those apart from the DFCS are interdependent and rely on each other so makes sense to do as a whole package. Some of the parts would work on their own, like the PTID but with much reduced functionality. This package would also add in the RWR display again as the additional 1553 bus allows for integration of the AN/ALR-67. As it stands we're lacking a lot of information on primarily the PTID which makes it impossible in our view atm, and even if we got that information it's not a given. Personally I'd very much like to see it though!

Only PD, Pulse mode does not use the filters at all.

Yes. The reason for it not being a priority is that the use-case is something that's not modelled in DCS and we're not really sure that it adds that much anyway. If eventually added it would just be some targets giving really large returns and maxing out the amplifier and/or eclipsing other returns and in that case the RIO would need to turn off the PARAMP. The problem is that the DCS engine doesn't currently model RCS in that detail so it's not really possible to implement in a decent way. And in any case it's an odd thing that would occur seldom and the solution would be to just turn off the switch.

If this is implemented do not expect it to allow earlier detection of targets like that as like it says it was mainly used to allow the RIO to turn the PARAMP off if needed for strong returns at close range. At long range the PARAMP would be on anyway.

The Doppler filters are not a software thing. The doppler filter number and ranges depend on the actual electronics in the radar. The documentation we have is quite clear on the -1800 to 1800 knots range.

Is that when looking at the TID repeater or the actual TID and in multiplayer or singleplayer? There's a bug currently with a pending fix regarding the blinking of the TTI on the pilot repeater.

It should be the same, that might be an oversight or bug.

No, afaik its only function was with strobes and TCS tracks.

As it currently is we can't guide a missile in DCS on just a track in the radar, it needs to track on a real target. What we did to allow some of this functionality is that when a track is lost we compare the location of the held track to the real target and if those are close enough together we still guide the missile. If they're not we don't. This means that if the target is not within this box anymore it will look as if the missile just stopped guiding and if it is it will continue to guide. It's not optimal for sure but it's better than nothing and we'd be more than happy to model it in a more correct way if we can in the future. Optimally we would be able to guide the missile towards a spot in the sky that we can decide on and then tell the missile to go active and find the target on it's own. But that's not currently possible afaik.

Basically it's used when you have a track that is lost due to jamming but stilled tracked via a jamming strobe or the TCS. What the function does is it allows the RIO to correlate the strobe or TCS track with the hooked track to transfer it's information into the strobe/TCS track. That then allows the WCS to extrapolate the likely position of the target using the last known elevation, direction and speed combined with the angle rates of the jam strobe or TCS track. Not exactly but better than just a strobe. It was also possible to enter this mode directly from a TCS track or jam strobe without correlation but it required at least 15000 feet of separation or something like that and some qualified guesswork from the operator. This is not something that we're currently comitted to include as it is a lot of work for an advanced function that in most cases don't add that much. But I'm not the one to say no here, it might happen eventually.

Thing is, the technical stuff behind it isn't that advanced. The problem is that a lot, if not all, of the missing functionality depended on having an operator on a ship or an aircraft controlling it. That's not currently possible in DCS. If we had a GCI or AWACS operator position possible on a unit in DCS it would probably not be that hard to implement. As it is it would mean developing a whole nother AI to simulate that operator and that's not really within the scope of a single aircraft module. Developing Jester was not an overnight thing as I'm sure you understand! That said, a lot of this stuff is also true for Link 16 so if a fighter controller for that link ever happens in DCS there'll likely be a possibility of transfering that functionality over to Link 4. But far from certain.

According to the documentation we have this is correct. Adjustment of the aspect switch allows selection of +1800 to -1800 knots rate around own speed.

I think AIM-7 needs XMT while AIM-54 only needs STBY, i.e. not off. I don't think this is currently modelled.

Yeah, the AWG-9 and it's weapons weren't really designed to allow for missile launch with the radar in standby as the transmitter is needed for the missiles to know what frequencies to look for. There is however a marked difference between the AIM-7 and the AIM-54 in that the AIM-7 uses the actual signal to tune the receiver in the missile while the AIM-54 only needs this information for launches that use semi-active illumination afaik. So without the WCS set to XMT the AIM-7 wouldn't be able to track a target at all as it wouldn't know what to look for. Actually the WCS shouldn't even allow for launch in standby, if it does it's probably something that slipped us by and needs to be looked at. The AIM-54 on the other hand is still able to launch in the ACM active modes that aren't supported by the AWG-9. The only non-standard STT or TWS launches that exists for each missiles are: AIM-7: Flood (which is used in the absence of any STT-track) and radar slave to TCS mode. When you slave the radar to the TCS the radar still transmits like normal but is guided by the TCS in azimuth and elevation. This is mostly useful for keeping the radar on a track even with heavy jamming and the radar can still be locked to allow for range information. This also keeps the CW illuminator on the target so is usable for AIM-7 launches. The radar will still need to be active and the target will get a launch warning but you can at least have the radar in standby until you want to launch. This all should work except for that I don't think we have the functionality in yet for allowing the range lock with the radar while slaved to TCS. AIM-54: Pure maddog launch (go straight ahead and kill the first target found) and launch along TCS line of sight. When launched along the TCS line of sight the missile launches like a maddog shot but is told what azimuth and elevation to fly away at so directly after launch the missile will execute a turn to follow that line of sight. This should work currently and should not require the radar to be active. As for locking the TCS manually you'd need to have the slave switch set to INDEP or RDR or not having a STT track as that can interfer. Then you use half-action to control the sensor pointing and then full-action to initiate track. All acquisition modes require full-action, even the auto modes.

What's needed really is the 1A for the later F-14B(U). Would be nice if someone could get a hold of it but I suspect that a lot of the information regarding the AIM-54C will remain classified as well. Availability of the data is one thing however, implementation of it another. I can't really speak for Heatblur in this regard but what were talking about here, i.e. an F-14B(U) with the Sparrowhawk HUD, CDNU, EGI and PTID etc would still be a lot of work so not a given even if we would like to do it.

Not sure what was decided upon in that regard, I'd have to refer to Cobra or Ironmike.

Well, a lot of aircraft purposefully used/use blocks or equivalent that were quite specific. The Hornet and Viper blocks and lots seems to be set configurations while the airframes within a specific Tomcat block appears to have differed quite a lot from factory, seemingly by having mods being applied as available rather than waiting for a new block denominator.

There was a later upgrade that replaced the old mechanical gyro with a new ring laser gyro called EGI and a CDNU that interfaced it and the old navigational system, that also added a GPS.

This is the one I could find at short notice. There seems to be a duplication on the left side so 10 menus available (not 12) from here as far as I can tell, not sure if there were more, seem to remember that there were. But out of those 10 I've seen images of only the nav and sms menues. The normal tactical and navigational displays we kinda have as it's quite similar to the earlier F-14s (Not the TAC menu as that's something else). But there's still a lot to flesh out. And yes, this is the HSD repeat of the PTID, not the PTID itself but still applies. About the PTID model I think there only were one (which might ofc had upgrades over time) but which could be integrated differently. The first PTID installations were kinda just a drop in replacement which added no new functionalities apart from a bigger screen and moving some controls onto the OSD buttons. In contrast the latest model F-14B(U) seems to be quite different with the more advanced integration seeming to allow for much better LANTIRN functionality and Sparrowhawk integration as well as more advanced navigation programming. I think there also were intermediary versions that had some but not all of that. As with other Tomcat stuff it's really a jungle with a lot of different versions and modifications.

The GPS-antenna is needed for sure, I've never seen an integration schematic that doesn't explicitly state it being there. The issue with the PTID is that we're missing so much, from the top of my head it's something like 10 out of 12 menus that we don't have. And yeah, as far as the F-14D TID it's a different story. The F-14B(U) relied on the PTID for the 1553 bus afaik while the -D didn't.

Our intention is to have it removable on the USN -As but possible to carry it. The IRIAF -As won't as they never had them.

No-one can do that without going stark raving mad... If we've learned anything it's that no fleet aircraft looked like any other.

IIRC it also had to do with if it was newly produced -Ds or conversion -Ds.

Our intention is to have the Late -A and -B to be ALR-67 and ALQ-126 equipped and the early -A to be ALR-45/50 and ALQ-100 IIRC. When everything is finished externally that is. As for the LANTIRN it indeed used the same antenna as the CDNU upgrade if that was also present, otherwise the antenna was just for the LANTIRN. As for the LANTIRN with the fishbowl we always knew it was an experimental thing that did not see extended fleet usage but we are quite sure that's how it was tested at first even if it was later decided that it wasn't really good enough to display it and thus later relegated to PTID birds. So a loophole? Not necessarily, but the decision was between not including LANTIRN or including it in a version that did exist, if only very briefly. As for the TID in general it was in use right up until very late, there's even photos of a -D model with a fishbowl TID.