This is to document a minor aesthetic issue. On OS X, but not on linux, the
Monitor button is smaller than the other buttons when it is off (not Green):
Steve k9an--
___
wsj
Hi Joe,
I get it. That’s a really neat case.
It just dawned on me that having improved the SNR of the sync tone correlation
by 3 dB, we should be able to raise the detection threshold a bit and possibly
reduce the number of spurious (false detections) vectors. That might speed
things up a bit
HI Joe-
Just thought I would report it.
It's not bothering me as I know what causes it.
May be an issue for others if the on JT9 with a lot of additional JT9
stations.
I See you on 160 tonight.
Looks like Eu is coming through for the northern US stations.
SA here so far.
73; Good DX
Bill W2PKY
Hi Bill,
OK, I now understand what you're reporting. Version 1.6.1 r5910 is
quite a while back, code-revision wise.
I tried to reproduce your effect with the current revision, r6041. I do
see a small difference that depends on Rx freq: maybe one or two
additional decoding seconds, with a tot
I would think, and I may be way off base here, the RCVR band-pass would
have an affect on this also.
My 1000MP has INRAD filters with Very Sharpe skirts. When operating both
JT65+9, I've seen decode times slow down a tad. I just assumed ( maybe
incorrectly ) WSJT-X was looking at what I had set
Hi Joe-
My observation is that the total time to decode the received signals is
influenced by the setting of the RX frequency.
IE if setting the RX @ 300 Hz all decoding [65 & 9] proceeds rapidly.
if setting the RX to 2K or above the JT9 prints are delayed significantly.
My computer is a 4Ghz CPU
Hello All,
Attached is an example showing the Data ( or config file path ) and
Logbook Database paths, along with os.getcwd() the ( application install
directory ). Appdirs determined the AppData local paths. In this case,
for Windows-10. I did not add the .Wave file location as of yet. If we
No doubt he did that because HA3LI sent him R-nn instead of just -nn when
WB9OTX answered his CQ. I've not been able to figure out why some people do
that, but if I'm not paying full attention I get caught out the same way.
I'm really looking forward to using the new decoder!
73,
Chris VE3NRT
--
Sorry, I sent this message in a garbled form.
Meant to delete the line "Suppose all data symbols in the wrong", just
above the last paragraph.
-- Joe
On 11/2/2015 4:10 PM, Joe Taylor wrote:
> Hi Steve,
>
> On 11/2/2015 3:59 PM, Steven Franke wrote:
>> Wait. What? Very cool example, but
Hi Bill,
I'm not sure that I understand your point. In JT9+JT65 mode, JT9
decoding is attempted only at frequencies above the "blue line" marker,
set by the "JT65 JT9" spinner control. Decoding is always started
first at the selected Rx frequency and mode, so the decode you care most
ab
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
> mess
Hello JT Developers-
Running 1.6.1 5910, noticed when mode is set to JT65 + 9
and the RX frequency is greater than 1500 the JT9 decoding takes a long
time.
If the RX is above 2000 and there are a few JT9 prints the last one could
come at second 59.
Regularly decode signals -26 -27 -28.
73, Bill
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 message. But then the second message would
decode with a big dt,
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,
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
produced
Hello All,
While working on a the SQL3 database tests for WSJT, I ran across a
rather painless solution for storing user_{config,data,log}_dirs rather
than sticking everything in the appdir = (~\install\directory\root).
Using the appropriate FSH (File System Hierarchy) approach has numerous
ad
On 10/27/2015 09:40 PM, Claude Frantz wrote:
> "./wsjtx --version" says "1.6.1-devel".
Hi Joe and all,
Using revision 6033 today, I have observed this behavior again. I have
noted that this occurs, like previously, at the start of the program and
that it disappears later.
Of course, this is n
This morning I did a debug build of R6033, ran it for 25 minutes with no
errors, lots of decodes (some from Europe with a -24 & -25), and made
one QSO in the US. Built an rinstall version, and currently running it
with no problems, regularly seeing -26 decodes on JT9.
The Fortran error may ha
18 matches
Mail list logo