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,

I think it's not a demod problem but a PCIe bridge problem. As I said in a post before this ECP3 chip (common to all TBS PCIe cards issued after the TBS6983 Arne uses) has 8 "channels" with seperate DMA buffers for up to 8 demodulators. If I got you right you did put T2 or T1  on demod0 and the problem was always there. This is always "channel0" of the ECP3 chip. I also notet that most of your lost packets bursts on HVS-2 are in sync with spikes of your HD/SSD read usage.

Under GNU/Linux there is interrupt affinity. You can pin certain interrupts to always use the same processor core. Your most frequent interrupts are probably related to ECP3 DMA transfer of the TBS-card, to your NIC and to the HDD/ SSD.
Under GNU/Linux you can do as root a "# cat /proc/interrupts" to see who uses what interrupts how often. The busiest interrupts should be on separate cores. There should be a similar system information under Windows 10 somewhere.
While I can optimize interrupts with a simple bash script under GNU/Linux Interrupt affinity under Windows 10 is probably registry stuff. So that's not the first thing you want to touch. But try to find out what causes thes HDD/SSD read spikes.


Good luck,
Ernst

On 15/11/2021 18:22, Ernst Lobsiger via groups.io wrote:

David and Arne,

my problem explained in the last post could be caused by the NIC going in some
sleep state. It's a PCIe device like the TBS6903.
Then the connection to SAMBA would not work and even with the scheduler
triggering my Satpy scripts would not find any data.
I wonder whether Windows 10 does now try to put whatever it finds on the PCIe
bus to a low power state when let unattended?

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby
<https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby>

At the CLI try "powercfg /a" to find out what low power states your PC can be
put in. The more UEFI the less we set in the BIOS.

Regards,
Ernst

Ernst,

On my system I see:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Users\David>powercfg /a
The following sleep states are available on this system:
Standby (S3)
Hibernate
Hybrid Sleep
Fast Startup

The following sleep states are not available on this system:
Standby (S1)
The system firmware does not support this standby state.

Standby (S2)
The system firmware does not support this standby state.

Standby (S0 Low Power Idle)
The system firmware does not support this standby state.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm now seeing a steady lost and recovered rate, together with odd bursts of
lost throughout the day, but only on the HVS-2/RAMdisk configuration/tuner.
This with the monitor permanently on logically, but physically switched off on
the front panel.

https://www.satsignal.eu/mrtg/performance_lund.php
(possibly with a Ctrl-F5)

I still don't understand why just one tuner is affected by the "Turn off screen
after..." setting.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @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@....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@...
Twitter: @gm8arv

Hi

Since the demise of METOP-A data I am a bit confused
I thought METOP-A data was transmitted on HVS1 EH1-EPS-10 but I am finding files such as AVHR_xxx_1B_M02_20211115091903Z_20211115092203Z_N_O_20211115105903Z in the folder
I thought M02 files were METOP-B and M03 files were METOP-C >
Have I missed something

Short before launch Eumetsat recognized a problem with the satellite and therefore launched the already assembled second satellite in the row M02 formerly planned as Metop-B now became Metop-A.

After repair Metop-A (M01) was launched as Metop-B

Best wishes

Heiko

--
---------------------------------------------------------------------------
Dipl. Inf. Heiko Schellhorn

University of Bremen Room: NW1-U 2065
Inst. of Environmental Physics Phone: +49(0)421 218 62091
P.O. Box 33 04 40 Fax: +49(0)421 218 62070
D-28334 Bremen Mail: mailto:schell@...
Germany www:
http://www.iup.uni-bremen.de/~schell
http://www.sciamachy.de
http://www.esa-ghg-cci.org
http://www.tropomi.eu/

The problem with the world is that the intelligent people are full of doubts,
while the stupid ones are full of confidence.
- Charles Bukowski -

David and Arne,

my problem explained in the last post could be caused by the NIC going in some sleep state. It's a PCIe device like the TBS6903.
Then the connection to SAMBA would not work and even with the scheduler triggering my Satpy scripts would not find any data.
I wonder whether Windows 10 does now try to put whatever it finds on the PCIe bus to a low power state when let unattended?

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby

At the CLI try "powercfg /a" to find out what low power states your PC can be put in. The more UEFI the less we set in the BIOS.

Regards,
Ernst

David,

