Re: [wsjt-devel] hash22calc: Allow hashes of nonstandard callsigns (and longer)

[Steven Franke via wsjt-devel]

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 jt9 for decoding FST4W 
while maintaining his own hashtable. Note that FST4W uses 50-bit message 
payloads and callsigns are limited to standard calls or standard calls with a 
prefix or suffix. 

Steve K9AN

> On Aug 16, 2024, at 1:52 AM, Pengo VK3PGO via wsjt-devel 
>  wrote:
> 
> hash22calc.exe cannot replicate a hash calculated by ft8code.exe, so
> I've made a patch to fix it: updating hash22calc to allow nonstandard
> callsigns as input. It also changes the output format.
> 
> The below text has also been posted to
> https://sourceforge.net/p/wsjt/wsjtx/merge-requests/19/
> where it is formatted to make it easier to read.
> 
> This patch cleans up hash22calc.exe so that it's more inline with 
> ft8code[.exe].
> 
> The 22-bit hash for YW18FIFA is 0771524 or in binary
> 001000010111000100
> 
> The first 12 bits are
> 001000
> 
> This string of bits are the start of one of ft8code's sample messages:
> 
> ## WSJT-X 2.7.0-rc6
> 
> $ ./ft8code "CQ YW18FIFA"
>Message   Decoded
>   Err i3.n3
> 
> 1. CQ YW18FIFA   CQ YW18FIFA
>4.  Nonstandard call
> 
> Source-encoded message, 77 bits:
> 0010000111101110111000111001101010111001110001100
> ...
> 
> To find the hashes of most callsigns, a user can employ hash22calc to
> calculate the hash, but not for this one:
> 
> ## WSJT-X 2.7.0-rc6
> 
> $ ./hash22calc "YW18FIFA"
> Invalid callsign
> Usage: hash22calc 
> 
> I've updated hash22calc[.exe] to allow longer callsigns, as are found
> in hashes generated elsewhere in wsjtx software. That's the crux of
> this patch.
> 
> But just in case someone might have previously found the error message
> from hash22calc useful for checking if a callsign was a valid shorter
> standard callsign, I've added back this user feedback more explicitly.
> 
> I've also made the hash value print first to make it easier to extract
> programmatically in future, and added code to stop invalid characters
> from being accepted.
> 
> Here's the new output in its entirety:
> 
> ## With this patch
> 
> $ ./hash22calc "YW18FIFA"
> 0771524 YW18FIFA
> 
> Valid standard callsign: no
> Valid nonstandard callsign: yes
> 
> If you don't like the additional lines of text, or perhaps you think
> it should be moved to another program, then you can delete the block
> of code under the comment "!also print if it's valid to remove it."
> 
> The patched version also accepts callsigns which are longer than an
> allowed "type 4" callsign because that is also allowed by ft8code.
> 
> For example:
> 
> ## WSJT-X 2.7.0-rc6
> 
> $ ./ft8code "CQ vk0muchTooLongCallsign"
>Message   Decoded
>   Err i3.n3
> 
> 1. CQ VK0MUCHTOOLONGCALLSIGN CQ VK0MUCHTOOL
> *  4.  Nonstandard call
> 
> Source-encoded message, 77 bits:
> 010001010110101101011110011001001010010011011101000111100
> 
> 14-bit CRC:
> 10111011010101
> 
> 83 Parity bits:
> 1011001001110100011011010110101010001100100011001011011
> 
> Channel symbols (79 tones):
>  Sync   Data   Sync   Data
>   Sync
> 3140652 31346620217433554737540021266 3140652
> 34432675223740637415507542722 3140652
> 
> ## With this patch
> 
> $ /hash22calc "vk0muchTooLongCallsign"
> 1137640 VK0MUCHTOOLONGCALLSIGN
> 
> Valid standard callsign: no
> Valid nonstandard callsign: no
> 
> 1137640 is
> 010001010110101000 (22 bits)
> 
> the first 12 bits are the start of the output from ft8code:
> 010001010110
> 
> So it can now match ft8code's existing and past output, which does
> indeed allow hashing of longer callsigns than even allowed by the
> nonstandard call format.
> 
> Hope this patch made use of. I have been enjoying learning about the
> intricacies of the FT8 format and now the curiosities of Fortran.
> 
> Peter (Pengo Wray) VK3PGO
> 
> As background to explain the ft8 message for anyone trying to follow
> along, it's "type 4" FT8 message, which is the type that includes a
> longer, "nonstandard" call. CQ has been set by turning on bit #74
> ("c1"), which also tells the receiver that the long callsign field is
> the sender's call, that it's a CQ message, and to ignore the first
> field (a 12-bit hash). Rather than leave the hash field empty, the
> hash of the sender's callsign is placed in this field by wsjtx,
> presumably for additional redundancy, or perhaps in case their call
> still doesn't fit in 

Re: [wsjt-devel] Superfox Waveform

[Steven Franke via wsjt-devel]

> 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://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Superfox Waveform

[Steven Franke via wsjt-devel]

> 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 modulation going on which would seem to be 
> undesirable.
> For example, analyzing this one section there is a 1697Hz signal.  But if the 
> amplitude drops the SNR will drop too limiting the decoding ability.
> Is amplitude modulation part of the Q-ary polar code?


The SuperFox audio waveform produced by WSJT-X is a constant-envelope Gaussian 
frequency shift keyed (GFSK) signal with bandwidth-time product BT=8.  The GFSK 
waveform includes 24 sync symbols at audio tone frequency 750 Hz and 127 polar 
code symbols at tone frequencies 750 Hz + n*11.71875 Hz, where n is in the 
range 1-128. 

If the transmitter’s upper-sideband audio-to-RF frequency response is flat over 
the bandwidth of the SuperFox signal (750 Hz - 2262 Hz audio) then the 
transmitted signal will also have constant envelope. What you are seeing in the 
example that you posted is the result of frequency-selective fading, i.e. the 
propagation channel’s frequency response is not flat over the 1512 Hz bandwidth 
of the SuperFox signal. Most signals will exhibit this effect so some extent.

Steve K9AN___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] No audio output to FT-710 with Raspberry pi

[Steven Franke via wsjt-devel]

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 audio on RPi 5 with the
>> same OS. Receive works on both.
>> 
>> I rebuilt wsjtx so the images are identical on both (2b9d65).
>> 
>> The settings are identical.
>> 
>> The sound output name is
>> "alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-
>> stereo"
>> 
>> The log is spammed with
>> 
>> Jun 28 14:48:00 wsjtx kernel: retire_capture_urb: 1014 callbacks suppressed
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: hw:2: snd_pcm_status error: 
>> No such device
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: hw:2: snd_pcm_recover error: 
>> No such device
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: get_status error
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: hw:2: snd_pcm_drop No such 
>> device
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: hw:2: close failed: No such 
>> device
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: front:2: snd_pcm_drop No 
>> such device
>> Jun 28 14:48:01 wsjtx pipewire[1007]: spa.alsa: front:2: close failed: No 
>> such device
>> Jun 28 14:48:01 wsjtx kernel: usb 1-2.2: reset full-speed USB device number 
>> 4 using xhci-hcd
>> Jun 28 14:48:03 wsjtx pipewire[1007]: spa.alsa: front:2: snd_pcm_drop No 
>> such device
>> Jun 28 14:48:03 wsjtx pipewire[1007]: spa.alsa: front:2: close failed: No 
>> such device
>> Jun 28 14:48:03 wsjtx kernel: usb 1-2.2: reset full-speed USB device number 
>> 4 using xhci-hcd
>> Jun 28 14:48:05 wsjtx pipewire[1007]: spa.alsa: front:2: snd_pcm_drop No 
>> such device
>> Jun 28 14:48:05 wsjtx pipewire[1007]: spa.alsa: front:2: close failed: No 
>> such device
>> Jun 28 14:48:05 wsjtx kernel: usb 1-2.2: reset full-speed USB device number 
>> 4 using xhci-hcd
>> 
>> If I set wsjtx audio output to the hdmi audio device, I get FT8 tones
>> and no complaints in the log.
>> 
>> The rig indicates transmit, but no audio, so no RF.
>> 
>> Any suggestions on tracking this down?
>> 
>> I tried uncommenting some of the qDebug calls, but can't find/enable
>> the output.
>> 
>> Steve WA9OLA
>> 
>> 
>> 
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] c2 files written after signals subtracted

[Steven Franke via wsjt-devel]

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 left after subtracting signals. 
It can also be re-analyzed by wsprd to study the effectiveness of a 2nd pass 
over the data and then again to do a 3rd pass, etc. 

If you need a .wav to .c2 converter, you might consider using the routines 
provided with wsjtx to create one.  WSJT-X does the conversion from 12000 
samples/sec to 375 samples/sec in src/widgets/mainwindow.cpp by calling the 
fortran routines in these files:

/src/lib/wspr_downsample.f90:q
/src/lib/savec2.f90

Subroutine wspr_downsample() downsamples from 12000 integer samples/sec to 1500 
complex samples/sec and function savec2() downsamples from 1500 to 375 complex 
samples/s and writes out the .c2 file.

Steve k9an

> On Jul 18, 2023, at 4:07 PM, Tolboom, Ryan via wsjt-devel 
>  wrote:
> 
> Good Evening,
> 
> When using wsprd in multi-pass mode (no '-s' option) and passing it
> the '-c' option to write a c2 file, it
> writes the c2 file at the end of the main loop on the first pass AFTER
> it subtracts out the decoded
> candidates. This means if you're using the c2 file to do analysis of
> the IQ data that was decoded you
> don't have the actual signals available (at least the ones decoded on
> the first pass).
> 
> Is there any particular reason the c2 file is written after the first
> pass? The only real changes I noted
> to idat and qdat within the main loop were signals being subtracted.
> Could it be written before the
> main loop after idat and qdat are created from a wav or c2 file? If
> so, I've attached a patch for
> wsprd.c that moves the logic that calls writec2file to right before
> the main loop.
> 
> Thanks for your time,
> 
> Ryan Tolboom N2BP
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.7.0-rc2

[Steven Franke via wsjt-devel]

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 hopping, the first band change cycle "unsets" Enable Tx, but 
> after resetting Enable TX, subsequent band changes keep it set.
> 
> -- 
> P.J. "Josh" Rovero http://www.roveroresearch.org 
>   
> Ham Radio: KK1D
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] possible bug in gen_ft8wave

[Steven Franke via wsjt-devel]

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 in WSJT-X version 2.5 the code was 
changed to allow calling with different fsample values.

73,
Steve k9an

> On May 27, 2023, at 2:53 PM, Paulh002 via wsjt-devel 
>  wrote:
> 
> Hello,
> 
> I am new to this group, and have a question about the fortran code of 
> gen_ft8wave. I am using the fortran code in a c++ library to support ft8 in 
> my own sdr transceiver development on a raspberry pi. (see github 
> https://github.com/paulh002/wsjtx_lib  
> and  https://github.com/paulh002/sdrberry 
> ). I have made a c++ wrapper library 
> with the fortran code which works fine but for one issue.
> Sometimes the subroutine gen_ft8wave generates an incorrect ft8 wave. This 
> happens when the subroutine gen_ft8wave is first used in the decode process 
> which uses a sample rate of 12000 Hz. The subroutine saves the sample time in 
> variable dt, but when I generate a ft8 signal I use 48 Hz and the dt 
> variable is then incorrect. (It saves the sample time on first execution).
> The other way around if you first generate a wave with 48000 Hz sample rate 
> the subroutine subtract will call gen_ft8wave with a sample frequency of 
> 12000 Hz and will receive an incorrect wave form.
> For now I fixed this by checking also the sample rate see the code snippet 
> below. My question is if this observation is correct?
> 
>  real f1
>  save pulse,twopi,dt,hmod,ibt0,ctab, f1
> 
>   ibt=nint(10*bt)
>   if(ibt0.ne.ibt .or. f1.ne.fsample) then
>  twopi=8.0*atan(1.0)
>  dt=1.0/fsample
>  hmod=1.0
> ! Compute the frequency-smoothing pulse
>  do i=1,3*nsps
> tt=(i-1.5*nsps)/real(nsps)
> pulse(i)=gfsk_pulse(bt,tt)
>  enddo
>  ibt0=nint(10*bt)
>  do i=0,NTAB-1
> phi=i*twopi/NTAB
> ctab(i)=cmplx(cos(phi),sin(phi))
>  enddo
>   endif
>   f1 = fsample
> 
> 73 PA0PHH
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsprd.c Subtracting Signals on the Final Pass

[Steven Franke via wsjt-devel]

Ryan,

See my comment, inline below:

> On May 9, 2023, at 11:19 AM, Tolboom, Ryan  wrote:
> 
> Good Morning,
> 
> First of all thank you for taking the time to explain the process. I
> know it can be exhausting and I greatly appreciate it.
> 
> Secondly, I'd point out that the noncoherent_sequence_detection
> function is called before  (line 1330) the subtract_signal2 function
> (line 1430) in the pass loop. This means that on the last pass the
> idat and qdat which were modified by subtract_signal2 are not used
> anywhere (except if you have to write a C2 file).

No. Look again and consider that the “pass” loop contains the “candidate” loop; 
i.e. in each pass we first identify the signal candidates (signals which are 
likely to decode) and then in the candidate processing loop we step over the 
candidates from highest to lowest SNR and try to decode each candidate. 

The routines noncoherent_sequence_detection and subtract_signal2 are inside of 
the candidate loop. The candidate loop starts at line 1304 and the closing 
brace for the loop is at line 1478. 

After each decode, subtract_signal2 modifies [idat,qdat] when it subtracts the 
decoded signal. Then, unless there are no more candidates, execution proceeds 
back to the top of the candidate loop so that when processing the next 
candidate noncoherent_sequence_detection will use the modified [idat,qdat].

Steve k9an

