SatSig topic:

Turbo Code 256K 2/3

(Read 14441 times)

Feb 23^rd, 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)

Feb 23^rd, 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)

Feb 23^rd, 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//

Feb 23^rd, 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.

Feb 23^rd, 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.

Feb 23^rd, 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//

Feb 23^rd, 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

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)

Feb 23^rd, 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//

Feb 23^rd, 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.

Feb 23^rd, 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

Feb 23^rd, 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.

Feb 23^rd, 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//

Feb 24^th, 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.

Feb 24^th, 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//

Feb 24^th, 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.

Feb 24^th, 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.

Feb 24^th, 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.

Feb 24^th, 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.

Feb 24^th, 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//

Feb 24^th, 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.

Feb 24^th, 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.

Feb 24^th, 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//

Feb 24^th, 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.

Feb 24^th, 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//

Mar 18^th, 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//