Sigmira Fix Now Available

The updated features.dat file for Steven A. Harlow's popular (and good) Sigmira program can be obtained at his web site.  Instructions on where to put the updated file are there as well.

Spectrum Lab Works Fine in 64-bit W7

I don't know why I thought it didn't.  It is installed in c:\radio\spectrum and it works just fine.  I also run it as an administrator with full permission set to its folder branch just to be sure.  So far, it's done everything it did in XP.

People might know that I really like Spectrum Lab, so it's nice to have it back.  Its window scales any size one would ever need it to be, and you can spend the rest of your life getting acquainted with all it can do.  I've even made digital art with it.

It's Not You: Sigmira Blows Up Again

Now, I like Sigmira.  It cranks on STANAG 4285, it has a great mode to demonstrate what's really up with the Japanese "slot machine" encrypted data station, and it does HFDL.

It has this one odd issue where every so often the features.dat file becomes obsolete and must be replaced for STANAG 4285 to work again.

This time, though, the problem is not loss of features.  The program starts up very briefly, then shuts down and displays a small window saying something unhelpful along the lines of "it didn't work."  Everyone got the problem at the same time, and it seems as if it might be related to the PC system date.

So far no word on the web site.   I won't be able to duplicate the problem and try for any insight because it never ran on my new 64 bit system anyway.  Too bad, because it IS a great program.

Ham Radio Software Meets Windows 7 #4: The Final Accounting

After much sound, fury, hair pulling, and bad language, the results are in.

Programs that recognize the W7 app data path variable, keep their data outside the program file tree, and work when installed to the default directory (Program Files (x86)):

FLdigi (Note 1)
JVComm32
TrueTTY

Programs that should probably be installed in a different folder you create yourself (I called mine "Radio"):

DSCdecoder (Note 2)
MultiPSK (3)
PC-ALE (4)
PC-HFDL (5)
POSFIX
Spectran

1) Created files under "Users," not in program folder.
2) ITU lookup won't work installed under Program Files (x86).
3) Some confusion over whether or not to run INSTAL.exe after unzipping.
4) Do not leave "create desktop icon" checked.  Create shortcut manually in program's home directory, and drag to desktop.  In fact, do this for all these programs.
5) Go into ground station file, change "AUCKLAND - NEW ZEALAND" to "AUCKLAND - NZ" due to a bug unrelated to platform.

As always, your results will be different.  That's what worked here.

Ham Radio Software Meets Windows 7 #2: DSCdecoder FIXED!

OK.  Thanks to the informative forum at HF-ALE, I have the intelligence that Windows 7 security prevents programs from modifying certain files in their own home folders and subdirectories therein.  Variable data is supposed to be stored in User Data, App Data, or someplace like that.   These old ham programs don't do that.

The advice was given to create a folder OUTSIDE Program Files (x86) for old radio software that won't work any other way, and install these old programs there.  While they were talking about PC-ALE, this worked for DSCdecoder.  The ITU lookup is now working and the program is as far as I'm concerned now operating properly.  The display screen changes, and the data is written to the daily log and shipid.txt.

While I was at it, I moved the logging folder to My Documents, since I look at it a lot.  This is done with Options > Directories > Log File.


I wouldn't recommend this installation procedure for every single new program, since it does defeat a security feature built into W7.  This is for the care and feeding of these old radio sharewares.  Make sure you trust the software.

Bletchley Park #2

Part 2 of our tour begins when we leave B Block and explore the extensive grounds of Bletchley Park.  This entire complex is always adding exhibits and special programs, some on more diverse subjects such as model railroading. There's a lot to do there, and a lot of opportunities to volunteer.

Pictures of the rather flamboyant mansion house are all over the Internet, and we are about radio here, so a quick Google is recommended for those wishing to see some truly dotty British country architecture.  This neat old place is available for weddings, if you can talk your non-radio-nerd fiancee into it.

Our first photo is of Hut 1. It was built in 1938 or '39 as early wartime operations outgrew the mansion.  As the sign suggests, it once housed radio transmitters, connected to a giant rhombic antenna on the grounds.  This activity was moved away from Bletchley to avoid attracting attention to the site.  Today, Hut 1 houses vintage radio gear from the "Diplomatic Wireless Service," but due to low staffing it is only open weekends.

The low brick wall was added in 1942. It is only a few centimeters from the building, making access to the walls difficult. It was intended as partial protection for the hut, which by then was used for ENIGMA activities.

At a far corner of Bletchley, one comes upon H Block, which is arguably the birthplace of modern computing.  It housed an activity related to attacking German High Command teleprinting traffic, which was on-line encrypted and decrypted at the Baudot bit level with a fearsome multi-rotored mechanical device called the Lorenz machine.  Appropriately, the building is now becoming a British museum of computing.

Geeks won't want to miss H Block.  One wing of it tells the whole story of the Lorenz project.  The next photo shows a recreation of a rather impressive rack from the  dedicated intercept station in Kent. Note the battery of RCA receivers plus two HROs, and associated gear.  These fed the intercepts to an Undulator tape inker for storage and transfer to Bletchley for attempted decryption.

At Bletchley, the encrypted traffic was attacked using a series of increasingly large and sophisticated computing machines.  Early versions were like the "Heath Robinson" machine that's been recreated in this room of H Block:

This line of attack led to the famous Colossus, a true computer using 1500 thermionic valves (radio tubes). Certain features in the Colossus design made it more like modern programmable digital computers than the American ENIAC or other such wartime projects.  Toward the end of the war, 10 of these machines were operational at Bletchley.  All were destroyed for security reasons.

Here's the recreated Colossus Mark 2.

The large frame in the foreground is where the inked tape loops were threaded up and run at a high speed (for the time) past optical readers.  Other racks hold the various parts of the computer.  The black battery of switches was used for manual programming.  A series of counters analyzed the bits for statistical patterns useful for determining the proper wheel settings for decryption.  When the operator got it right, resulting plaintext was printed out by a local teleprinter.

This machine was operating at the time, producing the regular 2-second clicking of relays by which Colossus is known.  You can see some of the clustered tubes all pulsing away.  They don't make any of these tube types any more, so it took some real scrounging to find enough to make this machine go.

