DVB-S2 tests
Home Page Up Ayecka SR1 TelliCast software RAMdisk Next steps eToken Help! DVB-S2 tests SR1 updates Monitoring with MRTG

 

DVB-S2 receiver evaluation notes

GEO members will be aware that EUMETCast is migrating from DVB-S to DVB-S2 at the end of 2014, and that existing receiver hardware will need to be replaced.  Latest EUMETSAT information is here.  EUMETSAT have tested a number of receiver options, and the only ones found suitable so far have been listed on their Web site.  As these receivers operate differently to the existing SkyStar PCI cards and DVB World USB boxes, GEO is in the process of testing these receivers using the existing EUMETCast data stream to understand the system architecture differences, and to be able to make recommendations to members in due course about suitable receivers and how to get the best from them.  So far, we have procured two Ayecka SR1 receivers which are being tested by various GEO members, and it tests are also in progress with the Novra S300E.  Both receivers have been in daily use for the new DVB-S2 service for some months without major issues.

Of course, other qualified receivers may become available before the end of 2014 so it is possible that the final recommendations may differ from the findings during our initial tests.  TBS offers both a USB box (TBS5925) and two PCIe cards (TBS6925 and TBS6983), but the software for the USB box has proven problematic with some testers, and one PCIe card has proven incompatible with some motherboards.  Some notes on these can be found later in this document.  A further PCI card from Omicom is known about, but tests show it to be very sensitive to RF signal level.

Please do not purchase any hardware, other than that approved by EUMETSAT, at the moment!  In particular, low-cost USB boxes or cards marked "DVB-S2" may well not be suitable for EUMETCast as they may lack the advanced functions required.

 

Update - EUMETCast User Forum - talks & video

In September 2014 EUMETSAT hosted a EUMETCast User Forum, at which a number of presentations were made.  You can see the video of my talk here.

Update - Ayecka threshold settings for best performance

With the recent solar outage in October 2014 there was a chance to evaluate the best settings for link margin to get the best from this receiver.  If the receiver is set for Basic Service reception alone, EUMETSAT are recommending that the link margin be set to Lower: -0.6 dB, upper -0.3 dB, i.e. a 0.3 dB difference.  These allow the maximum amount of data through based on EUMETSAT's own measurements.  As there may be some variation in receiver performance, and as I like to allow a little margin, I have now set my receivers to -0.5/-0.3 dB.  Use the System Menu (option 4), RX Link Margin Thresholds (option G) to check or set these items.

If you are using the High Volume Service as well, EUMETSAT currently recommend the thresholds be set to +0.5/+0.6 dB, i.e. a 0.1 dB difference, although this will also apply to the Basic Service as well thus causing it to stop at a higher margin than is optimum.  Selection of different thresholds for the two service types is planned a future release of the SR1 software.

Update - Ayecka MODCOD selection

If you have release 250 or later of the SR1 software as supplied with the GEO Christmas offer, there is a new option in the System menu (option 4) called MODCODS Filter (option H), which allows selection of which MODCODs the device will process.  This is a bit-mask, and the settings for the EUMETCast services are:

Service required MODCOD MODCOD mask Displays as
Basic service alone 8PSK3/5 1000 0x00001000
High Volume Service alone 16APSK2/3 40000 0x00040000
Both services together 8PSK3/5
16APSK2/3
41000 0x00041000

Information about SR1 software updates is here.  The current software is version 243, so the information above is for beta testers.

What is MODCOD?  MODCOD stands for MODulation and CODIng.  It refers to the density of data packed onto the satellite broadcast signal, and to the strength of error protection coding used.  You can find more information in Wikipedia.

Update - using the Ayecka SR1 on a single port

Recent tests have shown that the SR1 works very well when using a single port connection to the PC.  In this configuration both the EUMETCast data and any management commands and responses pass over a single network cable.  This is the configuration produced by the EUMETSAT configuration utility.  You simply need to set the IP address of your network adapter to an address in the same subnet as the Ayecka Manager port (192.168.10.x from the EUMETCast configuration.  You could use an address like 192.168.10.150, and the subnet mask should be 255.255.255.0.  The subnet mask is automatically set when using Windows.  There are instructions here, but you should not set the Default gateway or DNS server addresses.  I also disable everything other than Internet Protocol Version 4 (TCP/IPv4) for the connection.

Note that some LAN adapters will not correctly negotiate the 100 Mbps speed setting used by the Management port, and you may have to set the speed manually.  This is well described here, and you should select 100 Mbps Full Duplex.

Introduction

For information derived from the actual signals which started in June 2014, please see here.

During November 2013 I had the opportunity to test out a Ayecka SR1 DVB-S2 receiver (and later, a Novra S300 receiver).  This receiver differs from those we have used in the past, which have typically been PCI cards to fit into a desktop PC, or USB boxes plugging into a USB 2.0 hi-speed port on a laptop or desktop PC.  Both the Ayecka SR1 and the Novra S300E are a network devices which can be connected to a network port on a PC, delivering EUMETCast packets over the LAN.  In fact, existing PCI/PCIe cards or USB boxes also deliver their data over the network, but the network drivers which are supplied with the units simulate a network interface inside the PC rather than using a physical network interface like these IP receivers do.  

You may need a second network card ..

.. or you may try a very simple and high-performance LAN-to-USB adapter.  Initially, I was dubious about the potential performance of one of these devices, but when I bought one and tried it connected to a test PC (where there was no room for a second network card) I found it had even better performance than the LAN connection built into the PC!  This was just because the device had better drivers, ones which handled the EUMETCast DVB-S2 signal better, so if you are looking for a second LAN card, the inexpensive Edimax EU-4208 USB 2.0 to 10/100Mbps Ethernet Adapter may be a suitable solution.  But please do remember to set the power settings for your PC not to turn off USB devices!

  Edimax EU-4208 USB 2.0 to 10/100Mbps Ethernet Adapter, on Amazon at GBP 12.
 

The Ayecka SR1 box

Here are some pictures of the Ayecka SR1 from the brochure, although my unit was black rather than white.

If you want to skip the details of the tests, there is an FAQ here and a set of recommendations here.

 
EUMETSAT Setup Guide

After this document was written, EUMETSAT published a EUMETCast Setup Guide to the SR1 which I recommend you read!  They also publish an automated configuration utility, and you will find the download address in the guide.  (I would give the address here but it has changed between versions of the guide).  Please note that the Ayecka Web interface mentioned in section 5 of the guide is not needed by most users, is rather complicated, and may be safely omitted.
 

SR1 Console

Here's a screenshot from a program written by Space-Band - a monitoring console for the SR1 written in Java so it should be supported on multiple operating systems.  Here I'm running it on Windows-8/64.  You can download the program here.  Please note that this is not part of the Ayecka Web Interface mentioned in the EUMETSAT Setup Guide.

Ayecka SR1 Controller screen-shot

(Your software and hardware versions may be different - this is not an error.)
 

Test notes

Talking to the SR1 to manage it

My first test was to be able to talk to the SR1.  For this test, I used the USB interface as it required no reconfiguration of the network.  The company point to 3rd-party USB drivers which are required to connect to the serial-over-USB interface.  I wanted to test whether these drivers would work under Windows 8.1 (which requires signed drivers), as that version of the OS most likely to be in use when the DVB-S2 transmissions start.  In fact, there was no problem.  I ran the driver installer, configured the COM port to be at 115,200 baud, and connected a USB lead (not supplied) from the PC to the SR1 and got communication right away.  Press '0' (zero) to start the menu system.  One person has reported that the Ayecka box must be connected to the PC for the COM port driver installation to work.

Network addresses

Jumping ahead a little here, but once the device has been configured (perhaps with the EUMETSAT software, see later), there is no need to maintain a USB connection at all.  You can configure the two Ethernet ports to be on separate LANs, so that in my case, so example, the Traffic port is set to an address on a new private "Traffic" LAN (192.168.10.x), with the SR1 being set to 192.168.10.102), and the Management port is set to a free address on your existing network.  In my case, this was 192.168.0.195, which was outside my router's DHCP range.

Getting the SR1 set for EUMETCast

I had an existing EUMETCast feed (already split from one LNB) available, so I split EUMETCast RF connection once again down into two in preparation for testing the Ayecka SR1 receiver.  I used a splitter with a DC isolator path (fed to the SR1-) and with a DC isolator in the input feed to the splitter.  This was so that my main receiving PC would have full control over polarisation and high/low switching. I configured the SR1 RX for 1377 MHz (menu 1.1.1.1) and it picked up the signal immediately.

Using the SR1 to receive EUMETCast instead of a SkyStar PCI card

The available test PC was 1 GB 1.9 GHz Windows XP box, which had been receiving EUMETCast data but not processing it.  The streams were those typically used by amateurs, full MSG-1/2/3 data including foreign satellite data, full Metop-A/B AVHRR data, and full EARS AVHRR data.

