Can you please try the latest hamlib and see if it's fixed now?
Mike W9MDB
On Tuesday, September 28, 2021, 04:51:21 PM CDT, Marco Calistri
wrote:
Il 28/09/21 18:08, Black Michael ha scritto:
> #1 Does the rig behave when NOT running cqrlog?
> #2 Please run rigctld like this,
#1 Does the rig behave when NOT running cqrlog?#2 Please run rigctld like this,
duplicate the problem, and send me the log.txt filerigctld -m 1021 --vfo -v
-Z >log.txt 2>&1
Mike W9MDB
On Tuesday, September 28, 2021, 03:17:37 PM CDT, Marco Calistri via
wsjt-devel wrote:
That has been fixed in hamlib 4.3.1 and the 4.4 version too.
So it will be in the release of WSJTX.
Compile hamlib from herehttps://github.com/Hamlib/Hamlib/releases/tag/4.3.1
Mike W9MDB
On Sunday, September 19, 2021, 02:05:39 PM CDT, Alex Lelievre via
wsjt-devel wrote:
Hi there,
:27 AM CDT, Kari Sillanmäki via
wsjt-devel wrote:
Hi Mike,
On 8.9.2021 7.56, Black Michael via wsjt-devel wrote:
Clone the current master and try again...I made some changes
git clone https://github.com/Hamlib/Hamlib.git
Mike W9MDB
This compiled, bu
Clone the current master and try again...I made some changes
git clone https://github.com/Hamlib/Hamlib.git
Mike W9MDB
On Tuesday, September 7, 2021, 05:40:45 AM CDT, Kari Sillanmäki via
wsjt-devel wrote:
Hi,
I tried to compile WSJT-X 2.5.0-rc6 on XUbuntu 18.04.5 LTS but got an
You may find it compiles and works on OpenSuSe in earlier versions and should
work now.
1.0.23 fixed build problems on Windows and also allows wrapped devices which
may be implemented in some backends soon.
I'll change the wording to "may be required". It is just a warning though and
not an
? This after all is what the configure phase is all about.
73
Bill
G4WJS.
On 07/09/2021 13:05, Black Michael via wsjt-devel wrote:
USB is one of those technologies that doesn't stand still. Can't help it if
package maintainers are 1.5 years behind the curve.
I simply can't
USB is one of those technologies that doesn't stand still. Can't help it if
package maintainers are 1.5 years behind the curve.
I simply can't guarantee future compatibility but will try to maintain it.
That's why I put in the testlibusb.c program to catch this type of thing before
it's
Option #1 Preferably upgrade your libusb https://github.com/libusb/libusb.
Remove your libusb package and compile libusb yourself. Otherwise I can't
guarantee you'll be compatible with USB devices going forward.Option #2 Edit
testlibusb.c and add this #if block around that line -- again
Sounds like a baud rate mismatch.
Mike W9MDB
On Saturday, September 4, 2021, 10:54:59 AM CDT, Eddy Winrow via wsjt-devel
wrote:
Hello,I,m hoping you will be able help me.
Equipment: FT897D microham USBIII, LDG AT897 Plus
Problem: I have a Red Freqeuncy box and the OOB box is Red and
setting poll rate 1s, 2s or 5s. Always fails after a
while. I would say that shorter poll rate seems to raise problems faster.
I think I clean up everything and recompile all again.
--
Saku
OH1KH
Saku via wsjt-devel kirjoitti 30.8.2021 klo 17.27:
Black Michael via wsjt-devel kirjoitti 27.8.2021
50Hz channels won't work due to skirts on the 50hz spread, rig frequency
inaccuracies and sound card non-linearity effects (e.g. 2000Hz is not the same
real freq offset as 200Hz). 60 Hz would be a better channel width or 55Hz
might work.
Then you have operators whose bandwidth is limited but
Those cache times are showing 10134ms = 10 seconds since the last time ptt was
polled. For FT4 that's not good.
What is your polling rate in WSJT-X?
Mike W9MDB
On Friday, August 27, 2021, 10:12:57 AM CDT, Saku via wsjt-devel
wrote:
Thanks Bill!
Pulled last Hamlib from GItHub,
hash code may be received having never
received the first message with the matching call. It makes sense to clear the
hash table file occasionally to avoid this happening too often.
73
Bill
G4WJS.
On 14/08/2021 13:40, Black Michael via wsjt-devel wrote:
Doesn't WSPR also use the CRC i
Doesn't WSPR also use the CRC in messages? So it would be a combination of
collision + valid CRC.The 50/50 point for 32768 values is 214.Why does WSPR
remember the hash value?
We do see bogus matches in FT8 modes and such -- not real often but every once
in while a callsign hash will match a
That's because you only entered your grid in WSJTX as FN20.
Go to Settings/General and enter your 6-digit grid.
Mike W9MDB
On Monday, August 9, 2021, 08:00:03 AM CDT, Andrew Neumeier via wsjt-devel
wrote:
Not sure if anything like this has been reported. Today I used WSJTx,
, Black Michael via wsjt-devel wrote:
The split problem should be fixed. Uninstall the hamlib you have now and
clone the master repo -- you'll have to compile it. Hamlib-4.3 should be
released this month.
git clone https://github.com/Hamlib/Hamlib.git cd Hamlib ./bootstrap
./configure
WSJT-X most certainly does poll the rig. Though only every 5 seconds since you
set it that way.Of course it won't poll if it gets an error.
Perhaps you need to reset your frequencies in File/Settings/Frequencies --
right-click in the list and "Reset".
And dialing down to get "free tx space"
The split problem should be fixed.Uninstall the hamlib you have now and clone
the master repo -- you'll have to compile it.Hamlib-4.3 should be released this
month.
git clone https://github.com/Hamlib/Hamlib.gitcd Hamlib./bootstrap./configure
--prefix=/usrmake install
Mike W9MDB
On
Presumably you are not running Rig Split?
Mike W9MDB
On Sunday, August 1, 2021, 03:50:37 PM CDT, Rory Bowers via wsjt-devel
wrote:
No problems here... rc-4 came up and so far is running fine on my
IC-7610.Rory, K5CKS___
wsjt-devel mailing
I see the problem...will be fixed in the next release.
In the meanwhile you should be able to use Fake It.
Mike W9MDB
On Sunday, August 1, 2021, 10:57:43 AM CDT, Jon Anhold via wsjt-devel
wrote:
I have reverted to 2.50-rc3. With rc4, every time I tried to key my 7610,
without the
It's really a hamlib questionFYI...you don't need
--set-conf=serial_handshake=NoneThat's the default for the rig but it won't
help this problem.
You may want to use the new way as the old rc.local is old hat
Convert to the new method and see how it behaves.
Check your menu for this option
CAT control shows being able to change the rig config to select RTS or DTR for
DATA SEND too.
Mike W9MDB
On Monday, July 19, 2021, 05:25:13 PM CDT, Conrad PA5Y via wsjt-devel
wrote:
So why does the WSJT-x software work exactly as I want using
Could you please try the master repo to see if has already been fixed?
https://github.com/Hamlib/Hamlib
Mike W9MDB
On Sunday, July 18, 2021, 12:10:29 PM CDT, alawler mudhawk.com via
wsjt-devel wrote:
HI Folks,
I've encountered what seems to be a bug in how wsjtx uses the network
Those messages are harmless...but thanks for reporting.
I'll clean them up.
Mike W9MDB
On Tuesday, July 13, 2021, 01:15:52 PM CDT, Al Flapan
wrote:
This is what I see in the syslog when I start the program. I do not have
any issue with the program talking to my ICOM IC 7100 so I
connections it
would be nice if it kept reconnecting.73 Alan M0NNB
On Mon, Jul 12, 2021 at 4:45 PM Black Michael via wsjt-devel
wrote:
It should be trying to reconnect twice with 3 second timeout each time.
What rig are you using? You could increase the timeout value by adding a
switch to rigctld
It should be trying to reconnect twice with 3 second timeout each time.
What rig are you using? You could increase the timeout value by adding a
switch to rigctld
rigctld --set-conf=timeout=1
You could also try increasing the retry in rigctld.c from 3 to maybe 4 or 5 and
see if that makes
Somebody noted that EA3A came up with grid JN12.
The logic in void MainWindow::lookup() doesn't look for any exact match.
It finds the first call that matches EA3A which is this oneEA3ACD,JN12,,,
This lineif(t.indexOf(hisCall)==0) {
Should beif(t.indexOf(hisCall+",")==0) {
Mike W9MDB
That was fixed Jun 28.
Can you upgrade to the latest?
Mike W9MDB
On Tuesday, June 29, 2021, 02:12:22 PM CDT, Kari Sillanmäki
wrote:
Hi Mike,
On 29.6.2021 21.24, Black Michael via wsjt-devel wrote:
What does this show?
rigctld-wsjtx --version rigctl Hamlib 4.3~git
What does this show?
rigctld-wsjtx --version
On Tuesday, June 29, 2021, 01:19:16 PM CDT, Kari Sillanmäki
wrote:
Hi Dev Team,
Just noticed that the issue with rigctld-wsjtx reported by Saku, oh1kh,
in message https://sourceforge.net/p/wsjt/mailman/message/37298053/
still persists
of hamlib changes affecting certain rigs. Is this correct? Do you
understand just what changes caused the problem, and do you have a fix
in preparation? Let me know...
-- Joe, K1JT
On 6/15/2021 6:08 PM, Black Michael via wsjt-devel wrote:
> What rig?
>
> Mike W9MDB
>
> On Tues
Seems like this should be fixable if the devices were enumerated just before
opening the rig.
Or put a "Refresh" button on the error dialog but the auto-enumeration would be
better for any auto recovery.
Mike W9MDB
On Tuesday, June 22, 2021, 05:47:09 AM CDT,
wrote:
Could the
This is something new with the latest gcc...
Clone the latest from here and it should compile OK.
https://github.com/Hamlib/Hamlib
Mike W9MDB
On Sunday, June 20, 2021, 11:48:14 AM CDT, Jeff Stillinger via wsjt-devel
wrote:
Just an FYI...
Making all in rigs/prm80
libtool:
ng certain rigs. Is this correct? Do you
understand just what changes caused the problem, and do you have a fix
in preparation? Let me know...
-- Joe, K1JT
On 6/15/2021 6:08 PM, Black Michael via wsjt-devel wrote:
> What rig?
>
> Mike W9MDB
>
> On Tuesday, June 15, 2021, 05
What rig?
Mike W9MDB
On Tuesday, June 15, 2021, 05:06:26 PM CDT, Ned wrote:
Befuddled. I noticed that the TX start on FT8 using v2.4.0 seemed late
soon after I upgraded months ago. I always felt like I had taken a step
back in performance with v2.4.0 and decided to look at into it
Try this
rigctl -p com20 -P RTS -vv T 1 t T 0
Replace com20 with your serial port device. PTT should toggle on/off.
I suspect it will lock up when doing set_ptt which would mean your FTDI chip is
not functioning properly.
Mike W9MDB
On Monday, June 14, 2021, 04:04:04 PM CDT, Daniel
Those are a lot better
Do we have some benchmarks for WSJT-X decoding?
Thanks
Mike W9MDB
On Wednesday, June 9, 2021, 12:42:08 PM CDT, Richard Shaw
wrote:
On Wed, Jun 9, 2021 at 12:27 PM Black Michael via wsjt-devel
wrote:
Is there some reasons to think we get a notable
Is there some reasons to think we get a notable performance boost from AVX?
First link I found is not impressivevery few benchmarks show much
improvement and many show less and it's at a cost of 30% or so more CPU power
consumption...fans will be screaming...looks like it mainly helps on
--
Saku
OH1KH Black Michael via wsjt-devel kirjoitti 8.6.2021 klo 15.53:
All those programs will use the system libhamlib.so shared library.
If you do ldd /usr/bin/fldigi | grep ham ldd /usr/bin/qsstv | grep ham ldd
[path_to_cqrlog] | grep ham
And see what library it's pointing to.
All those programs will use the system libhamlib.so shared library.
If you doldd /usr/bin/fldigi | grep hamldd /usr/bin/qsstv | grep hamldd
[path_to_cqrlog] | grep ham
And see what library it's pointing to.
Then, if you install the latest hamlib to replace libhamlib.so they should all
work with
Use the rigctld from wsjtx 2.3.1 until the current WSJT-X has a fix.
Mike W9MDB
On Tuesday, June 8, 2021, 01:29:13 AM CDT, Saku wrote:
Bill Somerville kirjoitti 7.6.2021 klo 20.36:
Hi Saku,
the WSJT-X v2.5.0 RC1 RPM package for Fedora targets Fedora 34, which is why
you
If you run rigctld with "--vfo" it should work.
Mike W9MDB
On Friday, June 4, 2021, 03:12:29 AM CDT, Jonathan Magee
wrote:
Hi I just installed WSJTX 2.4.0 and I am noticing an issue with Split Rig
operation. When I change bands VFO-A changes frequency but VFO-B is not
changing
Check out the information hereYou need to add the 0x16 civ_addr for the 575
and then test the 475 model which will probably work.
Let me know what works and I'll add the 575 as one of the rig options.
https://sourceforge.net/p/wsjt/mailman/message/35618089/
Mike W9MDB
On Thursday, June
If you want to see the timings involved you can do this. Doing this would also
show if there's a bug or an improvement we can make.
#1 Run rigctld-wsjtx from a cmd prompt for the FT2000 -- note the -m will be
3014 for the IC725 -- adjust COM port and baud rate for your
setup.rigctld-wsjtx -m
void any confusion, Hound mode is not necessary to see what I described.
73,
Ton PA0TBR
On Thu, 15 Apr 2021 at 14:40, Black Michael via wsjt-devel
wrote:
Couple of thoughts
#1 Why are two instances being run? What's the use case?#2 What rig selection
are you using? Should be eit
Michael via wsjt-devel
wrote:
Couple of thoughts
#1 Why are two instances being run? What's the use case?#2 What rig selection
are you using? Should be either Flex or PowerSDR. #3 You might have more
success running FLRig and connecting both WSJT-X instances to the one
FLRig...that way you end
Couple of thoughts
#1 Why are two instances being run? What's the use case?#2 What rig selection
are you using? Should be either Flex or PowerSDR. #3 You might have more
success running FLRig and connecting both WSJT-X instances to the one
FLRig...that way you end up with just 1 program
Yes...full duplex...cross band.
Mike W9MDB
On Tuesday, April 6, 2021, 06:58:11 AM CDT, Claude Frantz
wrote:
On 4/6/21 1:29 PM, Black Michael via wsjt-devel wrote:
> get_vfo_info -- single call to retrieve freq mode width and split
> status for any VFO -- come to think of it
What questions? It's trying to explain the abstraction being made inside
hamlib. If you look at the new caching code it implements this and so do the
satellite mode rigs
For some software the RX/TX VFOs should serve their purpose (like WSJT-X which
only cares about RX/TX and not specific
Like I said it's all rig dependent.
Icom called their stuff Main/Sub where others used VFO A/B
Then things got complicated after that.
Conceptually VFOA=Main VFOB=Sub
Mike W9MDB
On Sunday, April 4, 2021, 11:23:31 AM CDT, Claude Frantz
wrote:
On 4/4/21 3:18 PM, Black Michael via wsjt
You find "VFOs.txt" in the main hamlib directory that tries to describe the
abstraction.The differences are rig-dependent along with rig mode.
The original abstraction which will remain is thisVFO_A=MainVFO_B=Sub
But the abstraction has been extended to support newer rigs and satellite mode
10.14.6
If it’s any mode other than Q65 or JT-65, I’ll need the settings used also Very
73
Dave KJ9I
Just a question: Why select “Fake-It” with K3S? I was advised to use “Rig”
and it works well.
From: Black Michael via wsjt-devel
Reply-To: Black Michael , WSJT software
Anybody out there with an Elecraft K3 or K3S willing do some testing for hamlib?
I have a report that Fake It does not work correctly on the K3/K3S so would
like to see some debug from other users to determine if this is a rig problem
or an Elecraft problem.
The behavior in Fake It is that the
Try this one please...your K3S is taking a long time to recognize a PTT change
so I'm disabling the ptt confirmation.That should take it back to the 2.3.0
status.
https://www.dropbox.com/s/xhaaaikqsfulykn/wsjtx-2.4.0-rc3-win64.exe?dl=0
On Saturday, March 20, 2021, 10:28:11 AM CDT, Mike
Could you please try this version of WSJT-X and see if it behaves?
https://www.dropbox.com/s/xhaaaikqsfulykn/wsjtx-2.4.0-rc3-win64.exe?dl=0
Mike W9MDB
On Wednesday, March 17, 2021, 06:40:49 AM CDT, Craig
wrote:
Hi all,
I am running WSJT-X 2.4.0-rc3 on an HP 8200 Elite with 8G ram.
I wonder if some of these rigs are avoiding hot switching PTT and ya'll are in
a borderline case.
Under the Advanced tab try changing the PTT delay to 0.2s instead of 0.1s.
Mike W9MDB
On Thursday, March 18, 2021, 02:49:51 AM CDT, Saku wrote:
HI!
This TX without audio
For a test please connect WSJT_X directly to the 7300 instead of Win4Icom.See
if that makes a difference.
Mike W9MDB
On Wednesday, March 17, 2021, 06:40:49 AM CDT, Craig
wrote:
Hi all,
I am running WSJT-X 2.4.0-rc3 on an HP 8200 Elite with 8G ram.
This is connected to an IC-7300
For a test please connect WSJT-X directly to the 7300 instead of Win4Icom.See
if that makes a difference.
Mike W9MDB
On Wednesday, March 17, 2021, 06:40:49 AM CDT, Craig
wrote:
Hi all,
I am running WSJT-X 2.4.0-rc3 on an HP 8200 Elite with 8G ram.
This is connected to an IC-7300
Whenever the GA release comes out you should be able to compile-and-go
Mike W9MDB
On Monday, March 15, 2021, 04:07:37 PM CDT, Marco Calistri
wrote:
Il 15/03/21 16:45, Black Michael ha scritto:
There is no GA 2.3.1 -- there is 2.4.0rc4 which should be up-to-date.
GA we could just compile it
straightforward avoiding to "GIT cloning" the latest hamlib.
Could you be so kind to confirm this before I will go to download and install
the GA 2.3.1?
Thanks a lot!
Best regards,
PY1ZRJ, Marco
Il 15/03/2021 12:44, Black Michael via wsj
Subject line didn't seem to catch up to the RC3...
Mike W9MDB
On Monday, March 15, 2021, 09:06:35 AM CDT, Joe Taylor
wrote:
We are pleased to announce release candidate WSJT-X 2.4.0-rc3, which
includes the new digital mode Q65.
Q65 is designed for two-way QSOs over especially
Have you tried this setting? Seesms reducing this should work.
LIN OUT NOR 010 Sets the LINE OUT level. LINE OUT connections go to PC
soundcard inputs.Settings above 10 may result in overdrive of the soundcard or
saturation of theKIO3’s isolation transformers; monitor signals using the PC to
What rig do you have?
Mike W9MDB
On Tuesday, March 9, 2021, 02:29:31 PM CST, KC7QY wrote:
Hi
I downloaded rc-2 last week shortly after it became available. I've managed a
Q65 QSO over the weekend with a rover. I noticed that when I went to TX there
seemed to be a delay between
One bug which is probably related to keeping the signal report constant...and a
needed ability to double-click.
When you have "Double-click on call sets Tx Enable" turned, off after you
transmit once, clicking on any new call puts the message in the Rx Frequency
window but does not generate new
You will find a Windows program and a Unix file you can compile for tweaking
the system time on my QRZ page.
I call it TimeFudge.
https://www.qrz.com/db/w9mdb
Mike W9MDB
On Thursday, March 4, 2021, 12:23:30 PM CST, Mark Spencer
wrote:
A few comments regarding this topic from the
hamlib now does band stacking for Yaesu rigs.
You need to set up each of your bands as you want them in the band stack and
WSJT-X will recall those settings.
Mike W9MDB
On Thursday, March 4, 2021, 04:26:28 AM CST, Dirk Kuschke via wsjt-devel
wrote:
- Weitergeleitete
Anybody with an IC-9700 that wants to volunteer for some testing with hamlib?
Mike W9DMB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Any Elecraft K4 users out there willing to do some testing with
hamlib/wsjt-x?Trying to ensure it's covered correctly.
Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
1, schrieb Black Michael via wsjt-devel:
The "-C stop_bits=2" should unnecessary -- that's the default for the FT-767GX.
If you're using model 109 that's an older version of hamlib. Where are you
getting rigctl.exe from? You're apparently not using the one in the latest
WSJT-X. Mike
He needs to upgrade hamlibthat's an older version and this is likely a
shared library problem.
Mike W9MDB
On Thursday, February 25, 2021, 11:43:37 AM CST, Bill Somerville
wrote:
On 25/02/2021 17:32, do4...@darc.de wrote:
>
> Hello,
>
>
> made FLDIGI work with HAMLIB using YAESU
The "-C stop_bits=2" should unnecessary -- that's the default for the FT-767GX.
If you're using model 109 that's an older version of hamlib.
Where are you getting rigctl.exe from? You're apparently not using the one in
the latest WSJT-X.
Mike W9MDB
On Thursday, February 25, 2021,
Speaking of the status messageCan we get a new status byte for when the
WSJT-X window is activated? Same action that resets the Watchdog but perhaps
we just need to poll the window activated status?
This would be a step towards selecting slices in Flex rigs.
Mike W9MDB
On
Been seeing some discussion on the inability of handling slices well with Flex
rigs.
I'd like propose that WSJT-X add a new message when the window is activated --
same logic as the watchdog timer does when you click on the window. External
apps could use that for many purposes like this.The
Is there an FT-991 operator out there that would be willing to help with some
testing on split mode changes for the FT-991?
Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Playing with Q65 decoding and anything over "Fast" mode takes a long time to
decode.Example at Deep decode taking 24 seconds to decode.
Is this expected?
Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
After you reset the split are you pressing the band select button for that band?
Mike W9MDB
On Thursday, February 18, 2021, 01:47:55 AM CST, Dirk Kuschke via
wsjt-devel wrote:
I reset the TRX and checked the VFO´s that there is no split. After that, I
switch the trx to a
I assume you are pressing the band select button to store the setting in the
band stack?
VFOA and VFOB have their own separate band stacks.
So you may have to select each VFO and press the band select to store it.
Mike W9MDB
On Wednesday, February 17, 2021, 01:01:51 PM CST, Dirk
a completely different app on the same system and then see if the
distortion is still there?
Alan G0TLK On 17/02/2021 13:02, Black Michael via wsjt-devel wrote:
Since I've also verified this on an IC-7300 with it's own USB sound card
seems it's a Windows bug. I think this is a recent Windows bug
Since I've also verified this on an IC-7300 with it's own USB sound card seems
it's a Windows bug. I think this is a recent Windows bug since I used to see
linear behavior on the Pwr slider so that reducing to -3dB would cut the power
in half...but no more
I've reported the problem to MS
/2021 5:56 AM, Black Michael via wsjt-devel wrote:
> You're wrong -- it's being transmitted too.
> I send that example a while ago.
That doesn't mean it's necessarily coming from the code -- the
distortion could be generated anywhere in the analog chain, from the
analog side of
You're wrong -- it's being transmitted too.I send that example a while ago.
Mike W9MDB
On Tuesday, February 16, 2021, 02:44:26 AM CST, Reino Talarmo
wrote:
>Patch to fix the problem
index 8e442d05f..81a978852 100644
--- a/widgets/mainwindow.cpp
+++ b/widgets/mainwindow.cpp
@@
wrote:
Mike,
we have verified the output from WSJT-X is clean, this is not an issue that
needs fixing in WSJT-X. Note also that on Linux and macOS no such distortion is
present.
73
Bill
G4WJS.
On 16/02/2021 04:18, Black Michael via wsjt-devel wrote:
Patch to fix the problem
their software to over-ride the changes we made. Just keep defaults as
they were and all will be happy.
End of rant
Tom
GM8MJV
On 16 Feb 2021, at 04:54, Black Michael via wsjt-devel
wrote:
A couple of complaints from those who were using a single
}
}
Then place this file in C:\Users\[username]\AppData\Local\WSJT-X and in
Each of the 4 WSJT-X folders but doesn’t work,
Alex, HB9DRI
From: Black Michael via wsjt-devel
Sent: Monday, February 15, 2021 11:11 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Black Michael
Subject: Re
etty certain Qt is not the cause since when the Pwr slider is at 0dB
Qt does nothing with the samples other than copy them to the Windows MME audio
buffers.
73
Bill
G4WJS.
On 15/02/2021 13:23, Black Michael via wsjt-devel wrote:
>
>
>
It's not just the waterfallthat nastiness gets transmitted too.
Mike W9MDB
On Monday, February 15, 2021, 02:53:44 AM CST, Reino Talarmo
wrote:
Hi Mike and Bill,
I looked those *.wav files using v2.4.0-rc1 and noted interesting presentation
difference, when I had Flatten
The PTT port is no longer shareable by default.
Place this file in C:\Users\[username]\AppData\Local\WSJT-X
{ "config": { "ptt_share": 1 }
}
Mike W9MDB
On Sunday, February 14, 2021, 07:43:47 PM CST, Alex Artieda, HB9DRI
wrote:
Just to inform you, I found a bug
Since I've duplicated this problem on two computers with two different rigs and
two different audio chains (one USB and one VAC) this is fairly obvious a
WSJT-X problem.
Anything that adds noise to the bands is undesirable. Especially when it can
be cured by a small software change.
Mike W9MDB
before the end of the main signal. I have zoomed
in as far as Audacity allows on the minimum amplitude bottom of the spectrum.
It looks perfectly clean to me!
73
Bill
G4WJS.
On 14/02/2021 21:01, Black Michael via wsjt-devel wrote:
Link to wav https://www.dropbox.com/s/cex6bfqfqzan65j
Same FT8 mode.
Do you still see harmonics if you drop WSJT_X Pwr level to -0.4 or so?
Mike W9MDB
On Sunday, February 14, 2021, 02:54:19 PM CST, Andy Durbin
wrote:
"I used Spectrum Lab to examine my TS-590S TX monitor audio for WSJT-X
versions 1.9.1, 2.00, 2.2.1, and 2.3.0. All
version of VAC (4.65.0). We can start by analysing the .WAV file for
problems.
73
Bill
G4WJS.
On 14/02/2021 18:45, Black Michael via wsjt-devel wrote:
Sorry to confuse
The receive was showing the effect of the bad Tx signal that has artifacts.
I did another test on Tx to show you
18:22, Black Michael via wsjt-devel wrote:
I just confirmed this same problem on an IC-7300 via the USB audio. You
can see the hash noise on the waterfall.
Seems we need to reduce the maximum amplitude WSJT-X generates.
Adjusting the Windows playback level does not affect the behavior
I just confirmed this same problem on an IC-7300 via the USB audio.You can see
the hash noise on the waterfall.
Seems we need to reduce the maximum amplitude WSJT-X generates.
Adjusting the Windows playback level does not affect the behavior.
Mike
Is there an FTDX3000 operator out there who wants to help test out some changes
to hamlib for me?
Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
near that high.
73
Bill
G4WJS.
On 13/02/2021 14:23, Black Michael via wsjt-devel wrote:
This is with 2.4.0-rc1 by the way...
Audacity shows a perfectly clean signalas does FLDigi. Only WSJT-X and
JTDX show problems with the signal. Common factor is Qt sound input.
Mike
Audacity's analysis tools.
73
Bill
G4WJS.
On 13/02/2021 13:57, Black Michael via wsjt-devel wrote:
I'll add one more data point. Looking at the same signal in FLDigi I don't
see any problem...nice and clean at 0dB attenuation.
Only problem is in WSJT-X and JTDX.
Mike W9MDB
I'll add one more data point. Looking at the same signal in FLDigi I don't see
any problem...nice and clean at 0dB attenuation.
Only problem is in WSJT-X and JTDX.
Mike W9MDB
On Saturday, February 13, 2021, 07:53:25 AM CST, Black Michael
wrote:
If you have a virtual audio cable
If you have a virtual audio cable you can do the same test.
This has nothing to do with the rig -- it's either Virtual Audio Cable (which I
doubt) or the Qt sound process. I've seen similar behavior from the Qt sound
device before.
I can run this test with the rig turned off and get the same
, February 13, 2021, 02:21:32 AM CST, Svend Aage Jessen
wrote:
FT-950. Alsomy cousin had the same thing happend on his FT-2000D.
Den 12.02.2021 18:58, skrev Black Michael via wsjt-devel:
What rig do you have?
Mike W9MDB
On Friday, February 12, 2021, 11:11:30 AM
What rig do you have?
Mike W9MDB
On Friday, February 12, 2021, 11:11:30 AM CST, Svend Aage Jessen
wrote:
What's up?
My current verion - WSJT-X v2.3.0 0c42df - makes my rig browse through
two or three band before setteling on chosen band.
The software works superb besides that,
301 - 400 of 1443 matches
Mail list logo
