On 03/05/2019 22:20, Bill Frantz wrote:
On 5/3/19 at 1:58 PM, g4...@classdesign.com (Bill Somerville) wrote:
your conclusions are all correct. We are currently fine tuning the
FT4 transmission start time so that the decoder gets a reasonably
even chance of decoding signals across the
Windows only or all platforms?
Scott W1ssn
Sent from my iPhone
> On May 3, 2019, at 4:58 PM, Bill Somerville wrote:
>
>> On 03/05/2019 21:24, Reino Talarmo wrote:
>> Hi,
>>
>> Thanks for an excellent piece of communication protocol both FT8 and FT4. It
>> would be interesting to see how big
Hi Scott,
Linux and Mac systems nearly all have accurate time synchronization
without any extra user setup. Obviously if no suitable Internet
connection nor GPS receiver is available then the same issues apply.
73
Bill
G4WJS.
On 03/05/2019 22:05, V. Scott Moore via wsjt-devel wrote:
On 5/3/19 at 1:58 PM, g4...@classdesign.com (Bill Somerville) wrote:
your conclusions are all correct. We are currently fine tuning
the FT4 transmission start time so that the decoder gets a
reasonably even chance of decoding signals across the allowable
DT tolerance of ± 0.5 S without losing
Hi Bill, Joe, Steve and all other participants in this forum
RE: Sub process error
I listened a long period of time on two WSJT-X FT4 instances at the
same time. There were no errors. I listened at the "normal" decoding
level. At the time (20:04) when I changed the level of decoding to
On 03/05/2019 21:24, Reino Talarmo wrote:
Hi,
Thanks for an excellent piece of communication protocol both FT8 and
FT4. It would be interesting to see how big guns start to use FT4
instead of RTTY. For strong signals RTTY is a bit faster than FT8, but
most of the users are not big guns! The
Hello Bill or Joe, good evening,
For some reason since I´ve installed WSJT X 2.1.0 the already known 100%
audio input level jumped also in my JTDX 135. I am not succeeding to go
back to lower audio levels in JTDX. Any reason for that ? Any suggestion?
73 de Enrique
PY2CP
Hi Enrique,
http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt
1. The 64-bit executable for Windows resets the audio input gain to
100% on program startup, when the input audio device is changed, and
when switching to a new configuration.
73`s Joe Jozef LB1HI
On 03/05/2019 23:50,
hi all,
I did mention this briefly a few days ago.
- The build platform is suse leap 15
- issue is active with wsjtx-2.01/linux (someone else built it for suse)
- issue is active with wsjtx-2.1.0rc5/linux (built myself)
- no issue with both versions in windows 10 pro
I believe it might be a
Hi all, firstly thanks for all the hard work in creating FT4, I'm having
lots of fun with it.
I think I have found a bug when decoding JT9 from the command line:-
C:\Users\alan\AppData\Roaming\m0nnb\SparkSDR2\jt9\jt9tmp_18796012>c:\wsjt\wsjtx21rc5\bin\jt9.exe
-9 -f 7076000 190503_0710.wav
At
Was doing some comparison with old/new FT8 and found I was unable to decode on
a local loopback either way.
I'm running at -21dB on both instances for power and the level meter is showing
about 60dB.The received wavform looks pretty but does not decode. Maybe
there's not enough noise?
Here is
Hello!
WSJTX 2.0.1, most likely 2.1.0-rc5 as well. Introduced with new ALL.TXT file
format.
When jt9 takes a bit too much time, decoded frames are coming late to the main
program.
For example, if FT14 period is from 122800 till 122815, and decoded frame shows
at 122816, then it is shown on
Bill,
Decode is already set to "Deep" plus AP. But no decoding of LZ497OM on my
Win10-PC with WSJT-X.
Will try to bring also example No. 1 through the size limit of the
reflector.
73 de Uwe, DG2YCB
Von: Bill Somerville [mailto:g4...@classdesign.com]
Gesendet: Freitag, 3. Mai 2019 12:46
An:
I had the system play back a couple of days worth of files and wasn’t able to
find the one that caused the issue. Is it possible that it plays back OK but
only fails when “live”?
From: Bill Somerville
Sent: Wednesday, May 1, 2019 9:57 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re:
Crash:
Win 7 pro 64-bit
M0FOX did CQ on 20m FT4 and I return to him several times and small error
window open in the middle of tx sequence with:
Running: D:\radio\HAM\Datamode\WSJT-X_210_RC5\wsjtx\bin\jt9 -s WSJT-X -w 1
-m 3 -e D:\radio\HAM\Datamode\WSJT-X_210_RC5\wsjtx\bin -a
Is there a new command line option for the command line jt9 app to allow
decoding of FT4? I see -4 is for JT4 but after compiling on my RPi 3 I
don't see anything listed for FT4. Is it not available there yet? Or just
not added to the help yet?
I'm looking to run jt9 w/ FT4 on my KiwiSDR to
>From "jt9 -h"
-5 --ft4 FT4 mode
de Mike W9MDB
On Friday, May 3, 2019, 11:21:41 AM CDT, K1RA - Andy Z
wrote:
Is there a new command line option for the command line jt9 app to allow
decoding of FT4? I see -4 is for JT4 but after compiling on my RPi 3 I don't
see anything
Jari --
Please click on "Read Before Download" here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
... which will take you here:
http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt
There is no need to provide further feedback on any of the known issues
in WSJT-X 2.1.0-rc5 that
Next curious observation: WSJT-X 64 bit and JTDX in parallel, listening to 6m
band, both connected to the same audio source, no QSO running, only a few
stations on band, with both programs saving all audio files to my SSD. Results:
From time to time JTDX decodes more callsigns. So far so good
Bill, LZ497OM's signal seems to be on the borderline of decoding. Got the
decode now two times when using the 64 bit version of WSJT-X. Be so kind as
to take a look also on example #1. There, the situation was more similar to
my QSO with F5NK a couple of days ago. (Unfortunately I have no audio
This comparison is not particularly meaningful.
JTDX was “in qso” with AM70U. So the DX Call box contained the callsign AM70U
and the internal QSO state machine was likely in a state that enabled AP
decoding using both your callsign and the dx call. On the other hand, the DX
Call box on the
Hi Paul,
On 5/2/2019 8:43 PM, Paul Kube K6PO wrote:
The documentation
http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf says, re S+P:
"Here “best potential QSO partner” means “New Multiplier” (1st priority)
or “New Call on Band” (2nd priority)."
Now it seems to me that "New Call"
Thanks! The old version was still in my PATH and since jt9 doesn't
report a version number when running -h (help) I didn't realize I was
still executing 2.0, hence no -5...ugh! All is well now running with
jt9 v2.1.0-rc5.
73
andyz - K1RA
>From "jt9 -h"
-5 --ft4FT4 mode
de Mike W9MDB
On 5/3/2019 11:21 AM, DG2YCB, Uwe wrote:
Next curious observation: WSJT-X 64 bit and JTDX in parallel, listening
to 6m band, both connected to the same audio source, no QSO running,
only a few stations on band, with both programs saving all audio files
to my SSD. Results: From time to time
Hi,
Thanks for an excellent piece of communication protocol both FT8 and FT4. It
would be interesting to see how big guns start to use FT4 instead of RTTY.
For strong signals RTTY is a bit faster than FT8, but most of the users are
not big guns! The bandwidth saving in FT4 is a really big issue,
25 matches
Mail list logo
