Author Archives: Fishbreath

Fishbreath Plays: MHRD Review

If you like puzzle games, it’s a good time to be alive. You’ve got your programming puzzle games, like Shenzhen I/O, SpaceChem, and really, the entire Zachtronics catalog; you’ve got your process optimization puzzle games, like Big Pharma and Production Line; you’ve got puzzle games of every shape, size, color, and description.

You even have, it turns out, logic puzzlers. That’s where MHRD comes in. You’re a hardware engineer for the waggishly-named Microhard, a company building the Next Big Thing in CPU design in the 1980s. You start with a single logic element: a NAND gate (for the uninitiated, that means not-and). You end up with a simple but entirely functional 16-bit CPU1, designing all the logic circuits you need along the way. Start with NAND, build the rest of the logic gates, figure out your multiplexers, demultiplexers, adders, and memory elements, put it all together into your higher-level CPU components.

It’s packaged in a fun, oldtimey DOS-style terminal editor, and unlike a lot of retro UIs, it doesn’t wear out its welcome. All your circuit design happens in a hardware description language, in an in-game editor. The editor has some foibles: it doesn’t scroll, and it only does line wrapping when adding text. On the other hand, it has a decent auto-completion engine. The hardware description language makes sense: you refer to pins and buses by name, connecting them to other pins and buses with an arrow operator. For instance, opCode->alu.opCode would connect the circuit’s opCode input to the ALU’s opCode input. Generally, the syntax is straightforward and easy to remember. Sound effects are basic; you get a background fan whir befitting an old PC, and an IBM keyboard sound effect which wears out its welcome after a while.

That’s all there is to it, which brings me to my next point. Is it good as a game? That’s a harder question to answer. It is sited in a difficult middle ground. It can’t be too freeform—given an instruction set and a CPU specification, very few people who don’t already know how could build all the necessary subcomponents. At the same time, it shouldn’t be too static, or else it feels a little too much like rote construction to the truth table for the component at issue. MHRD errs a bit too far in the latter direction. There is no real sandbox. All you’re doing is building the gates and circuits the game tells you to, in exactly that order. There’s no discovery to be had, and not a lot of freedom to design solutions in different ways. Unlike, say, Shenzhen I/O, the problems are small enough that it’s never all that unclear how to solve them.

That isn’t to say that there’s no fun to be had. If you aren’t a hardware engineer, or a software engineer with a deep interest in hardware2, you will find it fascinating how few steps it takes to get from a NAND gate to a functioning processor3. There are leaderboards, too, based on NAND counts for each element. Given that logic design is a fairly well-understood field, the NAND counts are uniformly the smallest possible number of gates required for each task, which gives you a nice target to aim for. The developer is active on his Steam forum, and seems to have more planned for the game. Given that it’s an atmospheric logic puzzle that I, an experienced software engineer, found enjoyable and educational, I think it’s worth a buy. (You may want to wait for a a sale.)

At the same time, there’s a better way. (If you’ve been reading the footnotes, you should have seen this coming.) There’s a free course out there, a Computer Science 101 sort of thing, called Nand2Tetris. As the name suggests, it’s similar to MHRD in that you’re building a CPU from a NAND gate alone. Nand2Tetris differs in two ways. First, it isn’t a game. As such, there isn’t a plot (MHRD’s is skeletal, but present), or any pretension that it’s about anything besides learning. Second, it goes a lot further. MHRD stops at the aforementioned functional CPU. The last puzzle combines the instruction decoder, the ALU, and some registers, and that’s it. It verifies your solution by running a few instructions through the CPU, and you’re done.

Nand2Tetris, as the name suggests, keeps going. After you finish the CPU, you write a compiler to generate your microcode. After you write your compiler, you write an operating system. After that, you can run Tetris. Furthermore, although you have assignments, you also have a proper sandbox. You get a hardware design language and a hardware simulator, and you can build anything you like. That, I feel, is the promise of a logic design puzzle game, and MHRD doesn’t quite deliver.

In the final reckoning, though, I say MHRD is worth the price of entry. I don’t really have the inclination to write my own compiler, and I have plenty of other software projects besides. If you’re only interested in the logic design portion, you ought to get MHRD too. If, on the other hand, you want to really understand how computers work—how the processor you built becomes the computer you use every day—try Nand2Tetris instead.

  1. It’s very similar in architecture, I understand, to the CPU designed in the Nand2Tetris course. We’ll come back to that. 
  2. Or a very good memory for that hardware class you took back in college. 
  3. Not counting the memory elements, the CPU task takes fewer than 800 NAND gates in the minimal solution. My current best is 3500. 

Nathaniel Cannon and the Lost City of Pitu Released!

Nathaniel Cannon and the Lost City of Pitu

The year is 1929. In the aftermath of the Great War, the world rebuilds, and the mighty zeppelin is its instrument. Carrying trade between every nation, airship merchantmen attract an old menace for a new age: the sky pirate. One man stands out above the rest. Ace pilot, intrepid explorer, and gentleman buccaneer Nathaniel Cannon and his gang, the Long Nines, prowl the skies in hot pursuit of wealth and adventure.

