EUMETCast Ku-band Europe

DVB-S service SNR Graph

Ayecka receiver #1
Basic Service
 
SNR dB x 10

SNR Graph - DVB-S2 service

Ayecka receiver #2
High Volume Service
 
SNR dB x 10

Click on a graph for weekly, monthly and yearly data

  

Much of this information will be out of date, but is left for historical interest.

Summary per PC

What do we observe?

What is EUMETCast?

EUMETCast Ku-band Europe - TelliCast Missed and Recovered packets

Feenix TelliCast Graph

Main PC - Feenix
 SkyStar2 V2.6D PCI card
Missed packets
Recovered packets

 This data is snapshots of the TelliCast statistics display.  The numbers are rather small, and packets per day would be the best display scaling, but MRTG only offers packets per hour at best.  Therefore, it's possible that for the backup PC, at least (which just takes Meteosat-8 rapid-scan and Meteosat-9 full-scan), the recovered packets may stay at zero for the display, rather than their actual non-zero value.  This appears to be the best that can currently be done.

EUMETCast Ku-band Europe - FSY file & scratch/RAM disk sizes

Alta TelliCast Graph

Win-7/64 i5-760 PC - Alta
DVBWorld USB box

Missed packets
Recovered packets

Hydra TelliCast Graph

Test PC - Hydra
 SkyStar2 V2.6D PCI card

Missed packets
Recovered packets

Click on a graph for weekly, monthly and yearly data

FSY file size on main RX PC

Main PC - Feenix
SkyStar2 V2.6D PCI card
Receiving:
MSG-2, free DWDSAT
EARS-AVHRR
& Metop-AVHRR
RAM disk size on Test PC

Test PC - Hydra
SkyStar2 V2.6D PCI card
Receiving:
MSG-2,
EARS-AVHRR & 
all Metop-A data

Scratch disk used on PC Alta

Win-7/64 i5-760 PC - Alta
DVBWorld USB box
Receiving:
MSG-2, Metop-AVHRR
& EARS-AVHRR

Click on a graph for weekly, monthly and yearly data

The size of the FSY file (or files) gives an indication of the amount of data being temporarily buffered from the DVB stream.  It will be larger if more data is configured (e.g. for Metop as well as Meteosat-9), and it can also be larger if the receiving system is less than optimally configured when data segments which cannot be reassembled (because the data stream is incomplete) are accumulated in the FSY file.  During normal operation, the file will grow during the first 24 hours of operation, and be reasonably stable after that.  Periods of data loss and the occasional transmission of large files (e.g. VGT4Africa) can cause FSY file increases.  There may be more than one FSY file if you configure the recommended 300MB RAMdisk - it's the total size which is plotted above.
For the TelliCast 2.5.17 client, FSY files are no longer used, so the space occupied by the tmp_directory files on the RAMdisk or hard disk partition is plotted instead.  Large spikes here likely indicate TelliCast operation without the necessary data managers being run, and very large spikes may be edited out to preserve the normal-running information.

EUMETCast Ku-band Europe - Daily Download Throughput

DVB Main Traffic Graph

Main PC - Feenix
SkyStar2 V2.6D PCI card
Receiving:
MSG-2, free DWDSAT
EARS-AVHRR
& Metop-AVHRR
DVB Test Traffic Graph

Test PC - Hydra
SkyStar2 V2.6D PCI card
Receiving:
MSG-2,
EARS-AVHRR & 
all Metop-A data

DVB Alta Traffic Graph

Win-7/64 i5-760 PC - Alta
DVBWorld USB box
Receiving:
MSG-2, Metop-AVHRR
& EARS-AVHRR

Click on a graph for weekly, monthly and yearly data


  

Other sites with EUMETCast monitoring - north to south order - map quick-look

How can I set up similar monitoring on my own system?  More information on monitoring EUMETCast and using MRTG for monitoring other information.

TelliCast and the network throughput.

