I assume your unlikely JT9 success is related to the limited bandwidth on many rigs? Split mode gets around the transmit limit but not the receive limit. I know the first time I ran JT9 signals that were > 3000 offset or so I ran into bandwidth limits that I had to adjust so I run in 5kHz width now. I adjusted the waterfall without realizing that it actually controls the bandwidth too. But I do believe it's only the Start, bins/pixel and JT65/JT9 split that have an effect, correct? Gain and offset are just visual as is flatten and smoothing?
Along with changing the defaults I would vote for a one-time message box that explains all this as it's a rather important item that quite a few have run into. And there was mention at one time about split mode helping limit side bands on transmit which should be included in that message too to encourage split mode. Mike W9MDB -----Original Message----- From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Friday, March 27, 2015 8:34 AM To: WSJT software development Subject: [wsjt-devel] WSJT-X: Default waterfall bandwidth. Hi All, after some discussion on the Yahoo WSJT-X list it seems that some users may be confused about the interaction between the waterfall bandwidth and the decoders. This confusion may come about with users who already have a waterfall display of their Rx e.g. SDR users. I propose to change the initial defaults for the waterfall to be a 4 kHz bandwidth (0 - 4000 Hz) with a suitable bins/pixel setting to fit on the smallest likely monitor. Along with this the default mode could be set to JT65+JT9. I see one downside to this, those with HD monitors may drag out the width of the waterfall without adjusting the bins/pixel which will cause a crash if "Flatten" is enabled. This probably needs fixing regardless. We would also have to make it more prominent in the documentation that without enabling split mode operating it is unlikely that transmission of JT9 signals is not going to work. Any objections, comments or, alternate suggestions. I know the user guide does say that the WF bandwidth effects decoding but in the interests in encouraging JT9 activity maybe we should nudge users to look up the band a bit and inform them that they can reduce the bandwidth if their Rx has no output up near 4 kHz. This approach will also make the progression of the tutorials different in that the +2 kHz check box would need to be introduced as an alternative to split operating for those with limited Tx bandwidth. 73 Bill G4WJS. ---------------------------------------------------------------------------- -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
