Advertisment: Broadband via satellite
Advertisment: Worldwide satellite services from Ground Control Company

www.satsig.net

Satellite Internet Forum.

Welcome, Guest.        Forum rules.
      Home            Login            Register          
  Satellite Internet forum › HughesNet and Hughes HX VSATs › Turbo Code 256K 2/3
Pages: 1

Turbo Code 256K 2/3

(Read 13652 times)
bray620
Member
★★
Offline



Posts: 13
Feb 23rd, 2010 at 5:09pm  
We have had our Dual 4000 package up for 3 days now and we have never been able to get on the Turbo Code 256K 4/5. It fails everytime we range it. I have been working with BW on the issue, but so far they haven't had an answer for the issue. I see that other people have had this issue as well and was wondering if there was a fix for it. Both my modems are on 2/3 with 4/5 failing.

Satellite Statistics Summary

------------------------------------
Network Time: TUE FEB 23 17:07:18 2010
------------------------------------

Adapter Main Statistics:
------------------------
Signal Strength.............. 91      Stream Msg-Ackd/Nakd........ 83381/1540
Flags............... 0x00000000       NonStream Msg-Ackd/Nakd..... 374/72
Stream Error Rate.......   1.81%      NonStream Error Rate.......  16.14%
UpTime (d:h:m:s).. 000:04:06:00       Aloha Starts................ 366
WakeUp Aloha Starts.......... 1       Ranging Starts.............. 0
Transport Alarm Bit..... 0x0000       Frames Received............. 1897128
Addresses Open............... 7       Frame Errors: CRC/Bad Key... 12/0
Carrier Info....... 021:E:13781       Miscellaneous Problems...... 150
Rate Code........  256k 2/3 (TC)      No Receive Outroute Lock.... 20
Inroute Group................ 1       No FLL Lock................. 472
Inroute..................... -1       No Network Timing Sync...... 380
IQoS ID...................... 1       Current Modcod............... 8-PSK 8/9 (16)

Ranging Reason: Ranging Done
Inroute Group Selection: Ranged at inroute rate selected by IQoS

Receive Status:  Receiver operational.  (RxCode 5)
Transmit Status: Transmitter ready. (TxCode 8)
Back to top
 
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #1 - Feb 23rd, 2010 at 5:11pm  
The other modem as well.

------------------------------------
Network Time: TUE FEB 23 17:07:41 2010
------------------------------------

Adapter Main Statistics:
------------------------
Signal Strength.............. 92      Stream Msg-Ackd/Nakd........ 88306/4314
Flags............... 0x00000500       NonStream Msg-Ackd/Nakd..... 154/24
Stream Error Rate.......   4.66%      NonStream Error Rate.......  13.48%
UpTime (d:h:m:s).. 001:14:16:18       Aloha Starts................ 155
WakeUp Aloha Starts.......... 0       Ranging Starts.............. 0
Transport Alarm Bit..... 0x0000       Frames Received............. 1580639
Addresses Open............... 7       Frame Errors: CRC/Bad Key... 9/0
Carrier Info....... 021:E:13781       Miscellaneous Problems...... 152
Rate Code........  256k 2/3 (TC)      No Receive Outroute Lock.... 0
Inroute Group................ 1       No FLL Lock................. 0
Inroute..................... -1       No Network Timing Sync...... 790
IQoS ID...................... 1       Current Modcod............... 8-PSK 8/9 (16)

Ranging Reason: Ranging Done
Inroute Group Selection: Not getting IQoS Maps or IQoS value is not in map

Receive Status:  Receiver operational.  (RxCode 5)
Transmit Status: Transmitter ready. (TxCode 8)
Back to top
 
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #2 - Feb 23rd, 2010 at 5:18pm  
The stream error rate is excessive. Mine runs typically under 0.03%. In most cases, that points to a bad POL angle. POL should be optimized first. If that doesn't bring the error rate to within an acceptable level, there are other potential TX path issues that can be addressed.

//greg//
Back to top
 
USN (Ret)
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #3 - Feb 23rd, 2010 at 5:27pm  
I sent BW pictures today of both my dishes today and they told me it was correct. The error rate was all the way at 10% on both dishes yesterday.
Back to top
« Last Edit: Feb 27th, 2015 at 12:09pm by Admin1 »  
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #4 - Feb 23rd, 2010 at 5:32pm  
We tried setting the Pol by using the back of the dish but we were told to set it back to 0 today and just rotate the LNB by BW.

...

...
Back to top
« Last Edit: Feb 27th, 2015 at 12:18pm by Admin1 »  
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #5 - Feb 23rd, 2010 at 6:07pm  
I'm not sure why BW told you to do that. Do you have the newer 1.2m Prodelin dish with a large polarization scale on a gray plastic wedge behind the dish - and a feed horn throat marked with a "505" ?

