Jump to content

Blue Force Tracker/Tactical Internet (TI), Fire Support (FS), TACFIRE/ATHS, or other additional datalink types


Donglr

Recommended Posts

Hi gents,

 

in the latest video Wags says

Quote

To the right at B3 is the Battle Area Management, or BAM, selection. We’ll come back to this later when we add the flight datalink and the FCR.

The Situational Awareness, or SA, is the Blue Force Tracker overlay; a second datalink system that is not planned at this time due to sensitivity issues and lack of reference data.

But what does that mean? They add flight datalink, so I guess we can see other Apaches. Can we also share targets?

The second sentence I interpret that there will be no other aircraft (F18, F16,A10) visible on the TSD, no target sharing and not even displaying friendly units, like the green crosses in the A10?

Link to comment
Share on other sites

In the D model Apache in the chosen timeframe, there’s no Link 16 or SADL type datalink. So don’t expect to see other friendly flights similar to the systems in Hornet and Viper. The apparent lack of detail/documentation on the SA function means they won’t be modelling ground force ‘green crosses’ ala A10C either, which should be a SA thing.

What should be available is the sharing of FCR targets/symbols, sharing engagement  ‘Zones’, sharing waypoints, text messages and other simple stuff, purely between upto an 8 ship Apache flight. I don’t think there’s even a real-time wingman PP symbol or anything like that. 

Link to comment
Share on other sites

6 minutes ago, AvroLanc said:

 The apparent lack of detail/documentation on the SA function means they won’t be modelling ground force ‘green crosses’ ala A10C either, which should be a SA thing.

The Apache doesnt only show the EPLRS (which are the green crosses in the A-10) but it also uses Blue Force Tracker

  • Like 1
Link to comment
Share on other sites

As mentioned in the latest TSD video from Matt Wagner, the SA feature isnt planned. I think an approximation of the system would make a great addition the the Apache. As linked below it mentions, "Blue Force Tracker-1 (BFT-1) and Blue Force Tracker-2 (BFT2) are used by almost every ground and aviation vehicle in the US Army today." I think marking every friendly on the SA might be a good approximation of the system. In addition the document states, "Blue Force Tracking (BFT) describes a GPS-enabled system that provides military commanders and forces with location information of both friendly (blue) and hostile (red) forces." So I think adding enemies within LOS of friendly units with a lesser accuracy might be a fair implementation of the Blue Force Tracker network.
https://www.satelliteevolutiongroup.com/articles/blue-force.pdf

  • Like 2
Link to comment
Share on other sites

33 minutes ago, llOPPOTATOll said:

The Apache doesnt only show the EPLRS (which are the green crosses in the A-10) but it also uses Blue Force Tracker

Yep, and Wags has confirmed that this function isn’t coming. It’s apparently too sensitive and they don’t have the documentation. Please see Wag’s latest vid and comments. 

  • Like 1
Link to comment
Share on other sites

Just to clarify, our current apache module, as the airframe model reveals, lacks the hardware required for "direct" connection to the TI. (Blue force tracker), the SA Data button we are all talking here would enable the display of icons received from the TI.

In regards to other forms of datalinks, is up to ED decision and info availability.

Link to comment
Share on other sites

20 minutes ago, AvroLanc said:

Yep, and Wags has confirmed that this function isn’t coming. It’s apparently too sensitive and they don’t have the documentation. Please see Wag’s latest vid and comments. 

If it is a system already modeled in the A-10 II I don't see how modeling it is "sensitive" for the Apache, it isn't like people are looking under the hood of how the "real" thing works. And as I recall from past discussion data link was coming down the road, just not in early access. 

  • Like 3

"Now how do I land this thing?" *Sound of pages turning*

Link to comment
Share on other sites

21 minutes ago, Funkysak said:

If it is a system already modeled in the A-10 II I don't see how modeling it is "sensitive" for the Apache

Different aircraft, different branches could mean drastically different regulations. There's a ton of info out there for the Apache which they may not be able to legally utilize for the game. When it comes to datalink capabilities the A-10 is also greatly simplified, and the Hornet also has some issues with this, the MIDS setup isn't simulated and the whole interface to interact with ground forces (like VMF or the CAS page) is also missing due to alleged sensitivity.

Link to comment
Share on other sites

27 minutes ago, Funkysak said:

If it is a system already modeled in the A-10 II I don't see how modeling it is "sensitive" for the Apache, it isn't like people are looking under the hood of how the "real" thing works. And as I recall from past discussion data link was coming down the road, just not in early access. 

