I would also like to point out another technicality about the OFDM modes in FLDigi in general. They technically are just multi-carrier modes, not OFDM. OFDM means that the spacing of the carriers is such that the center frequency of each carrier is located at the zero points (nulls) of each adjacent carrier. This produces a spectrum with a flat top. However, in FLDigi, the so-called OFDM modes are such that the zero points (nulls) of each carrier are located at the nulls of the adjacent carriers. So this makes them actually not true OFDM modes. Please fix this. You could get higher data throughput (or at least reduce the bandwidth) if you were to cut the carrier spacing in half, so that they were true OFDM modes where each carrier was located at the null of the adjacent carriers.

Hi Randy,

First of all, the mismatch between the speed factor displayed on the button and the actually used one is what I had described before, saying 'Note that the figure indicated on the button is not always in synch with the chosen mode'. I don't know why this happens, it might be a bug of some sort. That's why I recommended 'So better try it out before actually going on the air'.


The setting should make a very noticeable difference in TX/RX speed, but while the Button only affects transmission, the reception is adapted automatically, based on the Pic header and its suffix: either none, p2, or p4.

I attach a short audio file that you can play back in FLdigi via File - Audio - Playback (select all files (*.*) and then the audio file), after setting fldigi to MFSK64 at 1500 Hz audio. If should decode 3 (greyscale) images in a row:

PM5544_283x227_MFSK64_Pic_Mode_Test_X1+X2+X4_2025-02-16.ogg <- This is the audio file to test the 3 speeds.
PM5544_283x227.png <- the original image (in color), which was sent as greyscale to have a shorter duration.
pic_2025-02-16_175606z_X1.png <- original speed [Note there's no suffix in the Pic header.]
pic_2025-02-16_175654z_X2.png <- double speed. [Please don't ask me why suffix 'p4' is used for double speed...]
pic_2025-02-16_175721z_X4.png <- quadruple speed. [-... and suffix 'p2' in this case, for quadruple speed. I just don't know.]

You see the degrading decoding quality, as the speed increases? Obviously, you could send a larger image with 4 x the area (WxH) in X4 mode during the same time as the original at standard speed, but then, the overall image quality will not be any better, just the size of the image appears visibly bigger. Note that I have quite intentionally heavily compressed this audio file, leading to an unusually small file and rather poor quality. But this way, it kind of behaves like a (stable and reasonably strong) HF path, giving an idea what a receiving station might see in each of the settings.


Your picture (showing very good reception actually!) doesn't look /skewed/ (or \the other way\), which would indicate a sound card speed calibration issue, but your otherwise straight image has partially shifted sideways, let's call it 'sliced'. This usually happens when the PC is busy doing other 'things' (blame it on multitasking or a bit of an overload of other programs drawing much CPU power) and FLdigi (or even your sound card) momentarily doesn't get the continuous CPU support it needs to convert the image without interruption. Any brief pause in the decoded bitstream (although it's analog via the radio, before the ADC conversion within the sound card) will cause an immediate side shift of the remainder of the image, and possibly a tiny lost portion. I have side-shifted back the respective parts in your screenshot and now it looks quite good. You'll find the original (full) decoded image with a date/time stamp in your data folder under fldigi.files \images. Check the location via Menu - File - Folders... - WEFAX images, and it may be called something like 'pic_2025-02-15_205141z.png'. The full path usually is 'C:\Users\<USER NAME>\fldigi.files\images', unless you have chosen a different location.


You can sometimes find a direct root cause for this image 'slicing' behavior, e.g. WSJT-X suddenly starting to decode something (FT8) in the 'background', or a scanner checking for undesirable files, when an e-mail arrives or a website opens, or the like, just to name a few processes that may draw a lot of system resources. If you have or suspect such an issue, try to stop this interfering process and have FLdigi run as the only 'demanding' application, if possible. You may also try to generally increase the FLdigi process priority, e.g. via the Windows Task Manager, Find 'fldigi' in the Applications list, right-click it and choose 'Go to the process'. In the Processes list, right click fldigi.exe, choose 'Define Priority' and set it to 'High' for example. This may (or may not) have a positive effect, provided it's a software decoding issue, rather than the sound card itself. In the Process Manager, in Processes view, you may also try to find other processes that demand a lot of CPU, if you klick the CPU column to have the list sorted accordingly.


On the other hand, if, during image reception, you mouse click around within FLdigi, e.g. changing the frequency offset, or even click onto the RX image preview, this may also cause such image reception disruptions.


I attach a couple of the views mentioned above as examples:


Re_winfldigi_Sending_Pics_2025-02-16_1631_inline0_A)_original_view.png

Re_winfldigi_Sending_Pics_2025-02-16_1631_inline0_B)_straight_view.png

