Hi Eric,
On 6/10/2015 6:49 PM, Eric NO3M wrote:
Having problems with WSPR2 TX here.
WSJTX 1.6.0-devel r5578 (same problems with r5567 also before doing SVN
update/re-compile)
Band: 630m
Tx 1575 Hz
Tx Pct 33%
Upload Spots = true
Band Hopping = false
As soon as I click Tx Enable,
.
On 10/06/2015 19:36, Joe Taylor wrote:
Can anyone help me to understand how to make the on-screen appearance of
WSJT-X look more uniform, across platforms and OS settings?
To see one example that bugs me, look at the Astronomical Data windows
in screen shots of Echo mode at my station
Hi Bill,
While testing this I also note that we don't have a setting to allow six
digit grids to be sent. Should we be adding this to WSJT-X as well?
I noticed that, too. Yes, we should do this.
As for the way we wrap C routines, or otherwise make them callable from
Fortran: you've
Hi Charlie,
Again, I'm replying via wsjt-devel since this conversation is
important to others working on WSJT-X code.
G3WDG wrote:
Noticed a behaviour I hadn't seen before, with r5586.
When switching off Doppler, dial freq and rig go to bandedge. Previously
they stayed at sked frequency.
Actually, of course, decoding in -rc2 is exactly the same as in -rc1.
Original Message
Subject: (no subject)
Date: Tue, 2 Jun 2015 20:55:29 -0400
From: wmabes...@aol.com
To: k...@arrl.net
Good Morning,
Version 1.5 r2 has solved the PTT problem I was having with 1.5 rc1.
Hi Bill,
Thanks for your work on the frequency/mode combinations.
An unwanted side effect is that WSPR-mode band hopping no longer works.
Not sure why, but I've determined that the structure
auto f = frequency.valueFrequency();
presently at line 4349 in mainwindow.cpp always evaluates to
I'm not). :-)
Thoughts on this topic from others would be welcome.
-- Joe
On 5/29/2015 6:23 AM, Bill Somerville wrote:
On 29/05/2015 01:55, Joe Taylor wrote:
Hi Bill,
Hi Joe,
Thanks for your work on the frequency/mode combinations.
An unwanted side effect is that WSPR-mode band
Tnx Steve, I'm running v1.6 r5482 now.
What are you using for the grayline bands and duration?
-- Joe, K1JT
On 5/31/2015 3:22 PM, Steven Franke wrote:
Joe,
FYI, r5482 is an attempt to iteratively massage the tx(10,6) table so that it
has maximum number of consecutive transmissions
Hi Eric,
On 5/31/2015 11:34 PM, Eric NO3M wrote:
Testing this evening with Tx Pct 50%, band hopping = false, got 2
consecutive transmissions, but nothing further afterward. After
switching to Band hopping = true, Tx Pct still at 50%, and only 630 in
the Sunrise, Day, et.al., fields, Tx was
Hi Charlie,
The way we store the Frequencies table has changed. Go to the Settings
| Frequencies tab and hit the Reset button to get the defaults.
To make a distributable package you need to execute the command
build-wsjtx package.
-- Joe, K1JT
On 6/1/2015 10:53 AM,
Mike --
Band hopping is relevant only for WSPR mode, where Even/Odd has no
special significance.
I suggest reading the WSPR 4.0 User's Guide,
http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf
-- Joe, K1JT
On 6/1/2015 1:18 PM, Michael Black wrote:
I'm not familiar with the
Hi Bill,
I'm nearly ready to commit some new code that does EME Doppler
calculations with higher precision. It will require installing a binary
ephemeris file named JPLEPH. I suppose this file becomes a resource
in our builds? And should it be installed in the same directory with
the
/contrib/Ephemeris/JPLEPH
? Does it then become part of the package? What tells the installer
where to install it?
-- Joe
On 6/1/2015 1:51 PM, Bill Somerville wrote:
On 01/06/2015 18:21, Joe Taylor wrote:
Hi Bill,
Hi Joe,
I'm nearly ready to commit some new code that does EME
Thanks, Bill -- that did the trick!
-- Joe
On 6/1/2015 3:31 PM, Repository WSJT wsjt wrote:
Fix regression in applying transverter offset
Somehow I had decided that the offset could be determined from the
frequency coming from the rig, this is of course impossible so the
Hi Jay and all,
From messages on this list dated May 21:
1. I am not seeing the WSPR frequencies in the Frequencies tab
or in the Dropdown menu on the GUI. Do I need to enter these
manually somewhere? ...
Currently the best way to reset the frequency list to the defaults,
which now
this work properly we need
to change the v1.5 source code to point to the above URL ... (or else
rename the file to wsjtx-main.html, but then users of v1.4 would pull up
the v1.5 manual from their Help menu).
-- Joe
On 5/27/2015 4:17 PM, Joe Taylor wrote:
Hi all,
With SVN revision
The WSJT Development Group is pleased to announce the availability of
Release Candidate 2 for WSJT-X Version 1.5.0. Installation packages for
Windows, Linux, and OS X can be downloaded from the WSJT web site:
http://physics.princeton.edu/pulsar/K1JT/wsjtx.html
Release Candidate 2 fixes all
Hi Steve and all,
Thanks for committing the tone-frequency patch and for catching the
logical error in the code supposedly guarding against consecutive
transmissions. As you have probably noticed, I've been working mostly on
other things (JT4, etc) -- and I know that WSPR mode still needs some
Steve --
One more thing that I forgot to mention. So far I'm not enthusiastic
about making WSPR's Tx frequency spinner a double instead of an int. We
could do that, of course; but if we really need to do something about
correcting a fractional-Hz error there might be better ways.
We could,
Hi Bill,
I'm not sure I understand exactly what you want to do. Allow more than
the presently designated 10 bands in the band-hopping schedule? Could
be OK, I suppose; but it might require abandoning some safeguards on
band choices that we had.
The following is from the WSPR4 online manual
Steve --
SourceForge seems to be having problems; the email notices, at least,
seem not to be keeping up. But as far as I can see the repository is
perfectly OK. Please update to r5471 (the latest commit), merge in your
changes, and recommit. I'd like to try your activation of the
Hi Bill,
I forgot to mention that the band hopping band lists must now be entries
of the form NNm like '10m' '160m' etc.. I can amend the logic to allow
just digits like '10' '160' etc. if required but as I intend to make
selecting the active bands checkable items anyway so this will be
On 5/31/2015 8:48 AM, Michael Black wrote:
I submitted this over a week ago and never heard any comments..is this 25
second time limit on transmit for JT65/JT9 no longer desirable?
Or should other modes be included?
It's disabled because it's not wanted during testing.
I may have lost track of exactly what code is controlling the
band-hopping now (r5477), but I note that the program now seems to be
cycling me through all ten bands (160, 80, 60, 40, ...) even though my
list of Day bands is 40 30 20 17 15 12 10.
-- Joe
wrote:
Enabling band hopping gets Tx rolling, but as someone pointed out in
another message to the list, even with a low percentage Tx probability
(in my case 20% tested), up to 4 consecutive Tx cycles before I killed it.
On 05/27/2015 08:20 PM, Joe Taylor wrote:
Hi Eric,
It seems that my
Hi Bill,
Many thanks for a careful reading of the User Guide.
The link http://physics.princeton.edu/pulsar/K1JT/kv-installer.txt is
referenced but doesn't yet exist.
Yes. This was my way of putting off dealing with it until slightly
later. ;-)
Maybe you have an opinion on whether some
Hi Charlie,
My apologies -- the change in r5491 was a bad idea and caused the
Doppler corrections to fail. I have backed out that change. Please
upgrade to r5493 and rebuild. It should be OK now (but the FT-817 issue
remains unresolved).
-- Joe, K1JT
On 6/2/2015 8:55 AM,
like to have the program able to set dial frequency just before a
transmission starts, and possibly reset it to another frequency when
receiving. The present timing does not allow this.
-- Joe, K1JT
On 6/2/2015 10:20 AM, Bill Somerville wrote:
On 02/06/2015 15:11, Joe Taylor wrote:
Hi
Hi Mike,
On 6/2/2015 8:39 AM, Michael Black wrote:
Isn't part of the reason for split to make for a cleaner signal? Seems to
me that would still hold true no matter where it converts to analog,
wouldn't it?
Using Split mode is advantageous with most radios because it obviates
the need for
Hi Charlie, Rex, and all,
I have posted Windows installation files for two recent builds of WSJT-X:
http://physics.princeton.edu/pulsar/K1JT/wsjtx-1.6.0-r5493.exe
http://physics.princeton.edu/pulsar/K1JT/wsjtx-1.6.0-r5499.exe
Revision 5493 uses the old Doppler calculations -- the ones you have
Hi John, Greg, Bill, and all,
Thanks for your input. I've made a few last revisions to the User Guide
and committed them to ^/branches/wsjtx.
Bill, these changes to Section 3 should be merged into the wsjtx-1.5
branch for the RC2 release.
-- Joe
On 5/29/2015 8:01 AM, John Nelson
Hi all,
The feature list of WSJT-X Version 1.6 continues to grow. A number of
good things are still to come: for example,
- EME Doppler calculations using the JPL Planetary Ephemeris
- Improved message averaging for JT4
- Correlation decoding and message averaging for JT65
- WSPR-15
Hi Steve, Bill, and all,
On 6/30/2015 6:18 PM, Steven Franke wrote:
For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
which makes decoder #5 from Joe’s table, below, the default decoder in
wsjt-x ver 1.6. It is no longer necessary to separately compile
wsprd_exp to get
Hi Steve,
On 6/27/2015 8:36 PM, Steven Franke wrote:
I just captured a .c2 file after commenting out the call to timf2
in wspr_downsample and replacing x1 with x0 in the call to mixlpf.
The dropouts are gone. So it looks like the problem is in timf2.
Good work!
As far as I can remember:
One more point, while I think of it.
Since all WSPR-mode decodes are displayed at nearly the same time,
anyway, wouldn't it be a good idea to sort them in order of increasing
frequency before writing them out? Having them in frequency order makes
it much easier to compaere decodes with
From: Joe Taylor j...@princeton.edu
To: wsjt_ss_is...@yahoogroups.com
Hi Jay, Gary, and all,
KA9CFD wrote:
I would like to see ISCAT mode made available in WSJT-X. Then you would
get radio frequency control and also personally I would be able to log
QSO's directly into DXkeeper with the use
Hi Oleg,
UX5UL wrote:
If the last mode WSJT, before exiting the program, was working in JT65, CW,
or Echo,
then the next time you start WSJT get the following error and the program
closes.
Tested on two systems running Windows XP and 7PROx64.
WSJT Version 10.0 r5639 , by K1JT
Revision
Hi Alan,
On 7/6/2015 1:02 AM, Alan VK2ZIW wrote:
And, having compiled and run up WSJT-X 1.6.1-devel, I cannot see
in Help - About any Revision number.
This makes it hard to comment on features/problems, referring to an
exact Revision number.
Maybe I don't understand what you're saying. The
Hi Oleg,
As already reported, I have not been able to reproduce this problem.
At present I have no explanation for the behavior you observe.
I note that the file azel.dat has been created and written, as expected,
and has the correct length. Is some other program trying to access this
file?
Hi Rex,
Thanks for catching and reporting this bug. I'm not presently at a
location where it's convenient to generate test files. Could you send
me one or two example files that contain signals with suitable S/N and
spread that should be decodable in the G submode?
-- Joe, K1JT
On
Hi Ingebrigt,
Thanks for pointing out this detail. Compound callsigns like LA/VK2LJM
raise many issues, not all of which are presently handled in an ideal
way in WSJT-X. By copy of this message to the wsjt-devel (the WSJT
Developers email list), I will bring it to the attention of others --
Hi Steve,
I'm just back from dinner and the movies. Bill set you right on
deleting the Frequencies line in the *ini file. I had thought that
those using WSPR in WSJT-X would already have dealt with this one-time
issue.
As for calling the user_hardware script: as presently coded, this
PS to my message of 20 minutes ago:
The entry labeled Gray Time on Tab 4 specifies duration of the
Sunrise/Sunset Grayline periods, in minutes. Thus,
Gray Time 60
specifies a grayline period extending from 30 minutes before local
sunrise to 30 minutes after, etc.
-- Joe, K1JT
Hi Steve and all,
K9AN wrote:
Ah, I just noticed that 1.5*1.46=2.2. So the entered TX frequency
is the frequency of the lowest tone, presumably…
By convention, for all of the other modes in WSJT-X the frequency of a
transmission is described as that of the lowest tone. In JT9 and
especially
Hi all,
I believe WSJT-X v1.6.1 now works well in all of its supported modes:
JT9, JT65(A-C), JT4(A-G), and WSPR-2. Surely there is more work to be
done: to name just a few items on my To Do list, WSPR-15 should be
implemented, message averaging should be added to JT65, and a higher
accuracy
Hi Steve,
K9An wrote:
WSJT-X has been running for several hours now, and the day/sunset
transition seemed to work just as it should.
Regarding the user_hardware issue, would it make sense to send
the band and the mode as command-line arguments to user_command
and put the onus on the
Hi Bill and all,
Next topic...
On 5/25/2015 6:12 AM, Bill Somerville wrote:
Joe, are you proposing that the JT4 and other VHF and up features are
released along with the WSPR features? I am a little uncomfortable with
that as it is a lot of new content for one release and I suspect that
both
Hi Jim P, Jim B, and all,
On Tue,5/26/2015 1:12 PM, Jim Pennino wrote:
WSJT Version 10.0 r5247:
My $0.02 for future development; Use the same rig and sound card
setup that are used in WSJT-X.
On 5/26/2015 4:33 PM, Jim Brown wrote:
YES, PLEASE! I'm set up for SO2R contesting, and use the
Hi Bill,
On 5/25/2015 6:12 AM, Bill Somerville wrote:
we currently have the v1.5 branch of WSJT-X awaiting some documentation
updates before making a new release candidate, although unrelated it
would be nice to get that moving as well. The v1.5 branch has a few bug
fixes since the RC1
Hi all,
This message is especially for Bill/ND0B, because he designed the
auto-sequencing option in WSJT10. But it's also for anyone who has been
exercising the fast JT9 modes.
Are you happy with the way the current auto-sequencer takes one through
a QSO? Any suggestions for making it
Message- From: Joe Taylor
Sent: Friday, August 21, 2015 8:19 PM
To: Bill Ockert - ND0B ; WSJT software development
Subject: Auto-Sequencing with fast JT9 modes
Hi all,
This message is especially for Bill/ND0B, because he designed the
auto-sequencing option in WSJT10. But it's also for anyone
Hi Steve,
I have compiled the two-pass decoder in Windows, and am running it now.
To make it work I had to change line 1062 so that it calls
subtract_signal() rather than subtract_signal2(). Haven't yet tried to
determine what's amiss in the fully coherent subtraction routine.
I will report
Hi Charlie,
G3WDG wrote:
FYI, I have just been experimenting with ISCAT-B on 10GHz EME using
r5637 on 5 sec periods with some success:
201510 2 -8 4.2 0 0 * HELLN LOON 11 1 9 0.0
201520 4 -6 3.7 0 0 * HELLO MOON 11 1 10 1.1
201530 1 -7 3.1 0 0 * MOOO-HEKKO 11 0 8 5.6
201540 3 -2 2.6 0 0 *
Hi Steve, Edson, and all,
I had forgotten that wsprd_exp is currently using a different sync
algorithm. Thanks for the explanations. I, too, am happy with the way
the modified fano.c is behaving. By all means, go ahead and commit the
necessary changes.
I'm thinking about the possible
Steve --
Some follow-up on the rare (but annoying) false WSPR decodes...
I decided to look especially at the 15 files in the wspr_data.tgz
package that produced a false decode (one containing /) in *any* of
your test cases. The files are:
150426_0114.wav
150426_0148.wav
150426_0342.wav
PM, Greg Beam wrote:
Hi Joe, Steve,
Are these updates in the main wsprd binary, or do we still need to
build
the wsprd_exp binary and copy it over to wsprd to test the changes?
73's
Greg, KI7MT
On 7/28/2015 12:22 PM, Joe Taylor wrote:
Hi Steve,
Nice job with implementation
Hi Steve,
Nice job with implementation of a sequential decoder using the Jelinek
Stack Algorithm!
I have now run some reasonably thorough tests of it, comparing results
with the default Fano decoder in wsprd. I confirm essentially all of
your basic conclusions. Jelinek with maxcycles=5000
Sorry for the typo in the posted file
http://physics.princeton.edu/pulsar/K1JT/Fast_JT9.txt
which refers to the file
http://physics.princeton.edu/pulsar/K1JT/wsjt_modes.txt
The typo has been repaired.
-- Joe, K1JT
Hi Bill,
I'm moving this discussion to wsjt-devel, since others will be interested.
Many thanks for the comments. Obviously I need to deal with some issues
you had already solved, for ISCAT.
1. I was calling CQ and W3ZUP answered me while I had the auto sequencer
enable. I would not expect
Hi Peter,
Thanks for identifying and documenting this unintended behavior. It has
been fixed in r5772.
-- Joe, K1JT
On 8/10/2015 6:39 AM, Peter Frenning [OZ1PIF] wrote:
As usual, tested on Linux Mint Rebecca 14.1 (32-bit)
Running WSPR-2 with Tx offset at say 1565 Hz.
Then changing
Hi all,
My email suggests that others want to know more about the fun some of us
have been having with the new fast JT9 submodes for scatter
communication on 6 and 10 meters. Some details, instructions, and a
brief development history are outlined here:
Hi all,
I've been asked a number of questions about fundamentals concerning
the new Fast JT9 submodes in WSJT-X. This seems like a good time to
review the basics of *all* WSJT modes, including their particular
strengths, limitations, optimum propagation types, etc.
A useful comparison among all
Hi all,
Since way back when, around 2005-6, this email list has had a somewhat
arbitrary limit of 40 kB on message size. Such a limit precludes
sending things like screen snapshots, which can sometimes be useful when
reporting bugs, etc.
This morning I increased the limit to 999 kB (the max
Hi Bill,
Thanks for the helpful reports on program behavior. Much appreciated!
Over the next few days I hope to find time to fix these and other
reported anomalies and generally improve the program's polish when
running the fast modes.
You may have noticed that this morning I increased the
Hi Peter,
On 8/5/2015 4:50 PM, Peter Frenning [OZ1PIF] wrote:
Today I took the plunge, and replaced 1.5 with 1.6-devel(I know I know, it's
not
yet ready for production anyway, AFAIC it's the only way to really test
it!), I installed from Greg's PPA on my main machine running Linux Mint
What's up at SourceForge ???
This is getting ridiculous. Maybe it's time for us to consider github
seriously?
-- Joe, K1JT
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you
Hi Eric,
There is no intentional cutoff time for requesting Tx Next.
I have not been able to confirm that activating Tx Next close to the
end of a 2-minute period fails to trigger a TX period on the next
2-minute cycle. I tried t=55s, t=57s, and t=59s in the odd minute of
reception, and in
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
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 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
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
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 releas
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
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 +
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
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 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)
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
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
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,
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
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
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
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 the develo
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
OK, all is well now.
The WSJT-X User Guide pdf at
http://physics.princeton.edu/pulsar/K1JT/WSJT-X_User_Guide_v1.6_tmp.pdf
corresponds to SVN r6092.
-- Joe, K1JT
On 11/13/2015 3:43 PM, Joe Taylor wrote:
> Oops, I've left something out. Will commit again in a few minutes, and
>
Oops, I've left something out. Will commit again in a few minutes, and
make a new pdf.
-- Joe
On 11/13/2015 3:36 PM, Joe Taylor wrote:
> Hi all,
>
> With SVN r6090 I have committed a nominally "final" version of the
> WSJT-X User Guide for Version 1.6.0.
>
Bonjour Alain,
Yes, of course we can mention AlarmeJT in the WSJT-X User Guide. I will
add the necessary details.
-- 73, Joe, K1JT
On 11/16/2015 9:50 AM, f5...@free.fr wrote:
> Hello,
> I saw that in the WSJT-X documentation, there is a section cooperating
> programs. It mentions
Hi all,
Whew, creating good documentation is a big job!! I think I'm finally
nearing a good end-point for the Version 1.6.0 WSJT-X User Guide.
The doc sources are committed as r6105. I've posted html and pdf
versions here:
http://physics.princeton.edu/pulsar/K1JT/wsjtx-main_v1.6.0.html
Hi Greg,
Is something different here because you're using Win10? I seem to have
no problem moving that window in Win7.
-- Joe
On 11/16/2015 3:02 PM, Greg Beam wrote:
> Hi Joe, Bill,
>
> I've been playing with different modes and wanted to look at the Astro
> Data Widget. I ran into a
Hi Charlie,
Thanks, I was aware of the presence of the (unused) control that you
highlight. In v1.6.0 we "grayed out" several controls when they are
inactive, but did not make them invisible. In v1.6.1 I started making
them invisible instead. I think we'll leave it as is in v1.6.0.
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
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
-- 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
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 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
>
JT9 submodes do not exist in v1.6.0.
On 11/17/2015 10:58 AM, Richard Stanley wrote:
>
> jt9 submodes don't appear to be working in jt9
> works fine in 1.6.1
>
> decoding far superior in recent version, it now outperforms the jt65hf
> variant 100% of the time.
>
> Richard g7oed ex m0clz
>
>
>
>
On 11/17/2015 10:33 AM, Bill Somerville wrote:
> On 17/11/2015 14:47, Joe Taylor wrote:
>> Although ready to accept additional corrections or suggestions for the
>> User Guide (from anyone, of course) ... as of SVN revision 6109 I'm
>> basically ready to sign off on
Hi Bill,
>> Once more, I'd appreciate critical readings by any and all. Last call
>> for input before we release v1.6.0-rc1 !
> The WSPR section probably needs more. The band hopping schedule should
> be either referenced or documented in the User Guide. The key difference
> from prior versions
Hi John,
That orphan line was deleted in r6109. Thanks for your careful reading!!
-- Joe
On 11/17/2015 12:10 PM, John Nelson wrote:
> Hi Joe,
>
> Proof-reading continued;
>
> 10.1: Wide graph. Para. after "Select Current or Cumulative.." there is
> a line which appears to
201 - 300 of 1545 matches
Mail list logo
