Meet Jason, another new mode for LF.

Version 0.92 was released on 20/01/2002. It is not compatible with the previous versions.

The message above was decoded from a barely perceptable signal (see later in write-up).

Basically, the information is coded in the absolute value of the difference between two frequencies sent sequentially. This has the advantage of not needing a precise initial tuning. A tuning error of a few Hertz is perfectly acceptable. Another characteristic is that, being the frequencies sent one at a time, you don't need a linear amplifier. A class-D mosfet TX will do nicely.

The frequency deltas can assume one of 16 different values. After sending one tone, the next one is shifted by the appropriate amount in the direction of the barycenter of the range. With this method, a total of 32 different slots are needed to be able to send a delta ranging from 1 to 16.

With 16 possible deltas, each baud (a baud is a change in the signal transmitted, in this case a change in frequency) encodes 4 bits (called a nibble), which are not enough for a reasonable alphabet. So we need two nibbles for our alphabet. But now a problem arises : how can we get character synchronization ? In other words, which is the high-order and which is the low-order nibble ? I solved the problem in the simplest way, may be not the optimal one. I used the high order bit of each nibble to encode this info. So the high-order nibble is of the form '1xxx'b, while '0xxx'b is the low-order one. Here xxx stands for the actual information transmitted.

So now there are 6 bits available to encode our alphabet, enough for 64 symbols. I decided that my alphabet would be that that in ASCII code goes from x'20' (the blank) to x'5f'. This allows the transmission of all the letters (upper case only...), the ten digits, and practically all the interpunction symbols normally used.

For this version of Jason (but may change in future versions), I choose the following parameters :

- Each one of the 32 slots is separated from the adjacent by 3 FFT bins, so to guarantee some orthogonality.

- Each FFT bin is roughly 84 millihertz, so the slots are at a distance of roughly 252 millihertz, for a total band occupancy of 8.075 Hz

- Each baud (each tone sent) lasts for roughly 11.89 seconds (the inverse of the FFT bin width)

The program has a capture range of 1.5 times the band width (my arbitrary choice), i.e. slightly more than 12 Hz. The capture range can be easily positioned with the mouse.

It is evident that the combination of the Tx and Rx drifts must be such that, in each 11.89 sec. interval, the frequency must stay in one single FFT bin, i.e. 84 millihertz. To say the truth, a drift from -1 to +1 bin is tolerated, and accounted for, by the program. But let's remain on the conservative side.

If we translate this into short term stability, where short term means a period of 10 minutes, we compute that our oscillator must not drift, each 10-minute interval, not more than 0.084 * 600 / 11.89=4.24 Hz (roughly). This means, at 136kHz, a stability of 31 ppm, which doesn't look like a difficult figure to achieve.

How does Jason interfaces with the radio ? For reception, it's quite easy. Just bring the Rx into audio into the sound card, just as you do now with Argo and Spectran. For transmission, I have envisaged three different modes, to make interfacing the most easy possible.

- Parallel port output : via the Options menu, you can choose between LPT1 or LPT2. The code (ranging from 0 to 31) for the tone to be sent is output, with the strobe pulsed high for 100ms. The Tx condition is indicated by the SelectInput pin being high.

- Serial port output : via the Options menu, you can choose between COM1, COM2 or COM3. The code (ranging from 0 to 31) for the tone to be sent is output. The Tx condition is indicated by the RTS being active.

- Audio output : selectable via the Options menu. If you choose this method, a note is generated using the sound card, with a software implementation of a DDS, with a very long sine table (262144 entries), which ensures low distortion. The center frequency generated is 800Hz.

With these interfacing possibilities, it should be easy to hook-up a Tx to Jason, both if you have the possibility to up-convert the audio tone to the working frequency, or if you use a DDS board, either with a parallel or serial interface.

If you use a DDS board, you will need the following table to set up the frequency to generate, depending on the code output from Jason. Obviously these would be the received frequencies, they will need to be up-converted to 137kHz.

