I am still monitoring my site and the site is improving. Below is the output from the Advance menu > Transmitter > More > Timesync. Can you assist in explaining what each section contains and means?
I can only assumed that the Ranged timing parameters mean distance and time fm my site to SAT to NOC, but deciphering the numbers?
Timing info: Assuming which timing unit my site is using to sync. I know both unit 0&1 gets used. I also notice the No network time sysc here again and the reason(s). What is the SMA sync loss?
Timing units 0&1: Empty SFNP Packets means?
What are the type of errors mean.
I search google and got some info I could understand. I know that Turin, It is where I am getting the feed, I notice they have been getting bad weather there lately and more to come by looking at the wunderground.
---------- Timing Information ---------- Current Selected Timing Unit.. 0 Last Time Sync Error Reason. 10 No Network Time Sync.......... 2565 Total Flywheel Frames....... 61 Gershwin/Cavalier Clock Sync.. 2 SMA Sync Loss Perceived..... 278 SMA Sync Loss Initial Lock.... 0 SMA Sync Loss After Lock.... 1
===== Timing Unit 0 ===== Echo Delay.................... 2678043 Local Delay................. 146556 Min Satellite Delay........... 2528402 Max Satellite Delay......... 2531581 Last Satellite Delay.......... 2531487 SFNP Interval............... 3600000 Empty SFNP Packets............ 0 No Delay SFNP Packets....... 0 SFNP Space Timing Offset (STO) 695 SFNP Packets Received....... 131678
===== Timing Unit 1 ===== Echo Delay.................... 2678043 Local Delay................. 146556 Min Satellite Delay........... 2528400 Max Satellite Delay......... 2531581 Last Satellite Delay.......... 2531487 SFNP Interval............... 3600000 Empty SFNP Packets............ 114 No Delay SFNP Packets....... 0 SFNP Space Timing Offset (STO) 695 SFNP Packets Received....... 131570
Time Sync Error - Reason [ 1].. 3 Time Sync Error - Reason [14].. 0 Time Sync Error - Reason [ 2].. 0 Time Sync Error - Reason [15].. 0 Time Sync Error - Reason [ 3].. 0 Time Sync Error - Reason [16].. 1 Time Sync Error - Reason [ 4].. 0 Time Sync Error - Reason [17].. 3 Time Sync Error - Reason [ 5].. 0 Time Sync Error - Reason [18].. 0 Time Sync Error - Reason [ 6].. 0 Time Sync Error - Reason [19].. 0 Time Sync Error - Reason [ 7].. 0 Time Sync Error - Reason [20].. 114 Time Sync Error - Reason [ 8].. 0 Time Sync Error - Reason [21].. 0 Time Sync Error - Reason [ 9].. 0 Time Sync Error - Reason [22].. 0 Time Sync Error - Reason [10].. 281 Time Sync Error - Reason [23].. 0 Time Sync Error - Reason [11].. 21 Time Sync Error - Reason [24].. 0 Time Sync Error - Reason [12].. 0 Time Sync Error - Reason [25].. 0 Time Sync Error - Reason [13].. 0 Time Sync Error - Reason [26].. 0
I understand your frustration, but you're wasting your time sorting through all these arcane statistics hoping to find the answer. Even this TimeSync page points to an inroute issue. Quite frankly, I'm totally underwhelmed by the degree of interest you seem to be getting from your provider. From my perspective, further troubleshooting is pointless until the NOC evaluates your carrier.
That said, knowledge is power. So to help occupy the time till that happens, "Remote Distance" is that from your geoloco to your assigned satellite. It's a calculated value, based upon location data you enter during the setup/registration process. I don't know what unit of measurement they use. "Satellite Delay" is actually Time To Satellite, a measured value. It's obtained when your transmitter radiates a continuous wave carrier through the satellite to the NOC. It's listed in two legs; your geoloco to the assigned satellite, your NOC to the same satellite. The NOC knows their own TTS. When they receive your CW carrier, it's a product of both legs. They perform the subtraction process, and send you back both times. The unit of measurement is microseconds to one (invisible) decimal place. It's easier to just look at the first three digits and call them milliseconds. Add them together and it illustrates the space segment latency.
Even though one statistic is calculated and the other is measured, both are critical to obtaining/maintaining/recovering synchronization with the network. The network in this case is the loop made between the NOC and all subscribers assigned to a specific gateway server. There is only one NOC, but multiple subscribers. So NOC time and distance are sent to everybody's modem. Your unique time and distance are sent back to your modem ID only. Both sets of data are then combined to help your modem lock itself into place in the network. That's why if you get your geoloco wrong in the setup, it's gonna cause problems. But I believe we already confirmed that you entered valid GPS coordinates into your modem. IF NOT, DO THAT NOW !!
I believe SMA loss essentially applies to the entire IFL, which pretty much covers everything that happens between the digital half of the modem and the TRIA outside. SMA sync loss then would be if/when the digital half of your modem discovers it can't talk to either your transmitter or your LNB. Cable faults and local RFI can cause this.
I don't pretend to know what all Hughes' acronyms mean, but "SFNP Packets" are almost certainly contain sync pulses. They're anticipated by the NOC to arrive at predetermined times that are based upon Time & Distance statistics. If they don't show up when expected, it's reflected as a sync loss error. Again, these missing pulses can be explained by a transmitter problem, a POL problem, local RFI.
The error types should be coincident with your TX error numbering. In this instance, you lost timing sync 3 times due to TX1, 281 times due to TX10, et cetera. TX20 by the way is probably normal. No timing pulses are sent during the ranging process.
My NOC is just outside of Washington DC, and I doubt Turin weather is any more severe. They connect through a dozen satellites to over 200,000 subscribers, probably 12,000 of them in my network loop alone. So I think it would become apparent if/when "bad weather" at my NOC is causing the kind of problems you've described. The whole subscriber base would be in an uproar. But on an individual subscriber basis, "weather" all too often has been used as a convenient excuse to avoid more aggressive troubleshooting.
One other thing I've not addressed to this point is dirty power. I know I already suggested removing any coaxial surge suppression devices. But I didn't ask about where you're getting your electricity. Since the modem clock is dependent upon the power source, are you using any kind of AVR device to clean up/regulate the AC that you're feeding the modem power supply?
Thanks for the knowledge. I have asked the NOC to evaluate POL and for RFI for my site and send me a copy to post. I do not know if they did or not, but if they did, I did not get a copy. But for my geoloc input for the vsat parameters; I got this off of satsig.net based on my location: Lat-33.9417 Long-44.3913 Lat= 33degs 56.5mins North Long=44degs 23.5mins East
The input I submitted into the vsat parameters when commissioning the modem was; Long-44 deg 23mins East Lat-33deg 56mins North
The input form only allowed for whole numbers (56mins vice 56.5mins).
As for power. Our so called homes - have 220 only @ 50Hertz. I have a 750watt UPS that I am using to power the modem, switch and firewall. All combined uses less than 300watts. How clean the power is? I am not sure, but I can get one of the devices that will clean the power prior to plugging my modem into using a separate UPS if I have to.
Here is an example of the amount of attention I am getting from the NOC. And I can understand their situation with their customer base against the number of techs and new products (HX200) being deployed. I am patient and calm customer but persistent. I will keep submitting tickets and calls until I am a satisfied customer.
I did request a new data set for my horizon digital meter to check my signal again later this week. Something might have changed that I am not aware of.
Summary : Time Sync Error - Reason [10].. 157 Problem : MAC/Serial Number: Throttle checked (Y/N):N Number of PCs on the LAN:20
No Network Timing Sync...... 1666 Tx Code [05].. 163
I believe I am getting better results due to peaking the dish. Can you see any thing on your end that can improve my site or should I continue what I am doing. Ken
Resolution : Monitoring shows the site to be up and running now.
I have spent an hour on the phone with the hub this afternoon with two calls and they have tested the site several times. ?
The outlink downstream receive quality at the remote is about 82 - 83, which is not as good as reported previously and rather disappointing.
We did a ping test and send 1192 packets round the loop. ?3 packets timed out.
"It was noticed that ?the TDMA burst ?Rate Code? is generally at 256k 4/5, but it occasionally drops right down to 256k 1/2. ?The downstream signal strength also drops at the same time." ?This observation was confirmed later on during a ?second round of tests.
The low downstream SQF and its occasional drops are significant and and may be a start to finding the trouble.
Question: Can drops in the receive SQF be induced locally by physically waggling the LNB coax cable at the modem or LNB ends or by pushing on the antenna. Does gentle tapping of the modem or LNB cause an outage ?
My first guess:
The dish is mispointed causing an SQF of 82 instead of ?higher. ?The satellite is down the side of the receive beam and even further down the steep side of the narrower transmit beam.
The BUC transmit power may be automatically increasing to try and compensate and has now saturated and is sending distorted bursts.
So I suggest repointing the dish.
The pointing needs to be set to the exact centre and peak maximum SQF reading.
Make sure the foundation and pole is rock solid and the head unit secure to the pole.
Azimuth: ?Loosen both azimuth nuts about two turns. ?Gently swing the dish to rest against each nut in alternately (about 10 times) and adjust one nut till the degraded SQF is exactly the same when the dish is rested at either nut. ?Then progressively tighten both nuts in by the same number of turns and flats. The azimuth will now be in the middle.
Elevation: Mark a flat on the elevation nut. ?Adjust the elevation control nut in 1/6th turn increments and record the SQF at each position. ? Then wind back to the beam peak, by counting the flats.
It will take at least 30 minutes to complete the above pointing. ?I hope I don't sound too fussy but I'm trying to get across the precision and accuracy needed. ?Remember the transmit beam is narrower than the receive beam and that a good burst quality into the hub is not an indication of good pointing - the tx BUC power just increases to compensate.
At the end of pointing it should be possible to push quite firmly in any direction on the antenna with no change in the maximum SQF.
I would be interested to know the actual polarision angle reading on the scale behind the dish.
If the above does not solve the problem then..
Local interference to the site LNB (radar, electrical, vehicles, aircraft obstruction etc). Local power supply problems. Poor connection in LNB cable. (I thought this was checked)
are possibilities I can think of ..
Greg. ?I can assure you the hub are trying to help. ?
Ken. Please call the HX NOC if you need further assitance: ?Paul, James or Alex at +44 2392 311 118 .