This recreation of Colossus has been used several times to decrypt leftover WW II Lorenz text, or newer messages encrypted using Lorenz machines or emulations on the PC.  Again, operator insight is very helpful.  In the right hands, Colossus still performs surprisingly well for this application, with decryption times stacking up fairly well against modern equipment.

Bletchley Park's very comprehensive web site is at http://www.bletchleypark.org.uk/ .

All photos Copyright © 2010 Hugh Stegman

EasyPal Issue Resolved As Norton False Positive

After talking to knowledgeable people on the digital SSTV group, I have decided that the "virus" detected by Norton is a legitimate file distributed with the program.

The confusion seems to be stemming from Norton's detection of a file called loop.zip, which contains a Windows library file called loop.dll. Loop.dll has been around for a few years, and it contains routines that are sometimes used with SDRs. However, another file named loop.exe is associated with several known Trojans.

This leaves only the odd question of why loop.zip would be recreated whenever EasyPal ran. After I completely uninstalled EasyPal, this behavior stopped, so there's no evidence that the system is doing it.

I have not tested the latest version of EasyPal, which is only a few weeks old, to see whether it, too stops this behavior. However, I now once again consider it excellent software.

Apologies to the programmers of EasyPal, who have really done a nice job bringing hams a more reliable way to use a complex mode.

Other discussions have centered on the widely known fact that there are probably better anti-virus packages on the market than Norton. While my version is better than the previous two or so, it's still pretty bloated and prone to causing issues such as this one with EasyPal.

Sorry about that.

Possible Issue With EasyPal

Some people might have noticed that the glowing review of the EasyPal software has been deleted from this blog. This is because of various strange virus detection issues that many users, myself included, have gotten since the start of 2010 while using this program.

A rather spirited discussion of this subject is on QRZ. There's another on the DigiSSTV Yahoo! group.

The areas of agreement are as follows:

1. EasyPal detects as clear of malware on all checkers when its files are scanned on first installation.

2. At some point after the first picture is viewed, various different virus checkers start to show various different Trojan loaders in EasyPal's directories. MalwareBytes seems to do this the most often. (There is no agreement on whether or not these are false positives.)

3. After this detection, EasyPal still shows as clear. The alleged virus is in a more recently created file that was not distributed with the original package.

Such a behavior is common to some types of dropper programs, which will download the malware later while not making code changes that will be detected. Sometimes anti-virus programs find the new bad stuff before it runs, and sometimes they don't.

Unfortunately, it is also typical of false positives, given the huge complexity of virus detection lists.

In my own case, running EasyPal would create a zip file named loop.zip, which Norton would "quarantine" as containing a rare Trojan which logs keystrokes and steals all your passwords. I would delete the zip archive, but it would reappear on every subsequent running of EasyPal.

The suspect file inside loop.zip is called loop.dll. Searches show one old (~2008) reference to a QRZ forum thread mentioning a file with this name associated with ham radio software. Perhaps it creates a local loopback so a simplex sound card can feed multiple programs.

There is no other mention of this file anywhere detectable on Google, and a full disk search of my computer (which has at least 30 ham radio programs), finds nothing.

Therefore, there are two main possibilities:

1. Norton is confusing loop.dll with loop.exe, a program dropped by many Trojan loaders to capture keystrokes.

2. Norton is finding malicious code that somehow gets into the EasyPal directory hierarchy via file transfers on the air, or an infected utility which is called on the fly when pictures are viewed. (If so, this is a good reason to transfer them to Irfan View, the way DIGTRX does.)

Everyone will have to draw their own conclusion. In my own case, I am far, far from certain that there is any problem with EasyPal. I still really like it a lot. However, I won't put any version of it back on any of my computers until the issue is resolved one way or the other.

Perhaps I'm erring on the safe side, but that's what I do.

Getting to Bletchley Park

Bletchley Park, as most utility people already know, is a museum at the preserved historical site where ENIGMA and other German encryption schemes were broken. This truly inspired work, which among other things involved the first true modern computer (Colossus) using 1500 vacuum tubes ("valves"), is said to have shortened World War II in Europe by 1-3 years.

Directions in a recent Monitoring Times (not MY column!) on how to get there from London appear to be erroneous. Long time contributor Ken Maltz writes about how he made a recent trip:

... coming up from London, Bletchley is a local stop on the National Rail system. Either take a local train to Bletchley or take an Express train to Milton Keynes and then a local train southbound for just one stop to Bletchley. Once you get to the Bletchley station, there are signs directing you to Bletchley Park; less than a 5-minute walk.

My own visit to London, including a day trip to Bletchley, is a few weeks off. Research has confirmed that Ken's directions do seem to be accurate. There are something like four trains per hour, one of which is an express and stops only at Milton Keynes, so you change trains. Either way, you end up at a station very close to Bletchley.

There's a lot there. More after I see it!

Digital Mode of the "Week:" Hellschreiber

Hellschreiber means "shiny writing" in German. It's an old (1929) German direct printing mode used in World War II. It's inventor was a Dr. Rudolph Hell, which is one more reason to call the mode "Hell" and be through with it.

According to the history here, the original mechanical Hell was a popular alternative to more complex and expensive teleprinters. It was extremely simple. The receiver had two moving parts: a rotating print head and a tape feeder. Copy was printed, in pixels, onto an endless tape of treated paper. There were no carriage returns or line feeds.

The transmitter wasn't a whole lot more complex. A keyboard selected the proper wiper on a rotating drum containing contact strips for all characters. A space was nothing at all - a null frame. The result was a series of simple on-off pulses that could key a 900-Hz audio oscillator (for phone lines or MCW emission), or sometimes straight on-off CW. Today, the audio pulses are sent to a USB transmitter (350HJ2C mode). The narrow bandwidth is achieved through the use of raised-cosine shaping, making the mode less clicky.

This mode obviously lends itself well to computer software, and it is included in most multimode packages. There's also one of those nice stand-alone IZ8BLY programs. All of these use a virtual tape, printing lines of characters across white (or sometimes optionally yellow) strips on the screen.

Hell has the interesting attribute of being completely intended for visual reading by the receive operator. While its creation was and is digital, its reception is fuzzy. This is especially true if the software allows a grey scale, making the mode even fuzzier.