These are also the frequencies generated when using the audio output, provided that your sound card has an exact sampling rate. The encoding is taken care of by Jason, the DDS board task is only to generate the appropriate frequency, according to the received code. I do hope this notes are sufficient to make you understand how Jason works, and how to interface it with a Tx for LF work. Should you have any residual doubts, feel free to contact me at dibene@usa.net

Eager to try the new mode I loaded Jason onto my shack PC and it ran beautifully but I needed a signal to decode. I got another PC and tried that, 256 colour, Jason won't start in 256 colour.... Another try and I have 2 PCs running. I selected sound card mode under "options" "TX port" and when I switched to TX I got nice tones out of one PC. I connected it to the other with great optimism.

To transmit, you can either type the message first and then select TX and it will start sending, or you can switch to TX and type. It sends quite slowly, about one character every 2.5 seconds, so you don't need to type fast, the characters queue up in the transmit window. The first tone sent is 800Hz, centre frequency, followed by a pair of tones for each character.

In receive mode the idea is to get the tones to lie between the two yellow cursors on the Spectral display. If they are off centre you can shift the receive window by clicking the mouse either side of the centre of the window. If you transmit with no text in the TX window, you will get a two-tone sequence at the limits, ideal for centering the receive window. I had everything centred nicely but was only getting the odd wrong character on the display. It was difficult to reduce the local signal enough to prevent it "blooming" across the display, you really need to reduce the input level so you get nice sharp lines. Still no luck though.

It appears that my 200MHz machine is too slow to do the number-crunching required to decode at this speed. (Alberto has now brought out a version for slower PCs V0.91 which has switchable speed. I have now tried it on a 100MHz PC and it works. Get it from the link at the bottom of the page.)

I went and got a faster machine (850MHz) and brought it into the shack. Success! I then generated a weak signal by feeding the tones into my IC735 transceiver and listened to it against real band noise.

The Argo screen-shot below was taken at the limit of decoding. The message "2468 motorway" was being sent (don't ask me why, I just typed it!) and the same audio was going to the PC running Argo as to the PC running Jason.

Even the bit in the middle where it goes very feint was decoded OK, see the Jason screen at the top of the page, I think it's about "6" in the message.

That signal would probably be an "M" copy in QRSS or DFCW so the mode works well in noise. It doesn't cope quite so well when conditions are quiet and the Loran lines are visible in the decoder window. If the Jason signal is not significantly louder than the Loran lines then decoding is upset. Alberto may have a solution to that in future.

He is still developing the software and new versions, including a half-bandwidth version (now implemented, see below) that should fit between Loran lines. Look out for updates.

The mods are :

- Ctrl-Z clears the reception screen
- The blooming of the waterfall trace has been fixed.
- There should be now much less garbled and repeated
   characters when receiving just noise
- The new 17-tone signalling scheme is implemented
- When using audio output, it is possible to apply a multiplying
   factor to the steps between the tones
- A beacon mode is implemented
- Selectable USB/LSB both for Rx and Tx

Regarding this last point, a few notes are in order :

On the transmitting side, the Tx and Jason must be set both
either on USB or LSB. There is no need to announce in advance
which mode the transmission will be, as long as the above
rule is adhered to.

The same holds for the receiving side. Keep both the Rx and Jason
either on USB or LSB, irrespective on how the setting is on the
transmitting side.

A last word about the beacon mode.
The text to be beaconed must be surrounded by braces : {   }
When the opening brace is encountered, then the text found until
the closing brace is endlessly repeated. As an example, suppose
the following is typed :

HELLO ALL { THIS IS A TEST}

What will be transmitted is:

HELLO ALL THIS IS A TEST THIS IS A TEST THIS IS A TEST.....
and so on.

Any text following the closing brace will be ignored.

As usual, any and all reports are welcome

This version has selectable decoders, the original one and one based on Wolf by KK7RA which is better in marginal conditions.

It also has the facilty to analyse a stored wav file so you can record a file with windows sound recorder or similar and try the alternative decoders. Remember to record at 11025 samples/sec.

The TX format remains the same so it is still compatible with previous versions back to 0.92.

Meet Jason.