JNX (version) Help

JNX is Copyright © 2011, P. Lutus.

JNX is released under the GPL: http://www.gnu.org/licenses/gpl.html

Please visit http://www.arachnoid.com/JNX for more documentation and to acquire the latest version of JNX.

NOTE: For formatting reasons, users may want to temporarily make the JNX program frame larger to properly read these instructions.

Introduction | Operation | Technical Section
Version History | Resources



Figure 1: JNX text display

Figure 2: JNX time and spectrum display

Introduction

First, to avoid confusion, I have another program named JWX that receives shortwave signals from a computer's sound card and creates graphic weather charts. It's closely related, but not the same. This program, JNX, receives shortwave radio signals from a computer's sound card and creates Navtex weather reports in text form. I hope that clears it up. :)

I travel by boat quite a lot, mostly in Alaska where knowing the upcoming weather is simultaneously important and difficult. I recently realized that laptop computers have evolved to the point that they can serve as rather sophisticated signal processors — all one need do is feed them audio from a receiver tuned to a source of information like a coded weather report, and the computer will decode the signal and display the result.

My earlier project JWX is completely successful at receiving weather charts, so I decided to try to design a Navtex decoder based on the same general principles. Navtex is a bit more difficult to decode than weatherfax signals, but it produces more useful meteorological data in an easily interpretable form.

To use JNX, you only need a shortwave radio, a computer, and an audio patch cord to connect the radio to your computer's sound card. That's all — nothing else is needed.

Operation

If the explanations in this section either make no sense or seem too elementary, please read the technical description farther down the page. It's a longer read and it explains things in more depth. But if you want a painless, terse description that will get you from nothing to Navtex in the fewest steps, this section is for you.

Needed:

Startup

There are many Navtex transmitters and frequencies, more so as time passes, but the canonical Navtex system uses 518 kHz (or 490 kHz and possibly also 4209.5 kHz in some parts of the world). We'll start with the default frequency. Here is a basic startup procedure:

Tuning Navtex

Now for tuning issues. If you live in the continental U.S., Alaska or Hawaii, there will be regular Navtex broadcasts, several times a day, on 518 kHz. This website lists the available U.S. transmitters, locations and broadcast schedules.

The best approach is to sit down at your radio when the Navtex transmitter nearest you is scheduled to broadcast and see what you pick up, but there are some preliminary steps that will help:

In a perfect world, all radios would be able to stay tuned to a particular frequency for hours on end, and we all would have the sort of long outdoor antennas that are ideal for the required wavelength. But for many people, some of these things won't be true. Knowing this, I have designed JNX to automatically accommodate real-world conditions.

If you have a radio that works better in lower-sideband mode, tune to 519 kHz instead, and remember that this reverses the relationship between "mark" and "space," i.e. the relationship between logical one and zero. If you are faced with this situation, the symptom will be that JNX cannot decode the signal regardless of reception clarity and signal strength. The remedy is to reverse the relationship between "mark" and "space" by activating the "Inverted" option at the lower right of the JNX control panel. If reversed mark/space was the problem, within a few seconds JNX will begin to decode the Navtex transmission.

If for some reason it's not practical to tune to either 517 or 519 kHz, for example because your radio has a more favorable sideband frequency where its filtering is more effective, JNX can be adjusted to accommodate this. To set up for a sideband frequency other than 1000 Hz, do this:

Control Detail

First, JNX saves all its control settings between program uses. This means any changes you make will be preserved for the next JNX session. The configuration file is located at (user home directory)/.JNX/JNX.ini.

Here is a detailed summary of the JNX controls (refer to figure 1 above):

Technical Section

This section provides an in-depth look at Navtex, how JNX detects and processes it, and the digital signal-processing methods used in JNX.

Digression: My reason for including this section is to offer a counterexample to the spirit of the modern Internet, in which, as time passes, more and more information of poorer and poorer quality is ransomed for higher and higher prices. It seems that, no matter how trivial a piece of information is, someone, somewhere will ask, "How can I make a buck off this?"

I have long since given up trying to keep people from offering my free programs for sale, or copying my articles without attribution, or accusing me of undercutting their legitimate businesses by offering better computer programs for free. But I continue to post my source code and technical explanations to remind people that, if all information becomes private and ransomed, science dies. Science requires the free flow of information — without open doors, science cannot function. And science is the engine of the modern world.

This is not to say people can't write and sell computer programs. It is only to say that, if they offer programs for sale, they have to be better than my free ones.

