EUMETCast Ku-band Europe - SNR, Quality & Bit Error Rate
|
|
Test PC
Hydra
(V2.6D card)
SNR dB x 10
Signal Quality %
|
|
|
Backup PC
Stamsund
(V2.6D card)
SNR dB x 10
Signal Quality %
|
|
Backup PC
Stamsund
(V2.6D card)
Bit Error Rate
BER snapshots
parts per million
|
|
Click on a graph for weekly, monthly and yearly data
|
|
This data is taken from my Test and Backup PCs, which have SkyStar2 V2.6D PCI
cards. They are fed via two splitters from the main feed from the LNB.
The plot shows snapshots of the Bit Error Rate (BER) taken every five minutes,
and snapshots of the Signal Quality (green) and SNR (blue)
readings. To use a common scale, the SNR plotted is ten times the
true value, so that the SNR scale is 0..12.0dB. Time is shown in UTC.
Summary per PC
What do we observe?
- Local weather variations causing signal-strength and quality drops on
V2.6x cards, and higher BER on the V2.3 cards (only shows on V2.6 cards when
very bad). This happens during
high rainfall and perhaps snowfall periods, due to water-vapour in the
atmosphere and perhaps films of water or accumulations of snow on the LNB or
dish.
- Local variations due to high wind if your antenna is not securely mounted.
- Variations in signal strength across Europe which show as
variations SNR & signal quality on the V2.6x cards and as
non-zero BER on the V2.3 cards. These variations may also be caused
by weather conditions or other issues at the uplink station.
- Wide-bandwidth, or even out-of-band transmissions from the
HotBird-6 satellite (or adjacent satellite?) which cause non-zero BER values lasting from several minutes to several
hours, but only to be observed on the V2.3 cards. The signal
strength, even as reported by the V2.6x cards, remains high during these periods.
- Variations in TelliCast missed and recovered packets due to TelliCast
server issues - compare rates with
data volume and signal strength.
|
|
Main PC
Hermes
(V2.6B card)
Missed packets
Recovered packets
|
|
|
Test PC
Hydra
(V2.6D card)
Missed packets
Recovered packets
|
|
|
Backup PC
Stamsund
(V2.6D card)
Missed packets
Recovered packets
|
|
Click on a graph for weekly, monthly and yearly data
|
|
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 MSG-1 and EARS-AVHRR), the
recovered packets may stay at zero for the display, rather than their actual
non-zero value. This will be reviewed once a few days data is gathered.
 |
