S-meter

[eroyee]

While fairly arbitrary across different radios it's most common to report signal strength in S-units.

Although I'm personally happy enough with the present simple bar display with dBm I have to admit that I find myself looking for a scale of some sort, 'calibrated' in S / +dB.

I'm no HTML expert and in the past would have created a suitable graphic to simply place behind the moving bar. However I expect this could be nicely done in js (?), unfortunately I'm even less of a java expert!

Anyway I'm just interested to know if there's any desire for this, or if it's something that could be slated for the future?

[jketterl]

This topic has been on here before, even though dismissed early: https://github.com/jketterl/openwebrx/issues/118

It is still a matter of calibration, since I do not intend to display incorrect S-values, just because it is more commonly used. S-Units have a clear relation to receiver input voltages, however for most hardware the conversion is not known. I think the only type of receiver that comes with reproducible calibration is the SDRplay, even though I don't have the corresponding math at hand.

[eroyee]

Yes, I'd read 118 earlier, but thanks for reminding me of it.

However that was a different subject really. Of course, like that author, I have suitable equipment to correctly align an S-meter chart with signal input levels.

I had figured that the RX's we typically use are sufficiently homogeneous that a calibration setting (in the conf file for example) should be usable across the same make/model of RX. Thus, collaboratively, it should have been be possible to produce usable information for others to use. Also, as you say some hardware manufacturers provide data that could be used to calibrate the S-meter.

Anyway you've answered the question I guess, and as no-one else has commented it may be a moot point.

For my own interest/use I may pursue this a little further, I just wish I could get my head around js as I think it'd be better to use it to produce a scale, rather than a graphic! :-)

[jketterl]

Well, the thing is, even if a certain brand and model combination would have a stable correlation value, I'm not in a situation to collect and calibrate them all. There's simply too many makes and models available in the market.

To make things even worse, I'm in doubt that two samples of the same make and model would even produce the same results, especially if they have been manufactured at different times. As I said, to my knowlege no manufacturer besides SDRplay has put an effort into reproducibility, probably because they'd have to monitor that.

Those are my assumptions though, feel free to bring in new konwledge.

[eroyee]

I agree it would be a big task and of some limited value in collecting such data on all the SDR hardware. Certainly I wouldn't advocate for it.

To me the point of 's' units, and having a scale, is more about relativity (not the Einstein version!). What it does is provides a handy reference point for someone comparing a change of TX power/ antenna, or simply relative signal levels from a few hours or days ago. Very few people would use or consider 's' units a particularly accurate measure, but they are commonly and usefully utilised.

As a case in point; if I compare my transceivers none of them will give the same 's' reading for a given on-air signal. Even between two radios of the same manufacture (eg.TS930 vs TS440 or 430) there is not so much correlation. However what they do give is an idea of how certain signals compare [on the same radio].

For m the problem with the present signal bar in OpenwebRX is that there's no scale of any sort, it doesn't sync with the audio, and the dBm units change very rapidly meaning that it's very hard to get any real idea or comparison of signal even between two or more stations (CW/SSB). As 's' units are widely used (and I suggest widely understood not to be especially accurate) I suggest implementing a basic scale would resolve some of this, and enhance rather than detract functionality.

Furthermore I've been interested to look at other SDR implementations of 's' units, and how they work. They almost universally use an 's' scale, and those that use a bar quite often superimpose a second bar that has a much longer decay, which allows someone to get a better idea of peak (relative) signal strength. This is particularly useful where, necessarily, audio and [instant] signal indications are out of sync, which makes it difficult for the human to merge and make sense of.

To my mind such a 'delayed' bar would also be an enhancement for OpenwebRX, and may not involve too much coding to achieve? Of course (and I'm not trying to push the point here!) a slower AGC might also deal with some of this issue - for SSB and CW at least - although I would still vote for having a delayed bar all the same.

[jketterl]

At this point, I'm not even sure any more why you're asking for an S-Meter scale. All it would do would be to give a different scale to the current display, since one S-unit is 6dBs of power. So if you can't get a reading from the current scale, you wouldn't be getting one from the calibrated S-meter either.

I'm not going to implement an incorrect S-meter because it doesn't display correctly on most radios, either. That is simply not a valid point. I have said it before, I won't be displaying S-units unless calibrated.

As for the delay: No, that's not going to happen. There has been code in place before do delay the waterfall, but in the end it didn't achieve anything, simply because there's no correlation between the audio being played and the signal being received. Due to the way OpenWebRX works, there is shell buffers between pretty much all the demodulator steps, and to add to that, there's the audio buffers in the browsers. Pretty much the only one i could measure is the audio buffer in the client JavaScript, but there"s two different playback methods in place, one is double-, the other triple-bufferd. There's no way I'll even attempt to control all that.

[eroyee]

I think part of the point is that currently there's no marking to judge where the bar sits - this is what I mean by 'scale', apologies for not being clearer about that.

Anyway it's not a big deal, we can leave this alone for now :-)