Hello Gary,
I saw this in a QSO too. ??? It is like you are holding a printed
sign in front of a blind person and waiting for an reaction.
If you TX those texts in 77bit, only the ones with 77bits can read it
and "NO RCV 75 BIT" is like talking to yourself. For the ones using
RC4 or RC5 in 77bit
While everything functioned normally at my end of the world during this
evening's FT8 RU mock, I was puzzled by the number of dupes directed my way.
I was playing the role of a RUN station, transmitting at :00 and :30, and
had 3 stations who worked me, then turned around immediately and called me
All,
I operate on 60m with the FTDX3000 often enough (over 120 FT8 Qs, over 140 Qs
overall) The FTDX3000 uses memory channels for 60m operation, so you need to
shut off all rig control when operating on 60m. I now do this through a
separate configuration. I usually do the following:
- Set
Good on yer, Chuck!
I have composed and compiled a motley collection of free text messages to send
in sequence or sporadically between CQs e.g. “WSJTX2 RC5 HR”, “77 BITS ONLY”,
“NO RCV 75 BIT” and (in desperation) “PLS TX 77 BITS”.
Hey, it’s only a hobby! I’ve made about 10 shiny-new FT8
Bill,
(I'll put this comment in this thread instead of starting a new one, since
you are the "color" guy :)
Is there any way to control colors of a non-CQ message? There doesn't seem
to be, and I would like to do that.
For example:, I'd like to have a visual cue when someone not in the log is
fi
On page 5, LoTW Download Errors:
Note that Win32 OpenSSL is now at revision "q"
The new release works OK on my Win7 Pro 64
73-Larry.
K4OZS
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-d
When a new QSO is added to the bottom of the "Contest Log" window, and
the window is full, the window does not scroll down to show the last
QSO that was just added.
This is on Ubuntu 18.04 GNOME.
-John AC6SL
___
wsjt-devel mailing list
wsjt-devel@list
Ubuntu 18.04 AMD64
4 contacts - first two had to enter "rpt sent" and "exch sent" in log
dialog box.
Exited and restarted wsjt-x.
Second two, still had to enter "rpt sent" and "exch sent". Both fields
blank.
Log looks OK so far.
djb
___
wsjt
Ezacerly! We
Most non-standard/custom CQ messages are unclickable i.e. double-clicking them
doesn’t trigger an automated-response because the software doesn’t know who to
respond to. They are treated as free-text messages. They are not
automatically interpreted as CQs.
FT8 lets us in
It certainly is frustrating. I'm calling CQ and getting responses that are
very strong, but will not decode. I assume they are using 75 bit to respond
to me. I just sent a free text message "USE 77BIT" to one person and
suddenly his signal magically started decoding :). Oh well, in spite of all
the
Prior release candidates were able to decode both 75 AND 77-bit messages but
since there are many more 75s than 77s floating about, users mostly send 75 bit
responses … unless prompted … and even then it’s like pushing string uphill
some days …
Those of us using RC5 can ONLY transmit and receiv
On 29/11/2018 01:58, SKI W4PPC wrote:
After two QSO were logged now receiving Invalid QSO Data Check all
fields (attached) but nothing shows errors!?
Hi OM,
so I can see what happened, can you zip and send me the file db.sqlite
from your WSJT-X log directory please.
73
Bill
G4WJS.
__
Yes, if I manually fill the fields, the logging works.
On Wed, Nov 28, 2018 at 9:23 PM Bill Somerville
wrote:
> On 29/11/2018 02:05, Mark James wrote:
> > I seem to have run into an issue with the contest mode.
> >
> > Sometimes -- not always -- the "Exch sent" and "Rpt sent" fields in
> > the l
On 29/11/2018 02:05, Mark James wrote:
I seem to have run into an issue with the contest mode.
Sometimes -- not always -- the "Exch sent" and "Rpt sent" fields in
the log window are not getting populated, even though the QSO worked fine.
This is an example QSO from the "ALL.TXT" file, for whi
Actually, I have never seen one of my 77 messages as decoded - just assumed it
would decode as the bottom of pane tx message being sent read. I think all of
the non-standard messages I tried to answer by double-click had no numbers in
them, and they still did not auto-start.
Al Pawlowski, K6AVP
I seem to have run into an issue with the contest mode.
Sometimes -- not always -- the "Exch sent" and "Rpt sent" fields in the log
window are not getting populated, even though the QSO worked fine.
This is an example QSO from the "ALL.TXT" file, for which I had the logging
issue (with other stat
After two QSO were logged now receiving Invalid QSO Data Check all fields
(attached) but nothing shows errors!?
On Wed, Nov 28, 2018 at 7:54 PM Don Hill AA5AU wrote:
> Stations worked in the Roundup practice session are showing as new grids
> after they are worked and logged. The solution is to
Stations worked in the Roundup practice session are showing as new grids
after they are worked and logged. The solution is to uncheck "New Grid" and
"New Grid on Band" on the Colors tab of Settings.
Now, worked stations are shown in Green as they should.
Don AA5AU
_
Thank you. I knew I was missing something.
On Wed, Nov 28, 2018 at 7:38 PM Bill Somerville
wrote:
> On 29/11/2018 01:30, Chuck Furman wrote:
> > I’m confused. Why is CQ 77 helpful?
>
> Hi Chuck,
>
> the idea is a hint to v2.0.0 RC3 or RC4 users who probably will not have
> their "Force 77-bit Tr
HI Al.
As I understand it, the zero to 4 characters we can insert into a standard CQ
message must be letters only – no numbers – if the recipients are to be able to
double-click and respond to them. That’s why I’m using “CQ PLUS”. It’s a
limitation of the message compression – not enough b
On 29/11/2018 01:30, Chuck Furman wrote:
I’m confused. Why is CQ 77 helpful?
Hi Chuck,
the idea is a hint to v2.0.0 RC3 or RC4 users who probably will not have
their "Force 77-bit Transmissions" option checked. They will decode
77-bit but reply in 75-bit. If they are still following the
rec
I’m confused. Why is CQ 77 helpful? Only people who are already on 77 bit
mode will decode you. Am I missing something? I am just curious. It seem
more useful to TX on 75 bits with something like “PSE USE 77BIT”
On Wed, Nov 28, 2018 at 7:23 PM Al Pawlowski wrote:
> I have used “CQ 77 …..” a few
I have used “CQ 77 …..” a few times for the same thing and it is not very
sticky also. In fact, even saved free text messages revert to the standard
after any attempt to answer a call.
In addition, it appears double-clicking a received message with , which
is what other non-standard CQ messages
Thanks Joe!
Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone
Original message From: Joe Taylor Date:
11/28/18 6:41 PM (GMT-06:00) To: WSJT software development
Subject: Re: [wsjt-devel] ISCAT Problem?
On 11/27/2018 10:20 AM, Rory Bowers K5CKS wrote:
> Is t
On 11/27/2018 10:20 AM, Rory Bowers K5CKS wrote:
Is there a chance you will change that to a double click Joe?
No. ISCAT uses free-form messages. It's totally unsuited to
double-clicking or Auto-Sequencing logic.
I think
ISCAT could be a LOT of fun. I was amazed at the sensitivity!!
I
Have you given any more thought to improvements to ISCAT Joe??
Rory, K5CKS
Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-d
I'm running RC5 on the air for about an hour a day from NZ. Aside from
transmitting above 2000 Hz, I've tried sending "CQ PLUS ZL2IFB RF80" and
little free text messages to give more of a clue that I'm using the new 77
bit version . but I've noticed that the "PLUS" in my CQ message is not very
st
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
On 28/11/2018 21:22, DG2YCB, Uwe wrote:
Just one further question: N9BUB is a new call for me, but also a new
call on band. Thus, background color is assigned to the darker green
and foreground color is assigned to blue. Correct? But that means that
currently I cannot use the foreground color f
On 28/11/2018 20:07, Paul Kube wrote:
This way of doing things does provide some nice flexibility as you
point out. It is rather counterintuitive though; for example there is
no way to tell by looking at the color settings whether a foreground
color is set to black, or is not specified. I'm sti
Hi Phil and Ed,
Thanks for sharing your views.
We thought long and hard about backward-compatibility issues before
concluding that a change in the FT8 protocol was highly desirable.
Among the most important motivations were these:
1. Message formats optimized for North American VHF contests,
Hi Phil.
This question is really for the WSJT development team to address. But, my
personal opinion as a user differs a bit from yours. I'll offer it here as
another perspective.
In general, I agree with your stated principle of backward compatibility.
At the same time I tolerate breaking the p
Hi gang,
For those of us wanting to import ADIF files from other sources into WSJT-X,
this feature, documented in the most-recent released user guide, is not
working in RC5:
". turning Show DXCC entity and worked before status off and then on again
will cause WSJT-X to re-read the log file."
Hi Uwe,
I think there is some misunderstanding of how the colour highligting is
applied. For each highlighting type the foreground and background colour
may either be specified or not. If a colour option is not specified then
no highlighting for that highlighting type and, most importantly,
a
The signal strength report you received from the other station.
On Wed, Nov 28, 2018 at 1:01 PM Al wrote:
> When not in contest mode, what does the rcvd field signify on the log form
> ?
>
>
> AL, K0VM
> ___
> wsjt-devel mailing list
> wsjt-devel@lists
Oh disregard I just noticed the bottom right Recd box.
On Wed, Nov 28, 2018 at 1:05 PM Ryan Tourge wrote:
> The signal strength report you received from the other station.
>
> On Wed, Nov 28, 2018 at 1:01 PM Al wrote:
>
>> When not in contest mode, what does the rcvd field signify on the log
>>
When not in contest mode, what does the rcvd field signify on the log form ?
AL, K0VM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Hi Bill,
You are right. Thanks for spotting the wrong chevron.
Problem solved.
— John G4KLA
smime.p7s
Description: S/MIME cryptographic signature
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listin
As a non-LoTW user, I'd have to agree with Uwe.
I'd much prefer there be a way to highlight non-LoTW folks. Maybe that
way, folks in the USA who do use LoTW would stop calling me, especially
when I'm calling for DX.
On 11/28/2018 15:14, DG2YCB, Uwe wrote:
May I ask you for a slight change
Bill,
No, I have I never imported an ADIF into WSJT... This particular log
was started new with RC4 and continued with RC5.
AL, K0VM
On 11/27/2018 3:47 PM, Bill Somerville wrote:
On 27/11/2018 21:30, Al wrote:
Note below the change in color for GW4HDR after I called him the
first time..
Thanks, All
Lee KX4TT
-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
You have complete freedom to set the colors as you wish.
-- Joe, K1JT
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lis
It's not the colour, but the usefulness of the option. So, it's
UNCHECKED. Problem sorta solved.
On Wed, Nov 28, 2018 at 9:39 AM Bill Somerville
wrote:
> On 28/11/2018 15:27, Lee. KX4TT via wsjt-devel wrote:
>
> It also does not work well with the green highlighting for those who are
> color-b
This was changed in a recent RC from NOT LoTW user to YES LoTW user.
According to JT it was to conform to other programs with LoTW
highlighting. I guess those programs are devoid of LoTW users.
Since the change, I just keep the LoTW box UNCHECKED as it is of no real
interest as most users are LoT
Lee --
On 11/28/2018 10:27 AM, Lee. KX4TT via wsjt-devel wrote:
It also does not work well with the green highlighting for those who are
color-blind; People with either protanomaly or deuteranomaly may have
problems in this case. The result for red lettering on a green
background can be two i
On 28/11/2018 15:14, DG2YCB, Uwe wrote:
May I ask you for a slight change in the logics regarding the
highlighting of LoTW? Seems that there are only a very few stations
NOT using LoTW. Means when LoTW option is selected, nearly all text is
in red color (as for LoTW users foreground color is
On 28/11/2018 15:27, Lee. KX4TT via wsjt-devel wrote:
It also does not work well with the green highlighting for those who
are color-blind; People with either protanomaly or deuteranomaly may
have problems in this case. The result for red lettering on a green
background can be two indistinct
On 28/11/2018 15:20, John Nelson wrote:
Hi Bill,
That does sort files in blocks of date order; but within a block the sequence
remains in numerical order. I tried Data Modified and Data Created - which is
effectively the same. The drop down list doesn't have time ordered, ie: ls
-l
— J
It also does not work well with the green highlighting for those who are
color-blind; People with either protanomaly or deuteranomaly may have
problems in this case. The result for red lettering on a green background
can be two indistinct non-contrasting grays.I would actually suggest
not
Hi Bill,
That does sort files in blocks of date order; but within a block the sequence
remains in numerical order. I tried Data Modified and Data Created - which is
effectively the same. The drop down list doesn't have time ordered, ie: ls
-l
— John G4KLA
smime.p7s
Description: S/MIME c
Hi Steve,
> Personally, I prefer the naming convention the way it is now. I can tell
> which files are FT8 and which are JT65 by their different name formats.
Good point. I retract my suggestion…
— John G4KLA
smime.p7s
Description: S/MIME cryptographic signature
__
On 28/11/2018 14:34, John Nelson wrote:
I got caught out by the fact that the Open list is in strict numerical order
not time order.
Hi John,
you can change the sort order for the Finder window:
Thank will list them in strict creation time order.
73
Bill
G4WJS.
>
> *** Would it not be better if files were always numbered with 6 time digits
> insted of a mix of 4 and 6 digits, then the list would be ordered in a
> squential manner?
Hi John,
Glad that you figured out what was going on. Personally, I prefer the naming
convention the way it is now. I
Hi John,
Would it not be better if files were always numbered with 6 time digits insted
of a mix of 4 and 6 digits, then the list would be ordered in a squential
manner?
Possibly, but that's not the way we've done it. Labeling files with
4-digit times makes good sense for the modes with 60
Steve,
Agree there is not a problem. I got caught out by the fact that the Open list
is in strict numerical order not time order.
So my last FT8 WAV file was 181128_114500.wav before switching to JT65 and so
I was looking for the JT65 files to appear next in the list.
But the first JT65
It also happened to me many times. For example today three times out of four
QSOs. Two times I started a QSO, but after first report no more decoding. Each
time good signals around -13 dB. PC time synchronized within +- 5 ms. First I
thought that it was always QRM from 75 bit signals, but more a
Yes, I could wideband the transceiver. I still don't understand why after a
transmission on 5.358.500 a CAT signal is being sent to the radio to change
frequency to 5.358.308 if I put 5.358.500 in the frequency dropdown box and
I turn off split operation. Apparently, this is NOT a bug in WSJT-x? Th
Peter,
I use a Mac computer and have observed this same behavior by rc5 on my
computer.
_
On Nov 27, 2018, at 9:35 PM, Peter Sumner wrote:
Hello Dev team,
while reading the last batch of posts here, I noticed a reference by another
that their system appear to jump into J
Hi Peter,
while reading the last batch of posts here, I noticed a reference by
another that their system appear to jump into JT9 in certain
circumstances so while pondering what is going on with my RC5 install, I
noticed the Red TX marker on the waterfall is the size I would expect
for JT9
I've noticed on RC5 that when I call CQ and a station answers, I have to
send their signal report at least twice before things move along.
In checking with the other station if they have JTAlert messaging on, they
do have their Auto Seq on, and are sending their Rxx information as normal.
I'm just
Hi John,
I haven’t noticed that problem here on MacOS 10.14.
Steve, k9an
> On Nov 28, 2018, at 7:03 AM, John Nelson wrote:
>
> macOS 10.13.6: v2.0.0-rc5:
>
> FT8 is working well, colours included, on 20m, 30m and 40m. Several reports
> of -24 dB so sensitivity is vey good.
>
> I switch
Plenty of vids on you tube to wideband the 3000.
Eric J Evans
FCC Licensed Amateur Radio Operator: *K4NDN*
Elkton, Virginia 22827
Grid FM08qj
540.335.6178
On Wed, Nov 28, 2018 at 5:02 AM Claude Frantz
wrote:
> On 11/28/18 12:29 AM, Mike Saeger wrote:
>
> > My FTDX3000 works fine on FT8 on all b
macOS 10.13.6: v2.0.0-rc5:
FT8 is working well, colours included, on 20m, 30m and 40m. Several reports
of -24 dB so sensitivity is vey good.
I switched to JT65 for checks - all well. But, when attempting to decode a
saved JT65 WAV file I notice that in the “Open” list, only FT8 WAV files a
Bill, Paul, and all,
One additional observation: Seems that indeed only the foreground color is
affected by the bug. Modified my color scheme settings that way, that all
the ".on Band" colors not only have a blue foreground, but also a somewhat
lighter background. See the result in the followin
On 11/28/18 12:29 AM, Mike Saeger wrote:
My FTDX3000 works fine on FT8 on all bands except 60 meters.
The FTDX3000 has preset channels. The channel in memory 3 is preset to
5.358.500.
Hi Mike,
The XCVR's from Yaesu have often differences depending on the countries
where they are sold. This
Bill,
Yes, my wsjtx_log.adi file contains entries generated by an external ADIF
program, but band information is also in lower case. Since in contrast to
v1.9.1, WSJT-X v2.0.0-rc1 misinterpreted ADIF records with 6-digit entries
for grids, as a workaround a couple of months ago I generated one
65 matches
Mail list logo
