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?

Dave, Tnx for your reply. Right now all I'm concerned about is getting FLrig working.

Once I get FLrig working then I can focus on FLdigi and the VarAC program as well.

I have tried also RigCAT and Hamlib as well and same problem.

I'm going to try some earlier versions of FLdigi and FLrig.

?

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

?

Well I have been looking at some You Tube videos concerning setup for digital modes. They suggest using the "LINE-IN" from the menu of the G90. Using FLRIG for rig control but I have the radio set for 20 watts and I am only getting out about 2 watts. The red light comes on for transmit like it should. Still no luck for full 20 watts out. Checked the codecs and they are fine. Using here a SignaLink USB. Have tx set to max still no 20 watts.

Any help would be appreciated.

Dave

--

sent by ve3wej on samsung s21+