Topics

RSID will not change modes

Al Massaro
 

I have a local Ham who has been using FLDIGI for about 2 years, we have downloaded and used different versions over that time with little issue. Recently he has complained of it not changing modes when needed on receipt of an RSID signal. I have tested with him over HF and VHF in a variety of modes and it does not switch. He was using 4.0.15 until today, and is now updated to 4.0.18 and still no joy, his setup will send TXID just fine. I have tried every combination in the config setup I can see to no avail. His window shows a green button and will switch to red for passband, I am just at a loss as to how to proceed.
Thanks,
AL M 
KF5SMH

Ron
 

Al,

The first thing I can think of is Configure, other, ID.  Click Receive modes and make sure the mode you want to detect is checked or click Select All.

73, Ron NY3J

On 1/5/19 9:19 PM, Al Massaro wrote:
I have a local Ham who has been using FLDIGI for about 2 years, we have downloaded and used different versions over that time with little issue. Recently he has complained of it not changing modes when needed on receipt of an RSID signal. I have tested with him over HF and VHF in a variety of modes and it does not switch. He was using 4.0.15 until today, and is now updated to 4.0.18 and still no joy, his setup will send TXID just fine. I have tried every combination in the config setup I can see to no avail. His window shows a green button and will switch to red for passband, I am just at a loss as to how to proceed.
Thanks,
AL M 
KF5SMH

Al Massaro
 

Thank You Ron, I had done that earlier and selected all with no joy. As an addendum, I have also checked searches passband and mark previous freq/mode.
Thanks again,
AL M 
KF5SMH

Ron
 

Okay Al,

That was my guess and now out of ideas.  Be careful about search passband.  If you receive a TxID from another waterfall frequency it will change your waterfall frequency from the station you are working.

Here's another wild guess.  Look in Flmsg Config under ARQ.  The first 3 check marks will make changes to your RxID.  They are for the ARQ function so I have them unchecked.  The only thing I have checked is Sync modem to fldigi.

73, Ron NY3J

On 1/6/19 10:36 AM, Al Massaro wrote:
Thank You Ron, I had done that earlier and selected all with no joy. As an addendum, I have also checked searches passband and mark previous freq/mode.
Thanks again,
AL M 
KF5SMH

Al Massaro
 

Thanks again! As soon as I can get in touch with him we will give it another go.
AL M 
KF5SMH

Al Massaro
 

Well that still did not change anything, also tried turning the video RSID off for all modes, no joy there either. TXID works though, as I understand the system the Reed Solomon is something akin to an external FLDIGI control program, so I wonder if something could be corrupting his RSID side of the program.

Dave
 

Make sure that you are both on the same sideband

On 1/6/19 11:50 AM, Al Massaro wrote:
Well that still did not change anything, also tried turning the video RSID off for all modes, no joy there either. TXID works though, as I understand the system the Reed Solomon is something akin to an external FLDIGI control program, so I wonder if something could be corrupting his RSID side of the program.

Al Massaro
 

Thanks Dave, as I stated earlier we are working/testing in both HF USB and VHF.
AL M 
KF5SMH

Bart N5BLP
 

Al:

Most of the time I've seen people having a problem with this (when properly configured) they were acoustically coupling.  Not sure why, but it just doesn't seem to work as reliably with acoustic coupling.  Is your guy using a sound card interface like SignaLink or RigBlaster?

Bart N5BLP

Al Massaro
 

Bart, Thanks for the thought, but yes he is using a Signalink USB
AL M
KF5SMH

Ed
 

I had a similar problem with FLDigi 4.0.18 at our club station.  All the config check boxes looked OK to me, but no RsID decode.  I verified it was not in the hardware by running FLDigi with a prerecorded wave file from an ARES practice session, using File ->Audio->Playback.



Something was awry in the configuration that I could not find, so I copied the fldigi_def.xml file from another station which was working correctly.  Of course I needed to make appropriate modifications to the UI, rig and audio configurations, but after that RsID decoded OK.  It might be worthwhile to occasionally backup the fldigi.files and NBEMS.files folders, in case a similar problem occurs in the future.

73,
Ed
N2BHD

Ed
 

