JS8Call-improved
Replies: 16 comments 1 reply
|
Different operating systems render the waterfall differently. It does not do what you describe on Mac. BUT if I use a narrow filter in my IC-7300 it will display darker bands on the waterfall like you show in your second screenshot outside the filter edges. And I can change that by making the filter edge sharp or soft. So make sure what you are seeing is not an effect of the passband filter in your rig. |
|
I'm sure that the anomaly that I observe is not caused by any filter in the radio. The noise spectrum fed to JS8Call is perfectly flat within 100 - 3000 Hz or so, I have checked it with other FFT/waterfall applications. The strange thing is that the spectrum flatness changes significantly and becomes "un-flat" when the "Waterfall Controls" window is closed (shift-F4). Look at my second screenshot again. The lower 2/3 shows the waterfall when the Waterfall Controls window was open (flat), the upper 1/3 shows the waterfall (and spectrum graph) after the Waterfall Controls window was closed (not flat). I don't think that the spectral response should depend on whether a control window is open or not. |
|
No, it shouldn't. And it certainly doesn't do that here on MacOS. With the controls displayed: 
Taking a screenshot immediately after disabling the controls. 
So is this a problem in the code? FFT visualization renders differently between Linux and Mac/Windows primarily due to fundamental differences in graphics rendering engines. The anti-aliasing techniques, and font smoothing algorithms are different even with fonts, i.e. MacOS's stem darkening vs linux focus on subpixel rendering, which was originally invented by Steve Wozniak back in the 80's and is obsolete with today's OLED screens. So the linux guys are going to have to take a look at this one since it doesn't happen on Windows either. Perhaps @rruchte or @Joe-K0OG has some ideas. |
|
Side note for the linux guys: are we rendering in software on Linux, or like MacOS is the GPU being used to render FFT? There could be fundamental differences in the underlying rendering system, software vs hardware. I'm not sure of the capabilities of linux kernel in being able to hand off things like this to hardware. |
It's software rendering on any platform, using the CPU, not the GPU. I made that more efficient, but didn't change it to use GPU rendering, as that was early in the Qt6 porting effort and things were really in flux at the time. Multiplatform GPU rendering with Qt6 is quite doable; my screenshots in this thread are exactly that -- shaders running on the GPU for the waterfall and spectrum, with compositing on the CPU only for the translucent frequency overlay portion. |
|
I'll take a look, but that's pretty far outside my wheelhouse. Just looking at it, it seems like some math isn't mathing when the controls are hidden, which intuitively seems like a Linux-specific logic bug somewhere in our code, not anything to do with the system's rendering. |
|
Allen and I haggled over this a LOT when we were working on 2.3.0. We arrived at a "sweet spot" where all three OSs worked acceptably well. I suggest it not be changed. In the example provided by the original poster, he has the spectrum display pushed too far outside the upper and lower filter skirts. Pull it in to right inside the filter edges, and it will display perfectly. This is NOT related to the JS8Call filter settings, but the waterfall upper and lower limits. If the operator insists on seeing the filter shape "raw" he should NOT be using flattening. One purpose of the flattening is for older filters which do not have a very good shape. 73, |
|
To illustrate what Joe is talking about, here is the waterfall zoomed in. You can clearly see the edges of the rig filter. Run the waterfall in JS8Call from 500 to 2500Hz and run a filter in your rig that's slightly wider than that. 
|
|
Thanks. I had to reduce the main window width to cover 500-2700 Hz to make it work as expected (even though the input noise is flat from 100-3000 Hz). I can live with that but I find it a bit funny that the spectrum processing depends on whether the control window is open or not. The gain/zero controls and the Flatten checkbox seem to change the spectrum appearance in real time. When you are happy with your adjustments you close the control window and get something else. It's not exactly WYSIWYG :) |
|
When the controls are displayed it effectively narrows the rendered portion of the waterfall. When the controls are removed it renders a wider segment. And it will render differently on different platforms. I'm not exactly sure why, that code hasn't been looked in ages. Perhaps the waterfall controls should be a separate panel instead of being part of the waterfall, but there's no place to put it with the current UI design. |
|
I've noticed this issue on Ubuntu as well, but it wasn't important enuf to me to complain about :) As I recall, we let the OS (via QT) chose whether we use software rendering or not. |
|
The spectrum display and waterfall are, with some cleanup, still mostly based on what WSJT-X did, and some of the decisions made there still seem a bit odd to me. It's better than it was, but still leaves quite a bit to be desired IMO, and most of the 'instructions' on how to use it are based on hearsay and old wives' tales. I experience physical pain watching many of the how-to videos on it, where well-meaning people are unclear on the concept of a passband. Its function and the options to it, e.g., 'flatten', are based on transceivers of yesteryear, IMO, much of it doesn't make sense for the SDR-based transceivers in common use today, or even older tech that at least had decent filters. I strongly regret not doing the right thing with it, which would have been to burn it down to ashes and start over, rather than patching it as I did. It'd be nice to replace this with a standard spectrum and waterfall display that worked in sane manner. |
|
So that this is not just 'old man yells at cloud', an example from another piece of software I'm working on. 
These are as plain-vanilla as I can make them, so we're not distracted by pretty colors. On the left, I'm decoding P25, using a 5 MHz bandwidth, on the right, narrowband FM, using a 500 kHz bandwidth. I'm using an SDRPlay SDR here, so in terms of filtering, etc., this is excellent gear. These waterfall / spectrum plots, I'm generating from the radio's IQ feed. Note the pronounced edges of the bandpass on the left; while the radio is looking at a 5 MHz slice here, you can see that the 250 kHz edges are not nearly the lovely story that the center portion is; quite a lot of falloff there at the edges. On the right, we're only looking at 500 kHz in total, a bit of falloff at the edges, but overall, most of the spectrum is going to be usable. Now this to me, is extremely useful information, since I can make informed decisions based on it, such as to avoid the edges on the 5 MHz side, where the falloff is a big deal. Older receivers, older filters, you'd often see a very rainbow-shaped passband; just the nature of the technology. Newer stuff is going to look pretty flat, with falloff at the edges -- if you for example look at the spectrum that a 7300 puts out, it's exactly that, flat, with well-defined edges. 'Flatten' is basically saying, my receiver is meh, the rainbow shape saddens me, I have abandoned my quest for truth, and am now looking for a good fantasy. Flatten this sucker out for me so that I may feel better about myself and my life choices. If you apply flattening to an already-flat spectrum, and you include the band edges, the flattening math will tend to dish the spectrum; it was already flat, and by 'flattening' it again with the edges included in the math, you're effectively making it look concave. For my part, I'd like to know what my spectrum actually looks like, so I don't do stupid things like try to operate in the falloff area, and my preference would be that we just show people reality here. |
|
I've sometimes wished that I had a dedicated spectrum app instead of having to learn the quirks of every app you use. I know I'm misunderstanding some controls for sure, but I've also noticed that ostensibly similar controls operate different (or not in an intuitive manner). I also agree much of this could be operator error. But getting all the apps to agree and provide somewhat consistent results once I've dialed in the radio settings isn't as fun as I'm making it out to be. A dedicated app that you can dock into a corner, adjust for various gain (etc.) over a bandpass, possibly filter additionally for some cases, and allow config saves for different radios would be slick. I have no idea how that would play in the sandbox with the other apps. I have a feeling I'm describing a whole new data exchange format for inter-process comms. |
|
Interesting concept. I'd probably just supply standard IQ data and have the scope app deal with it, same as for example many SDRs do, with good reason. |
Yeah, just feeding it a stream of IQ would probably be sufficient. I guess you wouldn't (easily) get the interactivity of how each app likes to coordinate gestures on the waterfall with behaviour. Maybe I just want the best of JS8Call waterfall in other places. fldigi seems to have a cursed waterfall; I can rarely get it contrasted enough without it going all mushy. Again, this could be PEBKAC. |
|
I'll move this to the Discussions since it's not anything that's on our immediate fix list. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The displayed spectrum is not flat unless the waterfall control window is shown (shift-F4).
Steps to reproduce the behavior:
Note: The above problem does not occur if I disable 'Flatten' and adjust the waterfall/spectrum gains manually.
Screenshots:
The second screenshot shows the transition from flat to non-flat spectrum that occurred when the Waterfall Controls window was closed with shift-F4.
73 SM6LKM
All reactions