With the 17-year cicadas making their appearance in the eastern United States, VOA Radiogram for the weekend of May 18 and 19 included a picture of a cicada (actually a 13-year cicada from 2011). The picture was transmitted using three modes: SSTV Scottie DX, SSTV P5, and MFSK32.

Lorenzo in Italy sent these images from his reception on 17860 kHz: Scottie DX, P5, MFSK32:

Corrado in Italy, 17860 kHz:

Finn in Norway, 17860 kHz:

Rafael in Colombia on 5745 kHz:

After looking at many, many screenshots, my conclusion is that MFSK32 provided the clearer images than the SSTV modes. Most listeners agreed.

Lorenzo in Italy (near Rome) produced this YouTube video of the entire VOA Radiogram on 18 May 2013 at 1600-1630 UTC in 17860 kHz. 

It even includes the VOA French newscast beginning without accents displaying, during which Lorenzo changed the character set in Fldigi, with the accent showing correctly thereafter.

www.youtube.com/watch?v=YNID1UsZsOY 

Andy in Fredericksburg, Virginia, produced this YouTube video of the entire VOA Radiogram on 19 May 2013, 0230-0300 UTC, on 5745 kHz:

www.youtube.com/watch?v=hY-l1Fth2ig&feature=youtu.be

And on 19 May at 1300-1330 UTC on 6090 kHz:

www.youtube.com/watch?v=6l2PAQX0z4U&feature=youtu.be

Merkouris in Thessaloniki, Greece, received the Radio Australia MFSK test transmission 19 May 2013 at 0830-0835 UTC on 11945 kHz. Because Greece is well outside the Pacific target area, the signal quality was very poor (listen here), which was very good for testing digital text modes. 

The voice content, barely audible after the MFSK ended, is not intelligible. But MFSK16 was copied 100%:

And MFSK32 about 97%:

The MFSK32 Radio Australia logo was a bit fuzzy, though:

This audio of RA recorded in France by Marcel, 19-05-13, 0830 UTC on 11945 kHz, was even worse, because it included moderate interference. Decode of MFSK16 and MFSK32 (try it yourself) is still 100%.

The first Radio Australia test of digital text was successful. It was 18 May 2013, 0830-0835 UTC on 7410 and 11945 kHz.

I saw reports of 100% copy on 11945 from listeners in Germany and Kansas City: pretty good range for one transmitter and one frequency.

In norther Virginia, I listened and decoded on 7410 kHz because it was the signal coming in less well. Despite a fair-to-poor signal level, and a Cuban jammer on adjacent 7405 (listen to and decode audio here), copy of both MFSK16 and MFSK32 text was 100%.

Because the broadcast started a bit late, it ended just as the MFSK32 image was beginning. After the text, Radio Australia switched back to a sporting event. The audio gives you an idea of how a voice broadcast sounds given the same reception conditions.

Roger in Petersberg, Germany, provides this image of his reception on 11945 kHz.

Peter Marks in Sydney wrote this blog post about  the Radio Australia digital text test, and he produced this YouTube video.

The MFSK32 image was included during the transmission at 1230-1235 UTC on 9580 kHz. This is what it looked like in northern Virginia. A bit rugged but not bad for half way around the word:

My text copy on 9580 kHz was 100%. This is what it looked like when MFSK16 switched over to MFSK32: 

Reception by Omar Alfredo Ortiz in Bogota, Colombia, 18 May 2013 at 0830 UTC on 11945 kHz in this YouTube video.

Our experiment with the Scottie DX SSTV mode over the weekend of May 11-12 brought mixed results.

There were some impressively clear images. The picture is  a shortwave curtain antenna in North Carolina of the type used to transmit this SSTV picture.

For example, this from Hugo in Veurne, Belgium, 15670 kHz:

And from Marco, IK0DWN, in Rome, 17860 kHz:

And from Harald, DG0OCS, in Thuringia, Germany, 17860:

And from Mauno in Finland on 15670 kHz:

From Michael in Eschborn, Germany, on 17860:

From Tarmo, ES5NHC, in Estonia, a more impressionist SSTV image on 17860:

