DCS Gaming

Bullseye in any module – A simple Spider Card

The bullseye is a ubiquitous method of referencing positions and contacts, easing navigation and other purposes. In DCS, it's typically used to coordinate aeroplanes and provide situational awareness.
This article explains the creation of my simple Spider Card, its usage, and other definitely uncommon tests.

Video

Download

The Spider Card, both for OpenKneeboard and the in-game DCS kneeboard are available for download here.


Contrary to BRAA and formats that use single aircraft as references, in DCS the bullseye is standard reference method across the mission or subset of packages, flights and aircraft.
If you are still getting familiar with the differences between bullseye, BRAA, and fighter-based geometry, I suggest checking Chapter III of the Intercept Geometry 2023 study, which explains these topics.

As the Phantom II gets closer and after a few discussions with SMEs and friends, I realised I had never made a spider card that suited my needs. More correctly, I have never felt the need to have one.
In the F-14 Tomcat, we bastardise the navgrid to work as a poor man’s bullseye reference since we do not have the correct bullseye page or the PTID. Modern-era modules have instead embedded bullseye support in their avionics.

NOTE
I am considering a zero magvar situation in this discussion for simplicity’s sake.

Building a Simple Spider Card

I expected the web to be full of Spider Cards as modules such as the F-5E, the Mirage F1, and others do not natively support the bullseye reference. So, as usual, when I could not find something I liked or wanted, I sat down and made my own. This is the result in in-game kneeboard format.

I divided the circle into 15° slices, resembling how I usually use NAVGRID in the Tomcat, with thicker lines every 45°. In order to reduce clutter, each slide is divided into two parts 5° wide but only after a specific range.
Each 15° interval also reports the reciprocal heading, recognisable by the “R” before the number. For instance, the value at 10 o’clock shows “300 R120”. The reason behind this indication will become clear later.

To address the common issue of poorly placed bullseyes, especially in casual servers, I opted for a dual scale: a black scale from the bullseye location to 85 nm and a red scale from the centre to 215 nm. However, the reference values can be divided as required. For example, if “zoom” is needed, so to speak, the red scale can be divided by 10, ergo providing references every 2.5 nm.

The odd-looking table at the bottom of the kneeboard page is a simple way to determine distances in particular scenarios. Covering every possibility would not be feasible nor beneficial, and this table should help new players to expedite the process.
The distances, indicated with a “D”, refer to angles: the value for “D 120”, for example, is the chord length of the arc connecting two points separated by 120° at different given ranges. Therefore, the distance between 140 and 260 at 40 nm is 69 nm. This table is relatively rigid but provides a quick reference value when a compass cannot be used.
To obtain this value, I considered the triangle rectangle built by the arm of the spider card and the bisector of the desired angle, in this case, 60°. Basic trigonometry then provides the other cathetus’s value, which is doubled to match the original angle. For this reason, the D60 case is missing: it would create an equilateral triangle, and all sides would share the same length.


The last table at the bottom of the page is a quick way to simplify longitude calculations. More on this later.

Using the Spider Card

Now that the choices behind the design of my Spider Card are more transparent, how can it be used? Taking notes and marking positions would be ideal, but it is also a waste of paper, and it is not a valid solution for VR players. If you want to follow this route, printing and laminating the card is an excellent way to ensure reusability. Another advantage of the printed version is the possibility of using a goniometer and a compass to increase the precision of angles and distance measurements. The card can also be printed on a transparent sheet and superimposed on a matching scale map. If you have room on your desk or simpit, this is the most interesting solution, almost a throwback to past-days navigators.

The VR and environment-friendly solution is using it in-game. However, the standard kneeboard is not interactive, and although Heatblur is implementing the ability to write on the Phantom’s canopy, it is not a handy workaround.
An alternative is the excellent Open Kneeboard. This tool allows you to take notes via a graphic tablet, thus providing infinite usage.

Depending on your interest and feedback, I plan to make ad hoc versions for both OpenKneeboard and a printable A4. The latter will probably be scaled to allow the use of any metre-based ruler to determine distances, for instance, by setting 10 mm = 5 nm.

Understanding the Spider Card

In DCS, the centre of the spider card commonly indicates the bullseye location. Then, the controller or other agency or player can broadcast the bullseye-referenced location of a radar contact. For example, omitting information not relevant to the discussion:

“Single Group, bullseye 300, 25”

Our aircraft can then reference our position and determine the contact’s location relative to us. This information can then be used to determine whether the fighter should commit, whether the contact can be a threat, and so on.

This simple process raises a question: how can an aircraft that does not have any embedded bullseye support determine its bullseye position? There are several ways to answer this question. The simplest is creating a waypoint matching the bullseye latlongs and reading bearing and distance. These coordinates would be, however, incorrect: the range will match, but the bearing will be inverted, and the reciprocal must be considered. This is one of the main reasons I added reciprocal values to the spider card; although quick means to determine the reciprocal exist, such as the “Plus two, minus two” rule, having them displayed can simplify the user’s life.