Cannon receives word from a sometime friend in Paris about a job in the Dutch East Indies. The contact tells a tale of a mysterious lost city, bursting with treasure, not seen by human eyes for a thousand years. Will his tip pay off? Or will it lead the Long Nines straight to a fight for their lives, lost in the unfriendly depths of the Indonesian jungle?

Nathaniel Cannon and the Lost City of Pitu, the first of the Nathaniel Cannon adventures by Soapbox contributor Jay Slater, is now available at Amazon, Barnes and Noble, Apple iBooks, Kobo, and Smashwords for $1.99. E-books include two never-before-seen short stories featuring the Long Nines. Get your copy today.

The Crossbox Podcast: Episode 17 – Grab Bags

In this episode, we can’t decide on one item for each topic, so instead we bring you a grab bag of grab bags. Jay talks about backwards aircraft carriers and the origin of the minimap, John tells you about news which was fresh when we recorded and old when we publish, and new audio setup reduces Jay’s obnoxious breathing noises by up to 80%.

Further reading
John breaks the Wilson Combat EDC X9 story several hours before any major source
John decides the EDC X9 is stupid
Continue reading

How-To: Two USB Mics, One Computer, JACK, and Audacity

The Crossbox Podcast is going upmarket: I now have two USB microphones, and for the March episode, parvusimperator and I will each have one directly in front of us. This is a wonderful advance for audio quality, but it does pose some problems:

  1. Audacity, our usual recording tool of choice (and probably yours, if you ended up here), only supports recording from one source at once.
  2. Though other tools support recording from multiple sources, the minor variations in internal clocks between two USB microphones mean that each microphone has a sample rate which varies in a slightly different fashion, and that longer recordings will therefore be out of sync.

Modern Linux, fortunately, can help us out here. We have need of several components. First, obviously, we need two microphones. I have a Blue Snowball and a CAD Audio U37, with which I’ve tested this procedure1. Second, we need a computer with at least two USB ports. Third, we need the snd-aloop kernel module. (If your Linux has ALSA, you probably already have this.) Fourth, we need JACK, the Linux low-latency audio server. Fifth, we need the QJackCtl program.

Before I describe what we’re going to do, I ought to provide a quick refresher in Linux audio infrastructure. If you use Ubuntu or Mint, or most other common distributions, there are two layers to your system’s audio. Closest to the hardware is ALSA, the kernel-level Advanced Linux Sound Architecture. It handles interacting with your sound card, and provides an API to user-level applications. The most common user-level application is the PulseAudio server, which provides many of the capabilities you think of as part of your sound system, such as volume per application and the ‘sound’ control panel in your Linux flavor of choice. (Unless you don’t use Pulse.)

JACK is a low-latency audio server; that is, a user-level application in the same vein as Pulse. It has fewer easily accessible features, but allows us to do some fancy footwork in how we connect inputs to outputs.

Now that you have the background, here’s what we’re going to do to connect two mono USB microphones to one computer, then send them to one two-channel ALSA device, then record in Audacity. These instructions should work for any modern Linux flavor. Depending on the particulars of your system, you may even be able to set up real-time monitoring.

  1. Create an ALSA loopback device using the snd-aloop kernel module.
  2. Install JACK.
  3. Build QJackCtl, a little application used to control JACK. (This step is optional, but makes things much easier; I won’t be providing the how-to for using the command line.)
  4. Use JACK’s alsa_in and alsa_out clients to give JACK access to the microphones and the loopback device.
  5. Use QJackCtl to connect the devices so that we can record both microphones at once.

We’ll also look at some extended and improved uses, including some potential fixes for real-time monitoring.

Create an ALSA loopback device
The ALSA loopback device is a feature of the kernel module snd-aloop. All you need to do is # modprobe snd-aloop and you’re good to go. Verify that the loopback device is present by checking for it in the output of aplay -l.

The loopback device is very straightforward: any input to a certain loopback device will be available as output on a different loopback device. ALSA devices are named by a type string (such as ‘hw’), followed by a colon, then a name or number identifying the audio card, a comma, and the device number inside the card. Optionally, there may be another comma and a subdevice number. Let’s take a look at some examples.

  • hw:1,0: a hardware device, card ID 1, device ID 0.
  • hw:Loopback,1,3: a hardware device, card name Loopback, device ID 1, sub-device ID 3.

For the loopback device, anything input to device ID 1 and a given sub-device ID n (that is, hw:Loopback,1,n) will be available as output on hw:Loopback,0,n, and vice versa. This will be important later.

Install JACK
You should be able to find JACK in your package manager2, along with Jack Rack. In Ubuntu and derivatives, the package names are ‘jackd’ and ‘jack-rack’.

Build QJackCtl
QJackCtl is a Qt5 application. To build it, you’ll need qt5 and some assorted libraries and header packages. I run Linux Mint; this is the set I had to install.

  • qt5-qmake
  • qt5-default
  • qtbase5-dev
  • libjack-jack2-dev
  • libqt5x11extras5-dev
  • qttools5-dev-tools

Once you’ve installed those, unpack the QJackCtl archive in its own directory, and run ./configure and make in that directory. The output to configure will tell you if you can’t continue, and should offer some guidance on what you’re missing. Once you’ve successfully built the application, run make install as root.