The Navtex system is designed to be an automated, medium-range, meteorological and nautical data dissemination scheme. Dedicated Navtex receivers tend to have special antennas that get around many of the problems associated with receiving clear signals at 518 kHz, and such receivers also have database features — they detect messages by type, and allow the user to filter out particular messages. JNX must rely on your shortwave radio and its antenna for its signals, but it can filter Navtex messages by type (a feature explained above).

Message Structure

A Navtex message reveals its origin and message type using letter designators — each transmitter has a unique letter, so you can determine the origin of a received Navtex broadcast at a glance. Here is an example Navtex message:


ZCZC CA58
CCGD11 BNM 0145-11
1. CA-CAPE MENDICINO, DGPS BROADCAST SITE WILL BE UNUSABLE FROM
011700Z-011900Z MAR 11 PRIMARY DAY
021700Z-021900Z MAR 11 ALTERNATE
2. CANCEL BROADCAST AT TIME//021900Z MAR 11//

NNNN

Here is a content breakdown of the message, field by field:

Encoding and Radio Issues

Navtex uses a data protocol called SITOR-B, a 7-bit data format that is able to detect one-bit errors for the reason that a valid SITOR-B character must have four of its seven bits set. This limits the number of legitimate characters to 35, which means there aren't enough characters to support uppercase and lowercase, plus numbers and punctuation marks. The chosen character set is CCIR476, which, astonishingly, is not listed is a reliable way anywhere on the Internet except coincidentally in e-mails of individuals discussing the topic. Needless to say, the only semi-official listing is wrong (some characters are positioned incorrectly).

While we're on the topic, here's my best information about CCIR476, gleaned from multiple sources:

Letters

0123456789abcdef
0[alpha]
1JFCK
2WYPQ
3[beta]G[figs]MXV
4ASIU
5DREN[ltrs]Space
6ZL[rep]HChar32LF
7OBTCR

Figures

0123456789abcdef
0[alpha]
1'!:(
22601
3[beta]&[figs]./;
4-BEL87
5$43,[ltrs]Space
6")[rep]#Char32LF
79?5CR

Notes on these tables:

The SITOR-B Forward Error Correction Transmission Format

A SITOR-B transmission can be thought of as a two-channel broadcast, with channel names "alpha" and "repetition" (I call the second "rep" in the above tables and in this text), transmitted sequentially — one rep byte, then an alpha byte, then a rep byte, etc..

How does the receiver know which channel is which? The answer is that SITOR-B broadcasts are periodically interrupted for spells of what are called "phasing signals", which (I discovered) means a short, uninterrupted sequence of the unique characters alpha (0x0f) and rep (0x66). This allows the receiver to reacquire synchronization if it has lost it.

While transmitting actual data, the "rep" channel transmits a given character, then, three character times (210 milliseconds) later, the alpha channel sends the same character. Like this:

rep rep N A U T I C A L          
alpha alpha alpha alpha N A U T I C A L

The receiver stores the "rep" channel characters in a small buffer just three characters long. Then, when it receives an "alpha" character, it performs a bit count to see if it has the required four set and three clear bits. If it doesn't, the receiver knows the character isn't valid — let's say it was distorted during reception.

In most transmission protocols, the receiver must simply skip that character — after all, it was lost during delivery, it's gone. But the "rep" channel has also transmitted that same character, three character times ago. So the receiver checks the previously acquired character to see if it was received correctly. If it was, the valid character replaces the scrambled one. The idea is that one of the two received characters is likely to be valid, and they're adequately separated in time (210 milliseconds) to improve the prospect that one of them will have been received correctly. That, in a nutshell, is Forward Error Correction (FEC).

Bits and Bytes

At the bit level, SITOR-B is particularly annoying — there's no synchronization bit. Each of the seven bits in the protocol is data, there is no special set-aside bit to help the receiver out. This makes it difficult to stay synchronized with the transmitter, especially in noisy conditions.

When it is beginning reception or has lost sync, JNX uses a sliding-bit strategy — it sequentially and endlessly examines received bits in groups of seven to see if they meet the 4/3 requirement described above. If the test fails, JNX shifts one bit over, adds another received bit, and tests again. Once it has an initial valid group of seven bits, it begins to acquire bits in groups of seven and performs the same test. Once it has acquired three sequential valid groups of seven bits, it concludes that it has reacquired synchronization and begins to print characters. This is all to get around the fact that SITOR-B doesn't have a synchronization bit to signal the edge of characters.

