Dual Link Margin script SR1lm.pl


Thorsten Miglus
 

Ernst,

the NOVRA receiver provide no link margin values.
So I have defined my own values:
For BAS I subtract 6.7 from SNR.
For HVS I subtract 10.5 from SNR.
I observed, that error free reception above this values is possible.

Cheers,
Thorsten


On Tue, Nov 16, 2021 at 09:02 PM, Ernst Lobsiger wrote:
David,

yes the LM of HVS is normally the problem. With a reasonably sized antenna BAS almost always has a considerable LM.
Of course the constants I use are only "empirical" as far as I have found those from looking at an SR1 status display.
The SR1 people have certainly calculated those from MODCOD and maybe max symbol rate and other HW settings.

FYI: Yesterday I also did the test with two other SR1 EUMETCast receiver stations on your page:

Loughborough SR1 #1:   SNR (EsNo) = 13.9 dB   /  LMbas = 8.0 dB  /  LM hvs-1 = 4.6 dB
Rungsted Ayecka SR1:   SNR (EsNo) = 13.6 dB   /  LMbas = 7.7 dB  /  LM hvs-1 = 4.3 dB

Both SR1 receivers fulfill my simple equations.

But those do not work exactly with Thorsten's Novra S300N. The Novra staff has a slightly
different idea what LM = 0dB means. This might also be to some extent HW dependant.

Cheers,
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 16/11/2021 20:02, Ernst Lobsiger via groups.io wrote:
David,

yes the LM of HVS is normally the problem. With a reasonably sized antenna BAS
almost always has a considerable LM.
Of course the constants I use are only "empirical" as far as I have found those
from looking at an SR1 status display.
The SR1 people have certainly calculated those from MODCOD and maybe max symbol
rate and other HW settings.

FYI: Yesterday I also did the test with two other SR1 EUMETCast receiver
stations on your page:

Loughborough SR1 #1:   SNR (EsNo) = 13.9 dB   /  LMbas = 8.0 dB  /  LM hvs-1 =
4.6 dB
Rungsted Ayecka SR1:   SNR (EsNo) = 13.6 dB   /  LMbas = 7.7 dB  /  LM hvs-1 =
4.3 dB

Both SR1 receivers fulfill my simple equations.

But those do not work exactly with Thorsten's Novra S300N. The Novra staff has
a slightly
different idea what LM = 0dB means. This might also be to some extent HW dependant.

Cheers,
Ernst
Yes, empirical, but good enough to compare across the same devices. My guess
is that the passband shape will come into it, and how that affects both the
noise distribution across the passband, and the shape of the recovered digital
signal. It wouldn't surprise me if different companies had different definitions.

Some definitions talk about "when the receiver stops working", but what does
that mean? With digital systems there isn't a sudden stop between LM := +0.1
dB and LM := -0.1 dB, so should the "acceptable" bit error rate come into the
definition?

I see the value of these measurements as being for individuals to watch for any
gradual degradation in their system or to monitor improvements they may make,
or for comparisons across Europe to answer questions such as "I live in
Helsinki - what dish might I need?".

The more monitoring stations sharing their data the better!

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Ernst Lobsiger
 

David,

yes the LM of HVS is normally the problem. With a reasonably sized antenna BAS almost always has a considerable LM.
Of course the constants I use are only "empirical" as far as I have found those from looking at an SR1 status display.
The SR1 people have certainly calculated those from MODCOD and maybe max symbol rate and other HW settings.

FYI: Yesterday I also did the test with two other SR1 EUMETCast receiver stations on your page:

Loughborough SR1 #1:   SNR (EsNo) = 13.9 dB   /  LMbas = 8.0 dB  /  LM hvs-1 = 4.6 dB
Rungsted Ayecka SR1:   SNR (EsNo) = 13.6 dB   /  LMbas = 7.7 dB  /  LM hvs-1 = 4.3 dB

Both SR1 receivers fulfill my simple equations.

But those do not work exactly with Thorsten's Novra S300N. The Novra staff has a slightly
different idea what LM = 0dB means. This might also be to some extent HW dependant.

Cheers,
Ernst



David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 14/11/2021 21:15, Ernst Lobsiger via groups.io wrote:
Francis,