> Again, apologies if I'm mistaken.
> 
> 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.
>> 
>> K9AN DE N2LO~>
>> 
>> 
>>> On 05/09/2023 10:10 AM Steven Franke via wsjt-devel 
>>>  wrote:
>>> 
>>> 
>>> 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 algorithm 
>>> moves on to try to decode the next candidate.
>>> 
>>> Even on the last pass, subtraction of high-SNR signal “A” may remove enough 
>>> interference from low-SNR signal “B” so as to render signal “B” decodable 
>>> when signal “B” would not have been decodable otherwise.
>>> 
>>> You stated that “The updated I/Q data isn’t used as the loop doesn’t 
>>> execute again.”. This isn’t true. On each pass the [idat,qdat] vector is 
>>> updated in subtract_signal2 after each successful decode and the updated 
>>> [idat,qdat] vector is then used to find the bit metrics for subsequent 
>>> candidates in routine noncoherent_sequence_detection.
>>> 
>>> 73 Steve k9an
>>> 
>>>> On May 8, 2023, at 7:05 PM, Tolboom, Ryan via wsjt-devel 
>>>>  wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> When wsprd runs multiple passes, it still calls subtract_signal2() as
>>>> well as get_wspr_channel_signals() on the last pass.
>>>> The updated I/Q data isn't used as the loop doesn't execute again.
>>>> 
>>>> When I modified wsprd.c to skip subtraction on the last pass I noticed
>>>> better timing numbers (since subtract_signal2() is called one less
>>>> time) and no detriment to my decodes.
>>>> This was my change on line 1430 of wsprd.c
>>>> 
>>>>   if( subtraction && !noprint && (ipass != (npasses - 1))) {
>>>> 
>>>> Please let me know if there's something I'm not thinking of.
>>>> 
>>>> 73,
>>>> 
>>>> Ryan Tolboom N2BP
>>>> 
>>>> 
>>>> ___
>>>> wsjt-devel mailing list
>>>> wsjt-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>> 
>>> 
>>> 
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsprd.c Subtracting Signals on the Final Pass

[Steven Franke via wsjt-devel]

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 algorithm moves on to try 
to decode the next candidate.

Even on the last pass, subtraction of high-SNR signal “A” may remove enough 
interference from low-SNR signal “B” so as to render signal “B” decodable when 
signal “B” would not have been decodable otherwise.

You stated that “The updated I/Q data isn’t used as the loop doesn’t execute 
again.”. This isn’t true. On each pass the [idat,qdat] vector is updated in 
subtract_signal2 after each successful decode and the updated [idat,qdat] 
vector is then used to find the bit metrics for subsequent candidates in 
routine noncoherent_sequence_detection.

73 Steve k9an

> On May 8, 2023, at 7:05 PM, Tolboom, Ryan via wsjt-devel 
>  wrote:
> 
> Hello,
> 
> When wsprd runs multiple passes, it still calls subtract_signal2() as
> well as get_wspr_channel_signals() on the last pass.
> The updated I/Q data isn't used as the loop doesn't execute again.
> 
> When I modified wsprd.c to skip subtraction on the last pass I noticed
> better timing numbers (since subtract_signal2() is called one less
> time) and no detriment to my decodes.
> This was my change on line 1430 of wsprd.c
> 
>if( subtraction && !noprint && (ipass != (npasses - 1))) {
> 
> Please let me know if there's something I'm not thinking of.
> 
> 73,
> 
> Ryan Tolboom N2BP
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsprd.c Negative Index in Coarse Estimates Section

[Steven Franke via wsjt-devel]

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 search is negative for the first few iterations.
> It's set on line 1167:
> 
>kindex=k0+2*k;
> 
> Where k0 is iterating from -10 to 21 and k is iterating over all
> symbols (0 to 161).
> A negative index isn't common in C, but does compile without warning
> and I assume it references something earlier in the 2D ps array.
> If this is an oversight, you could add an additional guard to line 1168:
> 
>if(( kindex < nffts ) && ( kindex > 0)) {
> 
> I've tried this on my machine and it doesn't seem to affect the
> decodes in any negative way.
> Please let me know if there's something I'm missing.
> 
> 73,
> 
> Ryan Tolboom N2BP
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bugreport FST4W spot upload to wsprnet

[Steven Franke via wsjt-devel]

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 Mike
> 
> Thanks for posting it on the wsprnet forum.
> It seems that no one there could help with that either.
> 
> So it would be good if it could be changed in WSJT-X before the final release 
> of 2.6.0.
> 
> 
> 73
> Stefan
> 
> On 23.11.22 14:03, Black Michael via wsjt-devel wrote:
>> This was covered in the WSPRNET forum two years ago.  I added a question 
>> just now  about the new modes.
>> https://www.wsprnet.org/drupal/node/8500 
>> 
>> Going forward we will process the `mode` according to 4 values:
>>  * "2"
>>  * "15" for the current WSPR modes -2 & -15
>>  * "5
>>  * "30" for the FST4W modes 300 & 1800
>> Mike W9MDB
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v2.6.0-rc2 Reset Cabrillo log causes program to close

[Steven Franke via wsjt-devel]

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.cpp
> +++ b/widgets/mainwindow.cpp
> @@ -7320,7 +7320,7 @@ void MainWindow::on_reset_cabrillo_log_action_triggered 
> ()
>m_logBook.contest_log ()->reset ();
>m_activeCall.clear();  //Erase the QMap of active 
> calls
>m_score=0;
> -  m_ActiveStationsWidget->setScore(0);
> +  if (m_ActiveStationsWidget) m_ActiveStationsWidget->setScore(0);
>  }
>  }
> 
> Mike W9MDB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tuesday, August 2, 2022 at 11:40:13 AM CDT, Ari Hyvonen via wsjt-devel 
>  wrote: 
> 
> 
> 
> 
> 
> Hi,
> 
> Noticed that if I Reset Cabrillo log, that causes the program to close 
> without any error message. I had logging level as Info, nothing related to 
> this gets written to syslog.
> First I had some old qsos visible in contest log, after restart those were 
> gone, same happens also if contest log is empty and I select 'Reset Cabrillo 
> Log'
> 
> Windows 11, IC-9700
> 
> Regards,
> Ari, OH6DX
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Standalone jt9 doesn't find hashed callsigns in type 3 spots

[Steven Franke via wsjt-devel]

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. This trick 
decreases the size of the space that we have to search for codewords by many 
orders-of-magnitude in trade for giving up the ability to discriminate against 
false decodes that is normally provided by the CRC.  The fst4w_calls.txt file 
provides a memory of calls that have previously been decoded using the standard 
CRC-protected decoding method. This memory is used to reject false decodes 
whenever we use the CRCless decoding approach.

Note that the fst4w_calls.txt file is written to disk only when jt9 is called 
with the “-d 3” option.

The hash table that is used for resolving callsigns in the “type 3” messages is 
maintained internally in jt9 and is not written to disk.

Steve k9an

> On Jun 12, 2022, at 8:41 PM, Rob Robinett via wsjt-devel 
>  wrote:
> 
> Hi,
> 
> In version 3.0 of my wsprdaemon software for Linux systems 
> (http://wsprdaemon.org/ ) I am decoding FST4W by 
> running 'jt9 --fst4w ...'
> jt9 outputs spot lines for type 1 spots, but for a type 3 spot which follows 
> it in the next WSPR cycle jt9 always outputs the callsign '<...>'
> I can see that the file 'fst4w_calls.txt' is created when WSJT-x decodes 
> those same spots, and I suspect that file is used to look up the hashed calls 
> in a type 3 packet, but that file is never created when I run jt9 standalone 
> on Linux.
> The format of fst4w_calls.txt is simple and my code could create it for jt9, 
> but inspecting "fst4_decode.f90" with my limited familiarity with Fortan 
> suggests that jt9 will maintain that file in the same way "wprd" does its 
> hash table file.
> 
> So how can I get jt9 to resolve the hashed calls in type 3 FWT4W spots?
> 
> I now have 30 receive sites worldwide listening for FST4W spots 24/7/365, and 
> solving this hashed calls problem will complete their ability to report all 
> FST4W transmissions.
> 
> Thanks,
> 
> Rob
> 
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us 
> mobile: +1 650 218 8896
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] command line decoding of wav files containing FST4W signals

[Steven Franke via wsjt-devel]

Rob,

As I said in my earlier email, you need to specify the audio offset window 
using *either* upper or lower limits (using -L/-H) *or* center frequency and 
maximum offset (-f/-F). Your command line examples include redundant options.

For example, using -L/-H:

$ ./jt9 -W -d 3 -p 120 -L 1400 -H 1600 *.wav
0001 -30  0.0 1500 `  K9AN EN50 0 
   0   10

and an equivalent command using -f/-F:

$ ./jt9 -W -d 3 -p 120 -f 1500 -F 100 *.wav
0001 -30  0.0 1500 `  K9AN EN50 0 
   0   10

Steve k9an

> On Oct 2, 2021, at 6:05 PM, Rob Robinett  wrote:
> 
> Hi Steve,
> 
> With Bill's guidance I was able to get a working set of command line flags.
> I could use an explanation of some of the fields in the spot line output by 
> jt9.
> 
> thanks,
> 
> rob
> 
> rob@Robs-MBP:/Users/rob/jt9> /Applications/wsjtx.app/Contents/MacOS/jt9  -W 
> -p 120 -L 1400 -H 1600 -f 1500 -F 100  -d 3  20211002T035000Z_474200_usb.wav 
> 20211002T035100Z_474200_usb.wav
>  EOF on input file 20211002T035000Z_474200_usb.wav
>   27  0.4 1590 `  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 Sat, Oct 2, 2021 at 10:20 AM Steven Franke via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net>> 
> wrote:
> 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 
>> mailto:wsjt-devel@lists.sourceforge.net>> 
>> wrote:
>> 
>> Hello,
>> 
>> I am trying to add FST4W support to version 3.0 of my wspedaemon service 
>> (https://github.com/rrobinett/wsprdaemon 
>> <https://github.com/rrobinett/wsprdaemon> ) run by many of the top spotting 
>> sites worldwide. My goal is to encourage the adoption of FST4W by enabling 
>> dozens of sites worldwide to start listening for FST4W on all the 
>> appropriate bands 24/7/365, just as they currently do for WSPR transmissions.
>> 
>> For WSPR decoding I execute the 'wsprd' binary from the WSJT-x 2.5.0 giving 
>> it a 2 minute long wav file, e.g.:/usr/bin/wsprd -c -C 500 -o 4 -d -f 
>> 1.8366 211002_1450.wav
>> 
>> However when I execute a similar jt9 command on a wav file from which WSJT-x 
>> displays signals, I get no spots:   
>> 
>> /usr/bin/jt9  -p 120 -W 211002_0350.wav
>>0   00
>> 
>> I can see that a successful decode by WSJT-x of that file runs jt9 through a 
>> shared memory interface, but that would be awkward to use in my SW 
>> environment.
>> Ideally, I would like to give jt9 a list of 2 or more one minute long wav 
>> files which would optimize the use of disk space when attempting to decode 
>> all of the FST4W modes.
>> 
>> Thanks for any help.  73
>> 
>> Rob
>> 
>> -- 
>> Rob Robinett
>> AI6VN
>> r...@robinett.us <mailto:r...@robinett.us>
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
>> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
> 
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us <mailto:r...@robinett.us>
> mobile: +1 650 218 8896

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] command line decoding of wav files containing FST4W signals

[Steven Franke via wsjt-devel]

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 version 3.0 of my wspedaemon service 
> (https://github.com/rrobinett/wsprdaemon 
>  ) run by many of the top spotting 
> sites worldwide. My goal is to encourage the adoption of FST4W by enabling 
> dozens of sites worldwide to start listening for FST4W on all the appropriate 
> bands 24/7/365, just as they currently do for WSPR transmissions.
> 
> For WSPR decoding I execute the 'wsprd' binary from the WSJT-x 2.5.0 giving 
> it a 2 minute long wav file, e.g.:/usr/bin/wsprd -c -C 500 -o 4 -d -f 
> 1.8366 211002_1450.wav
> 
> However when I execute a similar jt9 command on a wav file from which WSJT-x 
> displays signals, I get no spots:   
> 
> /usr/bin/jt9  -p 120 -W 211002_0350.wav
>0   00
> 
> I can see that a successful decode by WSJT-x of that file runs jt9 through a 
> shared memory interface, but that would be awkward to use in my SW 
> environment.
> Ideally, I would like to give jt9 a list of 2 or more one minute long wav 
> files which would optimize the use of disk space when attempting to decode 
> all of the FST4W modes.
> 
> Thanks for any help.  73
> 
> Rob
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign hashing issue FST4

[Steven Franke via wsjt-devel]

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 the hashing in that 
instance. Can you give me a sequence of steps that will reproduce the issue 
using a saved .wav file?

73 Steve k9an

> On May 13, 2021, at 6:50 AM, Eric NO3M  wrote:
> 
> Possibly a bug in callsign hashing (FST4), see QSO messages below from two 
> different instances of WSJT-X (one pulled from ALL.TXT):
> 
> 0449  32  0.1 1241 `   NO3M -26
> 0450 -24  0.1 1223 `  NO3M  R-18 
> 0451  33  0.1 1241 `  W0SD/0  RR73 
> 0452 -22  0.1 1224 `   W0SD/0 73
> 
> 
> 210513_044900 0.474 Tx FST4 0  0.0 1241  NO3M -26
> 210513_045000 0.474 Rx FST4   -24  0.1 1223 NO3M  R-18
> 210513_045100 0.474 Tx FST4 0  0.0 1241 W0SD/0  RR73   <-- 
> interestingly, this one resolved
> 210513_045200 0.474 Rx FST4   -22  0.1 1224 <8Q3BGF/R> W0SD/0 73
> 
> N9RU also reported seeing this behavior, with his callsign being hashed and 
> unrecognizable from his own running instance of WSJT-X:
> 
> 0924 -21 0.1 1223 ` <3RXMO/OOL40> W0SD/0 73
> 
> but his call resolved fine on my running instances:
> 
> 0924 -15  0.0 1224 `   W0SD/0 73
> 
> My assumption was that only the compound call is hashed, but on any '73' or 
> 'RR73' message, the "other" (ie. non-compound call) is being hashed, 
> unresolvable to instances where the hashed call is the same as the station 
> callsign setting but resolvable in other instances where the station call is 
> not that of the hashed callsign.
> 
> - Eric NO3M
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC2 Report on MacOS 10.14.6 Mojave - Q65_Sync

[Steven Franke via wsjt-devel]

John, 

The file that Bill sent to you should be placed in the ~/Library/Preferences 
folder. This is the folder that your existing WSJT-X.ini file is located in. 
You should be able to open the ~/Library/Preferences folder and simply grab the 
attachment that Bill sent and drag it into that folder. When you are done you 
should see both WSJT-X.ini and wsjtx_log_config.ini next to (or near) each 
other in the list of files in that folder.

73 Steve k9an

> On Mar 6, 2021, at 9:43 AM, John Stengrevics  wrote:
> 
> Hi Steve,
> 
> Thanks for that.  
> 
> I have followed 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 10:27 AM, Steven Franke via wsjt-devel 
>> mailto:wsjt-devel@lists.sourceforge.net>> 
>> wrote:
>> 
>> 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 folder will always be visible.
>> 
>> 73 Steve k9an
>> 
>>> On Mar 6, 2021, at 8:36 AM, John Stengrevics >> <mailto:jstengrev...@comcast.net>> wrote:
>>> 
>>> Hi Bill,
>>> 
>>> I can’t find the ~/Library/Preferences/ directory in which to put the file. 
>>>  Can you provide a bit more detail on how I can locate it?  Sorry.
>>> 
>>> John
>>> WA1EAZ
>>> 
>>>> On Mar 6, 2021, at 9:20 AM, Bill Somerville >>> <mailto:g4...@classdesign.com>> wrote:
>>>> 
>>>> Hi John,
>>>> 
>>>> so I can see what is happening put the attached file into the WSJT-X 
>>>> configuration files directory (~/Library/Preferences/ on macOS), restart 
>>>> WSJT-X, run a minimal test to demonstrate the issue, then quit WSJT-X (do 
>>>> not turn off the rig until WSJT-X has exited). There will be a new file on 
>>>> your Desktop called WSJT-X_RigControl.log, send me that file for analysis 
>>>> please (g4wjs  classdesign  com)?
>>>> 
>>>> Once you have sent me the log file delete the wsjtx_log_config.ini and 
>>>> WSJT-X_RigControl.log files to resume normal operation.
>>>> 
>>>> 73
>>>> Bill
>>>> G4WJS.
>>>> 
>>>> On 06/03/2021 14:13, John Stengrevics wrote:
>>>>> Bill,
>>>>> 
>>>>> I have CAT selected and it does connect when I click on Test.
>>>>> 
>>>>> John (G4KLA) had asked what driver I was using.  I replied that the 
>>>>> driver had not changed.  It has always been  /dev/cu.usbserial-A503XYAO.
>>>>> 
>>>>> John
>>>>> WA1EAZ
>>>>> 
>>>>>> On Mar 6, 2021, at 9:07 AM, Bill Somerville >>>>> <mailto:g4...@classdesign.com>> wrote:
>>>>>> 
>>>>>> Hi John,
>>>>>> 
>>>>>> which option do you have checked for "Preferences->Radio->PTT Method"?
>>>>>> 
>>>>>> 73
>>>>>> Bill
>>>>>> G4WJS.
>>>>>> 
>>>>>> On 06/03/2021 14:03, John Stengrevics wrote:
>>>>>>> Hi Bill,
>>>>>>> 
>>>>>>> I just tried to use Q65 with “Cumulative" selected as you suggested.  
>>>>>>> However, the problem is still there as described below.  I have to shut 
>>>>>>> down my transceiver (Elecraft K3S) to get it to stop transmitting.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> John
>>>>>>> WA1EAZ
>>>>>>> 
>>>>>>>> On Mar 6, 2021, at 8:44 AM, Bill Somerville >>>>>>> <mailto:g4...@classdesign.com>> wrote:
>>>>>>>> 
>>>>>>>> Hi John,
>>>>>>>> 
>>>>>>>> I am not sure as I have not investigated this issue yet. It is easy 
>>>>>>>> enough to check, select "Cumulative" for the 2D spectrum display, 
>>>>>>>> restart WSJT-X, and see 

Re: [wsjt-devel] RC2 Report on MacOS 10.14.6 Mojave - Q65_Sync

[Steven Franke via wsjt-devel]

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 folder will always be visible.

73 Steve k9an

> On Mar 6, 2021, at 8:36 AM, John Stengrevics  wrote:
> 
> Hi Bill,
> 
> I can’t find the ~/Library/Preferences/ directory in which to put the file.  
> Can you provide a bit more detail on how I can locate it?  Sorry.
> 
> John
> WA1EAZ
> 
>> On Mar 6, 2021, at 9:20 AM, Bill Somerville > > wrote:
>> 
>> Hi John,
>> 
>> so I can see what is happening put the attached file into the WSJT-X 
>> configuration files directory (~/Library/Preferences/ on macOS), restart 
>> WSJT-X, run a minimal test to demonstrate the issue, then quit WSJT-X (do 
>> not turn off the rig until WSJT-X has exited). There will be a new file on 
>> your Desktop called WSJT-X_RigControl.log, send me that file for analysis 
>> please (g4wjs  classdesign  com)?
>> 
>> Once you have sent me the log file delete the wsjtx_log_config.ini and 
>> WSJT-X_RigControl.log files to resume normal operation.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> On 06/03/2021 14:13, John Stengrevics wrote:
>>> Bill,
>>> 
>>> I have CAT selected and it does connect when I click on Test.
>>> 
>>> John (G4KLA) had asked what driver I was using.  I replied that the driver 
>>> had not changed.  It has always been  /dev/cu.usbserial-A503XYAO.
>>> 
>>> John
>>> WA1EAZ
>>> 
 On Mar 6, 2021, at 9:07 AM, Bill Somerville >>> > wrote:
 
 Hi John,
 
 which option do you have checked for "Preferences->Radio->PTT Method"?
 
 73
 Bill
 G4WJS.
 
 On 06/03/2021 14:03, John Stengrevics wrote:
> Hi Bill,
> 
> I just tried to use Q65 with “Cumulative" selected as you suggested.  
> However, the problem is still there as described below.  I have to shut 
> down my transceiver (Elecraft K3S) to get it to stop transmitting.
> 
> Thanks,
> 
> John
> WA1EAZ
> 
>> On Mar 6, 2021, at 8:44 AM, Bill Somerville > > wrote:
>> 
>> Hi John,
>> 
>> I am not sure as I have not investigated this issue yet. It is easy 
>> enough to check, select "Cumulative" for the 2D spectrum display, 
>> restart WSJT-X, and see if the iusse goes away.
>> 
>> 73
>> Bill
>> G4WJS.
>> 
>> On 06/03/2021 13:25, John Stengrevics wrote:
>>> Hi Bill,
>>> 
>>> Will this fix solve the problem I reported yesterday with OS Big Sur?  
>>> I’ll repost below in case you didn’t see it.
>>> 
>>> Thanks,
>>> 
>>> John
>>> WA1EAZ
>>> 
>>> Repost - some additions in red:  
>>> 
>>> John & Joe,
>>> 
>>> I had been using the previous version successfully on a MacBook Pro 
>>> (Intel not M1) OS Big Sur 11.2.2.
>>> 
>>> Today, I downloaded Mac version 2.4.0-rc2.  
>>> 
>>> When running Q65, T/R = 30 seconds, Submode A, the program continues to 
>>> transmit after the 30 second period is complete for 60 seconds total.  
>>> However, it does not seem to drive my amplifier after 30 seconds. [PTT 
>>> is activated for the second 30 seconds, but no audio to drive the amp.] 
>>>  I have since tried FT8 on WSJT-X and can confirm that it works as 
>>> usual.  Thus, the problem seems to be isolated to Q65.
>>> 
>>> I did follow the instructions in the Readme file.  
>>> 
>>> If there is a file I can send you, please let me know.
>>> 
>>> I would appreciate any suggestions you can provide.
>>> 
>>> Best 73,
>>> 
>>> John
>>> WA1EAZ
>>> 
 On Mar 6, 2021, at 5:55 AM, Bill Somerville >>> > wrote:
 
 Hi Dave and Kevin,
 
 we have finally tracked down the cause of this crash, thanks for your 
 patience it was not so easy to track down. It is repaired for the next 
 release, for now if you do not use of the Q65_Sync Wide Graph 
 synchronization plot the crash will be avoided. Note this is not a Mac 
 specific issue although it does seem to have the most severe effects 
 on that platform.
 
 73
 Bill
 G4WJS.
 
 On 06/03/2021 03:59, David Schmocker wrote:
> Hello all,
> 
> A second report that mirrors this one:WSJT-X 2.4.0rc2
> 
> OS 10.14.6,  Mac Mini
> 
> Mode Q65,Waterfall Q65_ Sync selected and slow to let go of PTT 
> line to K3S radio (even after Tx period).   (when I go into Radio 
> Panel, the Test PTT Red bar stays on, won't easily release).
> 
> Then when a decode should take place,

Re: [wsjt-devel] FST4 Decode Bandwidth

[Steven Franke via wsjt-devel]

> 
> 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)?

Jim,

No. You would need to run separate instances of WSJT-X, one for each message 
duration that you want to monitor. For example, on 2190m (LF) I routinely run 
separate instances to monitor FST4W-1800, FST4W-300, and FST4W-120. You might 
find that the “SWL” view (under the “View” menu) is useful when running 
multiple instances for monitoring purposes.

Steve k9an



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FST4 Decode Bandwidth

[Steven Franke via wsjt-devel]

> 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 search window. To first order, these controls 
do not affect the candidate detection threshold, so a very weak signal should 
be detected regardless of the size of the search window in which it is located.

Increasing or decreasing the width of the search window will increase/decrease 
the number of spurious candidates, so a larger search window means longer total 
decoding time and higher false decode rate. That’s why we advise users to 
narrow the search window to the smallest width that makes sense for the 
purpose. 

73 Steve, k9an

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.3.0-rc3 Time Shift

[Steven Franke via wsjt-devel]

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 running just wsjtx.
> Takes several days of continuous operation before DT jumps up suddenly to 6+ 
> seconds.
> Fedora Core 32 Linux, 64-bit.
> 
> 210116 1218 -12 -0.19  14.0971780  MM1BTJ IO75 37
> 210116 1218 -15  0.02  14.0972055  ON4LUK JO11 23
> 210116 1220 -10  6.13  14.0970137  PA3CQE JO21 27
> 210116 1220  -9  6.17  14.0970168  M0OLS IO81 23
> 210116 1220 -17  5.91  14.0970337  8P9HA GK03 20
> 210116 1220 -24  6.00  14.0970435  G0BZB IO94 20
> 210116 1220  -9  6.00  14.0970654  G1CPC IO91 37
> 210116 1220   0  6.04  14.0970667  OZ7IT JO65 37
> 210116 1220  -7  6.00  14.0970735  DK1BL JO31 33
> 210116 1220  -5  6.08  14.0970768  MW0GRJ IO83 37
> 210116 1220  -1  6.04  14.0970943  DG4EU JO31 30
> 
> -- 
> P.J. "Josh" Rovero http://www.roveroresearch.org 
>   
> Ham Radio: KK1D
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X decode performance on 2.2.x

[Steven Franke via wsjt-devel]

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 
> figured out how to edit e-mails and the subject line when responding on this 
> forum … not new to WSJT-X, but new to formatting responses on this forum.
>  
> As a reminder, this is on a RigPi (3B+) connected via USB to a FT-991 working 
> FT-8.  On the RigPi, my typical DT values for transmissions that I think have 
> well set clocks are 0.0 to 0.3.  I see this using 2.1.2 and 2.2.1.  This 
> seems pretty steady for lots of decodes on a busy band or light bands. 
>  
> On 2.2.1, I see just a very few decodes in the first decode pass of the 
> cycle, a quick flash on the decode button on the second (which makes sense 
> from what was described in this thread as happening in that cycle) and then 
> very many in a long, third pass that runs well into the next cycle.  All of 
> this is seen in the FAST decode mode on 2.2.1.  On 2.1.2, in the FAST decode 
> setting, I get many decodes which are complete by a second or two into the 
> next cycle.
>  
> I did go back and look at the RigPi behavior on 2.1.2 on NORMAL and DEEP.  
> The RigPi does take a fair amount of time to decode a busy band into the next 
> cycle for those settings, but as mentioned, it works just fine using FAST.  
> So I understand the compute resource issue with the RigPi, and know it is not 
> as good a device for NORMAL or DEEP as then FT8 bands have become more 
> crowded.  What I don’t understand is why with FAST the 2.2.1 decoder has 
> slowed so much.
>  
> I have also set-up 2.2.1 on a Mac-Mini … older, but a lot more robust than a 
> RigPi.  That system decodes in FAST, NORMAL, and DEEP with a performance I 
> would expect (2.4 Ghz Intel, cached HD).  As you probably already know, the 
> RigPi is something like a 1.4Ghz ARM.
>  
> So I know a hardware upgrade will fix my issue, but still wondering what 
> happened to FAST decode that used to work on the RigPi.
>  
> ’73 - Tony
>  
>  Prior message in thread ---
>  
> Message: 2
> Date: Tue, 9 Jun 2020 08:39:08 -0500
> From: Steven Franke 
> To: WSJT software development 
> Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 76, Issue 93
> Message-ID: <0db596ba-cb5d-4292-af2e-c3aeff637...@icloud.com>
> Content-Type: text/plain; charset="us-ascii"
>  
> 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 are your typical DT values, i.e. what is the median DT value for a cycle 
> that has a good number of decodes?  Normally, we expect to see the bulk of 
> the decodes produced by the first decoding segment (say, 80%) and only a 
> small number of decodes produced during the third segment. However, if there 
> is significant receiver latency, this can push most of the decodes into the 
> third segment.
>  
> FWIW, no decoding is done during the second decode segment. This segment is 
> used to subtract all of the decodes that were obtained during the first 
> segment.
>  
> Steve k9an
>  
>  
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X V2.2.1 wsprd decode performance report + recommended wsprd command line flags

[Steven Franke via wsjt-devel]

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 virtually eliminated false decodes from the 
Fano decoder which, in turn, results in a much cleaner hashtable.txt file. 
Almost all of the very small number of good decodes that are obtained with your 
more aggressive setting "-C 5000" that are not obtained with “-C 500” end up 
being picked up by the OSD algorithm anyway.

In addition to a cleaner hashtable.txt, v2.2 includes the decoded grid square 
in the hashtable. This is used to validate decodes produced by the OSD 
algorithm.  This largely eliminates the false decodes with valid callsigns and 
incorrect grids that were occasionally produced by v2.1.2.

73 Steve k9an

> On Jun 11, 2020, at 3:49 PM, Rob Robinett  wrote:
> 
> With the release of the enhanced wsprd decoder, I have published version 2.9g 
> of my  'wsprdaemon' system (http://wsprdaemon.org/)  and upgraded some of the 
> 25+ WD sites to run it.
> 
> In addition to running wsprd 2.2.1, wsprdaemon can run both that new wsprd 
> and old wsprd 2.1.x and compare the number of spots extracted by them from 
> the same 2 minute wav file.
> Unfortunately, the Raspberry Pi4 at worldwide top spotter OE9GHV doesn't have 
> quite enough CPU power to execute both wsprds (i.e. complete execution of 48 
> wsprds in one 2 minute wspr cycle) on all of the 24 antenna+band receive 
> channels at that site.
> 
> However at US top spotter KD2OM the i86 CPU running WD has no problem 
> performing the 66 decodes required to document the decode performance on the 
> 33 antenna+channels at that site
> You can see in the following table of spots decoded in the last 16 hours at 
> KD2OM, that the 20M DI (dipole) antenna channel decoded almost 6% more spots 
> using the new wsprd, while on other bands the difference is in the range of 
> 2.5-4.5%.
> 
> So my question is:  would a change to the flags passed to the new wsprd 
> further enhance decode performance, even if it costs more CPU time?
> I am currently passing the same flags and values to 2.2.1 as I do to 2.1.1, 
> e.g. /usr/bin/wsprd -c -C 5000 -o 4 -f 14.0956 200611_2036.wav
> During the transition from 2.0.x to 2.1.x Steve suggested adding '-o 4'.  
> Would the performance of the 2.2.1 wsprd benefit from a similar change?
> 
> Thanks,
> 
> Rob
> 
> 
> plex@Plexserver:~$ show-spots
> BAND ANT NEW_WSPRD OLD_WSPR
>   10  BE9 new9 old   0.00%
>   10  DI   21 new   20 old   5.00%
>   10  VE4 new4 old   0.00%
>   12  BE1 new1 old   0.00%
>   12  DI5 new5 old   0.00%
>   15  BE   91 new   91 old   0.00%
>   15  DI  124 new  122 old   1.64%
>   15  VE   95 new   95 old   0.00%
>   17  BE   95 new   95 old   0.00%
>   17  DI  416 new  413 old   0.73%
>   17  VE  120 new  119 old   0.84%
>   20  BE 1992 new 1953 old   2.00%
>   20  DI 4304 new 4073 old   5.67%
>   20  VE 2351 new 2297 old   2.35%
>   30  BE 1563 new 1514 old   3.24%
>   30  DI 2968 new 2874 old   3.27%
>   30  VE 1853 new 1812 old   2.26%
>   40  BE 3126 new 3048 old   2.56%
>   40  DI 3625 new 3555 old   1.97%
>   40  VE 2758 new 2700 old   2.15%
>   60  BE6 new5 old   20.00%
>   60  DI0 new0 old   -nan%
> 60eu  BE8 new7 old   14.29%
> 60eu  DI2 new2 old   0.00%
>   80  BE  296 new  283 old   4.59%
>   80  DI  523 new  505 old   3.56%
> 80eu  BE   85 new   83 old   2.41%
> 80eu  DI  104 new  104 old   0.00%
>  160  BE  211 new  192 old   9.90%
>  160  DI  242 new  240 old   0.83%
>  630  BE  108 new  101 old   6.93%
>  630  DI   25 new   25 old   0.00%
> 2200  BE   17 new   14 old   21.43%
> plex@Plexserver:~$
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us
> mobile: +1 650 218 8896
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-devel Digest, Vol 76, Issue 93

[Steven Franke via wsjt-devel]

> 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 diff
diff --git a/lib/ft8/gen_ft8wave.f90 b/lib/ft8/gen_ft8wave.f90
index 02e7fdbd..9e277375 100644
--- a/lib/ft8/gen_ft8wave.f90
+++ b/lib/ft8/gen_ft8wave.f90
@@ -45,7 +45,7 @@ subroutine 
gen_ft8wave(itone,nsym,nsps,bt,fsample,f0,cwave,wave,icmplx,nwave)
! Calculate and insert the audio waveform
  phi=0.0
  dphi = dphi + twopi*f0*dt  !Shift frequency up by f0
-  wave=0.
+  if(icmplx .eq. 0) wave=0.
  if(icmplx .ne. 0) cwave=0. !Avoid writing to memory we may not have access to

  call timer('gen_loop',0)

Steve k9an




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] How can I determine the version number of the installed 'wsprd' from the Linux command line?

[Steven Franke via wsjt-devel]

> 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.
>> 
>> wsprd 2.1.x  added '-o ...' to the help printout, but there is no such 
>> difference between 2.1.x and 2.2.x.
>> 
>> Other than looking at the size of /usr/bin/wsprd, is there a more reliable 
>> way to determine which version is installed?
>> 
>> Thanks,
>> 
>> Rob
>> 
>> -- 
>> Rob Robinett
>> AI6VN
> Hi Rob,
> 
> there's not much to help you. The ALL_WSPR.TXT file has extra columns since 
> WSJT-X v2.2.0.
> 
> 73
> Bill
> G4WJS.
> 

Hi Rob and all,

FYI, here is a summary of the current format of the ALL_WSPR.TXT file as of 
v2.2.0 (the table should be viewed with a fixed-width font):

Sample lines from the ALL_WSPR.TXT file:

yymmdd hhmm snr   dt   frequency   22 character message12   3  45  
6   7 8 9
-
180909 1630 -21  0.11  14.0971248  W6IPA CM97 20   0  0.29  2  10  
0   9 1   433
180909 1630 -10  0.02  14.0971298  PA0MLC JO31 37  0  0.59  1  10  
0   5 1   571
180909 1630 -15  1.39  14.0971346  AA7NM CN86 37  -4  0.47  2  10  
0   5 1   522
180909 1630  -9  0.24  14.0971593  LA3JJ JO59 37   0  0.26  3  1  -16  
0  15   406   -78
180909 1630  -3  0.19  14.0971755  G0CCL JO02 37   0  0.65  1  10  
0   2 1   602
180909 1630 -28  0.11  14.0971990  ON4LUK JO11 23  0  0.19  1  10  
0  29   421   -89

Field descriptions:

1. drift in Hz over the duration of the WSPR message
2. sync value [0,1.0]
3. decoding pass {1,2,3}
4. block size, in symbols, used for symbol detection, {1,2,3}
5. dt jitter in samples [-64,64] (multiples of 8 samples)
6. 0 if the decode was obtained by the Fano decoder, 1 if obtained by OSD
7. number of bit errors in the received message
8. Fano iterations-per-bit [1,max_iterations]
9. Fano cumulative metric [-999,810]

Example - consider the 4’th message in the ALL_WSPR.TXT lines given above. The 
message “LA3JJ JO59 37” was decoded on the 3rd decoding pass. The sync value 
was 0.26, and the decode was obtained based on single-symbol detection, with a 
dt jitter of -16 samples. Note that dt offsets are tried in the order 0, -8, 8, 
-16, 16, -24, 24, etc. up to maximum offsets of +/- 64 samples.  Thus, in this 
example we can infer that decodes were attempted at dt offsets of 0, -8, 8 
samples before a successful decode was finally obtained at an offset of -16 
samples. Finally, fields 6 through 9 tell us that the decode was obtained from 
the Fano decoder, there were 15 hard bit errors (i.e. sign errors in the soft 
bit metrics), the Fano decoder required 406 iterations per bit, and the 
cumulative Fano metric was -78. 

I hope that this information will be useful to WSPR enthusiasts.

73, Steve k9an
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-devel Digest, Vol 76, Issue 93

[Steven Franke via wsjt-devel]

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 are your typical DT values, i.e. what is the median DT value for a cycle 
that has a good number of decodes?  Normally, we expect to see the bulk of the 
decodes produced by the first decoding segment (say, 80%) and only a small 
number of decodes produced during the third segment. However, if there is 
significant receiver latency, this can push most of the decodes into the third 
segment. 

FWIW, no decoding is done during the second decode segment. This segment is 
used to subtract all of the decodes that were obtained during the first segment.

Steve k9an


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Erros software

[Steven Franke via wsjt-devel]

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  wrote:
> 
> 
> 
> -- Forwarded message -
> De: Cesar Martinez mailto:cmanzueta2...@gmail.com>>
> Date: mar., 31 dic. 2019 a las 7:53
> Subject: Re: Error software
> 
>  Hi, this is the error
> 
> Happy new year 
>  
> 
> 
> 
>  
> 
> 
>  
> 
> On Tue, Dec 31, 2019 at 4:11 AM Cesar Martinez  > wrote:
> Hello, my name is Cesar Martinez HI3CMM, I have this problem,
> I don't know how to solve it. Install the new version and keep giving the 
> same error. 
> It is annoying and the sequence is lost.
> 
> Thank you.
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Erros software

[Steven Franke via wsjt-devel]

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 produce the error. 

In the meantime, I suggest that you un-check Flatten on the wide graph. When 
you do that, I think that you’ll see a steep rolloff on the high end of the 
wide-graph spectrum, caused by your receiver filters. You may be able to 
eliminate the error by decreasing the upper frequency limit that is displayed 
on the wide graph. You can do this by using the mouse to move the right edge of 
the wide graph to the left and/or by decreasing the Bins/Pixel setting to, say, 
5 instead of 6. Your goal is to adjust the wide graph so that only the main 
passband of your receiver filter is displayed, and not the steep rolloff 
regions on the low and high sides of the passband.

73 Steve k9an

> On Dec 30, 2019, at 9:11 PM, Cesar Martinez  wrote:
> 
> Hello, my name is Cesar Martinez HI3CMM, I have this problem,
> I don't know how to solve it. Install the new version and keep giving the 
> same error. 
> It is annoying and the sequence is lost.
> 
> Thank you.
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 3 passes??

[Steven Franke via wsjt-devel]

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 pass).

> jt9 -d 3 -8 191226_165400.wav
> 165400 -13  0.1  377 ~  SRY NO DECODE1st decode of pass 1
> 165400   4 -0.7  468 ~  F4DXX VA2PV -24
> 165400  -8  0.1  547 ~  CQ N5CHA EM12
> 165400 -21  0.2  663 ~  AJ8B CT7AGM RR73
> 165400   4  0.2  747 ~  CQ AA5N FN54
> 165400 -12  0.2  876 ~  W1VB VA7ME 73
> 165400   1  0.1 1057 ~  TF3VS VE2THQ -19
> 165400  -8  0.2 1267 ~  AE1N AA7EW R-15
> 165400   4  0.1 1487 ~  CQ KK7X DN17
> 165400  -1  0.7 1600 ~  K1HZ WA6LAU R-10
> 165400 -18  0.1 1732 ~  CQ GM2TT IO75 a1
> 165400 -13 -0.1 1849 ~  W5BR KV4AA EN41
> 165400 -20  0.1 1907 ~  HK4L KO8V 73
> 165400 -17  0.2 2315 ~  YC1MRF PJ2LJG -13
> 165400  17  0.1 2709 ~  KC1CS/IMAGE
> 165400   0  1.1 1496 ~  VE2GCE W4LCM R-191st decode of pass 2, candidate 
> within 10 Hz of Rx freq
> 165400 -23  0.2  525 ~  K3LAB M0BEW -11 2nd decode of pass 2
> 165400 -24  0.5  621 ~  N2CAR MM0JTV -07
> 165400 -19  0.2  693 ~  NU7K KG5GFV -18
> 165400 -12  0.9  792 ~  CQ KA7ICF DN22
> 165400  -3  0.1 1037 ~  CQ N6NII EN35
> 165400 -18  0.1 1231 ~  CQ CU3HN HM68
> 165400 -15  0.1 1400 ~  VE2BTZ KW2E +01
> 165400 -10  0.1 1552 ~  AA7CT EA5ET RR73
> 165400 -12  0.1 1502 ~  CQ N1UL EL95   1st decode of pass 3, 
> candidate within 10 Hz of Rx freq
> 165400 -16  0.6  780 ~  CQ EA1FCF IN82a1   2nd decode 
> of pass 3
> 165400  -8 -0.7 1016 ~  HC3AGT K3CKO FN12
> 165400  -7  0.1 1600 ~  W5BR KC5RHQ EM20
>0  28


Steve k9an___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 3 passes??

[Steven Franke via wsjt-devel]

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 at the top of the list.
2. try to sync each candidate and, if successful, attempt to decode multiple 
times using different methods for symbol detection and using different amounts 
of a priori (AP) info, depending on the current state of the QSO progress 
indicator
3. for each successful decode, subtract the signal from the audio waveform 
before attempting to decode the next candidate on the list.

Your screenshot shows that your rx frequency was set to something near 1824 Hz 
offset, and that successful decodes were obtained on the first two passes. No 
decodes were obtained on the third pass in the example that you provided.

73 Steve k9an
> On Dec 26, 2019, at 9:06 AM, Bill Somerville  wrote:
> 
> Mike,
> 
> I don't see any evidence of a 4th decoding pass in the list of decodes you 
> provided in your OP. What makes you think there is such a pass?
> 
> I see a single decode at 1824 Hz which I assume is at or very near you 
> currently set Rx audio offset, I see 24 decodes in ascending frequency offset 
> followed by another 4 from the final pass, again in ascending frequency 
> offset order.
> 
> Decodes are processed sequentially, there is no "still being worked on". AP 
> decodes, if enabled, will be tried if the non-AP decoding attempts have 
> failed to produce a decode for a candidate, before moving on to the next 
> candidate in a decoding pass.
> 
> 73
> Bill
> G4WJS.
> 
> On 26/12/2019 14:56, Black Michael via wsjt-devel wrote:
>> OK...let's call it 4-pass thenI wasn't including the rx offset as pass#1.
>> 
>> I didn't think anything was happening after what you're calling the 3rd pass 
>> occurs...but 3 more decodes show up.
>> So that's the AP or some decodes are still being worked on after the 3rd 
>> pass?
>> 
>> Mike
>> 
>> 
>> On Thursday, December 26, 2019, 08:50:50 AM CST, Bill Somerville 
>>   wrote:
>> 
>> 
>> On 26/12/2019 14:36, Black Michael via wsjt-devel wrote:
>> 
>> > Is there a 3-pass going on now in 2.1.2?
>> > I'm seeing 3 passes from the decodes.
>> > de Mike W9MDB
>> 
>> Mike,
>> 
>> 
>> this is nothing new. The first decode attempt is at the Rx audio offset, 
>> then another across the passband, and a third after subtracting 
>> facsimiles of the decodes so far. There are also different decoding 
>> strategies attempted on each candidate signal depending on the decoding 
>> depth settings and whether AP decoding is enabled, at least until a 
>> successful decode is achieved for each candidate.
>> 
>> 73
>> Bill
>> G4WJS.
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator

[Steven Franke via wsjt-devel]

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 separately on MacOS. In both cases 
I find that all decodes are written to ALL.TXT while running in Fox mode. I 
tested this in two ways: (i) running as Fox in monitor mode while tuned to 
14.074 MHz and (ii) using two instances of WSJT-X, one Fox and one Hound, and 
connecting the two instances using a loopback connection. This second loopback 
setup was used so that I could run as Fox while transmitting CQs every other 
sequence. In both cases, all of the Fox’s decodes were written to ALL.TXT, 
whether the decode was addressed to Fox or not.

73
Steve, k9an

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 Frequency on 40-m

[Steven Franke via wsjt-devel]

Paul,

I don’t know the answer to your question(s).

In addition to frequency separation and signal strength difference, one would 
have to consider overall signal strength (not just difference), the DT 
difference between the two signals, and the delay and Doppler spread on each of 
the two channels that are involved. There are too many dimensions in that 
parameter space!  

Steve k9an

> On Jul 28, 2019, at 8:06 PM, Paul Kube  wrote:
> 
> Steve --
> 
> Related to this, and to another recent thread on replying to CQ's on the 
> caller's frequency: 
> 
> What is the decoding probability a FT8 (or FT4) signal when being interfered 
> with by another FT8 (or FT4) signal, as a function of frequency separation 
> and signal strength difference? Seems clear that it would not be appropriate 
> to model the interfering signal as additive Gaussian noise, 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:
> 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 channels with severe Doppler spreading, the threshold SNR is higher for 
> both modes, and the difference between FT8 and FT4 will decrease somewhat 
> because FT4’s larger tone separation tends to give it an advantage in those 
> cases.
> 
> It might be of interest to some to consider that FT8 uses symbols with 
> duration 160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms 
> to send 2 bits apiece. For a given average transmitter power, the energy that 
> is transmitted per bit for FT8 is larger than the energy transmitted per bit 
> for FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical 
> sensitivity difference (ignoring any differences in signal detection, 
> synchronization or LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB, 
> very close to the actual difference of 3.3 dB that I quoted above.
> 
> I have no strong feelings one way or the other about your main point, but I 
> think that it’s preferable to base the discussion on accurate numbers.
> 
>> 
>> FT4 is awesome for MORE contacts (i.e. contests).
>> 
>> I’m sticking with FT8 for QUALITY. 
>> 
>> 73 de W8NET Miles / “Gene”
>> Secretary, Portage County Amateur Radio Service (PCARS)
>> 3905 Century Club - Master #47
>> DV2/W8NET in the Philippines
>> Licensed since 1974
> 
> Steve, K9AN
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Soft Demapper in WSJT-X

[Steven Franke via wsjt-devel]

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 that are subsequently consumed 
> by one of the LDPC decoders.  As part of the demapping process, the Gray code 
> permutation applied to symbols at the transmitter is removed.
> 
> Is there a textbook or specific journal/conference papers that describe how 
> this demapper works?  I can figure out the algorithm being used, but I am 
> looking for an explanation as to why that algorithm generates a good 
> approximation to the LLR for FT8’s 8-GFSK modulation, and what specific 
> channel impairments it is trying to deal with.

The code that you referenced implements noncoherent sequence estimation for 
groups of symbols of length, N, for N = 1, 2, 3. When the channel happens to be 
coherent over times that span several symbols this technique can significantly 
improve sensitivity. 

A reference that discusses this technique is:

Simon, M.K., and D. Divsalar, “Maximum-Likelihood Block Detection of 
Noncoherent Continuous Phase Modulation,” IEEE Trans. on Communications, Vol. 
41, No. 1, January 1993, p.90. 

As you might expect, there are dozens of articles on the topic — but this one 
is a good overview.

After sequence estimation has determined a soft metric for each of the 2^N 
possible symbol sequences, the next step is to derive soft bit metrics (“log 
likelihoods”) for each of the 3*N bits that are conveyed by the sequence of 
length N. 

There are many ways to do this and no one way is best for all possible 
channels. We use a max-log approximation to the numerator and denominator of 
the metric given in equation (17) of this reference:

Souryal, M. R., E. G. Larsson, B. Peric and B. R. Vojcic, “Soft-Decision 
Metrics for Coded Orthogonal Signaling in Symmetric Alpha-Stable Noise,” IEEE 
Transactions on Signal Processing, Vol. 56, No. 1, January 2008, p. 266.

> I was also wondering how the specific Gray code mapping in FT8 was chosen?  
> It is clearly not the “reflected binary code” that normally passes for a Gray 
> code, so clearly it is something else that I don’t yet understand.

The Gray mapping is defined such that the bit sequences associated with 
neighboring tones differ in only one position. 

With reference to subroutine genft8.f90, note that the 8 successive entries in 
the graymap vector are indexed by indices formed from 3 successive bits, and 
each graymap vector element represents a tone.

The graymap vector is defined like this:

integer graymap(0:7)
data graymap/0,1,3,2,5,6,4,7/

For example, graymap(6)=4. This means that the bit sequence 110 (6) is mapped 
to tone 4.

Here’s the correspondence between tones and bits that results from the graymap 
definition given above:

tone bits
0000
1001
2011
3010
4110
5100
6101
7111

I hope that this addresses your questions.

Steve k9an

> 
> James (VK3JPK)
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 Frequency on 40-m

[Steven Franke via wsjt-devel]

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 channels with severe Doppler spreading, the threshold SNR is higher for both 
modes, and the difference between FT8 and FT4 will decrease somewhat because 
FT4’s larger tone separation tends to give it an advantage in those cases.

It might be of interest to some to consider that FT8 uses symbols with duration 
160 ms to send 3 bits apiece. FT4 uses symbols with duration 48 ms to send 2 
bits apiece. For a given average transmitter power, the energy that is 
transmitted per bit for FT8 is larger than the energy transmitted per bit for 
FT4 by the factor (160/3)/(48/2) = 2.22. Thus, the theoretical sensitivity 
difference (ignoring any differences in signal detection, synchronization or 
LDPC decoding efficiency) is 10*log10(2.22) = 3.46 dB, very close to the actual 
difference of 3.3 dB that I quoted above.

I have no strong feelings one way or the other about your main point, but I 
think that it’s preferable to base the discussion on accurate numbers.

> 
> FT4 is awesome for MORE contacts (i.e. contests).
> 
> I’m sticking with FT8 for QUALITY. 
> 
> 73 de W8NET Miles / “Gene”
> Secretary, Portage County Amateur Radio Service (PCARS)
> 3905 Century Club - Master #47
> DV2/W8NET in the Philippines
> Licensed since 1974

Steve, K9AN


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MacOS WSJT-X v2.1.0 users please read

[Steven Franke via wsjt-devel]

> 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 than the declared on 
> for dummy argument ‘msgsent’ (-216172782113783786/22)”
> 
> — John G4KLA___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Hi John,

I’ve lost track of which issue your report pertains to. It seems that there are 
3 possibly unrelated issues at play on MacOS.

1. Crash related to reading the LoTW user file. Bill has identified the cause 
of this problem.
2. Kevin, VE7DS’s report of a crash related to MSK144 mode. I have tried, but 
have not yet been able to reproduce this here.
3. George, KF2T’s report of a crash on startup when running a beta version of 
MacOS. I have not tried to reproduce this.

Which one does your report address?  Or is your report yet another problem? 

Steve k9an




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] rc7 Subprocess Error ... exit code 2

[Steven Franke via wsjt-devel]

> 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:-.
>> 
>> Running: C:\WSJT\wsjtxRC7\bin\jt9 -s WSJT-X -w 1 -m 3 -e 
>> C:\WSJT\wsjtxRC7\bin -a C:\Users\Derek\AppData\Local\WSJT-X -t 
>> C:\Users\Derek\AppData\Local\Temp\WSJT-X
>> At line 43 of file C:\Users\bill\src\k1jt\wsjtx\lib\ft4\ft4_downsample.f90
>> Fortran runtime error: Index '-2147483647' of dimension 1 of array 'cx' 
>> below lower bound of 0
>> 
>> Error termination. Backtrace:
>> 
>> Could not print backtrace: libbacktrace could not find executable to open
>> #0 0x
>> #1 0x
>> #2 0x
>> #3 0x
>> #4 0x
>> #5 0x
>> #6 0x
>> #7 0x
>> #8 0x
>> #9 0x
>> #10 0x
>> #11 0x
>> #12 0x
>> #13 0x
>> 
>> I hope this is useful.
>> 
>> 
>> 73 de G4SWY Derek +++
> Hi Derek,
> 
> we are looking for a saved .WAV file that reproduces this issue, can you send 
> us the .WAV file for the Rx period that caused the crash please?
> 
> 
Hi Derek,
To add to what Bill said, if you identify a saved wav file that causes the 
crash, please send your WSJT-X.ini file along with the wav file.
Thanks!
Steve k9an

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] error code 2

[Steven Franke via wsjt-devel]

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 I returned
> received subprocess error exit code 2
> WSJT seemed to still be running ok...
> 
> 
> 
> Running: C:\Ham Programs\WSJT\wsjtx\bin\jt9 -s WSJT-X -w 1 -m 3 -e "C:\Ham 
> Programs\WSJT\wsjtx\bin" -a C:\Users\AL\AppData\Local\WSJT-X -t 
> C:\Users\AL\AppData\Local\Temp\WSJT-X
> At line 43 of file C:\Users\bill\src\k1jt\wsjtx\lib\ft4\ft4_downsample.f90
> Fortran runtime error: Index '-2147483647' of dimension 1 of array 'cx' below 
> lower bound of 0
> 
> Error termination. Backtrace:
> 
> Could not print backtrace: libbacktrace could not find executable to open
> #0 0x
> #1 0x
> #2 0x
> #3 0x
> #4 0x
> #5 0x
> #6 0x
> #7 0x
> #8 0x
> #9 0x
> #10 0x
> #11 0x
> #12 0x
> #13 0x
> 
> AL, K0VM
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 decoding sensitivity: WSJT-X vs. JTDX

[Steven Franke via wsjt-devel]

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 WSJT-X instance contained a different callsign, and who knows 
what state the QSO state machine was in. 

Note, too, that WSJT-X shows 23 decodes for this case, and only 22 are visible 
on the JTDX display. The two decodes that the JTDX instance does not show are: 



Steve k9an

> On May 3, 2019, at 7:12 AM, DG2YCB, Uwe  wrote:
> 
> Please find in this and in the next email two examples including audio files 
> and screenshots. Decoding/non-decoding is reproducible here on my PC when I 
> am opening the audio files with WSJT-X, or JTDX resp. Hope that these files 
> are useful.
>  
> Example 1: Today (190503_095230) on 20m. I am in QSO with AM70U. AM70U’s 
> signal seems to be overlapped by another station. Nonetheless, JTDX decodes 
> AM70U’s “-10” report to me with -7 dB, WSJT-X decodes nothing on that 
> frequency.
>  
> 73 de Uwe, DG2YCB 
> <190503_095230_AM70U_-10_to_DG2YCB.jpg><190503_095230_AM70U_-10_to_DG2YCB.wav>___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X Feature

[Steven Franke via wsjt-devel]

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 additional feature to WSJT-X.  If this is 
> not the proper place, please let me know how to do this, thanks.
> 
> My suggestion is:  In the lower right of the program window is the Pwr 
> control slider.  Is it possible to refine control of this slider by adding an 
> up arrow at the top, a down arrow at the bottom: a mouse click on the up or 
> down arrow would make an incremental movement of the slider in the direction 
> of the arrow.  It would be great to have at least 5 (more if feasible) 
> increments between each tic mark on the slider to enable precision control of 
> the slider.
> 
> Thanks for a great piece of software.
> 
> -- 
> Bill Cole, N2CSA, bco...@comcast.net  
> CMC Deputy RACES Officer, CMC ARRL EC
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] F/H sequence

[Steven Franke via wsjt-devel]

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 a “Hound”. Can you verify that 
you had selected “Hound” and that “Special operating activity” was checked?

73 Steve, k9an

> On Mar 13, 2019, at 5:11 PM, Pino Zollo  wrote:
> 
> Wrong sequence: WSJT 2.0.1 does not realize having received RR73 and replies 
> with R-20
> 
> I had to force by hand the 73
> 
> I have seen this fact 3 times with different F/H stations.
> 
> 73
> 
> Pino ZP4KFX
> 
> 
> 20415  Tx  1321 ~  7P8LB ZP4KFX GG14
> 220430 -20  0.0  303 ~  ZP4KFX 7P8LB +00? a3
> 220445  Tx  1321 ~  7P8LB ZP4KFX R-20
> 220500 -18  0.0  303 ~  DK6IM 7P8LB -17
> 220515  Tx  1321 ~  7P8LB ZP4KFX R-20
> 220530 -18  0.5  302 ~  ZP4KFX RR73; DK6IM <7P8LB> -18
> 220545  Tx  1321 ~  7P8LB ZP4KFX R-20
> 220548  Tx  1321 ~  7P8LB ZP4KFX 73 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JT9 FT8 arecord csdr sox and redpitaya

[Steven Franke via wsjt-devel]

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 convert_s16_f  | csdr 
> shift_addition_cc `python -c "print float(3568600-3573000)/384000"` | csdr 
> fir_decimate_cc 8 0.05 HAMMING | csdr bandpass_fir_fft_cc 0 0.1 0.05 | csdr 
> realpart_cf | csdr gain_ff 20 | csdr convert_f_s16 | sox -q -t raw -b 16 -e 
> signed -c 1 -r 48000 - -t wav FT8.wav
> 
> but when i try to decode with:
> 
> At line 188 of file /home/bill/wsjtx-prefix/src/lib/jt9.f90
> Fortran runtime error: Substring out of bounds: lower bound (-1) of 'infile' 
> is less than one
> 
> Error termination. Backtrace:
> #0  0x7f46d681f31a
> #1  0x7f46d681fec5
> #2  0x7f46d6820297
> #3  0x5654003b0ceb
> #4  0x5654003ae99e
> #5  0x7f46d58c6b96
> #6  0x5654003aea99
> #7  0x
> 
> 
> But when i try with other sample in wsjtx sample, it work great:
> 
> jt9 --ft8 181201_180245.wav
> 180245   0  0.1  232 ~  K8RGI W6BQ 73
> 180245 -21  0.2  325 ~  CQ RU K1BAA DM03
> 180245  -4  0.0  446 ~  CQ RU W7BOB DN14
> 180245  16  0.1  600 ~  KV4ZY NX8G 539 OH
> 180245  13  0.2  652 ~  KV7J WD9HSY 529 IL
> 180245   3  0.5  786 ~  N8HRZ W7CD 73
> 180245 -16  0.1  841 ~  W7PP AF4T 539 TN
> 180245  -2  0.1 1000 ~  XE1MEX N0UX 559 CO
> 180245   4  0.6 1151 ~  KC8YDS KF6CRW R 559 ID
> 180245 -19  0.1 1442 ~  K1JT 9A2JK RR73
> 180245 -15  0.3 1719 ~  W3RGA KJ7G 529 WA
> 180245  -9  0.1 1799 ~  N9CIF KE0PX DM67
> 180245  12  0.1 1879 ~  W3RGA KM6JD RR73
> 180245  -5  0.1 1980 ~  CQ RU NT2A FN20
> 180245   9  0.2 2189 ~  N9LF WV4P R 529 TN
> 180245   4  0.2 2454 ~  WB3LGC AA5AU R 529 LA
>0  16
> 
> have you somme idea?
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Timestamps missing in ALL_WSPR.TXT

[Steven Franke via wsjt-devel]

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 seems to miss the second part of type 2 WSPR messages and I 
> suspect that is due to the lack of date and time fields in the ALL_WSPR.TXT 
> file.
> 
> An example of the WSJT-x ALL_WSPR.TXT:
> 
> 170711 2234   1 -28  1.26  14.0970558  VE7XT CN88 20   0   1900
> 170711 2234   5 -17  0.11  14.0971048  W6CLB CM87 20   0 10
> 170711 2234   2 -26  0.07  14.0971457  W2GMD CM87 20   0 10
> 170711 2236   5 -17  0.07  14.0971049  W6CLB CM87 20   0 10
> 170711 2236   2 -26  0.15  14.0971605  W2GMD CM87 20   0 20
> 170711 2238   2 -26  0.07  14.0970629  W2GMD CM87 20  q 0 10
> 170711 2238   4  -9  0.15  14.0970705  WD6DFH CN84 20 -2 10
> 170711 2238   5 -17  0.07  14.0971049  W6CLB CM87 20   0 10
> 
> Whereas my ALL_WSPR.TXT looks like this with the freq and USB in the first 
> two fields:
> 
> 703860 _usb   3 -23  0.45   7.0400585  AJ8S EM89 270 10   
>  1  220  0
> 703860 _usb   3 -18  0.07   7.0400668  W1VR EL98 200 10   
>  1  464  0
> 703860 _usb   5 -13  0.19   7.0400802  KG5OVB EM10 37  0 10   
>  1  547  0
> 703860 _usb   5   3  0.15   7.0401045   DN70IC 33   0 10   
>  1  591  0
> 703860 _usb   4  -6 -1.00   7.0401085  VE7GNU CN88 33  0 10   
>  1  525  0
> 703860 _usb   7   7  3.99   7.0401146  W6TN DM13 230 10   
>  1  611  0
> 703860 _usb   4  -9  0.37   7.0401189  K4APC EM81 37   0 10   
>  1  525  0
> 703860 _usb   2 -20  0.45   7.0401333  VA3KV FN25 27   0   6300   
>  1  -33  0
> 703860 _usb   5  -4  0.79   7.0401342  WA4KFZ FM18 37  0 10   
>  1  564  0
> 703860 _usb   3  -8  0.79   7.0401448  N8VIM FN42 37  -2 10   
>  1  520  0
> 
> I can find no date and time fields in the WSJT-x wav file and no mention of a 
> wsprd date/time command time flag.
> 
> Would the lack of date and time in ALL_WSPR.TXT lead to missed decodes and if 
> so where is that information communicated to wsprd?
> 
> Thanks,
> 
> Rob
> 
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us 
> mobile: +1 650 218 8896
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Accessing raw decode data?

[Steven Franke via wsjt-devel]

Hi Joe,

Aside from the waterfall display itself, the numbers that are used to create it 
are not available for processing by external programs. The Fourier transforms 
that are displayed in color-coded form on the waterfall display are calculated 
in the Fortran routine src/lib/hspec.f90. This routine is called from the C++ 
code in src/widgets/mainwindow.cpp. You’ll be able to find the point where 
hspec is called by searching for the word “hspec” in the mainwindow.cpp file.

Honestly, if you’re not familiar with the WSJT-X code, it’d be easier to just 
use a sound analysis program like Audacity, or baudline, or perhaps the one 
that Mike, W9MDB, suggested to calculate the short Fourier transforms that 
produce a waterfall display. 

Steve k9an

> On Feb 1, 2019, at 4:59 PM, jbozell  wrote:
> 
> Hi Steve,
>  
> Thanks for the suggestion…do you think there’s a way to attach a number to 
> the visual representation that appears under “cumulative”? Alternatively, can 
> it be broken down into individual numbers for each of the 50 hz signals that 
> appear across the passband?
>  
> Actually, I’ve been using cumulative, and I think that’s what got me thinking 
> about alternate data mining techniques. If one considers two parallel grid 
> cells, one might be pretty dim while the other might be quite bright. At some 
> place in the source code, the dim cell should be translating some number x 
> into a certain level of pixel activation, while the bright cell is 
> translating some number y into more pixel activation. And y should be > x…I 
> think. I’d like to find numbers x and y (and all the other numbers output in 
> a given time unit.
>  
> In my previous life, I did a lot of spectral analysis of organic compounds, 
> and we used this type of integration to great use. Every time I look at the 
> waterfall and read that part of WSJT-X includes Fourier Transform, I start 
> thinking there’s got to be some overlap that could be useful.
>  
> But maybe WSJT-X isn’t programmed that way?
>  
> 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 
> Subject: Re: [wsjt-devel] Accessing raw decode data?
>  
> 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 each receive 
> interval. 
>  
> Make sure that the “Cumulative” option is selected from the dropdown menu at 
> the bottom of the waterfall window (just to the right of the color palette 
> selection). You can make the Cumulative spectrum occupy a larger fraction of 
> the window using the up-down arrows next to the box that is labeled “Spec 
> NN%”, where NN will be percentage of the vertical window space that should be 
> used for the Cumulative spectrum. 
>  
> Steve k9an
> 
> 
>> On Feb 1, 2019, at 1:57 PM, jbozell > <mailto:jboz...@utk.edu>> wrote:
>>  
>> Hi folks,
>>  
>>  <>I’m reposting the gist of my previous question after getting some nice 
>> suggestions that ultimately didn’t pan out (e. g., thanks to Mike W9MDB for 
>> leading me to Sonic Visualizer…it was close, but not quite there, and 
>> DL4YHF’s Spectrum Lab, which is powerful, but for PC only).
>>  
>> At some point during an FT8 decode, I’m assuming that there’s a number or 
>> library of numbers is generated that is then translated into a visual 
>> representation – the waterfall spectrum.
>>  
>> Is it possible to tap into the software and download those numbers into 
>> Excel or similar? It would be interesting, for example, to integrate the 
>> value of each 15 second x 50 Hz block that makes up the waterfall grid.
>>  
>> Is this possible ? Has someone already done it? Incompatible with the way 
>> WSJT-X works?
>>  
>> Thanks,
>>  
>> Joe/WB0CDY
>>  
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
>> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Accessing raw decode data?

[Steven Franke via wsjt-devel]

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 each receive interval. 

Make sure that the “Cumulative” option is selected from the dropdown menu at 
the bottom of the waterfall window (just to the right of the color palette 
selection). You can make the Cumulative spectrum occupy a larger fraction of 
the window using the up-down arrows next to the box that is labeled “Spec NN%”, 
where NN will be percentage of the vertical window space that should be used 
for the Cumulative spectrum. 

Steve k9an

> On Feb 1, 2019, at 1:57 PM, jbozell  wrote:
> 
> Hi folks,
>  
>  <>I’m reposting the gist of my previous question after getting some nice 
> suggestions that ultimately didn’t pan out (e. g., thanks to Mike W9MDB for 
> leading me to Sonic Visualizer…it was close, but not quite there, and 
> DL4YHF’s Spectrum Lab, which is powerful, but for PC only).
>  
> At some point during an FT8 decode, I’m assuming that there’s a number or 
> library of numbers is generated that is then translated into a visual 
> representation – the waterfall spectrum.
>  
> Is it possible to tap into the software and download those numbers into Excel 
> or similar? It would be interesting, for example, to integrate the value of 
> each 15 second x 50 Hz block that makes up the waterfall grid.
>  
> Is this possible ? Has someone already done it? Incompatible with the way 
> WSJT-X works?
>  
> Thanks,
>  
> Joe/WB0CDY
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 2.0.0 WSPR odd behaviors

[Steven Franke via wsjt-devel]

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 not address either 
of the issues that you have observed. You might consider running with decode 
depth set to “Normal” rather than “Deep”. This will give you the same 
performance that was available under the “Deep” setting in earlier versions of 
WSJT-X. You will lose a couple of dB in decoding sensitivity, but you will also 
see fewer false decodes.

73 Steve, k9an

> On Jan 24, 2019, at 4:03 AM, N1BUG  wrote:
> 
> I want to report two new behaviors with WSPR in 2.0.0 that were not
> occurring with prior versions.
> 
> 1. Occasionally a known / real call sign will decode with an
> incorrect grid. Usually the grid is thousands of miles from where it
> should be, sometimes in the arctic or the middle of an ocean. A look
> around WSPRnet confirms this is not limited to me.
> 
> 2. I have always had the occasional spurious decode while
> transmitting, due to all the noise of receiver overload I presume. I
> use separate receiver and transmitter (LF and MF). Usually it is
> 14MDA LR90. Prior to 2.0.0 it would happen a couple times a day or
> so. What is new in 2.0.0 is that once this decode comes up once, it
> keeps coming up every few minutes if not every transmission. If I
> delete hashtable.txt or remove the 14MDA entry from that file, it
> will then be several hours before I get another of those decodes.
> 
> Note: I am not yet certain whether not having hashtable.txt prevents
> the first odd behavior. I am now running a script which deletes that
> file after every decode period in an attempt to find out, but it
> will take some time to be sure. Fortunately WSJT-X does not seem to
> mind finding itself deprived of hashtable.txt and just silently
> re-creates it.
> 
> 73,
> Paul N1BUG
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible bug WSJT-X 2.0 FT8 F/H mode

[Steven Franke via wsjt-devel]

> 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 behavior as follows with annotated excerpts 
>> from my all.txt file:
> 
> [Snipped]
> 
>> If desired, I can send the entire 377 line session from my all.txt file.
>> 
>> The fact that re-starting the program temporarily fixed this problem 
>> indicates to me that this was not a case of MI0KOA also running F/H mode 
>> as Fox on the same frequency. Note that it started right after MI0KOA 
>> made his QSO. Strange!
>> 
>> Was anyone else seeing this?
>> 
>> 73,
>> John, K9MM
> 
> Yes, I noticed it too around the time (232315z on 2018-12-22) I worked HV0A 
> on 80m 
> although I didn't try restarting WSJT-X to see if the 'issue' disappeared; I 
> just assumed it was 
> MI0KOA also running as a Fox in F & H mode.
> 
> Here's an extract from my ALL.TXT:
> 

> 
> The first appearance of the MI0KOA callsign is at 232515z, when JA4DND was 
> calling him - 
> there's no evidence of that JA callsign previously having called HV0A.  At 
> 232500 HV0A was 
> calling BG3UPA on 417Hz , then BG3UPA was subsequently called by MI0KOA at 
> 232530 
> on 296Hz.
> 
> I wonder if MI0KOA really was QRV in F & H mode at the same time and on the 
> same 80m 
> frequency as HV0A and the two sets of QSOs just got completely intermixed and 
> tangled up, 
> or perhaps it's another instance of identical hash values for the HV0A and 
> MI0KOA callsigns 
> which got cleared by restarting the app.
> 
> --
> 73, Martin G0HDB

John and Martin,

What you were seeing was caused by a 10-bit hash collision between HV0A and 
MI0KOA. The next release of WSJT-X will incorporate a number of changes that 
are aimed at improving the handling of these situations. Specifically, the 
changes would have prevented MI0KOA from being displayed in angle brackets 
provided that you had HV0A entered into your DX Call box.

Thanks for the report!

Steve k9an



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Steven Franke via wsjt-devel]

Hi Jim,

Before you resort to dropping  back to 10.13.6, have you tried letting wsjtx 
create a new, clean, .ini file? You could either move your old one out of the 
way temporarily or you could start wsjtx from the command line using something 
like this:

cd /Applications/wsjtx.app/Contents/MacOS
./wsjtx -r test

which will create a clean .ini file named "WSJT-X - test.ini”.

Steve k9an



> On Dec 20, 2018, at 7:08 PM, Jim Kennedy  wrote:
> 
> Hi Steve:
> 
> Thanks for you thoughts!
> 
> I did do John, G4KLA's procedure quite some time ago when the Mac Mini first 
> came on line (as it was necessary).
> 
> I have reviewed that again, and the values haven’t change on the Mini, (or 
> the desktop and laptop which are working fine with OS 10.13.6).
> 
> My results are:
> $ sysctl -a | grep sysv.shm
> kern.sysv.shmmax: 33554432
> kern.sysv.shmmin: 1
> kern.sysv.shmmni: 128
> kern.sysv.shmseg: 32
> kern.sysv.shmall: 8129
> 
> The is significantly larger that what is working for you (although the last 
> line is smaller), and the error message is not the same as one that the 
> current message is producing.
> 
> 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 it out?
>> 
>> Hi Jim,
>> 
>> You may need to increase the shared memory allocation if you are running the 
>> stock configuration of MacOS. The instructions can be found in 
>> src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a 
>> relevant excerpt from that file:
>> 
>> 'After the reboot you should re-open the Terminal window as before and you 
>> can check that the change has been made by typing:
>> 
>> sysctl -a | grep sysv.shm
>> 
>> If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
>> an error message: "Unable to create shared memory segment”.'
>> 
>> Here’s what I get on this laptop, which is running MacOS 10.14.2 and which 
>> runs WSJT-X just fine:
>> 
>> $ sysctl -a | grep sysv.shm
>> kern.sysv.shmmax: 14680064
>> kern.sysv.shmmin: 1
>> kern.sysv.shmmni: 128
>> kern.sysv.shmseg: 32
>> kern.sysv.shmall: 17920
>> 
>> If your shmmax parameter is smaller than 14680064, I recommend that you 
>> follow the procedure that is explained in the ReadMe.txt file.
>> 
>> Regards,
>> Steve k9an
>> 
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Steven Franke via wsjt-devel]

> 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 it out?

Hi Jim,

You may need to increase the shared memory allocation if you are running the 
stock configuration of MacOS. The instructions can be found in 
src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a 
relevant excerpt from that file:

'After the reboot you should re-open the Terminal window as before and you can 
check that the change has been made by typing:

  sysctl -a | grep sysv.shm

If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
an error message: "Unable to create shared memory segment”.'

Here’s what I get on this laptop, which is running MacOS 10.14.2 and which runs 
WSJT-X just fine:

$ sysctl -a | grep sysv.shm
kern.sysv.shmmax: 14680064
kern.sysv.shmmin: 1
kern.sysv.shmmni: 128
kern.sysv.shmseg: 32
kern.sysv.shmall: 17920

If your shmmax parameter is smaller than 14680064, I recommend that you follow 
the procedure that is explained in the ReadMe.txt file.

Regards,
Steve k9an

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsigns substituted by <...>

[Steven Franke via wsjt-devel]

> 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 1590 ~  <...> LZ1PPZ R-18
> 103715  -5  1.9 1589 ~  <...> LZ1PPZ R-20
> 103745  -8  1.8 1588 ~  OG55W  73
> 
> Looks like LZ1PPZ worked OG55W, but why was the call of OG55W not shown in 
> the initial messages?
> And why is LZ1PPZ enclosed by <> in the last message?

For the first three messages, the full callsign OG55W had not yet been received 
and entered into the hashtable. Therefore, the hash number that was received in 
place of OG55W could not be associated with the callsign OG55W. On the other 
hand, the full call of LZ1PPZ was received in each of the first three messages, 
and each time that it was received it was entered into the hashtable. So when 
the hash of LZ1PPZ was received in the 4’th message, the callsign could be 
looked up in the hashtable and printed between angle brackets .

> 
> Other examples:
> 112030 -12  0.3  915 ~  G3PLP <...> -16
> 112100 -14  0.3  915 ~   ZS9YOTA RR73
> Why was ZS9YOTA substituted by <...> ?

Same as above. 

> 
> 111800 -17  0.1  650 ~  CQ SD4C JP80   Sweden
> 111830 -14  0.1  650 ~  <…>

> What happened here?

Don’t know.

> 
> I use WSJT-X v2.0.0.0 in FT8 mode
> 
> 73,
> Ton pa0tbr

Steve k9an



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] No more decodes with much larger hashtable.txt file

[Steven Franke via wsjt-devel]

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 never decoded?  My recommendation would be to 
delete your hashtable every couple of weeks, and let it fill back up on its 
own. That is what I do here on my 8-channel WSPR monitor.  

Steve

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Very few decodes during contest

[Steven Franke via wsjt-devel]

Hi Dave,

I know next to nothing about Windows, so I cannot say whether Dimension 4 
should be adequate, or not.  I can say that your computer clock would only need 
to be off by, say, 1 second in the “wrong” direction to cause most signals to 
fail to decode.  

Stations whose computer time was accurate would never encounter the bug when 
communicating with other stations whose time was accurate. The reason for this 
is that QSO partners with perfect clocks will both see positive DT due to 
audio-chain delays.  Assuming that the half the clocks that are out-of-whack 
are “fast”, and the other half are “slow”, then only half of the out-of-whack 
stations would have caused problems for stations with good clocks. This is a 
relatively small number, which explains why I didn’t notice the problem until I 
had occasion to work a lot of stations during the contest. On the other hand, 
an out-of-whack station whose clock was off in the wrong direction would fail 
to decode all stations who had accurate clocks - and this is the majority of 
stations. 

As I said earlier, this bug will be fixed in the GA release, which should be 
available within 10 days. I recommend that you try again once the GA version is 
released. It’s very possible that you will have better luck with the GA 
release, even if you do nothing to improve your computer clock’s accuracy.

Steve k9an

> On Dec 3, 2018, at 3:42 PM, David R. Hassall WA5DJJ  
> wrote:
> 
> Dear Steve, 
> In my case I had Dimension 4 running keeping my clock in my computer very 
> close to the correct time.
> Is there something better I could have used?   Or is it just a fluke from the 
> other stations I was calling?  Or is it the bug that was killing me and why 
> were others making contacts all 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/
> 
> 
> 
> -Original Message-
> From: Steven Franke via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: Monday, December 03, 2018 2:12 PM
> To: WSJT software development 
> Cc: Steven Franke 
> Subject: Re: [wsjt-devel] Very few decodes during contest
> 
> 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 a period. If the computer's clock drifts 
> such that DT's are shifted toward negative values, then that could have 
> prevented signals from decoding. This should now be fixed, and the corrected 
> code will be in the GA release. 
> 
> Here are the decodes that I get from the 193215 Saturday evening after fixing 
> the bug:
> 
> 193215 -15 -0.1 748 ~ CQ RU YC2YIZ OI52  Indonesia
> 193215 -16 -0.2 912 ~ ES4NY SV8EUB 539 0024
> 193215 -1 0.0 1035 ~ OH4NDU RX4HX 559 0036
> 193215 5 -0.3 1312 ~ OZ6GH EA3KU R 569 0017
> 193215 0 -1.0 1457 ~ IK2RZP SA3MYS 539 0002
> 193215 7 -0.1 1712 ~ G8AJM UA3ROB 539 0016
> 193215 -15 -0.3 1874 ~ HA8TKS ON4HRT R 549 0024
> 193215 -12 -0.3 1966 ~ PD2EMP UR7HN 529 0004
> 193215 -2 -0.3 2043 ~ ES4NY RX6ACJ 549 0024
> 193215 -17 -0.6 2194 ~ PD2EMP RA3TT 549 0010
> 193215 -6 0.1 2264 ~ UR3QTN EA2ASB 539 0003
> 193215 -19 -0.6 782 ~ OH8WW M0IEP 579 0009
> 193215 -12 -0.1 1015 ~ CQ RU R3QG KO91  EU Russia
> 193215 -8 -0.4 2040 ~ ES4NY RC7LS 569 0033
> 
> You’ll notice that most of these decodes show negative DT, which explains why 
> they weren’t decoding before.
> 
> Steve k9an
> 
>> On Dec 3, 2018, at 2:41 PM, Andi Malek  wrote:
>> 
>> Hi Dave,
>> 
>> I’ve got exactly the same problem but it seems that this thing happens on 
>> very very few Systems. Unfortunately I’ve encountered the Problem on two 
>> different Computers with two different receivers on Saturday evening. I 
>> wasn’t even able to receive my own Signal transmitted by one rig to the 
>> other one and no receive the other way round either. Switching back to 
>> V1.9.1 brought perfect reception on both systems and both rigs were 
>> receiving the signal of the other one.
>> 
>> Like a Miracle one of the two Systems started to operate just fine Sunday 
>> evening. So I was able to decode practically all readable transmissions 
>> during the test. I’ve attached two .wav files saved by the two different 
>> systems. One caught on Saturday evening, where just a few transmissions can 
>> be decoded, the second one caught Sunday evening with a lot of decoded 

Re: [wsjt-devel] Very few decodes during contest

[Steven Franke via wsjt-devel]

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 a period. If the computer's clock drifts such that DT's are 
shifted toward negative values, then that could have prevented signals from 
decoding. This should now be fixed, and the corrected code will be in the GA 
release. 

Here are the decodes that I get from the 193215 Saturday evening after fixing 
the bug:

193215 -15 -0.1 748 ~ CQ RU YC2YIZ OI52  Indonesia
193215 -16 -0.2 912 ~ ES4NY SV8EUB 539 0024
193215 -1 0.0 1035 ~ OH4NDU RX4HX 559 0036
193215 5 -0.3 1312 ~ OZ6GH EA3KU R 569 0017
193215 0 -1.0 1457 ~ IK2RZP SA3MYS 539 0002
193215 7 -0.1 1712 ~ G8AJM UA3ROB 539 0016
193215 -15 -0.3 1874 ~ HA8TKS ON4HRT R 549 0024
193215 -12 -0.3 1966 ~ PD2EMP UR7HN 529 0004
193215 -2 -0.3 2043 ~ ES4NY RX6ACJ 549 0024
193215 -17 -0.6 2194 ~ PD2EMP RA3TT 549 0010
193215 -6 0.1 2264 ~ UR3QTN EA2ASB 539 0003
193215 -19 -0.6 782 ~ OH8WW M0IEP 579 0009
193215 -12 -0.1 1015 ~ CQ RU R3QG KO91  EU Russia
193215 -8 -0.4 2040 ~ ES4NY RC7LS 569 0033

You’ll notice that most of these decodes show negative DT, which explains why 
they weren’t decoding before.

Steve k9an

> On Dec 3, 2018, at 2:41 PM, Andi Malek  wrote:
> 
> Hi Dave,
>  
> I’ve got exactly the same problem but it seems that this thing happens on 
> very very few Systems. Unfortunately I’ve encountered the Problem on two 
> different Computers with two different receivers on Saturday evening. I 
> wasn’t even able to receive my own Signal transmitted by one rig to the other 
> one and no receive the other way round either. Switching back to V1.9.1 
> brought perfect reception on both systems and both rigs were receiving the 
> signal of the other one.
>  
> Like a Miracle one of the two Systems started to operate just fine Sunday 
> evening. So I was able to decode practically all readable transmissions 
> during the test. I’ve attached two .wav files saved by the two different 
> systems. One caught on Saturday evening, where just a few transmissions can 
> be decoded, the second one caught Sunday evening with a lot of decoded 
> transmissions. I’m even able to decode the ‘good’ wave-file on the system 
> that is not decoding well from RF with very good results.
>  
> This evening I gave it another try with both rigs operating on 10m, where I 
> was the only one on the band. With V1.9.1 both directions worked fine. With 
> V2.0.0 RC5 only one direction worked, as yesterday.
>  
> The two systems are:
> Good working one: Old Lenovo laptop computer with built in sound card running 
> on Win7.
> The deaf one: Toshiba laptop computer connected to the radio via Signalink 
> USB modem running on Win10.
>  
> I made all settings exactly the same on both systems. Tomorrow I will try to 
> feed the same audio to both systems and give it a try. Hopefully the .wav 
> Files are useful to the developement team who is doing a great job!
>  
> 73s de Andy, oe3dmb
>  
>  
> Von: Dave Barr
> Gesendet: Montag, 3. Dezember 2018 19:02
> An: wsjt-devel@lists.sourceforge.net
> Betreff: Re: [wsjt-devel] Very few decodes during contest
>  
> Thanks for all the replies but almost everyone missed the point. It was
> my receiving with which I was having a problem.  My 5 watt signal was
> heard as well as would be expected.  My problem is that there are say
> ten signals showing clearly on the waterfall, I was able to decode only
> 2 or 3.  I did not have the CQ only box checked.   I was in the correct
> band, ie, 7080 khz for 40 meters (problem occurred on all bands).  The
> signals that did decode were at a variety of strengths, +7 to -20.  
> Software is RC5.   After the contest ended, I reloaded 1.9, and there
> were decodes for almost all signals at the regular QRGs.
>  
> Did anyone experienced this situation? Remember, receive decodes only
> and only with 2.0 rc 5 and rc 4.
>  
> Dave, K2YG
>  
>  
>  
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>  
> <181202_203100.wav><181201_193215.wav>___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Contest Log Window- Autoscroll

[Steven Franke via wsjt-devel]

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 the previous last, but then the newest is still out of view 
> unless I scroll manually...
> 
> 
> 
> On Sun, Dec 2, 2018, 12:00 PM Martin Davies G0HDB   wrote:
> On 2 Dec 2018 at 12:16, Bill Somerville wrote:
> 
> > On 02/12/2018 09:41, oe9...@ft8.at  wrote:
> > > Hello from Austria,
> > >
> > > RC5 737d2f, Windows 10 Pro, Version 1809 (Build 17763.134)
> > >
> > > looking at the Contest Log Windows - is there a "trick" to make it scroll
> > > down automatically
> > > all the way to the LAST entry?
> > >
> > > Regardless of the window position/size it always shows the last but one 
> > > log
> > > line.
> > >
> > > Thanks.
> > >
> > > 73, Frank
> > > OE9KFV
> > 
> > Hi Frank,
> > 
> > this is the first report of this on MS Windows. There are issues with 
> > the Contest Log window not scrolling to show the last QSO on some Linux 
> > desktops.
> > 
> > Is the Contest Log window trying to go to the last entry but stopping 
> > short by one row or is it not scrolling at all when you log a QSO?
> > 
> > 73
> > Bill
> > G4WJS.
> 
> Hi Bill (and all), I can confirm that on my system - 32-bit Win 7 Pro running 
> v2.0.0-rc5 737d2f 
> - the entries in the Contest Log window don't scroll up sufficiently to 
> ensure that a 
> newly-logged entry is fully displayed on the bottom line of the window.  
> 
> When a new QSO is logged the information in the window moves slightly upwards 
> but not by 
> enough to fully display the new QSO.  This happens no matter what size the 
> window is.
> 
> --
> 73, Martin G0HDB
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign problem?

[Steven Franke via wsjt-devel]

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 truncated after the 'E' in "EN50".  I then removed EN50 from 
> TX1.  His transmissions to me also appears to be truncated. 
> 
> Drew K9CW
> 
> 
> 
> -- 
> **
> * K9CW   DXCC: 363/340  CW: 351/339 (need P5!)
> * K9CW/B running 2 watts on 28.2095 MHz
> *
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Steven Franke via wsjt-devel]

> 
> *** 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 can tell which files are FT8 and which are JT65 
by their different name formats.

Steve



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0 rc5: Open list problem

[Steven Franke via wsjt-devel]

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 switched to JT65 for checks - all well.  But, when attempting to decode a 
> saved JT65 WAV file I notice that in the “Open” list, only FT8 WAV files are 
> shown and no JT65 WAV files although all the files are present in the Save 
> directory.
> 
> Next step:  select Open: select the FT8 WAV file immediately preceeding the 
> set of JT65 WAV files; this is loaded;  then select “Open next in directory” 
> and the first JT65 WAV file is decoded; “Open next in directory” continues 
> with the set of JT65 WAV files.
> 
> I find that the same curiosity is found with v1.9.1
> 
> Is the faulty loading of the Save directory a macOS problem?
> 
> — John G4KLA___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] RC4 v RC3 decode

[Steven Franke via wsjt-devel]

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 interference and hence may 
fail to decode. This will go away once all users switch to using only 77bit 
messages. 

Steve k9an

> On Nov 25, 2018, at 1:08 PM, Al  wrote:
> 
> I have been running both RC3 & RC4 on the same PC decoding the same digital 
> audio stream.
> At time I have noted that I get decode for 77bit station in RC3 that do not 
> appear in RC4.
> I can reproduce this playing back the same wav files in rc3 & RC4.
> RC3 decode
> 
> RC4 decode 
> 
> 
> Also noted where decode was present in both, that there is a difference in 
> s/n reported.  ( maybe just work in progress )
> 
> wav & all.txt files available on request..
> 
> 
> AL, K0VM
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsprd decoding mode used in WSJT-x 2.0

[Steven Franke via wsjt-devel]

> 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 than when the same file is processed by WSJT-x.
> So I infer that WSJT-x must be using a different set of command line flags 
> than my program.
> I haven't been able to find the relevant section of code in the WSJT-x 
> sources,  Could someone point me to them or just tell me the settings used by 
> WSJT-x?
> 
> Thanks,
> 
> Rob  
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us
>  ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 


Rob,

I quoted the settings that WSJT-X uses in a response to you, on this list, 
about a month ago:

> Hi Rob - 
> 
> Are you using the same command-line arguments that WSJT-X uses when it calls 
> the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses “-C 5000 -o 
> 4”. 

You have added the “-d” flag, which is not used by WSJT-X.

Steve K9AN

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] recent_calls bug?

[Steven Franke via wsjt-devel]

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.f90:  character*12 recent_calls(NRECENT)
> ldpcsim144.f90:character*12 recent_calls(NRECENT)
> msk144sd.f90:  character*12 recent_calls(NRECENT)
> 
> 
> Mike
> 
> On Thursday, November 15, 2018, 8:31:48 AM CST, Joe Taylor 
>  wrote:
> 
> 
> On 11/15/2018 9:17 AM, Black Michael via wsjt-devel wrote:
> 
> > Was checking out the recent_calls hash and noticed this:
> > 
> > mskrtd.f90:   recent_calls(i)(1:13)=' '
> > 
> > But recent_calls is char*12.
> 
> 
> Not correct.  See at top of packjt77.f90:
> 
> ##
> module packjt77
> 
> ! These variables are accessible from outside via "use packjt77":
>   parameter (MAXHASH=1000,MAXRECENT=10)
>   character*13 callsign(MAXHASH)
>   integer ihash10(MAXHASH),ihash12(MAXHASH),ihash22(MAXHASH)
>   integer n28a,n28b,nzhash
>   character*13 recent_calls(MAXRECENT)
> 
>   contains
> ...
> ##
> 
> -- 73, Joe, K1JT
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-x 2 wspr SNR

[Steven Franke via wsjt-devel]

Jim,
The number in question is the total Fano path metric for the returned codeword. 
When the last number is 1, that means that the Fano algorithm failed. In such 
cases, the path metric is just set to its maximum possible value, 810.  
Steve k9an

> On Oct 28, 2018, at 11:31 AM, Jim Lill  wrote:
> 
> 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 - 
>> 
>> Are you using the same command-line arguments that WSJT-X uses when it calls 
>> the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses “-C 5000 -o 
>> 4”. 
>> 
>> Also, it is essential that the decoder in v2.0.0  have access to a 
>> well-populated hashtable.txt. Briefly, the enhanced sensitivity is obtained 
>> by invoking a new (to wsprd) decoding algorithm if the Fano algorithm fails. 
>> The new algorithm always returns a codeword, but only a fraction of these 
>> are “good”.  Many of the returned codewords are incorrect and would produce 
>> false decodes. Ideally, one would use a CRC to reject the incorrect 
>> codewords (as in FT8), but the WSPR message doesn’t include a CRC. Instead, 
>> we only accept codewords that unpack to callsigns that we’ve seen before, 
>> i.e. callsigns that are in the hashtable. If there’s no hashtable, then we 
>> will never accept any of the codewords from the new algorithm. This means 
>> that the v2.0.0 decoder becomes more sensitive than 1.9.1 to a particular 
>> callsign only after that callsign has been decoded at least once by the Fano 
>> algorithm.
>> 
>> Finally, decodes produced by the new decoding algorithm will have a “1” as 
>> the last number on the line that is printed in ALL_WSPR.TXT.  Fano algorithm 
>> decodes will show a “0”.
>> 
>> I’ve been very pleased with the results here. There have been many nights 
>> when all of my MF decodes of VK4YB were produced by the new algorithm.
>> 
>> I hope that this information is helpful,
>> 
>> 73 Steve k9an
>> 
>>> On Oct 27, 2018, at 10:27 PM, Rob Robinett >> <mailto:r...@robinett.us>> wrote:
>>> 
>>> Hi Steve,
>>> 
>>> Jim's question was stimulated by tests I have been running at KPH to 
>>> compare the decode performance of the wsprd in 1.9.1 against the wsprd in 
>>> 2.0rc3
>>> 
>>> My test setup is located at KPH where I have one KiwiSDR fed by a 3-30 Mhz  
>>> TCI-530 and a second KiwiSDR fed from a Marconi T.  I don't use the 
>>> excellent wspr decode extension included in the Kiwi, but instead run a 
>>> bash script on a Raspberry Pi 3B which records a 2 minute  wav file for 
>>> each band from 2200M through 10 M.  Each 2 minutes wave file is then fed 
>>> first to wsprd 2.0 and logged as KPH2 and then the sme wav file is fed to 
>>> wsprd 1.9.1 and logged as KPH.  After 24 hours I can find no difference 
>>> between the KPH spots and KPH2 spots.
>>> 
>>> The wsprd binaries were obtained by downloading and installing packages 
>>> from the WSJT-x site and the binaries definitely are different sizes:
>>> 
>>> pi@KPH-Pi2:/tmp/kiwi-captures $ lrt /usr/bin/wsprd*
>>> -rwxr-xr-x 1 root root 46376 May 30 17:32 /usr/bin/wsprd
>>> -rwxr-xr-x 1 pi   pi   79972 Oct 16 21:32 /usr/bin/wsprd.v2
>>> pi@KPH-Pi2:/tmp/kiwi-captures $
>>> 
>>> I can see from 'top' that my script is first executing wsprd.v2 and then 
>>> wsprd, so I am confident in my test methodology.
>>> Perhaps I am misusing wsprd.  Before processing each wav file I truncate 
>>> the ALL_WSPR.TXT file but leave the other files used 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 26, 2018 at 3:37 PM, Steven Franke via wsjt-devel 
>>> >> <mailto:wsjt-devel@lists.sourceforge.net>> wrote:
>>> > On Oct 26, 2018, at 2:21 PM, Jim Lill >> > <mailto:j...@jimlill.com>> wrote:
>>> > 
>>> > What is the method to verify my system is indeed enjoying the 1 dB SNR 
>>> > improvement that 2.0 gives?
>>> > 
>>> > Thanks
>>> &

Re: [wsjt-devel] wsjt-x 2 wspr SNR

[Steven Franke via wsjt-devel]

Hi Rob - 

Are you using the same command-line arguments that WSJT-X uses when it calls 
the decoder? The “Deep” decode setting in WSJT-X v2.0.0-rc3 uses “-C 5000 -o 
4”. 

Also, it is essential that the decoder in v2.0.0  have access to a 
well-populated hashtable.txt. Briefly, the enhanced sensitivity is obtained by 
invoking a new (to wsprd) decoding algorithm if the Fano algorithm fails. The 
new algorithm always returns a codeword, but only a fraction of these are 
“good”.  Many of the returned codewords are incorrect and would produce false 
decodes. Ideally, one would use a CRC to reject the incorrect codewords (as in 
FT8), but the WSPR message doesn’t include a CRC. Instead, we only accept 
codewords that unpack to callsigns that we’ve seen before, i.e. callsigns that 
are in the hashtable. If there’s no hashtable, then we will never accept any of 
the codewords from the new algorithm. This means that the v2.0.0 decoder 
becomes more sensitive than 1.9.1 to a particular callsign only after that 
callsign has been decoded at least once by the Fano algorithm.

Finally, decodes produced by the new decoding algorithm will have a “1” as the 
last number on the line that is printed in ALL_WSPR.TXT.  Fano algorithm 
decodes will show a “0”.

I’ve been very pleased with the results here. There have been many nights when 
all of my MF decodes of VK4YB were produced by the new algorithm.

I hope that this information is helpful,

73 Steve k9an

> On Oct 27, 2018, at 10:27 PM, Rob Robinett  wrote:
> 
> Hi Steve,
> 
> Jim's question was stimulated by tests I have been running at KPH to compare 
> the decode performance of the wsprd in 1.9.1 against the wsprd in 2.0rc3
> 
> My test setup is located at KPH where I have one KiwiSDR fed by a 3-30 Mhz  
> TCI-530 and a second KiwiSDR fed from a Marconi T.  I don't use the excellent 
> wspr decode extension included in the Kiwi, but instead run a bash script on 
> a Raspberry Pi 3B which records a 2 minute  wav file for each band from 2200M 
> through 10 M.  Each 2 minutes wave file is then fed first to wsprd 2.0 and 
> logged as KPH2 and then the sme wav file is fed to wsprd 1.9.1 and logged as 
> KPH.  After 24 hours I can find no difference between the KPH spots and KPH2 
> spots.
> 
> The wsprd binaries were obtained by downloading and installing packages from 
> the WSJT-x site and the binaries definitely are different sizes:
> 
> pi@KPH-Pi2:/tmp/kiwi-captures $ lrt /usr/bin/wsprd*
> -rwxr-xr-x 1 root root 46376 May 30 17:32 /usr/bin/wsprd
> -rwxr-xr-x 1 pi   pi   79972 Oct 16 21:32 /usr/bin/wsprd.v2
> pi@KPH-Pi2:/tmp/kiwi-captures $
> 
> I can see from 'top' that my script is first executing wsprd.v2 and then 
> wsprd, so I am confident in my test methodology.
> Perhaps I am misusing wsprd.  Before processing each wav file I truncate the 
> ALL_WSPR.TXT file but leave the other files used 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 26, 2018 at 3:37 PM, Steven Franke via wsjt-devel 
> mailto:wsjt-devel@lists.sourceforge.net>> 
> wrote:
> > On Oct 26, 2018, at 2:21 PM, Jim Lill  > <mailto:j...@jimlill.com>> 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 you can decode the saved batch of wav files using older 
> versions of WSJT-X and with new versions, and compare the yield. 
> 
> Suppose that you want to compare the WSPR decoder in WSJT-X v 1.9.1 to WSJT-X 
> v 2.0.0-rc3.
> 
> 1. Run with Save All to save a large batch of wav files.
> 
> 2. Delete ALL_WSPR.TXT. Start WSJT-X v 1.9.1  and use "File/Open" to select 
> the first (earliest) wav file in the batch that you saved. This will cause 
> WSJT-X to process that file. Next, select "File/Decode remaining files in 
> directory" to process the rest of the files. When you have finished 
> processing all of the files, ALL_WSPR.TXT will contain all of the decodes. 
> Rename ALL_WSPR.TXT to something different, such as ALL_WSPR_1.9.1.TXT, so 
> that it will not be overwritten or appended to by subsequent runs.
> 
> 5. Make sure that you have moved ALL_WSPR.TXT to a new filename. Start WSJT-X 
> v 2.0.0-rc3. Process all files. Rename your ALL_WSPR.TXT, e.g. to 
> ALL_WSPR_2.0.0.TXT.
> 
> 6. Use your favorite tools to compare the decodes in ALL_WSPR_1.9.1.TX

Re: [wsjt-devel] wsjt-x 2 wspr SNR

[Steven Franke via wsjt-devel]

> 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 you can decode the saved batch of wav files using older 
versions of WSJT-X and with new versions, and compare the yield. 

Suppose that you want to compare the WSPR decoder in WSJT-X v 1.9.1 to WSJT-X v 
2.0.0-rc3.

1. Run with Save All to save a large batch of wav files.

2. Delete ALL_WSPR.TXT. Start WSJT-X v 1.9.1  and use "File/Open" to select the 
first (earliest) wav file in the batch that you saved. This will cause WSJT-X 
to process that file. Next, select "File/Decode remaining files in directory" 
to process the rest of the files. When you have finished processing all of the 
files, ALL_WSPR.TXT will contain all of the decodes. Rename ALL_WSPR.TXT to 
something different, such as ALL_WSPR_1.9.1.TXT, so that it will not be 
overwritten or appended to by subsequent runs.

5. Make sure that you have moved ALL_WSPR.TXT to a new filename. Start WSJT-X v 
2.0.0-rc3. Process all files. Rename your ALL_WSPR.TXT, e.g. to 
ALL_WSPR_2.0.0.TXT.

6. Use your favorite tools to compare the decodes in ALL_WSPR_1.9.1.TXT and 
ALL_WSPR_2.0.0.TXT.

Here are some results that I obtained back in September:

Bands monitored: 160/80/40/30/20/17/15/10 (these were monitored simultaneously, 
using my SDR setup)
Start: 2018.09.13 0128
Stop:  2019.09.18 2046

Total 1.9.1 decodes: 45344
Total 2.0.0 decodes: 52126

(Number of 2.0.0 decodes) / (Number of 1.9.1 decodes) = 1.15

Thus, 2.0.0 increased the yield by 15%. 

Note that WSJT-X v1.9.1 contains enhancements that improve sensitivity over 
that of v1.8 and prior versions for highly coherent signals, as obtained on 
LF/MF and sometimes, on 160m. Thus, I would expect a somewhat larger yield 
difference if v2.0.0 was compared to v1.8. FWIW, the improvements in 2.0.0 are 
expected to increase sensitivity for all signals, regardless of how coherent 
they are.

YMMV! 

Steve k9an



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hound 77-bit

[Steven Franke via wsjt-devel]

> 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 
messages in RC3. This is in preparation for dropping support for 75 bit 
messages in RC4.
Steve K9AN

> 
> de Mike W9MDB
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc3

[Steven Franke via wsjt-devel]

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/Contents/MacOS
./wsjtx

Steve

> On Oct 17, 2018, at 10:31 AM, John  wrote:
> 
> Hi Bill,
> 
> Problem on my MacBook.
> 
> Running: /Users/jmn/Desktop/wsjtx.app/Contents/MacOS/jt9 -s WSJT-X -w 1 -m 3 
> -e /Users/jmn/Desktop/wsjtx.app/Contents/MacOS -a 
> "/Users/jmn/Library/Application Support/WSJT-X" -t 
> /var/folders/vv/5c1b7szs1bgbr65gkt6y0gnhgn/T/WSJT-X
> At line 145 of file /Users/bill/wsjtx-prefix/src/lib/ft8_decode.f90 (unit = 
> 81)
> Fortran runtime error: Cannot open file 'fort.81': Permission denied
> 
> 
> This is repeatable when I use FT8 mode.   It appears near the end of the 
> first decode sequence.In the temporary file:   WSJT-X I find decoded.txt 
> has been created but is empty.  Permissions are OK.
> 
> — John G4KLA
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Transmit signal problems

[Steven Franke via wsjt-devel]

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 above 12dB no 
> problem...power is spot on when PTT is asserted...but this is just a symptom 
> of what appears to be a bigger problem.
> 
> So I compared the signal being generated by RC2 with 1.9.1.
> The image included here is the tune signal from both WSJT-X versions going 
> through the same VB audio cable recorded with Audacity so the audio paths are 
> identical.
> 
> First signal is 1.9.1 tune button (looks fine) followed quickly by RC2's tune 
> button (yikes!!).  Both systems at full scale on the pwr slider.
> I would hope this can be duplicated on somebody else's system.
> And RC1 behaves badly too.

Just for the record, I have not been able to reproduce this issue here on OS X 
or Linux. I’m using latest development code - but nothing related to generation 
of the audio output has been changed since RC2.

Steve k9an

> 
> de Mike W9MDB
> 
> <1538576199416blob.jpg>
> 
> 
> 
> 
> <1538576199416blob.jpg>___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] TX 2.0 Not Resetting Properly

[Steven Franke via wsjt-devel]

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 page Red Bar TX 2.0 now reads ARRL FD.  Generated appropriate 
> messages.  TX 1 grayed out.  Went back to  and checked .  Red 
> bar persists reading TX 2.0 with no appended text.  TX1 still grayed out and 
> unable to access TX1.

At this point, you should be able to double click the TX1 button (under the 
“Now” label) to re-enable it.

> 
> I was only able to clear by shutting down and restarting WSJT-X 2.0.  With no 
> contest selected system TX1 no longer grayed out however Red Bar TX2.0  seems 
> to now be permanently displayed on main page.

I think that this will be because you have the “Always generate  77-bit 
messages” box ticked.

Steve k9an

> 
> Win 7.0 WSJT-X 2.0-rc2
> 
> John K4SQC
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Second subprocess failed

[Steven Franke via wsjt-devel]

> 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 it 3 times and it gave
> that error msg.
> Attached here, hpe it helps...
> 
> Jarmo

Thanks Jarmo. The wav file that you provided was a great help. I’ve found and 
fixed that bug. I expect the fix to be incorporated into the next release 
candidate.

Steve k9an




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Still might be something strange with EA1FA Decodes v2.0.0-rc2

[Steven Franke via wsjt-devel]

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 callsign as a 
hexadecimal number in a telemetry message. People running RC2 will decode this 
telemetry message and will display the hexadecimal number that it contains, 
which is EA1FA in the examples that you are seeing.  

In summary, what you are seeing is the result of a bug in the instance of 
WSJT-X RC1 that is transmitting the message, and not due to a bug in your RC2 
version of WSJT-X. The station that is transmitting the incorrect frames is not 
EA1FA — it is someone who is trying to send a message to EA1FA.

Those incorrect messages should disappear once everyone moves to RC2 or newer 
releases.

Steve K9AN

> On Sep 26, 2018, at 4:29 PM, Ken Miller  wrote:
> 
> I went ahead and reinstalled WSJT-X v2.0.0-rc2, just in case. Using Win10 on 
> a I-5 quad core. Attached is a screen shot and my ALL.TXT file. I reset it 
> right after re-installing rc-2. The type of decode I was questioning 
> yesterday is at 211315.
> 
> 
> Ken k6wgx
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Subprocess error

[Steven Franke via wsjt-devel]

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, at 9:49 AM, jarmo  wrote:
> 
>> 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  
> Hi Steve
> 
> Yes, there "were" .wav files, but stumbled with them, lost them.
> Not my day at all...
> 
> Jarmo
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Subprocess error

[Steven Franke via wsjt-devel]

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 -0400
> Joe Taylor  kirjoitti:
> 
>> Hi Jarmo,
>> 
>> Thanks for your report.
>> 
>> You had followed the instruction for beta testers and enabled "Save 
>> all", right?  Please send us the .wav file that was recorded just
>> before you received this error message.
>> 
>>  -- 73, Joe, K1JT
> 
> Hi Joe
> 
> I thought, I did mark "save all", this morning, but I marked "save
> decoded".
> Yes, I have read here and there, what to do, but my bad. Now it is
> "save all"... My humble apologies...
> 
> But, when this happened, I was only monitoring, no tx.
> 
> Jarmo
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Major Virus Like Bug in V2

[Steven Franke via wsjt-devel]

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 “Save all” turned on 
and, as in this case, if the problem involves behavior that is triggered by 
receiving a certain type of signal or message, please submit a saved wav file 
that triggers the problem with your bug report.

If you are not willing or able to do the careful documentation that is 
necessary to help us find and debug problems then, like Hasan, I recommend that 
you follow his lead:
> 
> Going back to 1.9 on 260, V2 abandoned until fixed.
> 


73 Steve k9an

> On Sep 19, 2018, at 10:52 AM, Hasan al-Basri  
> wrote:
> 
> When running MSK144, the program will start tx'ing some weird sounding 
> tones...they will "infect" any V2 MSK144 station that hears them and they 
> will start sending the same strange tones.
> 
> 5 of us have experienced this same bug...all simultaneously upon hearing 
> those "odd" tones.
> 
> I'm betting it is connected to the CM auto-correct code.
> 
> If you TX for a bit with v2 msk144, you WILL infect other listemers/
> 
> Going back to 1.9 on 260, V2 abandoned until fixed.
> 
> 73, N0AN
> Hasan
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Compiling WSJT-X on Mac

[Steven Franke via wsjt-devel]

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$ FC=gfortran-mp-5 \
> >cmake \
> >-D CMAKE_PREFIX_PATH="~/Qt/5.8/clang_64;~/hamlib-prefix;/opt/local" \
> >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
> >-D 
> > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
> >  \
> >~/wsjtx-prefix/src
> -- The C compiler identification is AppleClang 9.1.0.9020039
> -- The CXX compiler identification is AppleClang 9.1.0.9020039
> CMake Error at 
> /Applications/CMake.app/Contents/share/cmake-3.9/Modules/CMakeDetermineFortranCompiler.cmake:33
>  (message):
>   Could not find compiler set in environment variable FC:
> 
>   gfortran-mp-5.
> Call Stack (most recent call first):
>   CMakeLists.txt:25 (project)
> 
> 
> CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also "/Users/charlesrogers/wsjtx-prefix/build/CMakeFiles/CMakeOutput.log".
> Charless-MacBook-Pro-2:build charlesrogers$ 
>> On Jul 13, 2018, at 12:12 PM, Gary Rogers > > wrote:
>> 
>> OK i misunderstood…Deleted the whole WSJT-prefix and am rebuilding…Will 
>> advise
>> 
>>> On Jul 13, 2018, at 12:03 PM, Gary Rogers >> > wrote:
>>> 
>>> Couldn’t get that command to work but i found the folder in finder:
>>> 
>>> 
>>> 
>>> I did move the previous version of QT to the trash before installing 5.8
>>> 
>>> Here is the command i used:
>>> 
>>> FC=gfortran-mp-5 \
>>>cmake \
>>>-D CMAKE_PREFIX_PATH="~/Qt/5.8/clang_64;~/hamlib-prefix;/opt/local" \
>>>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>>>-D 
>>> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>>>  \
>>>~/wsjtx-prefix/src
>>> 
>>> 
>>> 
 On Jul 13, 2018, at 11:50 AM, Bill Somerville >>> > wrote:
 
 On 13/07/2018 16:41, Gary Rogers wrote:
> i just installed 5.8 and am getting the same errors about the qt5 widgets
> 
 Hi Gary,
 
 can you report back with the CMake configuration command you used please? 
 Note that reconfiguring a CMake build tree when you have changed package 
 locations will not usually work and you must delete the whole build tree 
 and configure from scratch again.
 
 Also what does the following command list?
 
 ls -l ~/Qt/5.8/clang_64/lib/cmake/Qt5Widgets
 
 73
 Bill
 G4WJS.
 
 
 --
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, Slashdot.org ! 
 http://sdm.link/slashdot 
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
 
>>> 
>> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

Hi Take,

Your textbook figure shows the difference in Eb/N0 required to achieve 10^-4 
BER on the AWGN channel, using single-symbol non-coherent detection. 

Please consider the fact that if the SNR is large enough to provide 10^-4 BER, 
then any of the JT modes would virtually never fail to decode. We would be 
operating like a commercial communications system, at SNR well above the 50% 
decoding threshold that is used to characterize the relative sensitivity of the 
different JT modes. 

Consider FT8 as an example - the error-correcting code that we use will decode 
about half of the frames having 26 bit errors (out of 174 total bits). This 
means that our 50% decoding threshold is obtained at a BER of approximately 
26/174=0.15. This is more than 3 orders of magnitude larger than the BER in 
your textbook Figure. 

At the BER corresponding to the FT8 detection threshold, you will find that the 
advantage of 64FSK over 8FSK is relatively small, as I stated earlier.  

As I also stated earlier, any near-threshold-SNR advantage of 64FSK can be 
completely erased if the 8FSK signal is detected on the basis of groups of 
symbols using a technique called “noncoherent sequence detection”.  The 
efficacy of sequence detection is not just something that I read about in a 
textbook.  This idea has been implemented in the improved WSPR decoder that was 
released in version 1.8, where the detection threshold has been improved by 
almost 3 dB for highly coherent MF and LF signals.

Finally, you have not commented on the comparison that I presented earlier 
where I scaled QRA64 to the same total transmission time as FT8, and I showed 
that their detection threshold were virtually the same. If 64FSK has a large 
advantage of 8FSK at the relevant SNRs, then how do you explain the parity 
between scaled QRA64 and FT8?  

My assertions are not based on textbook figures. They are based on results 
obtained from realistic simulations, using detection and decoding algorithms 
implemented in computer programs written by Nico, Joe, and me. You have 
asserted that it should be possible to send nearly 5 times as many bits as FT8 
sends, in the same amount of time, while improving the decoding threshold by up 
to 1 dB over the current FT8 threshold. As Joe has already said, we invite you 
to prepare some code that demonstrates your assertion. 

73, Steve k9an

> On Jul 5, 2018, at 10:39 PM, Tsutsumi Takehiko  wrote:
> 
> Hi Steve,
>  
> This is a result of my searching “modulation theory book” in my shelves.
>  
> See the attached copy and Figure 1.1 in Japanese.
>  
> It indicates the degradation of EB/N0 by the increase of M concerning M-FSK 
> and this curve contradicts your “the energy-per-bit is the same, either way” 
> in your previous memo.
>  
>  
> Regards,<5CCC4EC6C6A94E25B2652B3E05EAC86F.jpg>
>  
> take
>  
> de JA5AEA
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Tsutsumi Takehiko mailto:ja5...@outlook.com>>
> Sent: Wednesday, July 4, 2018 10:20:16 PM
> To: WSJT software development
> Cc: Steven Franke
> Subject: RE: [wsjt-devel] Observation on Expedition Mode
>  
> Steve,
>  
> Thank you for your comments.
>  
> Ok, I understand what is the disagreement between us.
>  
> First, I do not fully understand the point why you object my +4dB gain but I 
> need to find modulation theory book in my book sheves (never opened for more 
> than 20 years) and check about “ *bit* SNR, Eb/N0” related area before my 
> final response. If I can not solve for myself, I can call my local experts 
> without bothering you anymore.  But, I am thinking the longer symbol proposal 
> does not heart any RF performance including the delay spread, fading 
> performance, interference performance and a fraction of a dB gain with 
> non-coherent detection given from you is another goody.
>  
> Concerning the “second +4dB term”, I remember Bill’s suggestion included 
> hashing of callsign (I used the number of (28-15) x 5 = 65 bit reduction). I 
> also reduced five 7x7 synch to one 7x7 synch, which I am not sure whether 
> Bill included. I will not further describe the details to defend my ballpark 
> number but I can say I disagree with your 0.6dB gain calculation, here.
>  
> Thank you very much spending your precious time to comment on my +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 Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Steven Franke via wsjt-devel  <mailto:wsjt-devel@lists.sourceforge.net>>
> Sent: Wednes

Re: [wsjt-devel] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

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 what should be possible?

>  
> By the increase of symbol length to 64mS (FT64) and 74.7mS (FT128) from 32mS 
> (from 160mS FT8 symbol length speed up by factor 5), the gain is 10LOG(64/32) 
> = +3dB and 10LOG(74.7/32) = +4dB. 

You have shown that the *symbol* SNR (Es/N0) will be doubled if we use 64FSK 
instead of 8FSK, but what matters is the *bit* SNR, Eb/N0. 

A single 64FSK symbol conveys 6 bits of information, whereas the 8FSK symbol 
conveys only 3 bits. You neglected to factor this into your calculations. While 
the 64ms 64FSK symbol contains twice the energy of the 32ms 8FSK symbol, the 
energy-per-bit is the same, either way. 

There *is* a slight modulation-detection-efficiency advantage to using 64FSK 
instead of 8FSK if the symbol detection is done noncoherently on a 
symbol-by-symbol basis, but the gain is fraction of a dB.  Furthermore, any 
such advantage vanishes if the 8FSK demodulator is configured to detect 
sequences of, say, 2 or 3 symbols rather than individual symbols.

In any case, the 64FSK vs 8FSK advantage was already included in the scaled 
QRA64 example that I described earlier.  I stand by my conclusions. 

I also fully agree with Joe’s objection to your "second" +4dB term. Each FT8 
message conveys 75 bits. If we send five of them serially, then we are sending 
375 bits.  If we were to combine the essential information into a single 
packet, it would need to convey a total of 11 callsigns (the Fox call, 5 calls 
to be printed with RR73, and 5 calls to be printed with signal reports_ plus 5 
signal reports. This is a total of 11*28 + 5*3 where I have conservatively used 
only 3 bits for each signal report. Thus, the available savings is 
10*log10(375/323) = 0.6 dB. 

73, Steve k9an


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

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 losses, the number is about 
-26 dB. The duration of a QRA64 message is 48.4s.

The 50% decoding threshold of standard FT8 on the AWGN channel (including sync 
losses) is about -20.5 dB and the duration of an FT8 signal is 12.6 seconds.

Note that the QRA64 signal contains a 72-bit message payload, whereas FT8 
conveys a 75-bit payload. Let’s ignore the fact that FT8 conveys more bits for 
the moment.

If we shorten the QRA64 signal by a factor of 48.4/12.6=3.84 so that it has the 
same 12.6s duration as an FT8 signal, it’s decoding threshold would be 
increased by 10*log10(3.84)=5.8 dB, resulting in a decoding threshold of -26.0 
+ 5.8 = -20.2 dB, about 0.3 dB worse than FT8. The bandwidth of the sped-up 
QRA64 signal would be 3.84*111 Hz = 426 Hz, or a factor of 8.5 times the 
bandwidth of FT8.

The nearly equal sensitivity of FT8 and QRA64 (scaled to the same duration as 
FT8) would be maintained if both signals were sped up by a factor of 5, say. In 
that case, the decoding threshold of both signals would increase by 7 dB. The 
bandwidth of the sped-up FT8 signal would be 250 Hz, and the bandwidth of the 
QRA64 counterpart would be 5*426=2.1 kHz.

> 65% packed message length base on Bill’s suggestion : +4dB gain

Of course, I agree that some gain would be available from careful source 
encoding, rather than just sending 5 standard messages serially.

73 Steve, k9an


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on Expedition Mode

[Steven Franke via wsjt-devel]

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 always, the Deserving 
will work the DX.

Steve k9an

> On Jul 3, 2018, at 9:43 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Surely you jest...nobody reading directionslarge % calling in the 
> blindand they are going to learn how to control themselves based on sig 
> reports and slots?  Not only do the majority not understand how slots affects 
> anything but they won't care either.
> 
> de Mike W9MDB
> 
> 
> On Tuesday, July 3, 2018, 9:38:17 AM CDT, Joe Taylor  
> wrote:
> 
> 
> Grant --
> 
> I understand your story -- and of course the way the link budget depends 
> on the number of slots in use.
> 
> I do not think that making Fox weaker (i.e., always 20 W per signal) is 
> likely to increase QSO rate.  Better that Fox and Hound operators should 
> take note of signal reports each way, learn to recognize and take 
> advantage of the dependence of Fox's signal strength on Nslots, and 
> decide accordingly when to call.
> 
> -- Joe, K1JT
> 
> On 7/3/2018 10:11 AM, Grant Willis wrote:
> > Joe,
> > 
> > Thanks for the reply. Yes it seemed to be going pretty well today on 40m
> > (although the pileup was immense). Looked like definitely 100+ QSO/hr was
> > being achieved which is faster than they were managing on RTTY on 40m the
> > night before.
> > 
> > Your idea of changing the fox signal to a different multiplex but single FSK
> > signal would definitely be one way and the 7dB would help - but I was more
> > thinking is there something we can do so that the per channel power is
> > reduced to be equivalent to the worst case power reduction with 5 channels
> > (or whatever the channel limit was that the operator set) when less carriers
> > are transmitting.
> > 
> > IE. If when transmitting 5 slots I can only send 20W/carrier - then when I
> > am running 4 slots - still only run 20W/carrier but accept that your total
> > combined output power will drop - doesn't matter however as the link budget
> > is set by the individual channel power not the TX total power capacity. Even
> > if you only run one sub-carrier hold it at 20W. I am looking at it from the
> > maintain constant sub-channel power rather than the use all the available
> > power regardless of the number of channels perspective (which is what causes
> > the sub-channel power to vary up to 14dB between 1 and 5 channels active).
> > 
> > Practically, I was seeing good decodes at 3 channels on 20m the other day
> > which for a 500W amp would have been around 50W/carrier - if they had
> > limited the number of channels to 3 and no one channel was ever allowed to
> > send more than 50W as the channel count varied people would have been
> > working against a constant link budget and I feel would have had a better
> > chance of not breaking the QSOs. As it was, whenever the 4th channel
> > appeared I struggled to decode them and if the 5th channel appeared I never
> > decoded them that day. If there were three channels active and they answered
> > me by bringing up the 4th (which I think they did on a couple of occasions)
> > I lost them and could never complete the QSO. It was from that perspective
> > that I made my observations.
> > 
> > FWIW and further comment?
> > 
> > Regards,
> > Grant VK5GR
> > 
> > 
> > -Original Message-
> > From: Joe Taylor [mailto:j...@princeton.edu ]
> > Sent: Tuesday, 3 July 2018 10:55 PM
> > To: WSJT software development; Tsutsumi Takehiko
> > Subject: Re: [wsjt-devel] Observation on Expedition Mode
> > 
> > Hi Grant, Take, and all,
> > 
> > I think the Fox operators are learning to manage their pileups
> > reasonably well.  I listened and watched the show on 40m this morning
> > for ~2.5 hours, with good signals from Fox.  The Op was doing a good
> > job: he was using 2 slots, thereby keeping the queue moderately short.
> > He must have been running ~100/hr.
> > 
> > Most Hounds are learning the proper operating techniques, too.  On 40m
> > today there were very few calling below 1000 Hz or on the wrong sequence.
> > 
> > I am looking forward to "de-briefing" the Fox operators after they
> > return home!
> > 
> > As long as we use the present scheme of frequency-multiplexing multiple
> > slots, there's not much we can do about power levels.  Fox is already
> > transmitting the strongest undistorted signal he can generate, in each
> > slot.  It's up to the operators on both sides to watch the signal
> > reports, recognize and take advantage of the dependence of signal
> > strength on Nslots, and decide accordingly when to call.
> > 
> > There exists a potentially attractive design alternative.  Rather than
> > transmitting up to 5 signals spread over the range 300-600 Hz, we

Re: [wsjt-devel] Fortran Runtime Error

[Steven Franke]

Hi John,

I am able to reproduce this problem, but only if the Start frequency on the 
wide graph is set equal to 5000 Hz. Can you verify that this is the condition 
under which the error message was generated?

Steve K9AN

> On Jun 28, 2018, at 6:58 AM, John  wrote:
> 
> Apologies:  my email about problems with 10.13.5 should have had a subject 
> heading   Fortran Runtime Error and not Hound Mode setting:
> 
> —
> I have had report from a Mac user (10.13.5) which appears immediately after 
> launching 1.9.1 taken from the WSJT-X web-page:
> 
> Running: /Applications/wsjtx.app/Contents/MacOS/jt9 -s WSJT-X -w 1 -m 1 -e 
> /Applications/wsjtx.app/Contents/MacOS -a 
> "/Users/fredhurd/Library/Application Support/WSJT-X" -t 
> /var/folders/2w/64f2h1r151q0nk0ny5jl6rmrgn/T/WSJT-X
> At line 104 of file /Users/bill/wsjtx-prefix/src/lib/ft8/sync8.f90
> Fortran runtime error: Index '0' of dimension 1 of array 'indx' below lower 
> bound of 1
> 
> I cannot reproduce this error…Bill, do you have advice about:  
> /Users/bill/wsjtx-prefix/src/lib/ft8/sync8.f90 ?
> 
> — John G4KLA
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-x Eqalization

[Steven Franke]

Hi Saku,

I think that you must be referring to the "Equalization Tools…" button that 
shows as “Don’t Save” on my linux box and as “Discard” on MacOS and Windows. 
This button is doing what it is supposed to do, as explained in the User Guide, 
section 13.3:

"Click the Discard button to remove the captured data, leaving only the applied 
phase equalization curve and corresponding group delay curve.” 

If you do not have any measured/captured data plotted, then the button will 
appear to do nothing.

Until now, I wasn’t aware that the name can show up differently on different 
platforms. Bill has explained that this is because we used one of Qt’s standard 
buttons. For the next release, we’ll define a custom button with a more 
descriptive label that will show up the same way on all platforms. 

Thanks for pointing this out!

Steve, k9an

> On Jun 8, 2018, at 8:19 AM, Saku  wrote:
> 
> Hi !
> 
> Looked (first time) the Eqalization Tools window and noticed that button 
> "Close without saving" does nothing.
> Expect that pressing it would close the window like "Close" button does.
> 
> I have 2 (linux) versions to test with:  1.8.0 and 1.9.1 r8733-dirty.
> 
> Both are working same way. I.E. button is not working at all.
> 
> Minor bug and probably someone has already informed about it.
> (Just in case nobody didn't)
> 
> -- 
> Saku
> OH1KH
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible error 1.90rc4 Mac

[Steven Franke]

Hi George - 

Thanks for the report. I think that the problem is being caused by a debug 
write statement that is being used for Fox/Hound debugging purposes --- it will 
be easy to fix and we will do that before the GA release. However, I should 
note that the problem is occurring because a double-click on the waterfall 
invokes the “click to decode” function, and initiates a call to the decoder 
with the deepest decode settings. 

If you are wanting to move the Tx and Rx frequencies, then a command-single 
click should do that without calling the decoder.

Steve K9AN


> On May 1, 2018, at 10:57 AM, George Molnar  wrote:
> 
> I’ve had this reproducible error occur a few times now. 1.90rc4 (8642) 
> downloaded from the WSJT-X homepage crashes when command-double clicking on 
> the FT8 wide graph to change DF only after at least one decode cycle has 
> completed. I had not seen this before 8642.
> 
> OSX 10.13.5 beta, quad core i7 with 16 GB RAM.
> 
> Running: /Applications/wsjtx.app/Contents/MacOS/jt9 -s WSJT-X -w 1 -m 3 -e 
> /Applications/wsjtx.app/Contents/MacOS -a 
> "/Users/georgemolnar/Library/Application Support/WSJT-X" -t 
> /var/folders/6j/2m5xrjn13s7c7k9fqv7vmp04gn/T/WSJT-X
> At line 98 of file /Users/bill/src/wsjtx-svn/lib/decoder.f90 (unit = 19)
> Fortran runtime error: Cannot open file 'fort.19': Permission denied
> 
> Error termination. Backtrace:
> #0 0x10d134ab6
> #1 0x10d135388
> #2 0x10d1359ec
> #3 0x10d1b5cca
> #4 0x10d1aea5d
> #5 0x1050f0f30
> #6 0x1050cada2
> #7 0x1050ca6a7
> #8 0x10513fbae
> 
> 
> George J Molnar
> Washington, DC, USA
> KF2T   -   @GJMolnar
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r8603 power at qso start

[Steven Franke]

Hi Mike, 

I don’t see any evidence of problems when I look at the WSJT-X Tx audio 
directly. I’ve attached a screen shot showing my recording of the Tx audio. I 
captured this audio by routing the WSJT-X TX audio through SoundFlower (an 
audio loopback device) and into the Audacity sound editor on my OS X machine. 
This plot shows about 700ms of audio.  

Steve k9an


> On Apr 5, 2018, at 10:43 PM, Black Michael via wsjt-devel 
>  wrote:
> 
> I found that this is related to the Tx delay settings.
> 
> The lower the Tx delay setting (< 0.2) the more max amplitude at the  
> beginning of the audio.
> 
> At 0.2 there's just a small portion but this may help explain why many people 
> have RF problems when Tx starts.
> 
> <1522968118900blob.jpg>
> de Mike W9MDB
> 
> 
> 
> <1522968118900blob.jpg>--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X v1.9.0-rc2 fox mode anomaly (Windows)

[Steven Franke]

Hi Joe and John,

I wonder if John’s observation relates to the fact that switching from Fox mode 
to Hound mode will not change which Tab is currently visible. 

When the user selects Fox mode, WSJT-X will automatically select Tab 3. If Fox 
mode is then turned off, or if Hound mode is selected, Tab 3 will remain the 
visible Tab and the user will need to manually select either Tab 1 or Tab 2.

Steve k9an

> On Mar 15, 2018, at 7:57 AM, Joe Taylor  wrote:
> 
> Hi John,
> 
> On 3/15/2018 1:02 AM, John S. Howell, Jr. AF3K wrote:
>> Exploring the new release and found what seems like a minor bug:  
>> Un-checking fox mode does not return the main screen to non fox mode.
>> To replicate:
>> File -> Settings ->Advanced
>> Check Fox FT8 DXpedition mode & click OK.
>> Main screen is updated to Fox mode + fox log window- (all OK).
>> File -> Settings ->Advanced
>> Un-check Fox mode & click OK
>> log window disappears but main screen stays in fox mode
>> Terminating and restarting does not fix it.
>> Workaround is to enter hound mode, then exit hound mode.
>> 73, AF3K
> 
> Thanks for your report.  You do not mention what OS you are running under.  I 
> tried here in both Windows and Linux, and it behaves correctly.  Following 
> your recipe, I cannot reproduce the undesired effect that you describe.
> 
>   -- Joe, K1JT
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Add ft8d and ft8sim to makefile?

[Steven Franke]

Hi Rockwell,

The development routine ft8d is not what you want for a stand-alone 
command-line decoder. It is not kept up-to-date. Every now and then, when we 
are testing a new feature or debugging a particular issue, we’ll bring it up to 
date for that purpose. But at any given instant in time, it may not be 
functional. I believe that this is one of those instants. At present, it is not 
even being compiled.

For command-line decoding of saved wav files, jt9 with the -8 command-line 
option should do want you want.

For simulation, the ft8sim executable should be found in your build directory, 
assuming that you are building the development versions yourself.

73, Steve k9an

> On Mar 6, 2018, at 8:13 PM, Rockwell Schrock  wrote:
> 
> Hi folks,
> 
> I am interested in integrating some software with FT8 by passing audio files 
> into and out of the FT8 modem as provided by WSJT-X. I'm no FORTRAN 
> developer, but it appears that I could utilize the `ft8d` command-line 
> utility to decode WAV files, and `ft8sim` to generate them. Is that a 
> reasonable approach?
> 
> If so, could we get `ft8d` and `ft8sim` executables added to the WSJT-X 
> outputs, alongside jt9, jt65code, etc.?
> 
> Thanks,
> 
> Rockwell WW1X
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Timer

[Steven Franke]

Hi Jim, 

Check out item 12 in the Hound instructions:

“12. After you receive a signal report from Fox, WSJT-X will automatically send 
your next transmission as message Tx 3 (“R+rpt”) at a randomly chosen frequency 
between 300 and 900 Hz. Note that WSJT-X will send this message even if Enable 
Tx is disabled, and even if you have not called Fox for several Tx sequences. 
If you have stopped calling Fox because you will be leaving the rig unattended, 
you should quit WSJT-X or disable Hound mode in order to avoid the possibility 
of unwanted transmissions."

It is important to understand this behavior. It means that, in most cases, you 
should not just leave your rig on and monitoring the DX after you have stopped 
paying attention, as you could be in for a surprise when your rig springs to 
life and starts TXing.

Steve K9AN

> On Mar 7, 2018, at 10:05 AM, James Shaver  wrote:
> 
> Yep, twice the timer had expired on me right as the “Fox” called me and I had 
> to scramble. 
>  
> Jim S. 
> N2ADV
>  
> From: Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: Wednesday, March 7, 2018 11:03 AM
> To: WSJT Software Development
> Cc: Bill Turner
> Subject: [wsjt-devel] Timer
>  
> Great job with the test last night.  I did find the 2 minute timer to be a 
> real pain, however. I understand you do not want a robot operation, but a 5 
> or 10 minute timer would be less frustrating.
>  
> When the software shuts off the Enable TX, how do we know that we are still 
> on the correct sequence when we click on Enable TX?  I noticed some comments 
> about folks calling on the wrong sequence last night.
>  
> Again, thanks for the effort in the test.
>  
> Bill Turner, W4WNT
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] jt9a memory leak

[Steven Franke]

Mike,

> Have you looked a the jt9 process though?

Yes. I checked the numbers again just now. There was no change in memory usage 
associated with the jt9 process over more than 12 hours since I checked last 
night.  

> Doug and I both see it growing pretty rapidly.  About every 4 minutes.  I'll 
> have to check with him about what version of Ubuntu he has.
> But what gcc version do you have?  Ubuntu 17.10 has gcc 7.2

I have gcc5.

Steve k9an--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] jt9a memory leak

[Steven Franke]

Hi MIke and All,

> I don't know if you have a Unix system to test but the jt9 process under 
> Ubuntu is leaking memory quite considerably as has already been reported by 
> Doug VE7GNU.
> It's not as visible under Windows.

FWIW — I run the latest development version(s) under Ubuntu 16.04 LTS. I 
haven’t been able to find evidence of a memory leak. I routinely run for many 
days in a stretch monitoring FT8 on crowded bands, with no trouble and no 
significant change in the memory footprint of WSJT-X. 

Steve k9an


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] channel description

[Steven Franke]

Don,

> It seems that by assuming a correct decode (and a time-invariant transmitter) 
> each user could store enough information (already supported by the SW) to 
> describe the channel statistics.  I see hints that you are trying to provide 
> the capability to describe the transmitter, but what about the larger 
> question of the channel?  Is there a behavior whereby a large body of users 
> could help describe the channel in a cooperative manner? 

The FT8, JT65, and WSPR demodulator/decoders estimate the channel for each and 
every decode. Given the decoded message we regenerate the transmitted waveform 
and use that as a reference to derive the time-varying, complex, gain function 
that describes the channel. We use this to reconstruct a (nearly) noiseless 
version of the received signal’s waveform that includes the channel-induced 
amplitude fading and phase-variation. The reconstructed signal is subtracted 
from the received data, enabling us to uncover weaker signals that occupy the 
same frequency slot as the subtracted strong signal. These weaker signals can 
often be decoded on a second decoding pass, after the stronger signals have 
been subtracted.

Steve K9AN
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Remove me from the mailing list.

[Steven Franke]

Iz6gvc

You can remove yourself. Follow the link at the end of every message:

> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
Then follow the link under “Unsubscribe & Settings”.

Steve k9an

> On Jan 25, 2018, at 10:33 PM, iz6gvc--- via wsjt-devel 
>  wrote:
> 
> Please, remove this email from your mailing list, I'm not member.
> 
> 
> 
> Thanks and 73s
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] choosing the best CRC for short data blocks

[Steven Franke]

>  They all reduce the number of incorrect decodes by about a factor of 
> 2^12=2048.
> 

Obviously, I have a problem with basic arithmetic. I should have said 2^12=4096.

Steve k9an



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] choosing the best CRC for short data blocks

[Steven Franke]

Hi Don,

To add to what Joe and Bill have already said, I’d like to point out that 
Koopman’s tables are not particularly relevant for our application. The FT8 
decoder always produces a valid 174-bit codeword that satisfies all parity 
checks. In other words, the decoder always return a codeword from the codebook 
defined by our (174,87) LDPC code. The purpose of the CRC is to help us 
determine when the decoder has returned the wrong codeword. As it turns out, 
the most likely number of incorrect bits in the 87-bit message+CRC block 
contained within incorrect codewords is 20. This is "off the charts” as far as 
Koopman’s tables go. I have not found any reason to believe that selecting a 
polynomial that is optimum for a Hamming distance (HD) of 4, say, has any 
bearing on how it would perform with typical incorrect codewords having HD=20. 
This is why we have resorted to long simulations to evaluate the performance 
that is available from different CRC polynomials. In fact, our simulations 
showed very little difference in the performance of various 12-bit CRCs from 
Koopman’s table. They all reduce the number of incorrect decodes by about a 
factor of 2^12=2048.

73,
Steve k9an

> On Jan 25, 2018, at 2:21 PM, Joe Taylor  wrote:
> 
> Hi Don,
> 
> Thanks for your message and your interest in FT8, etc.
> 
> We're well aware of the tables of "good CRC polynomials" published by 
> Koopman, though admittedly we have not always used them to best advantage.
> 
> Steve Franke, K9AN, did an extensive series of tests with different CRC 
> generators when used with the 75-bit information block in FT8.  The CRC12 
> used in FT8 is slightly sub-optimal, but the resulting increase in undetected 
> error rate is only a factor of 1.6.  Since the error rate is already very 
> low, the consequences are not serious.
> 
>   -- Joe, K1JT
> 
> On 1/25/2018 2:23 PM, Don Goldston wrote:
>> Sirs,
>> I have not delved into your software, and being old and retired I may not do 
>> so.  From the superficial descriptions of FT8 I have found, your group seems 
>> to know very well what they are doing.
>> https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
>> Here is a link to a paper on CRCs that you should consider for future design 
>> work.  The paper gives the best CRC of a given length for a data block of a 
>> given length.  You can potentially have equal or better corruption detection 
>> with a smaller CRC, Examine table 3 carefully.  I believe you could use an 8 
>> bit CRC (0x97) for data blocks of up to length 119 bits and achieve a 
>> hamming distance of 4,  which is equal to or better than the performance 
>> achievable with the optimal 12 bit CRC at data block lengths above 53 bits 
>> in length.
>> It may be too late to impact FT8, but the principles outlined in the paper 
>> can save you a few bits in future development.
>> As a general caution, be aware that previous published "standard" and "good" 
>> CRCs, may not be the best even at long block lengths.
>> If you were already aware of this paper, please forgive me for wasting your 
>> time.
>> Is there a more detailed description of the various modes available to 
>> members of this list?  I am a new ham, but did waveform design and optimal 
>> detection for many years until I retired last May.   I may be able to help 
>> in some manner.
>> 73,
>> Don Goldston, AE0AG
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Inconsistent JT65b reporting

[Steven Franke]

Hi Charlie,

Thanks for the report!

It seems clear that WSJT has a negative SNR bias across the board. The version 
of WSJT-X (r8345) that you used has a smaller bias. If you get a chance to test 
r8389 or later, I’d be interested to hear whether the tweaked SNR calculation 
improves matters in WSJT-X. 

I found your SNR=-22 dB case to be interesting. WSJT-X was able to decode 8 of 
the 10 files just using the standard soft-symbol Franke-Taylor decoder. The 
remaining two files were decoded using AP decoding. The correlation decoder 
(deep search) was never invoked. On the other hand, only 1 out of 10 files was 
decoded by WSJT using the soft-symbol decoder. The remaining 9 required deep 
search. This large difference suggests that if you leave Deep Search and AP 
decoding out of the picture, and consider just basic soft-symbol decoding, 
WSJT-X probably has a lower (better) decoding threshold - at least for the 
parameters that you tested.

Steve k9an


> On Jan 3, 2018, at 12:43 PM, Charles Suckling 
>  wrote:
> 
> Hi Steve, Bill and Joe
>  
> I've done some more simulation work with the new jt65sim.
>  
> Results are here:
>  
> https://drive.google.com/file/d/1qeTkWiHaNafMqYKlAHW8NaRNGYk1BCn0/view?usp=sharing
>  
> <https://drive.google.com/file/d/1qeTkWiHaNafMqYKlAHW8NaRNGYk1BCn0/view?usp=sharing>
>  
> 73
>  
> Charlie
>  
> -Original Message-
> From: Steven Franke [mailto:s.j.fra...@icloud.com] 
> Sent: 02 January 2018 14:50
> To: WSJT software development
> Subject: Re: [wsjt-devel] Inconsistent JT65b reporting
>  
> Hi Charlie,  Bill, and all,
>  
> > I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and
> > no DS did not decode anything, whereas it gets 2/10 with 12000 sample
> > rate.  It does OK however  with DS with these -23/40Hz 11025 signals. 
> > Perhaps the resampling on very marginal signals like this is responsible?
>  
> I think that you need to look at a larger sample to decide whether or not the 
> decode probability is different between the two sample rates. 
>  
> I used the following to generate 100 JT65C files at SNR=-23 dB with 40 Hz 
> Doppler spread, at sample rate 12000 /s:
>  
> ./jt65sim -d 40.0 -m C -n 1 -F 1200.0 -t 2.5 -f 100 -s \\-23 -G 10 -M "K9AN 
> G3WDG RRR”
>  
> With AP decoding enabled, G3WDG in the Dx Call box, and Tx5 selected, I got 
> 34/100 decodes. All decodes were AP decodes with aptype=3 or 4. Deep Search 
> was not enabled.
>  
> Then, I repeated the experiment with -S added to the command line so that the 
> files were generated with 11025 /s rate. When WSJT-X detects a wav file with 
> 11025/s rate, it calls Joe’s wav12.f90 resampler to resample the data to 
> 12000/s. In this case I got 38/100 decodes. 
>  
> It’s worth noting that we expect the number of good decodes to have a 
> binomial distribution. The standard deviation of the binomial distribution is 
> sigma = sqrt( n*p*(1-p) ) where n is the sample size and p is the decode 
> probability. My results with 100 simulated wav files suggest that the decode 
> probability for the case that we are considering is somewhere in the 
> neighborhood of 0.36. With a sample size of 100, and p=0.36, the standard 
> deviation of the binomial distribution is sqrt(100*0.36(1-0.36))=4.8. 
>  
> Thus, the difference between my results with sample rate 12000 (34/100 
> decodes) and sample rate 11025 (38/100) is not statistically significant, 
> i.e. the observed differences are of the same order as the differences that 
> we’d expect if we just processed two different groups of files, with the same 
> underlying decode probability for each group. 
>  
> In summary, there is no evidence (so far) that resampling in WSJT-X causes 
> any degradation in decoding performance. It would take many more trials 
> (>1000) to be able to detect any differences in WSJT-X’s decode probability 
> at the two sample rates. Of course, this experiment does *not* address what 
> happens when the operating system does the resampling, as would be the case 
> when processing audio data in real time.
>  
> Steve k9an
>  
>  
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://slashdot.org/>! 
> http://sdm.link/slashdot <http://sdm.link/slashdot>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>

Re: [wsjt-devel] Inconsistent JT65b reporting

[Steven Franke]

Hi Charlie,  Bill, and all,

> I also tried 40Hz spreading at -23 with 11025 with WSJT-X and found AP and
> no DS did not decode anything, whereas it gets 2/10 with 12000 sample
> rate.  It does OK however  with DS with these -23/40Hz 11025 signals. 
> Perhaps the resampling on very marginal signals like this is responsible?

I think that you need to look at a larger sample to decide whether or not the 
decode probability is different between the two sample rates. 

I used the following to generate 100 JT65C files at SNR=-23 dB with 40 Hz 
Doppler spread, at sample rate 12000 /s:

./jt65sim -d 40.0 -m C -n 1 -F 1200.0 -t 2.5 -f 100 -s \\-23 -G 10 -M "K9AN 
G3WDG RRR”

With AP decoding enabled, G3WDG in the Dx Call box, and Tx5 selected, I got 
34/100 decodes. All decodes were AP decodes with aptype=3 or 4. Deep Search was 
not enabled.

Then, I repeated the experiment with -S added to the command line so that the 
files were generated with 11025 /s rate. When WSJT-X detects a wav file with 
11025/s rate, it calls Joe’s wav12.f90 resampler to resample the data to 
12000/s. In this case I got 38/100 decodes. 

It’s worth noting that we expect the number of good decodes to have a binomial 
distribution. The standard deviation of the binomial distribution is sigma = 
sqrt( n*p*(1-p) ) where n is the sample size and p is the decode probability. 
My results with 100 simulated wav files suggest that the decode probability for 
the case that we are considering is somewhere in the neighborhood of 0.36. With 
a sample size of 100, and p=0.36, the standard deviation of the binomial 
distribution is sqrt(100*0.36(1-0.36))=4.8. 

Thus, the difference between my results with sample rate 12000 (34/100 decodes) 
and sample rate 11025 (38/100) is not statistically significant, i.e. the 
observed differences are of the same order as the differences that we’d expect 
if we just processed two different groups of files, with the same underlying 
decode probability for each group. 

In summary, there is no evidence (so far) that resampling in WSJT-X causes any 
degradation in decoding performance. It would take many more trials (>1000) to 
be able to detect any differences in WSJT-X’s decode probability at the two 
sample rates. Of course, this experiment does *not* address what happens when 
the operating system does the resampling, as would be the case when processing 
audio data in real time.

Steve k9an


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Inconsistent JT65b reporting

[Steven Franke]

Hi Bill,

> Steve, I am unsure about a couple of the changes I have made, particularly 
> the limited slice of the cdat complex array used when applying the Rayleigh 
> fading model on line 275 (necessary to avoid an array bounds violation when 
> using 11025 Hz rate), and whether I should apply clipping to 16-bit full 
> scale after applying the gain offset at line 288. I also don't understand 
> what line 287 is doing as it seems to apply a normalization factor 'fac' that 
> I would expect to be applied on line 288 yet that line used a fixed factor of 
> 100.0 (`rms`). Perhaps you can review my changes and advise?

I think that jt65sim is working properly in r8391. The fac vs rms thing was 
taking care of a hidden feature, whereby the simulator generates a noiseless 
signal whenever the requested SNR exceeds 90 dB. That wasn’t working properly 
with nonzero Doppler spread, even in the original version, because the peak 
amplitude is random - so I made some changes that will cause a noiseless 
(SNR>90 dB) signal to be scaled so that the (random) peak magnitude is 32767. 

I also changed the hardwired Nyquist frequency from 6000.0 to (fsample/2) so 
that the noise should be scaled properly for either sampling rate.

With the new option for an arbitrary “gain offset", I decided that it would 
also be worthwhile to print a warning if the simulated data is clipped in the 
wav file. The user should probably re-run with a smaller gain value if clipping 
is detected.

Steve k9an



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Inconsistent JT65b reporting

[Steven Franke]

Hi Bill,

> I believe you are now using git-svn, if so you can review the real changes 
> with a command like:
> 
> git show -w `git svn find-rev r8388`

Thanks - this came while I was writing the last message. I will look at the 
Watterson subroutine and make sure that it’s working OK with the 11025 kS/s 
rate.

Steve



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Inconsistent JT65b reporting

[Steven Franke]

Hi Bill  and Charlie,

In r8389 I’ve attempted to improve the calibration of JT65 VHF/UHF/Microwave 
SNR estimation. It looks like Joe may have originally tuned the SNR estimates 
for the large Doppler spread/JT65C cases. I’ve switched it around a bit to 
favor small to moderate Doppler spreads. In any case, accuracy will depend on 
mode, Doppler spread, and SNR. Feel free to let me know if you identify a set 
of conditions where the calibration is particularly inaccurate.

Question for Bill - how come the whole file (jt65sim.for) shows as changed in 
r8388?

Steve k9an

> On Jan 1, 2018, at 4:05 PM, Bill Somerville  wrote:
> 
> On 01/01/2018 20:41, Bill Somerville wrote:
>> On 01/01/2018 17:56, Steven Franke wrote:
>>> Hi Charlie,
>>> 
>>>> Does anyone know how to batch process a number of files (in Audacity or
>>>> something else) to a) amplify them and b) convert from 12000 to 11025.
>>> I have used sox and bash shell scripts to do the type of work that you have 
>>> described.
>>> 
>>> I will look at the JT65 VHF/UHF/Microwave SNR estimate to see if I can 
>>> tweak it to reduce the bias at low SNRs. (A different estimate is used for 
>>> HF operation). 
>>> 
>>> BTW, I note that your single example from WSJT suggests that it may have an 
>>> even larger bias, of the opposite sign. 
>>> 
>>> Steve k9an
>> Hi Charlie and Steve,
>> 
>> it seems to me that the easiest thing to do here is modify jt65sim to be 
>> able to generate 11025 Hz sample rate .WAV files as well as 12000 Hz. I have 
>> done this but cannot get WSJT to decode them. WSJT-X decodes them fine using 
>> it's automatic sample rate converter. When I work out why WSJT is not 
>> decoding them I will check in the updates to jt65sim.
>> 
>> 73 and HNY
>> Bill
>> G4WJS.
>> 
> 
> Hi Steve & Charlie,
> 
> I have got WSJT reading the simulated files. WSJT needs a fairly hefty 
> positive gain offset applied to the PCM stream, around +30dB seems about 
> right. I have added the following new command line options for jt65sim:
> 
> >\build\wsjtx-dev\Debug\jt65sim -h
> 
>  Usage: jt65sim [OPTIONS]
> 
> Generate one or more simulated JT65 signals in .WAV file(s)
> 
>  Example: jt65sim -m B -n 10 -d 0.2 -s \\-24.5 -t 0.0 -f 4
> 
>  OPTIONS: NB Use \ (\\ on *nix shells) to escape -ve arguments
> 
>  -h
>  --help
> Display this help message
>  -m MODE
>  --sub-mode MODE
> sub mode, default MODE=A
>  -n SIGNALS
>  --num-sigs SIGNALS
> number of signals per file, default SIGNALS=10
>  -F F0
>  --f0 F0
> base frequency offset, default F0=1500.0
>  -d SPREAD
>  --doppler-spread SPREAD
> Doppler spread, default SPREAD=0.0
>  -t SECONDS
>  --time-offset SECONDS
> Time delta, default SECONDS=0.0
>  -f FILES
>  --num-files FILES
> Number of files to generate, default FILES=1
>  -p
>  --no-prng-seed
> Do not seed PRNGs (use for reproducible tests)
>  -s SNR
>  --strength SNR
> S/N in dB (2500Hz reference b/w), default SNR=0
>  -S
>  --11025
> Generate at 11025Hz sample rate, default 12000Hz
>  -G GAIN
>  --gain-offset GAIN
> Gain offset in dB, default GAIN=0dB
>  -M Message
>  --message Message
> Message text
> where:
> 
>  --f0 n (or -F n) sets the base frequency of the generated signal(s), default 
> 1500.0 Hz,
> 
>  --11025 (-S for slow) generate a 11025 Hz sample rate,
> 
>  --gain-offset n (or -G n) sets the overall gain offset applied to the 
> generated signal output, default is 0dB.
> 
> Steve, I am unsure about a couple of the changes I have made, particularly 
> the limited slice of the cdat complex array used when applying the Rayleigh 
> fading model on line 275 (necessary to avoid an array bounds violation when 
> using 11025 Hz rate), and whether I should apply clipping to 16-bit full 
> scale after applying the gain offset at line 288. I also don't understand 
> what line 287 is doing as it seems to apply a normalization factor 'fac' that 
> I would expect to be applied on line 288 yet that line used a fixed factor of 
> 100.0 (`rms`). Perhaps you can review my changes and advise?
> 
> Charlie, I don't know what version of jt65sim you are using, you OP document 
> above shows a command line that probably matches a very old version. The 
> current version, which is not shipped in the installer, takes the above 
> command line options and switches. I used it like:
> 
> >\build\wsjtx-dev\Debug\jt65sim -M "G3WDG G4WJS -20" -f 10 -n 1 -t 2.5 -m C 
> >-S -F 1227.5 -s \-10.0 -G 30.0
> for 

Re: [wsjt-devel] Inconsistent JT65b reporting

[Steven Franke]

Hi Charlie,

> Does anyone know how to batch process a number of files (in Audacity or
> something else) to a) amplify them and b) convert from 12000 to 11025.

I have used sox and bash shell scripts to do the type of work that you have 
described.

I will look at the JT65 VHF/UHF/Microwave SNR estimate to see if I can tweak it 
to reduce the bias at low SNRs. (A different estimate is used for HF 
operation). 

BTW, I note that your single example from WSJT suggests that it may have an 
even larger bias, of the opposite sign. 

Steve k9an
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] CRC12 incorrectly specified to BOOST library

[Steven Franke]

Hi Pete,

I don’t think that there is any bug in the FT8 CRC.

As I pointed out back when we were having this discussion some time ago, the 
tables in Koopman and Chakravarty do not directly apply to our application. 

Any codeword produced by either of the FT8 decoders is a valid codeword. That 
is, the returned codeword always satisfies all 87 of the parity check equations 
associated with our LDPC code. We use the CRC to detect cases where the (valid) 
codeword returned from the decoder happens to be the wrong codeword. If the 
LDPC code is any good to begin with, any valid but incorrect codeword will 
differ from the correct one in many bits, i.e. the Hamming distance between an 
incorrect codeword and the correct one will be large - significantly larger 
than the Hamming distances considered in Koopman and Chakravarty. The same 
holds true for the Hamming distance between the “message” portion of any 
incorrect codeword and the correct message.

The bottom line is that we had to rely on long simulations based on our 
particular (174,87) LDPC code to determine how well any particular CRC 
polynomial would work.  Based on these simulations, we determined that the 
polynomial that we chose gave excellent performance, commensurate with the 
performance that we expect for an effective 12-bit CRC. In particular, we find 
that the chosen CRC reduces the undetected error rate by a factor of about 
2^12. 

Finally, perhaps it’s worth pointing out that the use of a 12-bit CRC is what 
enabled us to use the very effective, but computationally intensive, 
“ordered-statistics” decoding (OSD) algorithm to gain about 1 dB beyond what 
the iterative soft-decision belief-propagation decoding algorithm can provide. 
We realize even more gain from the OSD approach when doing “AP” decoding. The 
high sensitivity of the OSD approach comes with a downside — the 
ordered-statistics decoder is a complete decoder, that is, it always produces a 
codeword, even if you feed it pure noise. To use such a decoder it is necessary 
to have a very effective way to recognize when the returned codeword could not 
possibly be correct. It would not have been feasible to use this more sensitive 
decoder if we had used anything much shorter than a 12-bit CRC. 

Steve K9AN


> On Nov 27, 2017, at 12:50 AM, Pete  wrote:
> 
> Just for fun I've been trying to implement an FT8 encoder that would run on a 
> Teensy (or Arduino) microcontroller. As part of that effort, I've run into a 
> problem trying to replicate the CRC12 used in WSJTX. I've come to the 
> conclusion that the use of 0xC06 in crc12.cpp is a mistake/bug.
> I notice that Mike W9MDB pointed out this problem on the wsjt-devel list back 
> in March when he wrote:
> > You may want to check your polynomial.  I do believe 0xc06 should be 0xc07 
> > --
> > you never want a zero x^0 term.
> 
> Although I agree with him that when specifying a CRC to BOOST, it must be an 
> odd number - i.e. low order bit is set - I disagree that 0xC06 should be 
> 0xC07.
> 
> When specifying a polynomial to BOOST, the highest-order term of the 
> polynomial is omitted. But in the paper by Koopman & Chakravarty (K&C), the 
> low-order term is omitted. If it were decided to use the K&C polynomial 0xC07 
> (which is a much better choice than 0xC06), this would have to be specified 
> as 0x80F to BOOST.
> 
> Mike also asked:
> > What's the logic behind using a 12-bit CRC?  Is there a plan of some sort 
> > here?
> 
> If I understand Table 4 in K&C correctly, any one of the 8-bit polynomials 
> 0x97, 0x98, 0x83 or 0xCD would perform better than the 12-bit 0xC06 even if 
> it had been correctly specified to BOOST. An 8-bit polynomial would also free 
> up four bits in the message.
> 
> If the polynomial as currently implemented in 1.8.0 is indeed incorrect, what 
> is involved in getting it changed to a better 12-bit or 8-bit polynomial?
> 
> 73
> Pete VE5VA
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Feature Request of FT8 TX Frequency limitation less than 2kHz

[Steven Franke]

Hi Mike,

> On Nov 22, 2017, at 1:31 PM, Black Michael via wsjt-devel 
>  wrote:
> 
> JT65 is more sensitive than JT9 too.

I don’t think that I agree with this. According to the WSJT-X User Guide, 
second paragraph, "JT9 was originally designed for the LF, MF, and lower HF 
bands. Its submode JT9A is 2 dB more sensitive than JT65 while using less than 
10% of the bandwidth.” 

The User Guide statement is referring to simulations based on an AWGN channel. 
What’s the basis or context for your assertion?

Steve k9an
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Apriori check

[Steven Franke]

Mike,

> They decode the same whether AP is selected or not.  I did put K9AN in the DX 
> Call box and Generated Msgs.  Is there more required to get AP to work?

As I said before:

> To see the effect of AP, the state machine has to be in the appropriate state 
> (you can click on Tx buttons to set the state) and Dx Call has to contain the 
> right callsign (K9AN for the example message that I gave).

Your first message implied that you suspected a problem with RRR/73 messages. 
Your test message will not shed any light on that question, as you must know. 
In any case, I did a test similar to yours. I generated 10 files with SNR=-22 
dB as follows:

$ ./ft8sim "K9AN W9MDB -15" s 1500.0 0.0 0.1 1.0 10 -22
 Generating single signal at 1500 Hz.
f0: 1500.000   DT:  0.00   TxT:  12.6   SNR: -22.0  BW:50.0  K9AN W9MDB -15

I then entered W9MDB into the DX call box and decoded the files with AP turned 
off. The results are:

04 -21 0.0 1500 ~ K9AN W9MDB -15
10 -21 0.0 1500 ~ K9AN W9MDB -15

Next, I selected “Enable AP” under the decode menu, and put the state machine 
into the “CALLING” state (see the User guide, table 2) by selecting the “CQ” 
message. In this state, the AP decoder is looking only for CQs and for messages 
containing MyCall. The results were:

01 -22  0.0 1500 ~  K9AN W9MDB -15 a2
04 -21  0.0 1500 ~  K9AN W9MDB -15
07 -21  0.0 1500 ~  K9AN W9MDB -15   ? a2
10 -21  0.0 1500 ~  K9AN W9MDB -15

Next, I put the state machine into the REPLYING state by selecting Tx1. In this 
state, the decoder looks for "MyCall ???" (ap2) and “MyCall DxCall” (ap3). The 
results were:

01 -22  0.0 1500 ~  K9AN W9MDB -15 a2
04 -21  0.0 1500 ~  K9AN W9MDB -15
06 -22  0.0 1500 ~  K9AN W9MDB -15   ? a3
07 -21  0.0 1500 ~  K9AN W9MDB -15   ? a2
08 -21  0.0 1500 ~  K9AN W9MDB -15   ? a3
10 -21  0.0 1500 ~  K9AN W9MDB -15

Finally, I generated 100 messages, this time with SNR=-23 dB and this time the 
message contains “73”, i.e.:

$ ./ft8sim "K9AN W9MDB 73" s 1500.0 0.0 0.1 1.0 100 -23
 Generating single signal at 1500 Hz.
f0: 1500.000   DT:  0.00   TxT:  12.6   SNR: -23.0  BW:50.0  K9AN W9MDB 73

I put the state machine into the ROGER_REPORT state by selecting Tx4. The 
results are:

04 -22  0.0 1500 ~  K9AN W9MDB 73  a3
07 -22  0.0 1500 ~  K9AN W9MDB 73? a5
08 -22  0.0 1500 ~  K9AN W9MDB 73  a5
10 -21  0.0 1500 ~  K9AN W9MDB 73  a3
14 -23  0.0 1501 ~  K9AN W9MDB 73  a3
15 -22 -0.0 1500 ~  K9AN W9MDB 73  a5
22 -22  0.0 1500 ~  K9AN W9MDB 73? a3
25 -22  0.0 1501 ~  K9AN W9MDB 73? a3
27 -22  0.0 1500 ~  K9AN W9MDB 73  a3
30 -23  0.0 1500 ~  K9AN W9MDB 73? a5
31 -22  0.0 1500 ~  K9AN W9MDB 73  a5
33 -22  0.0 1500 ~  K9AN W9MDB 73? a3
34 -22 -0.0 1500 ~  K9AN W9MDB 73  a5
35 -22  0.0 1500 ~  K9AN W9MDB 73  a3
37 -22 -0.0 1500 ~  K9AN W9MDB 73? a3
40 -23 -0.0 1501 ~  K9AN W9MDB 73  a5
43 -22  0.0 1500 ~  K9AN W9MDB 73? a3
46 -22 -0.0 1500 ~  K9AN W9MDB 73? a3
47 -22  0.0 1501 ~  K9AN W9MDB 73? a5
49 -22 -0.0 1500 ~  K9AN W9MDB 73  a3
50 -22  0.0 1501 ~  K9AN W9MDB 73? a5
53 -22  0.0 1500 ~  K9AN W9MDB 73? a5
54 -22  0.0 1500 ~  K9AN W9MDB 73  a3
55 -23  0.0 1500 ~  K9AN W9MDB 73? a5
59 -23  0.0 1500 ~  K9AN W9MDB 73  a5
65 -22 -0.0 1500 ~  K9AN W9MDB 73? a5
66 -23  0.0 1500 ~  K9AN W9MDB 73? a3
68 -22  0.0 1501 ~  K9AN W9MDB 73? a5
71 -22  0.0 1500 ~  K9AN W9MDB 73? a3
75 -22  0.0 1500 ~  K9AN W9MDB 73  a3
76 -22  0.0 1500 ~  K9AN W9MDB 73? a5
78 -22  0.0 1501 ~  K9AN W9MDB 73  a3
89 -22 -0.0 1500 ~  K9AN W9MDB 73  a3
90 -22  0.0 1500 ~  K9AN W9MDB 73  a3
94 -22  0.0 1501 ~  K9AN W9MDB 73  a3
95 -22  0.0 1501 ~  K9AN W9MDB 73? a3
96 -22  0.0 1500 ~  K9AN W9MDB 73? a3
97 -22 -0.0 1501 ~  K9AN W9MDB 73? a3

There were 38 decodes, and all of them required the use of AP information. 

This all seems to be working as designed.

Steve k9an



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Apriori check

[Steven Franke]

Hi Mike - 

> I wonder it the AP bit patterns in ft8b.f90 could be double-checked?  I 
> couldn't quite figure out how to check these myself.

You can check them yourself using ft8sim:

$ ./ft8sim "W9MDB K9AN RRR" s 1500 0.0 0.1 1.0 1 -20
 Generating single signal at 1500 Hz.
f0: 1500.000   DT:  0.00   TxT:  12.6   SNR: -20.0  BW:50.0  W9MDB K9AN RRR 
   
10010111010101111001 011100110010101010101100
01101100
000
011011000110
   1   0.00 1500.00  -20.0  00_01.wav

The first line of bits contains the two 28-bit callsign fields:
10010111010101111001 011100110010101010101100

The second line of bits is the 16 bit report field. In this example, the report 
field contains the message bits that represent “RRR” message:
01101100

The third line of bits are the “extra” 3 bits (all zeros in this example):
000

The 4th line is the 12-bit CRC:
011011000110

Of course, you can examine ft8sim.f90 for details.

Please do let me know if you find any errors. 

Another good way to test is to generate a batch of wav files containing a 
message like “W9MDB K9AN RRR” at various SNRs from, say, -20 to -23 dB. Then 
decode them with AP turned on and off. To see the effect of AP, the state 
machine has to be in the appropriate state (you can click on Tx buttons to set 
the state) and Dx Call has to contain the right callsign (K9AN for the example 
message that I gave).

Steve k9an


> On Oct 30, 2017, at 10:29 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> I seem to have a lot of instances the the RRR/73 exchange having to be 
> repeated a bit too much.
> I do have AP enabled.
> 
> I wonder it the AP bit patterns in ft8b.f90 could be double-checked?  I 
> couldn't quite figure out how to check these myself.
> 
>   data icos7/2,5,6,0,4,1,3/
>   data mcq/1,1,1,1,1,0,1,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,1,1,0,0,1/
>   data mrrr/0,1,1,1,1,1,1,0,1,1,0,0,1,1,1,1/
>   data m73/0,1,1,1,1,1,1,0,1,1,0,1,0,0,0,0/
>   data mde/1,1,1,1,1,1,1,1,0,1,1,0,0,1,0,0,0,0,0,1,1,1,0,1,0,0,0,1/
>   data mrr73/0,0,0,0,0,0,1,0,0,0,0,1,0,1,0,1/
> 
> de Mike W9MDB
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fake QSO

[Steven Franke]

Hi Pino,

If you mean to imply that WSJT-X generated these messages internally, then I 
think that this is highly unlikely.

These are clearly not false decodes. Apparently, IS0FWY decided to send Tx2, 
Tx3, Tx4, and then Tx5 in successive intervals, for his or her own reasons, and 
obviously as some sort of response to your earlier call. 

While it is certainly possible to see an isolated false decode that contains 
your own callsign with the other callsign equal to the call that you have 
entered into the Dx Call box, such false decodes would always be accompanied 
with trailing “a2”, “a3”, or “a4” designators, indicating that they are the 
result of applying AP decoding. Even if the AP designator was present, I would 
still argue against false decodes because the probability of seeing Tx2 through 
Tx5 in order, in successive odd intervals, with precisely the same frequency 
offsets, the same DT, and the same SNR (in the first 3 cases) is vanishingly 
small. 

I am quite certain that these were real signals decoded by WSJT-X. As to why 
they were transmitted, I’m afraid that I have no idea.

73, Steve k9an

> On Oct 22, 2017, at 9:40 PM, Pino Zollo  wrote:
> 
> With TX NOT Enabled after having called for a while
> 
> than I have enabled TX after the RRR
> 
> 1.8.0-rc3 on Linux.
> 
> 
> 
> :-(
> Best 73
> 
> 
> 
> Pino ZP4KFX 
> 
> 13400  Tx   469 ~  IS0FWY ZP4KFX GG14
> 213445 -18  0.2  468 ~  ZP4KFX IS0FWY -13
> 213515 -18  0.2  468 ~  ZP4KFX IS0FWY R-13
> 213545 -18  0.2  468 ~  ZP4KFX IS0FWY RRR
> 213606  Tx   469 ~  IS0FWY ZP4KFX GG14
> 213609  Tx   469 ~  IS0FWY ZP4KFX R-18
> 213615 -20  0.2  468 ~  ZP4KFX IS0FWY 73
> 213630  Tx   469 ~  IS0FWY ZP4KFX 73 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org ! 
> http://sdm.link/slashdot___ 
> 
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel