Hi Bill and all,
> 1) What is the purpose of f77_wisdom.f90 and wisdom.c? I ask because
> they seem to duplicate functionality that is already available directly
> from the FFTW3 library in both C and Fortran form via the fftw3.h and
> fftw3f.f03 include files.
File fftw3f.f03 is apparently fairl
On 11/21/2014 12:34 AM, Michael Black wrote:
> I seem to be seeing some decoding problems recently. ...
The JT65 signals you mention in your first two files are below the
threshold for the JT65 decoder, around -24 dB.
It's hardly surprising to see a weak signal in the waterfall that fails
to d
Hi Bill,
> It would be handy to know exactly what compiler/linker options you used
> when building KVASD for the Mac?
cc -c -arch i386 usleep.c
cc -c -O2 -arch i386 asd1.c
gfortran -o kvasd_1.12_mac32_10.7 -m32 kvasd.f90 asd1.o usleep.o
cc -c -arch x86_64 usleep.c
cc -c -O2 -arch x86_64 asd1.c
g
John --
Not sure why you call these bugs? Does something on your system complain?
For each string that Fortran passes as an argument, the string length is
added as a "hidden argument" after the last visible argument.
If the function being called is written in C, the hidden argument is
visible
Richard --
On 11/21/2014 11:59 AM, Richard Shaw wrote:
> On Fri, Nov 21, 2014 at 10:44 AM, Joe Taylor wrote:
>
>> cc -c -arch i386 usleep.c
>> cc -c -O2 -arch i386 asd1.c
>> gfortran -o kvasd_1.12_mac32_10.7 -m32 kvasd.f90 asd1.o usleep.o
>>
>> cc -c -arc
Hi Bill and all,
I agree that responses to the "F4" command could use some further
thought. Possibly some history will help.
In the original WSJT program, including WSJT10, "F4" simply clears the
entry fields for DX Call and DX Grid. There is a user option "F4 sets
Tx6" on the Setup menu; if
Bill --
> ... How about leaving things as is
> except that the newly generated CQ message gets displayed in the "Gen
> msg" box (this is a clear defect as it stands now) and the "Gen msg"
> radio button gets selected. The custom free text message can stay
> unchanged. That way we don't have too m
Hi Alan,
On 12/7/2014 2:44 AM, Alan VK2ZIW wrote:
> On the Banana Pi, WSPR takes 2 mins 10 secs to "Decode".
This is not a very useful statement. The decoder used in my WSPR code
uses the sequential Fano algorithm, and execution times vary widely
depending on input data. Signals well above th
Hi all,
Just a note to say that I've recovered (more or less) from the third and
final weekend of the ARRL International EME Contest. Our multi-op
effort finished with 341 QSOs and 167 multipliers on seven bands. (Am I
getting too old to be playing these games?) Anyway, I'm once again
readi
Hi Alessandro and all,
Compiler optimizations can be helpful when tuning code for good
performance, but I am surprised that you see anything like a 2x
improvement in decoding speed.
The following table shows the results of a series of tests I made today
for the decoder (the executable program
Hi Alessandro,
I replicated your tests as exactly as possible, modifying
CMAKE_CXX_FLAGS and General_FFLAGS by the addition of "-mtune=native".
Using WSJT-X and the "Shift+F6" command, the sequence of ten files
(01.wav, 02,wav, ... 10.wav) was processed in 21 seconds with or without
the additio
On 12/17/2014 10:22 AM, Michael Black wrote:
> Have you got a batch file or such so perhaps I can try and replicate this
> too?
Replicating Alessandro's test requires a trivial change to the file
CMakeLists.txt for WSJT-X. See his email for details.
> It seems the current fftwf build from JTSDK
Mike --
> I didn't quite realize that jt9 didn't use the dll.
What dll are you referring to? If you mean the FFTW library, jt9[.exe]
definitely *does* use it.
> What's the command line to run jt9?
Type jt9 by itself at the command prompt, to get a brief "usage"
message. For example:
C:\JTSD
Hi Alan,
On 12/17/2014 6:19 PM, Alan VK2ZIW wrote:
> WSPR is not much use if it only runs 10 or 11 hours.
Many people run production releases of WSPR for many weeks, or even
longer, without problems.
It appears that you're running an executable you compiled yourself,
using various tools and pa
Alan --
For several years already the SVN repository has included two
lightweight WSPR tools:
wspr0.exe
wspr_nogui.py
If running on minimal hardware is a high-priority goal for you (or for
your balloonists, or ???) have you considered either of these?
These programs have not received mu
Hi Alan,
VK2ZIW wrote:
> ...
> In the end, we all need a Low Power, Low Price way to run WSPR or WSJT.
> That is repeatable and reliable.
Several questions seem relevant to me:
Who are "we all" (the many potential users) you are thinking of?
What do they want to do, or would you like them to be
Hi Sandro,
Thanks for your latest report. Clearly the mystery has been solved!
There is certainly no need to apologize for starting this thread. Your
reports are always clear and informative. I learned something from the
follow-ups that several of us did, and perhaps others did too.
Best wi
Keith --
In general, the best places for reporting such issues are the WSJT
developers email list, wsjt-devel@lists.sourceforge.net, or the
"wsjtgroup" email reflector, wsjtgr...@yahoogroups.com .
Most CAT-control issues are being handled by Bill, G4WJS. You don't
mention what radio you're ta
Hi all,
A long time ago -- 2008, I believe -- we fixed a pthreads-related memory
leak that affected Linux (and probably other *nixes) but not Windows.
It seems that the pthreads implementation in Windows is different in the
way things are cleaned up (or not) after a thread exits.
Anyway, at so
Thanks for the report, Peter -- very helpful!
-- Joe, K1JT
On 1/9/2015 2:02 PM, Peter Frenning [OZ1PIF] wrote:
> After several hours of testing, it's completely stable, no evidence of a
> memory leak can be found on my system.
Chuck --
The error message suggests that the must have a very large number of
audio devices -- more than 40, in fact. can this be true? Are you
using a setup that creates a large number of "pseudo-devices"?
-- Joe, K1JT
On 1/22/2015 8:24 AM, Chuck Kelly wrote:
> Hi all,
>
> First - m
Hi all,
I was wrong to suggest that something is amiss with decoding a file read
by the GUI from disk. The first decode will be slow, that's all --
because new "FFTW wisdom" must be accumulated because we're now using
the multi-thread capable FFTW library.
Note also that if we have success wi
Hi Bill,
>> Note also that if we have success with using OpenMP elsewhere in the
>> program, we'll need to use an FFTW library compiled with
>> "--enable-openmp".
> I am hoping that is not the case and that normal multi-threaded FFTW3
> can be used in parallel to OpenMP, otherwise other builders o
Hi all,
I have made further improvements to the speed of the decoders in WSJT-X,
independently of any recourse to concurrent processing in machines with
multiple CPUs. The changes involve
1. Making better choices for NFFT1 and NFFT2 (the lengths of forward and
inverse FFTs in the JT9 downsamp
I should have mentioned that if you're especially interested in snappy
performance of the JT9 decoder, you may consider the penalty for using
menu setting "Decode | Fast" to be unimportant. It will cost you
nothing at all at the QSO frequency: that first decoding attempt is
always done at "Dee
1JT
>
> On Mon, 2/2/15, Joe Taylor wrote:
>
> Subject: [wsjt-devel] WSJT-X Decoder Performance
> To: wsjt-devel@lists.sourceforge.net
> Date: Monday, February 2, 2015, 11:45 AM
>
> Hi all,
>
> I have made further improvements to the sp
Dear Colleagues,
I have made some further performance tests of the decoders in WSJT-X.
I copied a collection of 25 *.wav files into a clean directory. The
files wererecorded in *JT9+JT65* mode during a busy period of activity
on 20 meters. On average, around a dozen decodable signals are pres
Hi Bill and all,
Perhaps you already tried jt9_omp in Linux, but I had not. I tried it
today, and it seems to work OK, as is.
Here are some timing tests made on my rather elderly 2-core Linux
machine. This time all tests were made with the "Deepest" setting,
ndepth=3, and all resulted in 17
> sure about linking the libraries.
>
> The Qt5 Tool chain has winpthreads and gcc -v has --enable-libgomp so
> the tool chain looks to be OpenMP capable.
>
> 73's
> Greg, KI7MT
>
>
> On 2/3/2015 1:06 PM, Joe Taylor wrote:
>> Hi Bill and all,
>>
>
Hi Bill and all,
Probably you already know this, but just in case...
I ran WSJT-X over last night using jt9_omp.exe (renamed to jt9.exe, and
dropped in as a replacement) under r4928. It ran OK for a while,
producing interspersed decodes in both modes. The decoder then crashed,
popping up th
Hi Claude,
Thanks for your timing report.
Your first test may have used the correct executables, too. To get a
good test you must run a configuration at least twice. In the first
run, the program accumulates "wisdom" about the best way to configure
the FFT calculations. This wisdom is saved
Hi Bill and all,
Tests here suggest that r4929 produces a Windows jt9_omp.exe that runs
correctly. At least, it runs to completion on my sequence of 25 test
files -- which r4928 does not.
Timing results on a 4-core Win7 machine:
Params jt9 jt9_omp
--
-w 2 -m 1
/2015 10:24 AM, Bill Somerville wrote:
> On 04/02/2015 15:21, Joe Taylor wrote:
>> Hi Bill and all,
> Hi Joe,
>
>
>> Note that decoder.f90 now decodes the two modes in parallel sections
>> *ONLY* if txmode is JT9. I will fix this.
> Joe, I already have this in ha
On 2/4/2015 2:26 PM, Michael Black wrote:
> Not sure we want more than 1 thread
As I demonstrated and wrote here several hours ago:
"When using OpenMP to run JT9 and JT65 decoders in parallel, we gain
almost nothing by using multi-threading for the FFTW plans."
I think this will remain true.
Hi Bill,
> Before completely discarding MT FFTW3 I would like to try something. Can
> you give a brief rough summary of all the FFT sizes used by jt9?
The file wisdom1.bat in .../wsjtx/lib shows the following FFT plans
being used:
rif672000 cif77175 cib77175 rif16384 rif884736 cib2048 rif8192 r
Hi Mike,
The change was to replace "slope", a currently undefined, vestigial
remnant of some old code, to "nflatten" -- the correct argument to pass
to symspec. The variable "slope" was undefined in jt9.f90. Inside
symspec, its value supposedly controlled whether the spectrum being
computed
Hi all,
On 2/4/2015 4:49 PM, Michael Black wrote:
> So does this also mean if you don't check the Flatten box that your decodes
> would be slower since it does the flatten later if the GUi doesn't do it?
No. And I realized after hitting "Send" that I was wrong to say the
decodes would be differ
Paul --
Could you send me a screenshot or two, illustrating what you don't like
about the present spectral display(s) ?
-- Joe, K1JT
On 2/4/2015 10:20 PM, Paul DU2/WA8UGN wrote:
> Hello Developers:
>
> If not already on the "To Do" list, would you consider the following
> suggested "imp
Hi all,
Sorry to say, I seem to have broken something in the way double-click
decodes are done. I'll look into it tomorrow.
-- Joe, K1JT
--
Dive into the World of Parallel Programming. The Go Parallel Website,
Hi Bill,
I saw that behavior yesterday, too, but had trouble reproducing it. I
will give it some attention now.
-- Joe
On 2/6/2015 10:52 AM, Bill Somerville wrote:
> On 05/02/2015 23:01, Joe Taylor wrote:
>> Hi all,
> Hi Joe,
>>
>> Sorry to say, I seem to have
d takes several minutes. No doubt I could
address this issue, but old dogs learn new tricks very slowly.
-- Joe
On 2/6/2015 11:11 AM, Joe Taylor wrote:
> Hi Bill,
>
> I saw that behavior yesterday, too, but had trouble reproducing it. I
> will give it some attention now.
>
ally, what needs to be done; it's just that my fingers don't do
all of it so automatically as with "the old way". :-)
-- Joe
On 2/6/2015 11:29 AM, Bill Somerville wrote:
> On 06/02/2015 16:18, Joe Taylor wrote:
> Hi Joe,
>> One helpful sign: I can rep
Hi Paul,
Thanks for your report.
On 2/12/2015 2:51 PM, Paul DU2/WA8UGN wrote:
> Mode: JT9+JT
> Decode: Deepest
> Band: 10.138000
> Time: 1932 02-12-2105
>
> Anomaly: Decoding of station calling CQ as being "New DXCC" but have QSO'ed
> same station on 10.138000 three times prior. JTAlertX verifi
Hi all,
I have run an extensive series of tests of the JT9 and JT65 decoders in
six different versions of WSJT-X.
Each test involved reading and decoding an identical set of 10,682 *.wav
files. The files were recorded on various bands from 160 m to 10 m. In
these files the number of decodabl
We dealt with this issue (at least I thought we did) about a year ago.
See the message to wsjt-devel dated February 15, 2014, from NO3M --
copied below.
-- Joe, K1JT
Original Message
Subject: [Wsjt-devel] Decoded text "Q" / 2DPixmap height
Date: Sat, 15 Feb 2014 03:48
Hi Mike,
Thanks for posting those troublesome wav files. As it happens, I have
been busy looking at a number of similar examples of problematic files.
More or less from the beginning, the JT9 decoder has failed without
obvious good reason something like 1% of the time... and I'd like to
under
Hi Edson,
Interesting idea! I have no problem with your plan; certainly writing
85 symbol values to a file whenever WSJT-X wants to start a transmission
will be otherwise harmless.
-- Joe
On 2/19/2015 8:11 AM, Edson W. R. Pereira wrote:
> Hello Joe and everyone,
>
> For the last few w
Hi Claude,
On 2/4/2015 9:23 AM, Claude Frantz wrote:
> Up to now, I have never seen any beacon traffic in this yellow marked
> area, but often JT65 traffic. Just now, I can see SM7OYP calling CQ on
> my screen in the yellow range, but I cannot call him. And no beacon
> traffic there.
Something mu
Hi Jay,
Decoding speed (measured by the time the "blue background" stays on) is
strongly dependent on the data being decoded.
If you find significant changes over time for decoding *identical* data
-- say, data in a recorded *.wav file -- I would take the report
seriously enough to investigate
Hi Mike and all,
> So..in the test you did before on lots of wav files that showed JT9 getting
> fewer decodes I assume this may fix that problem hopefully?
Yes... but a full accounting with timing tests is still to come.
-- Joe
--
Hi all,
Here's an updated table summarizing decoding results from the same set
of 10,682 files that I used in tests of the decoders before.
Columns labeled "JT9" and "JT65" give the number of decoded signals in
each mode. "Time" is the time in seconds to process the full data set,
as measured
Hi Bill,
Thanks for tackling this question and offering what looks like a good
solution. I hope it will shake out well in testing.
-- Joe, K1JT
--
Dive into the World of Parallel Programming The Go Parallel Web
Hi Bill,
Thanks for tackling this question and offering what looks like a good
solution. I hope it will shake out well in testing.
-- Joe, K1JT
--
Dive into the World of Parallel Programming The Go Parallel Web
Well, it helps to know the actual error message.
##
WSJT ver 10.0 r4285
Rev date 2014-09-09
AudioInput Output
DeviceChans Chans
02 0 Microsoft Sound Mapper Input
12 0 Mic (RigBlas
Hi Bill,
On 3/2/2015 5:45 PM, Bill Somerville wrote:
> to anyone using the test version linked below. I would advise not using
> it on air as there is a flaw in my proposal.
>
> The messages like:
>
> DE TI4/N0URE R-10
>
> will not work because the report will not be collected at the far end :(
N
Bill --
> The message is indeed a valid standard message but that is not the
> issue. The issue is that current software will not extract the report
> from a message that doesn't contain the DE call.
Maybe we're arguing semantics. When you say "the report will not be
collected at the far end" a
Bill --
> Agreed but the received report is only captured (automatically) if the
> message contains the DE call sign i.e. if I decode:
>
> DE TI4/N0URE R-10
>
> WSJT-X does not record that -10 report unless I manually enter it.
Yes. I wasn't too worried about that; we do, after all, offer a chan
Bill --
> Either way, I am making the required change so that WSJT-X will extract
> a received report from a standard message containing only the QSO
> partner call sign. This seems safe and proper to me.
Sounds like the right thing to do.
-- Joe
Once more, here's an updated table summarizing decoding results from the
set of 10,682 files I've been using for tests of the JT9 and JT65
decoders in WSJT-X.
Columns labeled "JT9" and "JT65" give the number of decoded signals in
each mode. "Time" is the time in seconds to process the full data
I'm temporarily stumped, and wonder if someone here can help.
I'm working on some possible GUI enhancements for WSJT-X, using
QtCreator as I have done before. With a form (say mainwindow.ui) open
in the main designer window, I right-click on a widget -- more or less
any widget -- and select "G
-- Joe
On 3/7/2015 7:02 PM, Michael Black wrote:
> Try this one change and see if it fixes it for you...worked for me.
>
> Add this declarartion to the private section in mainwindow.h
>
> private:
>Ui::MainWindow *ui;
>
>
> Mike W9MDB
>
> -----Origina
Hi Ton,
Thanks for the suggested patch. It's a useful addition, and I have
included it in my current working branch. (It may be a while before I
do a merge into the main development branch, though.)
-- 73, Joe, K1JT
On 3/2/2015 5:10 AM, Ton PA0TBR wrote:
> Hi all,
>
> I have a small
Hi John,
I suggest you get in touch about this with Charlie, G3WDG, or Sam,
G4DDK. Earlier today Charlie reported to me that GB3VHF was about 1.8 s
late.
I get DT = 0.0 +/- 0.1 on local computer-to-computer tests.
-- Joe, K1JT
On 3/10/2015 1:01 PM, John Nelson wrote:
> Hi Joe,
>
> Pr
Hi Alessandro and all,
IW3RAB wrote:
> I cannot find the file lib/wav12.f90 in any repository
Of course you are welcome to build code from any branch in our
repository. But please keep in mind that for an experimental branch
such as "wsjtx_exp" there is no guarantee that any particular revisio
On 3/11/2015 12:04 PM, Michael Black wrote:
> I'm seeing CQ 000 consistently right now from PA1FR on 10M.
So, we need to know:
1. What software you're using.
2. What software he is using.
3. What message he thinks he is sending.
-- Joe, K1JT
-
Hi Greg,
On 3/11/2015 12:11 PM, KI7MT wrote:
> I've been reading / following along with your work on the wsjtx_exp
> bracnh, I dont understand allot of it, but it appears your adding
> various modes from WSJT into WSJTX. Is the long term plan to port all
> the VHF/UHF/EME modes from WSJT into WSJ
Thanks, Mike and John. I have seen some of those same calls with
"CQ 000" , too. What we still need to know is what software those
stations were using, and what message those guys thought they were sending.
-- Joe, K1JT
On 3/11/2015 2:49 PM, John Nelson wrote:
> Mike and Joe,
>
> I see
The WSJT Development Group is pleased to announce Release Candidate 4
for WSJT-X Version 1.4.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 4 (wsjtx-1.4.0-rc4) is a highly cap
Hi Beat,
Recently users of WSJT-X have started seeing decoded messages of the
form "CQ 000 K1ABC FN42". As far as I can tell, these messages arise
because of a change you made in line 47 of a file "packmsg.f"
if(msg(1:3).eq.'DX ') msg='CQ 000 '//msg(4:)
I did not look further in your
are probably some minor documentation updates required, for
> example a new setting on the Settings->General tab.
>
> 73
> Bill
> G4WJS.
>
> On 12/03/2015 13:32, Joe Taylor wrote:
>> The WSJT Development Group is pleased to announce Release Candidate 4
>> for WSJ
Hi all,
On 3/10/2015 1:11 PM, jean raynaud f...@orange.fr [wsjtgroup] wrote:
> Hello... Anyone can explain the meaning oF " cq 000 ..." ? I see this CQ
> rather often.
A brief follow-up on this perplexing problem.
Thanks to Sandro, IW3RAB [who goes through all our source code with a
fine-tooth
Hi Jim,
Sorry to say, I don't have a good solution to suggest. Unless VAC can
be configured to handle four audio channels as a single 4-channel device
like the Delta44 sound card, I don't think it's going to work.
In principle MAP65 could be modified to allow opening a pait of
2-channel audio
Please report your problem to Bill, G4WJS, who has handled most of the
CAT control issues. His email address is g4...@classdesign.com .
-- 73, Joe, K1JT
On 3/13/2015 5:34 PM, William Wuttke wrote:
> When changing bands - Rig Split operation enabled - Yaesu FT-DX1200 - use
> Hamlib FT-DX50
Hi Bill and all,
I haven't yet paid close attention to this thread, and have not yet
tried the new code enhancements. But I want to share a potential concern
about automating QSO procedures by too much.
How much is "too much"? When I started work on WSJT in 2001 I decided
to resist any tempta
Hi John,
Thanks for your message, and for your analysis of a problem in WSPR-X.
You have no doubt noticed that WSPR-X has been neglected of late -- most
of us have been busy with other programs in the WSJT group. So I'm
delighted that you have spent some time with it!
As for what to do with y
Hi Chuck,
We'll be very happy to have your help with packaging of WSJT and its
sister programs. It's too soon to be be thinking about packaging WSJT-X
v1.6, though 00 it's an experimental branch; some ideas in it will no
doubt survive, while others will not. We do hope to make v1.5 more
wide
Hi all,
Concerning a coming rc5: please look carefully again at the v1.4.0 User
Guide and make notes on anything in it that you think needs updating,
correction, or further improvement. In particular, consider things that
have prompted recent requests for help -- and whether suitable responses
Hi Greg,
> For those updating / building WSPR-X sources, the KVASD download routine
> needs to be addressed as well, ...
Actually it just needs to be removed. KVASD is not used by WSPR-X, and
was never a part of it.
-- Joe, K1JT
n Wed, Mar 18, 2015 at 04:41:58PM -0400, Joe Taylor wrote:
>> Hi John,
>> As for what to do with your changes: if you expect to have
>> continuing interest in these things, we'd be happy to have you as a
>> "official" member of the WSJT Development Group, with sv
Hi Sandro,
Responses from Greg and Bill have answered most of your questions, but I
can add a few details that may be of interest to you and others.
Probably you already understand the nature of my license to use Koetter
and Vardy's patented algorithm for soft-decision decoding of Reed
Solomon
The WSJT Development Group is pleased to announce Release Candidate 5
for WSJT-X Version 1.4.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 5 (wsjtx-1.4.0-rc5) is stable and r
To:
CC: WSJT software development
The WSJT Development Group is pleased to announce Release Candidate 5
for WSJT-X Version 1.4.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 candidat
Hi Andreas,
DJ3EI wrote:
>> A detailed log of program changes since v1.3 r3673 is available here:
>> http://physics.princeton.edu/pulsar/K1JT/wsjtx-1.4.0-rc5.log
>
> Regarding this particular file, I have found a few nits to pick:
The file in question, wsjtx-1.4.0-rc5.log, is *not* a troff file.
VK4QG wrote:
> The 'colors' tab under 'settings' is missing. In this current version
> there is little difference in colour between 'worked before' and 'not
> worked before'.
You appear to be confusing the release candidate WSJT-X v1.4.0-rc5 with
with the not-yet-released development branch vers
Bill --
FYI, I have replaces "-rc2" with "-rc5" everywhere in the online WSJT-X
User Guide. These changes are not yet reflected in the doc sources on
SourceForge. When I do so, I will simply remove "-rc2" everywhere.
I have a few other minor updates on my "ToDo" list for the manual. If
anyo
: Joe Taylor
Date: 4/3/2015 9:03 AM
To: "Edson W. R. Pereira" , "John C. Peterson"
Thanks, Edson!
John, I guess you can now commit all of your changes to the WSPR-X branch.
-- 73, Joe, K1JT
On 4/3/2015 8:41 AM, Edson W. R. Pereira wrote:
> Hi Joe,
>
&
the rig control, band-hopping, or I/Q input capabilities of the
older, Python-based WSPR version.
I will forward to your further contributions, when you find the time!
-- 73, Joe, K1JT
On 4/6/2015 2:22 AM, John C. Peterson wrote:
> On Fri, Apr 04, 2015 at 12:34:53PM -0400, Joe Tay
Hi all,
An updated revision of the WSJT-X User Guide has been posted
(temporarily) at
http://physics.princeton.edu/pulsar/K1JT/wsjtx-main-1.4.0.html
I have removed all references to "-rc1" and "-rc2" that have been in the
manual, and made a few other minor corrections. Unless someone lets me
ny serious issues
> that cannot be worked around. I am awaiting feedback from two users as
> to whether the suggested workarounds are OK for them. Assuming they
> confirm, I will build GA kits based on RC5 within a day or so.
>
> 73
> Bill
> G4WJS.
>
> On 06/04/2015 14:45, Joe
Hi Andreas,
DJ3EI wrote:
>> The file in question, wsjtx-1.4.0-rc5.log, is *not* a troff file.
>
> Yes! I fully agree with you!
>
> The server should join our agreement. At this point, the server
> still claims, to any browser fetching the file, it's serving
> application/x-troff-man. That is a
Tnx John, I fixed it.
-- Joe
On 4/6/2015 1:22 PM, John Nelson wrote:
> Hi Joe,
>
> wsjtx/source/install-mac.adoc has:
>
> * OS X 10.7 and later: {osx_107)
>
> but global/links.adoc has this:
>
> :osx_107:
> http://physics.princeton.edu/pulsar/K1JT/wsjtx-1.4.0-Darwin_10.7.dmg[wsjtx-1.4.0
Hi all,
We need to make a policy decision about how we store the source files
for our User Guides.
For WSJT-X the sources are currently found in these SourceForge directories:
.../branches/doc/wsjtx/source
.../branches/doc/wsjtx/images
This system has worked well in most ways, but does not
Hi Bill,
On 4/8/2015 7:34 AM, Bill Somerville wrote:
> I need the final v1.4.0 manual in place on your server before I can
> build the GA kits, this is because the build fetches the off line manual
> from the same URL it uses for the on line link.
>
> So if we are agreed that we have a reasonable
The WSJT Development Group is pleased to announce the release of WSJT-X
Version 1.4. Installation packages for Windows, Linux, and OS X can be
downloaded from the WSJT web site:
http://physics.princeton.edu/pulsar/K1JT/wsjtx.html
A detailed log of program changes since v1.3 r3673 is available h
Hi Tomáš,
Thanks for your message. Perhaps a slightly more informative
description of the JT65 tone frequencies could be put into the WSJT-X
User Guide.
The second sentence of the section from which you quote advises the
interested user to read the full detailed description of the protocol i
Tnx John, will do!
On 4/12/2015 1:03 PM, John Nelson wrote:
> Hi Joe,
>
> I find that WSJT-X (v1.6 r 5210) crashes with a seg fault in plotter.cpp
>
> The problem seems to be that DrawOverlay gets called before
> mainwindow::on_action_xxx calls are made.
>
> Each of these on_action routines cont
Hi Mike,
On 4/16/2015 10:13 AM, Michael Black wrote:
> Would it be a good idea to make the clicking on the waterfall select JT65/9
> based on the split bar?
>
> So if you click above it JT9 is auto-selected and below JT65 is selected?
> Wouldn't that be the common case?
Apparently you mean automa
Hi John,
Many thanks for sharing your interesting results on processing time
returned by the wsprnet.org server!
Your recent work with WSPR-X has prodded me to think again about
possible future developments of WSPR. I'm presently leaning toward
exploring the possibility of including WSPR as a
1 (Release Candidate 1)
Date: Wed, 22 Apr 2015 12:03:48 -0400
From: Joe Taylor j...@princeton.edu [wsjtgroup]
Reply-To: Joe Taylor
To: WSJT Group
The WSJT Development Group is pleased to announce the availability of
Release Candidate 1 for WSJT-X Version 1.5. Installation packages for
Windows, Linux
Hi Claude, Richard, Greg, and all,
KI7MT wrote:
> FWIW, I think this is a good Idea. I addition to the Hamlib updates, I
> would think the Qt Audio subsystem would also be of benefit.
>
> I like Python, but keeping the tool-chains and frameworks similar would
> surely be a plus and may even draw m
101 - 200 of 1871 matches
Mail list logo