I understand you solved your problem by not letting the system turn off the screen. I had a very similar issue here:
I scheduled the Windows PC to make an RSS frame of the UK every 5 minutes and to make a video every 30 minutes.
The satellite data was read from one of my GNU/Linux receivers via a SAMBA share. But when I left the PC after some
time the screen turned black and the PC *stopped making frames* !! It only restarted when the screen was lit again.
It seemed like the whole system went to sleep if I was not sitting in front and then and when moving the mouse.

I opened control panel / system /  power & sleep (the last screenshot I posted) and set it to Sleep "never".
Even with the Screen setting of "15 minutes" my monitor did never turn black again. I simply switched it off
with the front knob and during the next night all RSS frames were produced unattended as expected.

Windows 10 Pro
Version 21H1
Windows Feature Experience Pack 120.2212.3920.0

Cheers,
Ernst

On 15/11/2021 13:40, Ernst Lobsiger via groups.io wrote:

David,

I attach an english screen copy of the settings I had to use when testing
TelliCastStatsCollector.cmd over the LAN.
I also attach a layout of the tuner chip of the TBS-6903. As I explained I have
an stv6120 module parameter "rfsource".

rfsource = 0  (default, 2 cables)  --> demod0 at socket LNB0 / demod1 at socket
LNB1   (T1 and T2 any band and polarisation)
rfsource = 1  single cable mode, plug cable at socket LNB0   (only works with
T1 and T2 same band and polarisation)
rfsource = 2  single cable mode, plug cable at socket LNB1   (only works with
T1 and T2 same band and polarisation)

I still don't know how you switch to single cable mode. Do you still use the
SR-Test.exe you mentionned?
Does this just what rfsource = 1 does under GNU/Linux? So you cannot try the
setting of rfsource = 2?

It seems your losses occur on demod0. Is this also the case if you do not
switch to single cable mode? You
will probably have to reboot or power down? You then just test demod0 on input
socket LNB0 (T1 or T2 only).

Another trick that sometimes works (and TBS support proposes) is to use another
PCIe slot for the TBS card.

One more thought I had: There might be power saving configurations for the PCIe
bus. This used to
be called ASPM and was/is used mainly for Laptops and mobile PCs? Maybe
accessible in BIOS only.

I hope you can finally fix this. I have one receiver with a TBS-6903 that runs
perfectly here under GNU/Linux.

Cheers,
Ernst

Ernst,

Our e-mails crossed.

Yes, I use SR-Test.exe to set the "single cable" operation. It runs in Admin
mode at PC startup:

~~~~~~~~~~~~~~~~~~~~~~~~~
C:
PUSHD \Tools\BDADataEx
SR-Test.exe
timeout 5
start BDADataEx.exe
timeout 5
start BDADataEx.exe 1
POPD
timeout 5
~~~~~~~~~~~~~~~~~~~~~~~~~

I don't want to try any further experiments now as I'd like to be sure it's now
OK! But this PC did work with the TBS 6903 (not 08) in the same PCIe slot, so
I don't think that's the issue.

Thanks for the chip diagram. Seeing the I2C interface makes me wonder whether
a "power off DVI monitor" command is somehow finding its way into the TBS 6903
card, Tuner 1, through some programming error (AKA "feature") which has been
introduced by a fresh Windows install. Yes, that seems unlikely, but....

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

On 14/11/2021 11:59, Ernst Lobsiger via groups.io wrote:

Good luck,
Ernst

Thanks, Ernst. I've carried out further tests which have narrowed things down,
but I' still without a full explanation.

1. Swapping the tuners between HVS-1 and HVS-2: the packet loss moves with the
tuner. As HVS-1 is sent to a 4 TB HD, and HVS-2 to a RAMdisk, I think this
eliminates RAMdisk or HD from the problem.