If yes, the site owner has repeatedly advised that the feed horn must be set so that the 505 is always directly away from the feed arm. The fat lump on the opposite side of the feed throat will be directly underneath towards the feed support arm. This applies regardless of polarization setting. And that the polarization should be set by turning the entire dish

If you have different equipment, disregard.

If POL optimization does NOT subsequently lower the error rate, troubleshooting should be then concentrated on an issue in the transmit path.

//greg//
Back to top
« Last Edit: Jul 3rd, 2020 at 9:50am by Admin1 »  
USN (Ret)
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #6 - Feb 23rd, 2010 at 6:45pm  
Yes I do have the dish that is able to rotate in the back. We set it to +48 today on the back and we could not get it to transmit while locked onto the bird. I'm gonna try to upload a few pics and I would appreciate if you could tell me which way our LNB needs to be for Vertical Receive polarization.

In the picture below this is what we thought the dish should be set to. We could not get the dish to transmit at this position even though we would have a 90 signal strength locked. The settings we were given are the following:

PoL +48
Recieve Pol: Vertical
Transmit Pol: Horizontal

HX

Here is what we put the dish back too and we were able to get it to work pretty easily, although with a poor Stream Error and slow speeds. The dish is set to 0 degrees in this picture, straight up and down.

...

(images edited by forum admin)
Back to top
« Last Edit: Feb 27th, 2015 at 12:17pm by Admin1 »  
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #7 - Feb 23rd, 2010 at 7:07pm  
Check your satellite parameters. 21E is AfriStar1. I'm wondering if you shouldn't be on EuTelSat W6 at 21.6E. And that frequency 13781 frequency doesn't compute. Just a guess mind you, my perspective is from CONUS. But it just doesn't look right.

Did BW ever tell you that they've actually SEEN your signal?

//greg//
Back to top
 
USN (Ret)
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #8 - Feb 23rd, 2010 at 7:15pm  
I'm not 100% sure if they looked at them or not, they seemed very busy today. I am supposed to be on 21.6 W6. From what I posted above it looks like I'm on the wrong bird even though my Sat Meter I got from them tells me I'm on W6.
Back to top
« Last Edit: Feb 27th, 2015 at 12:18pm by Admin1 »  
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #9 - Feb 23rd, 2010 at 7:22pm  
Here are the parameters they sent me:

