开云体育

Hi Randy and all interested in this topic,

Below, you'll find my personal views, along with a few recommendations, on the MFSK image mode.

As you wrote, right-clicking in the TX pane and selecting 'Send image...' opens the respective dialog, allowing to load and transmit an image (usually a png, jpg or static gif image).


The special Button X1 is the 'TX speed multiplier' selector. It is described in the 'Fldigi Users Manual 4.2.00' as follows:

The "X1" button is a three-way toggle that allows you to transmit an image file in
X1 - normal and compatible with other modem programs
X2 - double speed, and
X4 - quadruple speed. X2 and X4 are fldigi specific image modes.

Note that the figure indicated on the button is not always in synch with the chosen mode, but the sequence always is 'X1 -> X2 -> X4 -> X1'. Also, the window caption shows the size of a loaded image, but the active speed multiplier setting is not included.

So better try it out before actually going on the air. The X1 standard speed produces a Pic Header such as 'Pic:240x160C;', double speed 'Pic:240x160Cp2;', and quadruple speed 'Pic:240x160Cp4;'. The 'C' is the tag for 'color mode' (omitted in greyscale), while the 'p' may just stand for 'picture' in this FLdigi definition, probably to avoid confusion with the 'x' (in W times H) used for the image dimensions.


- - - - - -


Why offer such different options in the first place?

Note that images are always transmitted per pixel in an analog way within the given MFSK bandwidth (lower frequencies represent darker, higher frequencies brighter colors), left to right, top - down, from the first to the last line at the very bottom. The advantage of analog image transmission is a (usually) shorter transmission time than for a digital transfer, and its tolerance against QRM. Tolerance meaning that noise will be visible as false-colored pixels or lines, but the entire image will not be lost, which usually is the case, if a digital image mode is interrupted in any way, or just too weak. The concept is somewhat similar to the well-known SSTV mode (older and not included in FLdigi), but it is not compatible.

Since the bandwidth and timing precision of an HF channel are limited, there is a reasonable maximum speed that can be realized before the pixels start to get blurred or even shift due to ionospheric effects like Doppler shift and multipath. The speeds chosen for MFSK images equal just about the physical limit, and may, in certain cases, already be a bit beyond, producing certain unintentional artefacts.

Note that transmitting an image takes quite a bit of time. This is defined by the formula (from the FLdigi Help file, with W and H being the number of pixels in width and height, respectively):

Time(sec) = W * H / 1000 for black and white

Time(sec) = W * H * 3 / 1000 for color

Color mode thus takes 3 times the B/W time, because each pixel is transmitted in a sequence of 3 color channels, red, green, and blue, which allow a very high number of colors to be represented, plus a brightness from black to white.


- - - - - -


In practical terms, consider a few things prior to transmitting.

Let's assume you have a nice image of the Moon you wish to send via MFSK. It is 800 x 1600 pixels, with the Moon roughly covering the central portion.
In your preferred graphics editor, first trim the image to only contain the Moon plus a bit of a dark 'frame' around it, whatever you visually prefer (there is no limit as to the W/H ratio, anything will work).

The dimension may now be something like 300x600. May look nice, but consider the TX time:

Time(sec) = W * H * 3 / 1000 for color means 300*600*3/1000 = 540 seconds, or nine (9) minutes! Is this really what you wish to (and can) put on the air?

Since the image content, the Moon, is almost perfectly black and white, you may wish to decide sending it in greyscale (Button 'Xmit Gry') instead, cutting the TX duration by 3, to 3 minutes.


Anyways, this may still appear a bit long, especially for a first try or a quick 'surprise' greeting. This is where scaling down a source image to a 'reasonable' size for transmission is the solution:

In your preferred graphics editor, scale the image down to 200x400 pixels for example, which cuts the greyscale TX duration down to 1.33 minutes, or 01:20, which appears to be a lot more appropriate for an MFSK image. You may try to (suitably) sharpen it before transmission, which may, yet to a lesser extent, enhance the impression of the received image.


On the other hand, if you agree upfront with your QSO partner to send a higher resolution image, taking into account the long TX duration, that's okay, as long as you're sure that your rig can handle an uninterrupted 100% power output of the given number of minutes without overheating. Unless you know for sure it will be OK, never aspire to use maximum PA power in digital modes. A rule of thumb calls for max. 20...30% of the peak power output, but, of course, this depends on the rig and its actual cooling situation.


The above example was specifically chosen to show the threefold TX speed advantage of a B/W or rather greyscale image. For color images, you may instead shrink the size a bit further to keep the overall TX time at bay. Generally speaking, it's a good practice to decide upfront which (part of an) image makes most sense to transmit, and try to avoid unnecessary 'borders' (which take up lots of extra time), thus literally focusing on the 'important' part of the view. Sometimes a suitable detail in higher resolution is more appealing than a full 'landscape' view.


- - - - - -


Back to the speed multiplier: You may say well, I'd rather use a higher resolution image and simply select a higher speed. Which is fair enough, as it actually cuts the above-mentioned TX duration by the respective factor, but there's no free lunch in physics (and thus the MFSK analog image transfer).

Speed factors above 'X1' will reduce the (visual) resolution accordingly, leading to more blur in the received images.

Also, due to the higher speed, ionospheric effects may show more distinctly, e.g. a light horizontal jitter (offset) between lines or double edges (echoes), usually caused by multipath and the resulting variations in the signal path and the travel time of the signal.

So in the end, if the image subject really needs size, you may opt using an X2 or X4 multiplier mode, but don't expect the result to be any clearer when received. Yet it may, admittedly, be more visible and impressive from a certain distance from the receiving screen, if that is something to factor in.


- - - - - -


Finally, you may ask, in which way the different MFSK modes differ in terms of image transmission.

Even more so, since the timing calculations described above are common for all image capable MFSK modes!

The very noticeable difference is in the resulting image resolution (clarity or sharpness) of the received image.

If you try to send an image in MFSK16, it will take just as long as in MFSK32 or MFSK64, but it will appear rather blurry.

MFSK32 will produce a visibly clearer result, and MFSK64 should look quite 'sharp' in comparison, but these modes will also use a respectively higher signal bandwidth.

The MFSK128 mode may not even fit into a ham bandwidth allocation, but it should theoretically be even clearer upon reception. On the other hand, any signal degradation may then (more quickly) lead to false-colored pixels, and thus the result, over an HF path, may not appear any better overall.


- - - - - -


If you want to get a good idea of what MFSK text and image transmissions are capable of, tuning in to Kim KD9XB's Shortwave Radiogram programs, which are broadcast on shortwave several times a week, and usually include text and images in MFSK32, MFSK64, or both. Info and schedules are found at 'http://swradiogram.net'.


- - - - - -


I hope this explains a bit of the background and practical usage of the MFSK image transmission.


Best regards and 73s

SWL Tobias
.-.-.