Example I

After creating a waypoint on the bullseye position, the avionics displays 100 55. Calculating the reciprocal, we find 280 55. This is our position using the bullseye as the reference point. Simple, isn’t it?

Example II

This example shows a picture provided by the in-game AWACS. Initially, we set up datalink and radio frequency. The former is unnecessary but can be helpful for additional verifications and testing.
The requested Picture returns a single group bullseye 296 35, 29000 feet. The value is then reported on the spider card.
Next, I needed to know my aircraft’s location. Rather than creating a waypoint, I asked for an alpha check. The returned value is the recip, so 014 20 to the bullseye becomes 194 20 from the bullseye.
At this point, I tried to plot the necessary bearing to reach the target. The poorly drawn line looked somewhat parallel to 325 or 330. The last step is the range determination: rather than eyeballing, I used the angle-distance table, with the desired value probably falling between 40 and 45 after interpolating the table entries. I also used a more graphical method by drawing the projection of the points onto the 325 line and adding the two distances for a total of 45 nm.
The verification with the F10 map was quite surprising, as it showed a BRAA of 332 44, quite close to the 330 45 I approximated.

Other references: NAVAIDS

The modus operandi described is the most common in DCS. However, I wonder how an aircraft that does not have a GPS, INS, or other means to tell its position besides common navigational aids would determine bullseye references. I am sure proper means exist, but I thought I’d give it a shot and show two possible ideas. If you have better ones, please share them!

The TACAN is a standard navigation aid found in the majority of Western aircraft, and it can be used to obtain bullseye references in several ways.
The first approach is to obtain the TACAN station’s location as a reference of the bullseye. This operation is relatively simple to perform via the F10 map. Then, the aircraft can use distance and bearing to the TACAN and correlate those values with the bullseye. More than one TACAN station can be marked on the spider card.
Another approach, even simpler but more limited in range, is to use the centre of the spider card as the TACAN’s location, thus making the process of correlating the aircraft coordinates even quicker and simpler.
Lastly, the aircraft itself can be used as the centre of the spider card, expediting the correlation to the TACAN station, but making the determination of the bullseye position possibly more convoluted.
Using Navigational aids to correlate the bullseye is probably a remote possibility, probably only used by aircraft monitoring the Controller’s frequency to increment their SA in casual servers.

What about LatLongs?

The last scenario is a bit silly, but bear with me. So, how would an aircraft without TACAN, or beyond its reach, use the bullseye in a modern scenario where the NS 430 is present? Think about the footage of Russian aircraft using handheld GPS devices or perhaps a helicopter such as the Mi-8 used by NATO countries. In these cases, the NS430 could be used to create a waypoint on the bullseye location, thus falling back into the examples already discussed. But, for the sake of having fun, let’s see how latitude and longitude can be used to determine the aircraft’s position to the bullseye.
The first step is annotating the bullseye’s latlongs. Next, get the aircraft’s latitude and calculate the latitude delta, taking advantage of the fact that 1° corresponds to 60 nm. The result provides the North / South distance from the bullseye.
Longitude is slightly more challenging since the Earth is not a perfect sphere; thus, its value changes depending on the latitude. Simply put, latitude indicates the parallels, which are equidistant from each other. Longitude instead refers to the meridians, which converge at the poles.

Example

This scenario sees the aircraft obtaining latlongs via the NS 430. The bullseye’s coordinates are known already.

BULLSEYE: LAT 26°10.3 | LNG 56°14.5
AIRCRAFT: LAT 25°37.2 | LNG 56°.34.4

LAT Δ
26°10.3 → 25°70
25°70 – 25°37 = 33 nm

LONG Δ
56°14 – 56°34 = 20 nm (equator)
18 nm @ 25° Latitude

Let’s calculate the difference between the two latitudes. 26°10 North can also be written as 25°70 since 1° equals 60 arcminutes of latitude. The result of the subtraction is 33 nm. The longitude is simple in this case since the degrees are still the same, and the result is 20 nm. Since we are not at the equator, the resulting nm are circa 92% of the original value, ergo around 18 nm. I have found that the easiest way to work the longitude is to convert the difference in arcminutes and then apply the percentage indicated in the kneeboard.
Then, drawing the lines to match the calculated distances, we find that the aircraft position is circa bullseye 150 37. Verifying with the F10 map confirms the computation’s surprisingly acceptable accuracy.

That being said, I doubt anyone will ever use this method, but playing with coordinates and navigational and coordination tools is always a good and fun exercise.

2 comments

    1. I plan to make a couple of changes before releasing them. For instance, not many care about the longitude table, and I can use that space in other ways.
      I should be able to release them over the weekend. Worst case I will upload the drafts you have seen in the video / article, and update them later.

      EDIT: actually, change of planes. No point in having you wait. The openkneeboard and the in-game KB page are available in Download.

      Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.