Fuzzy modes are quite the thing right now, since they allow people to do more and better processing than any practical software ever would. Things like "almost" and "that looks right" become a third logic state. SSTV, FAX, and CW Morse telegraphy are also fuzzy modes.

The mode most commonly used today is based on a robust, WWII, military variant named Feld-Hell ("Field Hell" ) You can make jokes like "War is Hell." Everyone else does.

Feld-Hell codes characters into series of on-off pulses, using a simple 7x7 character cell. For better resolution, two half-height pixels are transmitted instead of one full-height pixel. There's no key-up betweeen pixels, so they print together. This is what allows the half-height font smoothing. (It would strongly appear that Dr. Hell had hit upon the idea of sub-pixel fonts.)

This leads to a system where 150 characters are transmitted per minute, with each pulse 8.163 ms long. Effective throughput is 2.5 characters per second at 122.5 baud, or approximately 25 words per minute, which is plenty for hand typing.

Today's tape is a virtual one, drawn on the computer screen, and it's usually white. The audio tone is typically 980 Hz, for zero-axis crossing synchronous with the pixels, also conserving RF bandwidth.

Receiving consists of tuning in the Hell signal until the copy is as clearly black and white as you can get it. Waterfall displays are helpful. The signal sounds like kind of a bzzt bzzt, bzzt bzzt, which can be confused with impulse QRN from sparking electrical equipment, etc.

Weak signals will print lighter in grey scale. As you get down into the noise, the print just becomes harder to read, as opposed to just stopping. While printing can be seriously messed up by the usual HF propagation effects, the human brain can usually sort it out.

QRM is another matter. You wind up with abstract art.

Although characters are inherently in phase, timing errors cause the lines to slope. Computer sound cards are very prone to this. Hellschreiber has traditionally printed the copy

TWICE
TWICE

on the tape, so that one line will always be visible. It's weird, but it works.

A good place to lurk for Hellschreiber is around the amateur calling frequency of 14063 kHz USB. Lesser activity is on 7063, LSB or USB (not important, except for frequency accuracy). Most software also implements Hell in PSK, FSK, and a DX mode, though I haven't heard any of these much. There are also different fonts, which is no small achievement in such a character-based mode. Use of a large font can sometimes improve readability in noisy conditions.

"Digital" Mode of the Week: HF FAX

FAX stands for facsimile, or in this case radiofacsimile. Unlike the more recently developed office FAX machines used over wire telephone circuits, it is completely analog, using FM emission (F3C). It dates from work done by various inventors in the late 19th and early 20th centuries to send pictures over telegraph and later radio.

HF FAX was very widely used in the 20th century to send news photos and even entire newspapers over HF point to point circuits. Machines used huge drum scanners and similar drums to print at the other end. They were very precise, and very, very expensive. Now it can be done with simple computer sound card software, though at considerable loss of precision in this rather fussy mode.

Today's HF FAX uses a continuous FM carrier with a narrow 800-Hz deviation. Usually, anything around 1500 Hz, the lower limit, is reproduced as black, with the brightness increasing until it reaches a white point up around the high limit of 2300 Hz. By ear, fax can make a number of different sounds, but usually it makes a cyclic pulsing with a high-pitched shreik underneath.

Nowadays, instead of using true FM transmitters, the corresponding baseband audio tone is sent to a normal, single-sideband, suppressed-carrier, HF transmitter. The result sounds the same, only displaced in frequency due to the offset from the missing carrier. FAX is tuned in USB, or else it will reproduce as a negative, and the dial should read 1.9 kHz (the tone center) lower than published frequencies. Most of the time, one centers the waterfall display between two marks, and it's tuned in. Slight mistuning has no effect except to possibly wash out the blacks or whites, depending on which direction it is.

Two other parameters are essential for the reception of FAX. The first is called drum speed, though obviously nowadays transmission speed would be a better name. It's expressed in lines per minute. The receiving software must sync to this speed, or the pictures will not reproduce properly.

Far, far the most common speed is 120 LPM. It is used for nearly all weather FAX. Some more complex pictures are sent at 60 LPM, a speed which can sound like a time signal.

The second parameter is Index of Cooperation (IOC), expressed as an integer. This is a really arcane thing also dating from the use of drum scanners. It measures the resolution of the FAX. Nobody really has to know what the IOC measures, just what the number is, and it is nearly always 576. On very rare occasion, it's 288. This is way less important for computer screens than it is for rotating drums.

Those who are really curious as to just what the Index of Cooperation is will be pleased to know that it's commonly defined as the product of the total line length and the number of lines per unit length, divided by Pi. It's measuring the ratio of how much distance the scan steps for a new line to the diameter of the drum. The length of time any single FAX can last is determined proportional to the IOC. At 120/576, the standard weather format, this is 18.8 minutes, which is plenty. Going to 60/576 doubles this, along with increasing resolution, though of course the fax takes twice as long to send.

Now it's all clear, right? :-)

Most FAX software allows the setting of black and white or continuous tone (grey scale) modes. Except for satellite weather images, just about every FAX sent on HF nowadays is in black and white. I'll get some argument here, but I've always just kept it on continuous anyway. Otherwise lines get kind of jagged, and typical HF ionospheric multipath fuzz can get grungy looking in a hurry. Plus you have to change it whenever a satellite image is sent, and then change it back again.

Radiofax typically uses a standard called APT (Automatic Picture Transmission). This allows the unattended reception of faxes. Different bands and services use different versions of this, but the one we're interested in is as follows:

5 sec Start Tone (alternate black and white at 300 Hz)

Phasing (30 seconds of white with one black pulse per line)

Image (may have a white interval for sync)

5 sec Stop Tone (alternate black and white at 450 Hz)

Optional 10 sec black

Different agencies have slight variations on this, and these are usually just enough to confuse amateur software. Even so, one will notice that all the information needed to set parameters and receive faxes is here, except maybe for IOC and that's almost always 576 anyway.

Why more computer programs don't take advantage of this is beyond me. They don't however, and so your received fax is usually displaced (left edge is somewhere else in the screen) and slanted (computer is not printing lines at the exact speed of transmission). There are nearly always ways to fix these, either during or after reception.

