Hi Richard and all,
I don't really understand what's being discussed here. Bill sent me
copies of files with these names:
150916_1430.wav
150916_1433.wav
150916_1529.wav
150916_1530.wav
150916_1531.wav
I don't know who made the files, or with what program.
The files are, frankly, a mess: bird
JT-X before JT65-HB9HQX has any
> apparent effect.
>>
>> Richard m0clz
> 73
> Bill
> G4WJS.
>>
>>
>> -Original Message-
>> From: Bill Somerville
>> Sent: Wednesday, September 16, 2015 9:32 PM
>> To:wsjt-devel@lists.sourceforge.n
Bill --
Back to our other issue, for a moment. Have you tried doing the tests
outlined in the file CQnnnCAT.txt, on one of your setups? Are the tests
passed OK, using both "Rig" and "Fake it"?
If all seems OK, I'll probably prepare another alpha release tomorrow.
-- Joe, K1JT
--
Hi Steve,
Thanks for the update on your tests of kvasd and sfrsd. Very interesting!
I meant to mention before that I had tried errors-and erasures decoding
before, maybe ten years ago, by ranking the symbols in order of
estimated reliability and then "erasing" them, two at a time, from the
bo
Hi Paolo,
Your audio files do not sound right. The level is set far too high --
the first file (UTC 21:43:45) pegs the WSJT-X "thermometer" at +60 dB,
when the adjacent slider is around mid-scale. There is a lot of
impulsive interference, and even that does not sound right to me: it
sounds l
Hi Steve,
I've looked again at the innards of sfrsd. I'm *much* impressed by what
you have done.
Soon, it may be time to look again at the upstream decisions made in the
JT65 decoding chain -- decisions that determine what symbol vectors are
passed on to the actual decoder. Among other thing
I will assume that you are talking about JTMSK. You should not be
surprised to see an occasional false decode. Decoded messages are
"protected" by a 15-bit CRC, so the probability of a false decode
accidentally passing the CRC test is about 1/32768.
-- Joe, K1JT
On 9/19/2015 5:46 PM,
Hi Steve --
On 9/19/2015 6:03 PM, Steven Franke wrote:
> I have just now realized that the sync threshold is higher for “off
> frequency” signals. Since I had set Rx freq to 3000, the results
> reported below were obtained using the higher wideband sync threshold.
> That probably explains the lowe
> 1. it may be possible to achieve the same results with fewer trials if the
>>> soft-symbol information was utilized in a smarter way
>>>
>>> and/or
>>>
>>> 2. the quality of the presently used soft-symbol information is so bad that
>>> it’s n
Hi Håken,
On 9/21/2015 12:36 AM, Håken Hveem wrote:
> I found the error, the "power slider" must be at its top position,
> weird,- since the receive slider must be at almost the bottom of the screen.
Running with the Rx slider near the bottom of its range strongly
suggests that you have the RF g
Thanks, Sandro! I will see that this flaw is corrected.
-- Joe, K1JT
On 9/23/2015 8:19 AM, Alessandro Gorobey wrote:
> Hi All,
>
> on WSJT-X v 1.6.1 switch to JT9 not update correctly wide graph.
>
> To simulate:
> - select JT9 submode A
> - select JTMSK (or ECHO)
> - select JT9
> now ar
Hi Steve,
Thanks for sharing some further comparisons of kvasd and sfrsd.
When WSJT-X was first being expanded from a testbed for JT9 to a more
capable, more general program for HF DXing, JT65A capability was added
to make the program attractive to the large existing user base for that
mode.
is
> certainly true for anything that involve symbol metrics and any quality tests
> that depend on them.
>
> And - yes, the results that you got kvasd on WSJT-X are more-or-less
> consistent with mine.
> Steve k9an
>
>> On Sep 23, 2015, at 10:01 AM, Joe Taylor wrote:
&
Hi Steve and all,
Here's an update on my tests of decoding weak JT65A signals. I used
1000 files generated by SimJT, each containing one JT65A signal at
S/N = -24 dB. I am using current code revisions of WSJT-X v1.6.1 (with
minor edits noted below) and WSJT v10.0.
For each line in the followi
I can figure out. Thanks for taking
> time out to confirm my results! - it gives me a lot more confidence about
> what I’m doing over here.
> Steve k9an
>
>> On Sep 23, 2015, at 3:13 PM, Joe Taylor wrote:
>>
>> Hi Steve and all,
>>
>> Here's an update on
Hi Steve and all,
I've added more lines to the table summarizing my tests of decoding
weak, isolated JT65A signals. As before, the final number on each line
is the number of valid decodes from a thousand files at
S/N=-24 dB.
1. WSJT-X (BM only) 2
2. WSJT (BM only)
the number of “found” codewords is to the selected erasure
> probabilities and the metrics…
>
> If you have time to play, feel free to mess around with sfrsd - or create an
> jtrsd and we can merge them later.
> Steve k9an
>
>> On Sep 25, 2015, at 8:11 AM, Joe Taylor wr
figure out how to change the
> code to turn it off. As it stands, the program is calling the decoder to
> attempt to decode the averaged signal immediately after it tries to decode
> the current file - and that over-writes the kvasd.dat file.
>
> Steve
>
>
>> On Sep 25, 2
Steve --
That one always did look a bit odd. Quite possibly I made a mistake,
trying to do too many things at once.
I will investigate further... but it may be not until Monday.
-- Joe
On 9/25/2015 11:34 PM, Steven Franke wrote:
> Hi Joe -
>
>> 17.WSJT + kvasd (SFM no ntest)
Hi Steve,
On 9/26/2015 10:40 AM, Steven Franke wrote:
> Don’t worry about it Joe - I tried scaling up my metrics by a factor
> of 4 and then kvasd gave me 644 decodes. So it’s clear that kvasd
> wants bigger numbers. For now, I’ll just focus on trying optimize sfrsd…
>
> Your rsdtest looks like a
er right. That’s still without using the mr2sym’s.
>
> Getting closer! As time permits, I’ll see if I can reproduce these
> results using your sfrsd2 and rsdtest.
>
> Steve k9an
>> On Sep 26, 2015, at 10:27 AM, Joe Taylor > <mailto:j...@princeton.edu>> wrote:
>>
Steve --
On 9/26/2015 6:31 PM, Steven Franke wrote:
> Joe -
> A correction - it turns out I had ntrials set to 2:
>
> current sfrsd ntrials 2: 709/1000
> current sfrsd ntrials 1: 665/1000
>
> Still, a worthwhile improvement.
Agreed. How did you define the erasure thresholds to get th
Steve --
I moved your modified sources for the _rs_ routines into
.../trunk/sfrsd, merged sfrsd3.c back into sfrsd2.c, and updated
Makefile accordingly. I think it should be OK now. As of r5935 I am
getting 810/1000 for 1 trials and 874/1000 for 10 trials. I
hope I haven't done some
GM all,
We have made excellent progress on the quest Steve started toward an
open-source Reed Solomon decoder that's as good or better than the
closed-source Koetter-Vardy algorithm. This message aims to be a
summary of results up to now (for our own future reference), followed by
some though
Hi Steve and all,
A few more thoughts about my idea on how we might select erasure vectors
most likely to lead to successful decodes. This is potentially
important because the "right" erasure vector leads to a nearly
instantaneous decode; nearly all of the processing time in sfrsd2 is now
dev
Hi Steve,
Congratulations -- those are really good results using the 8x8
probability matrix.
With revision 5942 I have made minor adjustments to the criteria used
for rejecting potentially bad decodes. It gives 837/1000 good decodes
and NO bad decodes with ntrials=1.
I have put this best
Hi all,
Some further information on the new Reed Solomon decoder.
A simple timing measurement shows that for test program "rsdtest" 97% of
the execution time is spent in the Berlekamp-Massey
errors-and-erasures decoder.
This is good. It means that if/when we decide more speed is desirable,
it
On 9/29/2015 4:28 PM, Michael Black wrote:
> What kind of time is it taking now? The overhead of splitting the work can
> kill any advantage as I'm sure you know from the previous multi-threading
> of JT9.
Increasing ntrials from 10^4 to 10^5 increased running time by x 6.4:
about 22 minutes for
Mike --
On 9/29/2015 5:29 PM, Michael Black wrote:
> So the failures are a separate section?
No. Have you looked at what the decoder is doing?
If 25 or fewer of 63 received symbols are in error, the deterministic
Berlekamp_Massey (BM) algorithm is guaranteed to succeed. With more
than 25 err
Hi Steve
I played with your mr2 insertion code a bit. I agree that the
second-best symbols don't seem to help us much.
I posted two new plots of decodes vs. ntrials here:
http://physics.princeton.edu/pulsar/K1JT/decodes_vs_ntrials.pdf
http://physics.princeton.edu/pulsar/K1JT/decodes_vs_ntrials
e soft
> distance check.
>
> In any case, I agree that we should just stick with the current erasures-only
> scheme. but let's keep sfrsd3 on the side and see what it does when we get to
> testing real signals.
> Steve k9an
>
>> On Sep 30, 2015, at 5:27 AM, Joe Taylor wro
Hi Steve,
On 9/30/2015 8:52 AM, Steven Franke wrote:
>> A surprise discovery: it seems that all of our recent tests have been
>> using the original code in .../trunk/demod64a.f90, with its exp(x)
>> symbol metrics. I tried switching back to your simple p1/psum, p2/psum
>> mnetrics computed in ...
Hi all,
For the record: I have built a version of WSJT that calls sfrsd (with
ntrials=1) rather than kvasd. Results in line 20, below, show that
for the test data the new decoder is slightly better than kvasd (line 10).
# Test Decodes False Time
Hi Claude,
I have added the file int.h to the rsdtest directory.
Please note that successfully executing this Makefile is unlikely to
produce anything that you will find useful.
-- Joe, K1JT
On 9/30/2015 10:59 AM, Claude Frantz wrote:
> On 09/30/2015 01:14 PM, Steven Franke wrote:
>
>
Hi Bill,
A week or so ago you wrote "On the concurrency side the option to use
OpenMP is not available as there is no C/C++ OpenMP available on Mac".
Aren't we using OpenMP now in jt9[.exe], on all platforms? Are you
saying that on the Mac we can use OpenMP from Fortran, but not from C/C++ ??
Hi Greg,
Amusing tidbit.
I just finished building WSJT-X v1.6.1 r5949 on my in-shack computer.
The attached screen shot shows its first decodes of on-the-air JT65
signals, including KI7MT.
-- Joe
--
_
Hi Steve,
I'm scratching my head...
At SVN revision r5949, WSJT-X v1.6.1 uses sfrsd2 in place of kvasd. It
seems to work well, but so far the only tuning I've done is to try both
the original (kvasd-inspired) metrics and the simple ones based on
p1/psum and p2/psum. In this instance the simp
best way to go.
-- Joe, K1JT
On 9/30/2015 12:10 PM, Bill Somerville wrote:
> On 30/09/2015 16:57, Joe Taylor wrote:
>> Hi Bill,
> Hi Joe,
>>
>> A week or so ago you wrote "On the concurrency side the option to use
>> OpenMP is not available as there is no C/C++ OpenMP a
> Got two decodes on r5949 at -15 and -20 that 1.6.0 did not see.
> Follow at 1738 by a -1 decode on 1.6.0 that r5949 did not see.
> Another at 1739 with a -16 decode on 1.6.0 that r5949 did not see.
> So we're batting .500 in the early innings here
> You want I should save the w
Hi Steve,
On 9/30/2015 2:57 PM, Steven Franke wrote:
> As Joe said, for EME we probably want to run very large numbers
> of trials. If one were to start multiple calls to sfrsd2, each
> with its own random seed, all at once, and ensure that each
> call runs in its own thread, would this accomplish
Hi Steve,
Thanks for sharing your further test results. The iterative self-tuning
procedure seems to work very well, and guess we are agreed that
stochastic substitution of second-best symbols isn't buying us enough to
make the performance hit worthwhile. We should, however, remain
open-min
Hi Steve,
On 9/30/2015 10:00 PM, Steven Franke wrote:
> Joe,
>
> RR on all.
>
> I think that I have now arrived at where you were some hours ago - scratching
> my head.
>
> I’m running WSJT-X r5950 on OS X. The sfrsd2.c routine is set up for the jt
> symbol metrics. If demod64a uses jt metrics,
Hi Steve,
On 10/1/2015 9:22 AM, Steven Franke wrote:
>> Meanwhile I've been gaining some experience with WSJT-X r5950 on
>> 20-40-80-160 meters. (Yes, using the "wrong" metrics.) Performance
>> generally seems good, though I have seen some pretty long decoding times.
>
> I think that a large par
Hi Steve and all,
On 10/2/2015 9:50 AM, Steven Franke wrote:
Just re-read what I sent last night - I should have said “… 8 or more
no-decodes and only 2 decodes”. It is likely that many of those
no-decodes will eventually turn into decodes when the algorithm is
properly tuned.
Thanks for the
Hi Steve,
On 10/2/2015 7:26 PM, Steven Franke wrote:
> Very interesting Joe. Is there any reason to think that JT-65 and
> WSJT-X use the same symbol metrics?
Most of the signal processing in JT65-HF is Fortran code copied directly
from WSJT.
I haven't checked carefully to see what changes ther
wrote:
> Joe - in WSJT-X, where do I turn off the printing of blank lines for
> no-decodes?
>
>> On Oct 2, 2015, at 7:14 PM, Joe Taylor wrote:
>>
>> Hi Steve,
>>
>> On 10/2/2015 7:26 PM, Steven Franke wrote:
>>> Very interesting Joe. Is there any reason
Yes, that is normal behavior.
On 10/5/2015 2:46 AM, Paolo Petrini wrote:
>
> Hello!
>
> Yesterday during a meteor scatter QSO I noticed that the report which is
> automatically sent is changing every time a new burst is arriving. is it
> normal?
> Paolo
>
-
efore an appropriate
> acknowledgement is received locally, or vice versa. Sure it doesn't
> matter, it just seems a bit "untidy" :)
>
> Regards, Mark
>
> On 05/10/2015 15:22, Joe Taylor wrote:
>> Yes, that is normal behavior.
>>
>> On 10/5/2015 2:4
Hi STeve,
I think I understand what's going on with the less-than-perfect
selection of candidate frequencies at which to attempt JT65 decoding. I
hope to spend some time on it in the next couple of days. If I don't
get it sorted out then, it may be delayed for about a week. I'll be
away bet
Hi Greg,
Thanks for identifying and documenting the bug that could cause decoded
messages to be displayed twice (possibly with small differences) when
operating in JT9+JT65 mode. It's fixed in revision 5958.
-- Joe
--
Hi Steve and all,
In coming days I hope to catch up with your work on sfrsd. I haven't
yet tested r5970 under crowded-band, HF-style conditions.
I did make a quick test on my group of single-signal 1000 files
generated by SimJT, with S/N=-24 dB. The program ran well and was fast,
but the res
s working well, perhaps better than kvasd with the settings
> used in v1.5, even with ntrials=2000 as is currently the default in r5970.
>
> I decided to wait to see if you reached the same conclusions before taking
> any next steps…
>
> Steve k9an
>
>> On Oct 15, 2015
Correction:
> For these test files the "ntest" criterion is too stringent, so I
> removed the test commenting it out. Then all 994 candidates are
> submitted for decoding, and 662 produced valid decodes.
I should have written "662 produced valid decodes with ntrials=1".
-- Joe
---
Hi Steve,
Thanks for being skeptical about implications of my conclusion that
candidate selection is OK in r5970, at least for the simulated -24 dB
"gnnf" files.
I think your results make a strong case that while the correct
candidates for decoding were identified in nearly all cases, the
tim
Hi Steve,
Sorry to say, my progress has been slow today. I wanted to start by
reproducing your good-looking results using rsdtest. So far I have not
really managed to do so; I can get as many good decodes as you reported,
but not (yet?) with the sfrsd2.c attached to your email.
Could you ple
t;79) gives me 853 good decodes and 0 bad decodes on
> s3_1000.bin using ntrials=1 and my version of rsdtest.
>
> Steve k9an
>
>> On Oct 16, 2015, at 3:33 PM, Joe Taylor wrote:
>>
>> Hi Steve,
>>
>> Sorry to say, my progress has been slow today. I w
Hi Rex,
Thanks for the suggestion. As it happens, we're working only with JT65A
up to now. I'm well aware that the B and C submodes in WSJT-X are well
below par in sensitivity. No work has been done on them yet, beyond
putting most of the basic essentials in place. In due course, I expect
Hi Steve,
Thanks for pushing ahead with the new soft-RS decoder. Very interesting
results, to be sure! I'm delighted to see that a composite matrix for
erasure probabilities works so well.
I've made good progress here, too. I have fully confirmed your results
using rsdtest, and for complete
Thanks to those reporting the Fortran bounds error in sync65.f90. It's
fixed in code revision 5977.
The reason why some observed it and others (including me) did not is
simple: the error occurred only if you had the Wide Graph's "Start xxx
Hz" spinner set to 0. (It's worth noting that in gene
Hi Tom,
On 10/19/2015 1:59 PM, sq5rix wrote:
> ... I hope to contribute to your great project, if you
> need any testing, checking, anything - please assign. I have some
> experience in C, C++, ham radio.
>
> 73 and good luck!
> Tom
Thanks for your note. We'll be happy to have your contributions
Hi Mike,
On 10/19/2015 2:22 PM, Michael Black wrote:
> Consideration of this trivial patch to allow RRR to trigger the logging
> dialog box would be much appreciated.
Obviously you're welcome to modify the behavior of your own builds of
the programs according to your own wishes.
There's a lot o
Hi Steve and all,
I will be traveling and mostly out of touch for the next three days, so
I want to bring you up-to-date on what I've been doing.
Directory .../trunk/rsdtest now has code for three programs that do
their Reed-Solomon decoding in sfrsd2.
rsdtest - reads s3() data from file s
Hi Greg,
I intended to respond to this message of yours some weeks ago, but
apparently forgot to do so.
Basically, I think it's a good idea to look carefully at possible use of
SQLite for several tasks in WSJT-X: logging and a replacement for
CALL3.TXT are two good possibilities.
Have you gon
3:58 PM, Joe Taylor wrote:
> Hi Steve and all,
>
> I will be traveling and mostly out of touch for the next three days, so
> I want to bring you up-to-date on what I've been doing.
>
> Directory .../trunk/rsdtest now has code for three programs that do
> their Reed-
doing to update the
> JTSDK builds and InnoSetup files to ommit the KVASD binary inclusions
> for WSJT. Both changes should be fairly simple.
>
> 73's
> Greg, KI7MT
>
>
>
>
> On 10/20/2015 14:13, Joe Taylor wrote:
>> Hi all,
>>
>> I should have mentione
Hi Steve and all,
Thanks for passing on your test results with JT65 signal subtraction.
Very interesting!
> There are a couple of things that need to be looked at in more
> detail — I had to add a mysterious 1s offset to the “dt” parameter,
> and I don’t understand why this was necessary.
In th
Hi Charlie and all,
With revision 6010 of WSJT-X v1.6.1 I have added a checkbox labeled
"Track VFOs" at bottom right on the Astronomical Data window. By
default the box is checked and Doppler tracking behaves as before. If
you clear the box WSJT-X will stop sending Doppler-corrected frequenci
Hi Steve,
On 10/26/2015 10:27 PM, Steven Franke wrote:
> Hi Joe,
>> In the WSJT slow modes PTT is nominally asserted at t=0 s and audio
>> starts at t=1 s in a UTC minute. SimJT generates wav files in which the
>> noise starts at t=0 and signal starts at t=1. I guess this is
>> essentially what y
Hi Steve,
Just to let you know:
In r6011 I have changed the filter loop in subtract65.f90 from a
time-domain convolution to a frequency-domain multiplication. In my
test case the speedup was a factor greater than 6. Two-pass decoding of
JT65 is now acceptably fast. I think we have a definite
12:00 PM, Joe Taylor wrote:
> Hi Steve,
>
> Just to let you know:
>
> In r6011 I have changed the filter loop in subtract65.f90 from a
> time-domain convolution to a frequency-domain multiplication. In my
> test case the speedup was a factor greater than 6. Two-pass deco
Hi Bill, Richard, and all,
I guess we need to decide whether there will be a v1.5.1 release. As
Bill suggested, an alternative is to offer a v1.6.0-rc1.
If we do a v1.5.1 release, it would be well to include the corrected
version of jt65code committed (to v1.6.0) in SVN revision 6000.
Hi Claude,
I guess I need to remind you that useful bug reports should include
these items:
1. Program name, version, SVN revision number, and operating system.
2. If relevant: did you build it yourself?
3. Nature of the problem.
4. A minimum set of steps that will reproduce the problem.
I have
Hi Richard,
>> You should be building wsjx-1.5.0 not -rc2.
>
> I could probably change it if no one has upgraded yet but is there a known
> problem with 1.5.1-rc2 that is of concern?
I think Bill means that any mention of "1.5.1-rc2" suggests that we are
planning to have a version 1.5.1. This i
Hi Steve and all,
I've run some further tests with the two-pass JT65 decoder, using a
collection of 473 *.wav files recorded at 14.076 MHz. Here's a quick
summary of results:
Program Decodes Time
WSJT-X v1.6.0 v5636 (kvasd) 227
Hi Claude,
>> 1. Program name, version, SVN revision number, and operating system.
>
> The program is wsjtx, SVN revision number 6008, and OS is Fedora 22, 32
> bit, as mentioned in my previous message. All available updates are
> installed. uname -a says:
The SVN revision number is not enough, s
Hi Steve,
Thanks for catching and fixing my error in the scaling factor for
FFT-based convolutions. I've done some further cleanup of the code in
subroutine subtract65(), which I think is now in good shape. As you
suspected, I now get even more decodes from the second pass:
Program
Hi Guy,
We'll be happy to have your input from tests of any and all WSJT versions.
In general you can tell what's been changed by looking at the SVN
repository: http://sourceforge.net/p/wsjt/wsjt/HEAD/tree/ .
Changes to WSJT are in "trunk". Click on "branches" and then "wsjtx" to
see files fo
Hi all,
WSJT-X v1.6.1 now (SVN revision 6020) includes a first cut at using
Steve's 2-pass decoding scheme for JT65.
As you will have seen in previous posts by Steve and me -- based on use
of a stand-alone, single-purpose program -- the 2-pass scheme produces
significantly more decodes from
Thanks, Bill. I shouldn't have omitted mention of all the other worthy
additions made between WSJT-X v1.5 and v1.6.0!
-- Joe
On 10/29/2015 11:59 AM, Bill Somerville wrote:
> On 29/10/2015 15:35, Joe Taylor wrote:
>> Briefly stated, differences between the current full r
Hi Greg,
Thanks for the report.
> I just built and ran r6020 on Win32. Leaving ntrials at [6], it appears
> the start receive time is being delayed a by about 1 second ? This is
> JT65+JT9 mode.
Do you mean that *Monitor* does not go green and waterfall does not
start until t=1s of an Rx minute
Hi all,
I've added one more line to the table comparing JT65 decoding performance:
Correct False
Program Decodes Decodes Decoder
JT65-HF2329 24BM + kvasd
WSJT-X r5912 2249 0BM + kvasd
Hi all,
Most of my recent effort has been devoted to new features in our
experimental branch -- what we have been calliny WSJT-X v1.6.1.
However, I'm planning now to put some time into bringing the WSJT-X User
Guide into decent shape for a candidate release of Version 1.6.0.
According to my own
Hi Steve,
Thanks once more for your excellent work on the JT65 decoder!!
I have confirmed your results using the test program jt65[.exe]. I then
went ahead and merged your changes into v1.6.1 of WSJT-X; it's now
performing at least as well as the WSJT decoder for the S/N=-24 dB files
produced
Hi all,
Here's an amusing screen shot.
WSJT-X was running with 2-pass decoding enabled for JT65. Note the two
decodes of WB9OTX at Freq = 1856 Hz. Evidently he changed his Tx
message from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in
mid-transmission. The decoder gets the "73" message in its
Hi Steve,
On 11/2/2015 3:59 PM, Steven Franke wrote:
> Wait. What? Very cool example, but I’m confused.
>
> When the user changes messages in mid-stream, my assumption
> was that the program would jump to the beginning of the new
> message symbol-stream, i.e. start at the beginning of a new
> mess
there are a few JT9 prints the last one could
> come at second 59.
>
> Regularly decode signals -26 -27 -28.
>
> 73, Bill W2PKY
>
>
> On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor wrote:
>
>> Hi all,
>>
>> Here's an amusing screen shot.
>>
>
Sorry, I sent this message in a garbled form.
Meant to delete the line "Suppose all data symbols in the wrong", just
above the last paragraph.
-- Joe
On 11/2/2015 4:10 PM, Joe Taylor wrote:
> Hi Steve,
>
> On 11/2/2015 3:59 PM, Steven Franke wrote:
>> Wait. Wha
] proceeds rapidly.
> if setting the RX to 2K or above the JT9 prints are delayed significantly.
> My computer is a 4Ghz CPU with 8 Ex units.
> Hope this helps.
>
> Bill W2PKY
>
> On Mon, Nov 2, 2015 at 4:27 PM, Joe Taylor wrote:
>
>> Hi Bill,
>>
>> I&
Hi Remco,
Your request is noted. Since the capability you want is rather
specialized, and since it's already available in WSPR2, WSPR4 and
WSPR-X, it may not be assigned a very high priority.
-- 73, Joe, K1JT
On 11/10/2015 12:44 PM, Remco wrote:
> It took me some time to find the prop
Hi Igor,
Here's a brief note responding to your many messages about different
decoding results on different computers.
On 11/11/2015 1:09 PM, Игорь Ч wrote:
> Just got 96 decodes from 'AGC ON' files and 84 decodes from 'AGC OFF' files
> while running r6058 on Win7 / AMD Phenom II X4 945 Process
Hi all,
Perhaps you have noticed my flurry of activity concerning the way
certain add-on DXCC prefixes are used in WSJT-related programs. It's a
result of an upcoming EME DXpedition having been assigned the callsign
HK0/DL2NUD.
WSJT and MAP65 have supported HK0A and HK0M as distinct "Type 1"
Hi all,
FYI, I'm forwarding the message sent to the "Moon-Net" email list a few
minutes ago.
-- Joe, K1JT
Original Message
Subject: [Moon-Net] HK0 as an add-on prefix
Date: Wed, 11 Nov 2015 16:21:11 -0500
From: Joe Taylor
To:
Dear EME Friends,
Th
-- Joe
On 11/11/2015 4:20 PM, Bill Somerville wrote:
> On 11/11/2015 20:55, Joe Taylor wrote:
>> Bill, I think the code now used in genStdMsgs is yours. For some reason
>> did you intentionally de-activate the way Type 1 callsigns were
>> previously supported? Or am I forg
Hi Bill,
I was about to reply, but I see that you have now found the discrepancy
between User Guide and program action.
>> What is not working?
> Ah OK, I see the discrepancy against the User Guide where the generated
> reply to a CQ call is not a type 1 compound call message. IIRC this was
> do
Hi Bill,
> There was a lengthy discussion that was mostly related to type 2
> compound call signs. It was HF focused because at the time WSJT-X only
> supported that.
This is not exactly correct. WSJT-X fully supported tye original ("Type
1") compound callsigns, but it did not generate the requ
Hi Bill,
Your suggestions sound right. Thanks for thinking about these issues.
-- Joe
On 11/11/2015 7:03 PM, Bill Somerville wrote:
> On 11/11/2015 23:56, Bill Somerville wrote:
>> For Tx5 we could generate a "73" standard
>> message as per the User Guide except for the case where b
Hi Igor and Steve,
Perhaps it's worth mentioning that our advice for all WSJT-related
programs has always been to disable the receiver AGC (if possible) and
turn the RF gain control well down, thereby minimizing AGC action. If
you do this and follow instructions in the User Guide about setting
Hi Igor,
> What makes me worry is that when RF gain is used (some people
> do use attenuator) to get to more linear band of the AGC
> operation, it supresses receiver sensitivity putting very
> weak signals out of scope of the decoder.
Of course one does not want to reduce sensitivity to weak sig
3
(without callsigns) are often used.
-- Joe
On 11/11/2015 8:20 PM, Bill Somerville wrote:
> On 12/11/2015 01:02, Joe Taylor wrote:
>> Hi Bill,
> Hi Joe,
>>
>> Your suggestions sound right. Thanks for thinking about these issues.
> I have committed a change to
Hi all,
With SVN r6090 I have committed a nominally "final" version of the
WSJT-X User Guide for Version 1.6.0.
As you know, it's easy to overlook glaring deficiencies in something
you've been staring at for too long. A close reading of the full
document by any and all will be much appreciate
501 - 600 of 1353 matches
Mail list logo