2. Running at the maximum power setting (rather than "balanced" or "energy
saving" did not stop the packet loss. I wouldn't find the identical screen to
yours, but having the ability to control power and screen-saver was present.

3. I don't believe that having a screen-saver (blank screen) or not affected
the problem.

4. Setting the "Power off monitor" time to "never" did resolve the problem.

5. Switching the monitor on and off with its front panel switch did not cause
the problem to start again.

Arne had suggested some new process running when the issues started, but I
could not see a obvious change in CPU, network I/O, or disk I/O.

So my current conclusion is that something unknown happens when the monitor
power-off DVI signal is sent, which affects Device 1, Tuner 1. This is with a
completely fresh installation of Windows, to a PC which used not to have this
problem. One possible other clue is that when a Windows Restart command is
issued, the PC takes a very long time to complete the restart - the spinning
icon last for several minutes, which obviously isn't right....

I'll add this tale to my Web page.

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

David,

I attach an english screen copy of the settings I had to use when testing TelliCastStatsCollector.cmd over the LAN.
I also attach a layout of the tuner chip of the TBS-6903. As I explained I have an stv6120 module parameter "rfsource".

rfsource = 0  (default, 2 cables)  --> demod0 at socket LNB0 / demod1 at socket LNB1   (T1 and T2 any band and polarisation)
rfsource = 1  single cable mode, plug cable at socket LNB0   (only works with T1 and T2 same band and polarisation)
rfsource = 2  single cable mode, plug cable at socket LNB1   (only works with T1 and T2 same band and polarisation)

I still don't know how you switch to single cable mode. Do you still use the SR-Test.exe you mentionned?
Does this just what rfsource = 1 does under GNU/Linux? So you cannot try the setting of rfsource = 2?

It seems your losses occur on demod0. Is this also the case if you do not switch to single cable mode? You
will probably have to reboot or power down? You then just test demod0 on input socket LNB0 (T1 or T2 only).

Another trick that sometimes works (and TBS support proposes) is to use another PCIe slot for the TBS card.

One more thought I had: There might be power saving configurations for the PCIe bus. This used to
be called ASPM and was/is used mainly for Laptops and mobile PCs? Maybe accessible in BIOS only.

I hope you can finally fix this. I have one receiver with a TBS-6903 that runs perfectly here under GNU/Linux.

Cheers,
Ernst

On 15/11/2021 11:42, Graham Woolf wrote:

Hi

Since the demise of METOP-A data I am a bit confused

I thought METOP-A data was transmitted on HVS1 EH1-EPS-10 but I am finding
files such as
AVHR_xxx_1B_M02_20211115091903Z_20211115092203Z_N_O_20211115105903Z in the folder

I thought M02 files were METOP-B and M03 files were METOP-C

Have I missed something

Regards

Graham

The first launched was model 02, so:

Metop-A => M02
Metop-B => M01
Metop-C => M03

My latest is: 2021-11-15_0940_M02_78219.hpt

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

Hi

Since the demise of METOP-A data I am a bit confused

I thought METOP-A data was transmitted on HVS1 EH1-EPS-10 but I am finding files such as AVHR_xxx_1B_M02_20211115091903Z_20211115092203Z_N_O_20211115105903Z in the folder

I thought M02 files were METOP-B and M03 files were METOP-C

Have I missed something

Regards

Graham

On 14/11/2021 11:59, Ernst Lobsiger via groups.io wrote:

Good luck,
Ernst

Ernst,

Thanks for your notes. I sill need to read and understand them (again).

Just a progress report for the moment:

Work here continues to make PC Lund usable. It seems to have a large packet
loss on one of the two TBS 6903 tuners. I tried swapping the two tuners and
the loss went with the tuner (from HVS-1 to HVS-2). HVS-1 is now almost
loss-less (as HVS-2 was before the change), but it appears that losses are
minimal while the PC is being used (mouse, keyboard etc.) and start after the
user goes away. However, there is no screen-saver, or screen timeout currently
set, and the PC power is set for maximum performance and I can't see anything
set for a few minutes timeout in the advanced power settings.

Power settings are all at maximum, with no power-saving timeout, screen-saver,
or screen shutdown. I need to be sure I'm using the settings you indicated.

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

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

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

Hugo,

sorry our posts have crossed. I found your post after sending mine. But apparently looking at the screenshot we came to the same conclusion :-).

Cheers,
Ernst

Bernard,

the bottom line of your TLE says 41335 Sentinel-3 instead of 41335 Sentinel-3A. Also the numbering is out of order. It seems this is "weather.txt" and you have managed to damage that with an editor.
Both satellites 41335 Sentinel-3A and 43437 Sentinel-3B are in TLE-file "resource.txt". Please update these two TLE-files and check Sentinel-3A and Sentinel-3B in "resource.txt". Then try again ..

Regards,
Ernst

P.S. And please disclose your first name for minimum politeness.

Hi,

You should have two entries in the list named 'SENTINEL-3A' and 'SENTINEL-3B'. From your print screen I can only see the entry 'SENTINEL-3'. This list is probably not the 'resource.txt' file from Celestrak.com.
In Set preferences, choose TLE sources and add "https://celstrak.com/NORAD/elements/resource.txt" and do a new update TLE's.

grts,

Hugo

Hello
here is the error message i get when i add the two line sentinel-3 at the end of the weather.txt file....
an idea?

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