|
|
DVB-S2 receiver evaluation notes
Update - EUMETCast User Forum - talks & videoIn 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 performanceWith 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 selectionIf 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:
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 portRecent 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. IntroductionFor 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 boxHere 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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.
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.
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.
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.
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 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:
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.
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:
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).
Requirements:
There are three SR1 parameters to set:
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.
| 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 |
| 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 |
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...
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?
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.
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).
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.
| 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.
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).
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.
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.
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).
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?
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.
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.
Some notes from Andrew Brooks - Satellite Receiving Station, University of Dundee:
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.
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.
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.
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. |
 |
|
|
|
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.
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.
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.
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.
[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.]
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.
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!
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.
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.
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.
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
|
|