Well it’s not the same system as the A10C. It’s quite similar though. But I agree, the widely available docs do show how it should display etc. And that should be good enough for some kind of implementation, considering how simplified the datalinks for A10, Hornet and Viper already are.
 

As noted above, Apache has a few types of datalinks available, we’re getting the intraflight one, but not the Blue Force Tracker Situational Awareness type one. 


Edited by AvroLanc
Link to comment
Share on other sites

  • Wags changed the title to Blue Force Tracker

I would hope something could be implemented that is "close enough" to represent the capability, without revealing any State secrets or even modeling the entire network.  Sometimes, in a sim that is basically a game, good enough is good enough.  

  • Like 4

System: Intel Core i9-9900KF @ 5 Ghz, Z-390 Gaming X, 64Gb DDR4-3200, EVGA GeForce RTX 3090 FTW3, Dedicated SSD, HP Reverb G2, Winwing Orion & F-16EX

DCS Modules: A-10C II,  A/V-8B NA, Bf-109 K4, P-51D, P-47D, F/A-18C, F-14 A/B, F-16 CM, F-86F, JF-17, KA-50 Black Shark 2, UH-1H, Mosquito, AH-64D Longbow 

Terrains & Tech:  Caucasus, Persian Gulf, Normandy, Syria, Nevada, The Channel, Combined Arms, WWII Assets, Supercarrier

Link to comment
Share on other sites

5 hours ago, Mad Dog 762 said:

I would hope something could be implemented that is "close enough" to represent the capability…. Sometimes, in a sim that is basically a game, good enough is good enough.  

It’s funny to see this argument suddenly being brought out when it suits peoples agenda, i.e. to gain even more capability.

While at many other occasions people can‘t yell loud enough varying versions of „this is simulation, not a game.We don’t want gamey , arcady stuff in DCS bla bla etc“ 

 


Edited by Snappy
  • Like 4
Link to comment
Share on other sites

  • ED Team

Just to provide some context over what all these terms are within the Apache (some of it has been answered already, but trying to roll it all up into a one-stop shop):

TI/Tactical Internet is the term for how the Apache handles the BFT/Blue Force Tracker. SA/Situational Awareness is the TSD overlay that places BFT information on the TSD. BFT isn't a datalink per se, it's a network of the FBCB2 system. Think of it like this...FBCB2 is a datalink architecture. BFT is one of the networks it uses. The Apache is a device on the BFT network. An analogy would be cellular/mobile networks is a datalink architecture, T-mobile is an individual network among the cellular networks, and a Samsung smart phone is a device on the network. TI/SA could be called "apps" on that device. However, for all intents and purposes, the term "BFT" is used more universally because it is less of a mouthful than saying "FBCB2".

JVMF is a message format that can be sent among some datalink types. But just because two different datalink types use JVMF messages, that doesn't mean that those two datalinks can share such information. There is a lot more to this stuff than people realize.