Run QJackCtl
Run qjackctl from a terminal. We should take note of one feature in particular in the status window. With JACK stopped, you’ll notice a green zero, followed by another zero in parentheses, beneath the ‘Stopped’ label. This is the XRUN counter, which counts up whenever JACK doesn’t have time to finish a task inside its latency settings.

Speaking of, open the settings window. Front and center, you’ll see three settings: sample rate, frames per period, and periods per buffer. Taken together, these settings control latency. You’ll probably want to set the sample rate to 48000, 48 kHz; that’s the standard for USB microphones, and saves some CPU time. For the moment, set frames per period to 4096 and periods per buffer to 2. These are safe settings, in my experience. We’ll start there and (maybe) reduce latency later.

Close the settings window and press the ‘Start’ button in QJackCtl. After a moment or two, JACK will start. Verify that it’s running without generating any XRUN notifications. If it is generating XRUNs, skip down to here and try some of the latency-reduction tips, then come back when you’re done.

Use JACK’s alsa_in and alsa_out clients to let JACK access devices
Now we begin to put everything together. As you’ll recall, our goal is to take our two (mono) microphones and link them together into one ALSA device. We’ll first use the alsa_in client to create JACK devices for our two microphones. The alsa_in client solves problem #2 for us: its whole raison d’être is to allow us to use several ALSA devices at once which may differ in sample rate or clock drift.

