blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px
#715FFA solid !important; padding-left:1ex !important; background-color:white
!important; } Hi Bill,
Thanks for the reply and the explanation of the decode process. This was very
interesting; it did, however, make me wonder what was happening on my system.
Before sending my initial email on this, I had watched my decode displays over
several lengthy sessions and it didn't correlate with the information you gave.
I had no interspersed JT9 and JT65 decodes displayed, nor was the station on my
RX frequency dumped out into the rightmost box until it was his "turn" over on
the left side. Very strange.
But....... by the time I got to reading your reply, I had shut down WSJT-X and
restarted it. After doing this, everything went exactly as your description
said it would. I can only guess as to what had been going on before the
restart. One thing I can tell though, I had WSJT-X up and running for several
days without a restart. And, during that time I had jumped back and forth
between WSPR-2 and JT65/JT9 mode quite often. That is my normal mode of
operating. If I'm going to be away from the radio for any length of time, I put
it into WSPR-2 mode and let it do the RX/TX thing. Then, when I return, I go
back to JT mode and operate. Is it possible that somehow this back and forth
procedure introduced something that made the software think I was NOT operating
on a multi-thread processor?
At any rate, I will keep my eye on things. If I see it start doing what it had
been doing previously, will restart the application.
Thanks & 73, Jim / W6JHB
Sent from Yahoo Mail for iPad
On Saturday, June 25, 2016, 1:14 PM, Bill Somerville <g4...@classdesign.com>
wrote:
On 25/06/2016 20:54, Jim Bennett wrote:
> Now, what is my suggestion? How about if during the decode pass, that
> a signal decoded within +- a few Hertz of the operator's current
> receive frequency is the FIRST thing sent out to the decode display
> window? That would give the operator of the RPi (or any other "slow"
> processor) enough time to decide if his next transmission should be
> aborted or proceed as normal. If the "decode code" would look to see
> if (1) the Enable TX is turned on, and (2) there is a signal very
> close to the receive frequency, dump it out to the display first. Now
> THAT would be cool... :-)
Hi Jim,
the way the decoding is done is not quite as you describe. We are very
aware that not all CPUs are fast enough to decode signals on an HF band
as fast as users would like. The first thing that is done is that the
decoder concentrates on a small window around the DF of the Rx cursor
and will always decode a detectable signal in that window first. This
ensures that once you are in a QSO or simply have clicked on the
waterfall or an interesting signal or double clicked a decode you are
interested in; then an attempt to decode that signal is completed before
anything else.
When running JT9+JT65 mode there is another strategy employed as well if
you CPU has multiple processing threads available, the two modes are
decoded in parallel each utilizing a different CPU core. If you are
seeing one mode *always* decoded before the other then either you do not
have a multi threaded CPU or you have the settings such that one mode is
taking much longer to process. If you are seeing *any* interleaved
decodes (between the two modes) then you definitely have a multi
threaded CPU. Things that can slow down decoding of a mode include:
having the JT9 separator (blue line) set too low - this will slow down
JT9 decodes because JT65 signals in the JT9 decoder passband slow down
the JT9 decoder a lot. For JT65, with the latest decoder, you have
control of the effort applied to try and decode detected signals - in
"Settings->Advanced" you can adjust the "Random erasure patterns" spin
box. This control can be set as high as 7 or 8 on fast CPUs but if you
have a slow processor try lower levels for much snappier decoding. Lower
values will reduce the effective sensitivity of the decoder but the
difference in number of decodes is probably going to be very very small
compared to the potential time savings.
If nothing above helps with your situation then your best strategy is to
use single mode but that is unlikely if you CPU is multi thread capable
- which yours is.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
