Uverse

From www.AA6E.net
Jump to: navigation, search

AT&T's U-Verse service delivers television (IPTV), telephone (VOIP), and Internet service. The most common installations are categorized as FTTN (Fiber to the Node). A node, also known as a VRAD, is installed in a neighborhood. Transmission from the node to the home is via VDSL2 technology (nominally up to 50 Mb/s) over existing telephone copper connections. Maximum bandwidth available varies according to distance from the node and cable quality, but service is generally said to be available up to 3500 feet from the node.

Previously, we had been Comcast subscribers. Comcast's service is a conventional CATV system, with Internet and VOIP services based on the DOCSIS v2 standard. We only used Comcast's TV service, however, since we were subcribers to AT&T's ADSL service for Internet access, and AT&T "POTS" for voice.

U-verse is much more challenging than cable in an Amateur Radio environment, where RF transmissions up to 1.5 kW are often seen in the HF frequency ranges that U-verse's VDSL2 signaling requires (0 - 8.4 MHz). These web pages describe my ongoing work to maximize compatibility between U-Verse and ham radio.

Contents

U-verse Evaluation at AA6E

These pages are to record our Uverse installation and to document compatibility experiments with Uverse and Amateur Radio operations. The data here obviously only apply to our particular circumstances. Your mileage may vary! (Items may appear to be somewhat randomly ordered. This is a combination of a technical log and some explanation of how the system is supposed to work.)

Installation date 9/21/2010
Location Branford CT
Line Length to Node 2,554 ft (as measured electrically by AT&T technician)
Service "U300" television with HD; "Max" Internet (12 Mb/s); VOIP telephone service
Equipment Residential Gateway (DSL modem): 2Wire 3800HGV-B s/n 301019033005 (now updated to 3801HGV)
Set Top Box (1): Motorola VIP1225 s/n MP91029FB5909 coax (HPNA) connection to RG
Profile 19,192 kbs downstream, 2,040 kbs upstream (19/2)
Available video up to 1 HD channel plus 3 SD channels, simultaneous.
Previous block diagram
AT&T U-Verse "triple play" installation at AA6E, 12/24/2010 - Block Diagram

The distance from the NID (box outside house) to the RG is about 30-35 ft, from the RG to STB is about 20-25 ft.

Activity Log

Apr. 18, 2013 Our local cable service, Comcast, is heavily discounting rates for U-Verse folks who switch into a 2-year cable contract. That's the signal I needed. We have closed the book on U-Verse. It was an interesting experiment. One one hand, it's amazing what can be delivered over simple twisted pair copper. At the end, we were getting a 39 Mb/s "raw rate", which was delivered a net downstream 25 Mb/s and 2 Mb/s up. Of that, we got 18 Mb/s Internet download, with the rest going to TV service (2 HD + 2 SD). (I know the bit rates don't seem to add up, but everything did work for the most part.) ATT U-Verse is well designed in many ways, with a good user interface, good customer support, etc.

On the other hand, the U-Verse service was definitely not happy with strong HF signals up through the 40M band, at least. While it is better now (more tolerant of HF "insults"), we experienced very high error counts, freezing pictures, etc., when I was on the air. The modem (residential gateway) is much less likely to go into reset mode (2 minutes to resync) than it was before. But even when I was NOT on the air, there were relatively frequent error bursts (perhaps several per day), leading to frozen TV and internet at awkward moments. There are no other known hams in the neighborhood, and the problems don't seem to correlate with weather. So go figure. Why do we need the aggravation?

We lasted as long as we did, because my Amateur Radio activity is only moderate, and my wife is good natured.

When our new 2-year cable stint is over, we will look around again. Will there ever be a FIOS-style option? Advanced wireless? Stay tuned.

Feb. 24, 2013 We have had fairly good U-Verse service for the past year, but it has been a year of relatively little ham radio activity, and almost no QRO (high power) operation. We continue with a "25/2 profile", which allows us up to 2 simultaneous HD channels and 18 Mb/s Internet download speed:

Current bitloading (2-2013)

About two weeks ago I was on the air on 40M, signing in to ECARS under moderately difficult conditions. I switched on the SB220 and ran with about 800 W PEP output for 5 or 10 minutes. This may have been the first QRO on 40M since the profile upgrade; I'm not sure. I wondered if I would see the same behavior I saw in earlier tests on 80M, where high power operation "blasted a hole" in the bit loading spectrum around the operating frequency. (At high enough power, I'd also cause the local RG to reset itself.)