The way the DVB and TelliCast system works - in a nutshell - is this.  The data from the satellite is tagged with a packet identifier called the PID, and using the setup for your DVB card or box you can choose which PIDs the card should handle.  As there are only a limited number of PIDs which some DVB cards can handle, the PID is used as a rather coarse-level control to break the data stream down into reasonable-bandwidth chunks.  The data is sent from the DVB card to the TelliCast receiving program as an IP multicast stream, delivered over UDP for best efficiency, but meaning that delivery isn't guaranteed, hence the susceptibility of the system to interruptions by high CPU, disk and network loading.  

The data is further divided into streams by using "channel names".  Here are the channel names for EUMETCast.  A single PID may contain a number of different streams, but each stream will have a different multicast address.  The multicast address of the "Announcement channel" stream is fixed, and that channel talks to the TelliCast program saying what data is available.  If you have configured the TelliCast program to accept a particular data channel (e.g. EUMETSAT Data Channel 2 - for the HRIT data), and you are allowed access by your eToken, when new data is available for that channel the TelliCast program will "join" the multicast being sent out via the DVB software, and when the DVB software finds a "joined" channel (i.e. one with some listeners), it will send out the data packets for that stream to the appropriate multicast address.

In computer networking terms, the packets originate from a multicast network 224.0.0.0 with a netmask 240.0.0.0.  For example, for [Metop AVHRR] data, the source address is 224.223.222.239:2390.  The TelliCast software has the address of an "announcement channel" set by its recv.ini file, which also contains the address of the network interface (typically 192.168.238.238).  So the TelliCast software should be able to join a multicast group on the specified interface.  One thing which some DVB software appears to omit is the command to tell Windows that any request for the multicast network (224.0.0.0) must be routed via the DVB virtual network interface (192.168.238.238), and you may need to add that route with a manual command.  However, as the TelliCast software already knows exactly which interface to use, why you even need the route command is not yet clear.....  More about multicast programming.  The recv-channels.ini file will determine whether or not TelliCast accepts a particular set of data announced by the DVB network.  If that data isn't accepted, the network interface doesn't send it, and it won't appear on the flow reported by the DVB pseudo-network (although this behaviour appears to differ between the SkyStar PCI and Dexatek/DVBWorld USB software).  Perhaps this is handled by having more than one multicast group associated with the TelliCast software.  Perhaps there is one group per data channel?  Multicast Mechanics.

It is the sum total of data sent to active multicast channels which is plotted above as "throughput".  Note that as some of the data is compressed internally to the TelliCast software, the network throughput between the DVB interface and the TelliCast software may be less than the data throughput reported by the TelliCast software.  To reduce the load on your PC, you can either disable individual PIDs in the DVB software (right-click the green satellite icon , Setup4PC, Data Services), or you can select the channels you want by editing the recv-channels.ini file in the TelliCast software.

Significant events and changes

How were these results plotted?

I use MRTG to monitor my networks on Windows 2000, XP, Vista and Windows-7 (32- and 64-bit).  I suggest that you first set up MRTG to show the network throughput on your system, using the instructions on the MRTG Web pages.  If you are using Windows Vista or Windows-7 you may first need to install and enable the Windows SNMP component.  Define a directory for the output HTML and PNG files from MRTG, and use the command "perl cfgmaker public@<pc-name>" to establish your basic MRTG configuration file.  Note also that you will need to create the LogDir, HtmlDir and ImageDir folders yourself - MRTG doesn't do it for you.  These directories are where the summary log files, the HTML output, and the PNG image output are stored.  The HTML and PNG output make up the graph pages you have seen above.  You can use MRTG for monitoring other information such as CPU load, disk usage, air temperature and even cable modem signal levels.

