Hughesnet (Venezuela) HN7000 issue

[takoateli]

I'm having a problem with an HN7000. Many times a day we lose connectivity. The modem's status page shows it's status as being in the error state with a red status indication. The evt.csv log is showing what I believe to be errors. I'll post a section of the log below. The RX and TX status codes indicate no problem, but we obviously lose connectivity and there's the error indications I mentioned. Can anyone decipher the log and see what's going wrong? Thanks!

Greg

FRI MAR 16 20:46:50 2012, SAT MAR 17 00:46:50 2012, 40303 , 4 , 1 , 1 , , , PBP connection 1 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 20:46:50 2012, SAT MAR 17 00:46:50 2012, 40303 , 4 , 1 , 1 , , , PBP connection 3 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 20:46:50 2012, SAT MAR 17 00:46:50 2012, 40303 , 4 , 1 , 1 , , , PBP connection 2 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 20:47:09 2012, SAT MAR 17 00:47:09 2012, 40307 , 4 , 1 , 1 , , , PBP Backbone 1 Retry count: 6 txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 20:47:09 2012, SAT MAR 17 00:47:09 2012, 40307 , 4 , 1 , 1 , , , PBP Backbone 2 Retry count: 6 txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 20:47:09 2012, SAT MAR 17 00:47:09 2012, 40307 , 4 , 1 , 1 , , , PBP Backbone 3 Retry count: 6 txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 20:48:17 2012, SAT MAR 17 00:48:17 2012, 40301 , 4 , 1 , 1 , , , PBP connection 1 open/up.
FRI MAR 16 20:48:17 2012, SAT MAR 17 00:48:17 2012, 40301 , 4 , 1 , 1 , , , PBP connection 3 open/up.
FRI MAR 16 20:48:18 2012, SAT MAR 17 00:48:18 2012, 40301 , 4 , 1 , 1 , , , PBP connection 2 open/up.
FRI MAR 16 21:11:00 2012, SAT MAR 17 01:11:00 2012, 40303 , 4 , 1 , 1 , , , PBP connection 1 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:11:00 2012, SAT MAR 17 01:11:00 2012, 40303 , 4 , 1 , 1 , , , PBP connection 3 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:11:00 2012, SAT MAR 17 01:11:00 2012, 40303 , 4 , 1 , 1 , , , PBP connection 2 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:11:19 2012, SAT MAR 17 01:11:19 2012, 40307 , 4 , 1 , 1 , , , PBP Backbone 1 Retry count: 6 txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:11:19 2012, SAT MAR 17 01:11:19 2012, 40307 , 4 , 1 , 1 , , , PBP Backbone 2 Retry count: 6 txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:11:19 2012, SAT MAR 17 01:11:19 2012, 40307 , 4 , 1 , 1 , , , PBP Backbone 3 Retry count: 6 txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:12:21 2012, SAT MAR 17 01:12:21 2012, 40301 , 4 , 1 , 1 , , , PBP connection 1 open/up.
FRI MAR 16 21:12:21 2012, SAT MAR 17 01:12:21 2012, 40301 , 4 , 1 , 1 , , , PBP connection 3 open/up.
FRI MAR 16 21:12:22 2012, SAT MAR 17 01:12:22 2012, 40301 , 4 , 1 , 1 , , , PBP connection 2 open/up.
FRI MAR 16 21:31:01 2012, SAT MAR 17 01:31:01 2012, 40303 , 4 , 1 , 1 , , , PBP connection 1 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:31:02 2012, SAT MAR 17 01:31:02 2012, 40301 , 4 , 1 , 1 , , , PBP connection 1 open/up.
FRI MAR 16 21:33:44 2012, SAT MAR 17 01:33:44 2012, 40303 , 4 , 1 , 1 , , , PBP connection 1 restarted/down. RST Rxed. txCode=8 rxCode=5 Inroute Group: 3 Inroute Rate: 256k 2/3 (TC)
FRI MAR 16 21:33:45 2012, SAT MAR 17 01:33:45 2012, 40301 , 4 , 1 , 1 , , , PBP connection 1 open/up.
FRI MAR 16 22:32:48 2012, SAT MAR 17 02:32:48 2012, 385001 , 4 , 1 , 1 , , , ACM Egress: New Modcod = 8-PSK 8/9 (16) Previous Modcod = 8-PSK 5/6 (15) SINR(Switch) = 121 SINR(Current) = 121

 