I encountered the problem again, where RsID seemed to stop working.  This time it was on the station at my home.  I am running Windows 7 Pro, and fldigi 4.0.19.103.  Again, the problem was resolved by replacing the fldigi_def.xml file.  This time I decided to experiment with incrementally changing the configuration and saving the fldigi_def.xml file until I encountered the problem.  Each time I changed the configuration I saved it, checked to see if RsID worked, and closed fldigi.  When I reopened fldigi, I again checked to see if it would respond to a received RsID.  The last change I made was to modify the RigCAT COM port from COM1 to COM8.  RsID worked with COM8 before closing fldigi, but after reopening it, RsID no longer worked. If I changed the RigCAT COM port back to COM1, RsID began working again.  I repeated this several times, and the results were always the same.  If I opened fldigi when the fldigi_def.xml file was pointing to COM8, the RsID would not work.  I verified that the Device Manager indicated that COM8 was a functioning COM port, while I was conducting the experiment.  One interesting note is that COM1 is a hardware COM port, but COM8 is an ELTIMA virtual COM port.  The ELTIMA virtual COM port is spawned by the RemoteHams RCForb Client.  The RCForb client was actively running throughout this experiment.  I compared the fldigi_def.xml files and the only difference was the <XMLRIGDEVICE> tag.  The functioning fldigi_def.xml file contained <XMLRIGDEVICE>COM1</XMLRIGDEVICE>, while the disfunctional fldigi_def.xml  file contained <XMLRIGDEVICE>COM8</XMLRIGDEVICE>.  It is also worth noting, that the fldigi application at our club station is also interfacing to an ELTIMA virtual COM port, which is spawned by the RemoteHams RCForb Server.

I don't understand what the relationship might be between the RigCAT COM port, and the RsID decoding, but at least I think I can recover when I encounter the RsID problem again.

73,
Ed
N2BHD

Dave
 

COM port selection should have zero effect on RsID decoding.

I am not very familiar with the RemoteHams software.  Does it also provide a virtual sound card interface using VOIP technology?  If yes, then that is the reason for the loss of RsID detection.  The VOIP audio is probably a  lossy interface (not tcpip) and any audio drop outs or sound rate conversion noise will seriously effect the RsID detection.  It's probably OK for CW, voice and even PSK-31.   MT63 and Olivia will probably also work OK on a VOIP audio connection.  Higher baud MFSK modems will probably fail to decode or have lots of decoding errors.

73, David, W1HKJ


On 1/18/19 3:17 PM, Ed via Groups.Io wrote:
I encountered the problem again, where RsID seemed to stop working.  This time it was on the station at my home.  I am running Windows 7 Pro, and fldigi 4.0.19.103.  Again, the problem was resolved by replacing the fldigi_def.xml file.  This time I decided to experiment with incrementally changing the configuration and saving the fldigi_def.xml file until I encountered the problem.  Each time I changed the configuration I saved it, checked to see if RsID worked, and closed fldigi.  When I reopened fldigi, I again checked to see if it would respond to a received RsID.  The last change I made was to modify the RigCAT COM port from COM1 to COM8.  RsID worked with COM8 before closing fldigi, but after reopening it, RsID no longer worked. If I changed the RigCAT COM port back to COM1, RsID began working again.  I repeated this several times, and the results were always the same.  If I opened fldigi when the fldigi_def.xml file was pointing to COM8, the RsID would not work.  I verified that the Device Manager indicated that COM8 was a functioning COM port, while I was conducting the experiment.  One interesting note is that COM1 is a hardware COM port, but COM8 is an ELTIMA virtual COM port.  The ELTIMA virtual COM port is spawned by the RemoteHams RCForb Client.  The RCForb client was actively running throughout this experiment.  I compared the fldigi_def.xml files and the only difference was the <XMLRIGDEVICE> tag.  The functioning fldigi_def.xml file contained <XMLRIGDEVICE>COM1</XMLRIGDEVICE>, while the disfunctional fldigi_def.xml  file contained <XMLRIGDEVICE>COM8</XMLRIGDEVICE>.  It is also worth noting, that the fldigi application at our club station is also interfacing to an ELTIMA virtual COM port, which is spawned by the RemoteHams RCForb Server.

I don't understand what the relationship might be between the RigCAT COM port, and the RsID decoding, but at least I think I can recover when I encounter the RsID problem again.

73,
Ed
N2BHD

Ed
 

Hello Dave,
Yes, the RemoteHams software provides a VoIP interface for the audio.  However during my test scenario, I was not using the RCForb Client for the audio interface.  I was only using the RCForb client for the virtual COM port.  During my test scenario, I had two instances of fldigi communicating via a pair of virtual audio cables, on the same computer.  I have used these virtual audio cables for years between fldigi and the RCForb client, without any problems decoding the actual data.  The decode of the audio RsID and data mode by the receiving instance of fldigi was perfect, when RigCAT was initialized by flgidi-def.xml to COM1.  But when RigCAT was initialized by fldigi-def.xml to COM8, the RsID would not be recognized, so the mode would not change in the receiving instance of fldigi.  However, if I preset the receiving fldigi instance to the correct mode, then the data message would be decoded perfectly.  I don't think the audio has anything to do with the problem, because I could make RsID work by simply changing RigCAT back to COM1.  Then the RsID and the message would be decoded correctly.  I think the problem has something to do with the code path fldigi takes when it starts up and reads the RigCAT COM port from the flgigi-def.xml file.