Main PC
V2.6B SkyStar2 PCI
Receiving:
MSG-2, free DWDSAT
EARS-AVHRR
& Metop-AVHRR |
|
Test PC
V2.6D SkyStar2 PCI
Receiving:
MSG-2,
EARS-AVHRR &
all Metop-A data |
|
|
Vista PC
Dexatek USB box
Receiving:
MSG-2, Metop-AVHRR
& EARS-AVHRR |
|
|
Backup PC
V2.6D SkyStar2 PCI
Receiving:
MSG-2 (+ tests)
& EARS-AVHRR |
|
Click on a graph for weekly, monthly and yearly data
|
|
- UK - north to south order
- David Taylor, Edinburgh, Scotland - map
- John Say, Stanhope, Co. Durham - map
- Donald Martin, Billingham, Teesside - map
- Allan Gibbs, Prescot, Merseyside - map
- Paul Hayes, Salford, Manchester - map
- Alan Banks, The Wirral, Cheshire - map
- David Anderson, Loughborough, Leicestershire - map
- Nick Norman, Norwich - map
- Francis Breame, Surrey - map
- Denmark
- Copenhagen, Institute of Geography - map
- The Netherlands
- Fred van den Bosch, Capelle ad IJssel - map
- Belgium
- Daniel R. Hurtmans, Brussels - map
- Italy - north to south order
- Giuseppe Cico, Turin - map
- Nicola Sebastiani, Alessandria near Genoa - map
- Maurizio Calvitti, Anguillara near Rome - map
How can I set up similar monitoring on my own system? Read this
page!
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 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
(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 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.
- 0800 UTC, Monday, 2008 May 05, week 19. Start of main MSG-2 data
processed to effective radiance and not spectral radiance. Parallel dissemination of
MSG-2 data processed to effective radiance ended.
- 0800 UTC, Tuesday, 2008 Apr 29, week 18. Parallel dissemination of
MSG-2 data processed to effective radiance started.
- Sunday, 2008 Mar 02, week 9. Noticed some files named: E6D02290000030400001.
These have an invalid file name, as 2006 did not have 28 days in month
02. Could be renamed to E8D02290000030400001 for correct processing.
- 1649-1723 UTC, Tuesday, 2008 Feb 26, week 9. EUMETCast signal loss
on PCs Gemini, Hermes, Hydra and Stamsund. The signal strength
indicator on Gemini stayed at 69%, but was red. When the antenna lead
was removed it dropped to zero. Normal operation has a yellow-green,
and not a red, background.
- 0919 UTC, Monday, 2008 Feb 25, week 9. Was informed by EUMETSAT that
they don't use PID 502, so removed it from the Vista PC (Gemini).
- 1550 UTC, Saturday, 2008 Feb 23, week 8. Noticed intermittent red
T-icons on Hermes when doing other work. The log file was full of
failures to connect to the DWDSAT channel, which is on PID 302. But
when comparing Hermes and Gemini, it was PID 502 which was missing from
Hermes, and that's not listed on the EUMETSAT web-site list. Perhaps
PID 302 got lost in the glitch on Feb 13? Looks as if the act of adding
PID 502 into Hermes (what data?) has also restored PID 302 to being active.
- 1357 UTC, Wednesday, 2008 Feb 13, week 7. EUMETCast glitch caused
restarts on Hermes, Hydra and Stamsund. Noted about 400MB/day less
throughput on Hermes compared to Gemini after that, and they were identical
before. Why?
- 0700 UTC, Friday, 2008 Feb 15, week 7. Power-off reset of
Stamsund. The SkyStar2 PCI card now reports a lower signal level by about 1.25dB.
"Stable 2" condition!
- 1100 UTC, Saturday, 2008 Jan 26, week 4. Had occasion to reboot
Stamsund and found the reported signal level jumped by 1.5dB and quality by
8%. The actual signal was completely unchanged (as reported by
Hydra). Now it's Hydra 7.3dB 58%, Stamsund 7.1dB 56%. So much for consumer-level products!
- 1230 UTC, Monday, 2007 Dec 31, week 53. Replaced SkyStar V2.3 card
in Stamsund with V2.6D card, both to reduce the heat and to provide more
meaningful signal comparisons.
- 1700 UTC, Tuesday, 2007 Dec 25, week 52. PC Stamsund (backup PC)
power-supply fan stopped working. New PSU purchased from Maplins on
Boxing Day (26th) and operation restored at 11:30 UTC.
- ~0815 UTC, Tuesday, 2007 Nov 27, week 48. TelliCast Web service on
Test PC Hydra seemed to stop working. Windows updates installed
(including MS IE 7) and PC rebooted at 0615 the next day.
- 1725 -1737 and 2012 -2034 UTC, Tuesday, 2007 Nov 13, week 46. power
outage.
- 1420 UTC, Wednesday, Nov 07, week 45. Step increase in signal
strength and quality across Europe. About 1dB in signal strength and
5% in quality.
- 1610 UTC, Tuesday, Nov 06, week 45. Possible small step drop in signal
strength. 05 - 1.0dB, and slight quality reduction. Seen across Europe.
- 1415-1640 UTC, Tuesday, Nov 06, week 45. Although the signal
strength remained steady at its reduced level, the backup PC Stamsund showed
a very high missed packet/recovered packet rate, and hung at 1640. Is
the card on its way out?
- 0721 UTC, Monday, Oct 29, week 44. eToken error on Stamsund (backup
PC). Could not restart as the Web server port wasn't released (and so
still in use). Logged out and back in to restart OK at 18:00.
ERR:2007-10-29 07:21:43.212:eToken transaction timed out
ERR:2007-10-29 07:21:43.212:Critical dongle error (eToken transaction timed out). Restarting child.
ERR:2007-10-29 07:21:43.337:EToken thread does not terminate
- 0340 UTC, Sunday, Oct 28, week 43. Sharp dip in signal strength seen
on backup and test PCs, with degradation on either side of that time.
There was high wind here overnight, and perhaps rain. Nothing seen
across the rest of Europe. Slight data loss on the Backup PC
(Stamsund, V2.3 card) but nothing on the others (V2.6 cards).
- 2345 UTC, Monday, Oct 22, week 43. Break in EUMETCast from
2345-2359, and 0029-0042 (Tuesday 23). On Hermes and Hydra, the
timekeeping suffered a glitch as well.
- 0137 UTC, Saturday, 2007 Oct 20, week 42. Breaks in EUMETCast at
01:37:49 - 02:39:49 (Hermes), 01:37:54 (Hydra), and 01:38:00-02:39:49 on
Stamsund. On Hydra, the PC rebooted (with nothing in the event log), and on Stamsund, Server4PC.exe
"encountered an error". It looks as if the signal now is at
reduced strength and therefore reduced quality. However, Europe-wide
the strength and quality look OK. Rebooted Hydra again to try and
restore the correct signal strength reading.
- Tuesday, 2007 October 16, week 42. More uplink events. Signal
breaks at: 13:39:44 UTC and 13:44:10 (Hermes), 13:39:44 and 13:44:10
(Hydra), and 13:39:45 and 13:44:10 (Stamsund). BER and SNR look to be
back to normal after that.
- 1130 UTC Monday, 2007 Oct 15, week 42. T-Systems switched the entire Ku-band uplink to a redundant antenna.
The BER went down to almost nominal levels, and the signal level returned
gradually to near normal over the next few hours (some "noise" on
the SNR graph from Stamsund until about 18:00). The switch resulted in
small breaks being reported: on Hermes and Hydra at: at 11:31:03 UTC,
so the break at 11:30:33 (30-second TelliCast LOS timeout). Remarkably, no data was lost as a direct
result.
- 1300 UTC, Friday, Oct 12, week 41. Large signal strength drop noted
by V2.6 cards throughout Europe. Two short periods of normal strength
at around 1900-1940 on Friday 11th and around 0430-0530 on Saturday 12th.
- Afternoon, Thursday, 2007 Oct 11, week 41. The BER observed on the
backup PC started to increase, and had reached a sustained level of about
10^-3 (one in a thousand) by about 0200 on Saturday, Oct 13. I believe
this higher BER to be due to interfering signals from the satellite, but
that the lower signal strength reported above makes the effect of this interference
far worse.
- 1845 UTC, Sunday, 2007 Aug 19, week 33. EUMETCast strength glitch
seen throughout Europe - probably weather-related. Triggered a restart
on my older V2.3 card PC. There was a BER spike at 0545 UTC on Aug 19,
and an increased BER level from 1030 UTC onwards until 1030 UTC on August
20.
- 1100 UTC, Wednesday, Aug 08, week 32. A sudden increase in signal
level noted on SkyStar V2.6 cards across Europe, and a drop in BER to zero
on my own SkyStar V2.3 card. Something changed at the uplink or on the
HotBird-6 satellite. What?
- 1600 UTC, Monday, Aug 06, week 32. The higher BER noted on Saturday
Aug 04 seems to have reverted to its previous level. See: comparison
for the current graphs. Later: I heard from EUMETSAT that they found a performance problem in the Channel "EUMETSAT Data Channel
2", which also caused longer than usual delays on channel 2 and some other
channels. The problem was corrected yesterday around 16:30. No parameter change, just a reset of the server application.
- Saturday, Aug 04, week 31. At about 0230 UTC the missed packets and, perhaps,
the recovered packets, seems to become somewhat worse on the test PC
Hydra. This co-incided with the return of the IASI data. The
IASI files appear to be about the same size, though, so I would not expect
an increase. The same effect
was seen on the main PC from about 0330 UTC, although it does not take the IASI data (but it
does take Metop AVHRR data). See: comparison
for the actual graphs.
- 2006 UTC, Tuesday, Jul 31, week 31. TelliCast on Hermes
stopped. eToken transaction timed out. Event Viewer showed
"Smart Card Reader 'AKS ifdh 0' rejected IOCTL 0x310014: The semaphore
timeout period has expired." 2140 UTC logged out and
back in to Hermes, seemed to restart TelliCast OK. This stopped some
of the MRTG collection for a period.
- 1146-1149 UTC, Friday, Jul 20, week 29, EUMETCast drop-out triggered
TelliCast restarts on all three PCs. Drop-out was slightly longer on
the older V2.3 card on Stamsund, 1144-1150 UTC. NTP transients
triggered on Hermes and Hydra.
- 1811-1813 UTC, Tuesday, Jul 10, week 28. EUMETCast drop-out
triggered restart on Stamsund. Other PCs handled the loss OK.
- 1430 UTC, Friday. Jun 29, week 26. Seems that Hermes may not have
properly recovered after the Jun 21 crash, as the T-icon was intermittently
turning red, there were error messages about joining the DWDSAT channel, and
there was less DWDSAT data than expected (only about 100MB/day instead of
750MB/day). Couldn't stop and restart the TelliCast client (Web server
address not released), so rebooted Hermes. DWDSAT PID may have been
lost across the restart.
- 0900 UTC, Wednesday, Jun 27, week, 26. MSG-1 Rapid Scan data
restarted.
- 0900 UTC, Monday, Jun 25, week 26. MSG-1 Rapid Scan data stopped.
- 0317-0325 UTC, 1141-1146 UTC, Thursday, Jun 21, week 25. Rain-storms at Darmstadt
caused EUMETCast signal outage.
- 0915-0950 UTC, Wednesday, Jun 20, week 25. TelliCast fell over on
Hermes with an: "eToken transaction timed out, Critical dongle error
(eToken transaction timed out). Restarting child, EToken thread does not
terminate. So took the opportunity to install all the Microsoft Update
patches and update the anti-virus software to a new version.
- 1517-1524 UTC, Thursday, Jun 14, week 24. Rain-storm at Darmstadt
caused EUMETCast signal outage.
- 1400 UTC, Wednesday, Jun 13, week 24. MSG-1 rapid-scan data halted (seen on
Backup PC Stamsund).
- 1304 UTC, Wednesday, Jun 13, week 24. IASI data halted (seen on Test PC
Hydra).
- 1659-1703, 1708-1711, 1723-1735 UTC, Sunday, Jun 10, week 23.
Rain-storm at Darmstadt
caused EUMETCast signal outages.
- 1317-1335 UTC, Saturday, Jun 09, week 23. Rain-storm at Darmstadt
caused EUMETCast signal outage.
- 0615-0745 UTC, Tuesday, Jun 05, week 23. Power glitch at Darmstadt
took out everything except DWDSAT.
- 0955 UTC, Friday, Jun 01, week 22. MSG-1 rapid-scan data started
(seen on Backup PC Stamsund).
- 1926 UTC, Saturday, May 26, week 21. Signal outage/dropout 1925-1935
caused repeated restarts on Stamsund, two separate restarts on Hydra (at
1926 and 1929), and no effect on Hermes. Note that Hermes is fed via a
single splitter, and Hydra and Stamsund via two splitters and so will have a
lower signal strength.
- 0015 UTC, Saturday, May 26, week 21. Signal outage/dropout 0014-0019
caused restarts on all three PCs.
- 1300 UTC, Thursday, May 24, week 21. IASI data added to Test
PC. Increased data throughput, of course, plus increased missed data
packets and recovered data packets.
- 1000 UTC, Thursday, May 10, week 19. MSG-1 data dissemination halted.
- 1900 UTC, Tuesday, 2007 May 01, week 18. Considerable disruption to
EUMETCast services causing reduced data volumes and hence reduced missed FEC
data.
- 2007 Apr 11. MSG-2 replaced MSG-1 as the primary satellite.
- ~1240 UTC, Thursday, 2007 Feb 08, week 6. About 2dB dip in SNR lasting abut 30 minutes, centred on
1240.
- ~0930 UTC, Wednesday, 2007 Feb 07, week 6. SNR dip of about 1.5dB, worst at 0930, visible from about 0700 - 1400.
- ~2235 UTC, Sunday, 2007 Feb 04, week 5. TelliCast fell over on
Stamsund, taking the TelliCast logging (and hence MRTG) down on Narvik.
- 0820 UTC, Thursday, 2007 Feb 01, week 5. There was another glitch which caused a timekeeping step on the Test PC, and required an NTP restart on the main PC.
This seemed to coincide with a slight increase in signal quality and SNR as
recorded by the Test PC (0.5dB SNR and 2-3% quality).
- 07:50 UTC, Thursday, 2007 Feb 01, week 5. Test PC (Hydra) lost
EUMETCast connection for more than 90 seconds.
- 0424 UTC, Friday, 2007 Jan 19, week 3. EUMETCast drop-out triggered
restart event on Hermes. Hydra timekeeping affected.
- 1750-1820 UTC, Thursday, 2007 Jan 18, week 3. EUMETCast drop-out
on all three PCs. 19 red Server4PC icons visible on Stamsund 20 on Hydra..
- 0415 UTC, Monday, 2007 Jan 01, week 1. Sudden and deep drop of
EUMETCast signal strength all over Europe. Automated restart not
triggered (90s signal timeout).
- ~1520-1525 UTC, Sunday, 2006 Dec 31, week 52. PC Hydra time was
off, due to a drop in signal strength. Heavy rain and hail.
Suspect the card must have come near to loss of signal. but not quite.
The 90-second LoS TelliCast timeout was not triggered. Hermes
timekeeping also off. Restarted NTP on Hydra & Hermes.
- 0200 UTC, Friday, 2006 Dec 15, week 50. EUMETCast seemed to drop
out on Hermes and Hydra, but OK on Stamsund (older V2.3 card).
Required a manual restart on those two PCs. NTP consequently
affected.
Two more drops at 20:47 and 21:53, handled by automatic restart on
Hydra. Hermes didn't have automatic recovery and didn't re-lock, so
some data loss. Stamsund (V2.3 card) unaffected. Added automatic
restart to Hermes and Stamsund.
- 0200 UTC, Wednesday, 2006 Dec 13, week 50. EUMETCast seemed to drop
out on Hermes and Hydra, but OK on Stamsund (older V2.3 card). Hydra
also showed a drop from 10:00 to 11:00 (from about 9dB to 7.5dB). NTP
also affected.
- 1810 UTC, Sunday, 2006 Dec 03, week 48. Upped FSY file on Hermes to
RAMdisk 95MB, FSY size 99,000,000. Not tested with a reboot.
Later restored to 80MB, 83000000 for safety, that's what's working right
now, so leave it!
- ~22:30 UTC, 2006 Nov 29, Wednesday, week 48. Glitch on EUMETCast
caused PC Hermes and Hydra to stop collecting. Needed to restart by
selecting EUMETCast in Setup4PC. Stamsund (V2.3 card) recovered by
itself.
- 2345 UTC, 2006 Nov 28, Tuesday, week 48. Altered EUMETCast on
Hermes (a) to make the FSY file bigger (have 80MB RAMdisk allocated but file
size limit was 60,000,000 bytes) and (b) to specify a
tmp_directory=temp in the [parameters] section of the recv.ini file. I
noticed that the 28MB EPS global AVHRR files could take anything up to 30
seconds to build up.
- 0155 UTC,2006 Nov 27, Monday, week 48. Glitch on EUMETCast stopped
Hydra and Hermes reception. Hermes (V2.6D card) responded to a
right-click, select EUMETCast, but I decided to reboot Hydra as it was in
need of Windows XP security updates in any case.
- 1200 UTC, 2006 Nov 23, Thursday, week 47. Added BER/SNR/Quality
reporting on Hydra.
- 1043 UTC, 2006 Nov 22, Wednesday, week 47. Glitch on EUMETCast (?)
stopped Hydra working, but Hermes and Stamsund carried on. Some
segment loss on the 1030 HRIT.
- 0936 UTC, 2006 Nov 22, Wednesday, week 47. Added DWDSAT to Hermes.
- 0130 UTC, 2006 Nov19, Sunday, week 46. Timekeeping glitch on Hydra
suggests EUMETCast transient.
- 1440 UTC, 2006 Nov 17, Friday, week 46. Stamsund rebooted after
security updates.
- 1210 UTC, 2006 Nov 16, Thursday, week 46. Stamsund showed a period
of non-zero BER between two SNR glitches (12:10 and 13:40 UTC).
- 0700 UTC, 2006 Nov 08, Wednesday, week 45. Hydra rebooted to pick
up pending security updates.
- 2010 UTC, 2006 Nov 07, Tuesday, week 45. Missing segments on PCs
Hermes and Stamsund, and red satellite icon on Hydra. Could restart
satellite reception by right-clicking the Server4PC icon and selecting
"EUMETCast Hotbird 13E".
- 0140 UTC, 2006 Nov 02, Thursday, week 44. Seemed to be a
timekeeping glitch on both Hydra and Hermes, so I suspect a EUMETCast glitch
around this time. Another glitch at about 06:05.
- 1145 UTC, 2006 Oct 26, Thursday, week 43. BER on PC Stamsund
dropped back to zero. Nothing was changed at this end. Something
on the satellite or uplink? From about 16:00 UTC the SNR became
slightly higher. but slightly more variable, and there were some
corresponding slight increases in signal quality as well. Will need to
watch this carefully in case it's a developing fault this end. Just
realised that it was quite windy on Thursday afternoon. A
co-incidence?
- 0015 (clock), 2006 Oct 24, Tuesday, week 43. PC Stamsund recorded
very high peaks just after midnight local time. Some missing segments,
but only on Stamsund. Recorded BER (MRTG entries average/maximum for period
2315 UTC 33593/35865, 23:20 UTC 2503/35865, 23:25 UTC: 24/248). As
the signal strength remained normal, I can't explain the very high BER
(except perhaps by very high CPU load). TelliCast FSY file stayed the
same size (16.037MB). Nothing in the event
log. No missing MSG-2 data. MSG-1 missing 2315, ch. 1..11 seg 2,
ch. 12 seg 6 & 7. Raw data edited from MRTG log file: 1161645900 0 24 0 248,
1161645600 0 2503 0 35865, 1161645300 0 33593 0 35865. Left some
trailing BER values. This at least allows the rest of the more subtle
BER to be seen! Later - Arne van Belle reported a drastic drop in
signal at the same time, although no BER. So I restored the edited
entries to the MRTG plot, but with the values limited to 100.
- 1000 (clock), 2006 Oct 10, Tuesday week 41. EUMETCast reverted to
normal MSG-1 and MSG-2 operation, so the backup PC should show approximately
twice the throughput.
- 0910, 2006 Oct 10, Tuesday week 41. Stamsund spontaneously reboot
during a period of high network activity, so there is a small outage shown.
- 0500 - 0630, 2006 Oct 04, Wednesday, week 40. Local power
cut. On restoration of PCs, all were showing red (no signal), until I
unplugged the LNB form the splitter for a few seconds. Hermes now
showing lower strength than before (59%, 7.3dB) but figures recorded on
Stamsund seem OK.
- 0950, 2006 Oct 02, Monday, week 40. LNB re-adjusted (using the
second output via an extension cable). Reading on Stamsund 64% 8.5dB,
reading on Hermes now 8.8-9.1dB 66-68%.
- 1150, 2006 Sep 26, Tuesday, week 39. LNB connections taped, but he
knocked the LNB (?). Reading down on Stamsund from 8.8dB 66% to 7.6dB
61%. (Also readings on Hermes down from 8.8-9.0dB 66% to 7.5dB 60%.)
- 1030 - 1200, 2006 Sep 25, Monday, week 39. Reception interruption
due to antenna mounting, LNB and snow-shield upgrades. Some heavy rain
in the afternoon as well!
- 1145 - 1545, 2006 Sep 21, Thursday, week 38. Reception interruptions
due to people working near the antenna.
- 1023, 2006 Sep 18, Monday, week 38. Added DWDGDS to test PC
(Hydra). Don't know what the daily data throughput is expected to be.
- 1030, 2006 Sep 16, Saturday, week 37. Added GEONETCast (Americas-CH1)
to backup PC (Stamsund). As there were some large files (almost 32MB)
the FSY file increased from 16MB to 49MB.
- 1735, 2006 Sep 13, Wednesday, week 37. Backup PC and BER collection
(Stamsund) rebooted. Noted that XP was trying to run System Restore on
Z: (but failing), so need to add the registry entries to prevent this.
- ~0600 UTC, 2006 Sep 13, Wednesday, week 37. BER suddenly went to
zero (as measured on the backup PC), thus possibly ending the problem which
began on August 25.
- 1404, 2006 Sep 12, Tuesday, week 37. Noticed a momentary, red
TelliCast icon on the main PC (Hermes). Network ID now showing when
tested on the backup PC (Stamsund). Still non-zero BER on backup PC.
- 0715, 2006 Aug 26, Saturday, week 34. Rebooted test PC, and the
reported signal level increased to 54% and 6.8dB. There was no actual
change, though, so the indication is plain wrong. 07:30 rebooted
Stamsund to see if this non-zero BER would go away. It didn't.
- 0830-0856, 2006 Aug 25, Friday, week 34. HotBird-6 signal
loss. Both Stamsund and Hermes NTP became confused while the red
satellite icon was showing. Installed the security updates on Stamsund
and Hydra, and rebooted both. Last good file was time stamped 07:30:38
and first good file 07:56:45. Noted a non-zero BER on Stamsund after
the event, and the signal level was reported as low on Hydra (40%, 4.4dB),
dipping into the yellow.
- 0030-0300, 2006 Aug 13, Sunday, week 32. Data loss due to power
cut.
- 1000-1900, 2006 Aug 07, Monday, week 32. PC Stamsund rebuilt with Windows XP
Pro.
- 1456-1522, 2006 Aug 03, Thursday, week 31. PC Stamsund was down
for maintenance. Memory upgraded from 1 to 3GB, and thoroughly
cleaned! The SNR and BER figures will plot as constant during the
outage, which is not unreasonable.
- 2006 Jul 23, Sunday, week 29. Three brief dropouts during the period
19:00 - 20:30 UTC. Bad weather at the Usingen uplink station may have
been the cause.
- 2006 Jul 09, Sunday, week 27. Today showed the maximum throughput of
EPS test data (graph
here). During the 24 hours up to 0600 UTC Sunday morning, the
measured throughput on the DVB (as found on the TelliCast Statistics page)
was 38.7GB, and 40.0 GB of EPS data files were received. There was
also 11.0GB of Data Channel 1/2/3 etc. data throughput, so the total data
received must have been at least 51GB (40.0+11.0). As the TelliCast
system can include data compression, this may account for more data being
received (51GB) than the throughput shows (38.7GB).
The maximum 1-day average as shown by MRTG was 502kB/s, which is 41.3
GB/day, and this would have been the throughput for Sunday, July 09.
During Sunday (UTC+1), 38.4GB of EPS data files were received, so the actual
data received (49.4GB) again exceeds the throughput (41.3GB). Because
of the averaging in MRTG, it's possible that the actual 1-day value was
higher, so this may be a little misleading.
- 1600, 2006 Jul 05, Wednesday, week 27. Rain prior to a thunderstorm
caused a signal drop-out between about 1500 and 1530 UTC, and messed up NTP
timekeeping on Hermes and Hydra.
Stamsund was OK. All PCs retained signal lock without any
intervention.
- 2006 July 03, Monday week 27. Saw one peak on the EPS test PC of
average 5 minute rate 911.2kB/s, and a TelliCast HTML Shell peak of
20.3Mb/s. Maximum 5-minute peak on Tuesday was 988.5kB/s.
- 2006 Jul 02, Sunday, week 26. Some short, sharp thunderstorms this
morning produced signal drops and BER increases, but no missing segments.
However, a storm at 1500 clock resulted in a signal loss from about 14:45
to 1458, with the indicator in the red. Gradual recovery from 1500
clock onwards. Took the opportunity to apply security updates to
Stamsund.
- 0800 clock, 2006 Jun 30, Friday, week 26. High rate data tests
today - so far highest seen is 10.6Mb/s (from TelliCast shell overview).
- 1630 clock, 2006 Jun 29, Thursday, week 26. Since 1800 clock
yesterday, the test PC hasn't missed a single LRIT or HRIT segment, just one
DCP/WMO message. Looks as if the USB box is coping OK, as EPS/AVHRR
data has been flowing. But there have been some EPS/AVHRR files
noticeable smaller than most, so perhaps it is the EPS/AVHRR data which is
suffering? Closer inspection showed that all files received were the
same size as those on Arne van Belle's system, but that for the first couple
of hours after starting yesterday, some of the AVHRR files were simply
missing. From 1542 to 1745 UTC, June 28, Arne's system saw 45
EPS/AVHRR files, the USB system saw only 32 files. All but one of the
missing files was before I restricted the data to just channel EPS-10, so probably
caused simply by data overload.. Restored test PC to PCI card and full EPS data flow.
- 1800 clock, 2006 Jun 28, Wednesday, week 26. When AVHRR EPS data
started flowing, missing segments started to appear (mostly but not entirely
in the faster HRIT data), so I commented out all EPS channels except
the AVHRR data (EPS-10), to see how well the system could them cope.
This simulates the load from a user taking MSG-1, AVHRR regional from
NOAA-17/18 and AVHRR global from METOP.
- 1030 - 1100 clock, 2006 Jun 28, Wednesday, week 26. Removed DVB PCI
card from Hydra (the test PC) and replaced with older USB box from John
Tellick. Needed to add USB driver, and force correct IP address.
This is to test if the USB box (and its 12Mb/s maximum connection) can handle the
data from EPS as well as the normal MSG-1 and AVHRR data, without disruption
of MSG-1 and AVHRR reception. The peak rate seen so far through the
USB box has been 7.2Mb/s, monitored on the TelliCast HTML shell, and no
missing segments. Later data rate peaks of up 9.8Mb/s did result in
missing segments, though.
- 1800 & 2300 UTC, 2006 Jun 25, Sunday, week 25. Thunderstorms in
Germany cause signal outage. PCs automatically recovered (although NTP
timekeeping was affected).
- 2200, 2006 Jun 18, Sunday, week 24. Some sort of TelliCast glitch again.
A few missing segments. Upset NTP timekeeping on both Hermes and Hydra.
- ~1100, 2006 Jun 17, Saturday, week 24. Signal loss and
re-acquisition on Hermes.
- 2000-2400, 2006 May 27, Saturday, week 21. Backup PC rebooted a
couple of times to convert C: from FAT to NTFS.
- 2006 May 19 - 2006 May 22, Friday - Monday, week 20-21. Data collection
stopped due to main PC lockup. Data from backup PC was substituted.
-
1000 clock, 2006 May 13, Saturday, week 19. Added splitter in the feed to
Stamsund so that it is now at least 6dB down on full signal. Very
difficult to discern any change in quality or SNR. 3rd feed now available
for a test PC (Hydra) with SkyStar V2.6D. Hydra statistics started Monday May 15, but will be
intermittent.
-
0941 clock, 2006 May 13, Saturday, week 19. EUMETCast down from 0841 -
0908
UTC.
-
0700 clock, 2006 May 12, Friday, week 19. PC Stamsund rebooted for security
update.
-
1800 clock, 2006 May 02, Tuesday, week 17. Updated TelliCast client on Stamsund to
V2.4.4 B.
I use MRTG to
monitor my networks. I suggest that you first set up MRTG to show the network
throughput on your system, using the instructions on the MRTG Web pages. 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.
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.
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 the
current SDK does not work, so there is an earlier copy here in B2satus.zip. You will need to copy this program to somewhere on the
"path", such as C:\Windows\System32\,
so that the command can be executed from any location. If you aren't sure
what your "path" is, enter PATH at the
command prompt, and the current path will be shown. 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 two
separate scripts - one to get the Quality and SNR, the other to get the
BER. 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";
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";
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. I did add the Timezone
option, to make sure the plots are in UTC (which is 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
XSize[_]: 500
Timezone[_]: GMT
#---------------------------------------------------------------
# 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:
Legend1[SkyStar_Stamsund_BER]:
Legend2[SkyStar_Stamsund_BER]: Bit Error Rate (BER) in parts per million
PageTop[SkyStar_Stamsund_BER]: <H1>SkyStar2 Bit Error Rate (BER) snapshots - Stamsund</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, unknaszero
YLegend[SkyStar_Stamsund_SNR]: Quality, SNR x10
ShortLegend[SkyStar_Stamsund_SNR]: .
LegendI[SkyStar_Stamsund_SNR]: Quality %:
LegendO[SkyStar_Stamsund_SNR]: 10 * SNR dB:
Legend1[SkyStar_Stamsund_SNR]: Signal Quality (0..120%)
Legend2[SkyStar_Stamsund_SNR]: SNR * 10 (0..12.0dB)
PageTop[SkyStar_Stamsund_SNR]: <H1>SkyStar2 Quality & SNR snapshots - Stamsund</H1>
#---------------------------------------------------------------
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.
Fred van den Bosch posted the following information in the MSG-1
Yahoo 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 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. 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:
#---------------------------------------------------------------
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>
#---------------------------------------------------------------
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
2007 Jan 24