|
Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.
thanks
|
Other end must be transmitting the TXID before you can receive it.?
On Mon, Nov 4, 2024 at 5:31 PM, Al via groups.io <k2hro@...> wrote: Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.
thanks
|
Hi Al,
You wrote: 'Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.'
Here's the explanation (hopefully). I attach 2 screenshots and a config file in an archive (it's from an answer to earlier Q&A thread, thus the unrelated name).
A) First of all, as you have noted, FLdigi now distinguishes between 'Passband' and 'Min BW detection'. Passband will decode and follow RSIDs within the *entire* spectrum, while, with 'Passband' unchecked, the decoding range is limited to the bandwidth between the 2 dotted vertical lines in the waterfall. The witdh of this limited bandwidth can be set in the Config | IDs | RSID Dialog. At least as of FLdigi ver4.2.06, you may RightClick the RxID button in the main FLdigi window and check/uncheck 'Passband' there, very practical. If there are no vertical dotted limit lines visible in the waterfall, 'Passband' is activated and all received RSIDs will be decoded.
B) But for RSID to work, there's another selection you may need to set to your needs:
In FLdigi, RSID can be (de)activated *per mode*, which may not be very intuitive, but is certainly way better than no choice at all. In the attached screenshot 'FLdigi_Configuration.png', you'll see a Button 'Rx modes' and another Button 'Transmit modes'. They are entirely independent, but only activating the RSID function for all 'your' modes in both TX and RX will make these useful features available in both cases. Not visible in my RsID Dialog screenshot is another setting 'Disable frequency change', which, if activated, still allows RSID decoding, but then it's up to you to manually change frequency. This may be useful at times, e.g. if you are in a QSO and don't want to change the precise tuning currently set and used. Especially if a mode needs properly centered tuning for best decoding results (e.g. BPSK or narrow MFSK modes), following the received RSID may not be helpful, because the RSID tags are only 'accurate' to within steps of 5 Hz, which may be worse than what you can and wish to set manually.
C) Just FYI:
The RxID notifier is widely user-configurable, and if you add a few empty lines before and after an easily visible RSID tag text, the result may look like this (an example from Shortwave Radiogram):
- - - - - -
Shortwave Radiogram now changes to MFSK64 ...
----------------------------------------------------
RSID: <<2024-10-17T23:38Z MFSK-64 @ 1499>>
----------------------------------------------------
This is Shortwave Radiogram in MFSK64
Please send your reception report to radiogram@...
- - - - - -
I attach my 'notify.prefs' as stored in 'C:\Users\ < U S E R N A M E > \fldigi.files', which should give you the RSID tag layout shown above, should you be inclined to try it out (be sure to close FLdigi if you copy this file into your folder - and backup your existing file before, in case you wish to return to the previous settings). The leading and trailing empty lines are defined in 'notify.prefs' by the NewLine token backslash-n (\n = 1 new line, \n\n = 1 new and 1 empty line etc.), and you can easily adapt this to your needs in any text editor. The tiny preview in the 'Notifications' Dialog may not correctly show such extra lines etc., but they will be visible in the RX window. Most user-configurable settings are available under Menu - Configure - Notifications, others under Menu - Configure - Config Dialog - IDs [+] RsID, and the attached (commented) 2nd screenshots shows some of the settings to choose from.
- - - - - -
Good luck and enjoy FLdigi, it's really a great piece of free software, thanks to Dave's generous work he puts into ever improving it...
Vy 73 SWL Tobias
.-.-. Am Dienstag, 5. November 2024 um 00:31:08 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.
thanks
|
No luck decoding RSIDs with ver 4.2.05, 4.2.07, or an older version. I can see and hear the 2 sec RSIDs. After 5 hours of watching, it decoded only once. It used to decode all the time. T/R is great. Using 4,800,8,N,1 which also works for WSJT-x on an Icom 756-2 and a Signalink. See attached. Btw, I did see something perhaps on Radio Reference by the author discussing an RSID problem early in 2024 but can't find it now.
What versions work?
Thanks for your time.
On Tuesday, November 5, 2024 at 09:13:25 AM EST, T? via groups.io <tsquare123@...> wrote:
Hi Al,
You wrote: 'Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.'
Here's the explanation (hopefully). I attach 2 screenshots and a config file in an archive (it's from an answer to earlier Q&A thread, thus the unrelated name).
A) First of all, as you have noted, FLdigi now distinguishes between 'Passband' and 'Min BW detection'. Passband will decode and follow RSIDs within the *entire* spectrum, while, with 'Passband' unchecked, the decoding range is limited to the bandwidth between the 2 dotted vertical lines in the waterfall. The witdh of this limited bandwidth can be set in the Config | IDs | RSID Dialog. At least as of FLdigi ver4.2.06, you may RightClick the RxID button in the main FLdigi window and check/uncheck 'Passband' there, very practical. If there are no vertical dotted limit lines visible in the waterfall, 'Passband' is activated and all received RSIDs will be decoded.
B) But for RSID to work, there's another selection you may need to set to your needs:
In FLdigi, RSID can be (de)activated *per mode*, which may not be very intuitive, but is certainly way better than no choice at all. In the attached screenshot 'FLdigi_Configuration.png', you'll see a Button 'Rx modes' and another Button 'Transmit modes'. They are entirely independent, but only activating the RSID function for all 'your' modes in both TX and RX will make these useful features available in both cases. Not visible in my RsID Dialog screenshot is another setting 'Disable frequency change', which, if activated, still allows RSID decoding, but then it's up to you to manually change frequency. This may be useful at times, e.g. if you are in a QSO and don't want to change the precise tuning currently set and used. Especially if a mode needs properly centered tuning for best decoding results (e.g. BPSK or narrow MFSK modes), following the received RSID may not be helpful, because the RSID tags are only 'accurate' to within steps of 5 Hz, which may be worse than what you can and wish to set manually.
C) Just FYI:
The RxID notifier is widely user-configurable, and if you add a few empty lines before and after an easily visible RSID tag text, the result may look like this (an example from Shortwave Radiogram):
- - - - - -
Shortwave Radiogram now changes to MFSK64 ...
----------------------------------------------------
RSID: <<2024-10-17T23:38Z MFSK-64 @ 1499>>
----------------------------------------------------
This is Shortwave Radiogram in MFSK64
Please send your reception report to radiogram@...
- - - - - -
I attach my 'notify.prefs' as stored in 'C:\Users\ < U S E R N A M E > \fldigi.files', which should give you the RSID tag layout shown above, should you be inclined to try it out (be sure to close FLdigi if you copy this file into your folder - and backup your existing file before, in case you wish to return to the previous settings). The leading and trailing empty lines are defined in 'notify.prefs' by the NewLine token backslash-n (\n = 1 new line, \n\n = 1 new and 1 empty line etc.), and you can easily adapt this to your needs in any text editor. The tiny preview in the 'Notifications' Dialog may not correctly show such extra lines etc., but they will be visible in the RX window. Most user-configurable settings are available under Menu - Configure - Notifications, others under Menu - Configure - Config Dialog - IDs [+] RsID, and the attached (commented) 2nd screenshots shows some of the settings to choose from.
- - - - - -
Good luck and enjoy FLdigi, it's really a great piece of free software, thanks to Dave's generous work he puts into ever improving it...
Vy 73 SWL Tobias
.-.-. Am Dienstag, 5. November 2024 um 00:31:08 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.
thanks
|
Can you verify that the
transceiver is operating in USB?
David
On 11/6/24 13:50, Al via groups.io
wrote:
toggle quoted message
Show quoted text
No luck decoding RSIDs with
ver 4.2.05, 4.2.07, or an older version. I can see and hear
the 2 sec RSIDs. After 5 hours of watching, it decoded only
once. It used to decode all the time. T/R is great. Using
4,800,8,N,1 which also works for WSJT-x on an Icom 756-2 and a
Signalink. See attached. Btw, I did see something perhaps on
Radio Reference by the author discussing an RSID problem early
in 2024 but can't find it now.
What versions work?
Thanks for your time.
On Tuesday, November 5, 2024 at 09:13:25 AM EST, T? via
groups.io <tsquare123@...> wrote:
Hi Al,
You wrote: 'Using 4.2.05 Win, it won't decode RSIDs.
The RxID is green but 'ENABLED' under notifications is
yellow. I'm using FLRIG with it. Passband is
UNchecked.'
Here's the explanation (hopefully). I attach 2
screenshots and a config file in an archive (it's from
an answer to earlier Q&A thread, thus the
unrelated name).
A) First of all, as you have noted, FLdigi now
distinguishes between 'Passband' and 'Min BW
detection'. Passband will decode and follow RSIDs
within the *entire* spectrum, while, with 'Passband'
unchecked, the decoding range is limited to the
bandwidth between the 2 dotted vertical lines in the
waterfall. The witdh of this limited bandwidth can be
set in the Config | IDs | RSID Dialog. At least as of
FLdigi ver4.2.06, you may RightClick the RxID button
in the main FLdigi window and check/uncheck 'Passband'
there, very practical. If there are no vertical dotted
limit lines visible in the waterfall, 'Passband' is
activated and all received RSIDs will be decoded.
B) But for RSID to work, there's another selection you
may need to set to your needs:
In FLdigi, RSID can be (de)activated *per mode*, which
may not be very intuitive, but is certainly way better
than no choice at all. In the attached screenshot
'FLdigi_Configuration.png', you'll see a Button 'Rx
modes' and another Button 'Transmit modes'. They are
entirely independent, but only activating the RSID
function for all 'your' modes in both TX and RX will
make these useful features available in both cases.
Not visible in my RsID Dialog screenshot is another
setting 'Disable frequency change', which, if
activated, still allows RSID decoding, but then it's
up to you to manually change frequency. This may be
useful at times, e.g. if you are in a QSO and don't
want to change the precise tuning currently set and
used. Especially if a mode needs properly centered
tuning for best decoding results (e.g. BPSK or narrow
MFSK modes), following the received RSID may not be
helpful, because the RSID tags are only 'accurate' to
within steps of 5 Hz, which may be worse than what you
can and wish to set manually.
C) Just FYI:
The RxID notifier is widely user-configurable, and if
you add a few empty lines before and after an easily
visible RSID tag text, the result may look like this
(an example from Shortwave Radiogram):
- - - - - -
Shortwave Radiogram now changes to MFSK64 ...
----------------------------------------------------
RSID: <<2024-10-17T23:38Z MFSK-64 @ 1499>>
----------------------------------------------------
This is Shortwave Radiogram in MFSK64
Please send your reception report to
radiogram@...
- - - - - -
I attach my 'notify.prefs' as stored in 'C:\Users\
< U S E R N A M E > \fldigi.files', which should
give you the RSID tag layout shown above, should you
be inclined to try it out (be sure to close FLdigi if
you copy this file into your folder - and backup your
existing file before, in case you wish to return to
the previous settings). The leading and trailing empty
lines are defined in 'notify.prefs' by the NewLine
token backslash-n (\n = 1 new line, \n\n = 1 new and 1
empty line etc.), and you can easily adapt this to
your needs in any text editor. The tiny preview in the
'Notifications' Dialog may not correctly show such
extra lines etc., but they will be visible in the RX
window. Most user-configurable settings are available
under Menu - Configure - Notifications, others under
Menu - Configure - Config Dialog - IDs [+] RsID, and
the attached (commented) 2nd screenshots shows some of
the settings to choose from.
- - - - - -
Good luck and enjoy FLdigi, it's really a great piece
of free software, thanks to Dave's generous work he
puts into ever improving it..
Vy 73 SWL Tobias
.-.-.
Am Dienstag, 5. November 2024 um 00:31:08
MEZ hat Al via groups.io
<k2hro@...> Folgendes
geschrieben:
Using 4.2.05 Win, it
won't decode RSIDs. The RxID is green
but 'ENABLED' under notifications is
yellow. I'm using FLRIG with it.
Passband is UNchecked.
thanks
|
Yes it is in USB. I uninstalled, rebooted, and reinstalled. I even deleted folders. When I reinstalled, it populated the old info such as my call sign. I'm trying to find where the old data is stored so I can delete that too.
On Wednesday, November 6, 2024 at 04:12:44 PM EST, Dave <w1hkj@...> wrote:
Can you verify that the
transceiver is operating in USB?
David
On 11/6/24 13:50, Al via groups.io
wrote:
No luck decoding RSIDs with
ver 4.2.05, 4.2.07, or an older version. I can see and hear
the 2 sec RSIDs. After 5 hours of watching, it decoded only
once. It used to decode all the time. T/R is great. Using
4,800,8,N,1 which also works for WSJT-x on an Icom 756-2 and a
Signalink. See attached. Btw, I did see something perhaps on
Radio Reference by the author discussing an RSID problem early
in 2024 but can't find it now.
What versions work?
Thanks for your time.
On Tuesday, November 5, 2024 at 09:13:25 AM EST, T? via
groups.io <tsquare123@...> wrote:
Hi Al,
You wrote: 'Using 4.2.05 Win, it won't decode RSIDs.
The RxID is green but 'ENABLED' under notifications is
yellow. I'm using FLRIG with it. Passband is
UNchecked.'
Here's the explanation (hopefully). I attach 2
screenshots and a config file in an archive (it's from
an answer to earlier Q&A thread, thus the
unrelated name).
A) First of all, as you have noted, FLdigi now
distinguishes between 'Passband' and 'Min BW
detection'. Passband will decode and follow RSIDs
within the *entire* spectrum, while, with 'Passband'
unchecked, the decoding range is limited to the
bandwidth between the 2 dotted vertical lines in the
waterfall. The witdh of this limited bandwidth can be
set in the Config | IDs | RSID Dialog. At least as of
FLdigi ver4.2.06, you may RightClick the RxID button
in the main FLdigi window and check/uncheck 'Passband'
there, very practical. If there are no vertical dotted
limit lines visible in the waterfall, 'Passband' is
activated and all received RSIDs will be decoded.
B) But for RSID to work, there's another selection you
may need to set to your needs:
In FLdigi, RSID can be (de)activated *per mode*, which
may not be very intuitive, but is certainly way better
than no choice at all. In the attached screenshot
'FLdigi_Configuration.png', you'll see a Button 'Rx
modes' and another Button 'Transmit modes'. They are
entirely independent, but only activating the RSID
function for all 'your' modes in both TX and RX will
make these useful features available in both cases.
Not visible in my RsID Dialog screenshot is another
setting 'Disable frequency change', which, if
activated, still allows RSID decoding, but then it's
up to you to manually change frequency. This may be
useful at times, e.g. if you are in a QSO and don't
want to change the precise tuning currently set and
used. Especially if a mode needs properly centered
tuning for best decoding results (e.g. BPSK or narrow
MFSK modes), following the received RSID may not be
helpful, because the RSID tags are only 'accurate' to
within steps of 5 Hz, which may be worse than what you
can and wish to set manually.
C) Just FYI:
The RxID notifier is widely user-configurable, and if
you add a few empty lines before and after an easily
visible RSID tag text, the result may look like this
(an example from Shortwave Radiogram):
- - - - - -
Shortwave Radiogram now changes to MFSK64 ...
----------------------------------------------------
RSID: <<2024-10-17T23:38Z MFSK-64 @ 1499>>
----------------------------------------------------
This is Shortwave Radiogram in MFSK64
Please send your reception report to
radiogram@...
- - - - - -
I attach my 'notify.prefs' as stored in 'C:\Users\
< U S E R N A M E > \fldigi.files', which should
give you the RSID tag layout shown above, should you
be inclined to try it out (be sure to close FLdigi if
you copy this file into your folder - and backup your
existing file before, in case you wish to return to
the previous settings). The leading and trailing empty
lines are defined in 'notify.prefs' by the NewLine
token backslash-n (\n = 1 new line, \n\n = 1 new and 1
empty line etc.), and you can easily adapt this to
your needs in any text editor. The tiny preview in the
'Notifications' Dialog may not correctly show such
extra lines etc., but they will be visible in the RX
window. Most user-configurable settings are available
under Menu - Configure - Notifications, others under
Menu - Configure - Config Dialog - IDs [+] RsID, and
the attached (commented) 2nd screenshots shows some of
the settings to choose from.
- - - - - -
Good luck and enjoy FLdigi, it's really a great piece
of free software, thanks to Dave's generous work he
puts into ever improving it..
Vy 73 SWL Tobias
.-.-.
Am Dienstag, 5. November 2024 um 00:31:08
MEZ hat Al via groups.io
<k2hro@...> Folgendes
geschrieben:
Using 4.2.05 Win, it
won't decode RSIDs. The RxID is green
but 'ENABLED' under notifications is
yellow. I'm using FLRIG with it.
Passband is UNchecked.
thanks
|
Al,
This is a very unusual behavior.
We have a weekly QTC in MFSK32 and QSL tfc with multiple participants, some switching to MFSK16 for QRP reasons. The RSID almost always decodes, even when robust text digimodes have trouble decoding.
If you wish to give it a try, record a couple of non-decoding RSIDs directly in FLdigi via File | Audio | RX capture and send the short audio file for testing here.
Likewise I can provide an audio snippet recorded off-air, please find it attached. Open it via File | Audio | Playback and set your rx offset close to 2750 Hz. 2 signals are loud, the middle one from a 5 W QRP station > 100 km away. They decode flawlessly in ver4.2.06.
RSID needs clear distinct (non-overlapping) non-modulated (non-wobbly) sine tones. Sometimes audio processing somewhere (Rig or Soundcard control) add acoustic 'enhancements', which are always detrimental to reading digital signals. Be sure to have them checked and deactivated.
Please also check that the reverse 'Rv' button is not activated and, to get going, also turn off squelch.
For the recorded RSIDs to work, be sure to have the respective modes activated in the RSID Dialog via the Button 'Rx modes'.
Hope this will help find the issue.
Good luck!
73s Tobias
.-.-.
Am Mittwoch, 6. November 2024 um 20:50:30 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
No luck decoding RSIDs with ver 4.2.05, 4.2.07, or an older version. I can see and hear the 2 sec RSIDs. After 5 hours of watching, it decoded only once. It used to decode all the time. T/R is great. Using 4,800,8,N,1 which also works for WSJT-x on an Icom 756-2 and a Signalink. See attached. Btw, I did see something perhaps on Radio Reference by the author discussing an RSID problem early in 2024 but can't find it now.
What versions work?
Thanks for your time.
On Tuesday, November 5, 2024 at 09:13:25 AM EST, T? via groups.io <tsquare123@...> wrote:
Hi Al,
You wrote: 'Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.'
Here's the explanation (hopefully). I attach 2 screenshots and a config file in an archive (it's from an answer to earlier Q&A thread, thus the unrelated name).
A) First of all, as you have noted, FLdigi now distinguishes between 'Passband' and 'Min BW detection'. Passband will decode and follow RSIDs within the *entire* spectrum, while, with 'Passband' unchecked, the decoding range is limited to the bandwidth between the 2 dotted vertical lines in the waterfall. The witdh of this limited bandwidth can be set in the Config | IDs | RSID Dialog. At least as of FLdigi ver4.2.06, you may RightClick the RxID button in the main FLdigi window and check/uncheck 'Passband' there, very practical. If there are no vertical dotted limit lines visible in the waterfall, 'Passband' is activated and all received RSIDs will be decoded.
B) But for RSID to work, there's another selection you may need to set to your needs:
In FLdigi, RSID can be (de)activated *per mode*, which may not be very intuitive, but is certainly way better than no choice at all. In the attached screenshot 'FLdigi_Configuration.png', you'll see a Button 'Rx modes' and another Button 'Transmit modes'. They are entirely independent, but only activating the RSID function for all 'your' modes in both TX and RX will make these useful features available in both cases. Not visible in my RsID Dialog screenshot is another setting 'Disable frequency change', which, if activated, still allows RSID decoding, but then it's up to you to manually change frequency. This may be useful at times, e.g. if you are in a QSO and don't want to change the precise tuning currently set and used. Especially if a mode needs properly centered tuning for best decoding results (e.g. BPSK or narrow MFSK modes), following the received RSID may not be helpful, because the RSID tags are only 'accurate' to within steps of 5 Hz, which may be worse than what you can and wish to set manually.
C) Just FYI:
The RxID notifier is widely user-configurable, and if you add a few empty lines before and after an easily visible RSID tag text, the result may look like this (an example from Shortwave Radiogram):
- - - - - -
Shortwave Radiogram now changes to MFSK64 ...
----------------------------------------------------
RSID: <<2024-10-17T23:38Z MFSK-64 @ 1499>>
----------------------------------------------------
This is Shortwave Radiogram in MFSK64
Please send your reception report to radiogram@...
- - - - - -
I attach my 'notify.prefs' as stored in 'C:\Users\ < U S E R N A M E > \fldigi.files', which should give you the RSID tag layout shown above, should you be inclined to try it out (be sure to close FLdigi if you copy this file into your folder - and backup your existing file before, in case you wish to return to the previous settings). The leading and trailing empty lines are defined in 'notify.prefs' by the NewLine token backslash-n (\n = 1 new line, \n\n = 1 new and 1 empty line etc.), and you can easily adapt this to your needs in any text editor. The tiny preview in the 'Notifications' Dialog may not correctly show such extra lines etc., but they will be visible in the RX window. Most user-configurable settings are available under Menu - Configure - Notifications, others under Menu - Configure - Config Dialog - IDs [+] RsID, and the attached (commented) 2nd screenshots shows some of the settings to choose from.
- - - - - -
Good luck and enjoy FLdigi, it's really a great piece of free software, thanks to Dave's generous work he puts into ever improving it...
Vy 73 SWL Tobias
.-.-. Am Dienstag, 5. November 2024 um 00:31:08 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
Using 4.2.05 Win, it won't decode RSIDs. The RxID is green but 'ENABLED' under notifications is yellow. I'm using FLRIG with it. Passband is UNchecked.
thanks
|
Tobias,? Your flac file works
fine on my development system, Linux Mint 21.2.
================================================
Read macros from: /home/dave/ic7300/fldigi/macros/macros.mdf
================================================
a an ee? d l -? ee???? i? t?? ete es
Before RSID: <<2024-11-06T21:48Z BPSK-31 @
3525700+0997>>
Before RSID: <<2024-11-06T21:48Z MFSK-16 @
3525700+2752>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals = 73 AWDH =
Und nochmals QRZ QRZ QRZ QRZ QRZ de DL0BS DL0BS pse KKKK
twrotcR
Before RSID: <<2024-11-06T21:49Z MFSK-32 @
3525700+2751>>
¨®)
DL0BS DL0BS de DF6AH DF6AH DF6AH k
rne0
Before RSID: <<2024-11-06T21:49Z MFSK-16 @
3525700+2752>>
h? P<u? tthu
Before RSID: <<2024-11-06T21:49Z MFSK-16 @
3525700+2750>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals = 73 AWDH =
Und nochmals QRZ QRZ QRZ QRZ QRZ de DL0BS DL0BS pse KKKK
Before RSID: <<2024-11-06T21:50Z MFSK-32 @
3525700+2751>>
DL0BS DL0BS de DF6AH DF6AH DF6AH k
David
On 11/6/24 15:38, T? via groups.io
wrote:
toggle quoted message
Show quoted text
Al,
This is a very unusual behavior.
We have a weekly QTC in MFSK32 and QSL tfc with multiple
participants, some switching to MFSK16 for QRP reasons. The RSID
almost always decodes, even when robust text digimodes have
trouble decoding.
If you wish to give it a try, record a couple of non-decoding
RSIDs directly in FLdigi via File | Audio | RX capture and send
the short audio file for testing here.
Likewise I can provide an audio snippet recorded off-air, please
find it attached. Open it via File | Audio | Playback and set
your rx offset close to 2750 Hz. 2 signals are loud, the middle
one from a 5 W QRP station > 100 km away. They decode
flawlessly in ver4.2.06.
RSID needs clear distinct (non-overlapping) non-modulated
(non-wobbly) sine tones. Sometimes audio processing somewhere
(Rig or Soundcard control) add acoustic 'enhancements', which
are always detrimental to reading digital signals. Be sure to
have them checked and deactivated.
Please also check that the reverse 'Rv' button is not activated
and, to get going, also turn off squelch.
For the recorded RSIDs to work, be sure to have the respective
modes activated in the RSID Dialog via the Button 'Rx modes'.
Hope this will help find the issue.
Good luck!
73s Tobias
.-.-.
|
Hello Dave,
Thank you - exactly what my win7 does using fldigi ver4.2.06. Perfect. Let's see what Al comes up with.
I think all my previously used FLdigi versions (even many years back) had no issue decoding RSID properly.
Wish the AFC was of similar use and reliability. For MFSK modes, we have to recommend everyone to turn it off in FLdigi, because it rather drifts off than locking on to a signal - and staying on the spot without any signal. And MFSK like BPSK modes need perfect centering for best results, as you certainly are aware off. I have not found the bug in the code, but the effect as is is not at all helpful. AFC would be a great asset, though, when several stations with light offsets communicate. I always do manual centering in such cases, the implemented AFC rarely ever did the job of drawing an offset signal back in and staying there. It appears to wiggle about instead of self-stabilizing the found (?) center. And sadly, the 5 Hz steps RSID provides are too coarse, esp. for MFSK16 and lower sub-modes.
Anyway, Dave, thank you so much for this wonderful piece of software!
73s Tobias
.-.-. Am Mittwoch, 6. November 2024 um 22:52:11 MEZ hat Dave <w1hkj@...> Folgendes geschrieben:
Tobias,? Your flac file works fine on my development system, Linux Mint 21.2.
================================================
Read macros from: /home/dave/ic7300/fldigi/macros/macros.mdf
================================================
a an ee? d l -? ee???? i? t?? ete es
Before RSID: <<2024-11-06T21:48Z BPSK-31 @ 3525700+0997>>
Before RSID: <<2024-11-06T21:48Z MFSK-16 @ 3525700+2752>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals = 73 AWDH = Und nochmals QRZ QRZ QRZ QRZ QRZ de DL0BS DL0BS pse KKKK
twrotcR
Before RSID: <<2024-11-06T21:49Z MFSK-32 @ 3525700+2751>>
¨®)
DL0BS DL0BS de DF6AH DF6AH DF6AH k
rne0
Before RSID: <<2024-11-06T21:49Z MFSK-16 @ 3525700+2752>>
h? P<u? tthu
Before RSID: <<2024-11-06T21:49Z MFSK-16 @ 3525700+2750>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals = 73 AWDH = Und nochmals QRZ QRZ QRZ QRZ QRZ de DL0BS DL0BS pse KKKK
Before RSID: <<2024-11-06T21:50Z MFSK-32 @ 3525700+2751>>
DL0BS DL0BS de DF6AH DF6AH DF6AH k
David
On 11/6/24 15:38, T? via groups.io wrote:
Al,
This is a very unusual behavior.
We have a weekly QTC in MFSK32 and QSL tfc with multiple participants, some switching to MFSK16 for QRP reasons. The RSID almost always decodes, even when robust text digimodes have trouble decoding.
If you wish to give it a try, record a couple of non-decoding RSIDs directly in FLdigi via File | Audio | RX capture and send the short audio file for testing here.
Likewise I can provide an audio snippet recorded off-air, please find it attached. Open it via File | Audio | Playback and set your rx offset close to 2750 Hz. 2 signals are loud, the middle one from a 5 W QRP station > 100 km away. They decode flawlessly in ver4.2.06.
RSID needs clear distinct (non-overlapping) non-modulated (non-wobbly) sine tones. Sometimes audio processing somewhere (Rig or Soundcard control) add acoustic 'enhancements', which are always detrimental to reading digital signals. Be sure to have them checked and deactivated.
Please also check that the reverse 'Rv' button is not activated and, to get going, also turn off squelch.
For the recorded RSIDs to work, be sure to have the respective modes activated in the RSID Dialog via the Button 'Rx modes'.
Hope this will help find the issue.
Good luck!
73s Tobias
.-.-.
|
The RsID should be able to put
the carrier point within +/- 3 Hz of the received signal
center.? You flac file is performing correctly for the various
MFSK modes
with AFC enabled.? Not seeing any drift.? MFSK does require
critical tuning.? I recommend using THOR 16/32 etc to appreciate
it's impunity to mistuning and transceiver drift.
Dave
On 11/6/24 16:12, T? via groups.io
wrote:
toggle quoted message
Show quoted text
Hello Dave,
Thank you - exactly what my win7 does using fldigi ver4.2.06.
Perfect. Let's see what Al comes up with.
I think all my previously used FLdigi versions (even many years
back) had no issue decoding RSID properly.
Wish the AFC was of similar use and reliability. For MFSK modes,
we have to recommend everyone to turn it off in FLdigi, because
it rather drifts off than locking on to a signal - and staying
on the spot without any signal. And MFSK like BPSK modes need
perfect centering for best results, as you certainly are aware
off. I have not found the bug in the code, but the effect as is
is not at all helpful. AFC would be a great asset, though, when
several stations with light offsets communicate. I always do
manual centering in such cases, the implemented AFC rarely ever
did the job of drawing an offset signal back in and staying
there. It appears to wiggle about instead of self-stabilizing
the found (?) center. And sadly, the 5 Hz steps RSID provides
are too coarse, esp. for MFSK16 and lower sub-modes.
Anyway, Dave, thank you so much for this wonderful piece of
software!
73s Tobias
.-.-.
Am Mittwoch, 6. November 2024 um 22:52:11 MEZ hat Dave
<w1hkj@...> Folgendes geschrieben:
Tobias,? Your
flac file works fine on my development system, Linux
Mint 21.2.
================================================
Read macros from:
/home/dave/ic7300/fldigi/macros/macros.mdf
================================================
a an ee? d l -? ee???? i? t?? ete es
Before RSID: <<2024-11-06T21:48Z BPSK-31 @
3525700+0997>>
Before RSID: <<2024-11-06T21:48Z MFSK-16 @
3525700+2752>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals
= 73 AWDH = Und nochmals QRZ QRZ QRZ QRZ QRZ de
DL0BS DL0BS pse KKKK
twrotcR
Before RSID: <<2024-11-06T21:49Z MFSK-32 @
3525700+2751>>
¨®)
DL0BS DL0BS de DF6AH DF6AH DF6AH k
rne0
Before RSID: <<2024-11-06T21:49Z MFSK-16 @
3525700+2752>>
h? P<u? tthu
Before RSID: <<2024-11-06T21:49Z MFSK-16 @
3525700+2750>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals
= 73 AWDH = Und nochmals QRZ QRZ QRZ QRZ QRZ de
DL0BS DL0BS pse KKKK
Before RSID: <<2024-11-06T21:50Z MFSK-32 @
3525700+2751>>
DL0BS DL0BS de DF6AH DF6AH DF6AH k
David
On 11/6/24
15:38, T? via groups.io wrote:
Al,
This is a very unusual behavior.
We have a weekly QTC in MFSK32 and QSL tfc with
multiple participants, some switching to MFSK16 for
QRP reasons. The RSID almost always decodes, even when
robust text digimodes have trouble decoding.
If you wish to give it a try, record a couple of
non-decoding RSIDs directly in FLdigi via File | Audio
| RX capture and send the short audio file for testing
here.
Likewise I can provide an audio snippet recorded
off-air, please find it attached. Open it via File |
Audio | Playback and set your rx offset close to 2750
Hz. 2 signals are loud, the middle one from a 5 W QRP
station > 100 km away. They decode flawlessly in
ver4.2.06.
RSID needs clear distinct (non-overlapping)
non-modulated (non-wobbly) sine tones. Sometimes audio
processing somewhere (Rig or Soundcard control) add
acoustic 'enhancements', which are always detrimental
to reading digital signals. Be sure to have them
checked and deactivated.
Please also check that the reverse 'Rv' button is not
activated and, to get going, also turn off squelch.
For the recorded RSIDs to work, be sure to have the
respective modes activated in the RSID Dialog via the
Button 'Rx modes'.
Hope this will help find the issue.
Good luck!
73s Tobias
.-.-.
|
Hello Dave,
You're right, the short snippet I sent over didn't really show the AFC related issues I had described. And it was not 'selected' for this purpose.
And agreed, Thor is not at all affected by the perceived AFC issues, but in terms of robustness, Thor has so far not been fully convincing, as compared to the respective classic MFSK modes (when properly tuned). Nor has DominoEx, which also had its unexpected synch loss issues in tests, while MFSK still kept going. You are certainly aware that Kim Andrew Elliott KD9XB, with all his own experience and user feedback to his VOA/SW Radiograms, has also concluded that the most reliable workhorse on SW is MFSK32 (if we consider both throughput and robustness), but he also uses the 2x faster MFSK64, of course. In both cases, he luckily doesn't have any frequency offset or drift issues, though, since his shows are broadcast in standard AM instead of SSB.
So please allow me to explain what exactly I'm referring to.
Granted, light (slow) TX or RX drifts within 0...3 Hz are handled correctly by the current AFC algorithm. Which already is very good.
The 5 Hz RSID increments will effectively tune to within 3 Hz, which is very useful to get going when a new message starts.
Nevertheless, based on actual experience, especially when signals are not strong, and particularly in rather narrow modes like MFSK16 (even more so in MFSK8), decoding is clearly worse when the decoder is not 'perfectly' centered to the closest Hz. Even worse, when stations don't use TxID, or if it simply isn't decoded, e.g. during a loud QRN burst, signals from different stations may easily be off by 5 or 10 Hz (some of which may even be caused by the RSID steps), and this is a situation where the AFC should ideally step in and quickly (re)center / lock on to the nearest (e.g. within +/- 25...50 Hz) signal of the same mode. Which unfortunately it does not, see my example below. For comparison, analog AFC in FM radios certainly had such a predefined 'catch' frequency range, and when a signal was within this range, activating AFC would immediately tune it in and lock on to it. IMHO, this behavior is what a digital AFC should ideally emulate.
In topic 6 of my e-mail on FLdigi AFC back in 2022 (attached), I had described the FLdigi AFC behavior this way. I still consider the situation unchanged, and the suggested improvements desirable and practically useful:
- - - - - -
6) PERFORMANCE: AFC: Arguably, at least in classic MFSK modes (and possibly others), the AFC appears to be overdoing its task at times and actually tends to drift off the proper frequency rather than locking on to it to stabilize the reception, especially when signals temporarily drop, during QSB or signal pauses. This is even more counter-productive just before MFSK image reception, when the LAST found offset (which is rather arbitrary) is frozen during the whole image reception period, rather than freezing a reasonable average / typical center frequency found over the past few seconds before, e.g. at least during Pic header reception. Quite obviously, it's very unlikely that the TX or RX instantaneously drift off awfully at this very moment, in mid-transmission, just before the analog image starts.
On a related note (well, possibly), in DomEX Mode, under adverse conditions (especially high Doppler spread from about 10 Hz, or low SNR below -10 or even -15 dB), decoding becomes erratic, although it appears to lock on to the signal during short periods and momentarily decodes perfectly well then, before un-synching again (which unfortunately is the 'normal' state, happening most of the time). When looking at the 2nd Scope option, with center line and signal dots, it becomes obvious that the signals appear to shift sideways over time in wavy lines, although the physical TX signal was perfectly stable. Although the Button 'AFC' is deactivated by definition, due to the wide auto-search range in DomEX, the problem of losing synch and loss of proper frequency tracking (not even necessary in case of a stable TX signal!) may be linked to a similar scheme as the one described here for the classic MFSK mode example. This is why I mention this potentially linked topic here.
SUGGESTION PART 1: Instead of (arguably) mostly relying on individual tones or at least reacting 'nervously' to these (even the basic 'idle carrier' tone, since it might also be QRM), preferably link the AFC function to the 'big picture'. In other words, monitor the expected MFSK bandwidth and find the best match for it within the relevant spectrum (it's already present in the waterfall etc.). A pattern such as '____,--------,____' should be reasonably easy to find and center within a suitable search range around the last manually set (or even found) audio frequency, e.g. +/- 100 Hz. And once the signal appears to be synched and is actually decoding, use this extra information to slow down AFC and thus STABILIZE the found frequency, rather than quickly and permanently checking minor offsets around it, which potentially even degrades decoding (vs. AFC switched off altogether). I guess there is some measurable within the decoding chain that allows to continuously estimate the FEC error / confidence and thus decide, whether it is actual text or just noise that's being received.
SUGGESTION PART 2: Continuously track the (sliding averaged = smoothed) audio center frequency and use it as the principal input for the AFC control (this may already be the case) and then proceed as follows, actively distinguishing the different possible situations:
- While the smoothed frequency variation is low (ideally factor in the FEC error rate as described in part 1 above, to be sure there's an actual MFSK signal, not QRM or mere noise), curb the instant AFC range and speed accordingly. Again, in such a case relevant instant frequency steps are unlikely, whereas slow (usually thermal) drift should be automatically equaled out without the need of operator re-tuning.
- Otherwise, lacking a stable (decoding) signal, loosen the instant AFC range and speed up the AFC search gradually to try and lock on to an adjacent signal, should the 'big picture' (see part 1 above) suggest there actually is an MFSK signal close by.
- But if there is no such signal (signature), keep the current frequency, in other words, don't drift away from the last found and confirmed stable center. It's usually more likely, e.g. after an unintentional TX dropout, to reappear on the same QRG, rather than 50 Hz off. And even if it does reappear offset, we're back at the case above, and the signature should clearly lead the way back to lock onto the new center of the signal.
- If a new center frequency is manually set in the waterfall, try to find whether it matches a 'big picture' signal signature close by (e.g. within +/- 10 Hz) and then auto-center it there (snap), else tune to the actually pointed frequency. This should be the most intuitive and expected program behavior (simply assist the YL/OM to find and center the spot they tried to visually select).
Finally, if there's no such spectral MFSK signature in the area around the user-clicked frequency, there are still 2 cases to consider:
- If there's a stable 'idle' carrier close to the lower end of the clicked MFSK bandwidth, lock onto it as if it were (since it most pobably is) the basic MFSK 'idle' tone.
- Yet if there's but noise, don't search or drift off at all and remain where the user expects the signal. In my point of view, this is the most intuitive and logical behavior, and there's no credible reason to assume the signal would pop up somewhere else, against the spot intentionally (and possibly intelligently :-) selected by the user.
SUGGESTION PART 3: It would be cool to also have an FEC confidence display in classic MFSK modes, DomEx, Olivia etc. (or even a log / history display, see separate item 'SNR' above).
- - - - - -
Maybe this explains what I'm trying to ask in terms of AFC improvement.
In [mfsk.cxx] 'void mfsk::afc()', there is the following line, which appears to be the only one that actually performs an active AFC 'locking' action:
if ( fabs(f1 - f) < ts) {
freqerr = decayavg(freqerr, (f1 - f), 32); [comment: maybe the decayavg '32' value is still too fast for actual offset stabilization?]
set_freq(frequency - freqerr);
Given that 'double ts = tonespacing / 4;', I asssume (to be confirmed) that 'tonespacing' equals the actual frequency step from one MFSK tone to the next, for example in MFSK16, it would mean tonespacing = 15.625 Hz, and thus ts = 15.625/4 Hz = 3.9 Hz. If this interpretation is correct, the AFC will never try to center a signal farther off than some 4 Hz, which is a very (too!) narrow margin. And it is even more so, because, as explained above, looking at the tuned frequency offset with activated AFC, it simply does not stabilize onto the signal center but jumps around it, seemingly random, which doesn't appear to be the intended or ideal behavior. This is more visible in faster modes, e.g. MFSK64, but quite noticeable in MFSK32, which is what has been used in SW Radiogram and the German 'DL0BS' QTC I have mentioned yesterday. These broadcasts include longer periods of text, and only then this odd frequency 'wiggle' behavior becomes really apparent.
- - - - - -
I attach a few examples to show the described behavior, and why AFC 'locking' might still be improved (yet maybe I ask too much here):
1) Voc005b1-SW_DL0BS_in_MFSK16_3588u_-1x_Original_+_1x_drifting_down_+_1x_drifting_up-_2024-07-03_1919z.ogg
3x the same message recorded off-air: (A) = original, (B) = drifting down (about -18 Hz start to end), (C) = drifting up (about +18 Hz), both drifts were simulated in Audacity.
With AFC on, despite a perfectly stable signal (A) centered close to 2751 Hz, the FLdigi tuned frequency varies +/- several Hz, yet this is still OK for decoding, given the stong signal. With the drifts (A) and (B), though, FLdigi initially follows the frequency change but gets stuck well before the end of the message, losing synch and the remaining text content. While it can be argued that such a drift speed is unusual, I don't understand why the offset tracking works initially but not later, given that the applied drift rate ist constant over time.
2) Voc005b1-SW_DL0BS_in_MFSK32_3588u_-1x_weak_+_1x_loud_about_10_Hz_up-_2024-07-03_192108z.ogg
Note that the first weaker message is about 10-11 Hz below the stronger reply.
With AFC ON, in MFSK32, the tuned offset (randomly?) visibly jumps several Hz around the actual center frequency. Try it out several times, it does neither appear to stabilize over time, nor to be repeatable in its skip pattern.
With both RSID ON and AFC ON, it keeps track anyway and decodes the signals flawlessly. Great!
Without RSID (and the RSID induced frequency correction to close to the answer's offset, some +10 Hz higher), despite the very loud signal, AFC does not (or at least not swiftly and reliably) manage to pull the signal in and decode the message text.
Now finally try 'AFC ON' using MFSK64 while playing the same audio snippet. Granted, there is no valid MFSK64 signal, so it cannot lock on to anything, but watch how quickly (and randomly?) the frequency offset jumps around!
3) Voc053d1-SW_DL0BS_alias_DM88YLF_3588u_-Audacity-QSL-Zoom_View_+_Measured_Offsets-_2024-03-27_2027z.png
This screenshot shows the spectrum and all MFSK32 and MFSK16 signal offsets recorded during an on-air QSL traffic. The figures below show the precisely measured center frequencies of the master station (yellow) and answering stations (blueish labels). While a few Hz here and there may not appear much, they are decisive for reasonable decoding results, especially in the narrower MFSK16 mode.
- - - - - -
These few FLdigi AFC related examples may help understand what I meant to say yesterday by claiming 'it rather drifts off than locking on to a signal - and staying on the spot without any signal'. I assume the principle is the same for all MFSK modes, and maybe the algorithm offering a somewhat smoothed 'frequency locking' AFC functionality can be improved easier by selecting a faster mode first and watch/compare the effect there, before trying it in the slower modes, where the centering is more critical but the current odd 'skipping' is less obvious.
I apologize for the long 'lecture', but I'm afraid I just fail to put all the information in a nutshell...
Thanks again and 73s
Tobias
.-.-. Am Mittwoch, 6. November 2024 um 23:29:25 MEZ hat Dave <w1hkj@...> Folgendes geschrieben:
The RsID should be able to put the carrier point within +/- 3 Hz of the received signal center.? You flac file is performing correctly for the various MFSK modes
![]()
with AFC enabled.? Not seeing any drift.? MFSK does require critical tuning.? I recommend using THOR 16/32 etc to appreciate it's impunity to mistuning and transceiver drift.
Dave
On 11/6/24 16:12, T? via groups.io wrote:
Hello Dave,
Thank you - exactly what my win7 does using fldigi ver4.2.06. Perfect. Let's see what Al comes up with.
I think all my previously used FLdigi versions (even many years back) had no issue decoding RSID properly.
Wish the AFC was of similar use and reliability. For MFSK modes, we have to recommend everyone to turn it off in FLdigi, because it rather drifts off than locking on to a signal - and staying on the spot without any signal. And MFSK like BPSK modes need perfect centering for best results, as you certainly are aware off. I have not found the bug in the code, but the effect as is is not at all helpful. AFC would be a great asset, though, when several stations with light offsets communicate. I always do manual centering in such cases, the implemented AFC rarely ever did the job of drawing an offset signal back in and staying there. It appears to wiggle about instead of self-stabilizing the found (?) center. And sadly, the 5 Hz steps RSID provides are too coarse, esp. for MFSK16 and lower sub-modes.
Anyway, Dave, thank you so much for this wonderful piece of software!
73s Tobias
.-.-. Am Mittwoch, 6. November 2024 um 22:52:11 MEZ hat Dave <w1hkj@...> Folgendes geschrieben:
Tobias,? Your flac file works fine on my development system, Linux Mint 21.2.
================================================
Read macros from: /home/dave/ic7300/fldigi/macros/macros.mdf
================================================
a an ee? d l -? ee???? i? t?? ete es
Before RSID: <<2024-11-06T21:48Z BPSK-31 @ 3525700+0997>>
Before RSID: <<2024-11-06T21:48Z MFSK-16 @ 3525700+2752>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals = 73 AWDH = Und nochmals QRZ QRZ QRZ QRZ QRZ de DL0BS DL0BS pse KKKK
twrotcR
Before RSID: <<2024-11-06T21:49Z MFSK-32 @ 3525700+2751>>
¨®)
DL0BS DL0BS de DF6AH DF6AH DF6AH k
rne0
Before RSID: <<2024-11-06T21:49Z MFSK-16 @ 3525700+2752>>
h? P<u? tthu
Before RSID: <<2024-11-06T21:49Z MFSK-16 @ 3525700+2750>>
?de dl0bs dl0bs = ALles klar Olaf und Danke vielmals = 73 AWDH = Und nochmals QRZ QRZ QRZ QRZ QRZ de DL0BS DL0BS pse KKKK
Before RSID: <<2024-11-06T21:50Z MFSK-32 @ 3525700+2751>>
DL0BS DL0BS de DF6AH DF6AH DF6AH k
David
On 11/6/24 15:38, T? via groups.io wrote:
Al,
This is a very unusual behavior.
We have a weekly QTC in MFSK32 and QSL tfc with multiple participants, some switching to MFSK16 for QRP reasons. The RSID almost always decodes, even when robust text digimodes have trouble decoding.
If you wish to give it a try, record a couple of non-decoding RSIDs directly in FLdigi via File | Audio | RX capture and send the short audio file for testing here.
Likewise I can provide an audio snippet recorded off-air, please find it attached. Open it via File | Audio | Playback and set your rx offset close to 2750 Hz. 2 signals are loud, the middle one from a 5 W QRP station > 100 km away. They decode flawlessly in ver4.2.06.
RSID needs clear distinct (non-overlapping) non-modulated (non-wobbly) sine tones. Sometimes audio processing somewhere (Rig or Soundcard control) add acoustic 'enhancements', which are always detrimental to reading digital signals. Be sure to have them checked and deactivated.
Please also check that the reverse 'Rv' button is not activated and, to get going, also turn off squelch.
For the recorded RSIDs to work, be sure to have the respective modes activated in the RSID Dialog via the Button 'Rx modes'.
Hope this will help find the issue.
Good luck!
73s Tobias
.-.-.
|
Dave