As all EUMETCast data can be dumped on the network from the SR1, my first test was on an isolated network rather than my house LAN.  This involved changing the main network connection to the test PC from direct LAN connection to a Wi-Fi connection.  I added Netgear Wi-Fi dongle to the PC and assigned it a fixed IP address on my existing house LAN.  Once that was working, I added monitoring of the data throughput to my MRTG statistics.  Having noted the existing configuration of the Ethernet card, I then changed it to match the sub-net used by the SR1 box, and chose an address on the same subnet.  For simplicity I chose and address one more than that of the SR1 box by default (192.168.10.102).  That led to a LAN card configuration:

Address: 192.168.10.103
Subnet mask: 255.255.255.0
Gateway blank
DNS: blank

I then connected the PC's LAN port to "Traffic" port on SR1 using a standard Ethernet cable, and I could ping then SR1 on its LAN address of 192.168.10.102.  I did note that when running the Windows 4-burst PING, that the first test did not respond, but the remaining three did, and I've seen that behaviour subsequently with other PCs.  Likely it's the SR1 box learning the physical addresses of the networking cards making the PING request.

Having established basic communication, I then configured SR1 to pass the PIDs used by EUMETCast: 100 300 301 302 500 509 510 and it then showed data flowing (from the management menu 5.1).  However, testing with TelliCast on the PC did not get data, but I noticed that on the network menu (3.D) that the LAN multicast was set to Off, so that any EUMETCast data being received was not being sent to the Traffic LAN port!  I set this to On, and data flowed as required.

On the PC, the only change need in the EUMETCast configuration was in the [parameters] section of the recv.ini file, where I changed the interface_address to 192.168.10.103 - i.e. my PC's network card address.

Original:

[parameters]
interface_address=192.168.238.238

Updated:

[parameters]
# interface_address=192.168.238.238
interface_address=192.168.10.103

Finally I stopped the SkyStar reception by stopping the server process.

Observed performance

Here are the very first performance plots.  I note that the CPU usage is rather higher with the SR1 in use - the average is approximately 35% rather than 24%.  The missed packet count is very much higher, and although quite a lot of the missed packets were recovered, the packet loss was unacceptable.

Initially, I wondered whether the higher CPU and missed packet rate may have been my fault, but it was not.  From 11:20 to 13:40 I had kept the RF feed into the SkyStar card, which could have resulted in an unnecessarily high processing load.  At 13:50 I restarted TelliCast so as to reset the throughput and missed packet count.  Even after the restart, the CPU usage is still higher, and the missed & recovered packet counts continued at the unacceptably high level.

As expected, the throughput shown for the LAN interface from the SR1 after the change is approximately the same as that from the DVB PCI card before the change.  This suggests that I do have most of the PIDs correct!

The small amount of Wi-Fi traffic is from the MRTG statistics reporting and NTP activity.

Performance graphs

When the changes were reverted, the missed packet rate returned to its former low level, and the CPU usage dropped back to normal as well.

I later learnt that Windows XP may has networking limitations, which may prevent it working properly with a IP receiver such as the SR1.  As XP is no longer supported by Microsoft, I would strongly advise against its use with the Ayecka SR1.

Networking concerns

There are some issues I don't fully understand, and which will require further testing.  Perhaps someone with more networking expertise than I have can answer the questions?

  • I configured the PC with a new Wi-Fi interface because I didn't want the EUMETCast data flooding my existing LAN.  I keep careful note of the statistics on my LAN as one way of detecting issues or problems, and if all PCs (and Wi-Fi connected devices) start reporting over 1 MB/s then any errors will be completely masked.  What I don't know is whether a typical LAN or Wi-Fi card will report multicast packets on the LAN, even if that PC doesn't process them.
  • It raises the question of multiple networks running over the same physical LAN.  Suppose I made the LAN card have an address both on my house LAN (192.168.0.x), and on the SR1 LAN (192.168.10.x)....
  • Would a Netgear WRN2000 v2 Wi-Fi router successfully two devices on the 192.168.10.x LAN, even though it was actually running as an access point on the 192.168.0.x LAN?  I don't know whether the four LAN ports on that devices are switches or something more complex.
  • Would a Netgear GS508 switch pass packets from the 192.168.10.x LAN to the 192.168.0.x LAN?  As that device is unmanaged and address independent, I hope it would.
  • I suspect that MRTG would not be able to access the two LAN addresses on a multi-homed NIC, separating out the traffic.  Perhaps that doesn't matter.

.. and a very important question ...

  • If heavy LAN traffic is mixed with the EUMETCast traffic, will there be an increased chance of missed packets and data loss?  My feeling is that there must be, which does not bode well for a single physical LAN solution...

Obviously a lot of these things can simply be tested by experiment, but I do like to have a little more idea of the expected outcome before perhaps losing my home LAN!

Further tests by David Simmons have shown that feeding EUMETCast over one's home LAN may likely be unacceptable.  He reports:

"Earlier in the day I had the SR1 plug-in my main network and several computers using the data but as it broadcasts data it cause overload and things like VoIP phones on things similar ceased to function reliably."

I conclude that a separate network for EUMETCast traffic from the SR1 to the TelliCast PC will be a requirement for satisfactory operation.  For a portable PC, likely the main connection will be via Wi-Fi and the EUMETCast connection via a wired LAN connection.  For a desktop PC fitting a second network card may be essential.
 

Update 1 - tests with a separate EUMETCast LAN

As the single-core PC was producing so many errors that I abandoned that test, and have now added extra network cards to a couple of PCs and changed them from using a DVB World and a Dexatek box (direct RF feed) to using the SR1 over the LAN.  The traffic port of the SR1 was connected to an old 4-port 100 Mb/s hub, and the two PCs take their data feeds from two of the hub ports.  All that was required with EUMETCast was to reconfigure the "interface_address=" line in recv.ini.  Both PCs appear to be working well, and I will add some graphs and comments shortly.

[I did have issues with the Windows 8.1 PC which seemed to loose settings relating to the eToken driver, and the eToken Properties program could not see the device.  A re-installation of the eToken software resolved that issue.]

I added management over the house LAN by adding a second Ethernet cable and setting the Management Port IP address to a spare one for the LAN.  Access through telnet and the PuTTY program was straight-forward, although slower than the USB interface.  One strange feature of the Telnet interface is that the first time you try and connect it immediately disconnects you!  On the second attempt, you see the username, and are prompted to enter the password you have defined over the USB connection.

Here is the network configuration to explain the data flows:

House LAN - Netgear GS508 - 8-port 100 Mb/s 1 Gb/s switch
     ^      ^      ^     
|| || ||
|| || ||
v v v
     Management port 
192.168.0.195
 
Built-in LAN port
192.168.0.x
Built-in LAN port
192.168.0.x 
SR1 DVB-S2
receiver
PC Alta
Windows 7/64
PC Stamsund
 Windows 8.1/64 
 
USB port   192.168.10.102
Traffic port
192.168.10.104 
 Second LAN card 
192.168.10.103 
 Second LAN card 
 Spare port for 
another PC
v ^ ^ ^
v ^ ^ ^
v ^ ^ ^
Traffic LAN - Netgear DS 104 4-port hub running at 100 Mb/s
Later replaced with Netgear GS605 5-port 1 Gb/s Ethernet switch

Data from the house LAN is bidirectional to the SR1 receiver, and to the other house PCs, of course.  Data from the SR1 over its "Traffic" port consists only of outgoing broadcast UDP data, and is sent to all PCs on the Traffic LAN.
 

Performance - PC Stamsund

