Discussion in 'Working Different Modes' started by KD2NOM, Sep 16, 2017.
Log40M works fine but I can't keep the radio on frequency with Omnirig for some reason
Why dont you request assistance on our Log4OM forum if you have a problem?, we are always pleased to help and we have hundreds of users happily using WSJT/JTALERT with Log4OM without issue.
Terry G4POP Log4OM developer
Thanks. I'll pu something on, but i dont think its a log40m issue
I am convinced its a small issue easily fixed no matter which program is causing it
Well, sort of.
If you are running a rare call or location, people calling you can reduce the congestion on your run frequency by running split. Doing so increases the congestion throughout the rest of the receiver passband, however, and it can actually increase congestion on other people's run frequency.
I'm amazed at how much really bad behavior is caused by the "split" operation in WSJT-X. E.g., I'll be running a frequency, and somebody calls me -- on my current transmit frequency -- we exchange a QSO, and then they start calling CQ on my transmit frequency, in the opposite time slot. That means they are now clobbering everybody who is calling me S&P on my current transmit frequency. If they did that in any other mode, they would quickly earn the title of "lid of the year," but somehow because it's FT8, people think it's okay to clobber other people "because the manual tells me to."
The only way "split" can reduce congestion for everybody is for everybody to run a frequency, and only opportunistically S&P individual stations while they run. That means there has to be room in the passband for everybody who wants to run, and it can easily leave no room for people who just want to S&P.
Yes, their behavior does strike me as a bit pirate-ish.
The manual gives a detailed justification for operating split and breaks it down in terms of QSO success rate. From a VK perspective it works particularly well, because I can easily find a clear frequency time slot on which to transmit, and usually I stick to it. The only frequency I never respond to is the opposite time slot on my frequency, well unless it's a rare DX station because I know there will be much more QRM on that frequency and it's usually a lost cause. I have often had "local" FK8 stations call on "my frequency" and I'm happy about it because on that frequency at least they are not causing any QRM to me.
If everybody just read the manual, the congestion would be a lot less.
Hi - did you get this fixed? Just asking because I've just experienced (caused it!), and fixed it. I came here to post the cautionary tale, did a search and came across this thread. My short story as follows:
I'm using WSJT-X via OmniRig to an FT450. All working fine with Log4OM. Months ago when I set it up, I had to mod the .ini file to get the radio to go to USB-Data mode correctly (that's when I learned about the ini files).
Tonight, playing with my new RSP1a and HDSDR, a bit of Googling led me to make another mod to the OmniRig ini file for FT450, in order to have HDSDR mute on Tx when it's advised by OmniRig that the FT450 is in Tx. I followed someone else's experience and changed a flag indicating "Tx" at the end of the ini file from a 1 to a 2 - bingo, HDSDR mutes on Tx allowing me to use it as the receive audio & play with the filtering without my own voice in my ears with a 0.75 second delay.
Then I go back to WSJT-X, where I've been operating "Split" as advised by the manual (which isn't split but a method of keeping the Tx audio freq in a reasonable range but that's by the way), and the radio starts wandering off frequency after a few Tx/Rx cycles. The frequency was changing just prior to each Tx as usual, but not changing back for the Rx cycle - so instead of +0.5, -0.5, +0.5, -0.5 it was going +0.5, 0, +0.5, 0, +0.5......
Changing the ini file back to how it was fixed it - but of course un-fixed the HDSDR mute on Tx fix.
The conclusion is that this problem can be caused by - as far as I can deduce - WSJT-x not getting confirmation from the rig that it has gone into Tx, and therefore not "undoing" the freq offset it sent to the rig just before the Tx cycle.
Now I need coffee!
.....or it could be caused when the rig fails to go into transmit if you're using Digital VOX control and have the levels set wrong. I thought I had ruled this out though.
In any case, now that I've discovered that the option for "CAT" under PTT control in WSJT-X *includes* "CAT over OmniRig", and started using it, I've discovered that I can re-do the .ini file mod needed for HDSDR mute-on-Tx without causing the wandering Tx frequency issue on WSJT-x.......