If there are any debug flags or logs that can be enabled to help trace fldigi's code path from when it starts until the first RsID is received, I'd be happy to work with you gather more information about it.  I have an old email address for you at bellsouth.net, if you would like to correspond offline.

Thanks & 73,
Ed
N2BHD

Al Massaro
 

Ok, as an update to this issue, we have gone back through every setting and connection, radio, signalink and computer. I have decide that the issue is either with his incoming signal strength or with a recent windows 7 update. We have intermittent RXID operation, e.g. the Satern net yesterday his setup changed from Olivia 8-500 to the transmitted Olivia 8-1000 on its own, however the next change to Thor the rig never changed, additionally any further changes to the TXID had no effect on his setup. I am adding the equipment listing that may jog a memory of something similar and the repair for it.
Computer: Lenovo Win 7 laptop (spkr vol 50%, mic volume 50%)
Radio: Yaesu FT450D (AF gain typically at 25% +-)
Signalink USB card (Rx knob typically at the 10-11 o'clock position)
Antenna:Homebrew NVIS or a Butternut HF9V (NVIS CAPABLE OF A 1:1+- SETTING, BUTTERNUT 1.5+)
Tuner: Icom AT 100 manual, adjust
As I stated previously, the system had received and changed mode fine until that mysterious something changed, I have been back through all of this NR/BB settings and can find nothing wrong (not my radio so not readily familiar). The setup receives data and decodes just fine when it sees the signal. PSK31, MT63, Olivia, etc. 
I am at a loss to figure this thing out, as stated I am of the opinion it is signal or update related, just not sure what could be preventing the RXID from working properly,
AL M 
KF5SMH

 

Have you considered RFI in the shack?

Al Massaro
 

Thanks Dave Alexander, he has had one rf change in the shack and it occurred about the same time this issue reared it's head. We are pursuing that diligently, the unfortunate aspect is it is his hearing aid system. Although today we did confirm we can make everything work correctly via VHF simplex low power output as we are approx .1.0 mile apart give or take. We will work on the HF side of this issue over the next few days or so.
AL M
KF5SMH

 

Hummm, hearing aid. Well I guess that leaves out fixing it with ferrite beads!

 

I was thinking you could get a meter and  check for RFI. Try turning it off and operate for a while, then turn it back on and see if there is any difference.

 

Good Luck

 

73’s

Dave

KA3PMW

 

From: winfldigi@groups.io <winfldigi@groups.io> On Behalf Of Al Massaro
Sent: Tuesday, January 22, 2019 6:04 PM
To: winfldigi@groups.io
Subject: Re: [winfldigi] RSID will not change modes

 

Thanks Dave Alexander, he has had one rf change in the shack and it occurred about the same time this issue reared it's head. We are pursuing that diligently, the unfortunate aspect is it is his hearing aid system. Although today we did confirm we can make everything work correctly via VHF simplex low power output as we are approx .1.0 mile apart give or take. We will work on the HF side of this issue over the next few days or so.
AL M
KF5SMH


Virus-free. www.avg.com

Al Massaro
 

An update for those interested in the on-going saga. After extensive checking of settings and parameters, and a complete swap of nearly every component we now have it receiving intermittently on VHF. We set his receiving station on Olivia 8-500 and I Tx an MFSK 32 ID, change mode perfectly, try to send an MT63 change and nothing. Shutdown the receiving station FLDIGI (program only) restart and test MT63 again change just fine, the system will not change again until a restart of FLDIGI once again then it will change one time only. As an additional attempt at confirming RSID reception I have enabled the RSID in notifications, and we do not get the dialog window on receipt of the signal. There is no problem with message data received in any mode to include images in MFSK, which leads me to a question, does RSID depend upon a cleaner signal than data? Data has error correction to compensate, ID does not I imagine, signal degradation could be a very relevant issue?
P.S.The hearing aids were not the issue as we had hoped.
AL M
KF5SMH

Dave
 

What is the Rx-audio to computer interface?

David

On 2/4/19 11:24 AM, Al Massaro wrote:
An update for those interested in the on-going saga. After extensive checking of settings and parameters, and a complete swap of nearly every component we now have it receiving intermittently on VHF. We set his receiving station on Olivia 8-500 and I Tx an MFSK 32 ID, change mode perfectly, try to send an MT63 change and nothing. Shutdown the receiving station FLDIGI (program only) restart and test MT63 again change just fine, the system will not change again until a restart of FLDIGI once again then it will change one time only. As an additional attempt at confirming RSID reception I have enabled the RSID in notifications, and we do not get the dialog window on receipt of the signal. There is no problem with message data received in any mode to include images in MFSK, which leads me to a question, does RSID depend upon a cleaner signal than data? Data has error correction to compensate, ID does not I imagine, signal degradation could be a very relevant issue?
P.S.The hearing aids were not the issue as we had hoped.
AL M
KF5SMH