To show throughput, SNMP (Simple Network Management Protocol) also needs to installed on the PC as part of the Windows Networking components (it's on the Windows CD).  To install SNMP, Control Panel, Add/Remove Programs, Add/Remove Windows Components, check that Management and Monitoring Tools are selected.  Note that on Windows-7 and Vista, where the security is a little tighter, you may need to add the "public" to the Services, SNMP, Properties, Traps communities, and add "public" with READ ONLY access to the Security settings.  My thanks to Andrew Hall for reminding me about this possibility.  Andrew runs MRTG as a service, I run it from a shortcut in the Startup folder.

You can use SNMP/MRTG to monitor the throughput from the DVB card as well, since it appears as a network device.  Just as you determined the address(s) for the PC's network, run PERL CFGMAKER again to find out the network device interface number.  Hint: I find ROUTE PRINT a much easier way, at least to confirm the interface number.  As the DVB card is a one-way device, you may like to add the "noo" option to the DVB target in your MRTG configuration script.  Here's what I have for my PC Gemini:

    Options[Gemini_DVB]: unknaszero, growright, noo

You can also use MRTG to plot a variable which can be obtained from the command-line by running a program which writes it results to "standard output", i.e. a normal command-line output.  I used the B2status.exe program from the B2C2 SDK which can return a snapshot of the status of the DVB card.  Please be aware that the version of B2status.exe in some SDK versions does not work, so there are earlier and later copies here in B2satus.zip.  Please use the version appropriate for your drivers - the V4.4.1 version also works with V4.5.1 (and, I hope, 4.6.0) software.  You will need to copy this program to the MRTG "bin" directory, so that the MRTG script can find it.  The B2status.exe program can take command-line parameters to limit the displayed data, so I run this with the -TI parameter.  The first line of the Perl script below invokes the command, and processes the output from the program into a four-line response as required by MRTG.  There are three separate scripts - one to get the Quality and SNR, one to get the BER, and one to get the "Strength" for drivers V4.4.1 and later.  To make the values sensible integers for MRTG to plot, the SNR is scaled by 10 so that both it and Quality become values in the range 0..120 (at least on my system), and the BER is scaled by 1E6 so that it becomes an integer "parts per million" value.  

Note: it appears that using such small integers with MRTG may lead to slight errors in the yearly and monthly plots, with the values being less than the true values, so be careful not to interpret the results too critically.  It would perhaps be better to multiply the results by (say) 1000 before giving them to MRTG, but you would then need to rescale the graphs and display text.

Allan Gibbs comments: When using b2status I had to add the card's name - I just used "skystar" and it worked whereas I kept getting an error otherwise.  So my entry in the .pl files is:

    b2status -a skystar -ti

Note for SkyStar V4.4.1 drivers: The first line would be: 

	$ntp_str = `"C:\\Program Files\\TechniSat DVB\\bin\\b2status.exe" -ti`;

if you needed to run the b2status command from its installed folder, for example if you have the SkyStar V4.4.1 drivers.

 

File: SkyStarQualSNR.pl

$ntp_str = `b2status -ti`;
$qual = (split(/\n/,$ntp_str))[4];
$qual = (split(/ +/,$qual))[4];
$snr = (split(/\n/,$ntp_str))[5];
$snr = 10 * (split(/ +/,$snr))[3];
$snr = int ($snr);
print "$qual\n";
print "$snr\n";
print "0\n";
print "0\n";

I found that on one system, the SNR value reported was occasionally 1 or even blank, I don't know why, so I made an experimental version in July 2009 which has a retry should the SNR value possibly be incorrect.  I called this version SkyStarQualSNR-2.pl - here it is; 

File: SkyStarQualSNR-2.pl

$ntp_str = `b2status -ti`;
$qual = (split(/\n/,$ntp_str))[4];
$qual = (split(/ +/,$qual))[4];
$snr = (split(/\n/,$ntp_str))[5];
$snr = 10 * (split(/ +/,$snr))[3];
$snr = int ($snr);
$ber = (split(/\n/,$ntp_str))[6];
$ber = (split(/ +/,$ber))[3];
if ($snr < 10) {
  $ntp_str = `b2status -ti`;
  $qual = (split(/\n/,$ntp_str))[4];
  $qual = (split(/ +/,$qual))[4];
  $snr = (split(/\n/,$ntp_str))[5];
  $snr = 10 * (split(/ +/,$snr))[3];
  $snr = int ($snr);
  $ber = (split(/\n/,$ntp_str))[6];
  $ber = (split(/ +/,$ber))[3];
}
print "$qual\n";
print "$snr\n";
print "0\n";
print "0\n";

File: SkyStarBER.pl

$ntp_str = `b2status -ti`;
$ber = (split(/\n/,$ntp_str))[6];
$ber = (split(/ +/,$ber))[3];
$ber = int (1000000 * $ber);
print "0\n";
print "$ber\n";
print "0\n";
print "0\n";

File: SkyStarStrength.pl

$ntp_str = `b2status -ti`;
$strength = (split(/\n/,$ntp_str))[3];
$strength = (split(/ +/,$strength))[4];
print "0\n";
print "$strength\n";
print "0\n";
print "0\n";

Once the values are available as integers, they can be plotted with MRTG.  Plotting the Quality and SNR requires a fixed 0..120 scale (allowing for up to 12dB).  Plotting the BER is best done on a log scale, and strength a linear scale of 0..100%.  I did add the Timezone option, to make sure the plots are in UTC (which may be called GMT by MRTG) so that plots from different countries may be more easily compared, and I added an XSize setting so that the graphs cover a slightly wide time range.  These are entered as "default" values, i.e. using just the underscore as the target name.  I'm no expert in MRTG, so if you have any suggestions for improvements of the following I would welcome them!

Extra lines for MRTG.cfg

# These are default values.  The XSize sets the graph width with 
# the image being 100 pixels larger at 600 pixels.
# The TimeStrPos and TimeStrFmt put the date in upper-right corner.
# The timeout option provides extra delay when calling external programs.

XSize[_]: 500
Timezone[_]: UTC
TimeStrPos[_]: RU
TimeStrFmt[_]: %Y-%b-%d
SnmpOptions: timeout => 6

#---------------------------------------------------------------
#	PC Stamsund - EUMETCast BER (bit error rate)
#---------------------------------------------------------------

Target[SkyStar_Stamsund_BER]: `perl SkyStarBER.pl`
MaxBytes[SkyStar_Stamsund_BER]: 1000000
Title[SkyStar_Stamsund_BER]: SkyStar V2.6D DVB PCI card on Stamsund
Options[SkyStar_Stamsund_BER]: gauge, nopercent, growright, logscale, withzeroes, unknaszero
YLegend[SkyStar_Stamsund_BER]: BER ppm
ShortLegend[SkyStar_Stamsund_BER]: ppm
LegendI[SkyStar_Stamsund_BER]:
LegendO[SkyStar_Stamsund_BER]: BER:&nbsp;
Legend1[SkyStar_Stamsund_BER]: 
Legend2[SkyStar_Stamsund_BER]: Bit Error Rate (BER) in parts per million
PageTop[SkyStar_Stamsund_BER]: <H1>SkyStar2 V2.6D Bit Error Rate (BER) snapshots - Stamsund, Edinburgh</H1>

#---------------------------------------------------------------
#	PC Stamsund - EUMETCast quality and SNR
#---------------------------------------------------------------

Target[SkyStar_Stamsund_SNR]: `perl SkyStarQualSNR.pl`
MaxBytes[SkyStar_Stamsund_SNR]: 120
MaxBytes2[SkyStar_Stamsund_SNR]: 120
Unscaled[SkyStar_Stamsund_SNR]: dwmy
Title[SkyStar_Stamsund_SNR]: SkyStar V2.6D DVB PCI card on Stamsund
Options[SkyStar_Stamsund_SNR]: integer, gauge, nopercent, growright
YLegend[SkyStar_Stamsund_SNR]: Quality, SNR x10
ShortLegend[SkyStar_Stamsund_SNR]: .
LegendI[SkyStar_Stamsund_SNR]: Quality %:&nbsp;
LegendO[SkyStar_Stamsund_SNR]: 10 * SNR dB:&nbsp;
Legend1[SkyStar_Stamsund_SNR]: Signal Quality (0..120%)
Legend2[SkyStar_Stamsund_SNR]: SNR * 10 (0..12.0dB)
PageTop[SkyStar_Stamsund_SNR]: <H1>SkyStar2 V2.6D Quality & SNR snapshots - Stamsund, Edinburgh</H1>

#---------------------------------------------------------------
#	PC Stamsund - EUMETCast Strength
#---------------------------------------------------------------

Target[SkyStar_Stamsund_Strength]: `perl SkyStarStrength.pl`
MaxBytes[SkyStar_Stamsund_Strength]: 100
MaxBytes2[SkyStar_Stamsund_Strength]: 100
Title[SkyStar_Stamsund_Strength]: SkyStar2 V2.6D DVB PCI card on Stamsund, Edinburgh
Options[SkyStar_Stamsund_Strength]: integer, gauge, nopercent, growright
YLegend[SkyStar_Stamsund_Strength]: Strength %
ShortLegend[SkyStar_Stamsund_Strength]: %
LegendI[SkyStar_Stamsund_Strength]:
LegendO[SkyStar_Stamsund_Strength]: Strength:&nbsp;
Legend1[SkyStar_Stamsund_Strength]: 
Legend2[SkyStar_Stamsund_Strength]: Strength (percent)
PageTop[SkyStar_Stamsund_Strength]: <H1>SkyStar2 V2.6D Strength snapshots - Stamsund, Edinburgh</H1>

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

When I moved PC Stamsund to the drivers V4.5.0 (for lower DPC latency, V4.4.1 don't install on XP SP3), I noted that sometimes the Perl/B2status command returned a blank result, and as I had the "unknaszero" option set, these made for spikes showing zero signal on the graphs every so often, even though the signal quality and SNR were fine.  I therefore removed the "unknaszero" option (although it will make down-time less obvious).  So far, the strength plots seem useless - with the backup PC Stamsund stuck on 38% (V4.5.0 drivers), and the test PC Hydra dropping from 40% to 25% for no apparent reason (V4.4.1)!

Notes on Linux usage

Daniel R. Hurtmans has been using similar tools under Linux to plot values for his system in Brussels.  During e-mail exchanges in October 2012 he noted the following:

Methodology

I had to switch from MRTG to RRDTOOL.  This was not an easy decision as transition is not that easy, but it offers some features which are useful (handling properly missing data, having negative values, properly handling date/time conflicts).  Although it comes from the same developer and despite all my efforts to be as close as possible to MRTG look, resulting plots have a quite different look and feel (I've still some work do polish-up the presentation, as I'm discovering the tool).

Reported values

About the SNR, the tool used to "measure" is called femon.  It reports either pure hexadecimal, or percents (actually the hex value /0xffff). 
I'll dig a bit to see if it is real or not.  There are some discussions on the net about some card having a maximum of 30 dB so that the 
percentage should apply to this value.  I've no idea so far on the maximum value for my card. I'll dig that further....

Daniel later reported: the Linux driver "corrects" the raw values (I believe that is made on purpose for having some standard grid between different TV cards):

1) the signal quality is multiplied by 5./4. which corresponds to the jump I observed from ~60% to ~70%.

2) the SNR is encoded in a really weird manner. The chipset manual tells a cryptic: "A simple C/N estimator can be easily implemented by comparing the current indications with a primarily-recorded look-up table."