But this did not happen with this month's operation. I did see very high "corrected" and "uncorrrected" error counts (using UV Realtime) and the TV probably froze for a short while, but there was no RG reset and there was no obvious impact on the bitloading spectrum. (This makes sense in a way, because most all of the bitloading is required to support 25/2. There aren't many channels that can be ignored.)

The (somewhat) good news is that U-Verse operation returned more or less to normal after my ECARS operation. Except not really, I had relatively frequent errors afterwards - many more than before the QRO operation. After a few days of relatively flaky U-Verse, I decided to reset the RG manually. That seemed to help for a week or so.

In the past week, U-Verse service degraded quite a bit (with no further ham activity on my end). It got to the point that our TV (and Internet and phone service!) was freezing every 10-20 minutes. It was bad enough that I called AT&T support. (That is pretty bad!) I had a good session with the support agent, who was able to perform a "port reset" which has now given us low error counts for several days. (I hesitate to say things are back to "normal", but they may be.)

So here is the current hypothesis about QRO SSB on 40 M with U-verse. You can do it, but U-verse will likely be clobbered during your transmissions. Both the RG and the remote AT&T DSLAM port (at curbside) seem to be degraded. They do recover to some extent after QRO interference, but they may not be able to give you back a reliable U-verse connection. Both an RG reset and a "port reset" (by AT&T agent) may be required to get you back to square one.

(Your mileage may vary. A lot seems to depend on your antenna system, the U-verse signal routing, filters you may have installed, etc.)

In other news, Comcast is offering us "$600 off" to switch back to cable. We may have to consider that.

March 2, 2012 After weeks of degraded service, with near-daily link retrains (2 minute outages, losing phone, Internet, and TV), I made another call to AT&T. It seems to help to call right after a service glitch, because their automatic system interrogates the RG and they apparently see all the same bad numbers that I see. Without making me speak to anyone in Bangalore (just the ATT voicemail system), they sent out a Tech the same day. He swapped out the old 3800HGV-B RG for a new 3801HGV. (He was reluctant to do that, because he thought the older models were somehow more stable.)

The new unit (including a new UPS backup unit) looks a lot better in terms of data from the UVRealtime software:

Old Modem Stats Page
New Modem Stats Page


Note that we are now getting 37.2 Mb/s downstream (13.8 dB received power level), when we had only 35.4 Mb/s (12.6 dB) before.

Bitloading shows useful channels up to about 7.5 MHz now, when it used to cut off below 6 MHz. (This may - or may not - mean more trouble when AA6E is operating on the 40 M band - 7.0 - 7.3 MHz.)

New Bitloading Graph


January, 2012 Maybe I spoke too soon? After months of relatively stable operation, winter has arrived, and we are seeing fairly frequent errors. Most are correctable, but a number are uncorrectable leading to Link Retrains in the worst case. Here is the UVRT error table (now using version 1.9.0.0) that greeted me when I started up this evening:

ErrorTable-2012-01-22-20-09-42.png

I must add that my transmitter has been off the air during these error sessions! Are we seeing some other ingress of interference? Has the line just degraded due to an intermittent connection, weather problems, or ...?

December, 2011 Year-end Update. As I passed the 1-year anniversary of getting the U-Verse service, it is useful to note how things are doing now. The Amateur Radio interference issues haven't changed much, but fortunately (?) I have not been active enough on the air (especially on 80 and 40 meters) to cause much trouble with our TV operation. What has changed is that AT&T's lines seem to have improved. We now get many fewer serious data errors and have had no unplanned resyncs for a long time now -- until the last few days when we've had some 20 link retrain events! We also had several days of unavailability after Hurricane / Tropical Storm Irene. (Our power was out, and the UPS battery threatened to fade, so I shut it down for much of the time. The U-Verse signal seemed to continue without interruption.)