[grohgreg]

As you state, TX8/RX5 indicates "normal" transmit and receive operation. But other numbers suggest that you may have a minor pointing problem. The 256k 2/3 (TC) is your Rate Code (transmit symbol rate 256k, FEC rate code 2/3, turbo-code enabled). I'd have to know which Rate Codes are authorized in your account, but mine almost always runs at its max authorized 256k 4/5 (TC). I also noted that your Modcod shifted from 15 to 16. I'd have to know your typical signal strength however, to conclude what is normal. But the two sets of numbers combined suggest a slight dish pointing error, my guess would be in the POL angle.

Could you go to http://192.168.0.1/fs/advanced/advanced.html and post what's displayed there? Then look at the left column on your screen. Click on Diagnostics. When the dropdown list appears, select Hourly History. Any red X marks?

//greg//

 

[takoateli]

As you state, TX8/RX5 indicates "normal" transmit and receive operation. But other numbers suggest that you may have a minor pointing problem. The 256k 2/3 (TC) is your Rate Code (transmit symbol rate 256k, FEC rate code 2/3, turbo-code enabled). I'd have to know which Rate Codes are authorized in your account, but mine almost always runs at its max authorized 256k 4/5 (TC). I also noted that your Modcod shifted from 15 to 16. I'd have to know your typical signal strength however, to conclude what is normal. But the two sets of numbers combined suggest a slight dish pointing error, my guess would be in the POL angle.

Could you go to xxx and post what's displayed there? Then look at the left column on your screen. Click on Diagnostics. When the dropdown list appears, select Hourly History. Any red X marks?

//greg//

Thank you so much. I would have replied right away but I was away for a few days. I really appreciate your help!!!

Our normal blue sky signal strength peaks at 91 and it's often there or close. We're in the Amazon so we do get a lot of cloud cover and rain at times. But the issues we've been having happen even on perfect weather days and nights. Sometimes our RX strength does drop for no apparent reason (no clouds or obstruction).

I've had a great deal of trouble getting the POL right here. We've tried a few different antennas, and right now we're using an antenna that was provided by our ISP. Since we started using this company, Bantel, which resells Hughesnet service, we've had to change satellites a few times. In the past we spent days with Bantel trying to get the POL correct after changing satellites and pointing the antenna, and they finally just gave up and we stopped trying to get the POL better even though we really weren't getting the kind of isolation we should have been getting. In fact the isolation/POL alignment seemed to change for no apparent reason. The last time we changed satellites I just rotated the ODU for strongest RX and when Bantel checked our isolation they said it was fine and we never touched it again. It seemed too easy. What's strange is the POL angle is way off from what Bantel said it should be and what sites like dishpointer.com said it should be.

Under Diagnostics I don't have "hourly history".

I attached a screen shot of our "advanced" page.

Our ISP Bantel just said tonight that they want to try replacing our cables between the modem and ODU

Thanks so much for your help!

Please let me know if there's anything else I could provide that would help you diagnose our system.

Greg

 

[grohgreg]