The Linux drivers uses a conversion: ((65535-RAW_SNR)-41216)*3 / 65535 to get a value close to 1 at the card maximum.  After "googling" a bit I found an obscure translation from raw values to dB:  19.02-0.0017*RAW_SNR  which seems to correspond to the windows drivers values.  I've applied both these back transformations to get values more common to what I used to get before.

Still no clue on BER units. To what I've read so far I think I should divide my numbers by 2^12, 2^14, 2^16 or 2^18 (pick yours).

Aligning the results with the MRTG graphs

Now for the html plots alignment; the left edges of the actual plot plots are respectively 65 pixels and 81 pixels right of the picture left edge.  The difference is then 15 pixels. I think that the most compatible way (at least for modern browsers) is to do something like: 

<td style="padding-left: 15px;">
   <a href="http://cpm-ws4.ulb.ac.be/....

Monitoring Strength & Quality with the new USB 2.0 boxes

During 2008, the newer Dexatek and DVBWorld USB 2.0 boxes have come into wide use, partially because they don't require you to open the PC to use them, and partially because they offer such good performance.  However, there is no b2status.exe program supplied with these boxes, so signal strength monitoring has been more difficult.  However, I have now written a small program called DVBreport.exe which does a similar job the the combination of the Perl script and b2status.exe method described above.  If you want to try this experimental program, you can download it as part of the b2status.zip package, and put it in the same directory as your MRTG configuration file.  It has been tested with the Dexatek software with both the DVBWorld and Dexatek boxes.  Its settings are configured for the Eurobird-9A service, and with a simple command-line switch, the same program can also be used for the Envisat-DDS service on Eutelsat W2A at 10°East.  To test whether the program works on your system, simply run it from the command line, and ensure that you get four lines of numbers as an output: 

