Peter,
hash22calc was never intended to be compatible with nonstandard callsigns. It
is a special purpose routine intended to be used along with the -Y option to
jt9 when decoding FST4W “type 3” messages. In particular, it was added at the
request of the wsprdaemon author, to allow him to use j
> On Jul 23, 2024, at 9:33 PM, Glenn Williams via wsjt-devel
> wrote:
>
> SO: what is the frequency tolerance of 750 Hz tone for successful decoding?
750 +/- 100 Hz
Steve k9an
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://list
> On Jul 23, 2024, at 10:41 AM, Black Michael via wsjt-devel
> wrote:
>
> Was looking at this example SuperFox transmission using Audacity
>
> https://www.dropbox.com/scl/fi/stohwy3veidevmwr4j517/240605_181330.wav?rlkey=85h1c9riskq1mmbqzex9hpov3&dl=1
>
> It looks like there is amplitude modula
Yes.
> On Jun 29, 2024, at 2:31 PM, Kari Sillanmäki via wsjt-devel
> wrote:
>
> Hi Steve,
>
> Do you have "libqt5multimedia5-plugins" installed?
>
> 73's de Kari, oh2gqc
>
>> On 6/29/24 22:04, Steve Brown via wsjt-devel wrote:
>> Hi,
>>
>> No problem on Ubuntu 24.04 on an amd64, but no au
Ryan,
The -c option does what it was designed to do: "-c write .c2 file at the end of
the first pass". It writes a .c2 file after signals decoded in the first pass
have been subtracted. This .c2 file is useful for studying the effectiveness of
signal subtraction, i.e. to study the residuals lef
Hi Josh,
So far, I’m not able to reproduce that behavior here. WSPR band hopping is
working fine and Enable Tx stays enabled once it is set.
Steve k9an
> On Jul 8, 2023, at 5:49 AM, Josh Rovero via wsjt-devel
> wrote:
>
> Builds and runs well on Fedora Core 38 64-bit.
>
> While WSPR band h
Hi,
In the old version of gen_ft8wave that you have based your library on there was
was no bug because gen_ft8wave was always called with fsample=48000 when called
from the WSJT-X c++ code and with fsample=12000 when called from the jt9
fortran code.
When the “a7” decoding feature was added i
Ryan Tolboom N2BP
>
> On Tue, May 9, 2023 at 12:08 PM robert evans LAST_NAME
> wrote:
>>
>> I used to code that signal processing in fortran
>> because of the complex data type matrix
>>
>> I now code that in python for the same reason.
>>
>> K9
Hi Ryan,
On each pass signal candidates are sorted in order of decreasing
signal-to-noise ratio (SNR) and then wsprd sequentially attempts to decode each
candidate. If a decoding attempt is successful, then a reconstructed version of
the signal is subtracted from the data vector and the algorit
Thanks Ryan! I’ve fixed this in our development code. The fix will appear in
the next release.
Steve k9an
> On Apr 26, 2023, at 8:52 AM, Tolboom, Ryan via wsjt-devel
> wrote:
>
> Good Morning,
>
> In the coarse estimates section of the /lib/wsprd/wsprd.c decoder the
> kindex for the time se
Stefan,
Please see the Release_Notes.txt for 2.6.0-RC5. The second item is as follows:
- Upload FST4W-900 spots to wsprnet with TR code 15 instead of 16.
I believe that this addresses your request.
Steve k9an
> On Nov 30, 2022, at 10:15 AM, Stefan HB9TMC via wsjt-devel
> wrote:
>
> Hi Mi
Thanks Mike! I’ll incorporate your patch into rc3.
Steve k9an
> On Aug 2, 2022, at 12:35 PM, Black Michael via wsjt-devel
> wrote:
>
> This patch fixes the problem.
>
> diff --git a/widgets/mainwindow.cpp b/widgets/mainwindow.cpp
> index 8099aa7fa..8bde6aeff 100644
> --- a/widgets/mainwindow.
Rob,
The fst4w_calls.txt file is not used to resolve the hash in type 3 FST4W
messages. It is used to validate decodes obtained when jt9 is called with the
“-d 3” option, which enables a decoding pass that treats the FST4W message’s
CRC bits as if they were parity bits rather than message bits
` WB7ABP CM88 27
>0 10
> EOF on input file 20211002T035100Z_474200_usb.wav
>0 00
> rob@Robs-MBP:/Users/rob/jt9> cat decoded.txt
> 0 27 0.4 1590. 0 WB7ABP CM88 27FST4
> rob@Robs-MBP:/Users/rob/jt9>
>
>
>
>
> On Sa
Rob,
Try setting the offset frequency window using either -L/-H or -f/-F, e.g.:
$ ./jt9 -W -d 3 -p 120 -L 1400 -H 1600 *.wav
0001 -30 0.0 1500 ` K9AN EN50 0
Steve k9an
> On Oct 2, 2021, at 10:15 AM, Rob Robinett via wsjt-devel
> wrote:
>
> Hello,
>
> I am trying to add FST4W support to
Eric,
Thanks for the report. What version of WSJT-X are you running? Here, using the
latest development code I tried creating a .wav file containing a single signal
with the message “ NO3M/3 RR73”. I decoded this with “NO3M/3” in the Dx
Call box and with My Call set to K9AN. No problem with th
owed your suggestions. However, I don’t see
> ~/Library/Preferences/ under WSJT. (Bill had asked me to move a file that he
> sent (wsjt_log_config.ini) there for debugging purposes.) Maybe move it to
> WSJT INI?
>
> 73,
>
> John
> WA1EAZ
>
>> On Mar 6, 2021, at
John,
You can make the ~/Library folder visible in Finder with the following steps:
1. Open a Finder window.
2. Select your home directory in the left panel of the Finder window.
3. Select Show View Options under the “View” menu.
4. Check the “Show Library Folder” box.
Thereafter, your Library f
>
> Next thought. I called CQ for quite a while set for FST4-60. No responses,
> but a guy near Phoenix (I'm near SF) posted me to PSKReporter, probably
> unattended. My question is with respect to decoding, if I set up for FST4-60,
> would I also decode shorter period FST (and vice versa)?
Ji
> On Feb 2, 2021, at 4:56 PM, Jim Brown wrote:
>
> With FST4, is there an advantage to using narrower decode bandwidth and/or
> narrower frequency tolerance?
>
> Jim K9YC
Jim,
The GUI controls (FTol for FST4W and FLow/FHigh for FST4) determine the upper
and lower limits of the candidate sear
Hi Josh,
It would help us track the problem down if you could provide a .wav file for a
case that produces the large DT values.
Thanks in advance,
Steve, k9an
> On Jan 16, 2021, at 9:11 AM, Josh Rovero wrote:
>
> I have noticed this issue twice, first when running rigctld-wsjtx, second
> when
Hi Tony,
Thanks for following up. We’ve tweaked the Fast decode setting for the next
release. It should work much better on your RigPi.
73 Steve k9an
> On Jun 14, 2020, at 10:24 PM, Tony wrote:
>
> Hi Steve –
>
> Sorry it has taken a few days to answer your questions, and think I have now
Hi Rob,
WSJT-X v2.2.1 uses the following command line options for the Deep decoding
setting: " -C 500 -o 4 -d “. The “-d” option may be too intensive for
low-powered machinese.
You’ll notice that the number of Fano iterations is limited to only 500.
Testing here indicated that this virtuall
> Fine to learn how it should work, but here, there is always the same crash,
> even in 2.2.1, trying to decode FT8 on the air or from a wav file. In
> contrast, FT4 decodes well.
Claude,
Please try this change to line 48 in gen_ft8wave.f90 and let me know if it
fixes your problem:
$ git dif
> On Jun 9, 2020, at 12:09 PM, Bill Somerville wrote:
>
> On 09/06/2020 16:51, Rob Robinett wrote:
>> I want sites running my 'wsprdaemon' to benefit from the improved decoding
>> performance of the V2.2 wsprd decoder, but I am not sure how to determine
>> which version of wsprd is installed.
>
Hi Tony,
> Using a 2.2.x version, decoding on a busy band has the following behavior:
> first decode in cycle picks up a few messages, second decode a few, then the
> third decode runs a long time (well into the next cycle) and the majority of
> messages get decoded on that third decode.
What
Cesar,
Your screenshots only show part of a few lines of the error message, and it’s
not enough to be able to tell what’s going on. You’ll need to copy the *entire*
contents of the error box and paste that into a message.
73/HNY,
Steve k9an
> On Dec 31, 2019, at 7:09 PM, Cesar Martinez wrot
Cesar,
Two things would help us to diagnose the problem. Next time that the error
occurs please (i) click the “Show Details…” button and copy the detailed error
message and send it to the list, and (ii) send us a saved .wav file that
produces the error, along with instructions for how to produc
Mike,
>
> Ok...not as insane as I thought I was…
See my annotations to your list of decodes, below, in red. I can tell from the
results that the Rx frequency was probably set to something near 1500 Hz. I can
assure you that there are only 3 passes (see my previous post for the
definition of a
Mike and Bill,
WSJT-X does three decoding passes, where a “pass” consists of the following
steps:
1. do spectral analysis and make a list of likely FT8 signal candidates, sorted
in order of increasing offset frequency. If a candidate is found near the
current Rx frequency, put that candidate a
Grant,
> On Nov 21, 2019, at 2:31 PM, Grant VK5GR wrote:
>
> Folks,
>
> ALL.TXT is not populated when in FOX mode in 2.1.0 - I checked the logs from
> A35JT. Only when we were in standard mode was it being updated.
I am not able to reproduce this.
I have just tested v2.1.0 here on Linux and s
oise, so is this even
> something that you can solve or nicely approximate analytically? I'd be
> interested to know.
>
> 73, Paul K6PO
>
> On Sun, Jul 28, 2019 at 7:38 AM Steven Franke via wsjt-devel
> mailto:wsjt-devel@lists.sourceforge.net>>
> wrote:
> H
Hi James,
> The source code in question is lines 168 through 215 of lib/ft8/ft8b.f90 (Git
> tag wsjtx-x 2.1). This source code appears to implement a “soft demapper”
> that takes groups of 1, 2 or 3 successive symbol observations and turns these
> into groups of 3, 6 or 9 log likelihood ratios
Hi Gene,
> FT8 is WAY MORE sensitive! (~8db)
That number is not right. On the additive white Gaussian noise (AWGN) channel,
the 50% decode probability of FT8 occurs at SNR=-20.8 dB and the 50% decode
probability of FT4 occurs at SNR=-17.5 dB. The sensitivity difference is
therefore 3.3 dB.
> On Jul 21, 2019, at 12:58 PM, John Nelson via wsjt-devel
> wrote:
>
> Hi Bill,
>
> I managed to get someone to run the code from a Terminal window. It exits
> with:
>
> “At line 1 of file /Users/bill/wsjtx-prefix/src/lib/gen65.f90
> Fortran runtime error: Actual string length is shorter th
> On Jun 7, 2019, at 8:32 AM, Bill Somerville wrote:
>
> On 07/06/2019 14:29, Derek Turner via wsjt-devel wrote:
>> This just happened with FT4.
>>
>> I accidentally got into two QSOs simultaneously and the program did not send
>> 73 to the second station so I triggered it manually with TX6:-.
Hi Al,
Please verify that you were running the latest rc7 release?
Assuming that you are running rc7, it would be helpful if you could send a
saved wav file that reproduces this error.
Thanks!
Steve k9an
> On Jun 4, 2019, at 11:03 AM, Al wrote:
>
> I left while monitoring FT4 on 20m, When
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 WS
Hi Bill,
Fine control of the Pwr slider is already available using the up- and
down-arrow keys on your keyboard. Try clicking on the slider first and then
using the up- and down- arrows.
Steve k9an
> On Mar 23, 2019, at 8:25 AM, Bill Cole wrote:
>
> I wish to make a suggestion for an additiona
Hi Pino,
You called the DX on 1321 Hz offset. Then, the DX responded to you with report
+00. If you were operating as a Hound, then your next transmission should have
been at 303 Hz. Instead, you transmitted your “R-20” again at 1321 offset. This
behavior suggests that you were not operating as
Hi Olivier,
I think that the problem is that your wav filename is not in the expected
format. Try changing from “FT8.wav” to, say, “00_01.wav”.
73 Steve k9an
> arecord_adv -d 15 -q -t raw -f S16_LE -r384000 -c2 -D dsnoop:lp4,1 -F0
> --period-size=1024 -B0 --buffer-size=4096 | csdr conve
Rob,
- wsprd parses the file name to get date and time.
- the decoding algorithm does not use date and time.
Steve k9an
> On Feb 1, 2019, at 6:49 PM, Rob Robinett wrote:
>
>
> My wsprdaemon.sh SW is running at 7 beta sites and detects almost all of the
> signals in the bands.
> However it
;
> I really appreciate the feedback…it keeps me thinking. Thanks!
>
> Joe/WB0CDY
>
> From: Steven Franke via wsjt-devel
> Reply-To: WSJT software development
> Date: Friday, February 1, 2019 at 1:36 PM
> To: WSJT software development
> Cc: Steven Franke
> Sub
Hi Joe,
It sounds to me as if the Cumulative spectrum plot that can be displayed
underneath the waterfall is exactly what you have described. The Cumulative
spectrum is the sum of all of the short-term spectra that make up the waterfall
display. The sum is reset to zero at the beginning of eac
Hi Paul,
Recently, we’ve introduced a couple of techniques that have significantly
improved the sensitivity of WSPR-2. Increased sensitivity comes with higher
probability of false decodes. The next release of WSJT-X will fix a bug that
should eliminate some of those false decodes - but it will
> On Dec 24, 2018, at 5:11 PM, Martin Davies G0HDB
> wrote:
>
> On 24 Dec 2018 at 9:13, John Becker wrote:
>
>> I'm running WSJT-X v2.0 on a Windows 10 Pro (1803 update) computer.
>>
>> On Saturday, HV0A was running F/H mode on 3567 with a large number of
>> callers. I noticed strange beha
ing.
>
> My next step seems to be ripping out 10.14.2 and drop back to 10.13.6, and
> see if that even has anything to do with it.
>
> 73,
>
> Jim
> K6MIO/KH6
>
>> On Dec 20, 2018, at 12:02 PM, Steven Franke via wsjt-devel
>> wrote:
>>
>>>
> I seem to recall that there was a point, previously, during which some Macs
> needed to have a memory range tricked out. That was done with the Mac Mini,
> and it then worked fine with earlier versions of both the OS and the WJST
> package.
>
> Is that still an issue. Did the OS update wipe
> On Dec 15, 2018, at 11:11 AM, Ton PA0TBR wrote:
>
> I am trying to work out why some callsigns are shown as <...> in WSJT-X
> Sometimes <...> is reflected in JTAlert as ... other times it is not shown
> in JTAlert.
>
> For example:
> 103615 -12 1.8 1590 ~ <...> LZ1PPZ
> 103645 -2 1.8 159
Rob,
> The antennas and receivers are identical. Am I not properly utilizing the
> hashtable in my SW?
I see no good reason to use someone else’s hashtable.txt merely to try to eek
out a couple more decodes. Why raise the probability of hash collisions by
including stations that you have neve
the time and
> I was being kept out for some other reason that I need to fix?
>
> Thanks for your help.
>
> 73 Dave Hassall WA5DJJ Las Cruces, New Mexico
> Website: http://www.zianet.com/dhassall/
> QRSS SUPER GRABBER WEBSITE: http://www.qsl.net/wa5djj/
>
>
>
&g
Andy,
Thank you for sending wav files!
This morning I identified and fixed a bug that probably explains the symptoms
that you have described. The bug was causing signals with negative DT to fail
to decode. This bug may explain why some users observe that decoding seems to
stop working after
Try expanding the log window, vertically, so that it takes up at least 2/3 of
your screen. If I do that, I can always see the last line.
Steve k9an
> On Dec 2, 2018, at 11:07 AM, Bill Pence wrote:
>
> Same here. Last qso is just off the bottom on the contest log window. A new Q
> scolls to see
Thanks for the report Drew - I confirm the issue that you described. I’m
looking at it now, and it’ll be fixed for the GA release.
Steve k9an
> On Dec 1, 2018, at 10:02 AM, Drew White wrote:
>
> This morning I attempted an FT8 RC5 connection with C4XMAS. My initial
> transmission was truncate
>
> *** Would it not be better if files were always numbered with 6 time digits
> insted of a mix of 4 and 6 digits, then the list would be ordered in a
> squential manner?
Hi John,
Glad that you figured out what was going on. Personally, I prefer the naming
convention the way it is now. I
Hi John,
I haven’t noticed that problem here on MacOS 10.14.
Steve, k9an
> On Nov 28, 2018, at 7:03 AM, John Nelson wrote:
>
> macOS 10.13.6: v2.0.0-rc5:
>
> FT8 is working well, colours included, on 20m, 30m and 40m. Several reports
> of -24 dB so sensitivity is vey good.
>
> I switch
Al,
This is expected behavior. Since RC4 does not decode 75 bit messages, it cannot
subtract them. Thus, RC3 will often be able to decode a 77bit messages on the
second or third decoding pass, after it has removed interference from 75bit
messages. On the other hand, RC4 will not remove the inte
> On Nov 24, 2018, at 9:10 PM, Rob Robinett wrote:
>
> Hi,
>
> I am using the V2.0 wsprd in a stand-alone 8 band simultaneous WSPR decoding
> appliance built from a KiwiSDR and a Raspberry Pi.
> However when I process my 2 minute wav files with 'wsprd -d -C 5000 -o 4' I
> get different SNRs
Mike,
The 4 programs that you listed are obsolete development code. None of them are
used in WSJT-X.
Steve K9AN
> On Nov 15, 2018, at 8:44 AM, Black Michael via wsjt-devel
> wrote:
>
> Is the 77-bit separate?
>
>
> extractmessage144.f90: character*12 recent_calls(nrecent)
> ldpcsim128_90.f9
ote:
>
> Steve,
>
> What does the number before the 0 or 1 in ALL_WSPR.TXT represent? I see it as
> 810 when there's a 1 (new algo) decode
>
>
>
> -Jim wa2zkd
>
>
> On 10/28/2018 12:28 AM, Steven Franke via wsjt-devel wrote:
>> Hi Rob -
>>
sed by wsprd alone. Could the
> two wsprd versions depend up the history in ALL_WSPR.TXT or be sharing
> information in wspr_wisdom.dat or the other support files which influence the
> results?
>
> Thanks,
>
> Rob
> AI6VN
>
>
>
>
>
> On Fri, Oct
> On Oct 26, 2018, at 2:21 PM, Jim Lill wrote:
>
> What is the method to verify my system is indeed enjoying the 1 dB SNR
> improvement that 2.0 gives?
>
> Thanks
>
> Jim
>
> WA2ZKD
Hi Jim,
You might try turning on “Save All” and running for, say, 24 hours or even a
couple of days. Then yo
> On Oct 18, 2018, at 5:06 PM, Black Michael via wsjt-devel
> wrote:
>
> Seems it's not possible to turn off 77-bit messages when Hound is selected?
> As soon as I save it and come back in they're checked again.
Mike,
You are correct. This is what was intended. Fox and Hound use only 77-bit
m
Hi John -
It looks like I forgot to comment out a debug print to fort.81. On the Mac, you
can get around this by running from within the application bundle. For example,
my install directory is ~/Builds/wsjtx/install, so I would do this to run wsjtx:
cd ~/Builds/wsjtx/install/wsjtx.app/Content
Mike,
> On Oct 3, 2018, at 9:26 AM, Black Michael via wsjt-devel
> wrote:
>
> Having a problem with transmit signals behaving badly when 12dB down or more
> on RC2. The behavior I see is my output power gradually rises over about 3
> seconds and that's what started my investigation. If abov
Hi John,
> On Oct 4, 2018, at 4:23 PM, John Kludt wrote:
>
> Folks,
>
> In to and checked NA VHF Contest - on main page TX 2.0
> NA VHF verbage appeared in Red Bar. Generated messages as expected. TX1
> grayed out. Went back to checked ARRL FD and filled in exchange.
> Back on main pa
> On Sep 28, 2018, at 9:33 AM, jarmo wrote:
>
> Fri, 28 Sep 2018 12:07:40 +0100
> Bill Somerville kirjoitti:
>
>> you should be able to replay the .WAV files and determine which
>> period causes he issue. Set the application up as it was for original
>>
> Hi Bill
>
> Think found file, did run
Ken,
You are decoding frames that are being sent by someone who is still running
RC1. The person who is running RC1 is trying to send messages to EA1FA. The bug
in RC1 is such that whenever the first callsign in a message can be interpreted
as a valid hexadecimal number, it will send that first
Hi Jarmo,
I have another suggestion. Can you please look in your install/bin directory
and see if you have a file called “fort.81” there. If so, please send it to me.
On Windows, I am told that the location of that directory would be something
like C:\WSJT\WSJTX\bin
Steve
> On Sep 26, 2018,
Hi Jarmo,
Thanks for the report. It’s the first one of these that I’ve seen. If you had
“save decoded” checked, then I think that it should have saved that file. If
you can find it, I’d like to play with it.
Steve k9an
> On Sep 26, 2018, at 8:12 AM, jarmo wrote:
>
> Wed, 26 Sep 2018 08:48:52
Hasan,
Unfortunately, your report isn’t very useful as it stands. To you and others
who are testing the recent beta release of v2.0: when making a bug report,
please carefully document and report a sequence of steps needed to reproduce
the problem. When running a beta release, always run with “
Gary,
It can’t find the fortran compiler. If you are using MacPorts, it should be in
/opt/local/bin, e.g.:
$ which gfortran-mp-5
/opt/local/bin/gfortran-mp-5
Steve k9an
> On Jul 13, 2018, at 11:16 AM, Gary Rogers wrote:
>
> Here is the latest:
>
> Charless-MacBook-Pro-2:build charlesrogers$
+8dB
> challenge.
>
> Joe,
>
> As I write to Steve, I do not have any intention to sell or stick to my +8dB
> number. If you feel uncomfortable, please deal it to + (1~8)dB additional
> gain proposal .
>
> take
>
> de JA5AEA
>
> Sent from Mai
Hi Take-san,
> I meant QRAXX as “Q-ary Repeat-Accumulate Codes for Weak Signal
> Communications” in Nico’s literature but I do not have any intent to modify
> wsjt-X “QRA64” mode to this discussion.
Understood. But why not scale the well-known results from Nico’s excellent
QRA64 mode to see w
Hi Take-san,
> Additional gain comes from:
>
> Adopt QRA64 or QRA128 utilizing 3kHz wide fox TX bandwidth : +4dB gain
I don’t think that there is 4 dB to gain here.
Nico showed that the 50% decoding threshold of QRA64 on the AWGN channel is
about -26.5 dB under ideal circumstances. With sync
Mike,
Surely, those who really want to work the DX will take time to learn how to do
it. The others will be frustrated and will eventually quit. Along the way, the
clueless will also cause some QRM. That’s how it works in CW, SSB, and RTTY
pileups, and I don’t expect FT8 to be any different. As
76 matches
Mail list logo
