A Dsec would be useful where time is perfectly well synchronised but the
system incorporates a fixed and known delay, such as might exist on a
remote station where the audio stream is decoded locally.
Regards, Mark
On 06/05/2019 12:36, Bill Somerville wrote:
On 06/05/2019 11:49, Jay Hainline
Having just watched another station sending a "CHK TIMING" message in
FT8, which is obviously not likely to succeed...
I was wondering if a non-timing-critical "message" could be added to the
protocol, e.g. four continuous tones - or some such combination that is
unlikely to happen randomly, b
Hi Bob,
could you also look at the scenario where Tx5 is being used to send qrz,
e.g. "QRZ EI3KD". A reply to this isn't handled well by auto-sequencing.
In fact, when doing this, it didn't even seem to be possible to
double-click on a caller to fill the fields, without halting tx first?
Reg
Hi Jim,
I concur re habitually unchecking "Lock Tx=Rx" when sending Tx6 ("CQ") -
I curse myself when I've forgotten to do it and someone calls me split,
consequently finding myself dragged off to their qrg. Calling cq and
then accidentally leaving the original qrg seems to be considerably more
Bill,
I'm currently trying to capture some examples where the WSJT-X waterfall
appears to become corrupt with multiple images of signals, along with
multiple decodes - I see this fairly frequently when using FT8, and have
also seen it very rarely with JT65, including on older versions of
WSJT
+/- 1.5s shouldn't present a problem to anyone, even, just about, for
people (e.g. some dxp) that rely on crude GPS NMEA serial data time
synchronisation.
In the (unlikely?) event that an even shorter DT window is ever
considered, I'd like to request that a small range of DT adjustment be
mad
Hi Bill,
could it be implemented it such that, if set, "Skip Tx 1" is simply
ignored if the dx call is a compound callsign?
In fact the whole Tx1/RR73 thing might be boiled down to a more generic
option, like "minimal", or "optimise", or similar - i.e. attempt to use
the least number of exch
on a decode populates Tx1
> through Tx5. I tested this on r7375.
> Steve k9an
>
>> On Dec 13, 2016, at 2:00 PM, Mark Turner wrote:
>>
>> just a small thing: In MSK144 mode, when double-clicking a decoded call
>> to populate the messages, TX5 (the 73 message) isn
just a small thing: In MSK144 mode, when double-clicking a decoded call
to populate the messages, TX5 (the 73 message) isn't changed from the
previous callsign. Other appropriate message fields are changed as expected.
Regards, Mark
--
Hi
I find I have to run my rig's rx audio level at a significantly lower
output for WSJT-X 1.7 than any other software, such as WSJT, MSHV, etc.
As an example, if I set the rig audio output such that WSJT 10 indicates
-14dB then WSJT-X 1.7 indicates 42dB, so you can see that if WSJT is set
to
I'm also encountering a crash (to desktop) when trying to use MSK144 on
build 7005 (clean build from svn), at the point where it attempts to
switch to TX. Everything else (e.g. the other modes) work fine.
Windows 10 Pro.
Regards, Mark
On 06/08/2016 07:47, Claude Frantz wrote:
> On 08/05/2016
Hi Bill,
it is implied by the fact that nothing is decoded, other than on the
selected rx frequency.
Regards, Mark
On 20/06/2016 20:42, Bill Somerville wrote:
> On 20/06/2016 20:17, Mark Turner wrote:
>> An unrelated "feature": On first installation, the "Single deco
decode"
checkbox is shown unchecked, but appears to be active. I've had to cycle
the check box to get it to properly clear.
Regards, Mark
On 19/06/2016 19:05, Bill Somerville wrote:
> On 19/06/2016 13:27, Mark Turner wrote:
>> Perhaps I should try to go back a
>> version or
ecifically to see if it was fixed. I
could easily have mislead myself... Perhaps I should try to go back a
version or two to check, when I work out how.
Regards, Mark
On 19/06/2016 12:26, Bill Somerville wrote:
> On 19/06/2016 07:37, Mark Turner wrote:
>> (using 1.7.0.r6870, but has
Hi,
(using 1.7.0.r6870, but has been seen on previous recent builds)
Windows 10 Pro, up-to-date, Soundblaster Live! USB soundcard, WSJT-X set
to JT65 mode (VHF features disabled, everything pretty much default).
Occasionally, but more frequently than rarely, I'm seeing a very strange
display i
used now :)
Regards, Mark
On 07/05/2016 15:03, Bill Somerville wrote:
> Hi Mark,
>
> comments in line below.
>
> On 07/05/2016 14:58, Mark Turner (EI3KD) wrote:
>> lots snipped, but the clip below what was I was looking for; so my
>> understanding is that it will be po
Thanks Bill,
lots snipped, but the clip below what was I was looking for; so my
understanding is that it will be possible to auto-generate the "RO",
"RRR", "73" short-code messages instead of reports+signal strengths,
etc, for Tx3/4/5 in WSJT-X for EME, if we choose?
I do understand about the
Hi,
is it intended that the next incarnation of WSJT-X might be used for
EME? If so, it might be appropriate to look at the messages created by
"Generate Std Msgs", which currently seem fixed to the terrestrial
format. I couldn't find a way to change that behaviour but I might have
missed it.
Hi Joe,
There's certainly no reluctance to try new modes in Europe; as soon as a
new one appears, there's always a flurry of experimenters trying it out.
There are plenty of people who've used ISCAT and JTMSK extensively but
have migrated back to JT6M, and they seem to be of the opinion (when
As Joe says, that is the normal behaviour of the program.
It does seem to be rather unusual though - under normal circumstances,
once one starts sending a report it's generally considered "bad form" to
change it. It's currently quite possible that many different reports
could be received by one
20 matches
Mail list logo