C:\> DVBreport
85
65
0
0
C:\>

It seems that the DVB-S2 boxes may not output all the data using this program.  Sample command for MRTG when using the program are: 

#---------------------------------------------------------------
#	PC Gemini - EUMETCast quality and SNR
#---------------------------------------------------------------

Target[SkyStar_Gemini_SNR]: `DVBreport.exe`
MaxBytes[SkyStar_Gemini_SNR]: 120
MaxBytes2[SkyStar_Gemini_SNR]: 120
Unscaled[SkyStar_Gemini_SNR]: dwmy
Title[SkyStar_Gemini_SNR]: Dexatek DVB USB box on PC Gemini, Edinburgh
Options[SkyStar_Gemini_SNR]: integer, gauge, nopercent, growright, unknaszero
YLegend[SkyStar_Gemini_SNR]: Qual, Strength
ShortLegend[SkyStar_Gemini_SNR]: %
LegendI[SkyStar_Gemini_SNR]: Quality:&nbsp;
LegendO[SkyStar_Gemini_SNR]: Strength:&nbsp;
Legend1[SkyStar_Gemini_SNR]: Signal Quality (0..120%)
Legend2[SkyStar_Gemini_SNR]: Signal Strength (0..120%)
PageTop[SkyStar_Gemini_SNR]: <H1>Dexatek DVB USB box Quality & Strength snapshots - Edinburgh</H1>

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