Baud Rate Tracking

JNX uses a tracking scheme to keep its bit detector aligned with the middle of the arriving pulses. It works this way:

FSK Detection

Most radio data transmission schemes use some version of Frequency-Shift Keying (FSK), which has the advantage of being relatively indifferent to amplitude changes. Receiving and decoding FSK transmissions basically means FM detection, or converting frequency modulation into amplitude changes. There are many approaches to demodulating an FM signal, among which are:

For JNX I finally settled on a version of slope detection using narrow-band bandpass filters as discriminators. The method I arrived at tends to cancel out amplitude variations at a key point in the process, as a result of which it has all the advantages of slope detection (simplicity and stability) but little vulnerability to amplitude changes.

Digital Filtering

The basic building block of the JNX signal processing scheme is called a biquadratic filter, a relatively simple kind of filter than can be reconfigured while running (which is why users can change the sideband frequency and other properties while reception is underway). Here is how the initial filtering stages operate:

First, the incoming signal is submitted to a bandpass filter to focus on the spectrum of interest and reject noise at other frequencies. The user control for this filter is identified on the control panel as "Freq. Hz:" or "Receiver sideband frequency".

Then the signal is submitted to two much narrower filters, one tuned to the expected mark frequency, the other to the space frequency. These filters are automatically offset from the bandpass filter's frequency, so the resulting transfer function is consistent and reliable.

Here are some images that show the properties of the biquad filters used in JNX:


Figure 4

The above image shows how "Q" adjustments change the passband width of a biquad bandpass filter, a matter of some great significance during JNX development work.


Figure 5

The above image shows the properties of the three initial filters described above, combined into one image. Notice how much narrower the mark and space filters are compared to the bandpass filter.


Figure 6

The above image shows the overall effect of the three initial filters, plus a mixer that subtracts the space filter output from the mark filter output, or, more precisely:

tf = mark2 - space2

The transfer function image above shows the degree to which the behavior of a filter-based detection scheme can be fine-tuned to achieve a given result. The result is that JNX can successfully decode Navtex transmissions that are barely audible to a human listener (technically, JNX can decode Navtex signals that are 7.5 db below an interfering noise level).

The resulting signal is then submitted to a low-pass filter meant to distinguish between the mark and space characteristic frequencies, at or below about 100 Hz, and the sideband frequency of 1000 Hz.

Here are images (acquired from the JNX Frequency/Spectrum display) that show a noisy, barely-readable signal's appearance at different points in the JNX filtering system:


No filter
  
Bandpass filter output
  
Mark filter output

Figure 7: Overall effect of filtering

The above images show that the mark and space frequencies, unrecognizable in the no-filter image, stand out in the bandpass image, and the mark and space signals are essentially isolated by their respective filters.

JNX State Machine

The JNX scheme for detecting and decoding Navtex transmissions is orchestrated by something called a State Machine. As it happens, all computer programs are state machines, but some of them are explicit about it, with unambiguous, described states. The present state of the JNX state machine is displayed by the green window on the configuration panel (see Figures 1 and 2 above).

Here are descriptions of the JNX state machine states:
State Name Description
NOSIGNAL Initial state — sense signal input. If signal levels exceed minimums, move to SYNC_SETUP.
SYNC_SETUP Initialize arrays and values in preparation for analyzing signal data, move to SYNC1.
SYNC1 Phase 1 synchronization — read signal bits, shift them into a sample byte of 7 bits, repeatedly test for valid parity (4 set bits, 3 clear bits). If a byte meets this criterion, move to SYNC2.
SYNC2 Phase 2 synchronization — having detected one valid 7-bit byte, collect bits in sets of 7 and perform the same test. If four sequential bytes are valid, move to READ_DATA. If one of the new bytes fails, return to SYNC_SETUP.
READ_DATA Read data in 7-bit bytes and test for validity. As long as the data remain valid, print the results. If more than a certain number of bytes fails the test, return to SYNC_SETUP and start over.

System Block Diagram

Here is a diagram of the JNX system:


Figure 8

Version History
Resources

Here are some JNX-related resource locations specific to your system:

Resource
Location
JNX Home Page http://arachnoid.com/JNX
JNX version (version)
User home directory (user home directory)
JNX data directory location (data path)
JNX log file location (log path)
JNX configuration file location (configuration path)
Currently running JNX application location (application path)