This is the Windows 8.1 PC as it was changed from using a Dexatek USB box to a LAN feed from the SR1 receiver.  This involved some down time as the PC had to be physically moved to allow a network card to be added, but the subsequent reboot did free some memory.  It takes a rather limited set of data - just MSG-2 and MSG-3, but it is also running Plane Plotter (over TCP from a Raspberry Pi receiver), and Ship Plotter (from a MarineGadget Radar receiver working over serial-over-USB.

As with the single-core XP system, the CPU usage is higher with the LAN (~ 5%) than with the DVB USB box (~2.5%).  What does that tell us?  Whilst this is a doubling of the CPU, because that PC has a modern Intel i5-3330 processor with 8 GB memory the net effect is not too harmful.  The reported throughput with the Dexatek box is much higher, as that software reports the total data flow rather than just the data flow resulting from recv-channels.ini configuration with the TelliCast software.  The actual data flow is the same.  There were some missed packets, and at least some of those could have been caused by configuration changes during the experiments.  That PC has never been completely lossless - but there have been periods of up to two weeks without loss in the past, so it will take some time to try and determine whether the losses are now any better or any worse.

PC Stamsund performance over the change
 

Performance PC Alta

This PC is a generation older than PC Stamsund, running Windows 7 SP1 on a Intel i5-760 with 8 GB memory, but it takes a greater amount of data (MSG-2/MSG-3/EARS-AVHRR/Metop A&B AVHRR), and usually has even fewer packet losses.  It also runs Plane Plotter (from a Beast receiver over serial-over-USB) and runs mail and Usenet access, together with the occasional big download.

The graphs here tell a similar story - with a lesser CPU increase when switching from DVB World USB box to EUMETCast LAN (and a later test showed the CPU to be unaffected by the IP running or not on the DVB World software), and missed packets around the times of some of the changes.  In the last 7 hours (07:00 to 14:00) there have been no further missed packets.

 

Update 2 - an unexplained burst of losses

On the evening of Sunday Nov-18 I returned to the lab to find that the TelliCast icon on PC Stamsund was glowing red, indicating loss of signal.  I also noted that there had been continuous missed packets on both PCs fed from the SR1 since 20:15, with PC Alta having all but 10 packets recovered, but PC Stamsund having a steadily increasing values of both missed somewhat less recovered.  In the 24 hours up to 07:00 on Nov 18, PC Alta had missed 235 and recovered 225, PC Stamsund had missed 287 and recovered 140.  Although the signal was a little down, it was not low enough to cause these losses and had recovered to its normal value by midnight, and the main PC with its less sensitive SkyStar PCI card showed no losses at all - see the graphs below.

Disconnecting and reconnecting the network cable to PC Stamsund at both ends just after 21:00 seemed to restore the connectivity, but it failed again on Stamsund a few minutes later.  I therefore changed the network cable for another, but physical inspection of the cable showed no obvious problem.  These cables are likely made to minimum cost, so I won't rule out the cable just in case it was faulty.  I have also checked that the network card in PC Stamsund is not set to be powered down for power-saving.  The two network cards happen to be the same - TP Link TG-3269.  PC Alta is Win-7 SP2/64 and PC Stamsund is Win-8.1/64.

The next morning, the losses had continued.  Looking at the available statistics on the SR1 box showed no obvious errors, so I took the decision to reboot both the SR1 and the four port hub to see what happened.  Need to keep an eye on this to see whether it was a once-off occurrence, or something which will happen every so many hours of operation.  Since replacing the network cable between the 4-port hub and PC Stamsund there has been no re-occurrence of the problem, and the suppliers don't think it was a problem in the SR1.

There have since been at least two other reports of similar steady missed and recovered packets, and in two cases these were cured by updating the driver software for the new Ethernet card.  Although Windows supplied a driver automatically, that found on the manufacturer's Web site in one case, and via the DriverMax program in another, provided better results than the default Windows one.
 

Update 3 - adding SNMP & using MRTG to monitor

My first attempts at using the SNMP network management facilities built into the SR1 box failed, as it seems to have limited support for SNMP and did not respond to my SNMP walking program (GetIF V2.3.1).  This is fixed in software 1.05b243.  Possibly an alternative MIB browser such as that from iReasoning might be OK.  Ayecka supplied the details required (the object IDs) which allowed me to use MRTG to monitor the SNR and link margin.  Note that you will need the Management Default Gateway set to the IP address of your router, for SNMP requests from outside your LAN to get a response.  This was required for the EUMETSAT tests from June 2014 onwards.  You can see the comparison with other receivers here.  There is information on other EUMETCast monitoring with MRTG here.

Link margin for the Basic Service is shown in green, and that for the High Volume Service in blue.

There was still a problem in that when MRTG was configured in its normal way, where it makes the minimum of SNMP requests to the device, only the first retrieved value was valid, and this mean that rather than presenting these two values on the same graph I had to use two separate graphs.  The same problem meant that the green "bar" graph had to be used rather than my preferred "line" graph.  Here is the complete MRTG file I used, which you can copy and paste as a plain text file (i.e. go via Notepad!).  Note that you will need to alter the IP address of the Management Port of the SR1 (192.168.0.195 in the example below) to that of the box on your own system.  That will be the same IP address as you use to Telnet to the box for remote control.

Note: where a PageTop entry stretches over multiple lines, such as in the [SR1-Traffic] target below, each line after the first must be start with a space character, as the first line which does not start with a space will terminate the PageTop entry.

2014-Jul-04:  Two updates, to give the Traffic data in bits rather than bytes (as it's how EUMETSAT specify the throughput of the new service), and to record the rate of bad frames and bad packets as seen by the SR1, i.e. before any TelliCast error correction takes place.

2014-Jul-10: The bulk of the MRTG information has been moved here.

I have also given the code to obtain the TelliCast losses (both the classic "missed/recovered", and the new "lost" packets graphs).  For these graphs, you will need a program TelliCastStats.exe and a Perl script which may be obtained here.

Here is the extra code for collecting TelliCast statistics.  

I've recently added the MRTG configuration commands to extract the traffic details as well.  Thanks to research by Allan Gibbs, I have since discovered that two of the issues addressed above can be overcome by some MRTG configuration options.  First, the inability of the SR1 to respond to multiple SNMP requests (in software prior to SR1c_v1.05b239) can be overcome by adding the directive:

SingleRequest: Yes

in the common configuration section for the MRTG run.  This forces MRTG to make each SNMP request individually rather than as a bulk request, and reduces some of the (otherwise harmless) messages in the MRTG job command-line window.  This also results in SNMP getting a system uptime response from the SR1, which is useful (it seems it may reset itself possibly without packet loss?), but these uptime messages also result in further harmless errors begin reported in the command window.  If these still bother you, they can be suppressed with the directive:

NoMib2: Yes

There are two other settings in the configuration above which were new to me, but have been derived as a result of discussions with the early adopters:

  • In the SNR settings, it is convenient to limit the maximum displayed and recorded value to 18.0 dB.  This is likely to be the maximum value seen in a non-professional installation.  By setting the Y-axis to have 6 divisions rather then the usual 4, each division is 3 dB which may make estimation of intermediate values easier.  This is likely to be more important on the DVB-S2 service than the existing DVB-S service.  The maximum value seen so far on the DVB-S service is just around 16.5 dB.  The configuration settings are:
     
    AbsMax[SR1-levels]: 180
    MaxBytes[SR1-levels]: 180
    YTics[SR1-levels]: 6

     
  • For the same reasons, with a maximum value seen of just under 10.0 dB for Link Margin, a scale of 12.0 dB in 6 divisions appears appropriate and provides a little margin, so possibly 5 divisions spanning a 10.0 dB range might be even  better.
     
    AbsMax[SR1-link-margin]: 120
    MaxBytes[SR1-link-margin]: 120
    YTics[SR1-link-margin]: 6

Using SNMP remotely - 2014-May-17

In preparation for the EUMETSAT trials from June 2014, I have been playing with using SNMP remotely across the Internet, which is something I have not needed to do before.  I started by testing SNMP from a Windows PC, but if you read until the end of this section you may want to go for the SR1 right away. To test, I used the free Windows program snmpget, and wrote a simple command-line script to get an SNMP variable from a local PC:

snmpget -q -r:192.168.0.1 -o:.1.3.6.1.2.1.1.1.0

This returns a string containing the name of the operating system, at least it does on that particular PC.  Note that the PC must already be running SNMP for this to work, if not, see this page for enabling SNMP, and allowing the community "public" read-only access from any host in the network.  This string is the sysDescr variable under "system".

Hardware: Intel64 Family 6 Model 30 Stepping 5 AT/AT COMPATIBLE - Software: Windows Version 6.1 (Build 7601 Multiprocessor Free)

The next step was to get the same command working from a completely different network.  You may be able to test using the same network, but I wanted to be completely sure so I ended up installing an SNMP browser application on my Android phone.  I needed to know what my Internet WAN address was, and this site will tell you.  For sake of example, suppose your Internet WAN address is 100.100.100.100.  Of course, you may also be running a DuckDNS.org or similar service to have a fixed name instead of a changeable dynamic IP address, but that isn't required here (unless your IP changes very often).  Once you know the WAN IP address, you can ether use a command line, or the Android application.

snmpget -q -r:100.100.100.100 -o:.1.3.6.1.2.1.1.1.0

If you are using a dynamic DNS service, you could also use your host name rather than the IP address:

snmpget -q -r:example.dunckdns.org -o:.1.3.6.1.2.1.1.1.0

For the Android application, enter the IP/host as the WAN address, i.e.  100.100.100.100  or  example.duckdns.org.

On my first attempt, both snmpget and the Android application failed for me!  There were four things which needed to be fixed:

  1. The first realisation was that for a UDP packet coming in from the Internet, the router needs to be told where to send that packet.  So I needed to set up a port forward in my router, so that UDP packets coming in on port 161 would be sent to the PC on 192.168.0.1.  A good site for information about this is portforward.com.
     
  2. The next problem I discovered was that Windows, by default, does not allow SNMP queries from other than the local subnet.  You may need to go into the Windows firewall settings, Advanced, Inbound rules, look for the SNMP entry, and on the Scope tab, allow any IP address in the Remote section.  On the Advanced tab, ensure that both Private and Public are checked.  Still not working, though.
     
  3. I then recalled that VirginMedia (in common with some other ISPs including BT) will use SNMP themselves to manage network components, including my cable modem.  I could get round this by telling the SNMP monitoring program to send packets on a port other than 161 (I selected port 9746), and make the port forwarding in my router send packets intended for port 9746, to port 161 on the PC.  A simple change in the port forwarding settings for the router.
    Success, at last!

So now I hoped that replacing the forwarding address in my router to point at the Ayecka SR1 Management IP (192.168.0.194) instead of the PC (192.168.0.1), would allow probing of a similar variable on the Ayecka box.  This worked on the LAN:

snmpget -q -r:192.168.0.194 -o:.1.3.6.1.2.1.1.1

but the equivalent command over the WAN:

snmpget -q -r:100.100.100.100 -p:9746 -o:.1.3.6.1.2.1.1.1

did not work, nor did the Android SNMP browser which also allowed the source port to be set to 9746.  However, with help from Space-Band I discovered that I had missed a key step.

  1. I had not set the Management Router address when configuring my SR1 as I did not see any need when I first set up the SR1.  In the menu 3.7 option, I entered the IP address of my router, and remote SNMP then worked right away.  However, I did note that sometimes a couple of tries were required to get the SNMP response back to the Android device, but as it's UDP (not guaranteed delivery) over the Internet, perhaps that's not surprising.  My thanks to Baruch Kagan of Ayecka for spotting that!
      

Update 4 - EUMETSAT comments (2013-Nov-04)

Interesting report.

It reflects our experience.  A proper networking setup is essential to loss-free reception.

Professional users should use dedicated multicast networks or directly links to the reception PC on dedicated network cards.

We also experienced some problems with the 1GB interface.  Using the 100 base port resolved this.

Some more features of the SR1 which might be useful:

  • If multicast is dumped on the network, the receiver end does not have to be on the same subnet.  The SR1 interface can even be left open (0.0.0.0).  Only for managing the device the subnet must be the same.
     
  • You can connect both port (data and management) and retrieve the multicast from either interface.
     
  • You can use the built-in switch to "extend" your single network port on the PC, i.e. connect PC to data port (GB) and connect to mgmt port to your home network.  Multicast=on on data port, multicast=off on mgmt port.  This way you can use your home network and receive multicast without a second network card.  There should not be any multicast traffic congestion on the data interface since the bottleneck will be the mgmt interface.

And we have developed an application (.NET based) to program the SR1 over the USB interface. It uses an ASCII control file.

(Copied from e-mail with permission).
 

Update 5 - powering the LNB from the SR1

Requirements:

  • Polarity Horizontal/Left (high)
  • 22 kHz on (LNB 10600 MHz)

There are three SR1 parameters to set:

  • LNB power Off, 13V or 18V - 18V for horizontal polarisation
  • LNB compensation (off, it's +1V for long power cables)
  • 22 kHz On

I discovered that 18V, 22 KHz was already set, so I could just swap the SR1 lead from the non-pass to the DC pass port.  Simple, and it worked just as expected.

Previous configuration:

LNB
 O/P 1 
LNB
 O/P 2 
| |
 
*
Splitter                Splitter
 
 
*
| | | |
 Main 
PC
 Feenix 
  Splitter   Ayecka
SR1
 IP Receiver  
 |
 RF
 |
| | |  |
| | +--priv ate LAN-- -+   |
| | | |  |
* shows
DC & 22 kHz
control path
 Test 
PC
 Old-Feenix  
 Spare   i5-3330
PC
 Stamsund 
 i5-760 
PC
Alta

Current configuration:

LNB
 O/P 1 
LNB
 O/P 2 
| |
 
*
Splitter             |
|
| | |
 Main 
PC
 Feenix 
  Splitter     Ayecka
SR1
 IP Receiver 
| | |  
| | +---- -- private LAN -- ----+
| | | |
* shows
DC & 22 kHz
control path
 Test 
PC
 Old-Feenix  
 Spare   i5-3330
PC
 Stamsund 
  i5-760  
PC
Alta


Update 6 - initial unexplained losses

Please note that these losses have now been resolved, and were not due to the SR1 receiver.  For further information, please read these notes which are left for historic interest...

2013-Dec-02-03

Overnight between 2013 December 02 and 03 there were two packet loss bursts, the first of which had all packets recovered, but the second of which did not.  Comparing the SR1 with two SkyStar PCI card receivers (and others across Europe), it appears that the losses were purely in the SR1 box (which is fed from the second output of the same LNB as the SkyStar cards).  Signal was nominal at the time.  Local signal blockage can therefore be ruled out, although not that one LNB feed is faulty or intermittent, or that there is an issue with the four-port hub.  The losses are less with PC Stamsund as it takes fewer data streams than the other PCs.  However, on checking the SR1 statistics, there are zero MAC mismatch errors, and zero MPE CRC errors.

There have been two more occurrences of events like this on 2013-Dec-05 and 2013-Dec-09, so it seems to be characteristic of my arrangement,  Perhaps by 4-port hub is struggling?

2013-Dec-05

On 2013-Dec-05, you can see an extra missed packet burst at about 03:20 UTC on PCs Alta and Stamsund.  However, those PCs do not show the same missed packet burst just before 08:00 UTC.  Perhaps the more sensitive receiver in the SR1 has not lost packets at that time?  Unfortunately, I no longer have the signal strength plot for that period.

2013-Dec-09-10

The 2013-Dec-10 event is, fortunately, a little simpler.  There were two missed packet events on the previous day (Dec 09) at 12:00 and 14:35 UTC, and these are seen on all four PCs and on some other PCs across Europe, although as PC Stamsund is taking fewer EUMETCast channels less loss is recorded.  Both PCs Feenix and Old-Feenix showed one missed and one recovered packet at each burst.  However, on Dec-10 only those PCs being fed from the IP receiver showed two missed packets bursts at 03:20 and 07:20 UTC, totalling 12 in the case of PC Alta, and 11 for PC Stamsund (which takes fewer data streams).

The same happened again on the morning of December 11, at a similar time (03:15 UTC).

2013-Dec-27-28-29

On December 27 we had rain and high winds in Edinburgh, with the winds coming from a direction which causes the 10 GHz dish to wobble.  Consequently there were missed packet bursts and data loss as can be seen on the left end on the graph below.  Early in the morning of Dec 28, around 01:05 UTC, there were missed packets seen by the SkyStar PCI card receivers (Feenix and Old-Feenix), but not be the PCs fed from the Ayecka SR1 box.  This likely indicates a slight improvement in the effective sensitivity of that box, although it is fed directly from the second output from a dual LNB, whereas the other two receivers are fed from a splitter and therefore have a slightly lower signal level.

Of more significance is the right-hand end of the graphs, where the Ayecka receiver has packet and data losses at 03:15 UTC on December 29 (32 missed and 20 recovered packets), but the SkyStar PCI cards did not. 

Summary of dates and time of Ayecka SR1 receiver losses

Date
 
Day
 
Missed
Packet
Time(s)
Data Loss
Start & end
times
Plane Plotter 
e-mail Job
EUMETCast 
Log Analysis
Job
Update 
Keplers
Job
2013-Dec-02 Monday 23:45 (none) 03:17:00-03:17:25 03:20:30-03:21:30 23:42
2013-Dec-03 Tuesday 03:20 03:17:34-03:29:11 03:17:00-03:17:25 03:20:30-03:21:30 23:42
2013-Dec-05 Thursday 03:20 03:18_54-03:18:54 03:17:00-03:17:25 03:20:30-03:21:30 23:42
2013-Dec-10 Tuesday 03:20 07:20 (none) 03:17:00-03:17:25 03:20:30-03:21:30 23:42
2013-Dec-11 Wednesday 03:15 (none) 03:17:00-03:17:25 03:20:30-03:21:30 23:42
2013-Dec-29 Sunday 03:15 03:17:34-03:19:50 03:17:00-03:17:25 03:20:30-03:21:30 23:42
2013-Dec-31 Tuesday 03:15/03:20 03:17:46-03:21:55 03:17:00-03:17:25 03:35:30-03:36:30 23:42
2014-Jan-01 Wednesday 03:05 03:04:39..03:06:23 03:04:05-03:04:33 03:35:30-03:36:30 23:42
2014-Jan-03 Saturday 03.05 (probably none) 03:04:04-03:04:33 03:35:30-03:36:30 23:42
2014-Jan-10 Friday 23:40/23:45 (none) (on different PC: 03:52) 03:35:29-03:36:37 23:42
2014-Jan-14 Tuesday 23:40/23:45 (none) (on different PC: 03:52) 03:35:29-03:36:37 23:42

Looking at these times makes me wonder if something happens within  EUMETCast around 03:15 UTC, but I think it unlikely.  Checking on the two PCs in question, I see that PC Alta has an e-mailing task at 03:17:00, and a EUMETCast report summary at 03:20:30 (reads TelliCast log files), and PC Stamsund has nothing within ten minutes.  Whilst I don't see how the task on PC Alta could affect losses on PC Stamsund, I will move the time of the Alta task 15 minutes later to see.  This was done for the Dec 30 run, but more losses occurred at 03:15/03:20 on Dec 31 (not graphed), so I've now altered the 03:17 e-mailing task on PC Alta to run at 03:04:05 (from Jan-01) and see whether that makes any difference.  It seems almost certain that the e-mail task timing may be related to the data loss timing.  Currently, this is not understood.

Further, noted that the remaining odd shared losses may coincide with a job on PC Alta which updates Keplers.  This should have no reason to access the Ayecka SR1 box, but I notice that its address is listed first in an ipconfig command.  Is TCP on Windows searching for an internet connection in a particular order, and is there anything in common between the log mailing and the Keplers update job?  Just the need to use the Internet, I think.

Next tests might be to change the 4-port hub (although it is completely dumb and has no sense of the time), or to remove the hub altogether and connect the Ayecka box just to a single PC.  In fact, on Jan-04 I moved the e-mail part of the job to a different PC (PC Narvik) which has no connection to the SR1 box, and the errors around e-mail time disappeared.  As noted below, changing to a 1 G/bs network switch on Jan-24 also resolved the problem, with the e-mail back on PC Alta.

2014-Jan-24

As the existing multi-PC tests have been at 100 Mb/s, I felt it was desirable to test at the full speed of which the device is capable.  This could result in the PCs become more sensitive to losses as the data may be arriving a little faster and the Ethernet cards work in interrupt coalescing mode, or it may be that a newer gigabit switch will cope better than the old hub.  To this end, at 10:40 I replaced the 4-port 100 Mb/s hub with a Netgear GS605 5-port 1 Gb/s switch, and will monitor what happens.  I also re-enabled the e-mail job on PC Alta which had caused problems before.  Results show no missed packets at the time of the e-mail job, so issue solved (although I remain unsure as to just what was happening).

2014-Jan-31

At 07:00 UTC the Ayecka box as swapped for a Novra S300E box to compare the two.  Only one oddity while the box remained powered and connected to the House LAN was that the SNMP monitoring continued to record the previous values for signal level and SNR, but correctly recorded 0 for the Link Margin.  Unsure why this was happening, and didn't investigate further.  The correct levels (i.e. zero!) were recorded over SNMP once the box had been powered down.

2014-May-15

Around 09:00 UTC, updated the software on both SR1 boxes from 232 (I think) to SR1c_v1.05b239.asw.  This solved the problem of multiple SNMP reads in one request not working.

2014-Jun-16

At 10:55 UTC, I updated the software on the #2 SR1 from SR1c_v1.05b239.asw to SR1c_v1.05b243.asw, which should solve the SNMP write-access problem (the write community password was being revealed to the public read-access community).
 

Next steps?

  • To monitor the new LAN configuration for any issues, in particular the packet loss issue.
    This appears to have been resolved with the new Netgear GS605 5-port switch running at 1 Gb/s.
  • To test Novra receiver
  • Anything else?
     

David Simmons notes

2013-Nov-17

I now have the other SR1 up and running.  It was very easy to set up using the USB method Windows 7 found the drivers to the COM port relatively easily and installed them and using PuTTY as the terminal program it was easy to program SR1 to receive EUMETCast.  Now to the more difficult bit and something that we will have to sort out the way this receiver sends out the data onto network is by broadcast protocol which is fine as long as it is contained in a sub-network.  I have set up a sub-network here consisting of its own router which connects the SR1 to all the computers that receive the data from EUMETCast.  At the moment I have just one computer on this network receiving data.  Earlier in the day I had the SR1 plugged in my main network and several computers using the data, but as it broadcasts data it caused overload and things like VoIP phones on things similar ceased to function reliably.  All the computers receiving the data from it missed zero packets also of interest receivers status gives exactly the same results as my very expensive satellite meter in regards to the error rates and signal strength and quality of signal.

So far the only criticism with the receiver is that I cannot use it with my satellite switch which supplies the all our cottages with Astra/sky and Eurobird 9 satellite transmission.  The reason for this is it does not have the function to activate the switch with the various tones required.  This problem is probably unique to me in our group.

David Taylor's comment about it getting hot: I would say it is certainly warm to touch but not excessively hot.  In my case it is powering the LNB.

Obviously we need to do a little bit more work on finding out the best way of setting up networks to handle the broadcast data this receiver puts onto them.

I wonder if it is possible to set up a batch file to program it for EUMETCast?

2013-Dec-01

So far the Ayecka SR1 has performed faultlessly and I believe the receive performance of this device is far superior the USB boxes we have been using in the past.  The status menu for receive signal is the actual signal - it is exactly the same as my professional meter gives i.e. bit error rates, signal strength and all the other measurements are exactly the same as my Rover meter.  I find it is very encouraging because we are dealing with real-world signals and to be is to be calibrated correctly unlike the USB box.

I have discovered there is one slight problem with the SR1 in that the management port cannot be directly connected to the gigahertz network which does support 10/100/1000 MHz.  I have some of the other devices plug-in that works faultlessly on various switches around the house.  The SR1 is not recognised by these switches, and this caused me a bit of a problem until I got an old switch out which only supports 10/100 into which I connected the SR1, and that switch into the network which now gives me Internet access to all the computers behind the SR1 i.e. the weather satellite receiving computers.

The way to set up the SR1 to achieve this is to give it to static addresses for each of its parts i.e. the management port and the traffic port.  You then need to go down into the menu system of the SR1 and switch on link networks and make sure that broadcast data on the management port is disabled.  This enabled me to use NTP and Internet Explorer if so wished on all the weather satellite computers whilst receiving data from the traffic side of the SR1.  So far the weather satellite systems did not appear to have missed any packets and indeed the receiver itself has zero packets missed but it does seem to have something amiss with some MAC addressing which I have not got to the bottom of?  And my home network working perfectly correctly without overload because no broadcast data is getting onto my internal network but I can still acquire images through the switch which is built into the SR1 for use on the internal network if so required.

If you wish to feed the SR1 data signal broadcast signal to more than one computer a simple solution is to make sure computer behind the switch have a static IP address within your network.  This may enable you to assign a static address in the T systems software which is your network card in the computer address.  If you do use DHCP the only problem is you run into is that the systems will not work if the address changes upon a restart.  The SR1 allows all DHCP straight through on the home network or without any problems at all and indeed this is why I also selected as static address for the SR1 in both ports so that it can be managed over the network.  You can either manage on the broadcast side or from the management side.  But I will say it seems to be easy to program inside the SR1 via the USB lead using something like the PuTTY software.

To have multiple computers running behind the SR1 I have just put a simple 5 port TP Link switch which is broadcast packet compatible.

I have been trying to get the SR1 send high definition television signals onto the network.  I believe the SR1 is doing what it says it is doing but I haven't achieved in receiving the said signals on a computer yet.  Certainly the network traffic seems to be very busy.  I was doing this simultaneously while receiving EUMETCast data (using the two receivers in split mode).

My conclusion is I'm certainly going to keep this receiver as it is exceedingly easy to set up and get running, and all of its diagnostics are absolutely correct as regards signals.  The only thing I have not been nabbed to try out yet is a satellite using VCM.  I am working on this as I am aware that there are currently one or two transmissions using this mode.

2014-Feb-23

As a test, I replaced the TechniSat SkyStar feed on the main receiving PC (Feenix) with a 1 Gb/s network card and a connection to the Netgear GS605 5-port switch being driven from the Ayecka SR1 box.  As this is a single-core PC, but doing receive-only, I was interested to know whether it would handle the data stream, and the increased CPU load noted above, without producing packet loss.  High winds on the previous night had produced errors because of lost packets in any case, so it was a suitable moment to take the PC down and add the new hardware.  

For the moment, the TechniSat card has been left in place, and SkyStar receiving process (green satellite icon) stopped.  This will mean that the other PC (Old-Feenix) being fed from that LNB may be vulnerable to a reboot on the main PC as there is nothing to force the LNB into the correct frequency and correct polarity except what was left from the reboot of the main PC.  Perhaps that's no different to how it used to be, though.

2014-Jul-08

Some notes from Andrew Brooks - Satellite Receiving Station, University of Dundee:

  • Don't try and use the new FPGA firmware if you have the input connected to rx2.  It never gains Transport lock.  This is repeatable and has been reported to Ayecka.
     
  • The receiver has a habit of corrupting its own configuration.  For example when you edit one parameter you find something else has changed.  The safest way to edit any parameter is to go into the configuration from the main menu, edit the item, type 0 to return all the way back to the main menu (and maybe exit telnet for extra safety), then go back into the configuration to verify it changed as expected, then check all other configuration sets for all tuners to verify nothing else changed unexpectedly.  This is also repeatable and has been reported to Ayecka.
     
  • The receiver may lose Transport lock as a result of changing something unrelated.  For example if you turn off front-end power on tuner 1 then tuner 2 (the one which you are using) will silently lose transport lock.  It will show "Locked" on the main menu even if Transport lock has been lost, so make sure you check the Status page (or SNMP) explicitly for Transport lock.  The way to solve this is to go into the Filters table, edit the PID for a filter and set it to the same value it already has.  The receiver then magically gains Transport lock.  This is also repeatable and has been reported to Ayecka six months ago.
     

Ayecka tests by Francis Breame

Thanks to GEO I have had the opportunity to test the Novra S300E and Ayecka SR1 receivers.  In general, I agree with the findings of the other testers, in that there isn't a lot to choose between them from a reception point of view, in advance of receiving an actual S2 signal.  The ultimate choice lies with relatively minor issues and how you intend to use the receiver (personally I agree with David and prefer the SNMP facility and dual Ethernet ports of the Ayecka).  However, I did have one major issue with the Novra (reported here).

Support from both suppliers was good.

Test configuration

  • 80 cm and 1.2m dishes 
  • AMD 4-core PC running Windows XP
  • AMD 6-core PC running Windows 7 Pro
  • Dedicated NICs (network cards) on both.
  • I didn't try using the house LAN other than to the Ayecka management port.

These were used in all combinations.

Both PCs had a variety of other software running simultaneously (the full EUMETCast processing suite in the case of the 6-core).  Both receivers were set up using the EUMETSAT configuration files.  Packet loss was comparable and could be attributed to PC issues, although unfortunately I wasn't logging this before and therefore have no basis for comparison. It was insufficient to cause problems.

Ayecka issues

  • As others have reported, the management port may fail to work with a Gigabit 10/100/1000 switch/router/NIC (the standard these days) although it should auto-adjust. I am fortunate in using some surplus HP professional switches which can have the port speeds manually configured, which works fine, but is probably not possible on domestic switches. 10/100 switches are still available, but this may become an issue in the future.
    [Note from DJT: I have the management port connected to a Netgear GS608 8-port gigabit switch and see no problems.  David Simmons has seen a similar issue, and EUMETSAT also comment on this.  It has been reported to Ayecka.]
     
  • Again as reported by David, the SNMP implementation only sends back a single value per request, even if multiple values are requested. This affects MRTG. I have a simple script for use with MRTG which makes multiple requests and can extract a variety of parameters. The overhead is negligible. Ayecka were quick to send me the necessary MIB.
    [You may also be able to use the MRTG "SingleRequest" global option (see here) to modify MRTG's behaviour to work round this problem.  Thanks to John Say for spotting this one!  A later version of the SR1 software removes this limitation.]

Further notes on the network issues

I've done bit more testing regarding the problem which myself and David S had in connecting the SR1 management port to an auto speed sensing Gigabit switch.

Briefly, my network consists of a Draytek Vigor 2830n ADSL/router, which is expanded by connecting to three HP ProCurve 1800-8G 8-port switches.  All are Gigabit.  If the SR1 is connected to the HP switch with the port in auto mode, connection fails.  If however I connect to a spare port on the Draytek router, it correctly connects at 100Mb, as does the HP if I manually configure its port to 100.

Similarly, if I put a Netgear GS608 switch (same as David T) in series with the SR1 and the HP switch (set to auto), all is ok.  The conclusion is therefore that some switches will auto sense correctly, some won't - in my case the HP won't - nor evidently will whatever David S (and apparently EUMETSAT) is using.

(I should add that the HP switches, although a little old, work well with all my other devices.  A great advantage is that both the HPs and the Draytek have SNMP, not usually seen in domestic units.)

It will be worthwhile bearing this in mind in case other SR1 users run into a similar problem, as it is not at all obvious.  Many thanks to David S for finding it in the first place.

 

Comments and Notes

  • A separate LAN for EUMETCast data is likely to be required, although that does mean that multiple PCs can then receive the data.  Each PC would need a TelliCast software and an eToken.
     
  • It's likely that a dual-core processor is needed at a minimum, with quad-core being desirable.
     
  • There has been a packet loss issue which has yet to be explained.  Now seen on two systems.
     
  • There is a limit at the moment of 9 PIDs on this device (PID 509 is hard-wired in the firmware).  However,  this is not expected to be a limit as the new DVB-S2 service uses fewer PIDs than the present DVB-S service.
     
  • The SR1 may not support all the DiSEqC commands required by complex satellite reception installations.
     
  • Although the device performs well, a USB box directly connected to a PC may present a slightly lower CPU load, and could have fewer missed packets.  
     
  • With a 12 V 2 A power consumption, the box does get quite warm (just warmer than a DVB World box which is driving and LNB).  When not driving an LNB, the box consumes less than 0.5 A according to the supplier, so that should not be an issue.  If the box does get too warm for your liking, perhaps you could place in a slight draft or cooler location.  See this note from James Brown.
     
  • For the price, a USB to USB-mini cable and networking cable should be included in the box!
     
  • Other available devices currently appear to have too high an error rate, some even on the existing DVB-S service (e.g. TBS6925 reports from EUMETSAT and WXSATPICTURE [France]).  Later reports suggest the high error rate of the PCI card on the present service may have been cured by either updated drivers or updated firmware for the card (or both, I am unsure which).

Box cooling

James Brown writes: I don't know whether this would be of any interest to folk, but as the unit seems now to be at nominal working conditions I have now positioned the SR1 just a few inches above floor level on a skirting board - sideways on [i.e. body vertically mounted, slots horizontal].  I did this because I realise when I first posted to you about the coolness of the unit it was partly suspended off the floor.  When I had it flat on my desk to watch the traffic and management port LEDs it ran quite a bit warmer.

I realised that with ventilation holes running down both of the long sides it might be worth while mounting it differently.  My thinking was that the heat being generated would hence draw in fresh air from the underside holes and discharge it from the upper ones.  It has certainly cooled the casing right down again, and I can imagine that the swifter exit of hot air off the components will assist in a small way.  I don't think any components are using the case as a heat sink, so probably all the heat is just off the components themselves.

Anyway, it's just a suggestion - feel free to share it if you think it worthwhile.

Here's what I've done in Edinburgh - put the box on stilts.

DVB-S2 service - configuration for the early tests

  • Networking issue - my own mistake!  Because I operate two Ayecka SR1 receivers, I gave then both their individual private LANs, even though #1 is connected to three receivers and the #2 box to juts a single test receiver.  The first one was set up on network 192.168.10.x and worked without problem.  The second one I set up on network 192.168.20.x, and initially it would not respond to PING requests.  I discovered that this was because I had not set the built-in router to an address on that network, and doing so resolved the problem.  From the main menu, this is Network (3), Router IP address (E).  I ended up with:

      LAN address: 192.168.20.101
      Router IP address: 192.168.20.100
      IP address of PC card: 192.168.20.102
     
  • Douglas Deans found two configuration issues when setting up by hand for the early tests of the actual DVB-S2 signal.  Of course, these settings should be set by the EUMETSAT configuration utility once it is released with the appropriate DVB-S2 settings.
     
    • The Coding Mode needs to be set to "VCM".  This in the RX configuration menu, option 4.
    • The ISI needs to be set to "1".  This in the RX configuration menu, option D.  I found that with the Telnet interface, I needed to type "D1" to set the ISI to 1.
  • If you are using the single receiver channel, but using both configuration sets with the first for DVB-S and the second for DVB-S2, Arne van Belle spotted that the PIDs also need to be set for the second configuration set.
     
  • You may need to update either the firmware or the software if you purchased an early SR1 receiver - details of how to do this are here.  Only carry out an update if you are advised to do so by EUMETSAT or Space-Band/Ayecka.
     
     

Novra S300E box


Images from EUMETSAT install guide

On 24-Jan-2014 I received the Novra 300E receiver box from GEO for testing.  It's quite a noisy unit with its small fan at the rear, but that does mean that it runs cooler than the Ayecka SR1 box.  Initially, I found it impossible to communicate with, even though I knew its IP address (192.168.0.11) and could ping the box correctly and could see the yellow LED flashing with each ping!  There appears to be no "factory reset" function.  The communication issue was resolved by downloading a more recent version of the management program than was recommended in the first issue of the EUMETSAT install guide.

Management software is available here:
  http://novra.com/Website/Novra_Support.html
  http://novra.com/Zip%20Files/Novra%20Mgmt%20V6.3.9.zip
  File: Novra Mgmt V6.3.9.zip

You can download EUMETSAT's own configuration guide from this FTP site.  The next day I continued setting up the device on PC Old-Feenix - a lower-powered test PC using a 1.9 GHz single core Pentium with 1 GB memory and Windows XP.  This PC's LAN card was set 192.168.0.12 to start with as the receiver as supplied was set to an IP address of 192.168.0.11.  Whilst the receiver could be detected and configured with the management software, EUMETCast wouldn't work (stuck on trying to connect), and I concluded that having the Novra box on the same network as the house LAN meant that EUMETCast was confused as to where to get its packets.  Perhaps a ROUTE command would have helped, but I wanted to keep the massive network load from EUMETCast data off the house LAN in any case.

Therefore the S300E was set to:

Receiver IP address: 192.168.11.11
Subnet mask: 255.255.255.0
Default gateway: 192.168.11.10
Command port: 2048

and then the PC's network card was set to:

IP address: 192.168.11.12
Subnet mask: 255.255.255.0

EUMETSAT supply a ready-made configuration file which can be downloaded here:

  ftp://ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/
  EUMETCastDVB_NovraS300E_CFG.xml

which I loaded using the  "without network settings" option.  After some minutes operation, there was a data flow of:

Ethernet packets sent: few million
Ethernet packets received: few thousand
DVB packets accepted: 0
MPE packets processed few million (just less than Ethernet packets sent)

As this is a lower-powered PC, it would not be surprising to see some packet loss, and the graphs below show the data for the brief test period.  Bear in mind that the figures for packet loss and CPU usage before midday on 2014-Jan-25 (left-hand side of the graphs) are using a TechniSat DVB-S PCI card, which gave zero missed packets.  This PC is on the limit (or perhaps slightly past it!) when using a LAN card interface, compared with the SkyStar PCI card.  This was only a temporary test setup, and the intention is to try the receiver in the same position as the Ayecka SR1 box in due course.

The baseline is that with a SkyStar PCI card, the PC had zero packet loss.  However, when using the IP receiver in an 18-hour period, there were 1810 missed packets and only 1296 recovered, and this may be unacceptable for a EUMETCast system.  Although the losses appear less than with the Ayecka box, there was no rapid-scan data sent at the time, so data throughput was less and hence packet loss would be expected to be less.  This is a very similar result to that obtained with the Ayecka SR1 box, so there is nothing to choose between the two in this respect.

Update 2014-Jan-31

Today I replaced the Ayecka SR1 box with the Novra S300E for comparison testing.  This required changing the IP address of the box to one on the same network as the Ayecka box (not essential, but it was easier to alter one box rather than two network cards and two recv.ini files), so I set the IP address to 192.168.10.202 (the Ayecka box had been on .102).  After moving the antenna connection, and the network connection, I was surprised to see that the Novra box only supports 100 Mb/s networking.  That will be OK for the present data rates and likely the future Basic service, but could possibly be marginal for the future High Volume service, especially if an attempt was made to use a shared 100 Mb/s LAN.  It was good to discover that there was no need to even restart the TelliCast programs on the connected PCs, or to alter the recv.ini, as the IP address specified in recv.ini is that of the local network card and not that of the remote UDP source.  It may take some getting used to that!

You can see a summary of current EUMETCast performance here and throughput here, which will be from the Ayecka receiver after 2014-Feb-08.

Update 2014-Feb-09

I felt there was nothing further to learn from this box so I replaced it with the Ayecka SR1 which I now own, as that has the better remote monitoring capabilities.  Purely in terms of receiving today's DVB-S broadcasts there is nothing to choose between them.
 

Conclusions - Novra S300E box

  • For best function, a stand-alone PC or separate LAN is required.  Having the PC communicate with the rest of the network with a second LAN card or USB Wi-Fi dongle is fine, but the Novra box and PC interface card must be on their own distinct LAN.  The network port is only 100 Mb/s.
     
  • The box is noticeably noisy in a quiet office environment, but runs cooler than the Ayecka SR1.
     
  • A 1.9 GHz Pentium 4 PC is unlikely to be adequate (but that test box must be 12 years old!).  Dual-core minimum or quad-core preferred.
     
  • DiSEqC commands not supported.
     
  • The management software runs on Windows on the local PC, so the device cannot be managed from any desired PC on the network (perhaps need to check some bridging options?)
     
  • There is no SNMP management option possible.
      
  • At first glance, performance appears very similar to the Ayecka SR1 box.
     
  • The default IP address is likely: 192.168.0.11

The next step will be to compare the box driving two more powerful receiver PCs, in the same way as I am currently using the Ayecka SR1 box.  This was started on 2014-Jan-31, and worked as expected with no problems using the Netgear GS605 5-port gigabit switch.
 

Novra tests by David Anderson

[David worked with the same Novra S300E IP receiver which I reported on above.  My thanks to David for providing these notes.]

The receiver was connected to a home-built PC with an AMD Athlon LE-1640 2.60 GHz processor and 2.0GB memory running Windows 7.  As well as receiving EUMETSAT data the PC also runs applications to receive, process and upload data from my Davis Automatic Weather Station.  The PC is networked with an Acer PC with an Intel Corei3 3.10 GHz and 4.00GB with is used for general use as well as processing the EUMETSAT data.

For the purpose of the test I added an additional network card for connection of the Novra receiver.

I downloaded and installed the latest version (V65.3.10.0) of the Novra management software.

Rather than change the subnet of my existing PC's I changed the IP address of the Novra receiver to 192.168.1.202 through the management software.  The IP address of the network interface card was set to 192.168.1.201.  However, even after installing the receiver on the same subnet as my LAN the management software would not auto-detect the receiver, although I could log in through the record I created in the Managed List.

I agree the fan is noisy but I understand in an email from Francis that Novra are prepared to send us a replacement.

The Lock light on the receiver is actually blue - not green as shown in the documentation.

When I updated the recv.ini with the receiver IP address I was unable to connect to the TelliCast Software (the TelliCast icon turned red).  The TelliCast log did not show any errors).  When I removed the interface statement from recv.ini the receiver connected OK.

I ran the receiver from around 20.00 on Tuesday February 18th until 10.00 on Saturday February 22nd.

Attached is a screenshot from the Management Software at the end of the test showing packet counts and bad data counts.

In conclusion, it appears that once the receiver was installed and configured it performed well without any noticeable downgrading of other applications on my LAN.


 

[DJT note: the IP address to be set in the recv.ini is that of the PC connected to the Novra or Ayecka box.  I also made this mistake, thinking that it was the address of the IP RX box with was needed.  It isn't.  The software needs the address of the local PC, the one with the new network card, and specifically the address of that network card.]
 

Novra Tests by Francis Breame

Test configuration:

  • 80 cm and 1.2m dishes
  • AMD 4-core PC running Windows XP
  • AMD 6-core PC running Windows 7 Pro
  • Dedicated NICs (network cards) on both.
  • I didn't try using the house LAN other than to the Ayecka management port.

These were used in all combinations.

Both PCs had a variety of other software running simultaneously (the full EUMETCast processing suite in the case of the 6-core).  Both receivers were set up using the EUMETSAT configuration files.  Packet loss was comparable and could be attributed to PC issues, although unfortunately I wasn't logging this before and therefore have no basis for comparison.  It was insufficient to cause problems.

Novra issues

  • The LAN voltage (polarisation selection) can be set to either 11-15 or 13-18v. All LNBs I've ever seen (I'm open to correction) use 13-18v; however, the EUMETSAT configuration sets it to 11-15v. I changed it to 13-18v.  I don't know whether this makes any practical difference.
     
  • cmcs, the command line status/configuration utility used in place of SNMP, didn't work with Windows, although the Linux version was ok.  Apparently the S300E box sends back a slightly different response which wasn't recognised.  However, Novra quickly provided a new version.
     
  • This is the big one! The S300 would sometimes reset/drop lock for extended periods whilst sending normal traffic (so Ethernet port sleeping isn't an issue).  After a lot of investigation, this was traced to periods when my Canon MG6350 printer/scanner, which is connected to the house LAN, was switched off!  What was happening? Ethernet sniffing using Wireshark showed that the "Canon IJ Network Scanner Selector EX" program sends out polls on all Ethernet ports (including the one dedicated to Novra) using the Canon BJNP protocol.  This apparently upsets the S300 causing it to reset.  The program only polls when the printer is off; having found one, it stops (at least sufficiently not to cause problems).  Disabling the program provided a partial cure, since further polls are sent out at the conclusion of each print job.

    I spoke about this to Gordon from Novra at the GEO Symposium, and will be forwarding my captured data for their investigation. I will report any results. (The Ayecka box didn't show this problem.)

    Update 2014-May-06: Following my strange network interaction problem between the Novra receiver and my Canon printer, I sent various Wireshark captures to Novra.  They have now confirmed that this is a genuine problem and will be patching the firmware.  You may wish to add this bit of folklore to your DVB-S2 results page in case anyone else sees the same thing.

    I will be getting back to them to see what is so odd about my setup - I can't imagine that no-one else has a network-connected Canon printer.  Possibly [the problem] is unique to the S300E - the EUMETCast version - which will be rarer at the moment.
     
  • Update from Novra 2014-May-09  "The Novra S300E version receiver was only recently released.  Although we do thorough testing of Firmware prior to release, we are not able to test every scenario these receivers may see in the field.  Generally these devices are placed on either a quiet LAN segment or their own dedicated segment in the field and as such do not have a lot of other devices that are transmitting on the same segment.  Again, thank you for bringing this Canon printer issue to our attention.  The patch will be available shortly for download as a new S300E version 1.0.1.  Please advise us of other S300E issues you may find during your testing."
     
  • Update from Novra 2014-May-17  Firmware update to v1.0.1, and Francis Breame reports that the problem is fixed.  Download from support at: www.novra.com.
      

HVS status displays

Following tests on the second EUMETCast HVS service, Francis Breame kindly supplied screen shots of what the Novra Management Console might display in normal use.

He writes: As you requested in a recent group message, I attach a couple of screen shots of the Novra S300E config - one is for the original transponder, the other for the 2nd. I now have the test HVS-2 data flowing well.

Although my Novra is fed separately from a dual LNB, note that the levels are ~ -6dB due to a splitter which I'm using to monitor the downlink on the spectrum analyzer. This is showing TP2 to be down roughly -4dB (strictly should be down +4 I suppose!), which is in agreement with the Novra figures.

Please note that the display below is from the initial EUMETSAT tests of their second transponder on EUTELSAT 10A in January 2017, and the Symbol Rate is not representative of the final service!

 

TBS Units

PCIe cards

These are the lower cost TBS units, and there are two models which have been tested - the earlier single-tuner TBS6925 and the later dual tuner TBS6983 which uses a more recent tuner and decoder chipset.  My own experience has been with the TBS6983 card used under Windows 8.1-u1/64, where it has produced satisfactory results, albeit with a steady stream of missed and recovered TelliCast packets (but no lost ones), suggesting that the unit is working closer to the margin than might be ideal.  Typically, there are about 10 missed TelliCast packets per hour, and the same number of recovered packets.  It was tested with the TBS6983 Windows driver V1.0.0.4, and the TBS IP Tool V3.0.4.4 software.  The software was set to accept only the 8PSK3/5 MODCOD as the signal level here does not give sufficient link margin for the High Volume Service to be reliably received.

There is a EUMETSAT guide under construction - check for a download here.

USB box

The TBS5925 is nearest in function to the DVB World boxes which were very popular for the DVB-S service.  This unit has been tested on both Windows-7/64, and on Windows-8.1u1/64.  In both cases, using the TBS driver software with the TBS IP Tool program resulted in Windows crashing (i.e. BSOD) within periods ranging from 3 minutes to 20 hours.  Other testers have seen similar results, while yet other have no problem.  Crash dump analyses have been sent to TSB support who have produced updated versions of both the driver and the IP Tools program, but with no success at the time of writing (early November 2014).  There is a 3rd-party alternative to the IP Tool program called BDADataEx, which does not crash Windows, and which offers the ability to select reception of just the Basic Service MODCOD (from version 1.1.2.1230).  Setup screen-shots are here.

Why might I need to select just the Basic Service?  For example, in Scotland we have a weaker signal than in much of Europe, thus making it important to be able to receive just the Basic Service alone.   Otherwise when the signal level drops too low for the High Volume Service decoding errors start to arise, adversely affecting the performance of even the Basic Service, which is degraded to an unacceptable level resulting in missing data. This interaction has been widely observed.  To avoid this issue, it is desirable that your receiver be able to select just the Basic Service (MODCOD 8PSK/35) and to ignore the High Volume Service packets with MODCOD 16APSK2/3.

Consequently it is difficult to unreservedly recommend the TBS5925, but if a non-crashing version of the TBS IP Tool and driver becomes available, or if the BDADataEx program is fixed so that its MODCOD selection works, the situation would change.

There is a EUMETSAT guide available for download here.
  

Recommendations

  • Either the Ayecka SR1 or the Novra S300E are suitable for the EUMETCast service.
  • Both are easy to set up, and EUMETSAT configuration guides are available for either.
  • The Ayecka appears to be the more advanced unit, and offers good monitoring using MRTG and SNMP.
  • If you want an internal PCIe card, try the TBS6983.
  • If you want an external box, an IP receiver is likely to be less troublesome than the TBS5925, but it is more expensive.
  • Windows XP should be avoided for this application, as it is no longer supported by Microsoft and other suppliers.
     

FAQ

Q01: You configure the Ayecka SR1 by serial to USB Ė does that mean I need a serial port on my PC?
A: No, you need a USB port on some PC, and that need only be for the initial configuration.  A virtual COM port is emulated over USB, which is quite standard practice.  Once set up, you can access via a Telnet program (e.g. PuTTY) over Ethernet.  Likely you will have started using PuTTY over the virtual COM port.  If you have a pre-configured box such as that sold by the GEO Shop, you can access the configuration functions using Telnet over the LAN to the Management port.

Q02: What is the significance of powering the LNB?  I have a DVB USB receiver at the moment and I donít think that sends any power to the LNB.
A: All LNBs require two signals plus power. The power is delivered as a DC voltage, the voltage level controls the polarisation of the LNB. The second signal is a 22 kHz tone superimposed on the DC, and this switches the LNB between the "low" and "high" frequency ranges.

Q03: Can I use a single LAN connection?
A: Yes!  This is how the Ayecka SR1 boxes are configured when supplied by the GEO Shop or when using the EUMETCAST configuration files.  The Management LAN port is used both for management and for EUMETCast traffic, and you should set your PC's LAN port to an address in the 192.168.10.x network (we recommend 192.168.10.150) and to 100 Mbps full-duplex.

Q04: I want to run two or more PCs.  Does this mean I need two or more receivers?
A: No, use a simple multi-port LAN switch to connect each PC to the receiver box.  The network packets sent out by the receiver will appear on each port of the LAN switch, so using a 5-port 1 Gb/s switch such as the Netgear GS605 (£23) will allow connection of up to 4 PCs to the one receiver.  Each PC will need a TelliCast licence and eToken, though.

Q05: Do I need special Ethernet cables?
A: No, but you should ensure that cables you buy are suitable for "gigabit" Ethernet.

Q06: What networking equipment works with these units?
A: Whilst I have had no problems with the Netgear GS605 and GS608 units, please see these notes from Francis Breame.

Q07: I've set everything up according to the EUMETSAT guide and configuration program, but I still get a red LED and no lock.
A: You did see that RX1 is actually the right-hand of the pair of F-connectors on the back of the unit, I suppose?

Q08: I have a BT router, and TelliCast only connects when I start my PC with the router disconnected!  Otherwise I just get a yellow TelliCast icon ?
A: Try editing recv.ini to make the interface address four zeros:

[parameters]
interface_address=0.0.0.0

Q09: I am getting data but some of the channels stay in the Connecting state.  I have checked the recv-channels.ini file, and that I have all the PIDs selected.
A:
Try editing recv.ini to make the interface address four zeros:

[parameters]
interface_address=0.0.0.0

Q10: I am getting a lot of extra traffic on my house network, which may be spoiling EUMETCast reception or programs like Skype.
A: Be sure in the Network menu, option 4, that Management IP Multicast is set to OFF.  Normally, you would have a separate network connection from the SR1's Traffic port directly to your receiver PC (or receive & processing PC).  The default LAN IP Multicast ON setting (option D) ensures that EUMETCast data goes via the Traffic port.  If you are using two LAN connections from the SR1, you would not normally want EUMETCast traffic going via the Management port as well, unless you are using the receiver PC for management functions and have only one connection to the SR1 box.

Q11: I am seeing a steady stream on missed and recovered packets - perhaps 1000-1500 per hour - and yet almost all the missed packets are recovered.  Is this normal?
A: No, it's not normal, and has been cured in at least two cases by updating the driver for the network card.  Whilst Windows will provide an adequate driver automatically, a driver from the card manufacturer's support Web site may be better, as may one found via the DriverMax program.

Q12: I think I have everything set up for SNMP and MRTG works locally, but my device cannot be seen outside the local network?
A: You may need to port-forward the SNMP packets as your ISP may be using port 161 themselves.  Forward a high-numbered port, and tell the outside SNMP enquirer what the port number is.  You will also need to tell the SR1 the IP address address of your router, in the Management Default Gateway field.

Q13: I am trying to select just the Basic Service, but my box doesn't seem to have the "Dual receiver" capability?
A: With software version 250 there is no need to use the dual-receiver method, just use the MODCOD selection menu to choose the 8PSK3/5 MODCOD.  Details are here.


Acknowledgements

My thanks to Nigel Evans and Francis Bell at GEO for procuring these test boxes, and for the chance to try one out, to David Anderson for his test report, and to David Simmons, David Anderson, Alan Banks, Francis Breame and Arne van Belle for their valuable comments.
 

Copyright © David Taylor & GEO, 2013-2014
2014-Nov-05

 
Copyright © David Taylor, Edinburgh   Last modified: 2017 Jan 23 at 13:15