Slant is way the more annoying of the two, because computer sound cards really aren't up to the task. They don't have the tight frequency tolerance that an expensive dedicated device would have. Typically, the proper slant compensation has to be found manually for a given station, and then it will vary for others, or even change during a long FAX.

I like FAX because it's radio with pictures. One learns how to read the weather charts pretty fast. They're not that different than the ones on the Weather Channel. Also, the satellite images are as good as the ones on your local TV, and better if you get into colorized WEFAX downlinking on higher frequencies.

Many coast guards and weather offices still send hours of these a day, and since they are being used by boats for serious navigation and safety of life at sea, they won't go away any time soon. Check the various lists and radio loggings for something audible in your area.

More from Charles Brain on the Vista Problem

Charles:

Hello Vista users,

I have done a Google search and it seems that the problem is due to the fact that Microsoft have moved the sound drivers from Kernel space to user space. This has caused the hardware acceleration used by some cards to stop working. Accurate information on this problem is very difficult to come by.

It seems the reason that Microsoft did this was to protect Vista from errant sound card drivers not under their control. They were getting fed up with being blamed for crashes that weren't their fault. There are some other reasons for wanting to move the drivers to user space I have been told.

At the moment I can't see any short term fix to this problem as it appears to be outside my control. I understand that this problem is causing a lot of grief among P.C gamers too as they have lost some of their special sound effects.

I am guessing here but what I think is happening is that when I ask for a 48K sample rate the card is returning something else (possibly 44.1K) and that is why it does not work. I base this guess on the fact that I can get PC-HFDL to start on a Vista laptop and display hfdl packets on the spectrum display (indicating the sound handling is working) what it does not do is decode the actual packets (indicating a sample rate problem).

I am sorry I can't be any more helpful/hopeful than that.

- Charles

Charles Brain: Bad News for PC-ALE Under Vista

From the hflink group on Yahoo:

Hello Folks,

Well I have done yet another Google search to try and find why programs like PC-ALE won't work properly under Vista.

All I can find is that the Microsoft Vista sound development team have completely re-written the Sound subsystem, they have moved it from Kernel space to User space. Apparently the reason they did this was because Microsoft was being blamed for OS crashes by errant sound drivers that were not their fault.

The side effect of this change has been to disable hardware acceleration in a number of soundcards most notably Creative Devices ones. Creative got around the problem by using their version of ALchemy.

I have not tried this but it might help.

Unfortunately this problem with Vista goes places in Windows that I fear to tread so unless some genius comes up with a simple fix Vista support for PC-ALE will never happen. It seems like the only cards that stand a chance of working are the simplest ones with no hardware acceleration.

Looks like my next project will be Linux based!

- Charles

Digital Mode of the Week: PSK31 (Part 1 - Varicode)

Varicode is a Huffman code for use in PSK31 narrow band teleprinting. PSK31 is a binary phase-shift keyed, 31.35-baud mode designed for direct keyboard-to-keyboard ham contacts. Varicode is integral to the overall concept that made PSK31 so well suited to ham radio, despite this low baud rate. In fact, it was the original name for the whole mode that was proposed in 1998 by its developer, an English ham named Peter Martinez (G3PLX).

Like many "major breakthroughs" in radio, the underlying concept has actually been around a while - in this case, since the Morse code. Morse speeds up transmission by making the more commonly used characters shorter, for example a single dit for E. Morse, like Huffman coding, lends itself to tree-shaped decoding algorithms that save a lot of time. Unlike with Baudot, logic can be designed (including in your brain) that bails out of the loop whenever it detects that a character is complete.

The basic Varicode character set is the same as 7-bit ASCII, but the bits aren't, and the framing is completely different. Throughput is a lot faster than if straight ASCII were being sent and everything else was equal. One consideration, however, is that efficiency goes down in languages other than English, or if the traffic is something other than plain lower case text. Either situation begins to deviate from the designed optimum.

The shortest character is the blank space (a single 1 bit), and second shortest is the lower case e (11). Note that all characters, including nulls, end in a 1. This is due to the technical characteristics of the transmission mode, which we'll talk about next week.

Here's the code. It should look familiar, except for the bits.