Whereas your transmission error percentage of 0.73 isn't sufficient to open a trouble ticket, it's higher than it should be. That number is derived from that pair in the upper right. The larger number is the number of packets processed during the modem up time, the smaller is the number of errors. My error rate for example, is at 0.07% after nearly 15 days up time. Combine that the the lower than expected Rate code while receiving a strong signal, and it spells isolation problem. It's more evidence to me that you've got a POL angle issue. Consider the possibility that you may have inadvertently rotated to a negative value rather than a positive (or vice versa depending upon which side of the equator you're on).

Can you go back to http://192.168.0.1/fs/advanced/advanced.html then click Transmitter and Allowed Inroutes. Notice which Rate Codes have green balls in the associated box. What you should be expecting is the lowest green ball in the farthest right column, all other green balls are considered "fallback" rates.

//greg//

 

[takoateli]

Whereas your transmission error percentage of 0.73 isn't sufficient to open a trouble ticket, it's higher than it should be. That number is derived from that pair in the upper right. The larger number is the number of packets processed during the modem up time, the smaller is the number of errors. My error rate for example, is at 0.07% after nearly 15 days up time. Combine that the the lower than expected Rate code while receiving a strong signal, and it spells isolation problem. It's more evidence to me that you've got a POL angle issue. Consider the possibility that you may have inadvertently rotated to a negative value rather than a positive (or vice versa depending upon which side of the equator you're on).

Can you go back to xxx then click Transmitter and Allowed Inroutes. Notice which Rate Codes have green balls in the associated box. What you should be expecting is the lowest green ball in the farthest right column, all other green balls are considered "fallback" rates.

//greg//

Again thanks so much! I really appreciate it!

When I set the POL I used the recommended setting but couldn't even find the satellite in that position. I found the satellite with the POL about 90?out from what it should have been according to all sources.

Attached is a screen shot of our allowed inroutes


Thanks again!
Greg

 

[grohgreg]

Wow, that's worse than I thought. According to that, you should be transmitting at 2048k 4/5 FEC (TC). Whatever's wrong has dropped you back 4 fallback modes. Do you rotate the dish or the TRIA to obtain your POL angle? If you have a choice, the TRIA should be set to zero degrees of POL, and the dish rotated. Only if the dish is fixed should you rotate the TRIA. Which way did you do it? Weak/failing transmitter and/or cable problems can cause this problem too, but we should eliminate POL from the equation before adding them to the stew.

In the interest of further analysis, what is the latitude and longitude of the dish? Diameter? Transmitter power rating in watts? Cable type and length of run? Method of grounding?

Oh, and I forgot to ask earlier; with a signal strength of 91, does your Modcod improve? My own signal strength - depending upon conditions - ranges between 78 and 87. Within that window, Modcod stays pretty consistently 8-PSK 5/6 (15) likw yours. That's normal. But on those occasions when the signal rises to 91-92, the Modcod adjusts upward to the max 8-PSK 9/10 (17). Signal strength 91 suggests that your AZ and EL were good. But your original screen shot showed you operating at only the 3rd best of the 17 available Modcods. If it never gets better, that's another symptom.

//greg//

 

[takoateli]

Greg, again, thanks so much! I can't tell you how much I appreciate your help!

I rotate the TRIA for POL. When you say rotate the dish, I'm assuming you don't mean rotate it to set the azimuth. I'm assuming there's dishes where the entire dish rotates around it's center point without changing azimuth. Is that correct? In any case, I rotate the TRIA for POL.

The dish is at about 3N and 65W.

The transmitter is 2W. The grounding is through the base of the dish itself. The cable is about 100' or less. I can measure it. It came from the ISP pre-made.

I never see our modcod beter than 16. I'll watch it more closely.

The modem has a public IP address. If I can personal message you on this board I'll send you the IP address so you can take a look at it. If there's no way to PM on this board please email me: greg (at) ihnen . me

You can see pictures of the dish at greg ihnen . me / my-work-here/satellite-internet

Thanks again!

Greg

 

[takoateli]

Greg,

Here's some more info. I decided to swap out the RF cables between the modem and the ODU. Initially I thought it was an improvement because our "stream error rate" went down. But performance wasn't any better. Voice calls still had problems with people on the other end not hearing us well, email not moving mail like it should and web pages loading slowly. Then we had a rain storm pass. We had a rain fade and lost connectivity. RX dropped into the 30's. Then the rain passed and RX signals came up, but our status remained red/error. The error listed was TX error code 17. Rebooting the system remotely via the web GUI and manually by interrupting power didn't clear the issue. However, a manual forcing of ranging got us back on the air. But now our "stream error rate" is super high at 44%.

We do have some spare BUCs from a previous provider. I'm thinking of swapping out the BUC and seeing if that helps. We might even have a LNB for the frequencies we're using.

What do you suggest?

Thanks!
Greg

 

[grohgreg]

Ok, check'd the web photo. I see part of the problem straight away. Rough calculations specify a POL angle of approx -85 degrees. A negative number means you rotate the TRIA clockwise on the bracket scale. That's clockwise as viewed from in front of the dish. Your TRIA is rotated counter-clockwise. Clockwise and counter-clockwise depends upon the perspective. When you set POL at the TRIA, -85 degrees means rotate the TRIA clockwise as viewed from the front. On other dishes, POL is set by rotating the dish. In those cases, -85 degrees means rotate the dish counter-clockwise as viewed from the back.

Another issue is your pointing technique. POL angle is related to transmitter isolation, it is technically unrelated to receive signal strength. Physically, it can in fact affect receive signal strength. But technically it's a function of the transmit half of your connection. So to peak signal strength by altering the POL angle is actually counter-productive. Since we've got a working email link now, I'll provide more details offline

//greg//

 

[AlanRT]

Greg,

One issue that might be temporarily skewing your error rates is that you're just completing a week of sun outage at your latitude. This would have driven up your error rates and made your system unusable for a few minutes each day. Should be over after tomorrow.

Didn't catch your satellite but here is an example of approximate outage durations for your area (times shown are CST for 65W)

Predicted | Durat.| Starting | Ending
mm/dd/yyyy | mm:ss | hh:mm:ss | hh:mm:ss|
-----------|-------|----------|---------|
03/15/2012 | 06:55 | 10:25:24 | 10:32:19
03/16/2012 | 10:05 | 10:23:32 | 10:33:37
03/17/2012 | 11:35 | 10:22:32 | 10:34:07
03/18/2012 | 12:05 | 10:21:58 | 10:34:03
03/19/2012 | 11:50 | 10:21:48 | 10:33:38
03/20/2012 | 10:45 | 10:22:02 | 10:32:47
03/21/2012 | 08:20 | 10:22:56 | 10:31:16
03/22/2012 | 01:50 | 10:25:53 | 10:27:43

 

[AlanRT]

BTW, good on you for the work you're doing there.

 

[takoateli]

Ok, check'd the web photo. I see part of the problem straight away. Rough calculations specify a POL angle of approx -85 degrees. A negative number means you rotate the TRIA clockwise on the bracket scale. That's clockwise as viewed from in front of the dish. Your TRIA is rotated counter-clockwise. Clockwise and counter-clockwise depends upon the perspective. When you set POL at the TRIA, -85 degrees means rotate the TRIA clockwise as viewed from the front. On other dishes, POL is set by rotating the dish. In those cases, -85 degrees means rotate the dish counter-clockwise as viewed from the back.

Thanks! So know how do I read POL? I'm assuming that since this dish is a complete unit with ODU as a single package that I should be able to read the graduated marks on the ODU mounting bracket. I don't know whether I read the mark at the top (12 o'clock) or bottom (six o'clock) to get the angle, but I'm guessing the bottom mark. With the ODU not rotated at all the bottom mark points to 0?. The problem is if I point the ODU at +85 or -85 either way my signal strength drops into the 20's or 30's and I lose connectivity. When we switched to this satellite I only happened to stumble across the satellite after searching the sky for a long time and finally I started skewing the POL and searching.

One assumption I make about the POL is that I believe TX and RX are skewed 180?for frequency reuse, and when RX is properly aligned so is the TX. So if one tunes for max RX signal they're getting the TX POL very close. Is that an incorrect assumption?

I know that in working with Bantel when they couldn't get the POL/isolation good enough by directing me finally they told me to just tune for max RX and see what we get.

Greg

 

[takoateli]

Greg,

One issue that might be temporarily skewing your error rates is that you're just completing a week of sun outage at your latitude. This would have driven up your error rates and made your system unusable for a few minutes each day. Should be over after tomorrow.

Didn't catch your satellite but here is an example of approximate outage durations for your area (times shown are CST for 65W)

Predicted | Durat.| Starting | Ending
mm/dd/yyyy | mm:ss | hh:mm:ss | hh:mm:ss|
-----------|-------|----------|---------|
03/15/2012 | 06:55 | 10:25:24 | 10:32:19
03/16/2012 | 10:05 | 10:23:32 | 10:33:37
03/17/2012 | 11:35 | 10:22:32 | 10:34:07
03/18/2012 | 12:05 | 10:21:58 | 10:34:03
03/19/2012 | 11:50 | 10:21:48 | 10:33:38
03/20/2012 | 10:45 | 10:22:02 | 10:32:47
03/21/2012 | 08:20 | 10:22:56 | 10:31:16
03/22/2012 | 01:50 | 10:25:53 | 10:27:43

Thanks! I don't think that's it. We've been having problems for along time and all throughout the day and night.

We're on a satellite at 30W. We changed from Intelsat 903 to HispaSat Amazonas II if I remember correctly. I think that's our current satellite. We had better service on IntelSat 903.

Greg

 

[takoateli]

Today I tried putting some 2W Ku band BUCs in place of the Hughes BUC which is unmarked except for a CE number (the UL of the EU correct?). Anyway, they didn't work.

So what kind of a Ku band BUC does Hughesnet use? An "extended" frequency range one?

Thanks!
Greg

 

[grohgreg]

You have to have a transmitter that understands what the modem is telling it. Your spare may be on the wrong freq or using the wrong polarization, or any number of non-responsive reasons. Maybe it doesn't even understand the command to "send". Maybe it attaches to the feed arm in such a way that the focal length and feed angle are outa spec. All of this is basically cart in front of the horse stuff anyway.

You've got to get back to the pointing angles. Unless/until they're optimized, there's no point at all in swapping hardware. All that's spelled out in my email

//greg//

 

[takoateli]

You have to have a transmitter that understands what the modem is telling it. Your spare may be on the wrong freq or using the wrong polarization, or any number of non-responsive reasons. Maybe it doesn't even understand the command to "send". Maybe it attaches to the feed arm in such a way that the focal length and feed angle are outa spec. All of this is basically cart in front of the horse stuff anyway.

You've got to get back to the pointing angles. Unless/until they're optimized, there's no point at all in swapping hardware. All that's spelled out in my email

//greg//

Greg,

Thanks! I really appreciate all the help!

My understanding is that the BUC is just an upconverter which runs a certain IF, and what ever RF you send on the coax gets mixed with the IF and goes out the microwave port. But then again, the HN7000 modem has settings for about 20 different BUCs, so obviously there's important differences.

I'll get to your emails now. I was busy today with working on the satellite system, and also finishing my home made diesel outboard long shaft outboard motor. The plan is to go down river and get palm fronts for my roof. My roof needs to be "re-shingled". : - )

I feel bad that we've taken the thread off list to email. Should I post back here about the contents of your email, to keep the thread whole and complete for posterity?

Greg

 

[grohgreg]

In my opinion, the important thing to publish for posterity is the solution. Between there and there are likely to be a lot of trial and error and red herrings that can confuse those who use search engines for solutions. Too many folks have subscribed to the notion that - if it's on the internet, it must be true. For that crowd, none of the story is better than just part - especially if the person searching doesn't realize he/she just found the wrong answer. The other reason is simple selfishness - again opinion - I consider email to be more expressive than forum dialogue (diagrams/photos/attachments/blue language/etc).

A VSAT BUC is basically a radio frequency transmitter. The output of the modem constitutes the IF (intermediate frequency). In this case it's L-band, between 0950MHz and 1500MHz. It travels between the modem and the transmitter on coaxial cable. At this point it's still at the milliwatt level. When it gets to the transmitter, it's not yet polarized. First it gets mixed in the LO section (local oscillator) which adds xx.xxxGHz. That product then goes into the up convertor section which adds another x.xxGHz and amplifies. This separation is part of what keeps the TX frequency from interfering with the RX frequency. I don't know the 30W satellite characteristics, so I'll describe the sequence of events on mine. The uplink signal starts out as DC from my keyboard, gets converted by the modem to 1010MHz, travels via cable to the transmitter, gets mixed in the LO to produce 11.760 GHz, then up-converted to 14.060GHz and amplified to 2 watts. Now it gets polarized IAW the satellite frequency plan. My default output is horizontal. If vertical is required, a mechanical shim must be installed at the RF output of the transmitter. The reason that not all BUCs are compatible with HughesNet is that they don't necessarily all use the the same IFL, and/or the same LOF, and/or the same up convertor freq, and/or the same polarization technique, et cetera. Even they are compatible in all that, they may not attach in the correct location/position on the feedarm. That usually results in an incorrect focal angle and/or focal length. If however your spare BUC(s) were given to you by the provider, it's not unreasonable to expect they're compatible with both the modem and the assigned satellite.

//greg//

 

[takoateli]

I just put some more pics of the antenna at Satellite Internet Problems | gregihnen.me

Greg

 

[grohgreg]

Photo 1; weatherproofing as discussed in email. Once the caulk harders, it expands and contracts at a different rate than the metal connector. Gaps form, water between goop and connector. Plus, it's not likely dielectric.
Photo 2: (a) transmitter is upside down in bracket. That's why you're confused about POL angle.
(b) TRIA bracket may not be in the correct position relative to the reflector (wrong bolt holes used). This negatively affects focal length and focal angle (hits the dish in the wrong place). Select your dish from here; determine if your TRIA placement on the feedarm is correct.
Photo 9: self-fusing tape only serves to further seal in any moisture that may already be present between the goop and the metal.

//greg//

 

[takoateli]

Photo 1; weatherproofing as discussed in email. Once the caulk harders, it expands and contracts at a different rate than the metal connector. Gaps form, water between goop and connector. Plus, it's not likely dielectric.
Photo 2: (a) transmitter is upside down in bracket. That's why you're confused about POL angle.
(b) TRIA bracket may not be in the correct position relative to the reflector (wrong bolt holes used). This negatively affects focal length and focal angle (hits the dish in the wrong place). Select your dish from here; determine if your TRIA placement on the feedarm is correct.
Photo 9: self-fusing tape only serves to further seal in any moisture that may already be present between the goop and the metal.

//greg//

Greg, thanks so much! The process I had used was first the self-vulcanizing rubber tape, then the silicone over that just to provide a second layer, not the other way around. The self-vulcanizing tape seals the connection, the silicone is just a second line of defense. This time I'll just do the self vulcanizing tape. I do have "Coax Seal", the space-age black silly putty that never gets hard and remains soft and tacky forever. It's a great connector sealant but it is messy. I prefer to put some kind of tape down first and then something like that to facilitate removal. You just cut all the way through what ever is on the outside (Coax Seal, silicone, what ever) and then through the tape and peel away. There's also a 3M product called Scotchcoat (not sure of the spelling) that's made to seal underwater connections, but it's super messy. Putting down tape first is a must and don't get it on anything else.

About the feed horn position, I know I did it right as per the instructions that came with it, but I'll see if I can get the instructions again from the company. I'll also try and identify the antenna from the General Dynamics link you sent.

Thanks again!
Greg