On 24/07/2024 14:56, Hibby via wsjt-devel wrote:
Hey Neil,
Don't worry - bubble not burst. I'm choosing to not pick a fight about
the specific licensing of the binaries. Arguments about licensing are
full of opinions and not very fun. They usually end up in flame wars and
cold disagreement,
Debian has been building wsjtx with the stock upstream hamlib for ages
without issues.
Mageia also.
We build against the system version.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
On 05/10/2023 09:33, Adrian via wsjt-devel wrote:
of a digital Mode database setup & registered to , with license proof
etc, similar to QRZ.
Hmm... Nice idea.
Are you going to set up, maintain, pay for and verify (in multiple
languages) a database of every call sign in the world?
If
On 08/05/2023 17:44, Jim Brown via wsjt-devel wrote:
I strongly disagree, Mike. Bjorn's suggestion to call it Transmit
Harmonic Prevention is a VERY good one, because it describes what the
choice does. It is NOT "split" in the sense it has been used in ham
radio for at least 70 years.
People
Further to my last and after a good search of the git log it seems that
since 2.5.4 nobody has tagged the releases.
There are commits with references to making preparations for the
releases of 2.6.0 and 2.6.1 but neither were tagged at release!
So this has broken my script which was checking
Forwarded Message
Subject: Re: [wsjt-devel] WSJT-X 2.6.1 GA Release
Date: Tue, 14 Feb 2023 16:03:56 + (UTC)
From: Black Michael
Reply-To: Black Michael
To: Barry Jackson
What does git log show?
I show this as the most recent commit
commit
On 13/02/2023 23:00, Brian Morrison via wsjt-devel wrote:
On Mon, 13 Feb 2023 22:35:13 +
Barry Jackson via wsjt-devel wrote:
On 16/01/2023 14:22, Joe Taylor via wsjt-devel wrote:
The WSJT Development Team is pleased to announce that today the
Solar Flux Index is 234 and Sunspot Number
On 16/01/2023 14:22, Joe Taylor via wsjt-devel wrote:
The WSJT Development Team is pleased to announce that today the Solar
Flux Index is 234 and Sunspot Number is 195.
Oh, yes: and the WSJT-X 2.6.1 General Availability (GA) release is now
available for free download from SourceForge.
Hi
While testing 2.6.0~RC5 I had a QSO which puzzled me. (FT8)
The attached image shows what happened.
I replied to 9K2YM's CQ
He responded and I replied with report.
Then I received:
222900 -2 0.2 1371 ~ G4MKT RR73; SP6TO <9K2YM> -18
I have never seen that format before.
He sent RR73 to me
On 19/10/2022 18:24, Barry Jackson via wsjt-devel wrote:
Seems my reply only went to Mike so forwarding to list.
...but no attachments!
Here they are.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists
: [wsjt-devel] 2.6.0-RC4 GUI error
Date: Wed, 19 Oct 2022 00:34:00 +0100
From: Barry Jackson
Reply-To: zen25...@zen.co.uk
To: Black Michael
On 17/10/2022 04:27, Black Michael wrote:
Did you increase the font size?
Mike W9MDB
Hi Mike,
Not as I recall, but it's irrelevant as you will see below
An annoying error has crept in that chops half the leading character in
the band field on the left of the main window.
Mageia cauldron (dev) (Linux)
Using 1024x1280 resolution monitor.
See in the attached photo that the 3 of '30m' is indistinguishable from
an 8.
Cheers,
Barry
Hi,
Since the sad loss of Bill Somerville I am not sure who will receive this.
I maintain wsjtx for Mageia and have just packaged 2.6.0-RC4 for testing
in Mageia (9) Cauldron.
There seems to a problem with wsjtx interaction with hamlib.
I have filed this bug report with upstream klog,
There seems to be a regression in hamlib-4.3.x which I have been testing
for our dev branch.
I maintain the wsjtx package for Mageia (Linux) and do all my testing
with my Kenwood TS-450S.
We use the system hamlib.
Fake-it works, but any attempt to use RIG for split now fails with the
On 18/10/2021 14:42, Bill Somerville via wsjt-devel wrote:
Hi Bill,
It seems we are all as confused as each other although your suggestion
would work.
Mike just suggested:
[baz@localhost ~]# rigctld -v -Z -v -m 2003 -s 4800 -r /dev/ttyUSB0
-t 4532 --set-conf=serial_handshake=None
On 15/10/2021 16:18, Black Michael wrote:
Try this
rigctld -v -Z -v -m 2003 -s 4800 -r /dev/ttyUSB0 -t 4532
--serial_handshake=None --write_delay=5
Hi Mike,
Going back to this command of yours with syntax that does not work, is
there a current up-to-date ridctld documentation somewhere.
On 15/10/2021 19:09, Bill Somerville via wsjt-devel wrote:
Hi Barry,
I have already sent Mike a copy of that document.
Great - thanks for letting me know :)
Have a good evening!
Cheers,
Barry
G4MKT
___
wsjt-devel mailing list
On 15/10/2021 18:37, Black Michael via wsjt-devel wrote:
What's the title of that manual? I'd hope it would be available on-line.
Do you have a scanner on your printer?
Also...are you able to checkout the master repo and test the fix I just
posted?
Mike W9MDB
It's called:
"TS-450S
On 15/10/2021 18:25, Barry Jackson via wsjt-devel wrote:
I do have the paper one. Maybe the bits you need are not too big?
TS-450S that is.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo
On 15/10/2021 18:25, Barry Jackson via wsjt-devel wrote:
On 15/10/2021 17:46, Black Michael via wsjt-devel wrote:
I'll have a fix for this shortlyI put in a split check for
Elecraft rigs and that is doing the "FT" query which isn't supported
as Bill notes.
Bill...do you kno
ne.
Mike W9MDB
On Friday, October 15, 2021, 11:30:50 AM CDT, Bill Somerville via
wsjt-devel wrote:
On 15/10/2021 17:21, Barry Jackson via wsjt-devel wrote:
On 15/10/2021 15:57, Bill Somerville via wsjt-devel wrote:
the TS-450S and TS-690S use RTS/CTS hardware handshake flow control.
I
On 15/10/2021 17:46, Black Michael via wsjt-devel wrote:
I'll have a fix for this shortlyI put in a split check for Elecraft
rigs and that is doing the "FT" query which isn't supported as Bill notes.
Bill...do you know of a CAT manual for the TS590/690? I can't seem to
find one.
Mike
On 15/10/2021 15:57, Bill Somerville via wsjt-devel wrote:
the TS-450S and TS-690S use RTS/CTS hardware handshake flow control. I
have never see a rig with a serial CAT interface that uses XON/XOFF flow
control, RTS/CTS is ubiquitous on Kenwood rigs with the exception of
some handhelds that
On 15/10/2021 15:43, Black Michael wrote:
Now please test 4.4 without the stopbits and serial_handshake options (let
rigctld use the defaults).
The difference is the commands are now being stacked and it's possible the lack
of hardware flow control is causing this problem.Just let those two
On 15/10/2021 15:02, Black Michael wrote:
I noticed you have serial_handshake=XONXOFF and stopbits=1
Just let those two items default to stopbits=2 and serial_handshake=Hardware
which what I show is the setup for the TS-450.
And you should be able to just check all the Default labels in
On 14/10/2021 20:50, Black Michael wrote:
That should be fixed in the master branch now.
Can you please try that?
Hi Mike,
Thanks for your quick reply.
I rebuilt hamlib package from git master (da34930) and rebuilt a new
wsjtx-2.5 package against it. (Not sure if that was strictly
On 14/10/2021 20:22, Bill Somerville via wsjt-devel wrote:
Hi Barry,
there have been two of your attempted posts rejected because they were
not posted from an email address that is registered on the SourceForge
list server. All the rest of you posts to this thread have arrived at
the list
There seems to be a regression in hamlib-4.3.x which I have been testing
for our dev branch.
I maintain the wsjtx package for Mageia (Linux) and do all my testing
with my Kenwood TS-450S.
We use the system hamlib.
Fake-it works, but any attempt to use RIG for split now fails with the
On 14/10/2021 20:02, Neil Zampella via wsjt-devel wrote:
Where are you sending your 'bug report' ... here, or the Groups.io
list? Two different locations.
Good question.
I was not aware of a groups.io list or would have used it as I have many
accounts on there.
I have only used this
On 14/10/2021 19:55, Neil Zampella via wsjt-devel wrote:
Are you getting the digest version?
That said, I saw this at 1:54 PM Central time on the 14th
Also, your name & callsign is helpful
Neil, KN3ILZ
Thanks Neil,
I will try sending the original bug report again (if I can find it).
The
On 14/10/2021 19:42, Carey Fisher via wsjt-devel wrote:
I read it at 17:42 but it was 5 minutes old then.
Yes it's not the list that is slow it is the bouncing process that is
taking the time.
I don't understand why my other messages are bounced.
I will try again - 4th time including one from
On 14/10/2021 19:33, Barry Jackson via wsjt-devel wrote:
Does this list really take hours to update? sent at:
Thursday, 14 October 2021 19:32
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo
Does this list really take hours to update? sent at:
Thursday, 14 October 2021 19:32
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
On 27/01/2021 20:46, Christoph Berg wrote:
Re: jeff millar
WSJTX starts, starts receiving, responds to Tune every thing is normal.
But on Enable Tx and start of a Tx cycle, it keys, but no transmit tones.
Tune works but Tx does not. the messages look right.
There have been reports that using
On 14/11/2020 04:21, Black Michael via wsjt-devel wrote:
Barry said his reply was rejected so forwarding this to the list for him.
Thanks Michael,
I have figured out how to set up 'folder account' add-on in Thunderbird
to avoid that happening again. Using this as a test!
Cheers,
Barry
G4MKT
On 20/11/2020 02:37, Jim Shorney wrote:
Shift-click anywhere on the waterfall.
Thanks Jim - easy when you know!
73
-Jim
NU0C
73 Barry
G4MKT
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
Hi,
Is there a hot key or something that I have missed to allow click/drag
on the TX frequency slider?
I often find that after initiating a contact I need to move TX while
leaving the RX where it is, and I cannot find an easy way to achieve this.
Barry
G4MKT
On 14/11/2020 19:44, Bill Somerville wrote:
Barry,
have you tried just checking the "Transmit" option?
I have now, and yes that does appear to be doing what I want, both
transmit and tune settings seem to be the same.
I can't understand why, from the way the options are presented, but
On 14/11/2020 18:30, Bill Somerville wrote:
Barry,
the default *is* that the level is the same for all transmissions. Only
if you enable the power level per band options does the level for tune
and normal Tx get saved separately.
I don't see a connection between wanting to save power
Why do TUNE and TX have separate level settings?
I want to use TUNE to adjust the power level for the next transmit
cycles, isn't that what everyone wants?
If there is some obscure use case for separate levels, then may I
suggest a means of making this optional, and the default being that
Hi Bill and all.
For the last several months I have been trying to help a friend sort out
his set-up so he can use wsjtx.
He uses Windows 10 and an FT-991A and the problem, which we initially
thought was down to RF, is now probably not.
He can receive OK but on start of transmit the USB
On 26/09/2019 19:36, Bill Somerville wrote:
On 26/09/2019 16:54, Claude Frantz wrote:
Probably you will have to inform cmake about the location of your
local hamlib. Use the cmake-gui in order to modify your cmake config
so that your local hamlib can be found by cmake.
Hi Claude,
the best
On 15/11/2019 14:31, Barry Jackson wrote:
Trying again...
Forwarded Message
Subject: Re: [wsjt-devel] Confusing build errors 2.1.0
Date: Tue, 12 Nov 2019 21:08:40 +
From: Barry Jackson
Reply-To: zen25...@zen.co.uk
To: WSJT software development
On 26/09/2019 19:36, Bill
Trying again...
Forwarded Message
Subject: Re: [wsjt-devel] Confusing build errors 2.1.0
Date: Tue, 12 Nov 2019 21:08:40 +
From: Barry Jackson
Reply-To: zen25...@zen.co.uk
To: WSJT software development
On 26/09/2019 19:36, Bill Somerville wrote:
On 26/09/2019 16:54
Testing a reply as I don't seem to be getting any messages through to
the list.
This is sent from zen25...@zen.co.uk mail account which as far as I can
tell is the mail account that I am registered to this list.
Barry
G4MKT
___
wsjt-devel mailing
Test
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
On 29/01/2019 11:34, Bill Somerville wrote:
Hi Barry,
you asked for a web page. If you want a more reliable list of releases,
that isn't prone to SourceForge changing the format of that web page,
that is always a problem
you should clone the git repo and use the following two commands to
On 29/01/2019 00:01, G8DQX (WSJT developers on SF) wrote:
Barry,
or this might be what you are after:
https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Versions.cmake. The
Mark I eyeball may also be what you are after, since there is no obvious
(to me, at least) reliably parsable version
On 28/01/2019 23:45, Bill Somerville wrote:
On 28/01/2019 22:40, Barry Jackson wrote:
Hi Barry,
the best I can think of is this:
https://sourceforge.net/projects/wsjt/files/
..
Hi Bill,
That will do nicely, I don't know how I failed to find that page!
[baz@leno ~]$ lynx --dump
https
In order to keep the packages I maintain up-to-date, especially prior to
our distro releases I run a script which parses and extracts the latest
stable version numbers and compares them to our current packages.
To do this I use lynx --dump and parse the page text to extract
the version
On 21/01/2019 01:34, Bill Somerville wrote:
Hi Barry,
we can't automatically account for device names changing due to an o/s
upgrade. If there are more than one i/p and o/p audio device then
changing to another and back to whatever the rig audio devices are in
the WSJT-X settings should
On 20/01/2019 22:02, Bill Somerville wrote:
On 20/01/2019 21:44, Barry Jackson wrote:
both use the same /home/me
Hi Barry,
this may be a problem. The id of the selected audio devices is probably
not the same on the two systems and that information is stored in the
configuration file
Hi Bill,
I finally got around to testing on air this weekend and have a problem.
The package built for Mageia 6 stable release runs fine and was running
WSPR most of Saturday afternoon, with a short spell of FT8.
However, the build for Mageia Cauldron, (our next version approaching
On 18/01/2019 22:41, Bill Somerville wrote:
Hi Barry,
you don't need to generate the sources tarball, we provide it on the
project web site and on SourceForge.
73
Bill
G4WJS.
Hi Bill,
OK thanks for that - makes life a lot easier!
Package updated to use your tarball and builds fine.
Hello,
I just tried to update our (Mageia) package to 2.0.0 using the script I
normally use and something is broken.
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/baz/BLD/BLD_Mga7_07/wsjtx/SOURCES/wsjtx-superbuild/build
Scanning dependencies of target
On 17/06/18 20:03, Saku wrote:
Barry Jackson kirjoitti 17.06.2018 klo 20:23:
Closing wsjtx leaves a running instance and lockfile which has to be
killed manually.
That is because it leaves a "pulse" sub process hanging.
This have been noticed already a month ago with 1.9.1 and
On 17/06/18 13:30, Richard Shaw wrote:
Ok, while good, this is very frustrating...
Went back and build current git, waterfall locked up, no audio out,
process hung on exit...
Went back and changed it from Release to Debug and changed the QT option
for debug output, make clean, make, make
On 15/06/18 19:04, Bill Somerville wrote:
Hi Barry,
I am aware of the issue that patch resolves, unfortunately we have to
support Qt back to v5.5 and it is only later that the Qt provided CMake
files have the necessary definitions for those macros to work. Rather
than start adding Qt
On 15/06/18 01:37, Bill Somerville wrote:
On 14/06/2018 22:25, Bill Somerville wrote:
Hi Barry,
we are moving to git, part of that involved reorganizing the svn repo.
Each project now has a top level directory in the repo with a trunk
and optionally a branches and tags directory alongside.
On 09/06/18 19:23, Bill Somerville wrote:
the WSJT svn repository is back up and running now, sorry for the
extended outage, reorganization is complete.
73
Bill
G4WJS.
Just ran my regular script to create a 1.9.1 tarball which uses
wsjtx-superbuild and it does not find the script:
svn:
On 08/12/17 15:04, David Tiller wrote:
Barry,
I think it's operating as designed. From the manual at
http://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#WSPR
"If you will be transmitting as well as receiving, select a suitable
value for *Tx Pct* (average percentage of
Hi,
I don't understand why the doc directory was moved from
/usr/share/doc/wsjtx/ to /usr/share/doc/WSJT-X/ in 1.8. and why upper case?
In most linux distributions the doc sub-directory is the package name
which is generally lower case, in our case /usr/share/doc/wsjtx/.
Small changes like
On 19/12/16 17:27, Joe Taylor wrote:
> Dear Colleagues,
>
> Thanks to all for your many contributions to the development of WSJT-X,
> Version 1.7. The following notice will be sent soon to the wsjtgroup
> and Moon-Net reflectors.
>
> -- 73, Joe, K1JT
>
>
On 03/03/16 01:13, Bill Somerville wrote:
> On 02/03/2016 20:54, Barry Jackson wrote:
>> On a new clean build of rev6503 I do have the same as above with one
>> exception, I don't have moc_OmniRigTransceiver.cpp but maybe that is
>> from a different build.
>
On 03/03/16 01:13, Bill Somerville wrote:
> On 02/03/2016 20:54, Barry Jackson wrote:
>> On a new clean build of rev6503 I do have the same as above with one
>> exception, I don't have moc_OmniRigTransceiver.cpp but maybe that is
>> from a different build.
>
On 02/03/16 16:13, Michael Black wrote:
> Yeah...you're missing the moc for Configuration and a bunch of others.
> Are you out of disk space perhaps?
> RRR
> Mike W9MDB
>
> moc_about.cpp
> moc_astro.cpp
> moc_BWFFile.cpp
> moc_Configuration.cpp
> moc_Detector.cpp
> moc_Directory.cpp
>
On 02/03/16 16:10, Barry Jackson wrote:
> These are the files:
> moc_Directory.cpp
> moc_DXLabSuiteCommanderTransceiver.cpp
> moc_FrequencyLineEdit.cpp
> moc_FrequencyList.cpp
> moc_HamlibTransceiver.cpp
> moc_LettersSpinBox.cpp
> moc_LiveFrequencyValidator.cpp
These are the files:
moc_Directory.cpp
moc_DXLabSuiteCommanderTransceiver.cpp
moc_FrequencyLineEdit.cpp
moc_FrequencyList.cpp
moc_HamlibTransceiver.cpp
moc_LettersSpinBox.cpp
moc_LiveFrequencyValidator.cpp
moc_MessageClient.cpp
moc_MessageServer.cpp
moc_Modes.cpp
moc_PollingTransceiver.cpp
On 02/03/16 15:49, Michael Black wrote:
> No grep for the function name of that missing signal in the moc for
> Configuration.
>
I just realized and did:
[baz@mageia-pi build]$ for f in moc*; do cat $f |grep "on_font_button" ;
done
[baz@mageia-pi build]$ for f in moc*; do cat $f |grep
On 02/03/16 14:07, Michael Black wrote:
> The nm output at least confirms some version of the function is in the
> executable.
> Your idea sounds like a really good possibility.
The qt4 moc was available in the local build on the Pi2, but it would
not have been in the Mageia BS build as this is
On 02/03/16 13:02, Michael Black wrote:
> nm wsjtx.exe
I guess you were thinking Win ;)
https://paste.kde.org/p6ccgtyto
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM:
On 02/03/16 00:56, Bill Somerville wrote:
> On 02/03/2016 00:26, Barry Jackson wrote:
>> I am attempting to run 1.7 (or 1.6) on a RPi2.
>> There is no problem with the package build either on the Mageia build
>> system (1.6) or locally on the Pi2 (1.7), however attemp
Hi,
I am attempting to run 1.7 (or 1.6) on a RPi2.
There is no problem with the package build either on the Mageia build
system (1.6) or locally on the Pi2 (1.7), however attempting to run
either, the errors are the same:
[baz@mageia-pi ~]$ wsjtx
QMetaObject::connectSlotsByName: No matching
On 01/01/16 15:47, Bill Somerville wrote:
> On 01/01/2016 15:36, Barry Jackson wrote:
>> Not sure if this is related, but I am testing 6330 in WSPR mode and I am
>> seeing triple decodes of strong signals the main one and then two others
>> at approx +/-30Hz about 25dB down
On 17/12/15 01:14, Joe Taylor wrote:
> Barry --
>
> Did you read my WSPRnet message posted here ?
> http://wsprnet.org/drupal/node/5786
>
> If not, please refer to it now.
I hadn't but I have now - let's see what happens, although it's already
been a month since you wrote that :\
>
> We in the
On 10/12/15 14:30, Bill Somerville wrote:
> On 10/12/2015 14:26, Richard Shaw wrote:
>> I'm not sure if it's the root cause but it looks like the configure
>> setup is running twice on hamlib...
> Hi Richard,
>
> yes I'm seeing that too. In fact the whole external project build is
> happening
On 10/12/15 14:43, Bill Somerville wrote:
> On 10/12/2015 14:40, Barry Jackson wrote:
>> Not sure if this is related but I'm seeing this when attempting a test
>> build of rc2:
>>
>> Makefile:541: recipe for target 'rig.lo' failed
>> /home/baz/rpmbuild/BUILD/wsjtx-
On 27/11/15 11:04, Bill Somerville wrote:
> On 27/11/2015 10:44, Barry Jackson wrote:
>> I am a little confused as to why it actually needs to build anything at
>> all, let alone install.
>> Maybe it could have a switch to skip the install?
>>
>> The machine
On 27/11/15 13:14, Richard Shaw wrote:
> Interesting, while I found many references to it using google, I'm not
> familiar with INSTALLD but what I did find I don't think that's what you
> want to use with DESTDIR.
>
> DESTDIR is to basically relocate where a package is installed for
> packaging
On 27/11/15 15:35, Greg Beam wrote:
> Hi Barry, All,
>
> Just a couple things.
>
> I build allot of different applications, not just WSJTX. So to keep
> things straight I use INSTALLD and BUILDD both on Windows and Linux.
> Folks can use whatever name they like or nothing at all if that's a
>
OK, I think that for me this is resolved.
I have followed the consensus and kept to the simple approach that Bill
and Richard use.
I would like to commend this project for the best upstream support that
I have found in any project with which I have been involved. (With the
possible exception
On 27/11/15 02:11, KI7MT wrote:
> Hi Barry,
>
> I wasn't aware you were looking for a script to build the source tarball.
>
> I made up a maintainer script some time back that allows me to build
> either the current RC branch or the Devel branch, both the tarball and
> application build. It's not
Hi Bill,
Thanks for your quick reply.
On 26/11/15 00:56, Bill Somerville wrote:
> On 26/11/2015 00:19, Barry Jackson wrote:
>> Hi,
> Hi Barry,
>> I am in the process of packaging wsjtx for Mageia (Linux) and hit a
>> couple of issues test building the latest svn (r618
Hi,
I have packaged kvasd-installer for Mageia, however
both autogen .sh and Makefile.in both try to send 'clear' to a terminal,
which it cannot do on our build system. This breaks the build.
I have patched both files and the package now builds OK.
Maybe you could include this in the source?
y luck!
>
> I'll add this to the list for the next update, if there is one.
>
> 73's
> Greg, KI7MT
OK thanks.
Cheers,
Barry, G4MKT
>
> On 11/26/2015 07:44, Barry Jackson wrote:
>> Hi,
>> I have packaged kvasd-installer for Mageia, however
>> both autogen .sh and
On 26/11/15 12:47, Bill Somerville wrote:
On 26/11/2015 12:28, Barry Jackson wrote:
...
Regarding Hamlib, I would rather avoid any bundled software that is
available in the distro (it's also policy). I have been testing wsjtx
with our packaged hamlib and not had any problems that I am aware
86 matches
Mail list logo
