Model Builder version 4.08a and later supports an automatic jamming feature. The radio object will play a user-defined sound file while it is being actively jammed. The jamming may be intentional, such as that due to enemy action, or unintentional, such as that due to in-band interference by partially overlapping, but not completely in-tune, radio bands.
The user simply creates a sound file library containing audio files corresponding to various transmitter types. This library is inserted into a radio object; whenever the receiver portion of the radio is being actively jammed, the appropriate sound file will play. This provides an audible cue to the operator/student that jamming is occurring. If there is not a sound file associated with a particular transmitter/jammer type, no audio is played.
One benefit to this MB feature is that jamming over the network can be done with a minimal amount of bandwidth consumed. Since the jamming noise is generated locally within the radio, there is no need to transmit that audio stream over the network. Set the jamming transmitter audio encoding type to “no audio”, and only transmitter PDUs for that object will be sent over the network. Even though the jammer is not actively transmitting an audio stream, the normal radio propagation rules apply to the jammer and radio receiver pair. Factors such as transmitter power, bandwidth, antenna gain and range will impact the effectiveness of the jammer. Additionally, the jammer and radio receiver pair is subject to the effects of a terrain server (if used).
Collect the sound files that are going to represent the various types of jamming signals. In the event that you do not have a store of ready-to-use sound files, create a white noise object in Model Builder. Adjust the frequency, filter and Q-value to create the desired sound. Then use the “Record Sound” object to create the file locally on the DACS.
Go the sound files list in Model Builder, and create a “Group”. Add the desired jamming sound files to this group. As the individual sound files are added to the jamming group, change the “Jammer Modn” field to reflect the transmitter types that will jam the radio. Use the +/- keys to scroll through the various modulation types until the desired one is found.
For example, if the only jammers in the simulation are pulse type, then set the “Jammer Modn” type to “Pls 1”. If you are simulating in-band interference as well as intentional jamming, then include additional sound files and set the “Jammer Modn” to “Ang FM” or “AM AM” as appropriate. Model Builder will automatically resolve which sound file to play based on the jammer’s modulation type.
The jamming libraries are put in the radio object on a per-mode basis. If you have a multi-mode radio, ensure that there is a jamming library for each mode. It is standard and acceptable to use the same jamming library for each mode of the radio.
Implementing jamming is really quite simple, but there are one or two “tricks” to make it easy.
First, let’s start with the receiving radio object.
In order to simplify jamming both locally (within one DACS) or over a network (multiple DACS running DIS or HLA), each radio object is responsible for generating the appropriate jamming effects when it detects that it is in a jammed state. This avoids the need for the jamming source object to stream (redundant) signal PDUs over the network, which would consume precious bandwidth on a continuous basis.
Basically, the radio looks at its modulation mode and will decide whether any received signal is in-tune. This implies that the modulation mode matches, the frequency is matched—or if you want to be totally accurate, that the bandwidth overlap around the tuned center frequency overlaps enough to allow the receiver to correctly demodulate the transmitted signal—and that the TX signal is in-range. If a signal does not match modulation mode but is otherwise convinced that the other parameters are within reception tolerance, then the radio declares that the received signal is “jamming” the receiver. This does not (yet) mean that the radio will produce any jamming noise effects, but the logic to allow this is built into the radio object.
When a radio is correctly receiving a transmission, then the radio will indicate an “Active RX” flag in the lower right corner of the radio object. Additionally, on the very last line of the radio object you will see a line reading “RX from *<radio_name>” where the asterisk symbol (*) means clean reception.
When a radio is receiving a jamming transmission, you will see an “Active RX” flag, but the very last line will read “Rx from !<radio_name>” where the ‘!’ symbol means “jammed”.
Now we can see that we have a rather smart radio that can decide whether or not it is being jammed. But what of the jamming sounds? Well, this is also integrated into the radio, with a little help from our Soundfile objects.
If you look at pages 5 and 8 of the Model Builder Radio object, you will see that for each possible operating mode of the radio there is a connection field labeled “JammerSND”. The intent of this field is to link this to a SoundGroup. A SoundGroup is a convenient “container” for a set of associated soundfile objects. The SoundGroup will be the source for the jamming sound effects.
The radio object includes an internal playsound object which plays the appropriate soundfile and routes the audio into the correct connection point within the radio object. This is another way to say that it is not necessary to attach an additional playsound object or other convoluted combination of objects; all the required “parts” are included in the radio itself.
So how do we identify what soundfile will play and under what condition? Well, we already know that the radio has the ability to identify that it is being jammed (or not). What is not so obvious is that the radio object also knows “how” it is being jammed, i.e. what the source modulation of the “jammer” is. The effect that a radio will give when jammed will depend entirely on the source modulation and the nature of the jamming signal that is being transmitted.
The mechanism used to determine what sound is played is that the Soundfile objects placed inside the “JammerSND” SoundGroup must be tagged with the modulation type they represent. If you look a Model Builder Soundfile and scroll down to line 4 of the object, you will see the right hand field is labeled “Jammer Modulation”. If you move the cursor to this field, you will find that by using the “+” and “-” keys you can increment/decrement through all the valid modulation types available within the radio object.
More simply: If the jamming transmitter has a modulation type of Angular Pulse Modulation (Ang PM), and your receiver is type Amplitude Modulation (AM), then your radio will be jammed. So MB now needs to generate a sound for this condition. Within the JammerSND SoundGroup, you should add a Soundfile and then set the Jammer Modulation parameter to be “Ang PM”. If you have another type of jammer, say a Pulse Modulation type (Pls 1), then you would need to add another Soundfile to your JammerSND group with the Jammer Modulation parameter set to “Pls 1”, and so on. You can set up any number of different soundfiles that will play, depending on the source transmitter (jammer’s) modulation type.
Of course, you may not necessarily want to represent any specific source transmitter modulation. This can be solved by using any of the undefined modulation modes that the radio object recognizes. There are currently 26 defined modes that can be selected, leaving 230 others available. So, in theory, you could set up a total of 256 jammer sounds, 26 of which that could map to an enumerated modulation type, and 230 “others”.
But we still need to look at the source transmission part of the system. This is the “jamming source”.
The ASTi Model Builder Transmitter library includes a specific “Jammer” object. This is intended to represent a broadband jammer that covers a wide block of the frequency band. This is achieved by setting an upper and lower frequency bound where any radio within distance range that is tuned within the jamming band will be jammed by this object. The downside to this object is that it can only be preset to one modulation mode. Of course, multiple jammer objects can be placed within the model and enabled as required to represent different jammer threat types.
One trick that applies particularly to networked systems is to set the “Encoding” type of the Jammer object under the Mode definition to “No Audio”. This prevents the jammer from flooding the network with redundant signal PDUs, but still allows any receiving radio to be jammed (since the modulation mode and other critical information is contained within the Transmitter PDU).
Another option is to simply use a standard radio object as a spot frequency jammer. The beauty of this is that you can utilize the ability of the radio to change mode, and hence represent different jammer types while only using one modeling object. Any of the radio modes can be set to any of the available modulation types (including the undefined modes).
If, for example, an instructor station wants the ability to select a different jamming sound or effect, one way is to set up a radio to act as the jammer source, and connect a control to the “Power/Mode” field. Assuming the appropriate modes are configured and the corresponding Soundfiles are set up in the JammerSND SoundGroup, the instructor can simply change the mode of the source jammer object and achieve the required jamming effect.