Igor --
I do not know what's happening in your setup, but none of those effects
is true here. The audio for every transmission starts at phase angle 0
(and therefore amplitude 0). There is no tone burst before the message
transmission. There are no clicks.
Have you listened to your
The WSJT Development Group is pleased to announce a second candidate
release for WSJT-X Version 1.6.0.
Changes since v1.6.0-rc1 include the following items related to rig control:
- Improved Yaesu FT-817/857/897 support
- Speed up interaction with the Kenwood TS-940S
- Full IPv6 support
Mike and all,
On 12/16/2015 12:00 PM, Michael Black wrote:
> This brings up the idea that perhaps we should remember power level for
> each mode/band.
Let's not get carried away implementing special-purpose features. Lower
power for Tune is probably useful for some, and OK.
I think power
Hi Greg,
Unless I've done something wrong, jtsdk-nix-2.0.18 seems to be
installing to the wrong place:
-- Installing:
/home/joe/jtsdk/wsjtx/1.7.0/6283/install/Release/usr/bin/wsjtx
Should be .../install/Release/bin/wsjtx
NOT: .../install/Release/usr/bin/wsjtx
-- Joe
REFIX at the top (line 51) of the jtsdk-wsjtx script to:
>
> CM_PREFIX=""
>
> That would take it back to: /install/Release/bin/wsjtx
>
> 73's
> Greg, KI7MT
>
>
> On 12/16/2015 01:50 PM, Joe Taylor wrote:
>> Hi Greg,
>>
>> Unless I've done something wrong
ral times and the error repeated on the next decode.
> But now it's not doing it.
> Phase of the moon?
>
> I will, naturally, let you know if this repeats again.
>
> 73
> Mike W9MDB
>
>
> On Wed, Dec 16, 2015 at 3:45 PM, Joe Taylor<j...@princeton.edu> w
Barry --
Did you read my WSPRnet message posted here ?
http://wsprnet.org/drupal/node/5786
If not, please refer to it now.
We in the WSJT Development Group have nothing to do with running
WSPRnet. I hope the problem will be sorted out some time soon...
Of course, you don't need a WSPRnet
B
>
>
>
> On Thu, Dec 17, 2015 at 8:10 AM, Joe Taylor<j...@princeton.edu> wrote:
>
>> What was "just for testing"? What error seems random???
>>
>> The error you reported yesterday was fixed with r6286.
>>
>> -- Joe
>>
&
ng results,
as obtained, back to the GUI thread. I haven't spent the time to work
out how to (in effect) send Qt "signals" from the Fortran code.
-- Joe
On 12/17/2015 9:29 AM, Bill Somerville wrote:
> On 17/12/2015 14:25, Joe Taylor wrote:
>> Not sure what you meant by &qu
umulative the spectrum
> level looks the same.
> Not sure why just that one entry should be *2.5 when the others are not.
> 73
> Mike W9MDB
>
>
>
> On Thu, Dec 17, 2015 at 9:15 AM, Joe Taylor<j...@princeton.edu> wrote:
>
>> Please explain why removing the 2.5
Scott --
You're running test code. To do it from the standard location you will
need to comment out lines 150-153 in routine jt65a.f90:
write(79,3001) nutc,nint(sync1),nsnr,dtx-1.0,nfreq,ncandidates,&
nhard_min,ntotal_min,ntry,naggressive,nft,nqual,decoded
3001
Hi Bill,
Many thanks! I will read your new code -- and will be on the lookout
for any unexpected behavior.
-- Joe
On 12/17/2015 3:35 PM, Bill Somerville wrote:
> Hi All,
>
> I have committed a change r6290 that cuts right across wsjtx.exe and
> jt9.exe, it is a first stage of moving
Hi Greg,
Could you check to see whether jtsdk builds WSJT-X r6278 properly in
Linux? I checked in a bunch of code changes and may have messed
something up. It seems to build OK with Windows JTSDK, but in Linux the
jtsdk script does the Hamlib3 tests and then outputs the following:
Important note to those who have been compiling and using code at the
head of the WSJT-X Development branch, also known as "Version 1.7":
REVISION 6278 IS TEST CODE, NOT INTENDED FOR ON-THE-AIR USE. PLEASE
RESPECT THIS REQUEST AND DO NOT USE IT FOR NORMAL OPERATION.
-- 73, Joe, K1JT
ent. However, the work around is
> as follows:
>
> * Edit: sudo gedit /usr/bin/jtsdk-wsjtx
> * Comment out lines: 346 to 362
>
> That should skip the wsprd_exp build step and continue on as normal.
>
> 73's
> Greg,. KI7MT
>
>
> On 12/15/2015 02:44 PM, Joe Taylor
On 12/14/2015 12:24 PM, Игорь Ч wrote:
> Hi Joe and all,
>
> In the JT65 protocol document there is statement: 'For the tests
> illustrated in Figure 4 with SNR less than about –29 dB, failure
> to synchronize is the cause of many failures to decode.'
>
> Quick question: why do not we
Hi Bill,
Thanks for sharing your thoughts on release announcements.
I agree that making RC releases earlier (and more often in the work
cycle) makes sense. Also that having ~15% of the active user base
trying out the RC is more than we need.
Probably most of those testing our RCs find out
to the development branch in part so we (the developers)
can keep up-to-date with one another's work. Except when otherwise
announced, builds from the HEAD of the development branch are NOT to be
considered as Alpha releases. They are nothing like it.
-- Joe, K1JT
On 12/15/2015 7:48 PM, Joe Taylor
Hi Mike,
One of the advantages of open source software is that anyone with
special needs or desires can study the code and learn enough to make the
changes needed to implement them. You have done the hard work and
evidently have solutions that suit your purposes (which, if I've
understood
Hi Ed,
K0KC wrote:
> I am currently testing WSPR-2 with WSJT-X 1.7.0 r6333 on 30 meters.
> I am getting multiple decodes at -30 dB. Seems like all of the
> hard work that the development team has put into this release
> has paid-off.
> I wonder how this performance translates to JT65 and JT9; I
Hi Bill and all,
> currently the WAV files generated by WSJT-X only contain the audio
> format description and the PCM sample data. I note that there has been
> some investigation into adding some metadata to the files as well. ...
Adding some metadata to our .wav files has long been on my "to
Hi Igor,
Hinted decoding is not for use at HF.
-- Joe, K1JT
On 1/5/2016 12:05 AM, Игорь Ч wrote:
> Hi Joe and All,
>
> I would like to create Call3.txt for HF hinted decoding using the collected
> All.txt files,
>
> what do you think if it is worth to make somewhere storage for
Hi Borja,
On 12/31/2015 4:46 AM, ea2...@gmail.com wrote:
> While getting acquainted with the project sources, there is a
> contribution I can make, translating the manual to Spanish.
> Has it ever been considered?
>
> 73,
> Borja EA2EKH
In general we have been delighted to have translations of
On 12/31/2015 1:09 PM, Guy G4DWV/4X1LT wrote:
> Joe Taylor<joe@...> writes:
>
>
>
>> Normal operation at HF should set "Aggressive decoding level" to 0.
>> If you try operating on HF with higher values, be sure to set Ftol=1000.
>>With
Hi Steve and all,
In case you have built WSJT-X v1.7 from r6329 and used it on the HF
bands, you'll surely see many more false decodes than usual. As
committed, the code uses aggressive values for the parameters d_0 and
r_0. These values may be appropriate for EME-like conditions, but
Hi Bill,
I can work around any conflicts. As far as I'm concerned, you can go
ahead and commit.
Looks like I won't have the JT4 test files ready until tomorrow.
-- Joe
On 12/29/2015 4:36 PM, Bill Somerville wrote:
> Hi Joe, Steve& all,
>
> I am about to make a checkin that retires
Hi Mike,
On 12/31/2015 5:04 PM, Michael Black wrote:
> It seems as though once aggressive decoding is turned on you can't decode
> JT65 with JT9 any more. All you get is JT9 decodes in the combo mode.
Thanks for pointing out this anomalous behavior.
As I assume you must understand, our
t;
> 73, Edson PY2SDR
>
>
>
>
> ---
> - We humans have the capability to do amazing things if we work together.
> - Nós seres humanos temos a capacidade de fazer coisas incríveis se
> trabalharmos juntos.
>
> On Fri, Jan 1, 2016 at 3:09 PM, Joe Taylor<j...@princet
Hi Steve,
On 1/1/2016 11:25 AM, Steven Franke wrote:
> All-in-all - across-the-board improvements are evident and, based on my test
> results, r6330 has the best jt65a decoder performance of any version that we
> have produced to date.
Thanks for sharing your latest test results. They're fully
KF2T wrote:
> Happy Christmas, Joe...
>
> After a longer stare at the waterfall, the lower traces appear
> not to be WSPR-2. They look a lot like it, but keep on going much
> longer. Perhaps I haven't been as attentive as I should have been!
Indeed, the signals just below the 30m WSPR band are
ompted me to learn a bit about FORTRAN 90.
>
> RRR
> Mike W9MDB
>
> On Thu, Dec 17, 2015 at 1:13 PM, Joe Taylor<j...@princeton.edu> wrote:
>
>> Mike --
>>
>> A brief addendum to Bill's comments.
>>
>> Fortran90-style modules are always a good ide
Hi Greg,
On 12/17/2015 4:08 PM, KI7MT wrote:
> Also getting allot of odd decodes, see attached.
I see you were running with "Aggressive decoding level = 5". For
operation at HF the recommended setting is 0. These advanced features
are for EME and the like.
-- Joe
Bill --
> I have noted that selecting the "Current" plotter spectrum in WSPR mode
> causes problems, I thought it was down to my changes but it seems to be
> from before that. I see massive overload when I have have that enabled
> in WSPR mode.
For what it's worth: in a quick test here, I don't
Hi Bill,
Sure, your ideas for timer sound OK. I only wanted to avoid having
"timer" prove to be a hangup of any sort, as I don't see it as a very
high priority.
-- Joe
On 12/18/2015 11:05 AM, Bill Somerville wrote:
> On 18/12/2015 15:41, Joe Taylor wrote:
>> Y
Hi Bill,
A brief report to say that I've been exercising v1.7 r6290, running for
several hours making QSOs on HF with JT9 and JT65, and on 6 meters with
JTMSK.
I haven't yet hit any unexpected behavior. Nice job on some sensible
refactoring of the code!
I will continue to read and review
Bill --
I think we should allow @ in column 1 in any message box. For many
years this has been interpreted (in WSJT) as a request to transmit a
fixed tone at a specified frequency.
Surely the need for "@" in other messages, especially in column 1, is
negligibly small.
-- Joe
On
Tnx Mike -- Done.
On 12/18/2015 5:34 PM, Michael Black wrote:
> Really long, complicated patch :-) to allow any message button press to
> reset the watchdog timer.
> A minor annoyance.
>
> Index: mainwindow.cpp
> ===
> ---
. That should
be possible in a number of fairly simple ways.
-- Joe
On 12/17/2015 6:46 PM, Bill Somerville wrote:
> On 17/12/2015 14:42, Joe Taylor wrote:
>> On a related matter: have you given up your effort aimed at compiling
>> the decoders into wsjt-x, as opposed to a separ
On 12/18/2015 4:07 PM, Michael Black wrote:
> I think the idea is that they want the "@" to remain. But if it's always
> "@" with N=frequency could JTAlert allow that through without
> substitution?
That's irrelevant. A message of the form "@" is for WSJT or WSJT-X
alone. There's no
Hi Laurie, Bill, and all,
On 12/18/2015 3:49 PM, Laurie, VK3AMA wrote:
> This is not a JTAlert issue. ...
I don't see that it was ever an issue, at all. The uses of "@"
messages for special purposes never bothered anyone, as far as I'm aware.
-- Joe, K1JT
Hi Steve and all,
I've committed some changes that increase the range of acceptable DT
values in JT65 mode to -2 to +5 s. This should fix the occasional
garbage decodes I've been seeing on strong signals with DT < -1.1 s -- I
think they are the "circular shift, off-by-one-symbol" cases you
Hi Steve,
Thanks for finding and fixing the mysterious half-symbol offset!
-- Joe
On 11/26/2015 8:53 AM, Steven Franke wrote:
> Hi Joe,
>
> Sleep is a wonderful thing. I found the problem right away this morning. The
> first pulse generated by jt65sim (which is a sync pulse) *was* a
always allowed for in the computer clock and its movement through the OS
into the Tx and Rx software. That's why a range as large as -2 to +5 s
makes sense -- asymmetric to allow for the 2.5 s EME delay.
-- Joe
On 11/25/2015 12:46 PM, Bill Somerville wrote:
> On 25/11/2015 17:37,
Hi all,
PSK Reporter now shows 450 people using WSJT-X v1.6.0-rc1. We have
received only a few reports about undesirable behavior; I think they
were all minor and easily dealt with. Is it time for a GA release of
Version 1.6.0?
-- Joe, K1JT
Version 1.6.0 uses kvasd. Version 1.7.0 (formerly known as v1.6.1) does
not.
On 11/18/2015 9:11 AM, Richard Shaw wrote:
> Sorry if I missed the email but I remember seeing some discussion on the
> replacement of kvasd. Is that transition (or will it be) complete with the
> release of 1.6.x?
>
>
Hi Bill and Greg,
Thanks for looking into the font-rendering issue I raised.
> https://dl.dropboxusercontent.com/u/4192709/wsjtx-main.html
With default settings my browsers display your html file very nicely.
I'd say the 90% setting is an improvement.
To my eyes, the pdf file you posted here
Any measurement has an associated uncertainty. More precisely, for any
measurement there is a probability distribution of "true" values that
might have given rise to the measured value. Seeing an occasional
measured value of -29 dB is nothing to be concerned about.
-- Joe
On
Hi Steve and all,
I've added what I hope is a reasonable EME fading model to the simulated
data files produced by jt65sim. The fading characteristic is defined by
a specified amount of "Doppler spread" (in Hz) applied to the simulated
signal. Typical Doppler spreads on popular EME bands are
Hi Rex,
Thanks for the reminders! Your item 6 is included in my item 3
("Optimizations of submodes B and C). I agree that the degradation
facility can be useful; I'll put that on the list. Also maybe JT65D
(and even JT65E?) ? I'll think more about these.
-- Joe
On 11/20/2015 2:57
Hi Steve,
Sure, feel free to make some new use of the ndepth parameter.
-- Joe
On 11/21/2015 5:36 PM, Steven Franke wrote:
> Hi Joe,
>
> I’d like to try to add a checkbox to the Advanced setup tab that will
> control, in some fashion to be determined, the robustness of the jt65 sync
>
Hi Bill and all,
FYI, related to minor thread "Redundant Information in the WSPR Receive
Window" a few minutes ago: with r6149 I have made the necessary change
in the v1.6.0 branch to correct this unwanted behavior.
-- Joe, K1JT
Hi Steve and all,
I've attached a plot comparing the sensitivities for decoding JT65A in
WSJT 10.0 (r6088), WSJT-X v1.6-rc1, and WSJT-X v1.7 (r6131). The
simulated channel is AWGN; the demodulators all use noncoherent
measurement of symbol amplitudes. Correlation decoding and message
Hi Steve,
When is a dB not a dB?
The calibration of signal strengths in my recently written "jt65sim" is
probably not exactly the same as that in "SimJT", which we used before.
All the measurements here were based on files produced by jt65sim.
Probably we should establish a standard, and
Hi Bill and all,
I've noticed recently that invoking "Help | Online User Guide" from
within WSJT-X v1.7 incorrectly sends one's browser to
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-main-1.7.0-devel.html
The correct location is
Hi Bill,
More on our User Guides, this time concerning content.
I believe we have some wrong/garbled/misplaced entries in the "Platform
Dependencies" section of the V1.6.0 User Guide:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.6.0.html#PLATFORM
For example, look under
Hi Anders, Borja, and all,
I suggest that translations should probably start with the WSJT-X User
Guide in the development branch -- that is, the Guide for Version 1.7.0.
As it now stands, this document is not much different from the one for
version 1.6. New sections need to be written for
Steve --
Try revision 6723. The problem is a collision between Neal's global
variable "table" and one of the same name in pulseaudio. I renamed ours
to "ldpc_table".
-- Joe
On 6/3/2016 3:21 PM, Steven Franke wrote:
> Hi Bill and all,
>
> Trying to build the latest on Ubuntu 14.04.
Hi Dave,
>I have been using Various WSJT packages for several years.
> WSJT-X V 1.6.1 is terrific but there are a couple additions that could
> make it even better ( in my humble opinion).
Actually we're 'way beyond v1.6.1 now. Version 1.7 has many features
not in v1.6.x. We have yet
Hi George,
On 6/5/2016 11:44 AM, George J Molnar wrote:
> Haven't had much luck with any of the versions including MSK144 on my Mac.
When and if MSK144 becomes a supported mode in WSJT-X, we'll let
everyone know what it is, what it's good for, and how to use it. In the
meantime, it's best to
Bill --
Thanks... and yes, please look into it!
-- Joe
On 6/8/2016 5:06 PM, Bill Somerville wrote:
> On 08/06/2016 21:43, Joe Taylor wrote:
>> In WSJT-X r6739 if you have Monitor stopped and then switch mode to
>> JT65, JT9+JT65, or WSPR, Monitor is turned on. Switch
Hi all,
In WSJT-X r6739 if you have Monitor stopped and then switch mode to
JT65, JT9+JT65, or WSPR, Monitor is turned on. Switching to JT4, JT9,
ISCAT, JTMSK, or MSK144 does not turn Monitor on. This seems illogical.
Was there a good reason that I've somehow forgotten?
-- Joe,
Hi Bob,
I'm not aware that anyone else has observed the strange behavior shown
in your screen shots. Certainly I haven't seen it here.
It might be helpful to set about diagnosing your own problem. Your
screen shots suggest that you have an unusually large number of programs
running, and
Thanks, Bill! -- Joe
On 6/3/2016 7:43 PM, Bill Somerville wrote:
> On 04/06/2016 00:18, Joe Taylor wrote:
>> I thought I did the right things when adding mode "MSK144" to v1.7. All
>> seems OK, with one exception: when I right-click in the Working
>> Frequencies
Hi Bill,
I thought I did the right things when adding mode "MSK144" to v1.7. All
seems OK, with one exception: when I right-click in the Working
Frequencies area of Settings | Frequencies and select Insert, the pop-up
"Add Frequencies" window does not offer MSK144 as a valid mode. Could
you
Hi all,
On 6/10/2016 10:18 AM, Black Michael wrote:
> I can't think of a reason to not start monitor...but shouldn't it
> be consistent across mode changes then? I would think any change
> from mode-to-mode should behave the same. Maybe Joe has a reason
> to not want to start it since he
Hi Bill,
I think I see it the way Mike does: just leave monitor alone, let it
stay the way it was set when doing a band change.
-- Joe
On 6/10/2016 11:01 AM, Bill Somerville wrote:
> On 10/06/2016 15:40, Joe Taylor wrote:
>> I frequently run with Monitor off at startup, most
Hi Bill,
Today I've received three messages about email sent to your standard
address, marked as
Message could not be delivered for 1 day
Message will be deleted from queue
Are you receiving email?
-- Joe
--
Hi Bill,
Thanks for making the GPL URL in the "About" window a live link, and
adding the GPL logo.
Here's a related suggestion. Would it be reasonably easy to add our own
WSJT-X logo alongside the GPL logo, say to its left? The juxtaposed
images would help to convey the cooperative,
Igor --
Please feel free to tune the WSJT-X decoders in any way you see fit, and
to use external bandpass filters on the data as you wish.
One of the benefits of open-source code is that you can modify it as you
desire. If you come up with code you believe is superior, I'm sure you
will let
Thanks, Bill -- those changes are exactly what was needed.
-- Joe
On 1/13/2016 10:06 AM, Bill Somerville wrote:
> On 13/01/2016 14:05, Joe Taylor wrote:
>> More on our User Guides, this time concerning content.
>>
>> I believe we have some wrong/garbled/misplaced ent
Mike --
Whatever tests you might choose to do would have more value if they were
your own -- i.e., independent of tests already done by others.
If you want representative JT9 and JT65 data, set up in dual mode on
14.076, on a weekend in daytime, check "Save all", and let it run for
all day.
Hi Bill,
At VHF and up, users of WSJT(-X) will generally want to start a session
with FTol at a high value. As you say, once set the value persists on
another program startup -- so I wouldn't have thought this is a big
deal. I guess we could say the default is FTol if the band is above 30
Hi all,
A brief note to say that I'll be away and out of email contact between
Feb 7 and Feb 13.
-- Joe, K1JT
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM:
Hi Bill,
No doubt it's about time to fix the sub-par performance of the JT65
decoder when used for submodes B and C. (Maybe also time to implement
submode "D", which has been requested by the microwave EME guys.)
For your tests I see no reason to be using "Robust sync" or "Two-pass
Igor --
On 1/21/2016 10:54 AM, Игорь Ч wrote:
> I have checked JT65-HF 1.0.9.3 and JT65-HF HB9HQX v2.0 TX audio
> using virtual audio cable and r6404 for RX.
>
> JT65-HF 1.0.9.3 in my setup transmits dirty signal with the multiple glitches.
>
> JT65-HF HB9HQX v2.0 has mostly clean signal, but
Igor --
On 1/22/2016 12:48 PM, Игорь Ч wrote:
> In the latest WSJT-X release we still have large unwanted side
> spectrum emissions at beginning and end of the message transmission.
I consider it a gross exaggeration to say that transients at the start
or end of JT9/JT65 transmissions cause
Hi all,
K9YC wrote:
> The decibel IS a ratio.
I think all here know the meaning of a decibel.
The reference level is often taken as understood -- which means it's
understood in the context of some particular usage. Sloppy, perhaps,
but we all use shorthand language for convenience.
A
Igor, Bill, Mike --
UA3DJY wrote:
>> Hello Mike,
>>
>> Width of the tones is the reason behind it: each single tone
>> occupying spectrum of the several tones, it is Doppler effect.
>>
>> I wrote message on it to Joe K1JT some time ago, this propagation
>> issue had not high priority in the
On 1/23/2016 6:35 PM, Michael Black wrote:
> allowing for 60dB that's a factor of 106, right?
Sixty dB is a *power* ratio of one million, or 10^6. Not 106 (one
hundred six).
Equivalently, 60 dB is a *voltage* ratio of one thousand; and 30 dB a
voltage ratio of sqrt(1000) = 31, approx.
So,
Hi all,
Glad you enjoyed the LIGO links, etc.
On 2/16/2016 9:36 AM, Bill Somerville wrote:
> it must be fantastic to have the LIGO team make direct observations here
> on Earth of what your previous work had measured indirectly!
>
> Do you think they got lucky with their detection so soon after
Hi Bill, Michael, and all,
On 2/16/2016 2:00 PM, Bill Somerville wrote:
> it seems such a large clean signal that I assume even the previous
> equipment might have detected it.
The design sensitivity of Advanced LIGO is 10 times better than the
previous detector, and the low-frequency end has
On 2/19/2016 9:57 AM, Guy G4DWV/4X1LT wrote:
> For days, there does not seem to have been any new builds for wsjtx; I have
> been stuck on r6469. Is that really the current state of affairs or is
> something broken?
- Nothing is broken.
- I have been traveling.
- Most of us have "day jobs";
Hi Guy,
No problem, I assure you. Read my post as simply a request for
patience... and thanks for your continued interest and contributions.
-- Joe, K1JT
--
Site24x7 APM Insight: Get Deep Visibility into
Mike --
Best not to build the jt65 executable during ongoing development of JT65
decoding with averaging and variable smoothing. Temporary work-around:
comment out lines 959 and 960 in the top-level CMakeLists.txt.
-- Joe, K1JT
On 3/9/2016 4:49 PM, Michael Black wrote:
>
Hi Mike and all,
On 3/10/2016 1:16 AM, Michael Black wrote:
> r6514
>
> Seems the decodes for JT65 are showing "*" instead of "#" on the Band
> Activity window and when sent to the Rx Frequency window on
> double-click.
>
> This is causing JT65 transmits to switch to JT9 on every transmit
Thanks
Hi Bill,
Am I missing something here? Is there a good reason to have implemented
subroutine jt4_average as a callback, when all it does is write a few
items out to file avemsg.txt?
I've presently done the equivalent things for JT65 by simply writing the
desired info to logical unit 14,
Hi Bill, Mike, and all,
1. RR understood. Using a file is simple, but perhaps less elegant. I
guess I'll leave it as is, for now.
2. The problem with JT65 decodes is now fixed, I believe.
-- Joe
On 3/10/2016 2:07 PM, Bill Somerville wrote:
> On 10/03/2016 19:02, Joe Taylor wr
Hi all,
As of revision 6538, WSJT-X v1.7 (the development branch) should once
again be suitable for use on the HF bands.
It's possible that there could still be some undesired side effects of
recent changes to the JT65 decoder aimed at VHF/UHF/Microwave usage. If
you observe any undesired
/wsjtx/lib/wsprd
> make -C wsprd CFLAGS='...' wsprd_exp
>
> All in all, the experimental status of the wsprd_exp code fits very well
> the experimental status of my multiband WSPR receiver and I'm having a
> lot of fun with both :-)
>
> Best regards,
>
> Pavel
>
> Joe Tayl
Hi Alberto,
> please pardon my truly naif question, but, isn't Fano a decoding algorithm for
> sequential
> convolutional coding, while your FT decoder is meant for block RS coding ?
> Do you mean that JT4F doesn't use RS, while JT65C does ?
Yes, JT4 uses a convolutional code with K=32, r=1/2.
Hi Alberto,
On 3/30/2016 1:16 PM, Alberto I2PHD wrote:
> On 3/30/2016 7:08 PM, Joe Taylor wrote:
>
>> /More recently, Steve (K9AN) and I developed an open-source Reed Solomon
>> decoder for the (63,12). Many messages about this work are in the
>> wsjt-devel Archives,
Hi all,
Lots of work has been going on (off list) on optimizations of the JT65
decoder for cases where Doppler spreading is significant. A summary
graph of my most recent simulation results is attached.
I've come to believe that using any JT65 submode (including C or even a
"D" submode) is
o this group to find a
link to its Archives.
> In past versions of his code Joe Taylor used the closed-source Koetter-Vardy
> soft decoder for the Reed Solomon FEC. At a certain point in time, he
> declared that the KV decoder was replaced by an open-source one, written by
> N4HY (
Hi Pavel and all,
Thanks for your effort on optimizations in wsprd. The change from
doubles to floats has been on our "To Do" list for many weeks. We
didn't get around to it because the potential gains (though desirable)
were not likely to be huge. Floats have enough precision for use in
Nice!
On 3/30/2016 8:34 PM, Greg Beam wrote:
> Not a WSJT Dev issue per say, but, interesting nonetheless.
>
> http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash
>
>
> 73's
> Greg, KI7MT
>
>
>
>
>
Hi Alberto,
On 3/30/2016 6:32 PM, Alberto I2PHD wrote:
> all clear, thanks. Well, with k=32, the use of Viterbi is out of question, for
> sure ! A state machine with more than 4 billion states is just...
> impractical... :-)
Agreed. Note that although sequential decoding with the Fano
Hi all,
I have often thought it would be convenient if WSJT-X provided a way to
save its current configuration -- window sizes and positions, mode,
band, etc. -- so that it can be restored at another time.
I do this now in a round-about way, by using the multi-instance feature.
I start the
Josh --
Thanks for the report. For what it's worth: nothing has been changed
recently (knowingly, at least) in the Tx audio chain.
-- Joe, K1JT
On 3/22/2016 5:06 PM, Josh Rovero wrote:
> Just noting that it required major changes to my transmit audio volume
> (increase, in this case)
Hi all,
In the past several days I've once more had some time to devote to
WSJT-X, and I thought a brief progress report might be useful.
Until now the JT65 decoder in WSJT-X has been essentially HF oriented.
In particular, it has not included the following features that have been
present in
Hi Charlie,
Many thanks for sharing your test results -- they are much appreciated.
Following up on them, I found an issue in the JT65 DS routine that can
*sometimes* hinder finding a valid decode. It has been fixed in
revision 6568.
To test in a way consistent with your tests, I ran two
401 - 500 of 1545 matches
Mail list logo