my point is, of course I cannot be 100% sure or prove it, that the SR1 people
used exactly those empirical constants to get their LM.
When I look at David's Ayecka #1 this evening comparing mean values I see SNR =
12.6 dB,  LM BAS = 6.7dB,  LM HVS-1 = 3.3dB.

But 12.6 - 5.9 = 6.7 and 12.6 - 9.3 = 3.3 as I stated above.

Cheers,
Ernst
Ernst,

Using the SNR also has the advantage of simplifying the MRTG, not needing to
run a Perl script. Almost!

For an HVS-1 or HVS-2 measurement the script below works well - sorry about the
wrap on the "Target" and "Options" lines.:

#----------------------------------------------------------------------------
# SR1 DVB-S2 receiver HVS link margin
#----------------------------------------------------------------------------

Target[SR1-hvs-link-margin]:
1.3.6.1.4.1.27928.101.1.1.4.4&1.3.6.1.4.1.27928.101.1.1.4.4:public@192.168.0.194 -
93

MaxBytes1[SR1-hvs-link-margin]: 100
MaxBytes2[SR1-hvs-link-margin]: 100
Unscaled[SR1-hvs-link-margin]: dwmy
YTics[SR1-hvs-link-margin]: 5
YTicsFactor[SR1-hvs-link-margin]: 0.1
Factor[SR1-hvs-link-margin]: 0.1
Options[SR1-hvs-link-margin]: gauge, nopercent, growright, unknaszero,
nolegend, noi
ShortLegend[SR1-hvs-link-margin]: dB
YLegend[SR1-hvs-link-margin]: Link margin: dB
LegendO[SR1-hvs-link-margin]: High Volume Service:
Title[SR1-hvs-link-margin]: SR1 HVS Link Margin
PageTop[SR1-hvs-link-margin]: <h1>Ayecka SR1 - HVS Link Margin</h1>

#----------------------------------------------------------------------------

My MRTG knowledge isn't good enough to get it to display BAS link margin as one
value, and HVS link margin as another. For a single value the "Target" format
above is:

SNR-MIB-ID&SNR-MIB-ID:public@ip-address - 93

so both "input" and "output" in MRTG terms are SNR - 93. SNR is in units of
centibels.

What I don't know, and I can't discover is whether it's even possible is to get
both BAS and HVS link margins using a "Target" something like:

SNR-MIB-ID:public@ip-address - 59 & SNR-MIB-ID:public@ip-address - 93
or:
SNR-MIB-ID - 59 & SNR-MIB-ID - 93:public@ip-address

"Left as an exercise for the reader", perhaps?

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Ernst Lobsiger
 

On Sun, Nov 14, 2021 at 12:08 PM, fbreame wrote:
Also I'm not terribly happy about using empirical constants when we have the values anyway, assuming that the SR1 people knew what they were doing.
Francis,

my point is, of course I cannot be 100% sure or prove it, that the SR1 people used exactly those empirical constants to get their LM.
When I look at David's Ayecka #1 this evening comparing mean values I see SNR = 12.6 dB,  LM BAS = 6.7dB,  LM HVS-1 = 3.3dB.

But 12.6 - 5.9 = 6.7 and 12.6 - 9.3 = 3.3 as I stated above.

Cheers,
Ernst


fbreame
 

Hi John

I'm the original author of the SR1lm script. Sorry for the delay but I haven't looked at it for ages!

Whichever values the script is generating, it's clear that it's not communicating with the SR1 properly, as the 'uptime' field is zero.
If you could try rerunning with a -d option added to the call, you should get some debug output. This is probably the quickest way of working out the problem. If you can then send me a sample from the start of the run (preferably by PM to avoid clogging the group) hopefully I can see what's wrong.

I'm not aware that there has been a difficulty in indentifying which value is related to which MODCOD. For one thing the values are obtained in a single SNMP transaction.which should minimise problems. Do you have any specifics David?

When I get a chance I'll have a look at using Ernst's equations to simplify the script and compare the results to see if there has been a change, although I'm not sure that there is much of an advantage assuming the the SR1's output is correct. Also I'm not terribly happy about using empirical constants when we have the values anyway, assuming that the SR1 people knew what they were doing. Actually once initial values have been found, the script only samples every 5s by default, or as specified, which I don't think is much of an overhead.

