Long transmission times when FX.25 enabled on TX

[radar27]

Greetings,

When using Direwolf 1.6G from the DEV branch (downloaded and compiled on 6/19/2020) on HF/300 Baud, the transmission times when FX.25 is enabled on transmit is significantly longer - nearly 5x. Attached are two zipped WAV files recorded over the air.

• The file ax25_beacon.wav is a UI frame sent to "AX25" with the text "Testing Direwolf"
• The file fx25_beacon.wav is a UI frame sent to "FX25" with the same text "Testing Direwolf"

ADEVICE plughw:0,0
ACHANNELS 1
CHANNEL 0
MYCALL DWTEST
MODEM 300 1600:1800 7@30 /4
MAXV22 0
AGWPORT 8000
KISSPORT 8001
FIX_BITS 1
IGTXLIMIT 6 10
KISSCOPY

Additionally, a screenshot is attached viewing each track, the ax25_beacon is on top and lasts about 1.5 seconds, the fx_25_beacon is on the bottom and lasts approximately 7.5 seconds.

Listening only to the audio, there is a large portion of the fx25_beacon in the center which does not seem to have the same type of tone variance in the middle for about 5 seconds, possibly a source of the delay.

I understand that FX.25 has some overhead, though I think this longer transmission may be an indication of some other issue. When used in connected mode packet, retry frames are being sent while the original frame has gone through, even with FRACK values of 7000ms or more.

Thanks for this great software. ax25_beacon.zip fx25_beacon.zip

The transmitter is attached to a home brew interface with a hardware based PTT via GPIO pin (no VOX).

73!

[jbrzozoski]

Did you enable FX.25 with a FX25TX line in your config file or a -X option on the command line? What exact parameter did you give to either? I think if you just give it a 1 meaning "yes" it actually enables the RS encoding with the most possible overhead. You probably want to use a value of 16 as a safe value for now. (I think the meaning of this value needs either some tweaking or better documentation.)

[radar27]

This is being started with the -X 1 flag. I do recall there being an option prior (1.6E) to indicate the check bytes (16, 32, 64), but starting sometime in 1.6F (I think), this option was changed to simply -X 1 which follows UZ7HO's soundmodem implementation where the check bytes change with frame size.

Please see "Compatibility with UZ7HO Soundmodem" section of https://github.com/wb2osz/direwolf/blob/dev/doc/AX25_plus_FEC_equals_FX25.pdf

The test frame sent is fairly small, no digipeaters are specified and the entire body of the beacon is "Direwolf testing".

The reason I think something may be off here is that I've done a 1:1 replacement of the Direwolf modem with Soundmodem, which has FX.25 enabled on transmit and the transmission times are nowhere near as long. In some testing I have done, when the frame size is too large, the console indicates something to the effect of "frame size too large, reverting to AX.25" which from what I understand means there is not enough room in the packet for the FX.25 overhead to "fit".

[jbrzozoski]

Yeah, I've seen that document, but I'm not finding anything in git that implements that "1" for autoselect mode.

It looks like John may have accidentally committed a change to the help message for -X but not the actual implementation? I see the help message changed in commit 45136a which are AIS-related changes. I think the back end is still looking for the number of check bytes 16/32/64 or a hard-coded tag number.

[radar27]

Yes it was the help message where I saw the mention of

-X n 1 to enable FX.25 transmit.

I did retest omitting "-X 1" from the startup in favor of FX25TX option in the direwolf.conf file and the issue seemed to persist. I then commented out FX25TX from direwolf.conf and specified "-X 16" from the command line, the beacon time was much shorter. I reran the same test with "-X 32" and "-X 64", in all cases the duration was also significantly shorter. The portion I mentioned in my original post where the tone variance seems to stop is still present in all cases, but it is very much shorter. As another test, I sent the same beacon through UZ7HO's soundmodem and it too had a similarly sounding portion of the transmission. It does appear that there may be a gap between the help menu indicating "-X 1" the value the code is looking for. I'll keep checking back, the usage of FX.25 on HF has made a great improvement in adverse conditions.

[wb2osz]

jbrzozoski wrote:

It looks like John may have accidentally committed a change to the help message for -X but not the actual implementation? Yep, part of it snuck out with other modifications to a file. Sorry for the confusion it caused.

This should be fixed by commit 909b703b7e2c54d17492c14a009c8065c4cc161b. Use "git pull" to get the latest and then rebuild. "-X 1" should now automatically select an appropriate correlation tag based on the frame length. Use "-dxx" command line option for debugging information. That will show the actual tag being used for each transmission..

[radar27]

That got it, thanks for all your efforts!