On Fri, Jun 5, 2020 at 11:45 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
>
> On Friday, June 5, 2020, 06:36:13 PM CDT, Josh Rovero <
> josh.rov...@gmail.com> wrote:
>
> Any hints?
>
Unless you just really want to build from source yourself you can use the
Fedora ver
WSJT-X 2.2.1 is a bug-fix release that addresses several regressions or
defects in version 2.2.0.
Most importantly, v2.2.1 incorporates a revised Hamlib version that
properly controls the Yaesu FT-891 and FT-991 radios. A list of all
program changes since WSJT-X 2.2.0 can be found in the cumu
Thank you for the update. I am able to connect with my Yaesu FT991 direct
again to control the radio.
73 Jay KA9CFD
-Original Message-
From: Joe Taylor
Sent: June 6, 2020 17:44
To: WSJT software development
Subject: [wsjt-devel] WSJT-X 2.2.1 GA Release
WSJT-X 2.2.1 is a bug-fix relea
Out of curiosity, why not list hamlib as a prerequisite and have people
install it separately, so that those of us that already use it and keep it
updated don't have duplicated libraries on our systems that can potentially
cause version conflicts?
Hamlib has installers for windows and Mac on the gi
On 06/06/2020 19:55, Topher Petty wrote:
Out of curiosity, why not list hamlib as a prerequisite and have
people install it separately, so that those of us that already use it
and keep it updated don't have duplicated libraries on our systems
that can potentially cause version conflicts?
Hamli
WSJT-X 2.2.1 GA on both RaspberryPi and macOS (10.14.6)
Dreaded “RigFailure Hamlib error: Target VFO unaccessible while getting
current frequency” when Rig: Yaesu FT-897.
Have not had this issue with these settings on previous releases.
The good news is, that, if I select Rig: Yaesu FT-857, ins
On 06/06/2020 21:33, Chuck Reti WV8A via wsjt-devel wrote:
WSJT-X 2.2.1 GA on both RaspberryPi and macOS (10.14.6)
Dreaded “RigFailure Hamlib error: Target VFO unaccessible while
getting current frequency” when Rig: Yaesu FT-897.
Have not had this issue with these settings on previous releases
It's not a regression...the FT857 has never had set_vfo or get_vfo enabled so
never should have worked.
The FT857 does have set/get_vfo but it uses a vfo toggle just like the FT897.
If the FT857 is working well with this we can implement the same thing for the
FT897.
Are you operating in rig sp
Bill, I just looked at github, and the latest commit was 23 minutes ago...
I appreciate your stance w/r/t conflicts, however, uninstalling wsjtx 2.1
resolved issues I was having with SKCClogger and FLDIGI. it may be
"rubbish", but using dpkg to remove the .deb published on the Princeton
website res
Chris,
here's the list of files installed by the WSJT-X Debian package, no
more, no less. Please explain to me how any of those files could
possibly interfere with another application? Indeed, how could any of
them have anything to do with some other Hamlib installation on your system.
BTW,
Bill:
You tell me. All I know is that I was having issues with rig control on two
other pieces of software, and when I uninstalled WSJT-X 2.1.x, those
problems disappeared. The other two pieces of software worked flawlessly
with their hamlib rig control, even surviving reboots, until I re-installed
For example:
I won't report that, for some reason, 2.2.1 seems to cycle my 7300 from VFO
A to VFO B and back to VFO A on startup, which makes me need to press the
"TUNE" button again to get the auto-tuner back in sync with the radio. I
won't report that changing bands to a band 15m and above using
Hi Team,
Win10, USB SignaLink to Yaesu FT-817ND: Similar error to that already
reported with FT-897D.
"RigFailure Hamlib error: Target VFO unaccessible while getting current
frequency"
Have rolled-back to 2.2.0 which is working well.
I noted the 857/897 discussion; Q: which alternate
On 07/06/2020 01:08, Topher Petty wrote:
For example:
I won't report that, for some reason, 2.2.1 seems to cycle my 7300
from VFO A to VFO B and back to VFO A on startup, which makes me need
to press the "TUNE" button again to get the auto-tuner back in sync
with the radio. I won't report that
There are a (small) number of WSJT-X users who have difficulty reporting
their spots to pskreporter. Some of these are in "difficult" areas of
network connectivity (e.g. Marine Mobile) and I suspect that the UDP
transport is losing most of their packets. The general loss rate seems to
be around 1%-
Apparently the statically linked WSJT-X with its own hamlib does...
Neither FLDIGI nor the SKCClogger does these things on startup..
As SKCClogger is written in Python and references my local copy of hamlib,
this shows that hamlib most likely isn't the issue.
But you're right... I should contact th
I've got a friend with an IC-7300 that I'll test this with.
Sounds pretty strange that preamps are being changed.
I'll let you know if we can duplicate this.
Mike W9MDB
On Saturday, June 6, 2020, 07:17:03 PM CDT, Bill Somerville
wrote:
On 07/06/2020 01:08, Topher Petty wrote:
> For e
It sounds like SKCClogger was talking to WSJT-X rigctld-wsjtxis that
possible?Otherwise I don't see how it could have any effect.
As another test move the WSJT-X into a subdirectory in WSJT-X and then move
them back one at a time and see if any particular file breaks things.Most
likely to be
And when you are installing WSJT-X can you show how you install it?
Mike W9MDB
On Saturday, June 6, 2020, 10:53:26 PM CDT, Topher Petty
wrote:
Apparently the statically linked WSJT-X with its own hamlib does...Neither
FLDIGI nor the SKCClogger does these things on startup..As SKCClo
This sounds like a great idea. I am surprised it is not already done via
tcp.
On 7/6/20 11:23 am, Philip Gladstone wrote:
There are a (small) number of WSJT-X users who have difficulty
reporting their spots to pskreporter. Some of these are in "difficult"
areas of network connectivity (e.g. M
Hi Adrian, messages via TCP put a requirement on the local PC to handle
errors which all add complexity and resources to do it. The messages have
to be sent, an answer waited for and if no answer, sent again until a time
out is received, then handle this time out... UDP on the other hand is a
send
Hi Folks,
Interesting discussion. Peter’s overview is 100% correct. Philip (PSKReporter’s
maintainer) states that his resource should only offer a “guide” and I must
also highlight that.
TCP should be perhaps only used in the exception and only if uploads to
PSKreporter are observed to not reg
Hi Peter:
While its true that the TCP protocol puts additional computing requirements on
both the sender (the local PC) and the recipient to guarantee the reliable,
ordered, and error-checked delivery of data, these additional requirements are
nearly insignificant in modern fast networks and ne
I did not see Steve's reply before I sent mine. While I disagree with the
conclusion that "Peter’s overview is 100% correct.", I don't think we have to
reach agreement on that point. If you are designing a client/server
application, and want to make a call as if you should implement communicatio
24 matches
Mail list logo