Re_winfldigi_Sending_Pics_2025-02-16_1631_inline0_C)_straight_image.png

Re_winfldigi_Sending_Pics_2025-02-16_1631_inline0_D)_skewed_L.png

Re_winfldigi_Sending_Pics_2025-02-16_1631_inline0_E)_skewed_R.png


If actual skewing occurs, this is caused by a mismatch between the TX and the RX sound card calibration. An absolute reference can be found by calibrating the RX sound card setting using a precise Time Signal, e.g. WWV. It's described in the FLdigi Help file in the chapter 'WWV codec PPM measurement'.

I also attach my 'FLdigi_Soundcard_ppm_Calibration_Recipe_2024-12-10.zip' in case you need it for yourself or someone else sending /skewed/ images.


Hopefully this explains what has happened and what to try to improve the result.


73s from Bavaria

SWL Tobias
.-.-.

make a copy, and edit the copy. if you srew it up, delete and make a new copy.

?

Thanks for the information Tobias.? Except when I transmit a picture in MKSF64 it indicates Cp4 when selecting x2 and Cp2 when selecting x4.?

?

Here's a picture I received from a local station on 40 meters during our test of sending pictures.? We were switching between x1, x2, and x4. Didn't make a difference.?

?

Why causes this picture to be skewed?

?

-Randy

GaDay All! I went back and installed previous versions of FLrig? 2.0.0 thru 2.0.03.

Those worked fine thru 2.0.03. So all is good in the world. Works just fine with the latest FLdigi build.

Dave W1HKJ, if you are reading this was not able to run the Event log on either 2.0.05 or 2.0.05.93.

It just would not provide any telemetry. Anyway it's working.?

?

? ? ? ? ? ? ? ? ? ? ? ? 73 de Steve KB6HOH

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
.-.-.

I'm sending pictures in MFSK64. I load the picture, click x1, XmtClr. In the send window it reads: "200x254Cp4;"?

?

What is does "Cp4" indicate?

?

Thanks.

?

-Randy

Any one know how to use Any Desk or Team Viewer to look at my settings for PSK in my computer?

Thanks

--

The average output power on PSK will only be about 15 % of peak power to insure the transmit signal is clean and not producing? unwanted side bars.? A 20 watt transmitter should never exceed 3 watts on PSK.

Dave I am trying to set up for PSK using FLRIG/FLDIGI

?

--

Hey Don! Good to hear from you. It's been awhile since we last connected.

I am NOT a Fan of the Omirig BUT I will give it a try. My plan is to head on down later today to our Club House in Mill Valley.

I did have it working when I 1st installed VarAC? here at home. I'm glad Irad added FLrig which as far as I'm concerned is much better.

I'm also going to a different CI-V Cable (FTDI) just to see if that makes a diff. If NO change there, I'm going to go back to previous vers of FLrig and try those.

I haven't installed Winlink Express or the VARA-HF Modem on the Clubs PC yet but, that's on my list as well. At-least I have JS8Call and FT8 working on that PC.?So I know CAT Control does work.

Since the last time we connected have now have 2 locations for my Winlink Gateways. I still have the 1 here at home on VARA-HF (80m-10m) VHF (Packet/VARA-FM) and UHF (VARA-FM).

The HF Gateway Radio is a Icom IC-7300. I have 2, 7300's running here and the 2nd is my everyday radio.

The VHF Radio is using a Alinco DR-135T MKIII and I'm using the DigiRig Lite (Formerly a Rim-Alinco) so I can run Packet and VARA-FM without a conflict.

The UHF Radio is a Alinco DR-435T MKIII also running a Digirig Lite (Formerly a Signalink USB). I took down my 220mhz Radio since NO activity there.

I now have for my normal usage the Icom IC-9700 and the Icom IC-705.

The 2nd Gateway is at our Club House in Mill Valley. Again running the Alinco DR-135T MKIII/DR-435T MKIII. The Digirig Lite on VHF Packet/VARA-FM and the Rim-Alinco on VARA-FM on the UHF Radio.

During the day look for me on VarAC on 20m. Either on 14.088 talking to Larry K7LRB in Arizona or on the Call Channel 14.105.

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?73 for now de Steve KB6HOH

?

Which mode Dave?