Uploading the data

Once you have MRTG creating the HTML and PNG files, you will need to create a routine job to upload those files to your Web server, and schedule that job with the Windows scheduler.  I update every 30 minutes, the choice of update frequency is yours.  Use the Advanced settings in the Windows Scheduler to repeat the upload task every 30 minutes for a duration of 24 hours, and schedule the overall task to run every day.  Notes on using the Windows scheduler.

Scheduled command file - e.g. C:\Tools\UploadMRTG.cmd 

----------------------------------------------------------------------
REM Go to where the MRTG HTML output is:
PUSHD  C:\Web\LocalCopy\

REM Call FTP with redirected input:
FTP -n -i -s:C:\Tools\UploadMRTG.ftp

POPD
EXIT
----------------------------------------------------------------------

FTP commands - e.g. C:\Tools\UploadMRTG.ftp 

----------------------------------------------------------------------
open ftp.<my.web.space>
user <user-name> <password>

cd /mrtg/
lcd \Web\LocalCopy\
prompt			N.B. only required for MOVEit Freely.
type ascii
mput *.html
type binary
mput *.png

quit
----------------------------------------------------------------------

Well, I expect you get the idea.....  I found that the Windows-supplied command-line FTP program tended to hang with my ISP's Web provision, so I now use MOVEit Freely from Standard Networks instead.  Almost identical command syntax, but you need to turn off per-file prompting with the "prompt" command, as shown above.  If you are new to command-line FTP, there are some hints and tips here.
  