Dec . Hex .. Char ... Bit Code
....0 ... 00 ... NUL ... 1010101011
....1 ... 01 ... SOH ... 1011011011
....2 ... 02 ... STX ... 1011101101
....3 ... 03 ... ETX ... 1101110111
....4 ... 04 ... EOT ... 1011101011
....5 ... 05 ... ENQ ... 1101011111
....6 ... 06 ... ACK ... 1011101111
....7 ... 07 ... BEL .... 1011111101
....8 ... 08 ... BS ...... 1011111111
....9 ... 09 ... HT ...... 11101111
..10 ... 0A ... LF ...... 11101
..11 ... 0B ... VT ..... 1101101111
..12 ... 0C ... FF ...... 1011011101
..13 ... 0D ... CR ..... 11111
..14 ... 0E ... SO ...... 1101110101
..15 ... 0F ... SI ....... 1110101011
..16 ... 10 ... DLE ... 1011110111
..17 ... 11 ... DC1 ... 1011110101
..18 ... 12 ... DC2 ... 1110101101
..19 ... 13 ... DC3 ... 1110101111
..20 ... 14 ... DC4 ... 1101011011
..21 ... 15 ... NAK .. 1101101011
..22 ... 16 ... SYN ... 1101101101
..23 ... 17 ... ETB ... 1101010111
..24 ... 18 ... CAN .. 1101111011
..25 ... 19 ... EM ..... 1101111101
..26 ... 1A ... SUB .. 1110110111
..27 ... 1B ... ESC ... 1101010101
..28 ... 1C ... FS ..... 1101011101
..29 ... 1D ... GS .... 1110111011
..30 ... 1E ... RS ..... 1011111011
..31 ... 1F ... US ..... 1101111111
..32 ... 20 ... SP....... 1
..33 ... 21 ... ! ..... 111111111
..34 ... 22 ... " ..... 101011111
..35 ... 23 ... # .... 111110101
..36 ... 24 ... $ .... 111011011
..37 ... 25 ... % ... 1011010101
..38 ... 26 ... & .. 1010111011
..39 ... 27 ... ' ..... 101111111
..40 ... 28 ... ( .... 11111011
..41 ... 29 ... ) .... 11110111
..42 ... 2A ... * .. 101101111
..43 ... 2B ... +... 111011111
..44 ... 2C ... , .. 1110101
..45 ... 2D ... - .. 110101
..46 ... 2E ... . .. 1010111
..47 ... 2F ... / .. 110101111
..48 ... 30 ... 0... 10110111
..49 ... 31 ... 1... 10111101
..50 ... 32 ... 2... 11101101
..51 ... 33 ... 3... 11111111
..52 ... 34 ... 4... 101110111
..53 ... 35 ... 5... 101011011
..54 ... 36 ... 6... 101101011
..55 ... 37 ... 7... 110101101
..56 ... 38 ... 8... 110101011
..57 ... 39 ... 9... 110110111
..58 ... 3A ... : .. 11110101
..59 ... 3B ... ; .. 110111101
..60 ... 3C ... < .. 111101101
..61 ... 3D ... = .. 1010101
..62 ... 3E ... > .. 111010111
..63 ... 3F ... ? .. 1010101111
..64 ... 40 ... @ .. 1010111101
..65 ... 41 ... A... 1111101
..66 ... 42 ... B... 11101011
..67 ... 43 ... C... 10101101
..68 ... 44 ... D... 10110101
..69 ... 45 ... E... 1110111
..70 ... 46 ... F... 11011011
..71 ... 47 ... G... 11111101
..72 ... 48 ... H... 101010101
..73 ... 49 ... I... 1111111
..74 ... 4A ... J... 111111101
..75 ... 4B ... K... 101111101
..76 ... 4C ... L... 11010111
..77 ... 4D ... M... 10111011
..78 ... 4E ... N... 11011101
..79 ... 4F ... O... 10101011
..80 ... 50 ... P... 11010101
..81 ... 51 ... Q... 1111011101
..82 ... 52 ... R... 10101111
..83 ... 53 ... S... 1101111
..84 ... 54 ... T... 1101101
..85 ... 55 ... U... 101010111
..86 ... 56 ... V... 110110101
..87 ... 57 ... W... 101011101
..88 ... 58 ... X... 101110101
..89 ... 59 ... Y... 101111011
..90 ... 5A ... Z... 1010101101
..91 ... 5B ... [ .. 111110111
..92 ... 5C ... \ .. 111101111
..93 ... 5D ... ]... 111111011
..94 ... 5E ... ^ .. 1010111111
..95 ... 5F ... _ .. 101101101
..96 ... 60 ... ` .. 1011011111
..97 ... 61 ... a..... 1011
..98 ... 62 ... b..... 1011111
..99 ... 63 ... c..... 101111
100 ... 64 ... d..... 101101
101 ... 65 ... e..... 11
102 ... 66 ... f..... 111101
103 ... 67 ... g..... 1011011
104 ... 68 ... h..... 101011
105 ... 69 ... i...... 1101
106 ... 6A ... j..... 111101011
107 ... 6B ... k..... 10111111
108 ... 6C ... l..... 11011
109 ... 6D ... m... 111011
110 ... 6E ... n.... 1111
111 ... 6F ... o..... 111
112 ... 70 ... p..... 111111
113 ... 71 ... q..... 110111111
114 ... 72 ... r..... 10101
115 ... 73 ... s..... 10111
116 ... 74 ... t..... 101
117 ... 75 ... u..... 110111
118 ... 76 ... v..... 1111011
119 ... 77 ... w..... 1101011
120 ... 78 ... x..... 11011111
121 ... 79 ... y..... 1011101
122 ... 7A ... z..... 111010101
123 ... 7B ... {..... 1010110111
124 ... 7C ... |..... 110111011
125 ... 7D ... }.... 1010110101
126 ... 7E ... ~..... 1011010111
127 ... 7F .. DEL ... 1110110101

Digital Mode of the Week: HFDL

HFDL stands for High-Frequency Data Link. It is the HF band portion of a comprehensive, global, air-ground, communications system that also uses VHF and satellite. The ACARS ( Aircraft Communications Addressing and Reporting System) is another part of all this. Most people associate ACARS with VHF, but the HFDL protocol can carry it as well.

The HFDL standard is ARINC Report 635-3 (HF Data Link Protocols), which can be ordered from the company, Aeronautical Radio Inc, for a price. ARINC is a private company, formerly owned by the airlines, but now contracting with them for communication services.

Like packet radio, HFDL has layers. These are physical, link, and subnetwork. The subnetwork layer isn't important for receiving, since we're just randomly decoding everything on a frequency.

The physical layer is, once again, the actual transmission of data over the radio. HFDL is a single-tone, phase-shift keyed, text-based, error-checking mode with a baseband audio carrier frequency of 1440 Hz. It is tuned in USB, and the 1440 Hz center is critical for decoding. LSB works too, but the dial frequencies won't match the ones in the ARINC database.

Each burst begins with the unmodulated 1440-Hz tone, so that the decoder's automatic frequency control can lock on. This is the scary-sounding "frequency error" that is output by the decoder. Errors within 50 Hz or so can be ignored. This beeping, followed by hiss, is what the mode sounds like.

The symbol speed is fixed at 1800 baud, but the data rate is determined by the exact modulation used. BPSK is 300 bps, QPSK is 600, and 8PSK is 1200 or 1800. 300 is by far the most common, though I've heard it go up to 1200. Tuning error, modulation type, and signal quality are best viewed on a phase constellation display like the one in the PC-HFDL program.

Frequencies are stored in a numbered database, called a system table, which is sent by ARINC to all stations. A few times a year, the table is replaced by a new one with a higher number. The resulting mismatch causes aircraft software to request an update, which we receive too. At least one decoding program (again PC-HFDL) will grab these for its own use, if you're lucky to hear one. Afterward, the frequencies show up in kHz, which is extremely convenient. Otherwise, there are ways to update PC-HFDL manually with system tables found online.

Old databases aren't useless. The frequencies always come from the same pool, and never change that much.

Ground stations pick 2-3 frequencies from the table depending on propagation. This may change every few hours. The frequencies being used by the entire network are sent, two stations at a time, in the "squitter." (Squitter in air comm jargon is an unsolicited information transmission. More on these soon.)

Aircraft can choose frequencies, or even ground stations. If reception exists, they can also switch to satellite or VHF. The comm status is passed to the ground station. All this is automatic, so the crew can just get on with flying the airplane.

Transmission types are uplinks (ground-air), downlinks (air-ground), and the aforementioned squitters. A squitter is always sent every 32 seconds by the ground. It contains various network maintenance data, including all the frequencies (if you wait long enough). It's also a quick propagation check, because you're never more than half a minute from a ground transmission coming from a known location. Of course, aircraft may be heard even if the squitters are inaudible, and vice versa.

HFDL uses a simple form of time-division multiplex. The entire 32-second cycle is divided into 13 numbered slots of 2.5 seconds each. Slot 0 is always the squitter, leaving 1-12 for up- and downlinks. Databursts always occupy all of one slot, though the various overheads of the physical layer reduce the actual transmission of data to 1.8 seconds. Sometimes an uplink with an embedded ACARS message might require a double-length transmission using two slots.

The network assigns the use of these slots, keeping stations from transmitting at once. Assignments are made by ID, a temporary hexadecimal number given each aircraft at logon.

The use of condensed message formats and lookup tables makes HFDL extremely efficient in its use of air time. It's amazing how much can be crammed into a 2-second burst. Most decoders have a "verbose" mode which will output everything. Hundreds of lines with every kind of count and measurement you can think of will scroll madly up your screen, filling your buffer at a merry rate.

Really long ACARS messages, like airport arrival information (ATIS), can be sent in numbered packets (same as on VHF). Otherwise the communication makes use of standard formatted blocks called Protocol Data Units (PDU). This gets geeky in a hurry. Rather than write a 2000-word blog entry, I'll just list them:

SPDU
Squitter Protocol Data Unit
Frequencies and slot assignments, plus network maintenance data

PDU (PREAM)
Preamble Data Unit
Basic negotiation of connection - frequency error, station ID, bit rate, etc

BDU
Basic Data Unit
The smallest data block, from which LPDU are built

LPDU
Link Protocol Data Unit
Larger structure, which in turn makes up the largest ones

MPDU
Media Access Protocol Data Unit
Several LPDU concerning login, aircraft ID, and the ACARS message, if any

HFNPDU
High-Frequency Network Protocol Data Unit
Several LPDU, containing all manner of data, most for network maintenance. The most useful to us is HFNPDU PERFORMANCE, which will usually contain the flight number and GPS position of the aircraft.

Here are the ARINC ground stations. Note that some numbers are skipped:

1 San Francisco, CA
2 Molokai, HI
3 Reykjavik, Iceland
4 New York, NY
5 Auckland, NZ
6 Hat Yai, Thailand
7 Shannon, Ireland
8 Johannesburg, S. Africa
9 Barrow, AK
13 Santa Cruz, Bolivia
14 Krasnoyarsk, Russia
15 Al Muharraq, Bahrain
16 Guam
17 Canarias (Canary Islands)

Interesting RTTY Message from KSM 24 May 08

KSM is the commercial station at the Maritime Radio Historical Society, Pt. Reyes, CA (at the old RCA/MCI maritime and point to point site). In cooperation with the Comm Center group on Yahoo!, which is comprised of former or retired military communicators, it broadcast several RTTY/RATT messages in standard military form.

Here's one of the most interesting ones. All net discipline is exactly as received. The "?" character was used in the message to replace ones that aren't in ITA2. Any format changes, such as stripping leading blanks, were done by Blogger, not me:


VV HNA033
RR RUWMKSM
DE RUMLNHA 0033 1410200
ZNR UUUUU
R 200131Z MAY 08
FM COMMCENTER AT YAHOOGROUPS.COM //NNN7DXB//
TO KSM MARINE RADIO SAN FRANCISCO CA //KSM BCST//
BT
UNCLAS
SUBJ: ACP-127 FORMATTED MESSAGE
REF: ACP-127 TAPE RELAY INSTRUCTIONS ( )
1. THIS IS AN EXAMPLE OF A MILITARY MESSAGE FORMATTED IN
THE ACP-127 TELETYPE TAPE RELAY FORMAT THAT WAS IN USE
IN THE US MILITARY PRIOR TO THE MID-1970S. DURING THE 1970S,
THE MILITARY TELETYPE TAPE RELAY SYSTEM, ALSO KNOWN AS
THE ?TORN TAPE RELAY SYSTEM? WAS SLOWLY REPLACED BY THE NEWER
AND FASTER AUTOMATIC DIGITIAL NETWORK, OR ?AUTODIN?.
2. AUTODIN WAS A HIGH-SPEED, HIGH CAPACITY, COMPUTER CONTROLLED
?SUPER TELETYPE? SYSTEM THAT WAS ALSO CAPABLE OF HANDLING
DATA TRAFFIC IN IBM PUNCHED CARD FORM (HOLLERITH CODE), AND
MAGNETIC MEDIA. IT RELIED ON SERVOS AND TAPE DRIVES, AND LATER,
WAS UPGRADED WITH WHAT WE NOW REFER TO AS HARD DRIVES
THAT WERE ABOUT THE SIZE OF WASHING MACHINES. SOME OF
THE MAIN BRAINS IN THE AUTODIN SYSTEM WERE RCA SPECTRE 70


PAGE 2 RUMLNHA0033 UNCLAS
MAIN FRAME COMPUTERS. MOST ARMY AUTODIN FACILITIES WERE
MAINTAINED BY EITHER PHILCO-FORD OR WESTERN UNION UNDER
DOD CONTRACT. AUTODIN ITSELF WAS FINALLY REPLACED ON
SEPTEMBER 30, 2003 BY A NEW MEDIUM CALLED THE DEFENSE
MESSAGING SYSTEM, OR ?DMS?. DMS OFFERS MORE CAPACITY THAN
DID AUTODIN. IT PERMITS ATTACHMENTS, GRAPHICS, MAPS, MAP
OVERLAYS, LETTERS AND NON-MESSAGE CORRESPONDENCE, FILES,
AND EMAIL TRAFFIC TO BE TRANSMITTED IN A SINGLE SECURE SYSTEM
THAT IS WORLDWIDE IN SCOPE AND OPERATION.
3. ACP-127 PROCEDURES HOWEVER, DIDN"T GO AWAY. MOST US
MILITARY TACTICAL CIRCUITS STILL USED ACP-127 FORMATS UNTIL
THE LATE 1980S, UNTIL THE AUTODIN SYSTEM WAS FINALLY
INTEGRATED IN THE FIELD UNITS. NATO UNITS CONTINUED TO USE
ACP-127 FORMATS, SINCE NONE OF THEIR EQUIPMENTS OR SYSTEMS
WERE COMPATIBLE WITH THE US COMPUTERIZED FORMAT. SYSTEM
COMPATIBILITY IN THOSE DAYS WAS CALLED ?INTEROPERABILITY?.
EVEN TODAY, ACP-127 FORMATS CAN STILL BE FOUND IN SOME
NATO COUNTRIES WHERE INTEROPERABILITY ISSUES CONTINUE
TO PERSIST.
4. TRANSMITTED AS AN INFORMATIONAL SERVICE BY THE


PAGE 3 RUMLNHA0033 UNCLAS
COMMCENTER AT YAHOOGROUPS.COM GROUP. ALL MATERIAL
APPEARING HEREIN IS IN THE PUBLIC DOMAIN.
5. SERVICE AND SUPPORT TO THE TROOPS FROM ONE OF THE
US ARMY"S FINEST COMMUNICATIONS OPERATIONS CHIEFS OF
THE 1ST INFANTRY DIVISION (FORWARD), FORMERLY LOCATED
A COOKE BARRACKS, GOEPPINGEN, NEAR STUTTGART, GERMANY.
BT
0033





NNNN

Digital Mode of the Week: PACTOR

PACTOR® (from Latin "the mediator," also a possible play on PACket plus amTOR) was developed by German hams in the early 1990s. It was originally intended to deal with the limitations of packet radio and AMTOR over noisy and fading HF circuits. It has become something of a de facto standard for HF e-mail systems, not only in amateur bands but also in commercial networks used by ships at sea and by nongovernmental organizations working in isolated areas.

PACTOR was originally based on the clever idea of using the good features of HF packet (robust error checking) and of AMTOR/SITOR (tight sync, short packet lengths), while eliminating the bad ones. The data bursts are longer than SITOR's, greatly reducing the timing demands on equipment. The protocol is better suited to HF than AX.25 packet, meaning fewer retries. Much of the time, PACTOR outperforms both modes in real-world band conditions.

The original mode is called PACTOR-I (Roman numeral one). The company has been speeding it up and adding features ever since, to the point where PACTOR-I is now rather slow and primitive by comparison.

PACTOR-I is a half-duplex, synchronous, ARQ mode which uses connections. The initiating station operates in "master" mode, while the called station is the "slave." Stations then take turns as information sending and receiving stations. The receiving station does a Cyclic Redundancy Check (CRC) on the packets, and transmits a brief ACK/NAK Control Signal (CS). In order to speed things up, a system called "memory ARQ" is used to compare packets and reduce repetition. In the original SCS equipment, this feature used an extremely clever analog algorithm.

There is also a PACTOR-I FEC mode. This does not use connections, but something resembling the "unproto" mode in packet. Frames are repeated and padded out with character 21 if nothing is in the send buffer.

PACTOR-I packet lengths are 96 bits in the slow mode (100 baud) and 192 at 200 baud. The modems are able to choose the appropriate data rate based on error responses from the receiver. PACTOR uses online data compression to further speed up throughput. Text is ASCII using Huffman coding (which prints as garbage unless decoded), falling back to straight ASCII when necessary or for calling.

PACTOR-I modulation is frequency-shift keying (FSK/AFSK), 200-Hertz shift. Like packet, the bits are in the state transitions, so it can be successfully tuned in either USB or LSB without changing polarity. For this reason, amateur mailboxes often list PACTOR frequencies by their center of intelligence, between the two original FSK tones, which then are +/- 100 Hz. LSB dial/window reading will then be the center frequency plus the audio center of your modem or software. On USB, you subtract the audio center.

PACTOR-I has been released for use in any 3rd party products, including modems and multimode sound card programs. It can be considered a standard. Everything else, however, remains completely proprietary to SCS, the German company started by PACTOR's inventors, or its licensees. The company has also worked with large commercial networks such as Globe Wireless to adapt PACTOR into even more proprietary modes.

SCS modems are high-end products for professional use, and they are priced accordingly. There has been some criticism from hams that these prices are a bit out of reach for amateurs. SCS has answered with a simplified PACTOR modem, the PTC-IIex, that lists for "only" 614 Euros as opposed to 1025 Euros for the full-featured version. Of course, either of these prices is a steal compared to the staggeringly expensive WAVECOM and HOKA multimode packages that will do all PACTOR's modes.

Out in the real world, PACTOR-I is used mostly for calling. Some people are still reporting traffic in it, but otherwise you'll be able to tell it's PACTOR and grab a callsign or two, then things will get weird in a hurry as the modems adapt. They'll start to switch quickly through a truly bewildering number of highly advanced modes that remain available only in boxes made or licensed by SCS.

PACTOR-II adds several more compression and coding features, and switches the modem to differential phase-shift keying (DPSK) to save spectrum. The sound changes from the well known lazy brrrrrrp brrrrrrp brrrrrrp to various hisses and buzzes usually otherwise heard in advanced military modes. Throughput increases from 100/200 baud to a best case 1200 bits/sec using compression.

The current hot setup is PACTOR-III, which adds yet more features to the firmware in existing SCS modems. Users can try these features for 20 connects, then a license is required. This one goes at a screaming best case throughput of 5200 bits/sec, though in doing so it becomes very wide indeed (2.4 kHz), with 18 tones and a physical bitrate of 3600/sec.

Here's a list of PACTOR modulations:

PACTOR-I:
FSK, 200 Hz, 100/200 baud

PACTOR-II (uncompressed)
2 tone DBPSK, 200 b/s physical, 100 b/s throughput
2 tone DQPSK, 400 b/s, 200
2 tone 8-DPSK, 600 b/s, 400
2 tone 16-DPSK, 800 b/s, 700

PACTOR-III (uncompressed)
2 tones, 200 b/s physical, 76.8 net data rate
6 tones, 600 b/s, 247.5
14 tones, 1400 b/s, 588.8
16 tones, 3200 b/s, 2039.5
18 tones, 3600 b/s, 2722.1

Pactor-III also has many submodes depending on various combinations of tones and DBPSK vs DQPSK.

In all modems, the maximum speed level can be set by the user.


--
Legal note: PACTOR® is a registered trademark of SCS, Germany.
http://www.scs-ptc.com/

Digital Mode of the "Week:" HF Packet

This is early because I'm going on vacation.

---

"Packet Radio" is an amateur mode used to send data between terminals attached to radios. It really took off in the 80s after the authorization of ASCII on amateur bands. It gets its name from "packet switching," a networking protocol in which data is divided into small blocks (packets) with the address and sequence numbers attached. This allows a station to act as a "node," and connect to multiple users on the same frequency. Incidentally, you're using packet-switching and routing right now, since these are also used in the TCP/IP protocol suite which makes the Internet go.

HF packet, which is what we're interested in, is an adaptation of the VHF packet you might be more used to. It transmits at 300 baud, with a 200-Hz shift, using audio frequency-shift keying (AFSK) of standard single-sideband ham transceivers. Various tone centers have been used by different hardware Terminal Node Controllers (TNCs), with the most common being 2210 and 1700.

The AX.25 link-layer protocol used by amateur packet radio uses a special polarity (or lack therof) called NRZI (Non-Return to Zero Inverted). In this, any bit state transition is a one, and no transition is a zero. Since it's the transitions that matter, mark and space are in practice not relevant. This means that packet can be tuned in USB or LSB with no need to change polarity at the receiver. However, as in RTTY, the receiver dial frequencies are usually (though not always) closer to the listed ones in LSB mode.

Today, software TNCs have pretty much replaced hardware ones, but the underlying link-layer scheme is the same. It's just better hidden. AX.25 uses connections, meaning that one station will connect with the other before exchanging information. However an "unproto" mode is provided for CQs, and a "beacon" mode for all-station-this-net broadcasts. There's also a "monitor" mode, which is what we will use, because it decodes all the packets.

Packets are labeled for type of data, which for our purposes means that they are either control packets or data packets. A lot of control packets are sent, giving the mode a rather high overhead.

The receiving connected station will error-check packets and ask for retries of missed ones. Therefore packet radio, like SITOR-A, slows down as channel noise increases. Even at 300 baud, the need for retries can make real information throughput absolutely glacial, and HF packet just isn't used much for long messages. In extensive monitoring, I've seen a few BBS (Bulletin Board System) connections, a few compressed file transfers (which print as gibberish), and a lot of automatic forwarding of packets (aka "digipeating").

Plain text is 7-bit ASCII. TNCs can switch to 8-bit mode for binary transfers or extended characters, but the one at the other end has to do same.

HF packet sounds like a series of short buzzes. These are much shorter and chirpier sounding than other modes used for e-mail and such. Given the greater chance that long packets will be rejected, it's best to keep the bursts very short.

One interesting mode that is run as an application on top of packet is Automatic Position Reporting System (APRS). This automatically sends the GPS position of the station, or even such data as the weather. It allows hams to track vehicles out in the boonies, or participate in weather observing networks. These are then forwarded to multiple stations, and plotted using slick map software. Obviously, HF has considerable potential here due to its coverage of areas where VHF is unheard of.

The best HF frequency for APRS is listed as 10147.6 USB. This is the worldwide APRS gateway. My receiver gives a 1700-Hz tone center when tuned in this mode. I have it on right now, and an HF station just reported a position in California. This is cool stuff.

KSM Encrypted Broadcast WILL Take Place May 3

KSM's intrepid transmitter engineer has recovered sufficiently to come to the station and make the encrypted RTTY and SITOR-B broadcasts using a classic US military crypto machine from World War II. Details are as follows:

Times: Approximately 1900 and 2100 UTC on May 3.

Assigned frequencies: 8433.0 and 12631.0.

Modes: RTTY and FEC. Baudot transmissions are at 170cps shift, 45 baud. FEC transmissions are at 170cps shift, 100 baud (SITOR-B).

Text will start with a plaintext preamble and will include the settings for the M-209 as well as the key. That will be followed by the encrypted text in five letter groups. Since hardly anyone has an M-209, a software emulator is available here. I have been playing with this, and it's a very slick program.

K6KPH will guard its usual CW frequencies of 7050, 14050, 21050 (3550 on request). Since these frequencies are in the scan with the ship calling frequencies the best bet is to use commercial calling procedure: repeat "K6KPH" (within the limits of FCC identification requirements of course) until the K6KPH operator responds with "DE", then send your call and traffic.

QSL, as always, is to Denice Stoops, PO Box 381, Bolinas, California 94926 USA.

Maritime Radio Historical Society web site

Charles Brain's Web Site Vanishes

Those looking for Charles Brain's web site with the "official" distributions of PC-ALE and PC-HFDL got a rude surprise today when it vanished. Those taking the link got a blank white page with the cryptic, "I am sorry but my website got deleted."

The last "official" stable release of PC-HFDL, version 2.031, is still available on this column's web site. It was put there originally by request of Charles to help with his bandwidth issues, and it is a copy of the official msi file in a zip folder.

Since the beta 2.04 was never "officially" released, I won't put it up unless asked to, even though I have the distribution zip archive, and the program has always worked just fine here.

The latest stable, non-MARS version of PC-ALE is 1.062G. There's a beta of 1.062H available here. This one is really intended for amateur radio use, though I have gotten it to work for utilities simply by changing the frequencies and group names in the QRG file. There has been some grumbling about this program by those who preferred the old, terse, rather inscrutable user interface. However, it's the one in use here.

While checking all this, I notice that the frequency 14109.0 is now the amateur ALE "pilot channel," though 14109.5 will be scanned until July of 2008.