I am trying to find the link from Fldigi to logging programs that allows them to look up previous calls when a callsign is entered in Fldigi to start a QSO.听 When used with DX Keeper as soon as you enter a callsign in Fldigi, DX Keeper and DxView look up the callsign.听 When used with N3FJP the same process happens.听 I am trying to duplicate this lookup with Log4OMv2 but I cannot find what is sending the data to the other programs.听
听
Does anyone have any idea where I can look, or how to do this set up?
听
Thanks in advance for any ideas.
73
Bill
w1wrh
|
Re: Fldigi and Win11 audio tricks
Apparently I did not make myself clear about what exactly is happening in Win11 that differs from Win10; I'll try to do a better job on that this time: If one looks at the levels displayed in the MIC output display in say the audio mixer, one sees the levels being output by the receiver through Fldigi. There is no such display in the SPEAKER level control reading where it should be. Ordinarily, in Win10, one can see audio from the radio receiver being displayed in the SPEAKERS section of the display. Instead, in Win11 we are seeing the audio output by the attached radio receiver in the MIC section of the display where it should NOT be. The SPEAKERS section of that display shows nothing. In as plain language as I can say it, the input/output signals to/from the SignaLink are reversed in the Win11 audio system. Those exact same signals are NOT reversed in the Win10 audio system displays. FYI, I have been heavily involved with computers and software since about 1970, so I do know what I am seeing. Thanks for the input, though. As I said, in this case, I fixed the issue by installing and activating a new seat of Win10 Pro 64 bit. Ken W7EKB On 9 Nov 2024 at 17:03, ve3ki via groups.io wrote:
That is the way Windows has always labeled sound card inputs and
outputs. What Windows calls the "microphone" is a generic name for
analog audio inputs to the sound card. In the case of a transceiver,
that is the signal from the receiver (the same signal you hear in the
radio's speaker). What Windows calls the "speaker" is a generic name
for analog audio outputs from the sound card. In the case of a
transceiver, that is the audio modulation input to the transmitter
(takes the place of the transceiver's microphone input). This did not
change between Windows 10 and 11. 听 You can rename these inputs and
outputs to make this less confusing. You can rename the playback
device you use for transmitting digital modes from "Speaker" to
something like "Radio Transmitter" and the recording device you use
for receiving digital modes from "Microphone" to something like "Radio
Receiver".听 听 The "default communications device" in Windows is the
sound card device used by VoIP programs (e.g. Skype or Zoom). It has
nothing to do with radio communications, and should not be used for
that purpose. The "default communications device" in Windows should
normally be set to be the motherboard sound card, the same as the
regular "default device". 听 Note that in addition to the master
volume level controls, in the Windows 11 Sound Settings there are also
application-specific level settings. You should check these to make
sure that the application-specific settings for fldigi have not been
defaulted to zero. 听 73, Rich VE3KI 听 听 听 On Sat, Nov 9, 2024 at
07:08 PM, Kenneth G. Gordon wrote: I know several of those who post
here have reported good results with Fldigi and Win11, but we here
have not.
The subject computer is a new Acer Aspire 3 which came with the latest
version of Win11.
After messing around with this thing for the past two or three days,
we find that Win11 has reversed the two ports for Fldigi's receive and
transmit functions.
We have set the computer's audio settings to the Realtek Speakers, and
its input to the onboard microphone. These work correctly.
We have also set the communications device settings to the Fldigi
choices, although what SHOULD be the RECEIVED signal from Fldigi,
Win11 sees as the MIC input,and the MIC input to Fldigi is seen by
Win11 as the SPEAKER output
The audio level control for the Fldigi ports is set permanently at
zero and cannot be increased. It is grayed out.
This occurs with two different interfaces, 1) a SignaLink USB unit,
and 2) a West Mountain RigBlaster Advantage.
And there appears to be no way to reverse these settings, except by
physically reversing the two connections within the Signalink or
Rigblaster.
We have updated Win11 to the laatest verion and have searched the
internet for possible solutions. finding none.
At this point we are fed up with fooling with this, and have installed
a new version of Win10 Pro 64 bit on the laptop.
Ken W7EKB
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
--
Ken Gordon W7EKB
-- This email has been checked for viruses by Avast antivirus software. www.avast.com -- Ken Gordon W7EKB
|
Re: Fldigi and Win11 audio tricks
That is the way Windows has always labeled sound card inputs and outputs. What Windows calls the "microphone" is a generic name for analog audio inputs to the sound card. In the case of a transceiver, that is the signal from the receiver (the same signal you hear in the radio's speaker). What Windows calls the "speaker" is a generic name for analog audio outputs from the sound card. In the case of a transceiver, that is the audio modulation input to the transmitter (takes the place of the transceiver's microphone input). This did not change between Windows 10 and 11.
听
You can rename these inputs and outputs to make this less confusing. You can rename the playback device you use for transmitting digital modes from "Speaker" to something like "Radio Transmitter" and the recording device you use for receiving digital modes from "Microphone" to something like "Radio Receiver".听
听
The "default communications device" in Windows is the sound card device used by VoIP programs (e.g. Skype or Zoom). It has nothing to do with radio communications, and should not be used for that purpose. The "default communications device" in Windows should normally be set to be the motherboard sound card, the same as the regular "default device".
听
Note that in addition to the master volume level controls, in the Windows 11 Sound Settings there are also application-specific level settings. You should check these to make sure that the application-specific settings for fldigi have not been defaulted to zero.
听
73,
Rich VE3KI
听
听
听
On Sat, Nov 9, 2024 at 07:08 PM, Kenneth G. Gordon wrote:
I know several of those who post here have reported good results with Fldigi and Win11, but
we here have not.
The subject computer is a new Acer Aspire 3 which came with the latest version of Win11.
After messing around with this thing for the past two or three days, we find that Win11 has
reversed the two ports for Fldigi's receive and transmit functions.
We have set the computer's audio settings to the Realtek Speakers, and its input to the
onboard microphone. These work correctly.
We have also set the communications device settings to the Fldigi choices, although what
SHOULD be the RECEIVED signal from Fldigi, Win11 sees as the MIC input,and the MIC
input to Fldigi is seen by Win11 as the SPEAKER output
The audio level control for the Fldigi ports is set permanently at zero and cannot be
increased. It is grayed out.
This occurs with two different interfaces, 1) a SignaLink USB unit, and 2) a West Mountain
RigBlaster Advantage.
And there appears to be no way to reverse these settings, except by physically reversing the
two connections within the Signalink or Rigblaster.
We have updated Win11 to the laatest verion and have searched the internet for possible
solutions. finding none.
At this point we are fed up with fooling with this, and have installed a new version of Win10
Pro 64 bit on the laptop.
Ken W7EKB
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
--
Ken Gordon W7EKB
|
Fldigi and Win11 audio tricks
I know several of those who post here have reported good results with Fldigi and Win11, but
we here have not.
The subject computer is a new Acer Aspire 3 which came with the latest version of Win11.
After messing around with this thing for the past two or three days, we find that Win11 has
reversed the two ports for Fldigi's receive and transmit functions.
We have set the computer's audio settings to the Realtek Speakers, and its input to the
onboard microphone. These work correctly.
We have also set the communications device settings to the Fldigi choices, although what
SHOULD be the RECEIVED signal from Fldigi, Win11 sees as the MIC input,and the MIC
input to Fldigi is seen by Win11 as the SPEAKER output
The audio level control for the Fldigi ports is set permanently at zero and cannot be
increased. It is grayed out.
This occurs with two different interfaces, 1) a SignaLink USB unit, and 2) a West Mountain
RigBlaster Advantage.
And there appears to be no way to reverse these settings, except by physically reversing the
two connections within the Signalink or Rigblaster.
We have updated Win11 to the laatest verion and have searched the internet for possible
solutions. finding none.
At this point we are fed up with fooling with this, and have installed a new version of Win10
Pro 64 bit on the laptop.
Ken W7EKB
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
--
Ken Gordon W7EKB
|
Hello Al,
In any issue description, it would generally be helpful to be very specific about the FLdigi version, DigiMode and settings used, either in the text description, and/or please join a screenshot of the entire FLdigi window, to see the respective settings there, and also show, which FLdigi version you are using.
Not sure what exactly you refer to here. But I assume you tried clicking a line in the Signal Browser Window (some modes allow this multi-signal decoding, but you didn't mention which one you were using - MFSK16, which you wrote about earlier, is not even supported) and it didn't select the frequency to show the result in the (main) Rx Pane ...?
Regarding your info 'I have to read the tiny text on the left', you should always be able to click the respective frequency in the waterfall and then the main Rx Pane should instantly display what's received on the selected QRG. This also is a good check, whether the mouse command (clicking) as such is working OK. At least in Windows, sometimes modifier keys (e.g. Shift, Ctrl, Alt on the keyboard) 'get stuck' and continue to be logically active while physically, they are no longer pressed. In such a case, unexpected things (or nothing) may happen, instead of the expected function. But I don't think this was the case here.
To verify what's possible (FLdigi V4.2.06, running Windows 7), I have tried all potential frequency 'locking' settings I could find, but in no case or combination, this effect could be reproduced. So bottom line I'm really puzzled...
Looking at your earlier e-mail about the RSID, you have mentioned that you tried 'Passband' already without success. That's yet another puzzle, because the RSID has always worked very reliably here, and I have not been able to reproduce what you have described. So here are just 2 more remarks based on experience:
If the received signals are not strong or noisy, you may wish to open the Config RsID dialog and set the 'Allow errors' setting to 'High' (my usual setting), which increases the chances of decoding an RSID tag.
On a related note, I would generally *discourage* activating the settings 'Mark previous mode' (which normally won't be of much use anyway, since it's the NEW, that really matters) and also the Rx/Tx RsID EOT, which is very rarely used and, if so, often inadvertendly: It's not at all helpful in QSOs, since this EOT TxID appears after the end of the digimode signal, when as answering station may already send its normal TxID, leading to overlapping signals possibly failing to decode. We've had such a case on the air, quite confusing! The OM had no idea, that he had activated this option an gladly got rid of it, once notified.
Well, if any 'odd behavior' is *permanent* in your otherwise functional FLdigi installation, please send your FLdigi configfuration files over. Comparing these with a 'functional' configuration here might provide a clue, which setting(s) may be off. Both files usually are located in 'C:\Users\<USER_NAME>\fldigi.files': 'fldigi.prefs' and 'fldigi_def.xml'.
Sorry, that's all I can come up with at this point.
Good Luck!
73s Tobias
.-.-. Am Freitag, 8. November 2024 um 00:10:13 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
Thank you very much. I'll try it. I hate to be a pain but a few minutes ago I had a QSO that went well except when I clicked the left white pane with frequencies listed---it didn't transfer to the top right pane like it used to do so I have to read the tiny text on the left.
On Thursday, November 7, 2024 at 04:32:21 PM EST, T虏 via groups.io <tsquare123@...> wrote:
Hello Al,
Please consider the attached explanation.
73s Tobias
.-.-. Am Donnerstag, 7. November 2024 um 21:53:31 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
The RSID popup worked reliably today BUT the cursor had to be over the signal AND in the same mode as the transmitting station--(MFSK16). No change with passband checked or unchecked. In other words, you need to know the freq & mode to get the popup.
I did a clean install earlier. FLRIG 2.0.05.81听 FLDIGI 4.2.05 & 4.2.06
thank you Al
|
Re: Link to W1HKJ software URL goes to wrong site
The following applies only to Microsoft Edge, although other browsers may have similar features.
听
By default, Edge redirects http:// requests to https://. You can disable this feature by navigating to edge://flags/#edge-automatic-https and selecting "Disabled" from the dropdown. Once I did this, the fldigi "Online documentation..." link went to the correct site.听
Hope this helps
听
Bob AD2HL
|
Thank you very much. I'll try it. I hate to be a pain but a few minutes ago I had a QSO that went well except when I clicked the left white pane with frequencies listed---it didn't transfer to the top right pane like it used to do so I have to read the tiny text on the left.
On Thursday, November 7, 2024 at 04:32:21 PM EST, T虏 via groups.io <tsquare123@...> wrote:
Hello Al,
Please consider the attached explanation.
73s Tobias
.-.-. Am Donnerstag, 7. November 2024 um 21:53:31 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
The RSID popup worked reliably today BUT the cursor had to be over the signal AND in the same mode as the transmitting station--(MFSK16). No change with passband checked or unchecked. In other words, you need to know the freq & mode to get the popup.
I did a clean install earlier. FLRIG 2.0.05.81听 FLDIGI 4.2.05 & 4.2.06
thank you Al
|
Hello Al,
Please consider the attached explanation.
73s Tobias
.-.-. Am Donnerstag, 7. November 2024 um 21:53:31 MEZ hat Al via groups.io <k2hro@...> Folgendes geschrieben:
The RSID popup worked reliably today BUT the cursor had to be over the signal AND in the same mode as the transmitting station--(MFSK16). No change with passband checked or unchecked. In other words, you need to know the freq & mode to get the popup.
I did a clean install earlier. FLRIG 2.0.05.81听 FLDIGI 4.2.05 & 4.2.06
thank you Al
|
The RSID popup worked reliably today BUT the cursor had to be over the signal AND in the same mode as the transmitting station--(MFSK16). No change with passband checked or unchecked. In other words, you need to know the freq & mode to get the popup.
I did a clean install earlier. FLRIG 2.0.05.81听 FLDIGI 4.2.05 & 4.2.06
thank you Al
|
Flrig Mac Intel and IC7300
#flrig
I am unable to download flrig onto my Mac Mini Intel.听 I tried several months ago and gave up. trying anew.
Thanks
John AB8O
|
Re: FLDIGI RSID not working
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
.-.-.
|
Re: FLDIGI RSID not working
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
.-.-.
|
Re: FLDIGI RSID not working
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
.-.-.
|
Re: FLDIGI RSID not working
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
.-.-.
|
Re: FLDIGI RSID not working
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
|
Re: FLDIGI RSID not working
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
|
Re: FLDIGI RSID not working
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
|
Re: FLDIGI RSID not working
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
|
Re: FLDIGI RSID not working
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
|
This is all good advice...while W11 ~does~ make virtually ~everything~ more difficult, IMO, these are still good recommendations to follow. Note that the attachments that appeared on the digirig forum apply as well to SignaLink; hence the embedded SL comment about versions of SL. On 2024-11-05 04:00:, Daniel (AE4ON) wrote: First, go into the Sound Settings and select your default sound devices for the PC/HDMI/etc., and you may choose to set that as your "Default for audio" and "Default for communications".� You do not want to choose your transceiver or audio device (signalink, digirig, etc) as the default device. Same as for W10. Then launch the amateur radio program (this applies to fldigi, js8call, Vara Modem, wsjtx etc.) and you should see in the sound settings an option to choose the audio device for that application to use.� Choose your transceiver USB audio codec (or other mic/speaker) here. Do this for each amateur radio program you operate for data modes. Same as for W10. One nice feature of the Windows 11 audio system is you can change the name or label of an audio device in the sound settings.� So instead of having "USB Audio Codec" and "USB Audio Codec 2", I have "Kenwood TS-590SG" and "Icom IC-7200" as my device labels.� This makes it easy if I want to swap which radio a piece of software is using for its audio in/out. Same as for W10. These are exactly the same 3 recommendations I use for W10.
|
Dave
Rich NE1EE