Now, it’s time to plug in your microphones. Do so, and run arecord -l. You’ll see output something like this.

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC295 Analog [ALC295 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Audio [CAD Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Snowball [Blue Snowball], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

This lists all the currently available capture hardware devices plugged into your system. Besides the first entry, the integrated microphone on my laptop, I have hw:1 or hw:Audio, the CAD Audio U37, and hw:2 or hw:Snowball, the Blue Snowball.

Next, set up alsa_in clients so JACK can access the microphones.

$ alsa_in -j snow -d hw:Snowball -c 1 -p 4096 -n 2 &
$ alsa_in -j cad -d hw:Audio -c 1 -p 4096 -n 2 &

Let’s go through the options. -j defines the label JACK will use for the microphone; make it something descriptive. -d declares which ALSA device JACK will open. -c declares the number of channels JACK will attempt to open.

On to the last two options: like the JACK settings above, -p defines the number of frames per period, and -n defines the number of periods per buffer. The documentation for alsa_in suggests that the total frames per buffer (frames per period multiplied by period) should be greater than or equal to JACK’s total frames per buffer.

Next, set up an alsa_out client for the ALSA loopback device.

$ alsa_out -j loop -d hw:Loopback,1,0 -p 4096 -n 2 &

The arguments here are the same as the arguments above.

Use QJackCtl to hook everything up
Now, we’re almost done. Go back to QJackCtl and open the Connect window. You should see a list of inputs on the left and a list of outputs on the right. Your inputs should include your two microphones, with the names you provided in your -j arguments. Your outputs should include system, which is linked to your system’s audio output, and an output named ‘loop’, the ALSA loopback device.

Assuming you have mono microphones, what you want to do is this: expand a microphone and highlight its input channel. Then, highlight the system output and hit ‘connect’ at the bottom of the window. This will connect the input channel to the left and right channels of your system audio output. At this point, you should be able to hear the microphone input through your system audio output. (I would recommend headphones.) The latency will be very high, but we’ll see about correcting that later.

If the audio output contains unexpected buzzing or clicking, your computer can’t keep up with the latency settings you have selected3. Skip ahead to the latency reduction settings. That said, your system should be able to keep up with the 4096/2 settings; they’re something of a worst-case scenario.

If the audio output is good, disconnect the microphones from the system output. Then, connect one microphone’s input to loop’s left channel, and one microphone input to loop’s right channel. Open Audacity, set the recording input to Loopback,04, and start recording. You should see audio from your microphones coming in on the left and right channel. Once you’re finished recording, you can split the stereo track into two mono tracks for individual editing, and there you have it: two USB microphones plugged directly into your computer, recording as one.

Recording more than two channels
Using Jack Rack, you can record as many channels as your hardware allows. Open Jack Rack, and using the ‘Channels’ menu item under the ‘Rack’ menu, set the number of channels you would like to record. In QJackCtl’s connections window, there will be a jackrack device with the appropriate number of I/O channels.

In Audacity, you can change the recording mode from ALSA to JACK, then select the jackrack device, setting the channel count to the correct number. When you record, you will record that many channels.

Jack Rack is, as the name suggests, an effects rack. You can download LADSPA plugins to apply various effects to your inputs and outputs. An amplifier, for instance, would give you volume control per input, which is useful in multi-microphone situations.

Reduce frames per period
If you’re satisfied with recording-only, or if you have some other means of monitoring, you can stop reading here. If, like me, you want to monitoring through your new Linux digital audio workstation, read on.

The first step is to start reducing the frames per period setting in JACK, and correspondingly in the alsa_in and alsa_out devices. If you can get down to 512 frames/2 periods without JACK xruns, you can probably call it a day. Note that Linux is a little casual with IRQ assignments and other latency-impacting decisions; what works one day may not work the next.

You can also try using lower frames per period settings, and higher periods per buffer settings, like 256/3 or 512/3. This may work for you, but didn’t work for me.

If you come to an acceptable monitoring latency, congratulations! You’re finished. If not, read on.

Fixing latency problems
Below, I provide three potential latency-reducing tactics, in increasing order of difficulty. At the bottom of the article, just above the footnotes, is an all-in-one solution which sacrifices a bit of convenience for a great deal of ease of use. My recommendation, if you’ve made it this far, is that you skip the three potential tactics and go to the one which definitely will work.

Further latency reduction: run JACK in realtime mode
If JACK is installed, run sudo dpkg-reconfigure -p high jackd (or dpkg-reconfigure as root).

Verify that this created or updated the /etc/security/limits.d/audio.conf file. It should have lines granting the audio group (@audio) permission to run programs at real-time priorities up to 95, and lock an unlimited amount of memory. Reboot, set JACK to use realtime mode in QJackCtl’s setup panel, and start JACK. Try reducing your latency settings again, and see what happens.

Further latency reduction: enable threaded IRQs
Threaded IRQs are a Linux kernel feature which help deliver interrupt requests5 more quickly. This may help reduce latency. Open /etc/default/grub. Inside the quotation marks at the end of the line which starts with GRUB_CMDLINE_LINUX_DEFAULT, add threadirqs, and reboot.

Further latency reduction: run a low-latency or real-time kernel
If none of these help, you might try running a low-latency kernel. You can attempt to compile and use low-latency or real-time kernels; the Ubuntu Studio project provides them, and there are packages available for Debian. If you’ve come this far, though, I’d recommend the…

All-of-the-above solution: run an audio-focused Linux distribution
AV Linux is a Linux distribution focused on audio and video production. As such, it already employs the three tactics given above. It also includes a large amount of preinstalled, free, open-source AV software. It isn’t a daily driver distribution; rather, its foremost purpose is to be an audio or video workstation. It worked perfectly for me out of the box, and met my real-time monitoring and audio playback requirements for The Crossbox Podcast6. I recommend it wholeheartedly.

Given that my laptop is not primarily a podcast production device, I decided to carve a little 32gb partition out of the space at the end of my Windows partition, and installed AV Linux there. It records to my main Linux data partition instead of to the partition to which it is installed, and seems perfectly happy with this arrangement.

So am I. Anyway, thanks for reading. I hope it helped!

  1. Two identical microphones actually makes it slightly (though not insurmountably) harder, since they end up with the same ALSA name. 
  2. If you don’t have a package manager, you ought to be smart enough to know where to look. 
  3. This is most likely not because of your CPU, but rather because your Linux kernel does not have sufficient low-latency features to manage moving audio at the speeds we need it to move. 
  4. Remember, since we’re outputting to Loopback,1, that audio will be available for recording on Loopback,0. 
  5. Interrupt requests, or IRQs, are mechanisms by which hardware can interrupt a running program to run a special program known as an interrupt handler. Hardware sends interrupt requests to indicate that something has happened. Running them on independent threads improves the throughput, since more than one can happen at once, and, since they can be run on CPU cores not currently occupied, they interrupt other programs (like JACK) less frequently. 
  6. Expect us to hit our news countdown time cues a little more exactly, going forward. 

The Crossbox Podcast: Episode 16 – Winter, Planely Negative

In this episode, Jay picks a horrifyingly punny title, we agree that shotguns are for door locks, beanbags, and pigeons clay and live, John picks older items in a gaming topic than Jay for once, and we discuss the only pitiful species of hornet in the world.

Further reading
Clashes and 11 Days of Christmas, Marshall L. Michael III
A Gripen-C (payload 11,400lb) can indeed carry an empty A-4F (weight 10,450lb). We couldn’t find payload figures for the Gripen-A in our admittedly abbreviated after-show research.


Visit the Soapbox for articles and commentary authored by the hosts of the Crossbox Podcast. Find back episodes of the Crossbox Podcast here.

Fishbreath Flies: DCS AJS 37 Viggen Review

Leatherneck Simulations is at it again: a 1970s aircraft modeled in loving detail. Once more, we get a plane which has virtues beyond accuracy. Leatherneck’s DCS Viggen has heart.

I’ve written about the Viggen’s history already, so if your first thought is, “Why should I care?”, there’s your answer. With that out of the way, we can move onto the plane itself.

Digital Combat Simulator made huge strides on this front with the release of its new rendering engine in 2015; Leatherneck has proven itself well above average at the graphical side of DCS module development. The MiG-21 was a work of art, and the Viggen is perhaps even more so. The external model is well done, and seems perfectly realistic to me1. The real artistry comes inside the cockpit, though. Flip on the battery and the low pressure fuel pump, and the master warning lights (labeled HUVUDSVARNING, because Swedish) come on, bathing the cockpit in a luminous flashing red. Turn them off and get through the rest of the startup checklist, then turn the radar on. The CRT casts its eerie green CRT glow over everything, and seems to glow with the inner light all displays of its type do.

Beyond the superb lighting effects, the cockpit also has the weathered feel you would expect from twenty-year-old airframes. (Remember, the AJ 37 Viggen is a 1970 plane; the AJS 37 Viggen is the 1990s update). It isn’t dingy, but it does look and feel as though it’s been used, and that adds tremendously to the plane’s character.

We come now to perhaps the best part of the Viggen: its sound design. Although the DCS engine may not do very well at exterior sounds for any plane, Leatherneck has still managed to make the flyby sound meaty, especially in afterburner. In-cockpit, the state of things is much better. Turn on the AC power, and the computer’s fans spin up with a sound that reminds me of my childhood machines. The master warning alarm has the same warmth to it as the light does. Later, the insistent chirp of the radar warning receiver gives way to the thunder of the afterburner, growing deeper by stages as the throttle clicks past its detents through the three afterburner power bands.

Sound is an important and underrated component to immersion in sims. The Viggen gets it spot-on. It’s good as any sim I’ve played to date.

Systems and weapons
The Viggen flies a mission profile rather out of favor in today’s world: interdiction. That is, it’s designed to fly at ludicrously high speeds and ludicrously low altitudes, carrying a wingload of bombs, rockets, or rudimentary guided weapons. It gets to its target, pops up at the last minute to aim its weapons, makes one pass, and heads home.

This is reflected in its design: the canarded double delta makes quite a bit of low-speed lift, but it does so inefficiently. The Viggen is happiest in its native habitat: Mach numbers greater than 0.6, altitudes lower than 500 meters above the ground. It does not fit into the low-intensity COIN world of DCS nearly so well as (say) the A-10C, the Ka-50, or even the Su-25. The weapons fit requires you to know where your target is, and even the air pressure at the target’s location. All of this (except for the air pressure) must be programmed into the computer ahead of time, or using the wee six-digit input display while flying.

So, don’t expect to do much loitering, waiting for JTAC, and dropping bombs precisely. Even if it was more straightforward, the Viggen has very little facility for dropping quantities of its weapons smaller than ‘all’. Only guided missiles fire one at a time.

Having introduced this section with an extended ramble, let me get back on point for a paragraph. The systems modeling feels right to me. I’m not an expert on Swedish systems of the 1970s and 1990s, but everything feels plausible enough, modulo some early-access issues Leatherneck is working through in weekly patches. Notable fun items include the overwhelmingly programmable RB-15 anti-ship missile, the BK-90 totally-not-a-low-altitude-cluster-JDAM, and the RB-05A manually-guided missile (easier to use than it sounds). The air-to-ground mapping radar works as expected; that is to say, it’s very cool, albeit with the confusing wrinkle that green means no radar return and black means return.

There are some ongoing issues with rearming, as well as some others involving weapons and multiplayer, but I’m confident Leatherneck will be able to get those squared away.

On to the most subjective point! Is it fun?

Yes. Yes it is.

The design of the HUD, with few numbers and lots of indicator lines, makes you feel like you’re flying a Swedish X-Wing, and the rest of the cockpit supports that impression. As the treetops zip by at four hundred knots, and the waypoint distance line on the HUD shrinks to indicate you’re closing in on your target, you can just picture yourself hurtling down the Death Star trench.

Maybe that’s an exaggeration, but the Viggen’s mission profile makes for a certain sense of rising anticipation as you speed toward your target. Do you know that stereotypical scene from adventure movies, the one where the sun inches toward a bejeweled staff placed just so, or the one where some narrator is speaking while an orrery clicks toward planetary alignment? Everything is building toward a single moment, and then, bam—the payoff. The sun sparkles off the jewel and lights up the model of the city below, the orrery’s planets align. That’s the feel of a Viggen mission done correctly. Your range-to-target dial—and it is a dial; the Viggen may be computerized, but it isn’t that computerized—ticks down toward zero. You pull up, catching a glimpse of your target as you do. You roll onto it, lining up the sighting mark in the HUD, and then, bam. You pull the trigger and your weapons strike home. There’s the payoff.

It’s tremendously exciting.

I recommend the Viggen wholeheartedly, based on its production values and on the sheer thrill I get out of flying it. I offer the following two caveats, though. First, it’s an early access product; more importantly, it’s an early access DCS product. There are still plenty of gremlins. Second, if you’re a multiplayer-primary player, be warned that there are several bugs and several usability issues to contend with. Even with those caveats, though, it’s an excellent aircraft, and I very much doubt you’ll be disappointed with your purchase.

  1. I don’t count rivets, though. 

Sunday Puzzle: Air-to-Air Refueling Edition

Need something to wash the taste of Patriots victory out of your mouth? Try the Sunday puzzle.

Much ink has been spilled about the limited range of modern American carrier fighters. It’s one of parvusimperator’s biggest bugaboos. Sometimes though, it’s difficult to get a good sense for the penalties imposed by limited range. Let’s formulate it as a riddle.

You, Colonel Reader, command a fighter wing in Friendly Mideastistan. You have orders to strike a target in Enemy Mideastistan. Your target is six hours away from your airbase. Your fighters only fly for three hours on one tank of fuel.

Some additional parameters: your fighters fly at a constant speed without respect to payload or altitude, and their fuel consumption is also constant. You have exactly one airfield to work with, placed six hours from the target. Planes may not take off from or land anywhere else, nor may a plane run out of fuel in midair. (It looks bad.) Planes may refuel each other; there is no limit on how much fuel a plane may transfer. Takeoffs, landings, and refueling are assumed to be instantaneous.

Question 1: for each plane which drops a payload on the target, how many planes are required for refueling?

Question 2: describe the pattern of refueling which is required to get one plane to the target.

Answers and analysis:


I first saw this as a question about circumnavigating the globe, so I’m going to talk about 180 and 360 minutes instead of 6 hours.

Two refueling planes are required per strike plane. All three take off at T+0. When they reach T+45, all three have 135 minutes of endurance remaining. The first refueling plane fully refuels the other two, at the cost of 90 minutes of endurance. It has 45 minutes of endurance remaining, and returns home. The other two have 180 minutes of endurance left.

At T+90, the first refueling plane has landed. In the air, the two remaining planes each have 135 minutes of endurance remaining. The second refueling plane fully refuels the strike plane. The refueling plane is left with 90 minutes of endurance, and the strike plane now has a full 180. The refueling plane turns for home.

At T+180, the strike plane drops its payload on the target, with 90 minutes of endurance remaining. The second refueling plane has landed. The first refueling plane, now refueled, takes off.

At T+270, the strike plane and the first refueling plane meet. The strike plane is running on fumes, with 0 minutes of endurance left, and the refueling plane has 90 minutes. It transfers half its fuel to the strike plane, leaving both with 45 minutes of endurance. The second refueling plane takes off.

At T+315, the strike plane and the first refueling plane meet the second refueling plane. The first two are running on fumes. The latter has 135 minutes of endurance remaining. It transfers 45 minutes of fuel to each of the first two planes, leaving all three with 45 minutes of endurance: just enough to get back to home plate.

And this, of course, is the best-case scenario. Our model is simplistic in the extreme; it doesn’t account for the time taken to refuel, the time taken to find the tanker, the difference between fuel consumption based on payload, the ordinary requirement that strikes be flown at a speed and altitude different from those used for best cruise performance, and a myriad of other factors.

Let us consider a real-world example which closely matches our riddle in its setup: the Black Buck raids, flown by the RAF during the Falklands War. The distance between the closest British airfield, Wideawake on Ascension Island, and Port Stanley Airport, in the Falkland Islands, is 6,300 kilometers. Different sources list the Vulcan’s cruising range at between 4,100 and 7,000 kilometers. Even if you choose the worst possible figure, the Vulcan’s endurance is nearly two-thirds the required range, much better than the half in our riddle. Of course, I haven’t been able to find actual range figures; this column does not merit that much investigation.

What it does merit, however, is the answer to our riddle for the real-world case. For each Vulcan strike (they were flown as single-aircraft raids), eleven tankers were required, refueling each other, then refueling the Vulcan six times on the outbound leg and once on the return trip.

Refueling is hard. Not only is it difficult mechanically, not only does it require specialized aircraft (or limited refueling performance, for buddy stores), it also gets you into a vicious cycle in the same vein as rocket design. When you have to carry your fuel, you need more fuel to carry your fuel to where it’s needed, and so on and so forth. The United States has an enormous advantage in that it already operates refueling assets worldwide; much of its fuel is already where it needs to be. This may not always be the case, hence our advocacy for aircraft designs with legs built in.

I hope you enjoyed the inaugural Sunday puzzle. There may be others.

The Crossbox Podcast: Episode 15 – Two Favorites

After yet another month of failing to finish our special project, we knock together an episode at the last second to keep our monthly schedule going, sort of like this.

Further reading
P320 selection
Borgundy pistol selection
DCS Viggen videos
InRange TV AK mud test


Visit the Soapbox for articles and commentary authored by the hosts of the Crossbox Podcast. Find back episodes of the Crossbox Podcast here.

US Ground Combat Systems Are Not Obsolete

I came across this article in the Free Beacon this morning, whose headline reads as follows: “Army’s Ground Combat Systems Risk Being Surpassed By Russia, China”.

Look, if you’re reading this article, you’ve read a lot of our articles. You know that I, Fishbreath, am not the expert on ground combat systems. Not really my cup of tea. You know, therefore, that when I say, “Man, this article is dead wrong,” that it really is just flat out dead wrong. Let me revise the Free Beacon’s headline: “Army’s Ground Combat Systems Risk Being Roughly Equalled By Russia, China After 40 Years Of Curb-Stomping Dominance”.

In the modern era, a combat system’s age is not nearly as important as its current capability. The T-14 and the Type 99 are modern tanks. They compete against the modern American system, the M1A2, in the three categories by which all armored fighting vehicles are judged: firepower, protection, and systems1.

First off: firepower. The American contender mounts the stalwart Rheinmetall 120mm smoothbore gun in the 44-caliber length. The Germans, being a little squeamish about depleted uranium2, made an L/55 version for higher muzzle velocities. This gun, either the lengthened version or the original with depleted uranium, still sits in the top tier of tank guns as far as penetration goes3. The Russian and Chinese entries both use the Russian standard 125mm caliber; the Armata uses the 2A82, the shiny new version sans fume extractor for installation in the unmanned turret, while the Type 99 uses the ZPT-98, the traditional Chinese clone of the 2A46. Neither is clearly superior to the Western choice of gun. Standard 125mm ammo is nevertheless lighter and shorter overall (counting the penetrator and propellant) than the one-piece 120mm loads usually fired through the Rheinmetall guns. In exchange, the Russian-style gun gains the ability to launch ATGMs—questionably effective against modern tanks—and a little bit more power for HEAT rounds, which have the same issue as the ATGMs. Call this one a slight win for the Abrams.

Next: protection. The Type 99 falls behind quickly here; it’s more or less a T-72 hull, and the T-72 doesn’t have a great deal of headroom for armor. Too, the Type 99 has to deal with the swampy, rice-paddied Chinese south. The Chinese can’t build a T-72-based tank much heavier than the current 52 to 54 tons, and the protection they can achieve there is limited, given what they have to work with. The Armata, though it weighs in in the 50ish-ton range itself, has the benefit of an unmanned turret. Unmanned turrets can be smaller, and armored volume is expensive in weight terms. Our own parvusimperator claims Armata has roughly Western-equivalent protection. Give Armata an edge, even; there are no squishy humans in its turret, and no explodey ammo in its hull. The unmanned turret, unproven though it may be, neatly isolates the two. Call this one a slight win for the Russians.

Finally: systems. This is the hardest one to write about, since the Russians and the Chinese aren’t talking. We know more or less what’s in the M1A2: nice digital moving-map navigation, color displays, modern sighting units, separate ones for the commander and gunner, with nice thermal displays. I think it’s reasonable to assume the Armata has similar. We can see that it has an independent sight for the commander, and the Russian avionics industry has built color MFDs and moving map systems in the past. Presumably, the charionics4 in their tanks won’t be too far behind. It’s even less possible to speculate about the Chinese; their latest MBT entered service around the turn of the century, and who knows what they’ve stuck in it. Call this one a tie between the Americans and the Russians.

In a way, though, systems are the least important item here. Unlike armor or guns, swapping out the computers, stabilizers, navigation systems, and sights in tanks is more or less trivial. There may be integration costs, and there are definitely upgrade costs, but ordinarily, you don’t run into the same sort of critical design problems you find when, say, trying to cram a 140mm gun into an Abrams turret.

So that about wraps it up. Contra the Free Beacon article, the new Combloc5 tanks do not surpass the Abrams in any meaningful way. Where they are superior, it’s a matter of degrees. Elsewhere, they still fall behind the Abrams. What we have today is not a new era of Combloc dominance. It’s a return to parity for the first time in almost forty years.

Let’s go back a few years more than that. It’s 1972, and the fearsome T-72 has just entered service. It’s faster than the M-60, hits harder, has better armor, and is being cranked out of the Soviet tank factories at an astonishing rate. The armored fist of the Soviet Union could well crush Western Europe. This doesn’t sit well with Western Europe.

The Germans and Americans are already hard at work on the MBT-70. It reaches a little too far, and doesn’t quite work out. The Germans and Americans each take the blueprints and build something on their own, and we get the Leopard 2 and the M1 Abrams, entering service in 1979 and 1980. This begins the aforementioned era of Western tank dominance. The Abrams and the Leo 2 are vastly superior to the T-72 and T-80. The Russians do some various upgrade projects to the T-72 and T-80 over the years, but never regain the lead. The Leo 2 and Abrams see upgrades on more or less the same schedule; they’re still a generation ahead.

Finally, today. The Russians have Armata, a legitimate contender; the Chinese have the Type 99, which is sort of the Gripen to the Abrams/Armata F-22: some of the same technologies, still half a class behind. Which brings us to the final decider. Quantity.

The Russians have about one hundred Armatas. They only entered service last year, so I give them a pass. Their eventual plan is to acquire about 2300.

The Chinese have about 800 Type 99s. I have no idea if they’re still being produced.

The Americans have roughly 1000 M1A2s, the most recent Abrams. Of course, we also have about 5000 M1A1s of various marks, most of which have been upgraded to include nearly-modern electronics.

Even if we allow that the Type 99 and the Armata are superior to the average Abrams in American service, which is wrong, we still have twice as many as both other types combined.

The Free Beacon may say otherwise, but I say we’re doing just fine.

  1. To include sights and viewers, as well as command and control computers. 
  2. Understandable, given that in most hypothetical wars, the Wehrmacht Bundeswehr would be shooting it over their own land. 
  3. As far as anyone knows. Armies are a little cagey about revealing how punchy their guns are, for some unfathomable national security reason. 
  4. Electronic systems for tanks, by analogy to avionics. (An avion is a French plane, a char is a French tank.) 
  5. Yes, I know they are, respectively, not Communists anymore and nowadays only Communists inasmuch as they’re heirs to a truly Communist body count. I don’t care. ‘Combloc’ is a reasonable way to refer to Russia and China in the context of this article. 

Swedish Strike Saturday: the AJS-37 Viggen

The AJS-37 Viggen is a modernized classic: a 1990s update of the 1971 AJ-37 Viggen.

Why is it a classic, though? You may be forgiven for not knowing. In fact, I did not know until I saw that Leatherneck Simulations1 are making a DCS AJS-37. So, on this first Swedish Strike Saturday, let’s take a look at why the Viggen is such an icon, and why you ought to be excited for it.

In doing so, we first have to take a trip back in history, back to Sweden circa 1961. The enemy du jour is the Soviet Bear. Although the Saab 35 Draken matches up well against Soviet fighters of the day, the Saab 32 Lansen, a late first-generation jet which handles the attack role, is looking a little long in the tooth. It’s time to make something better.

Much better. The Swedes had a history of pioneering aircraft designs out of Saab, and the Viggen was no exception.

It was the first canard aircraft to enter front-line service, and featured the first afterburning turbofan in a strike fighter. By date of start of development, the Viggen’s computer was the first integrated-circuit computer designed for use on an aircraft. For a time in the early 1960s, while development work was under way on the computer, Saab was the world’s largest buyer of integrated circuits. It was the first single-seat third-generation jet strike fighter to enter development, and the second to enter service2.

As one of the two first digital attack aircraft to enter service, it is, then, an object of some historical interest. Similarly, its computer is one of the first in the aviation world, and that makes it interesting to me (a computers guy). The CK37 (CK for Central Kalkylator) flight computer does just about everything data-related in the aircraft: it runs both of the cockpit displays (the HUD and the Central Indicator—think radar screen, but with navigational information, too), does navigational calculations, and handles weapon aiming.

Saab built the prototype, using individual transistors, in the 1960. It was table-sized, featured about 5,000 transistors, and ran at about 100,000 cycles per second. Total weight was about 450 pounds. Obviously, it wasn’t altogether suitable for aerial usage. Redesign efforts in 1961 used the newly-available ‘integrated circuit’.

Enter Fairchild, who beat Texas Instruments (!) for the contract. Their integrated circuits featured a whopping two transistors per square millimeter, ten times the density of discrete components. Some few years later, in 1964, Saab’s computing division delivered the final CK37 prototypes. This final version could run about 200,000 instructions per second, with about 28 kilobytes of magnetic core memory, with core density of about one core per millimeter3. It weighed about 150 pounds, comprised five computer units, and drew about 550 watts of power.

And, going by everything I’ve seen, it made for a tremendously effective aircraft. On seven hardpoints, the original Viggen could carry a combination of weapons: 135mm rockets, 120kg bombs, the RB-05A MCLOS missile, and the RB-04 anti-ship missile. Between the radar and the advanced (for its day) navigation system, the Viggen could fly in ugly weather, dropping unguided bombs precisely on any target it could see by radar. Although its air search capabilities were rudimentary, the radar could still cue Sidewinder seekers; on those grounds, it was not altogether ineffective as a fighter.

It did so without a navigator; the autopilot and navigation systems are sufficient to permit the pilot alone to fly and fight. By all accounts, the Viggen gave excellent service from its introduction date in 1971 to its retirement thirty-odd years later. Along the way, it gained the RB-75 missile4, and a variant called the JA-37. A fighter first and striker second, the JA-37 gained a better computer, a lookdown-shootdown radar, and support for the Skyflash5 missile. Much later, both the JA and the AJ Viggens saw some upgrades. The JA-37 became the JA-37D, with a glass cockpit and the ability to sling AMRAAMs6. The AJ-37 became the AJS-37, and that’s the plane we’re interested in today.

Development of the JAS-39 Gripen7, the follow-on to the Viggen and the Draken, began in 1979. It didn’t fly until 1988, and it didn’t enter service until 1997. In the interim, Swedish military planners began to get a little nervous about the state of their ground attack force. Though the Viggen was a solid workhorse, its armaments were outmoded, and its navigation system was fiddly.

Some of the Gripen’s weaponry was already available in the early 1990s, though, including the BK-90 submunitions dispenser8 and the RBS-15 anti-ship missile. The S-modification allows the Viggen to launch both, giving it access to modern smart weapons. At the same time, Saab’s designers added a data cartridge, greatly simplifying pre-mission preparation. The extra data capacity in the cartridge also allowed for a terrain contour matching function. The data cartridge contains information about the elevation contours expected during the mission and their locations; in flight, the computer correlates the expected contours to the actual, observed contours from the radar altimeter. This allows the computer to update the INS with true positions, correcting to some degree for drift during flight.

With those upgrades, the AJS-37 soldiered on until 2005, flying alongside the Gripen for eight years, at which point it was finally retired. An airplane of many firsts, it was also a notable last: the last of the great 1970s low-altitude strike fighters to fly its original mission profile. The Tornado, the F-111, and all the Viggen’s other contemporaries were upgraded to fly more modern, middle-altitude missions. The Viggen never lost its focus as a low-altitude interdictor.

Is the Viggen a good interdictor in its original threat environment? Do the upgrades make it better? Is it suitable for the modern world? How good is the Leatherneck recreation? This paragraph is where I had hoped to tell you that we would soon be finding out. Unfortunately, it’ll be a little longer than I had hoped; Leatherneck’s Viggen releases on January 27, and it isn’t looking like the Soapbox is big enough for a preview key. No matter—that just gives me more time to prep for the articles down the road. In February, you can expect two or three of them, touching on the answers to the questions posed at the start of this paragraph.

Stay tuned!

  1. Makers of the DCS MiG-21
  2. The A-7 Corsair came first, entering service in the late 1960s to the Viggen’s 1971 
  3. The CK37 divides its memory into 8192 words of 28 bits in length, with 1536 words as working space and the remainder write-protected data. 
  4. The AGM-65A Maverick; the Swedes have a thing about keeping American names for missiles. 
  5. Or RB-71. 
  6. Surprisingly, they call this one the AIM-120. 
  7. The Gripen is a longtime favorite of mine. 
  8. The Swedes are anti-cluster-bomb, so a weapon which drops explosive bomblets is called a ‘submunitions dispenser’.