That's a good point. Even though I can see the signal better doesn't mean
better decode I guess. My FST4-60 N6SS decode was done at 3K default band
setting, and I have not decoded on FST4 with 600 Hz RFilter yet, however it
is very beneficial on FT8. I will stay at 3k for initial testing, I did try
On 2/9/2021 1:34 PM, Adrian wrote:
Once a sought signal is known from a cluster or a random rx, then lost
etc on its audio freq, you can hone in on it with narrow filtering.
Last I heard, K1JT advised strongly against narrowing the IF, because
the filters create phase shift in the passband tha
Jim, yes while working FST4-60 you will not auto detect FST4-300 signals
which I was using unless you manually see the signal line, and see its
vertical size past the '60' markers, to then increase the time capture
to match it, as I am sure you are well aware, but that is why you have
not seen
> On Feb 9, 2021, at 7:47 AM, Joe Mixsell wrote:
>
> Thanks guys for input. Will see if I can keep the RF out.
>
>>> On Feb 8, 2021, at 3:58 PM, Jim Brown wrote:
>>>
>>> On 2/8/2021 4:19 PM, JOE MIXSELL wrote:
>>> Wonder if anyone has seen this behavior and if so what might you have done
Thanks guys for input. Will see if I can keep the RF out.
> On Feb 8, 2021, at 3:58 PM, Jim Brown wrote:
>
> On 2/8/2021 4:19 PM, JOE MIXSELL wrote:
>> Wonder if anyone has seen this behavior and if so what might you have done
>> to eliminate it. Set up is TS 590, MFJ 1204 and HP labtop. Cab
Hi Dave,
I don't think you have sent us any .wav files for EME QSOs on 6 meters.
It would be very useful to have some indication of your on-the-air
experience with Q65 for 6m EME.
Have you at least studied the example files for 6m EME mentioned in the
Quick-Start Guide to Q65? Or read the
Bill, N6SS is using an Elecraft K3, and myself a Yaesu FTDX101MP, which
are extremely stable on frequency in test reports. N6SS decodes me ok on
FST4-300. Is there a log I can check for this for my RX ?
Thankyou
Adrian Fewster
On 10/2/21 1:06 am, Bill Somerville wrote:
Hi Adrian,
does you
Hi Adrian,
does your, and your QSO partner's, equipment meet the frequency
stability requirements of FST4-300 mode?
73
Bill
G4WJS.
On 09/02/2021 14:46, Adrian wrote:
Bill tried again tonight with N6SS on FST4-300, and no success here decoding.
I used both 600Hz roofing filter making a very p
Bill tried again tonight with N6SS on FST4-300, and no success here decoding.
I used both 600Hz roofing filter making a very prominent seen signal N6SS, and
tried with the normal 3 KHz rx filter.
Tried 20 and 100 FTol. After several rx seen signal passes, there was no
decode. TX and RX pan freq
>This strikes me best handled by astute operators rather than by software that
>will rapidly consume the efforts better spent on performance and capabilities.
Hi,
If somebody really needs that kind of automated help, then some companion
program would be a better place for implementation. I thi
GA/GM Bill and all of the developers,
Thank you so much for all the team is doing.
Can Short-Hand messages be added for Q65A (used at 6m) also please?
It’s helpful to have those single-tone messages Q65A at 6m EME because I have
had at least one 6m EME JT65A weak signal QSO where
This strikes me best handled by astute operators rather than by software that
will rapidly consume the efforts better spent on performance and capabilities.
George J Molnar
College Park, Maryland
KF2T | FM19ma___
wsjt-devel mailing list
wsjt-devel@lists
I think agree with you Tom, and as you suggest, creating the possibility to
have a list of calls that is not answered by WSJT-X might be a better
solution. An 'Ignore' list where users can put in calls of known bots and
other callsign ranges other that they don't want to work would
absolutely be a
wholeheartedly agree Tom
On Tue, 9 Feb 2021, 13:31 tom, wrote:
> Against it.
>
> There are too many callsigns being issued for numerous reasons -
> anniversaries / covid / 1st etc. Having the software check (and keep
> having to get internal lists updates from other sites) is not really
> pract
Against it.
There are too many callsigns being issued for numerous reasons - anniversaries
/ covid / 1st etc. Having the software check (and keep having to get internal
lists updates from other sites) is not really practical.
I can’t think of an easy way to detect pirates - non-dxcc you have
On 09/02/2021 03:54, Hattori, Yoshihisa wrote:
Hi all.
I am testing Q65 and realized that we are missing Short hand indicator
on waterfall display, which is provided for JT65. (three yellow lines
suggesting the RO/RRR/73 tones.) While less Q65/QRA64 users are using
shorthand, it is good to h
On 09/02/2021 02:51, halst...@gmail.com wrote:
2.3 and 2.4-rc1 both still have the defunct Yahoo Groups support email
address on the splash screeen.
~W. Halstead
KN6HXP
Hi OM,
thanks for the issue report, it is fixed for the next release.
73
Bill
G4WJS.
___
Would it be an idea to implement a 'Valid DXCC' checking and 'Pirate
Detection' feature?
The problem is that pirate callsigns like the Dxx from the Donetsk region
in Russia show up as new/unknown DXCC's. It would be fairly easy to
implement a check against the ITU list and the valid DXCC list and
On 2/9/21 9:10 AM, Reino Talarmo wrote:
Hi Reino and all,
A piece of wire between RTS and CTS at rig end may also work as then rig
thinks that a hardware handshake is there. May not work in all case and all
situations, but worth of try. Normally PC does not care as long as WSJT-X
handshake None
>RTS/CTS is the same as HARDWARE. Here these lines are not present, as you
explain well. XON/XOFF (aka DC1/DC3, aka Ctrl-Q/Ctrl-S, aka software flow
control) is possible in this constellation, but the support is necessary at
BOTH ends of the line.
Hi Claude,
A piece of wire between RTS and CTS at
20 matches
Mail list logo
