Topics

SW2 S-Meter #fdm-sw2 #fdm-s2 #smeter


Paul White
 

Ivo's post prompts me to air my own comment on the SW2 S-meter.
 
I'm not an expert user. There are two radio/software combinations available to me whose S-meter by reputation provides a well-defined, accurate and reliable total (not peak) power measurement: RSP1A+SDRuno and S2+SW2.
 
My use of S-meter readings includes:
(a) meaningful logging of received signal strength, for signals of any type
(b) comparative assessment of changes to system components (e.g. antenna mods)
 
I have no specialised signal measurement equipment, hence the reliance in (b).
 
In those activities (for my comfort) there are two enhancements to SW2 that could help considerably:
(1) showing Marker 1-type data in the "desert" next to the S-meter
(2) calculating/displaying an average S-meter reading as well as SNR
 
The argument for (1) is that bringing up marker data is time-consuming. For (2) it is that even relatively stable signals show fluctuations that cannot accurately be averaged by eye.
 
Refinements could be:
(3) user control over averaging period
(4) calculating/displaying the S-meter variance (standard deviation)
 
I would find (3) especially useful for slow fading, and (4) as a measure of fading severity.


Neil Smith G4DBN
 

I find the markers in the IF window more useful than those in the main window. If you set the averaging in the IF window to 60 or 100, then the numbers are smooth enough to use for sun noise measurements on microwave bands.  You can reduce the jumpiness of the on-screen measurements by changing the averaging on the main waterfall to 20 or so, and smooth out the S meter readings by changing the update interval from the default 60 ms, but I don't know if that does an averaging process, or just discards the intervening measurements!

For anything really clever, it is probably easier to work on the waterfall data which is streamed out of the extio port, and do the analysis using some custom code.

Neil G4DBN

On 19/03/2020 10:01, Paul White wrote:
Ivo's post prompts me to air my own comment on the SW2 S-meter.
 
I'm not an expert user. There are two radio/software combinations available to me whose S-meter by reputation provides a well-defined, accurate and reliable total (not peak) power measurement: RSP1A+SDRuno and S2+SW2.
 
My use of S-meter readings includes:
(a) meaningful logging of received signal strength, for signals of any type
(b) comparative assessment of changes to system components (e.g. antenna mods)
 
I have no specialised signal measurement equipment, hence the reliance in (b).
 
In those activities (for my comfort) there are two enhancements to SW2 that could help considerably:
(1) showing Marker 1-type data in the "desert" next to the S-meter
(2) calculating/displaying an average S-meter reading as well as SNR
 
The argument for (1) is that bringing up marker data is time-consuming. For (2) it is that even relatively stable signals show fluctuations that cannot accurately be averaged by eye.
 
Refinements could be:
(3) user control over averaging period
(4) calculating/displaying the S-meter variance (standard deviation)
 
I would find (3) especially useful for slow fading, and (4) as a measure of fading severity.
-- 
Neil
http://g4dbn.uk


Paul White
 

Thank you for your suggestions, Neil. I'll take these in reverse order.
 
I'm not technical enough to write custom code or interpret FFT data, and anyway shouldn't need to for something as basic as reading off a standard metric from the main display.
 
There are dozens of graphics configuration settings for spectrum and waterfall, including refresh rate and averaging (though not anything cleverer than on/off). The S-Meter is the poor relation, with only a limited rise and fall time range of control (that I interpret as) to/from the peak reading: fine for peak estimation and useless for the average.

Spectrum (not waterfall) averaging seems to me to be a purely graphical process that hardly (or maybe not at all) affects the S-Meter reading. Thankfully. Refresh rate *does* reduce the S-Meter sampling frequency, but that's it - no averaging, it simply hides more data.
 
The IF spectrum window marker values are scaled differently from those in the main window, and I've no idea how to compensate for that.
 
A few additional points:
 
* Using markers is all very well for an in-depth investigation of one or a few signals, but has too much operational overhead for routine listening, measurement and reporting. Part of that arises from having to switch cursor/click behaviour between two functional modes.
 
* There *may* be work-arounds that could come close to what I am asking for, but (by the looks of things) would involve extra work and probably some mental arithmetic or worse. In principle an averaging S-Meter should be easy to implement and give the desired result in the right place, in the right format, and with no operational overhead.
 
* I quite understand that my request may not resonate with radio amateurs (who are possibly the majority user base) as their needs seem to be quite different from the SWL community, and the even smaller number who want to get "down and dirty" with fancy measurements.
 
