-------------------------------------------- On Sun, 3/29/15, Bill Somerville <g4...@classdesign.com> wrote:
Subject: Re: [wsjt-devel] WSJT-X: Default waterfall bandwidth. To: wsjt-devel@lists.sourceforge.net Date: Sunday, March 29, 2015, 12:09 PM On 29/03/2015 19:10, Jim Pennino wrote: > Hi Bill, Hi Jim, > > I don't really see a problem. > > You scale the range of values to the range of pixels as a rounded integer. You are probably correct although you can't round an integral division, only truncate. round ( results of all other float calculations) > > That is, for a window 1000 pixels wide and data from 500 Hz to 4 Khz, the > values get scaled to 0 to 1000 with integer rounding and plotted. > > Maybe there are people with the eyes of eagles out there that can see > an artifice at the 1 pixel level, but I can't. The quantization errors are quite large due to the number of FFT bins being of the same order as the number of horizontal pixels. Across the whole waterfall, not much impact, but on a single JT9 signal in a 4 kHz waterfall fairly significant for awkward unfortunate scaling choices. It was my understanding that the waterfall, other than the start and stop frequencies had nothing to do with decoding. In any case, a strong JT9 signal show "splattering" all around the signal; I don't see where it would matter. > > The only was I can see where this would effect the accuracy of anything > is the case where someone had a very narrow (in pixels) display and clicked > on the waterfall, in which case they could be off frequency by a few Hertz, > which is basically irrelevant as a signal can be off for tens of Hertz and still > decode in the receive pane and any error will be corrected when the responding > call is clicked. The tolerance for "on frequency" is roughly +/- 10Hz but I don't think that will be an issue, I was more concerned about the accuracy of signal representation. Most times this is not important as double clicking a decode sets the correct net frequency without requiring manual adjustment. I too would like to see a more flexible waterfall implementation and this is certainly worth investigating. Currently Joe is working on VHF & up usage in a separate branch and I believe this involves some waterfall changes so now is not the best time to start making changes in that area because it will complicate any future merges of this enhancements. OK, I can buy that. FWIW, I find the current waterfall to be of marginal utility, especially when I try to use rig features like notching out a strong non-JT signal and the waterfall basically goes bat crap crazy. I would rather see a dumb, simple spectral display who's limits matched the decoding limits which are expliitely set and unchanged by the window size in pixel. 73 Bill G4WJS. > > -------------------------------------------- > On Sat, 3/28/15, Bill Somerville <g4...@classdesign.com> wrote: > > Subject: Re: [wsjt-devel] WSJT-X: Default waterfall bandwidth. > To: wsjt-devel@lists.sourceforge.net > Date: Saturday, March 28, 2015, 4:54 PM > > On 28/03/2015 22:48, Jim > Pennino wrote: > Hi Jim, > > > I too think the waterfall in it's current configuration > is confusing and a bit unwieldly. > > > > What I would like to see is the bins/pixel > control go away and be replaced by a Stop control. > > > > The frequency spread > would then be controlled by the Start and Stop controls. > > > > Resizing the window > should do that, and only that, i.e. resize the window. The > bins/pixel > > becomes an internal > calculation. > > > > Doing > that would make the window monitor independant and each user > can set things > > up that best match their > combination of radio bandwidth and monitor width. > > > > The initial defaults > should be about 500 Hz to 4 KHz with a width of about 1000 > pixels, > > which should display on any > monitor, including laptops, from the last decade or so. > That is a rather more complex proposal to > implement and may well be > undesirable. > > There are two choices, either > maintain the integral relationship between > horizontal pixels and data plotted on the > waterfall or do a much more > complex > floating point plot mapping that may not actually result in > a > clean waterfall display. > > The former would have to make > dragging the width of the waterfall a very > clunky operation with large "steps" > in size, the later would make the > waterfall > width independent of bandwidth at a considerable computing > and > accuracy penalty. > > > > > > > > Bill, > this is where some of the confusion arises with those > > new to the mode > > (I'm still learning). I > now use the WSJT-X waterfall after > > Mikes help, now > > that I realise its > importance. > > > > The thing is that you mention > the default bandwidth and then > > a suitable > > bins/pixel setting as two > different things. When I adjusted > > the bins/pixel > > setting here I also increased > the waterfall bandwidth. > > > > I was not aware that some of > the waterfall settings did not > > just alter the > > display, but configured > WSJT-X too. > > > 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 ------------------------------------------------------------------------------ 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