Monitoring FSY file size

Fred van den Bosch posted the following information in the MSG-1 self-help group for those who wish to monitor the size of the TelliCast FSY database file(s).  You can see Fred's results here.

Fred writes: With some trial and error I found something (don't dare to call it a solution yet).  At least it works for 0.fsy.  I can only test it when a 1.fsy file is generated, so I hope I can never test this :-)  For those who already have a 1.fsy and want to test it this is the whole content of fsysize.pl.  Crazy language, that Perl.  Why crazy? Well during testing I noticed that fields I set within the "if" has no value outside the "if". ??????  I agree, I know nothing about Perl (and after the above experiences I like to keep it that way), so there's a good chance I do something completely wrong. But it works and that's all that matters.  Later: Nice language, that Perl.  Thanks to hint from Rob Alblas I understand now what was wrong.  My means to declare a variable and this I did a couple of times.  So the revised (and hopefully final) version is now:  

use File::stat;
chdir("z:");
chdir("/receiving");
my $fsysiz0 = 0;
my $fsysiz1 = 0;
$fsysiz0 = stat("0.fsy")->size;
$sb=$fsysiz0 * 0.000001;
$dev = stat("1.fsy");
if ($dev > 0) {
	$fsysiz1 = stat("1.fsy")->size;
}
$sb=($fsysiz0 + $fsysiz1) * 0.000001;
print "0\n";
print "$sb\n";
print "0\n";
print "0\n";

Monitoring FSY File size - alternative method

Based on Fred's work above, I also added FSY file size monitoring.  I used an alternative Perl script which takes the directory to be monitored as a parameter.  I also made the "check status and report" size part a Perl subroutine so that it could be extended to any number of FSY files, and returned the value as bytes rather than megabytes, as MRTG is quite happy handling large numbers.  In the example below, up to three FSY files are checked, for a RAMdisk size of up to about 380MB (the EUMETSAT recommendation is a RAMdisk size of 300MB). 

----------------- File: FSYsize.pl -----------------------------------
use File::stat;
chdir ($ARGV[0]);	# read the command-line argument

sub fsysize
# procedure to extract file size, if the file exists
# Otherwise it returns 0
{
	$dev = stat ($_[0]);
	if ($dev > 0) {
		stat ($_[0])->size;
	}
}

$total = &fsysize ("0.fsy") + &fsysize ("1.fsy") + &fsysize ("2.fsy");
print "0\n";
print "$total\n";
print "0\n";
print "0\n";
----------------------------------------------------------------------

The commands for MRTG then look like this: 

#---------------------------------------------------------------
#	PC Stamsund - FSY File Size
#---------------------------------------------------------------
Target[Stamsund-fsy]: `perl FSYsize.pl Z:/receiving`
MaxBytes[Stamsund-fsy]: 313900000
Options[Stamsund-fsy]: integer, gauge, nopercent, growright, unknaszero, noi
Unscaled[Stamsund-fsy]: dwmy
YLegend[Stamsund-fsy]: FSY size
ShortLegend[Stamsund-fsy]: B
LegendO[Stamsund-fsy]: Size  &nbsp;
Legend2[Stamsund-fsy]: FSY file size
Title[Stamsund-fsy]: Stamsund FSY file total size - 314,572,800 byte (300MB) RAMdisk
PageTop[Stamsund-fsy]: <H2>PC Stamsund - FSY Files Total Size</H2>
#---------------------------------------------------------------

Monitoring TelliCast statistics

I wrote a small program which takes a PC node name as a parameter, reads the output from the TelliCast HTML Shell, Statistics screen, and returns the result to standard output.  The program was updated on 2008 Aug 21 to work with both the V2.4.4B and the later V2.4.4.a TelliCast client software.  Place TelliCastStats.exe in your MRTG\bin directory, and ensure that the run-time libraries are installed on the system.  If you have a software firewall installed, you may need to give the program permission to access the local network.  You can use that program together with MRTG like this, where hermes is the TCP/IP node name for the PC you wish to monitor: 

#---------------------------------------------------------------
# PC Hermes - TelliCast statistics
#---------------------------------------------------------------
Target[Tellicast-Hermes]: `TelliCastStats hermes`
MaxBytes[Tellicast-Hermes]: 1000000
Options[Tellicast-Hermes]: unknaszero, growright, logscale, nopercent, withzeroes, perhour
YLegend[Tellicast-Hermes]: Packets / hour
ShortLegend[Tellicast-Hermes]: packets / hour
LegendI[Tellicast-Hermes]: Recovered packets
LegendO[Tellicast-Hermes]: Missed packets
Title[Tellicast-Hermes]: TelliCast Statistics - on main PC Hermes
Legend1[Tellicast-Hermes]: Recovered Data Packets
Legend2[Tellicast-Hermes]: Missed Data Packets before FEC
PageTop[Tellicast-Hermes]: <H1>TelliCast Statistics - on main PC Hermes</H1>
#---------------------------------------------------------------

John Say has kindly contributed an alternative way of using the TelliCastStats.exe program to show lost packets.  Here is his note:

After several days running, I have changed my mind and after all think this produces a useful result for lost (unrecovered) packets.

The Perl script is: 

$pkt_str = `TelliCastStats <name> -all`;
$rec = (split(/\n/,$pkt_str))[0];
$miss = (split(/\n/,$pkt_str))[1];
$loss = ($miss - $rec);
print "$loss\n";
print "0\n";
print "0\n";
print "0\n";

Note that the <name> could include a port number (e.g. eumetcast-pc:2517) with the TelliCastStats.exe from 2014-Nov-23 and later. A sample of the results is here:

John Say's "only unrecovered packets" graph
 

Testing the scripts

To help you test an installation on your own system, I would first suggest getting Perl, MRTG and SNMP installed on your system, and getting the network throughput data from the DVB card correctly plotted.

Alan Banks comments: If you need to fault find the cfg file go to C:\mrtg-2.15.0\bin ( or wherever you put mrtg.cfg)

    perl mrtg mrtg.cfg

This will tell you what errors there are in the file if it wont start.  When you have it working, close the command window, re-open go to C:\mrtg-2.15.0\bin and type

    wperl mrtg mrtg.cfg

Check wperl is in processes in Task Manager and then close the cmd prompt.  [DJT note: I just use Perl and not WPerl]

Once you have the throughput correctly plotting and updating, progress to the scripts above.  Here are some debugging hints:

First question

Is the SkyStar card installed in the system where you are running MRTG?  OK, I thought it was!

Second question

When you run B2STATUS.exe, does it produce something like this? 

C:\> b2status -ti
************* Current Tuner information: ****************
Tuner type : Satellite
Status In Lock : YES
Signal Strength : n/s
Signal Quality : 65 %
SNR : 8.651000
BER : 0.000000
Total Blocks : n/s
Corrected Blocks : n/s
Uncorrected Blocks : 0
Settings Frequency : 10853 MHz
Symbol Rate : 27500 kS/s
FEC : 3/4
Polarity : HORIZONTAL
Modulation : n/s
Diseqc : NONE
LNB Frequ. : 9750 MHz
LNB Select. : 0 kHz
Guard Interv. : n/s
Bandwidth : n/s
*********************************************************
C:\>

It is this output which the Perl Script parses.

Third Question

Finally, running the command from the Command prompt: 

perl SkyStarQualSNR.pl

should produce 4 lines of output, something like: 

65
86
0
0

Please note that we have also found that the BER is almost always zero on some cards, unless the signal is about to crash completely through the floor!

David Taylor
2011 Jan 08