* All I can do is state my point of view on a modification that would be a great help in my tiny world, without any expectation of sympathy or satisfaction.
 


Neil Smith G4DBN
 

I think it would be a great idea to put a firm proposal to Elad for some enhancements via the support ticket system.  Give it a go.

The scaling in the IF spectrum window should just reflect the FFT bin size change from 11.7Hz to 2.9Hz, a ratio of about 4:1, so the power per FFT bin should be around 6dB less.

Neil G4DBN

On 19/03/2020 18:59, Paul White wrote:
Thank you for your suggestions, Neil. I'll take these in reverse order.
 
I'm not technical enough to write custom code or interpret FFT data, and anyway shouldn't need to for something as basic as reading off a standard metric from the main display.
 
There are dozens of graphics configuration settings for spectrum and waterfall, including refresh rate and averaging (though not anything cleverer than on/off). The S-Meter is the poor relation, with only a limited rise and fall time range of control (that I interpret as) to/from the peak reading: fine for peak estimation and useless for the average.

Spectrum (not waterfall) averaging seems to me to be a purely graphical process that hardly (or maybe not at all) affects the S-Meter reading. Thankfully. Refresh rate *does* reduce the S-Meter sampling frequency, but that's it - no averaging, it simply hides more data.
 
The IF spectrum window marker values are scaled differently from those in the main window, and I've no idea how to compensate for that.
 
A few additional points:
 
* Using markers is all very well for an in-depth investigation of one or a few signals, but has too much operational overhead for routine listening, measurement and reporting. Part of that arises from having to switch cursor/click behaviour between two functional modes.
 
* There *may* be work-arounds that could come close to what I am asking for, but (by the looks of things) would involve extra work and probably some mental arithmetic or worse. In principle an averaging S-Meter should be easy to implement and give the desired result in the right place, in the right format, and with no operational overhead.
 
* I quite understand that my request may not resonate with radio amateurs (who are possibly the majority user base) as their needs seem to be quite different from the SWL community, and the even smaller number who want to get "down and dirty" with fancy measurements.
 
* All I can do is state my point of view on a modification that would be a great help in my tiny world, without any expectation of sympathy or satisfaction.
 
-- 
Neil
http://g4dbn.uk


Paul White
 

On Thu, Mar 19, 2020 at 07:48 PM, Neil Smith G4DBN wrote:
The scaling in the IF spectrum window should just reflect the FFT bin size change from 11.7Hz to 2.9Hz
Thanks, Neil, it is as you say (dependent on main FFT span), so it is indeed possible to make the necessary corrections under duress :-).
But there are plenty of gotchas, apart from the "cumbersomeness" and nuisance factors I already mentioned. For example: even with very accurate positioning of a marker, zooming out enough makes it "fall off the edge" of the peak so wrecking the marker statistics. Whereas the S-Meter itself doesn't exhibit that kind of artificial sensitivity.
I'll definitely take your advice and raise a support ticket if that's the right way to go (I hadn't realised group topics were ineffective for this).
Grateful for all your help!
Paul


Neil Smith G4DBN
 

I guess the team in Italy have an awful lot on their minds at the moment, raising a ticket is best so the request is recorded.

Agreed, getting a marker in the right spot is very hard. I'd like to be able to slide a marker or have a "find peak" and "find next peak" facility, and a "set CF to marker" within the IF window, and to have click-to-tune in the IF window as well.  Also a proper frequency scale in the IF window would be nice.

However, those can wait for some time in the future when things get back to normal.

Neil

On 19/03/2020 23:34, Paul White wrote:
On Thu, Mar 19, 2020 at 07:48 PM, Neil Smith G4DBN wrote:
The scaling in the IF spectrum window should just reflect the FFT bin size change from 11.7Hz to 2.9Hz
Thanks, Neil, it is as you say (dependent on main FFT span), so it is indeed possible to make the necessary corrections under duress :-).
But there are plenty of gotchas, apart from the "cumbersomeness" and nuisance factors I already mentioned. For example: even with very accurate positioning of a marker, zooming out enough makes it "fall off the edge" of the peak so wrecking the marker statistics. Whereas the S-Meter itself doesn't exhibit that kind of artificial sensitivity.
I'll definitely take your advice and raise a support ticket if that's the right way to go (I hadn't realised group topics were ineffective for this).
Grateful for all your help!
Paul
-- 
Neil
http://g4dbn.uk