Hi Bill,
You asked me a question recently about utility programs like
jt4sim[.exe], wsprsim[.exe]. There's no reason to include
compiled executables for these programs in the WSJT-X packages.
These simulators were extremely useful to me, when writing decoders for
the various modes. But they
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
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
>
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<j...@princeton.edu> wrote:
>
>> Hi Bill,
>>
>>
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
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
ding is 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, 201
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
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
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
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-Solom
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 mentioned that (as of r
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
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
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
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
that the statistics of the scheduler may “feel” different when
TX Pct is less than 17%, as a different algorithm is used in that regime.
Steve k9an
On Jul 6, 2015, at 6:32 PM, Joe Taylor mailto:j...@princeton.edu
j...@princeton.edu wrote:
Hi Jean Louis and all,
I have not yet
Hi all,
Just a brief note to let you know that sun, sand, sail, and
grandchildren will be my top priorities for just over a week, starting
tomorrow.
I will not be reading email until July 19 or 20.
-- 73, Joe, K1JT
Hi all,
I've been working on ISCAT (in wsjtx_exp) rather than helping to trace
the problem with band-hopping Kenwoods. For what it's worth, though:
with my TS-2000 I continue to see the same kind of glitches that Steve
has been reporting. I could do more extensive tracing if that would help.
Mike --
I haven't been following these tests in great detail, but as reported I
see see similar bad behavior to what Steve has reported.
My setup is a TS-2000, which (with a firmware upgrade) has no problem
changing frequency while transmitting.
-- Joe, K1JT
On 7/10/2015 11:10 AM,
Thanks, Bill -- certainly you're right.
-- Joe, K1JT
On 11/14/2015 1:58 PM, Bill Somerville wrote:
> FAO Steve K9AN,
>
> I notice that wsprd reports the integer value of DT in the drift column,
> I assume this is a defect. If so I will apply the following patch:
>
> index
Hi all,
Many VHF users of WSJT-X are now playing with the new mode JTMSK.
I view this mode as a candidate replacement for FSK441 and JTMS, for all
meteor scatter work.
For some further details and a download link, see the info posted at
http://physics.princeton.edu/pulsar/K1JT/Fast_Modes.txt
Hi Steve,
Thanks for the bug report. Were you running with T/R sequence lebngth
30 s? I think there are problems there. Try setting T/R = 15 s, which
is what everyone is using. I will trace the problem.
-- Joe
On 8/29/2015 8:59 AM, Steven Franke wrote:
Attemptimg to play with
Steve --
No apparent problem here when monitoring a birdie. Does it die when
attempting to decode, at the end of a sequence? If you hace checked
Save all and re-open the saved file, does that crash the program? If
so, could you send me the file?
-- Joe
On 8/29/2015 10:29 AM,
Hi Bill, Steve, and all,
On 8/29/2015 9:44 AM, Bill Somerville wrote:
On 29/08/2015 13:59, Steven Franke wrote:
Hi Steve,
Attemptimg to play with jtmsk here using r5824.
I am seeing the following:
$ ./wsjtx
At line 65 of file /home/radio/Builds/wsjtx_exp/lib/jtmsk.f90
Fortran runtime
Steve --
On 8/29/2015 10:29 AM, Steven Franke wrote:
OK, I spoke too soon. Running with 15s T/R sequence. Seems to run OK when the
input is “pure” noise - but I can make it crash within seconds if I tune to
or tune slowly through a birdie.
That may be a different problem. I will
Steve --
I think the problem is related to T/R =30 s sequences.
For frequency selection: you need to explicitly enter one or more
frequencies for JTMSK mode.
-- Joe
On 8/29/2015 9:52 AM, Steven Franke wrote:
Thanks Bill. I hadn’t thought through the frequency selection issue.
A bit
Steve --
I didn't get a file from you, today???
-- Joe
On 8/29/2015 1:02 PM, Steven Franke wrote:
It still crashes on the file that I sent to you Joe…
Steve k9an
On Aug 29, 2015, at 3:35 PM, Joe Taylorj...@princeton.edu wrote:
Hi Bill, Steve, and all,
On 8/29/2015 9:44 AM, Bill
Hi Steve,
Thanks for the files. Neither one makes the program crash for me with
r5829 in either Windows or Linux, so I'm presently at a loss to offer
any diagnosis.
-- Joe
On 8/29/2015 5:23 PM, Steven Franke wrote:
Joe,
Here is yet another try at sending links to files that crash
Hi Steve,
... I received your CQ using my Cushcraft WARC dipole at 20m height. It
happens to present a low reflecction coefficient on 6m. The pattern is
probably “lobe-y” on 6m. In any case, the dipole is broadside NE/SW.
Not bad for 1200 km on a dead 6m band with an HF dipole at the
Hi Steve,
You were one step too quick for me. Subroutine genmsk(), which
generates the JTMSK channel symbols, also calls the Fortran wrapper for
nhash(). The wrapper requires the second argument to be an 8-byte
integer. This has now been done, in revision 5833.
-- Joe
On 8/30/2015
Hi Steve,
Thanks! What's your antenna on 6m, and where was it pointed?
Coincidentally, your decodes illustrate another undesired behavior that
I'm aware of, in the WSJT-X running JTMSK mode. Sometimes the decoder
produces a pair of identical results. Supposedly, dupes are being
suppressed;
Hi Steve,
I was about to write to you along the same lines. The copies of nhash.h
and nhash.c in .../wsjtx_exp/lib have been used only for building the
executable testmsk, not for wsprx. I was clearly on the wrong track
yesterday.
It turns out, I believe, that the problem is entirely
Steve --
I'll CQ with JTMSK, 50.280 in your direction for the next 10-15 minutes.
(This is not a good time of day for meteors, though.)
-- Joe
On 8/30/2015 12:02 PM, Steven Franke wrote:
That seems to have fixed it Joe. Neither file causes it to crash now. I have
not yet decoded
regression test.
I also wonder why the nhash algorithm has been used for a CRC on JTMSK
messages since there are probably simpler well tried and tested CRC
algorithms in common usage.
Comments?
73
Bill
G4WJS.
On 30/08/2015 15:47, Joe Taylor wrote:
Hi Steve,
I was about to write to you along
Steve --
Are you building on a 64-bit system? Anyway, please try compiling
revision 5830. I changed line 204 in nhash.c so as to force the second
argument to be a 32-bit unsigned (rather than size_t) integer.
-- Joe, K1JT
On 8/29/2015 7:45 PM, Steven Franke wrote:
The crash is
Hi Paolo,
On 9/1/2015 12:28 PM, paolo petrini wrote:
> HAs anybody an audio file to check jtmsk?
> Paolo IW1ACL SA4BHT
I'm not sure what you mean by "to check jtmsk". If you simply wish to
confirm that your installation of WSJT-X can decode JTMSK signals, I
have posted two sample wav files:
I am unable to reproduce this problem. On the systems I've tested (two
Windows, one Ubuntu Linux) the wsjtx v1.6.1 r5834 transmits as expected
after startup in JTMSK mode.
-- Joe, K1JT
On 8/31/2015 6:48 PM, Alan VK2ZIW wrote:
> *Hi,
>
> WSJT-X 1.6.1-devel r5834, works a treat but:
>
>
On 9/1/2015 8:34 AM, Paolo Petrini wrote:
> Joe,
> where can I find r5834 (or newer) for windows?
> Paolo
You can build the program yourself, from the source code. Otherwise you
must wait until we post another installation package. Currently the
most recent experimental ("alpha") release
Hi all,
Probably you have noticed my work toward a new alpha release of
WSJT-X v1.6.1. Today I posted a Windows installer for r5865 on the WSJT
web site, along with an updated version of
http://physics.princeton.edu/pulsar/K1JT/Fast_Modes.txt
THis document has on program changes since r5823,
Hi Bill,
>> Does the build procedure do something different, for you?
> Yes, builds without any new errors or warnings.
>
> The first error appears to be a bug that was fixed in gfortran 4.3 I
> think, the bug report isn't very helpful on version fixed in:
>
>
Hi Bill,
> Your changes are fine with 4.9.2 here but I think there is a problem
> with the hash() function as you have declared the 'len' argument as
> INTEGER(KIND=C_SIZE_T) but where it is called in wqencode() it is called
> with a default integer which is INTEGER*4 which will be a mismatch on
Hi Bill,
Thanks for doing the new DTR/RTS arrangement. I've just merged
revisions 5825, 5868, and 5869 from the main development branch into
wsjtx_exp. You might want to check that I did the right things with
Configuration.ui.
-- Joe, K1JT
On 9/9/2015 8:25 AM, Bill Somerville
Bill --
> You may have this correct already but when setting a split Tx frequency
> the following sequence or an equivalent is necessary:
>
> if (m_monitoring || m_transmitting) {
> if (m_config.transceiver_online ()) {
> if (m_config.split_mode ()) {
> // All
Hi Bill,
> Perhaps we should be doing the same as for WSPR with the fast modes i.e.
> turning off split on the rig. It looks like you have already added some
> of the relevant code in r5774 assuming that
> MainWindow::fast_config(true) is being called appropriately.
I had previously thought this
Hi Steve,
Thanks for the additional info. I will look forward to your further
progress with the sfrsd decoder.
> By the way, one thing that I’ve already noticed is that some
> files produce lots of identical un-decodable received symbol
> vectors. Since I have to try a whole bunch of virtual
Hi Steve,
I finally found time for a quick look at "sfrsd", your drop-in
replacement for kvasd that uses the stochastic Chase algorith.
I compiled and ran it on a few test cases this morning, and (as will be
no surprise to you) found that it works, and it succeeds in some cases
where the
Hi Bill,
> I assume fast modes will normally always be at the same nominal audio
> frequency probably centred in the SSB Tx passband.
I now have things set up so that JTMSK is always centered at 1500 Hz.
The JT9-fast modes all use 700 Hz for the lowest tone; this means that
the widest fast
of previous
program exit, restarting WSJT-X immediately switches the radio out of
split mode.
Does this make sense? Is there a good reason for the program to do this?
-- Joe
On 9/15/2015 10:47 AM, Joe Taylor wrote:
> Hi Bill,
>
> As you may have noticed, I'm having a devil of
Hi Bill,
I don't have any version of JT65-HF currently installed here, to make
the comparison. What version have you tried? Can you send me the full
list of decodes for at least one of the files you posted?
-- Joe
On 9/16/2015 12:17 PM, Bill Somerville wrote:
> Hi All,
>
> I am
HQX 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.net
>> Subject
Bill --
My experience is that most claims that "program X" decodes JT65 better
than WSJT (or WSJT-X) are the result of using wrong soundcard sample
rates. I seem to remember that JT65-HF doesn't read (or write) *.wav
files, so it's very hard to do a real comparison of the decoders. I
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 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:
09/09/2015 20:52, Joe Taylor wrote:
>> Hi Bill,
> Hi Joe,
>
> ...
>>> Personally I would prefer a solution that ships the sample files but
>>> compresses them to minimize package size. Second preference would be a
>>> separate download from the project web
Hi Rex,
Many thanks for your helpful comments on code revision 5865.
VK7MO wrote:
> Some feedback on r5865. Some of this might be in the "cleaning up category"
> that you might prefer to fix at a later stage.
>
> JT9 Fast Modes
>
> We are still seeing the problem of frequency jumps on JT9 fast
Hi Charlie,
G3WDG wrote:
> With Doppler control off, and Split set to none, the [fast JT9] tones are
> indeed on
> the correct frequency and I don't get Rig control errors, but can't
> properly use it for EME!
Agreed. But the fast JT9 modes were intended for ionoscatter, not EME.
The wide
Hi Steve,
Some interesting results concerning JT65 symbol vectors. Your
suggestion (that these these may be false syncs obtained when stepping
in frequency across a fairly strong JT65 signal) sounds plausible. It
may be significant that the JT65 decoder was designed (and fine-tuned)
for
Hi Bill,
As you may have noticed, I'm having a devil of a time getting the
"CQ nnn ..." messaging to work properly. I want to be sure that I
handle split mode (either "Rig" or "Fake it") in the right way.
I may have some more specific questions about the cod3e for you soon,
when I finish
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)
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
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 availa
> 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 wav's?
>
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
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
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<j...@p
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 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
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
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
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<j...@princeton.edu> wrote:
>>
>> Hi Steve,
>>
>> On 10/2/2015 7:26 PM, Steven Franke wrote:
>>> Very in
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
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
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 <j...@princeton.edu
>> <mailto:j...@princeton.edu>> wro
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
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 all,
Today I committed 8 additional *.wav files to the .../wsjtx_exp/samples
directory. These will be particularly useful for those learning to use
the modes recently added to WSJT-X, including WSPR, JT4, ISCAT-B, Fast
JT9, and JTMSK. Unfortunately, these files add 6 MB to the WSJT-X
Hi Sandro,
Thanks, as always, for your detailed comments on WSJT-X v1.6.1 r5870. I
am copying this response to the wsjt-devel list, since some of the
points you raise may be best answered by another one of us.
On 9/9/2015 1:12 PM, Alessandro Gorobey wrote:
> Hi Joe,
>
> I write directly to
Hi Bill,
Of course -- I should have remembered that you had made embedding the
sample files optional. :-)
I don't know how to do this from within Greg's JTSDK, or by using
cmake-gui. Probably there's a way? Anyway, turning the option OFF by
editing the top CMakeLists.txt works fine. I
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
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
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
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
t;> following might be true:
>>>
>>> 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
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.
ertainly 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<j...@princeton.
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<j...@princeton.edu> wrote:
>>
>> Hi Steve and all,
>>
>> Here
gure 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
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<j.
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
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
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
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
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)
301 - 400 of 1545 matches
Mail list logo
