Definitely do not want an automatic uninstall
All that needs to be done is put the version # in the default installation path.
Just like FLDigi, FLRig and such do.
Mike W9MDB
On Sunday, June 28, 2020, 07:47:58 PM CDT, Bill Somerville
wrote:
On 29/06/2020 01:35, Stephen VK3SIR
Joe has identified the problem has said it will be fixed next release.
Mike W9MDB
On Sunday, June 28, 2020, 04:52:01 PM CDT, Gary Rogers
wrote:
Bill, is there a way to get a crash report at this point?
Sent from my iPhone
On Jun 28, 2020, at 1:27 PM, Bill Somerville wrote:
.net/lists/listinfo/wsjt-devel
------ Forwarded message --
From: Bruce Bohannon
To: Black Michael via wsjt-devel
Cc:
Bcc:
Date: Sun, 28 Jun 2020 12:08:09 -0400
Subject: Re: [wsjt-devel] FD FT4 crashing
I had several crashes yesterday myself on FT-4. In my case I had to reboot the
lost.
On Sun, Jun 28, 2020 at 9:36 AM Black Michael via wsjt-devel
wrote:
Decided to work some FT4 Field Day operators and about 4 times so far WSJT-X
2.2.2 has crashed.Seems to be when it's in a Tx/Rx cycle but not sure about
that.It's not the WAV file causing it as a replay works just
I can't find that error message in either WSJT-X or Hamlib.
Are you running hamlogger?
https://groups.io/g/hamlogger/topic/invalid_operation/16815153?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,60,16815153
Mike W9MDB
On Sunday, June 28, 2020, 09:30:54 AM CDT, Rik Strobbe
wrote:
Decided to work some FT4 Field Day operators and about 4 times so far WSJT-X
2.2.2 has crashed.Seems to be when it's in a Tx/Rx cycle but not sure about
that.It's not the WAV file causing it as a replay works just fine.
I had a friend reporting the same problem.
Mike
Also...what rig are you seeing thsi error on?
Mike W9MDB
On Sunday, June 28, 2020, 08:49:26 AM CDT, Rik Strobbe
wrote:
I tried to run 2 instances of WSJT-X, as described in
https://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.2.html
(FAQ, point 2).
Both instances
Or maybe need to do a Frequency Reset on the instance that is failing?
File/Settings/Frequencies -- right-click in the Working Frequencies list and
choose "Reset".
Mike W9MDB
On Sunday, June 28, 2020, 08:58:46 AM CDT, Bill Somerville
wrote:
On 28/06/2020 14:43, Rik Strobbe wrote:
I assume you mean the 785x works fine in Rig Split?
Mike W9MDB
On Sunday, June 14, 2020, 03:31:54 AM CDT, Roeland Jansen
wrote:
Not sure if the 785x works the same but if so... all is online here Mike.
On Sun, Jun 14, 2020 at 5:36 AM Black Michael via wsjt-devel
wrote:
Hi Jon
Hi Jon,Would you be willing to let me connect up to your computer and do some
debugging?I think we may already have this fixed but would like to confirm for
the 7610.
Mike W9MDB
On Saturday, June 13, 2020, 10:24:55 PM CDT, Jon Anhold
wrote:
Working the VHF contest with the IC-7610
Can we change the rig selection where it varies between Serial/Network to just
be a single "Device" ?
Then use the same tooltip for Network but add com port info too.
All devices are now capable of supporting network-based serial devices so the
"old" way is obsolete. Some are network-only but
G4WJS.
On 11/06/2020 13:05, Black Michael via wsjt-devel wrote:
Reading the documentation it's implied and refers to a "control channel".
The thing just does a passthru so I don't know how it could possibly share the
rig with CAT control. That's likely why he got a bus collision
w to share the radioport with other functions, use the control lines
(RTS, CTS, DTR, DSR) for handshaking, or apply afixed level.
Mike
On Thursday, June 11, 2020, 06:43:56 AM CDT, Bill Somerville
wrote:
On 11/06/2020 12:36, Black Michael via wsjt-devel wrote:
> You can't have two progr
You can't have two programs doing CAT control to the MKII at the same time.
If you're interested I can post a video of how to configure N1MM and WSJT-X to
work together. But it requires three more programs. #1 FLRig#2 rigctlcom
(comes with WSJT-X)#3 Virtual serial port software like com0com or
It sounds like you're trying to do port sharing. I'm don't believe the
microham supports that. I believe it does support PTT on one com port and CAT
on another. And it can also echo CAT responses to another COM port for
monitoring...but not CAT control.
So if you turn off N1MM and connect
ntrol.
73 de AI8W, Chris
On Wed, Jun 10, 2020, 00:06 Black Michael via wsjt-devel
wrote:
I was able to test with a friend that has an IC-7300 and we could duplicate
this problem -- but it's not easily reproducible.
Has nothing to do with WSJT-X or hamlib. Appears to be some sort of bug in th
I was able to test with a friend that has an IC-7300 and we could duplicate
this problem -- but it's not easily reproducible.
Has nothing to do with WSJT-X or hamlib. Appears to be some sort of bug in the
IC-7300 where changing bands and quickly transmitting is causing some sort of
burp that
on or just don't do it and leave it to the application to
decide if this is appropriate?
73
Bill
G4WJS.
On 08/06/2020 22:31, Black Michael via wsjt-devel wrote:
Do you have "Monitor returns to last used frequency" turned on?
That will cause the rig to wake up as it has
Do you have "Monitor returns to last used frequency" turned on?
That will cause the rig to wake up as it has to get the frequency.
Mike W9MDB
On Monday, June 8, 2020, 03:30:13 PM CDT, Al Pawlowski
wrote:
Personally, I do not need/want WSJTx to turn my radio on, or off, when
I'm the hamlib primary developer right now and not inclined to turn off the rig
when closing the client. Not many people want that feature.
If you want to turn it off it's not hard to do.
Create a batch file and put this in it -- adjust paths and such to suit -- then
create a shortcut to the
The short term fix is to use the FT857 -- it's compatible.
This has been fixed for the FT897 and will be in the next release.
Mike W9MDB
On Sunday, June 7, 2020, 04:32:56 PM CDT, Adam Gilmore
wrote:
Hi
On behalf of 2E0SMX, he has just upgraded to 2.2.1 and his CAT connection
OK...it's implemented in hamlib now...you should see it in the next
release.Mike W9MDB
On Sunday, June 7, 2020, 08:20:57 AM CDT, Chuck Reti WV8A via wsjt-devel
wrote:
Mike/Bill,
I tested “Rig" split with the FT-897D using the FT-857 setting. It works.
“Split” mode is indicated on
Since you're already batching the reports in 5 minute intervals I wouldn't keep
the connection open.Just make it, report, and close it. And if it gets an
error just drop 'em and maybe stuff a message in the decode window (rather than
a dialog box) that says "PSK Reporter error" maybe with the
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
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
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
Helps if I give the
linkhttps://www.dropbox.com/s/wno7tgxt11oiq4f/ice_video_20200604-222426.webm?dl=0
On Thursday, June 4, 2020, 10:34:03 PM CDT, Black Michael via wsjt-devel
wrote:
Simple enough...get a few decode cycles without CQ Alert enabled.Then turn on
CQ Alert.On the next
:17, Bill Somerville wrote:
On 04/06/2020 23:48, Black Michael via wsjt-devel wrote:
I can reproduce this on my machine. No excessive load. I just turned on the
CQ Alert and next cycle it highlighted all the calls that matched in the
history of the call.
Hi Mike,
what does
I can reproduce this on my machine. No excessive load. I just turned on the
CQ Alert and next cycle it highlighted all the calls that matched in the
history of the call.
I'd call mine a fast machine with about a 30% load.
Mike
On Thursday, June 4, 2020, 05:14:27 PM CDT, Bill Somerville
This has been fixed and will be in the next release.
Mike W9MDB
On Thursday, June 4, 2020, 04:30:35 PM CDT, Bensay 1
wrote:
Dear WSJT-X Devel team,
Many thanks for your patience and the help;
I’ve just discovered a bug with the most recent WSJT-X version 2.2.0 released
Really? Doesn't seem like the copyright notice says that.I thought WSJT-X was
GPL?
Mike W9MDB
On Thursday, June 4, 2020, 07:44:42 AM CDT, Bill Somerville
wrote:
On 04/06/2020 06:11, Stephen VK3SIR wrote:
Hi Folks,
The FT-991 now works with WSJTX 2.2.0 with Mike
Version date has been added to all the utilities in the latest commits.
Mike W9MDB
On Wednesday, June 3, 2020, 12:55:36 PM CDT, Saku wrote:
Bill Somerville kirjoitti 3.6.2020 klo 14.38:
>
> Please repeat the tests that failed using `rigctld-wsjtx` and report
> if they still fail
in this case I think just using an
'f' command with rigctl will suffice.
73
Bill
G4WJS.
On 03/06/2020 13:22, Black Michael via wsjt-devel wrote:
I've got a patched version that I sent to one of the testers
On Wednesday, June 3, 2020, 06:26:20 AM CDT, Bill
05:20, Black Michael via wsjt-devel wrote:
The FT-991 is one that doesn't have the ability to query which VFO is active
and doesn't have the ability to query "current VFO" either.
Since we allow currVFO to pass through to the Icoms it's also now passing
through to all rig
to
sort out similar issues with some Icom rigs. Nothing relevant has changed in
the Hamlib interface code in WSJT-X since v2.2.0 RC3, yet these rigs (FT-891 &
FT-991) were OK then and not now.
73
Bill
G4WJS.
On 03/06/2020 04:28, Black Michael via wsjt-devel wrote:
Don't know
rned?
73
Bill
G4WJS.
On 02/06/2020 23:21, Black Michael via wsjt-devel wrote:
So WSJT_X is asking "v" when the rig has no get_vfo function.
I could modify rig.c to return RIG_OK from rig_get_vfo if RIG_VFO_CURR is
asked for.
Bill?
Mike W9MDB
On Tu
I need one of the Yaesu owners to follow the directions in this youtube video
and send me their debug.txt file.
https://www.youtube.com/watch?v=0yZG1-v-BXA
Mike W9MDB___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
Brett -- please contact me off list and we can debug this. mdblac...@yahoo.com
Mike W9MDB
On Tuesday, June 2, 2020, 11:28:42 AM CDT, brett williams
wrote:
I have noticed that the new GA release does not work with my Yaesu FT-891.
Hamlib reports “invalid parameter while getting
Adrian -- can you please check the operating modes in this bug report?
Somebody was reporting different behavior for MONO between using the 101 rig or
the 5000 and bad behavior on the 101.
https://github.com/Hamlib/Hamlib/issues/260
Mike
On Tuesday, June 2, 2020, 10:02:14 AM CDT, Adrian
I need somebody willing to help with debugging the FT-DX101D
I've got some complaints it's not working but nobody that's willing to help
debug it.
Any volunteers?
Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
You apparently don't have the latest code.
This was fixed a couple days ago.
Mike W9MDB
On Monday, June 1, 2020, 01:27:18 AM CDT, Iztok Saje
wrote:
Hello!
Old slackware linux. Libraries needed for WSJTX had not been touched for some
two or three years.
When compiling hamlib, it
We know...working on it.
Mike W9MDB
On Friday, May 29, 2020, 11:17:43 PM CDT, Saku wrote:
Saku kirjoitti 30.5.2020 klo 6.06:
Hi!
Just jumped from rc1(snap) to rc3. (self compiled source from K1JT homepage)
Sad to see that the same hamlib error still exist there in rc3
What do you get from these commands?
ldd rigctld-wsjtx | grep hamlibldd wsjtx | grep hamlib
Mike W9MDB
On Friday, May 29, 2020, 10:43:10 AM CDT, Kari wrote:
Hello,
I'm still getting "Feature not available while getting current VFO" error
on my Ubuntu 18.04.4 LTS systmem(s) when
It has to do with Windows shutting off sounds. They assume that if you put
your monitor to sleep surely you want all of your sound devices to sleep
too.That's why I use the power button on the monitor and have no problems that
way.
Microsoft has no concept of audio other than speakers and
RTS or DTR on a serial port, not also used for CAT, was
messed up.
73
Bill
G4WJS.
On 26/05/2020 22:05, Black Michael via wsjt-devel wrote:
Do you have CAT control turned on?
We're still trying to figure out what's causing this.
Mike W9MDB
On Tuesday, May 26, 2020
Do you have CAT control turned on?
We're still trying to figure out what's causing this.
Mike W9MDB
On Tuesday, May 26, 2020, 03:33:25 AM CDT, David M. Boyter
wrote:
Morning
I get the same as I use 232 for PTT. Happened about every 2nd transmissionAnd
"tune" button same problem
73
Are you running in split mode?
If so, try using Fake It.
Mike W9MDB
On Tuesday, May 26, 2020, 09:13:34 AM CDT, William D'Agostino via
wsjt-devel wrote:
Hi All,
This might be a "bug" with both WSJT-X 2.2.0-rc2 and WSJT-X 2.1.2.
I’m using a Kenwood TS-690S with a Dell Latitude
Mike,
I was able to fix the issue by installing an earlier version of the Mac OS
SILAB driver. Is the issue really within HAMLIB and the earlier driver just
gets around the issue?
73,
Bill - AK6A
On Sun, May 24, 2020 at 7:59 AM Black Michael via wsjt-devel
wrote:
I've identified some
I've identified some problems with the 101D that I'll be fixing.
Mike W9MDB
On Sunday, May 24, 2020, 12:55:37 AM CDT, Ken Chandler via wsjt-devel
wrote:
I had issues to but on window 10 platform.I used the FT5000 rig, everything
burst into life when I switched over from FTdx101D
Guess I was recalling the wrong reason for the RR73 then
What is the history?
On Thursday, May 21, 2020, 08:55:50 AM CDT, Bill Somerville
wrote:
On 21/05/2020 14:33, Black Michael via wsjt-devel wrote:
> The whole intent of RR73 was for meteor scatter QSOs which can t
RR73 requires no response...if the receiving party doesn't get the RR73 they
automatically retransmit TX3...
The RR73 is stating "I expect no further replies from you". There is no 73
required at allit is a courtesy done on HF bands.
The whole intent of RR73 was for meteor scatter QSOs
Yeah, I know, but a good number do it anyways...
Mike
On Tuesday, May 19, 2020, 11:09:47 AM CDT, Neil Zampella
wrote:
FWIW .. someone sending an RR73 does not expect a reply, the last 73 is a
courtesy from you the answering station. If someone keeps sending RR73, they
don't
What he's describing has happened to me numerous times...
You send 73 and move on to another QSO...then the last QSO sends RR73 again so
you have to double-click it.
Seems to me double-clicking an RR73 that has your callsign in it should
automatically go to Tx 5 instead of TX3.
de Mike W9MDB
If anything it would be to cd to their desktop. Many users don't even know how
to use a file browser.
Mike
On Monday, May 18, 2020, 08:58:36 AM CDT, Bill Somerville
wrote:
On 18/05/2020 14:28, Black Michael via wsjt-devel wrote:
I created a youtube video demonstrating how
Frank, can you please try the daily
snapshothttp://n0nb.users.sourceforge.net/hamlib-w32-4.0~git-71bd84d5-20200518.exe
Shut down WSJT-X, extract this into a separate directory and open a cmd prompt,
cd to the directory, and run this
rigctld -m 28001 -r COM1 -s 9600 -Z -v >log.txt 2>&1
Then
Just a thoughtperhaps we could open up the wsjt-x source code repository
now that we are in release candidate mode?And then leave it open for bug
patches too after the final releasemaybe a forked copy or such.
It would open up testing to hopefully fix any other bugs noticed before rc2.
There is a bug in DTR/RTS PTT in RC1 that will be fixed in the next release.
de Mike W9MDB
On Friday, May 15, 2020, 08:46:46 PM CDT, lgtngstk
wrote:
Just to report, I am also having this issue as well.
On Wed, May 13, 2020 at 7:04 AM Bill Somerville wrote:
On 13/05/2020 00:37,
Save your WAV files and submit some examples.
de Mike W9MDB
On Friday, May 15, 2020, 10:10:38 PM CDT, Allan VK4QG
wrote:
Hi All,
While monitoring 6m, which for 99% of the time is very quiet here, (from
a QRM and amateur activity perspective) I am getting a vast increase in
the
You can use any version of hamlib as long you build WSJT-X too.
de Mike W9MDB
On Friday, May 15, 2020, 04:57:44 AM CDT, Claude Frantz
wrote:
On 5/10/20 11:58 AM, Bill Somerville wrote:
>> Which releases of hamlib can be used to compile ?
> although it is still recommended to use
If you're running an older rigctld backwards compatibility was broken and has
been fixed.
For now you should be able to use rigctld-wsjtx in WSJT-X which should always
work together.
de Mike W9MDB
On Wednesday, May 13, 2020, 11:59:32 PM CDT, Saku wrote:
Saku kirjoitti 14.5.2020
There is a bug in setting the frequency with rigctld which has been fixed and
should be in the next release.
Either today's hamlib snapshot or tomorrow's will also have the fix. I'm not
sure if the patch made it in to today's snapshot.
http://n0nb.users.sourceforge.net/
de Mike W9MDB
crazy that connecting an sdr to other software is
more tricky than a conventional radio. As some people connect tens of
simultaneous instances of digimode sw to spark it is particularly desirable to
keep it simple. 73 Alan M0NNB
On Wed, May 13, 2020 at 4:44 PM Black Michael via wsjt-devel
wr
sw to spark it is particularly desirable to
keep it simple. 73 Alan M0NNB
On Wed, May 13, 2020 at 4:44 PM Black Michael via wsjt-devel
wrote:
I'm going to see about fixing the backwards compatibility. Hopefully
today...
Mike
On Wednesday, May 13, 2020, 09:27:
I'm going to see about fixing the backwards compatibility. Hopefully today...
Mike
On Wednesday, May 13, 2020, 09:27:48 AM CDT, Alan Hopper
wrote:
Hi Bill and Michaelthanks very much for your reply. I added the response to
'q' but as expected no magic fix. The error message from
Are you able to compile hamlib?
de Mike W9MDB
On Wednesday, May 13, 2020, 07:48:25 AM CDT, David Tiller
wrote:
Thanks for the info, Bill and Mike!
I added the cache param and tried it with and without the -m parameter - with
the -m 3027 it failed, without it the command 'worked',
The internal protocol has never been published.The method to integrate is to
use the hamlib client interface.As it is your emulation doesn't do the
dump_state correctly for example.
Since SparkSDR is emulating a rig it's much more logical to write a backend for
SparkSDR or have SparkSDR emulate
You don't say what OS you use but there is JTAlert for Windows.And GridTracker
and AlarmJT for Linux.
http://hamapps.com/
https://sourceforge.net/projects/alarmejt/
https://www.m0spn.co.uk/2020/02/01/gridtracker-a-jtalert-for-linux/
de Mike W9MDB
On Tuesday, May 12, 2020, 05:07:26 PM
A couple of minor warnings from simple cppcheck of 2.2.1 -- neither of which
should be problematic since they are error conditions.There are, of course, a
lot more warnings with cppcheck --enable=all -- some of which look important.
de Mike W9MDB
getfile.cpp -- resource leak on fp not being
Unless something changed failing to uninstall the old version leaves programs
hanging around in the Windows uninstall arena that can't be uninstalled.
I also noticed that Communications is mispelled Communicaitions.
de Mike W9MDB
On Monday, May 11, 2020, 09:48:02 AM CDT, Joe Taylor
Link is at the bottom of the email
de Mike W9MDB
On Tuesday, May 5, 2020, 03:33:37 PM CDT, Rick wrote:
On Tue, May 5, 2020 at 10:24 AM Joe Taylor wrote:
Hi all,
This message is to let you know of some important WSJT-X development
plans. We plan to make a first candidate
, there are no timeouts,
it just waits for the function to finish. What is this timeout you are
referring to?
73
Bill
G4WJS.
On 24/04/2020 16:40, Black Michael via wsjt-devel wrote:
I've had several reports from the JTDX groupas I said due to the new
power level calls it is making. And now
of Hamlib timeouts I have seen are where the connection is
not set up right, e.g. the wrong COM port, baud rate, or handshaking. Can you
point me to a report of a Hamlib timeout that is not caused by similar
misconfiguration?
73
Bill
G4WJS.
On 24/04/2020 15:29, Black Michael via wsjt-d
some
tests when I get some time and work out if WSJT-X is really calling rig_open
twice on the same RIG handle without an intervening rig_close. I'll get back to
you.
73
Bill
G4WJS.
On 24/04/2020 15:03, Black Michael via wsjt-devel wrote:
I have no idea why it's treated differently
020, 08:49:41 AM CDT, Bill Somerville
wrote:
On 24/04/2020 14:39, Black Michael via wsjt-devel wrote:
rig_close being synchronous won't (shouldn't) matter. The problem is that
hamlib recovers from the timeout but when it's done WSJT-X has already timed
out and shuts down rigctld. A
le
wrote:
Hi Mike,
I really dislike arbitrary timeouts, they make software seem unresponsive.
Why is rig_close() not synchronous?
73
Bill
G4WJS.
On 24/04/2020 14:04, Black Michael via wsjt-devel wrote:
Direct control has the same problem. And you don't need a network
then there is a more serious issue there.
73
Bill
G4WJS.
On 24/04/2020 04:21, Black Michael via wsjt-devel wrote:
Via the rigctld interface would be the "q" command getting sent by WSJT-X
via rig_close()...but the rigctld thread would be locked by the mutex while
it's still waiting fo
y. rig_close() will have been called before rig_open() is called
again on the same RIG handle.
73
Bill
G4WJS.
On 23/04/2020 22:20, Black Michael via wsjt-devel wrote:
Actually I just repeated it. Has to do with the timeout.using
rigctldor any network-based rig. So if the ri
to duplicate this by turning off your rig, wait for the
timeout, and turn it back on, then click Retry.
de Mike W9MDB
On Thursday, April 23, 2020, 04:10:51 PM CDT, Black Michael via wsjt-devel
wrote:
Don't have any more details than the error message of invalid configuration.
I've
());
error_check (rig_open (rig_.data ()), tr ("opening connection to rig"));
Mike
On Thursday, April 23, 2020, 02:40:48 PM CDT, Bill Somerville
wrote:
On 23/04/2020 20:15, Black Michael via wsjt-devel wrote:
> And sometimes doing retry will give a configuration erro
via wsjt-devel wrote:
Yes
On Thursday, April 23, 2020, 12:19:11 PM CDT, Bill Somerville
wrote:
Hi Mike,
Does this cause WSJT-X to offer a Retry/Reconfigure/Cancel message box?
73
Bill
G4WJS.
On 23/04/2020 18:00, Black Michael via wsjt-devel wrote
On another note...do you think we could add always writing the debug file and
put in a debug level pulldown?That way we can get complete debug when somebody
has a problem and not have to resort to running rigctld.I could probably have
found this problem sooner if WSJT-X showed it was shutting
Yes
On Thursday, April 23, 2020, 12:19:11 PM CDT, Bill Somerville
wrote:
Hi Mike,
Does this cause WSJT-X to offer a Retry/Reconfigure/Cancel message box?
73
Bill
G4WJS.
On 23/04/2020 18:00, Black Michael via wsjt-devel wrote:
The Flex takes almost 3 seconds
n Thursday, April 23, 2020, 11:49:27 AM CDT, Bill Somerville
wrote:
On 23/04/2020 17:34, Black Michael via wsjt-devel wrote:
Found a problem with Flex which is fixed by changing the rig polling rate to 3
seconds and adding some changes to hamlib. Doing a profile change on Flex can
tak
Found a problem with Flex which is fixed by changing the rig polling rate to 3
seconds and adding some changes to hamlib.Doing a profile change on Flex can
take almost 3 seconds.So if you have polling at 1 second WSJT-X times out
waiting for the profile change and actually requests hamlib to
If you follow the link at the bottom of the email you should get to here...
https://sourceforge.net/projects/wsjt/lists/wsjt-devel/unsubscribe
de Mike W9MDB
On Saturday, April 11, 2020, 10:25:27 AM CDT, Barry Bowman
<77bow...@charter.net> wrote:
Hello
I somehow got on the email list
Make sure you update to the latest swig
de Mike W9MDB
On Saturday, April 4, 2020, 04:23:22 PM CDT, Richard Shaw
wrote:
Just to let everyone know, I've build hamlib 4.0 prerelease for Fedora 30, 31,
32, 33 (Rawhide) and also rebuilt all 11 dependencies for each branch (whew!).
The
Comment out the std::hash function in qt_helpers.cppHopefully it's identical
de Mike W9MDB
On Saturday, April 4, 2020, 08:05:55 AM CDT, Stephen Ireland
wrote:
I found the issue that provided the pre-processor/cmake abend: Cmake was set
to 3.5.2 when it must be set to 3.10.3 (or
"Option to prevent
sound device from ever becoming the default". and upvote it.
The we can just check a box and stop this insanity.
de Mike W9MDB
On Friday, April 3, 2020, 04:50:34 PM CDT, Paul Kube
wrote:
On Fri, Apr 3, 2020 at 1:42 PM Black Michael via wsjt-devel
w
You should not be selecting "default" for WSJT-X. Select your rig sound card
instead and that problem will go away.
And..your rig sound device should not be the default...when it is all your
computer boops and beeps will go out your rig.
de Mike W9MDB
On Friday, April 3, 2020,
4.0 breaks the ABIergo the major version bump.
I see that Fedora does not mandate shared library usage
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_shared_libraries
Applications linking against libraries SHOULD link against shared libraries not
static versions.
So yes...it's
nd a bunch more
through the use of static analysis tools.
de Mike W9MDB
On Thursday, March 26, 2020, 08:45:04 AM CDT, Christoph Berg
wrote:
Re: Black Michael via wsjt-devel 2020-03-26
<423480794.1565067.1585229983...@mail.yahoo.com>
> The hamlib release you need is in the
The hamlib release you need is in the WSJT-X tarball.Read the directions on
building it.Since you maintain the Fedora distribution you should be building
it correctly and not use your system hamlib.
And you are linking the static libraries when you build WSJT-X unless you
changed the default
What was packaged with WSJT-2.1.2 is more recent than the Hamlib 3.3 version
you are using.
You should be using the hamlib version packaged in the WSJT-X tarball and that
message will go away.
We should have a release candidate for 4.0 soon.
de Mike W9MDB
On Thursday, March 26, 2020,
What version of WSJT-X are you running?
I don't see that message in V2.1.2 or in the hamlib code for v2.1.2
de Mike W9MDB
On Wednesday, March 25, 2020, 07:33:01 PM CDT, Richard Shaw
wrote:
I switched from hamlib to flrig some time ago and just happened to check my
journal on my
Yes...you have to rebuild both then.
Mike
On Tuesday, March 17, 2020, 02:04:05 AM CDT, Claude Frantz
wrote:
On 3/16/20 5:45 PM, Black Michael via wsjt-devel wrote:
Hi Mike,
> If you're using a device other than "Hamlib NET rigctl" in
> WSJT-X...yes.You do
If you're using a device other than "Hamlib NET rigctl" in WSJT-X...yes.You
do need to rebuild hamlib first of course
de Mike W9MDB
On Monday, March 16, 2020, 11:37:36 AM CDT, Claude Frantz
wrote:
On 3/16/20 5:23 PM, Black Michael via wsjt-devel wrote:
> Try agai
t me off-list please as this is not a WSJT-X problem.
de Mike W9MDB
On Monday, March 16, 2020, 11:13:58 AM CDT, Claude Frantz
wrote:
On 3/16/20 3:32 PM, Claude Frantz wrote:
> On 3/16/20 2:52 PM, Black Michael via wsjt-devel wrote:
>
>> Try again...I fixed it.
>> de Mi
Done.
On Monday, March 16, 2020, 09:01:18 AM CDT, Bill Somerville
wrote:
Hi Mike,
I believe Claude is using the SF git repo do you probably need to push there
as well.
73
Bill
G4WJS.
On 16/03/2020 13:52, Black Michael via wsjt-devel wrote:
Try again...I fixed
Try again...I fixed it.
de Mike W9MDB
On Monday, March 16, 2020, 02:40:01 AM CDT, Claude Frantz
wrote:
On 3/15/20 8:57 PM, Black Michael via wsjt-devel wrote:
> Try checking out hamlib in a new directory.
> I'm seeing that the build-aux directory isn't being cleaned.
>
I thought you were running rigcltd with your TS-2000...this log is for the
dummy rigI meant to "add -Z -v" to your existing rigctld line.
Mike
On Sunday, March 15, 2020, 12:00:34 PM CDT, Claude Frantz
wrote:
On 3/15/20 5:17 PM, Black Michael via wsjt-devel wrote
501 - 600 of 1443 matches
Mail list logo
