开云体育

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