The following display from UV Realtime shows an interesting development. We are now getting a maximum downstream bit rate over 32 Mb/s. Even though we are still working with a "19/2" profile (19Mb/s down, 2 Mb/s up), the software indicates that we ought to be able to step up to 25/2. This may be worth pursuing, although we wouldn't need the extra HD channel or extra Internet capability that would result.

DecUVRTprofile.png

May 5, 2011

The U-Verse retrain activity (with no ham radio work) has improved rather dramatically (see graph below). It appears that the network has really stabilized considerably. We just don't see the 2-minute outages that occur with a RG retrain. Now, that could be a real network improvement, or it could be an "accidentally" favorable RG training setting that just happens to be a lot better than anything it achieved before. I lean toward the former option, because the loss of sync and large error bursts we were seeing several times a day just don't seem to be there anymore.

None of this makes us feel good about Amateur Radio compatibility -- because I was off the air for all of the "good" time during the past several weeks. Yesterday (5/4), I tested 40 M transmission at all power levels. I could seriously upset my home CO detector (very loud!), but the RG sailed through. (I wasn't checking STB performance, so there could have been issues there.) On 80 M, the story was pretty similar to what we had before. I could apparently operate CW (key down for 30 s) at 100 W, and the RG would adapt. At higher power levels, 300 - 700 W, I could indeed kill the RG session.

One new wrinkle is that when the RG recovered its balance after my last 80 M test, it did not train very well. See following

MayUVRTprofile.png

The problem (if I understand correctly) is that the downstream "bits" (VDSL2 channels) are over-committed, i.e. > 100% are in use. This may signify an unstable configuration. If everybody wanted to use all the bits they were "entitled" to (TV, Internet, VOIP) the session would not work. Perhaps it would force a retrain. "Bits in use" is generally rather under 100% - maybe 90%. I have seen this behavior before, but retrains came often enough that it did not last long. Now, with our newly "stabilized" line (??), it's not clear how long the over-commitment will last. I suppose the worst that will happen is a forced retrain at some point, after which we should be back in the normal range -- if there is no RF interference.

I did a manual RG reset on 5/5 to see how much better it could get if it "forgot" about the bad RFI episode it had had. The result: Max Rate now 25,581 Kbps download. Line capacity 72.2%,. Max bits 6,164, Reserve bits 582, bits in use 90.6%. Much better.

March 28, 2011

We seem to have a pattern of multiple days with no RG retrain events, then a burst of activity for several days. But as of 4/25/2011, we have had over four weeks of no retraining! (There was little Amateur Radio activity in this period.) Here are some graphical results: (updated: 5/4/2011)

FebMarUVRTdate.png

It appears that the latest tech visit may have improved our connection's reliability. There are longer periods of sanity between error burst days. There has been no apparent effect on sensitivity to Amateur Radio transmissions, however. (These do not appear on this graph.)

FebMarUVRThour.png FebMarUVRTday.png

I checked the distribution of RG retrain events vs hour of day and day of week. This is definitely not a random distribution. There is a strong peak at 8 - 9 AM, but no clear dependence on day of week. Is this due to techs out there doing work on the lines? The error rate does not seem to correlate with hours of peak TV or Internet usage.

March 4, 2011

We had a period of 8 days (2/24 - 3/3) with no RG retrains. Remarkable! But I had not been on the air with Amateur Radio in that time. Time to get back on 40 and 80 meters. A little bit of operating on 40 M CW at up to 100 W showed no RG errors. (I was not checking the STB, but historically the STB has frozen my TV service with 40 M activity.) On 80 M, we are back to our old habits. As the operating power is increased, the FEC error rate increases. When I operate at "full" (100W) power, there are many FEC and CRC errors, and eventually the RG loses sync and enters its 2 minute retrain cycle. (This is not really full power. Full power here is 1,000W!)

After last night's activity was done, the RG seems to be back to its old habits. There have been at least 3 retrain events since ham transmissions ceased.

The appearance is that the RG trys to "anneal" its frequency channel assignments and may get itself into a sweet spot in the absence of local RF interference. It can go for many days without serious upset (only occasional small bursts of correctable FEC errors) until it is upset by strong local RF activity.

Feb. 27, 2011

We called for a tech visit to deal with our persistent retraining RG and marginal line conditions. The U-Verse tech arrived and very kindly agreed with my assessment that we have problems with our outside lines. He called in for an "I&R" truck (Installation and Repair, I think, a completely different organization within AT&T). The I&R fellow (also very friendly and interested in my issues) came on Feb. 15. He spent several hours working on our lines, interrupting service 6 or 8 times as (I imagine) he worked his way along our line back to the fiber node (VRAD). When he departed, I did a manual RG reset, and indeed the line quality looked better (higher max. bit rate). But over the course of a week, the RG trained itself back to a condition roughly the same as before. (Right now, we have 29,716 kbps downstream and 22.8 dB attenuation.)

Furthermore, we continue to get sporadic RG retrains about as often as before, averaging 2-3 per day. Sometimes, like the present moment, we may get 3 or 4 days without retrains, but then we go back to the old pattern.

Question to myself: Is there any correlation between retrain / error rates and my own TV/Internet operation? I shouldn't think so.

Feb. 4, 2011

Using an SRL QS1R SDR receiver to check upstream transmission. An current probe next to the RG-6 coax to/from NID provided a clear but weak spectrum. No strong peaks seen.

Jan. 20, 2011

After worrying a lot about ham radio ingress to the VDSL2 line, I have a different problem now (in addition to others, not instead!): On low-power 40 M transmission (WSPR mode at 10 W), I see almost complete breakup of TV. VDSL2 (RG) is not upset -- there are no FEC errors and no loss of sync. Phone and Internet service are fine, also. This appears to be an STB issue. It is an unfortunate fact that my HPNA coax runs parallel to the RG-213 antenna feed, about a foot away on the outside of the house. The HPNA run is now about 40 feet, after we reorganized our TV installation. I tried shortening the HPNA run temporarily. It helped, but only a little. I moved my Westel HPNA filter from the RG end to the STB end, and that did help. Now I can run reliably at 10 W, but not at 100 W. The STB seems surprisingly sensitive at 7038 +/- kHz. (I have tried filtering the power line and have eliminated the HDMI and HDTV as culprits.)

Jan. 4, 2011

After December tech visit, we may have quieted some of my ham-related ingress problems by switching to coax from the NID to the RG and by adding a few more filters. 40 meters is looking pretty good. However, the Max. Rate is down to 28,809 Kbs (at the moment) from over 32,000 Kbs before. That means we are running with 80.6% "bits in use" (19/2 profile). This is too high to allow for much channel reassignment. In particular, we may not be able to adapt well to 80 meter transmissions.

Even without any local ham activity (i.e., when the local op is watching TV!), we are getting service drop-outs (of the 2-minute recovery type). This are really unacceptable outages for "triple-play" service. They kill all Internet, telephone, and TV service, after all.

I expect to call in the trouble to AT&T again soon.

How VDSL2 (U-Verse) sends data

U-Verse uses VDSL2 standard signaling -- modulating each of up to 1972 carriers ("tones") with a certain portion of the digital data stream. The number of bits (bits/sample?) that are carried by each carrier tone is called the "bit loading".

You can monitor the bit loading through the RG's webserver (Settings -> Diagnostics -> DSL) i.e., http://192.168.1.254/xslt?PAGE=C_5_3 via standard IP address. A more useful display is available with the either of the monitor programs U-Verse Realtime or VDSL Monitor. (See software list below.)

More on Bit Loading

Bit loading is the term for the number of useful data bits (per sample?) that are assigned to a particular VDSL2 frequency channel. See Dynamic Spectrum Management and Scholarpedia article on Digital Subscriber Line.

Our U-Verse connection uses ITU G.993.2 protocol, Profile 8c, Plan 998 (according to U-Verse Realtime). This corresponds to the following parameters (Wikipedia):

Parameter Value
bandwidth 8.5 MHz
no. carriers 1972
carrier bandwidth 4.3125 kHz
Power +11.5 dBm
Max. downstream throughput 50 Mb/s

U-Verse channel assignments, as reported by VDSL Monitor program, 12/2/2010, (Tones in use reflect the limitations of my particular connection.)

Band Tone Numbers Tones (MHz) in Use Comment
downstream band 1 0 - 869 32 (0.138) - 851 (3.66937) Conflict with 160 & 80 M ham bands
upstream band 1 870 - 1205 876 (3.777750) - 1164 (5.019750) Conflict with 80 M ham band (possible RFI to ham Rx)
downstream band 2 1206 - 1972 1224 (5.278500) - 1493 (6.438562) Conflict with 40 M ham band (in unused channel region)

Adapting to RF Interference

The Residential Gateway adapts to narrowband interference by reassigning data bits from the affected frequency (tone) channels to unused channels elsewhere in the spectrum. This works as long as there are enough spare channels available.

Experimental results and interpretation: Bitloading adapting to transmissions

Jan-Feb 2011 Performance Info

These data mainly are about the "Loss of Sync" (LoS) events, as experienced first-hand (while I was online or viewing TV) or through the RG's Training History log, as seen through VDSL Monitor software. The log data is cleared when we do a major reset or power cycle operation. In some cases, LoS events will be missed. The true outages will happen more often than reflected here.

N.B. None of these LoS events were caused by local Amateur Radio activity! (AA6E was off the air.)

Jan., 2011
(skip in monitoring)
Jan 25: (mon. started 1100 EST) LoS 1331.  [1400-1600 local Amateur transmission tests. causing some LoS.] Monitoring continues afterward.
Jan 26: no problems (big snowfall)
Jan 27: no problems
Jan 28: no problems
Feb. 1: no problems for 7 days!
Feb. 2: power cycled several times checking possible RFI to Amateur 80 M band receiver.  LoS 1911 (after tests completed)
Feb. 3: LoS 0956 1410 1727
Feb. 4: LoS 1424  (then some RFI tests) LoS 2333
Feb. 5: LoS 0000 0041 1001 1057 1224 (manual reset 1332 to clear high FEC condition)

These data may suggest that the RG can get itself into a "good" state where LoS events may not occur for a week or more. (There are still FEC bursts that are not recorded here.) When the RG is reset (losing training history), it may take multiple days LoS (& retraining) cycles for it to find the "good" state again. (This is just a suggestion, because it is equally possible that something changed outside the house to give a relatively good week of data.)

I have seen a number of times when the RG retrains itself into a "bad" (high FEC state). This will persist for a long time -- hours at least.

Oct-Dec 2010 Performance Info

  • Training_History_2010_12_19 from VDSL Monitor showing last week of retraining events. Not all of these caused loss of RG sync, but we are seeing 1 or 2 resync events per day -- with no local ham radio activity or any other notable electrical activity.
I'm not sure if "resync" is the correct term. I am referring to the RG losing connectivity for 1-2 minutes with flashing red "service" light.

Bad RG State

On Feb. 5, 2011, we saw a condition that has appeared before a number of times. The RG suffers an LoS event -- loss of sync, causing a retrain. After the RG comes back on line, the FEC error rate is high and relatively stable, whereas the FEC error rate before was very low or zero. This state will persist indefinitely until the next retrain that generally cures the problem. We see high FEC but no CRC errors. User-level services (TV, Internet, VOIP) do not seem to be affected by this condition. See Bad RG State Data.

RF Compatibility Measurements log. (2010)

"Breaking news" about this project and other ham activities may be available at blog.aa6e.net. This site is meant to provide a cumulative database of the evaluation work at AA6E. Please return periodically for new data.

U-Verse Technical Software

I have found these programs to be very helpful.

This program gives great displays of current statistics, bit loading, STB usage, DVR usage, etc. It can operate as a limited web server, also.

This program displays basic statistics numerically, but its value for me is its "chart recorder" mode of displaying error counts as a function of time (over last ~2.5 hours). It can also upload results to an FTP server.

Main
Personal tools