EPLRS is like the BFT, in that it is a type of network, but not a datalink architecture in itself. An EPLRS-based device can't necessarily communicate with another EPLRS-based device simply because they are both EPLRS devices.  Likewise, just because the A-10C's (and some F-16's), have an EPLRS-based datalink called SADL, that doesn't mean that it can communicate with an Apache using an EPLRS-based datalink system. A ground unit equipped with a SADL terminal does not equate to an FBCB2-equipped unit. SADL and BFT are not similar at all, aside from the fact they populate ground force icons/symbols equipped with the appropriate terminals. SADL is more akin to Link16 than it is to FBCB2/BFT.

All this stuff is apples and oranges. And the only datalink system that currently exists in DCS that permits multiple modules to communicate with each other is Link16, which no AH-64D in existence has.

[This is all open-source information, I'm just trying to properly sort and separate the various terms to avoid the propagation of myths and misconceptions]


Edited by Raptor9
  • Like 5
  • Thanks 4

Afterburners are for wussies...hang around the battlefield and dodge tracers like a man.
DCS Rotor-Head

Link to comment
Share on other sites

So what kind of capability could we expect from the Ah-64D, provided it is properly simulated? The ability to put target symbols on the map and send them to the other aircraft in the company? Anything more exiting than that? 

I am quite happy if I all I would be able to, is to share targets with my co-players, and in a more convenient, and less roundabout way than in the Ka-50. Far too many keypresses and moving about in the cockpit for my taste, but on the other hand, when properly used, it is really a nice thing to have when playing co-op.

Link to comment
Share on other sites

  • ED Team
On 12/9/2021 at 4:59 AM, doedkoett said:

So what kind of capability could we expect from the Ah-64D, provided it is properly simulated? The ability to put target symbols on the map and send them to the other aircraft in the company?

I am quite happy if I all I would be able to, is to share targets with my co-players, and in a more convenient, and less roundabout way than in the Ka-50.

If modeled correctly, it should be very similar to how the Ka-50 datalink functions, minus the requirement to reset the targeting system between storing and sending. Plus the Apache should have a lot more variety of point types available, and a lot more slots than the 20 in the PVTz-800. Plus the sharing of PFZs like in Janes.

We'll have to wait and see I suppose to how they plan on fleshing it all out.

  • Like 3
  • Thanks 1

Afterburners are for wussies...hang around the battlefield and dodge tracers like a man.
DCS Rotor-Head

Link to comment
Share on other sites

2 hours ago, Raptor9 said:

Just to provide some context over what all these terms are within the Apache (some of it has been answered already, but trying to roll it all up into a one-stop shop):

TI/Tactical Internet is the term for how the Apache handles the BFT/Blue Force Tracker. SA/Situational Awareness is the TSD overlay that places BFT information on the TSD. BFT isn't a datalink per se, it's a network of the FBCB2 system. Think of it like this...FBCB2 is a datalink architecture. BFT is one of the networks it uses. The Apache is a device on the BFT network. An analogy would be cellular/mobile networks is a datalink architecture, T-mobile is an individual network among the cellular networks, and a Samsung smart phone is a device on the network. TI/SA could be called "apps" on that device. However, for all intents and purposes, the term "BFT" is used more universally because it is less of a mouthful than saying "FBCB2".

JVMF is a message format that can be sent among some datalink types. But just because two different datalink types use JVMF messages, that doesn't mean that those two datalinks can share such information. There is a lot more to this stuff than people realize.

EPLRS is like the BFT, in that it is a type of network, but not a datalink architecture in itself. An EPLRS-based device can't necessarily communicate with another EPLRS-based device simply because they are both EPLRS devices.  Likewise, just because the A-10C's (and some F-16's), have an EPLRS-based datalink called SADL, that doesn't mean that it can communicate with an Apache using an EPLRS-based datalink system. A ground unit equipped with a SADL terminal does not equate to an FBCB2-equipped unit. SADL and BFT are not similar at all, aside from the fact they populate ground force icons/symbols equipped with the appropriate terminals. SADL is more akin to Link16 than it is to FBCB2/BFT.

All this stuff is apples and oranges. And the only datalink system that currently exists in DCS that permits multiple modules to communicate with each other is Link16, which no AH-64D in existence has.

[This is all open-source information, I'm just trying to properly sort and separate the various terms to avoid the propagation of myths and misconceptions]

Awesome comment! So far this thread was more confusing than helpful, but this made it all much clearer :thumbup:

  • Like 3

Intel i7-12700K @ 8x5GHz+4x3.8GHz + 32 GB DDR5 RAM + Nvidia Geforce RTX 2080 (8 GB VRAM) + M.2 SSD + Windows 10 64Bit

 

DCS Panavia Tornado (IDS) really needs to be a thing!

 

Tornado3 small.jpg

Link to comment
Share on other sites

The apache's data link that we will get between Apaches (and hopefully to some extent the Kiowa also) will be superb. Zones of fire can be defined quickly and efficiently and handed off to other apaches to ensure an efficient and fast large scale kill rate in the shortest time possible.. it will be superb.

 

Bluefor identification will need slow and low time to fully evaluate the battlefield. Superb AI ground force comms via Vaicom/voiceattack would be awesome for choppers.... fast movers too I guess.

 

.

 

 


Edited by Rogue Trooper
  • Like 1

HP G2 Reverb, Windows 10 VR settings: IPD is 64.5mm, High image quality, G2 reset to 60Hz refresh rate as standard. OpenXR user, Open XR tool kit disabled. Open XR was a massive upgrade for me.

DCS: Pixel Density 1.0, Forced IPD at 55 (perceived world size), 0 X MSAA, 0 X SSAA. My real IPD is 64.5mm. Prescription VROptition lenses installed. VR Driver system: I9-9900KS 5Ghz CPU. XI Hero motherboard and RTX 3090 graphics card, 64 gigs Ram, No OC at the mo. MT user  (2 - 5 fps gain). DCS run at 60Hz.

Vaicom user. Thrustmaster warthog user. MFG pedals with damper upgrade.... and what an upgrade! Total controls Apache MPDs set to virtual Reality height with brail enhancements to ensure 100% button activation in VR.. Simshaker Jet Pro vibration seat.. Uses data from DCS not sound.... you know when you are dropping into VRS with this bad boy.

Link to comment
Share on other sites

11 hours ago, Snappy said:

It’s funny to see this argument suddenly being brought out when it suits peoples agenda, i.e. to gain even more capability.

While at many other occasions people can‘t yell loud enough varying versions of „this is simulation, not a game.We don’t want gamey , arcady stuff in DCS bla bla etc“ 

 

 

 

  You are referencing two scenarios that can (and often do) have very, very different underlying context. In a lot of cases, controversies about realism versus "gamey arcade stuff" in DCS end up coming down to things like what pylons HARM's will work from or what specific weapons/systems are going to be implemented outside of the version of the aircraft being modeled. In those cases, ED will always skew towards the more plausible, more authentic/realistic choice when it is in their power to do so. This isn't always going to please everyone but ED has been pretty open about how that decision making process goes and why things happen the way they do. Even the now rather well-worn complaints about the Blackshark 3 additions are not really difficult to understand if one actually wants to understand them. 

 What we are talking about here (adding some Blue Force Tracker functionality even if different enough to not get ED in hot water) isn't really different from how ED handles other major aspects of the sim. A similar arrangement exists with radar warning receivers, countermeasures, electronic countermeasures, various weapons, IFF, datalink details, and a number of other important systems. There are things that ED will always have to (for lack of a better term) half implement in order to get the basic functionality into the sim without getting into some material that can get them in a lot of trouble. 

  I don't blame ED for not wanting to touch the whole Blue Force Tracker thing but I also would totally understand if they were to decide to go with a relatively basic implementation of it that captures the basic functions without getting into any serious detail. This is just the way this stuff has to go sometimes and we should be okay with this by now. 

  • Like 7
  • Thanks 1
Link to comment
Share on other sites

In the TSD video, Wags says that the SA page, which uses a secondary datalink to show blue force units (and red force units that were spotted and referenced) is not planned due to sensitivity issues and lack of references.

Now, to me it seems like a big deal. It looks like a very useful tool on the battlefield (it's literally the "situation awareness" page...). If possible, it would be a way better and more realistic solution to do something "close enough", even if icons and options are not like the real deal. Automatically showing blue forces and red forces spotted by them on the SA page would give relatively similar capabilities.

Link to comment
Share on other sites

21 minutes ago, Mad_Shell said:

In the TSD video, Wags says that the SA page, which uses a secondary datalink to show blue force units (and red force units that were spotted and referenced) is not planned due to sensitivity issues and lack of references.

Now, to me it seems like a big deal. It looks like a very useful tool on the battlefield (it's literally the "situation awareness" page...). If possible, it would be a way better and more realistic solution to do something "close enough", even if icons and options are not like the real deal. Automatically showing blue forces and red forces spotted by them on the SA page would give relatively similar capabilities.

This has already been discussed here:

In my personal opinion ED should stay away from fantasy implementations. 

  • Like 1
Link to comment
Share on other sites

7 minutes ago, Snappy said:

This has already been discussed here:

In my personal opinion ED should stay away from fantasy implementations. 

Thx, I checked the general forum but forgot to check the wishlist section lol. 

As for fantasy implementation, wouldn't a "believable" implementation be more realistic than no implementation at all? Plenty of things in DCS are not true to the real deal. For example all the electronic warfare/radars aspects are almost fantasy compared to real life. Would you prefere ED to not implement those aspect at all rather than what we have now?

Link to comment
Share on other sites

Yes, but the problem with that is , who defines " believable"? Just because certain aspects of DCS are not the real deal, does that mean anything else goes?  By that logic, (the russian law thing notwithstanding) you could also argue for the implementation of  modern red force jet. Oh, well most systems and fm data is classified and/or we dont have access to it . However lets do our best guestimate implementation based on the information we have..
Or would you rather not have a modern redfor jet? There it gets highly subjective.. 

Its not like you dont have enough capability in the AH-64D without it.

 

 


Edited by Snappy
  • Like 1
Link to comment
Share on other sites

1 minute ago, Snappy said:

Yes, but the problem with that is , where does "believable" stop?Just because certain aspects of DCS are not the real deal, does that mean anything else goes?  By that logic, (the russian law thing notwithstanding) you could also argue for the implementation of  modern red force jet. Oh, well most systems and fm data is classified and/or we dont have access to it . However lets do our best guestimate implementation..
Or would you rather not have a modern redfor jet? There it gets highly subjective..

There is a difference between modelling a whole redfor jet based on "believable" systems and fm (which is taking things way too far) and modelling a few classified systems from an aircraft which is otherwise modelled very realistically (which imo should be done if it's to end up with an aircraft closer to the real deal than if the system was not modelled at all).

  • Like 2
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...