Francis Breame


Ernst Lobsiger
 

On Sun, Nov 14, 2021 at 07:01 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
The simple answer is that the SR1 returns these values directly, but it's not always clear which mode it's referring to. We were unaware of the alternative derivation all that time ago. Agreed that direct would be better.
David,

yes, that's exactly the problem with the SR1 and VCM on T1. With snmp once you get the LM for BAS (8psk 3/5) and then you get the LM for HVS-1 (16apsk 2/3) just as with the SSH display. Under Windows you have always tried to get both values by high speed snmp sampling and then try to figure out which is which. But my above equations stem from simply watching SNR and LM values of the SR1 via ssh for a while back in 2014. I'd be surprised if anything has changed since maybe with some firmware update. I only had an SR1 as pilot user from EUMETSAT and (different from what they said at the beginning of the DVB-S to DVB-S2 transition phase) I had to send it back later. But as I said: You have the SNR of T1 with no problem via snmp. So the LM calculation can easily be done on the Windows side either in Perl or even with CMD. I have not used MRTG for a decade now but you David could certainly provide a simple solution ...

Cheers,
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 14/11/2021 14:06, Ernst Lobsiger via groups.io wrote:
John,
<cite>
As mentionned a couple of times on this list, you must have a minimum SNR per MODCOD. If your SNR is above, you have some Link Margin (LM):
Basic Service  MODCOD     8psk 3/5 --> LM = SNR - 5.9  [dB]
HVS-1, HVS-2 MODCOD 16apsk 2/3 --> LM = SNR - 9.3 [dB]
</cite>
The SR1 does nothing else when it calculates the link margin for BAS and HVS-1. I really don't understand why you Windows guys try the hell of snmp stuff to get these LM values from the SR1 if you alredy have the T1 SNR.
Just easily slightly adapt your sr1-snr.pl  to make these calculations for you. Under GNU/Linux I do these calculations in the eLuna/RRDtool drawing routine only. This has all been explained shortly after I had an SR1 in 2014.
Cheers,
Ernst
Ernst,

The simple answer is that the SR1 returns these values directly, but it's not always clear which mode it's referring to. We were unaware of the alternative derivation all that time ago. Agreed that direct would be better.

Cheers,
David

--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Ernst Lobsiger
 

John,

<cite>
As mentionned a couple of times on this list, you must have a minimum SNR per MODCOD. If your SNR is above, you have some Link Margin (LM):

Basic Service  MODCOD     8psk 3/5 --> LM = SNR - 5.9  [dB]
HVS-1, HVS-2 MODCOD 16apsk 2/3 --> LM = SNR - 9.3 [dB]
</cite>

The SR1 does nothing else when it calculates the link margin for BAS and HVS-1. I really don't understand why you Windows guys try the hell of snmp stuff to get these LM values from the SR1 if you alredy have the T1 SNR.
Just easily slightly adapt your sr1-snr.pl  to make these calculations for you. Under GNU/Linux I do these calculations in the eLuna/RRDtool drawing routine only. This has all been explained shortly after I had an SR1 in 2014.

Cheers,
Ernst



john.haslam4@...
 

I currently have ActivePerl ver 5.28.1 installed in C:\Perl\64 and MRTG in C:\Tools\MRTG. 
I am successfully monitoring SNR including "sr1-snr.inc" in the mrtg.cfg file and Tellicast Losses with the "tellicast-RECEIVER.inc" included in the mrtg.cfg file.
I have attempted to implement dual link margin monitoring by following the instructions on the Satsignal web page and have reached a sticking point
I have copied SR1lm.pl to C:\Tools\MRTG\bin
When I do the test run of SR1lm.pl  I get zero values for all output parameters except the receiver ID. It runs outputting zero values every few minutes until I stop it.
No errors are reported.
Here is a copy of the test output:_

C:\Tools\MRTG\bin>perl SR1lm.pl 192.168.10.99
0
0
0
Ayecka SR1
0
0
0
Ayecka SR1

I am currently reading all the relevant documentation but if anyone has seen this problem before and found a solution please let me know.
There is probably a pre-requisite I am overlooking!

Many Thanks

John