Satellite Longitude 21 Degrees East
Satellite Frequency 13781
Symbol Rate 9000000
LNB 22KHz Switch Off
DVB Mode DVB S2 ACM
Frequency Band KU/QPSK
Receive Pol Vertical
Transmit Pol Horizontal
Back to top
 
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #10 - Feb 23rd, 2010 at 7:30pm  
I think I'm on the correct one, I got to Bentley Walker and enter my ESN and select w6 and it shows my details.
Back to top
« Last Edit: Feb 27th, 2015 at 12:21pm by Admin1 »  
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #11 - Feb 23rd, 2010 at 7:35pm  
Well, see - that's the deal. Your meter may tell you you're pointed at W6. But it seems to me like your modem thinks it's looking at AfriStar1. If BW has your actual signal on W6, never the twain shall meet. That said, maybe your modem statistics don't reflect decimal longitudinal values (although I'd expect it to round 21.6 up to 22). I think this is worth bringing to the attention of BW, if for no other reason than clarification.

If it's just my misinterpretation of your modem stats, we can move on. I believe it's important to confirm that BW has actually identified your specific signal on W6. At the same time, they can perform crosspol measurements. That will determine whether or not your transmitter isolation (POL angle) is acceptable. If the answer to all of the above is yes, then we move on to troubleshooting the transmit path.

Oh yeah, and I'd still like to confirm whether or not you can find "505" cast into that waveguide connector. It's about 2" long, pieced in right between the feedhorn throat and the OMT/filter. If no, we can move on. If yes, we have to confirm that it's rotated correctly.

//greg//
Back to top
« Last Edit: Feb 27th, 2015 at 12:20pm by Admin1 »  
USN (Ret)
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #12 - Feb 24th, 2010 at 2:58am  
Yes, we have the "505" on the waveguid connector. It was directly on top of the Feed arm assembly like this site suggest, but its now rotated now that we have changed the LNB to the +48 degree angle.
Back to top
« Last Edit: Feb 27th, 2015 at 12:20pm by Admin1 »  
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #13 - Feb 24th, 2010 at 4:20am  
Ok, except the site also recommends rotating the dish rather than the TRIA. Other than I don't think we can do much more until you hear from BW about the satellite parameters (the Carrier Info....... 021:E:13781 part), and their detection and subsequent crosspol evaluation of your signal

//greg//
Back to top
 
USN (Ret)
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #14 - Feb 24th, 2010 at 5:28am  
I understand the rotating of the dish and I tried that yesterday. I wasn't complaining or anything about the support I'm receiving from you if thats how you took it, I was just saying I had the "505" directly on top of the Feed Arm like this site suggests before BW told me to rotate the LNB. I'm going to call them today and verify all my settings are correct. I have also found pictures from Eric in another post with the correct way to have it set for Vertical Receive Pol. Mine is currently incorrect.
Back to top
« Last Edit: Feb 27th, 2015 at 12:20pm by Admin1 »  
 
IP Logged
 
James-BW
Senior Member
★★★
Offline



Posts: 65
Reply #15 - Feb 24th, 2010 at 9:16am  
Good morning Sir,

I have sent you an emailed with regard to troubleshooting the site we will conduct some live testing on your TX chain to determine if there are any outstanding issues.

@USN-Retired

The Hughes HN/HX modems do not accept decimal input for the satellite so it will be listed as 21 opposed to 21.6. This does not impact upon the pointing but is worth noting.
Back to top
 
www.freedomsat.com a high-speed Satellite Internet solution that delivers fast and reliable internet to difficult to connect spots around the world.
WWW  
IP Logged
 
Admin1
YaBB Admin
★★★★★
Offline



Posts: 1203
Reply #16 - Feb 24th, 2010 at 9:18am  
Polarisation:

This picture below shows the result of adjusting the dish +45 deg clockwise, having initially set nominal vertical receive polarisation (LNB at one side). The direction clockwise (+) refers to your view, standing behind the dish and facing towards the satellite in the sky, towards the south west in this case.
...
The giant circular scale behind the dish will read 45 deg.

From this image it is not possible to see the orientation of the 505 or fat lump on the feed throat. The 505 must always be directly away from the feed arm. The fat lump must always be directly towards the feed arm.

Best regards, Eric.
Back to top
« Last Edit: Jul 3rd, 2020 at 9:50am by Admin1 »  
WWW  
IP Logged
 
Admin1
YaBB Admin
★★★★★
Offline



Posts: 1203
Reply #17 - Feb 24th, 2010 at 9:27am  
Peaking up and transmit signal:

You peak up the pointing, azimuth and elevation, using the receive signal from the satellite. You see numbers like 91, 92 etc.

It is important to get to the exact centre as the transmit beam is narrower than the receive beam. This is not easy as the top of the beam is rounded. It may help to degrade the signal down to say exactly 70 on either side of the beam and then physically set the antenna to the middle mechanically. In elevation, mark one flat on the nut with felt tip pen and count the flats between the two 70 positions. Then half the number and set to the middle. A similar process can be applied in azimuth but you must start by going back and always moving in the same direction as there is backlash.

Best regards, Eric.
Back to top
« Last Edit: Jul 3rd, 2020 at 9:50am by Admin1 »  
WWW  
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #18 - Feb 24th, 2010 at 11:30am  
Not a problem, I was just trying to dot all the tees and cross all the eyes while waiting for BW to get back in the game. Eric by the way, is the owner of this site. I just watch a few of the forum categories for him. If/when those stream errors don't rectify after POL optimization, I'm still standing by to assist with the TX path. If necessary, we'll do a little loop resistivity testing.

//greg//
Back to top
« Last Edit: Feb 27th, 2015 at 12:25pm by Admin1 »  
USN (Ret)
 
IP Logged
 
Eric Johnston
Senior Member
★★★
Offline



Posts: 2109
Reply #19 - Feb 24th, 2010 at 12:20pm  
Stream traffic is what happens after the remote site has initiated a transmit data transfer and is using an assigned set of time slots for a series of transmit bursts. This stream may be interrupted by occasional ALOHA bursts from other sites, slight interference or just normal noise, leading to up to 10% stream error rate. If it is regularly above 10%, give BW a call.

Non-stream traffic is when the remote site is making initial random ALOHA requests and it is expected that many of these will fail, perhaps 40 - 50%. As soon as one gets through the hub can then assign time slots for the subsequent stream traffic.

Note that both stream and non-stream errors will be caused by a low transmit signal. This can be due to BUC cable connectors, pointing or polarisation at the remote site. A low transmit signal or rain at either end will also cause the modulation to drop back to 2/3 FEC rather than say 4/5 or 5/6 or whatever higher is possible FEC in clear sky with good pointing. Using lower rate FEC makes your signal better at getting through in difficult conditions.

Bentley Walker keep a watch on these error rates and several sites have recently had their figures improved following dish adjustments. I've just spoken with James at BW about this. If you have concern about your site give them a call. Their tech support no is +44 2392 311 118

Best regards, Eric.
Back to top
« Last Edit: Jul 3rd, 2020 at 9:51am by Admin1 »  
 
IP Logged
 
bray620
Member
★★
Offline



Posts: 13
Reply #20 - Feb 24th, 2010 at 2:13pm  
James helped me for a good 3 hours today over MSN messenger. We are able to get both dishes down to less than a 1% error rate. I am still stuck on 2/3 but this was  due to me having to go back to work. I appreciate all the support you guys have given. I'm hoping to have time in the next couple days to try and push it into the 4/5 Turbo Code. I also have 1 dish set up like James requested me to put it at and one the way Sat Sig recommended.
Back to top
 
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #21 - Feb 24th, 2010 at 2:40pm  
Eric wrote
Quote:
Stream traffic is what happens after the remote site has initiated a transmit data transfer and is using an assigned set of time slots for a series of transmit bursts. This stream may be interrupted by occasional ALOHA bursts from other sites, slight interference or just normal noise, leading to up to 10% stream error rate. If it is regularly above 10%, give BW a call.
That would be a definition I'd associate with non-stream errors Eric. I look at it more like this:
non-stream errors: those detected/recorded across the entire input bandwidth. Possibly valuable in identifying local EMI/RFI (network data). The vast majority of this data is simply shunted.
stream errors: those detected/recorded within the stream that is actually extracted from the input bandwidth (data unique to the user) and subsequently sent to the Ethernet output port

Note that the modem statistics list dozens of trigger points for key performance parameters. They're listed under the Advanced Configuration. Open the dropdown list to Diagnostics/Expert/General/Config. On the page that opens scroll down to Statistics Classification Thresholds. Note the Stream NAK to ACK ratio category reflects triggers for minor alarm at 1.0% and a major at 5.0%.

As I mentioned above, mine typically runs below 0.03%. During nearly 11 days since the last modem restart, it's at 0.02818%. I'm wondering if your definition may pertain to non-stream errors. Mine typically run slightly over 10%, but I have found no performance-related reason to pay any attention to them. Note that they don't even rate mention on the thresholds list.

//greg//
Back to top
« Last Edit: Feb 19th, 2015 at 8:52pm by Admin1 »  
USN (Ret)
 
IP Logged
 
Eric Johnston
Senior Member
★★★
Offline



Posts: 2109
Reply #22 - Feb 24th, 2010 at 3:36pm  
Maybe I'm wrong. I thought that these stream and non-stream % figures referred to the transmit direction from the remote site to the hub.

If I understand BW correctly, the non-stream traffic is the random ALOHA transmit attempts from the remote which obviously have a high chance of collision at the satellite, compared with the stream traffic, where the remote is transmitting a series of bursts into assigned time slots, where there is lower probablilty of collisions.

Regarding the outbound carrier towards the remote sites, with SQF=90+ I would have thought that the bit error rate would be virtually nil, whether measured for over the full modem receive carrier (e.g. 11 Mbit/s) or just over the packets extracted at that particular site.

If anyone is concerned about the performance of their system please contact Bentley Walker.

Best regards, Eric.
Back to top
« Last Edit: Jul 3rd, 2020 at 9:51am by Admin1 »  
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #23 - Feb 24th, 2010 at 4:08pm  
Yeah, in hindsight I got the directionality of the stream errors backwards. The true definitions probably lie somewhere between your understanding and mine. But I think the stream error rate thresholds stored in the modem GUI speak for themselves

//greg//
Back to top
 
USN (Ret)
 
IP Logged
 
USN - Retired
YaBB Moderator
★★★★★
Offline



Posts: 837
Kentucky (USA)
Reply #24 - Mar 18th, 2010 at 12:30pm  
USN - Retired  wrote
Quote:
Yeah, in hindsight I got the directionality of the stream errors backwards. The true definitions probably lie somewhere between your understanding and mine. But I think the stream error rate thresholds stored in the modem GUI speak for themselves

//greg//

Upon reflection Eric, I believe we're both partially correct. You, in that the user modem introduces the test packets on the inroute. Me in that they (or the results) are quickly looped right back on the outroute. But since they carry the unique modem ID, they're classified "Stream" data - as opposed to everything else on the outroute that is not so identified ("Nonstream").

So perhaps my explanation would have been more accurate had I described "Stream" to be the (returned) test data unique to the modem that initiated it. "Nonstream" errors then would be all other errors detected across the general bandwidth.

//greg//
Back to top
« Last Edit: Feb 19th, 2015 at 8:53pm by Admin1 »  
USN (Ret)
 
IP Logged
 
Pages: 1

Email me: eric@satsig.net

Powered by YaBB 2.5.2!
YaBB Forum Software © 2000-. All Rights Reserved.

Disclaimer, Terms of Use and Privacy   Forum User Agreement   Forum rules   Cookie policy.