And from Bruce, N0NHP, in Colorado, a more Dadaist SSTV image on 17860:

Four YouTube videos demonstrate the reception and decoding of VOA Radiogram from the weekend of May 4 and 5 2013.

Two are from Andy, N9VT, near Fredericksburg, Virginia…

5745 kHz:

www.youtube.com/watch?v=fjqCzhLPYH8

6095 kHz:

www.youtube.com/watch?v=dTioSlwgcVw

Hugh Stegman of Monitoring Times Utility World shows how Flamp worked during his reception in California on 5745 kHz:

www.youtube.com/watch?v=1Q0k9uFykvk

Craig, AV4M, in Tennessee, produced this video of the entire broadcast on 15670:

www.youtube.com/watch?v=a3qFP6WD4Nk

Dezider, OM5NA, in Slovakia, provided these screenshots of his MFSK32 image reception on 4 and 5 May 2013, on 17860 vs 15679 kHz:

Audio of Dezider’s reception of the entire VOA Radiogram on 15670 kHz is available at his SoundCloud page.

Thanks to everyone who sent reception reports, screenshot, audio samples, and other attachments after listening to VOA Radiogram during the weekend of April 27-28.

After six weeks of experimenting with digital text modes, I think we can conclude that the PSK modes are good, MT63, Olivia, and Thor are better, but MFSK remains the best.

We can coin a new acronym: FUM – Fastest Usable Mode. It appears that these would be our FUMs:

• MFSK16 (58 wpm): when poor reception conditions are expected
• MFSK32 (120 wpm): when fair reception conditions are expected
• MFSK64 (240 wpm): when good reception conditions are expected
• MFSK128 (480 wpm): when perfect reception conditions are expected (eg local FM or AM)

During reception of the Sunday 1930 UTC broadcast on 15670 kHz, I experienced a poor signal (being in the skip zone), moderate fading, and local noise. Excellent conditions to test digital text modes. This audio excerpt shows how MFSK16 provided a perfect decode even in these conditions. The Fldigi readout is below, showing MFSK64 on top, MFSK16 on the bottom:

In the April 27-28 VOA Radiogram, a VOA news story was transmitted using Flamp, a program that accompanies Fldigi. Flamp divides text or any type of file into a certain number of blocks, each with a certain number of characters. Then it transmits the file more than once, with subsequent transmissions filling in any blocks that did not have the correct number of characters during the first pass.

To test Flamp, I used the MFSK128 mode. This mode is very fast, thus prone to errors, hence useful for experimentation with Flamp. My own reception of VOA Radiogram on April 28 at 1300 UTC on 6095 kHz provided a textbook example of how Flamp works. After the first of two transmissions, three blocks were missing, i.e. rejected because they had the wrong number of characters :

Then all of the text was transmitted again. Flamp filled in the blocks that were missing:

The result was a perfect html file that could be saved, or pasted to a text editor, and opened in a web browser. The result looked like this:

Many listeners reported reception of a high percentage of the blocks after the second pass, but without 100% of the blocks received, the file could not be opened. This suggests that, next weekend, I should set Flamp to transmit three times. A 3X transmission of Flamp will take more time, so the question for us is whether the slower but more robust MFSK64 transmitted once is a better solution than MFSK128 transmitted multiple times.

For some listeners, Flamp did not work at all. One cause for this is that the beginning code was not not received correctly (“header corruption”). It should look like this:

Any actual use of the Flamp concept in international broadcasting would require a software application that simplifies the process and places it in the background. 

I’ve noticed in the text “dumps” sent by many VOA Radiogram listeners that the line breaks are uneven. This happens when the received text is copied from Fldigi or other decoding software and pasted into a text editor or word processor. 

The problem was that I was pasting text with no line breaks into the Fldigi output window. The solution, suggested to me by Christopher, K6FIB, is to force line breaks at the traditional (from the days of punched cards) 80 characters per line:

I will try to remember to use line breaks from now on. If decoding of digital text via shortwave on mobile devices becomes common, we might  have to adopt a smaller number of characters per line.

Kim