Re: Dual Link Margin script SR1lm.pl
On 14/11/2021 14:06, Ernst Lobsiger via groups.io wrote:
John,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@... Twitter: @gm8arv
|
|
Re: Dual Link Margin script SR1lm.pl
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
|
|
Dual Link Margin script SR1lm.pl
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
|
|
Re: TBS 6903 tuner allocations
Ernst Lobsiger
On Sat, Nov 13, 2021 at 10:35 PM, David J Taylor GM8ARV 🏴 🇪🇺 wrote:
David, the TBS6908 is twice the TBS6903. You certainly refer to the latter one as in the subject. As I have never setup a TC receiver under Windows I might not be the right person to answer here. I try to explain once more the problem we had with PCIe cards (only) when HVS-2 started. HVS-2 was very dynamic going from full throttle to almost zero bits/second for longer periods. Georgios Potiriadis at EUMETSAT finally found the reason for TC client timeouts and CrazyCat said what HW, the PCIe bridge chip, was causing this. In the case of the TBS-6903 (and TBS-6908) the driver under GNU/Linux basically consists of three kernel modules loaded at boot up: stv6120 This module is for the tuner chip including the matrix switch at the input. It has a parameter "rfsource" that you can set for single cable mode. stv091x This module is for the demodulator chip. MODCODs are set here. It has a parameter to set it in single mode to double the bandwidth (never used for EUMETCast). tbsecp3 This module is for the ECP3 PCIe bridge chip common to all TBS PCIe cards that have been produced after the (deprecated) TBS-6983. ECP3 allows for up to 8 demodulators each having its own DMA buffer. This buffer accumulates a certain number of 188 Bytes MPE packets and then flushes the whole batch over the bus. In early drivers IIRC this was hard coded to be 512 MPE packets. HVS-2 on T2 with long gaps of almost zero bits/second made the TC client loose time sync because some minimal heartbeat was stuck in the DMA buffer that only slowly filled to 512 MPE packets. HVS-1 on T1 never had that problem because BAS always provided some minimal trafffic that kept the DMA buffer busy. The problem was solved by two different approaches. I added a module parameter to tbsecp3 to choose the size of each of the 8 DMA buffers in units of MPE packets. So we could set that e.g. to 256 packets for T1 but 32 packets for T2. Of course this increased the interrupt load of the receiver PC but that was no problem. CrazyCat streamlined my solution which is still part of tbsecp3 and can easily be configured for all TBS cards. EUMETSAT resolved the problem later by always providing some minimal (invisible?) traffic on T2 so that even drivers with a fixed DMA buffer size of 512 MPE packets should make TC happy. On T1 nothing was added which means that if you set MODCOD for HVS-1 only you have the "dejavue" problem of HVS-2. On your site you describe the situation under Windows for "Single Cable operation" https://www.satsignal.eu/wxsat/dvb-s2/T1-T2.html#full-t2 You mention som SR-Test.exe that was used to set the input matrix switch right (module parameter "rfsource" under GNU/Linux). You then have a note that makes me think that the PCIe bridge DMA buffer sizes are still fixed somehow in the Windows drivers. Note: If you are using the beta TBS6903 driver (drivers dated 2017-07-07) you need to lock and receive HVS-1 with tuner-0 and HVS-2 with tuner 1, because they have different-sized packet buffers (64 packets for tuner 0, and 16 packets for tuner 1). So, unless you have now some other means to set these DMA buffer sizes, those might depend on your Windows driver version :-( ??. But don't worry there is still the EUMETSAT solution of the initial problem. All drivers should work now except for MODCODs HVS-1 only. In othe words I do not think that having T1 on demod 0 and T2 on demod 1 should be a problem nowadays (with recent Windows drivers). That all said the first thing I would try is to go to your Windows control panel and under "Netzbetrieb und Energiesparen" tell it to never go to the energy saving mode if it is working unattended. I attach a German screenshot, this must look similar in English. I also noted that CrazyCat has a new version of BDADataEx from 2021/10/27 (no idea what he has improved though) http://crazycat69.narod.ru/sattelite/DVBDataEx/bdadataex.htm Good luck, Ernst
|
|
TBS 6903 tuner allocations
Ernst,
I recall that the two tunes on the 6908 - or their driver software under Windows - should be used in a particular way because of buffering differences. I see from an earlier screen-shot (attached) that I used to have: Device 2, tuner 0, transponder 1. Device 1, tuner 1, transponder 2. On page: https://www.satsignal.eu/wxsat/dvb-s2/T1-T2.html Image: https://www.satsignal.eu/wxsat/dvb-s2/TBS-single-cable-1-Status-Tuner-production.png On a rebuilt PC I see that Device 1, tuner 1, transponder 1. Device 2, tuner 0, transponder 2. Would this cause a problem like high packet loss on TP1? I'm seeing a steady packet loss (and missed 1000/hour, recovered 2000/hour) but only on transponder 1. TP2 is essentially lossless. The current graphs are here: https://www.satsignal.eu/mrtg/performance_lund.php The loss seems to stop when I'm actually at the PC, which makes me think it may not be the TBS at all, but some other background process which runs when I leave the PC, but I have tried to disable some such as anti-virus on the EUMETCast processes and tc-recv.exe. Your thoughts would be appreciated. Thanks, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv
|
|
Re: sentinel3 datas computing
On 13/11/2021 13:40, rossinib@... wrote:
I receive HVS-2 data and have a lot of ".TAR" files on subdirectory E2H-S31-01/02 or E2H-S3B-01I have some notes here: https://www.satsignal.eu/wxsat/Sentinel/index.html but they are rather old, and the data stops within a month. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv
|
|
Re: sentinel3 datas computing
Ernst Lobsiger
If you cannot do it with EUMETCastView then there might be no easier way.
Here is what my PyTROLL/Satpy Starter Kit 3.0 does. But be aware that Sentinel-3 OLCI data will not be disseminated after December 15th 2021. Regards, Ernst
|
|
sentinel3 datas computing
rossinib@...
I receive HVS-2 data and have a lot of ".TAR" files on subdirectory E2H-S31-01/02 or E2H-S3B-01
What is the easyest way to compute them... I try EUmetcastview with no success. thanks.....
|
|
Re: HVS-1 data
On 12/11/2021 10:44, geojohnt via groups.io wrote:
Ernst and All,Thanks for your helpful comments, John. Folks, you can find TD 15 here: https://www.eumetsat.int/media/44096 Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv
|
|
Re: HVS-1 data
geojohnt@...
Ernst and All,
I've just had a look at EUMETAT's TD 15 again - which gets regularly updated and now contains a quite a lot more interesting 'relevant information' regarding reception.
It's well worth reading again.
It refers to 'recommended dish size' several times - but they don't exactly do this.
The 'required dish size' actually depends on where you live in Europe as the transmitted power contour varies across Europe.
See pages 15 - 18 and 30 - 31.
And the attached rain fade effect maps start with a 90 cm dish for instance right up to a 4.5 m dish at the end of the document.
And I would say it's not only rain fade to take into account.
I have quite often seen considerable reduction in 'signal strength' - leading to reduced SNR and Link Margin from ice crystals in nearby thunder storms 'in line' with the satellite when it's not raining that hard in my location.
Another thing to be taken into account is rain drops on your LNB face which in my experience can reduce your SNR by up to, 1.5 dB or more.
I read in the EUMETCast Satellite Antenna Satellite Pointing Guide that they recommend the use of an LNB rain shield on dishes up to 1.2 m.
And of course accurate pointing and skew adjustment is essential.
Regards,
John.
++++++++++++++++++++
Flo,
first of all we are talking about SNR not signal strength. I also hope you only loose UDP packets not packages. My above equations say that HVS-reception begins with about SNR = 9.3 dB. This is not on/off, you still have missed and lost packets. The EUMETSAT recommendation of minimum 4 dB LM means they propose SNR >= 13.3 dB which is indeed rather high. This might be intended for National Meteorological Services and should still work in not too heavy rain. I doubt you have no missed packets with SNR between 10.5 and 11.5 dB. But it certainly works as your LM is between 1.2 and 2.2 dB (not below 0 dB as the one of Terence). Cheers, Ernst
-----Original Message-----
From: Ernst Lobsiger via groups.io <ernst.lobsiger@...> To: MSG-1@groups.io Sent: Tue, 9 Nov 2021 18:14 Subject: Re: [MSG-1] HVS-1 data On Tue, Nov 9, 2021 at 09:33 AM, T-Online wrote:
everywhere i read that it is necessary to have min 12db signal strength for the HVS-1 Service.... _._,_._,_
_._,_
|
|
Re: HVS-1 data
On 11/11/2021 16:08, Terence O'Hanlon Smith via groups.io wrote:
A query if I may.I've not seen that effect, but a screen-shot, please. Has anyone else seen that? I might suggest the SatSignal group.... David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv
|
|
Re: HVS-1 data
Terence O'Hanlon Smith
Excellent news, Terence! Thanks for reporting back. I have a suspicion that IA query if I may. I don't know if this is a problem suffered by anyone else, but my two instances of the GOES ABI manager, with their headers as high as I can get them, show on screen only to the bottom of the lowest set of four image boxes. The captions for these boxes are off the bottom of the screen along with the Start/Stop buttons, "LEDs", the CLOSE button, and the processing status line (as I see them on your page for the programme). I cannot scroll down the window. Very odd. Changing the screen resolution makes no difference. I have files in the \Eumetcast\received\HVS-1\ directory trees for the various channels, but cannot process them. Each of the logs says the programmes have started on opening, but I presume no processing will occur until the start button is clicked. I have little doubt that there is a simple explanation and solution, but these presently escape me. Kind regards, Terence -- This email has been checked for viruses by AVG. https://www.avg.com
|
|
Re: HVS-1 data
On 11/11/2021 12:40, Terence O'Hanlon Smith via groups.io wrote:
Ernst, and anyone to whom it may be of interest,Excellent news, Terence! Thanks for reporting back. I have a suspicion that I might deserve another fraction of a dB, but it wouldn't be safe for me to adjust. I do find that tightening the four wall-clamp screws make a difference, and that I might put down to the screws gradually coming out with the repeated high winds we get. In my case it's the two upper screws which seem a shade looser. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv
|
|
Re: HVS-1 data
Terence O'Hanlon Smith
Ernst, and anyone to whom it may be of interest,
after yesterday's dismal weather, with a SNR of near 8.0dB, and losses even of basic data, I took advantage of the sunny spell this morning to climb on the garage roof and tweak my 90cm dish and LNB. I used my and my wife's mobile phones on Facetime, one with it's camera on the BDAdatex window on the screen in my study, and the other with me on the garage roof. This made it possible watch any improvement in SNR as I adjusted the receptors. From the 8.2dB with which the professional left me, I managed to obtain 11.3dB. What particularly took me by surprise was that, once the dish pointing and LNB focus and skew were near optimum, I was able to more finely improve th SNR by simply tightening or loosening each of the four bolts clamping the dish mount to the wall bracket. These theoretically only adjust azimuth, but by adjusting each bolt in turn I was able to further improve SNR by at least a half decibel. How sensitive is that! Anyway, thanks to y'all, particularly Ernst, for the heads-up, without which I would still be languishing in despair. Needless to say, by the time I came back indoors the data was flowing happily into the HVS-1 instance of Tellicast without me needing to touch anything else; so it appears, surprisingly, that at least I had done everything correctly in software set up. ATB, Terence On 09/11/2021 18:14, Ernst Lobsiger via
groups.io wrote:
On Tue, Nov 9, 2021 at 09:33 AM, T-Online wrote:
|
|
Data Access Services - Data synergy and collaboration with EUMETView
EUMETSAT have announced the following session for tomorrow. You may need these
services when the bandwidth from direct broadcast becomes too great or unsustainable! ======================================== Data Access Services - Data synergy and collaboration with EUMETView Online 11 November 2021, 13:00 - 14:00 UTC Monthly series of open, online short sessions on the Data Access Services and their usage via GUIs and APIs, answering top questions posted by participants in an open sli.do EXT EXT (event code #data-services, link https://app.sli.do/event/flsdivtc). We encourage you to post your questions in sli.do now so that we can adapt the content of the next session to answer them. The next scheduled sessions are on: Thursday 11 November 2021, 14:00-15:00 CET Thursday 9 December 2021, 14:00-15:00 CET The sessions are open to all and address a wide range of attendees, from service providers to scientists and forecasters. Each session requires registration via Zoom. A great opportunity to remove any technical challenges in using the Data Access Services GUIs and APIs, and engage users in discussion with EUMETSAT experts and colleagues. ======================================== More: https://trainingevents.eumetsat.int/trui/events/2092 Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: david-taylor@... Twitter: @gm8arv
|
|
Re: HVS-1 data
Ernst Lobsiger
On Tue, Nov 9, 2021 at 09:09 AM, Terence O'Hanlon Smith wrote:
t looks as though I may need a larger dish, as it was professionally adjusted and checked only a few short weeks ago, with a brand new Inverto LNB. I also then connected my Rx laptop and TBS 5927 directly to the dish with a short testing cable, and the reception levels and snr were the same as when indoors on the main cable link. I could perhaps try another LNB before going the whole hog.Terence, assuming that you still live on Mersea Islands and have not moved to Orkney, also assuming that you are not talking about a 45 - 60cm caravan TV dish, I still think your antenna is misaligned! If you check SNR on David's site: http://satsignal.eu/mrtg/performance_eumetcast-europe_snr.php There is an 88cm dish near Cardiff with SNR=12.4dB (average) There is an 85cm dish near Liverpool with SNR=12.4dB (average) I have had an 80cm dish with SNR around 13dB here in Switzerland. Until you get this sorted you should set a MODCOD filter for 8psk 3/5 only. This should dramatically improve your Basic Service reception. Cheers, Ernst
|
|
Re: HVS-1 data
T-Online <metcom@...>
Thanks for correcting me.
Till now i don't have any "damaged" picture from GOES16/17. Only when the weather is not good (rain, snow etc.). Strong winds are also not a problem. Ciao...Flo
|
|
Re: HVS-1 data
Ernst Lobsiger
On Tue, Nov 9, 2021 at 09:33 AM, T-Online wrote:
everywhere i read that it is necessary to have min 12db signal strength for the HVS-1 Service....Flo, first of all we are talking about SNR not signal strength. I also hope you only loose UDP packets not packages. My above equations say that HVS-reception begins with about SNR = 9.3 dB. This is not on/off, you still have missed and lost packets. The EUMETSAT recommendation of minimum 4 dB LM means they propose SNR >= 13.3 dB which is indeed rather high. This might be intended for National Meteorological Services and should still work in not too heavy rain. I doubt you have no missed packets with SNR between 10.5 and 11.5 dB. But it certainly works as your LM is between 1.2 and 2.2 dB (not below 0 dB as the one of Terence). Cheers, Ernst
|
|
Re: HVS-1 data
T-Online <metcom@...>
Hi guys,
everywhere i read that it is necessary to have min 12db signal strength for the HVS-1 Service.... With my 80cm dish i have all the time between 10.5 and 11.5db signal strength. I don't have with this setup any lost packages. Just in strong rainy conditions i am losing some packages. Good luck, Terence! Ciao Flo
|
|
Re: HVS-1 data
Terence O'Hanlon Smith
Thank you Ernst,
it looks as though I may need a larger dish, as it was professionally adjusted and checked only a few short weeks ago, with a brand new Inverto LNB. I also then connected my Rx laptop and TBS 5927 directly to the dish with a short testing cable, and the reception levels and snr were the same as when indoors on the main cable link. I could perhaps try another LNB before going the whole hog. I had not intended to suggest that I had previously taken HVS-1 on the SR1, as this was certainly not the case. My purely 'basic' system had not changed in many years. Attempting to receive HVS-1 has been an entirely new, and quite exacting, adventure for this rank amateur. Thank you again for your help and advice. ATB, Terence On 09/11/2021 16:44, Ernst Lobsiger via
groups.io wrote:
On Tue, Nov 9, 2021 at 06:56 AM, Terence O'Hanlon Smith wrote:
|
|