- 10/6/2010. A preliminary test of Uverse while operating on 80 meters CW at ~3536 kHz was successful when running 80-100W output power. The DSL circuit was lost when transmitting at 850W, however. This is very preliminary. We expect improvements after installing RF chokes and other straightforward measures. We expect to run a series of tests on all bands from 80M to 10M. No interference from DSL to the amateur receiver has been noted so far, but careful tests are needed.
- 10/10/2010. Continuing the tests with HF CW operations.
These results are with no changes to my initial DSL / RG wiring. Power levels are output power as measured by LP-100 wattmeter. Generally, tests started at low power and increased in steps. The highest power that was OK is noted and the first power level that produced a failure is also noted.
Freq Pwr OK Pwr Fail 3562 190 272 3999 859 CO monitor set off. Note freq is in DSL upload band 7031 330 570 7119 155 324 and kills UPS link, too 14066 980 beam N-S bidirectional (SteppIR) 14349 870 21029 866 28299 492 UPS link dropped Attempted fix #1 wrap incoming DSL line (Cat 5e) 8 turns on Amidon type 77 core: 3562 572 676 Note 640W level showed transient video errors (bit errors) that recovered quickly if key released 7033 553 667 Not full DSL dropout, but reset out of an on-demand movie 7119 791 Loud speaker hum at 400W The ferrite has clearly helped to allow ~ 3 dB higher power levels at some frequencies, but not 7033 kHz. Further actions to try - filter DC power line from RG UPS, filter more Ethernet lines.
- 10/23/2010 A few more tests.
Downloaded "VDSL Monitor. 2Wire 3800HGV-x version." from http://adslm.dohrenburg.net/download/download.php . In some ways, this program should be more useful than "U-verse Realtime", because it provides graphic displays of the error rates (FEC and CRC) versus time. There is also an event log that shows error rates and bitloading changes with a granularity of 10 seconds.
Tried operation at ~ 7029 kHz. With 100W, there was an FEC rate of "5" (10=257480 per 10 sec?), but VDSL connection was not lost. With QRO = ~ 727W output, FEC rose to "7", but we began to see CRC errors also (up to full scale = 122 per 10 sec?) -- and VDSL connection was lost.
The above was with ferrite filters as installed before. Adding a second type 77 core (6 turns) on the VDSL low-level input cable (at other end near wall jack) produced significant improvement. No CRC errors at 727W and FEC errors less than the earlier 100W result. VDSL connection was maintained. (However, we were not monitoring the TV for possible video problems.) Clearly, the VDSL input needs careful protection against common-mode currents. We may want to add even more cores. Testing in 80 M band will possibly show less attenuation due to core material.
- 11/25/2010 New confusing results
It's Thanksgiving holiday here. Time to try a few more checks on 40 and 80 CW. A 40 M QSO went OK (but we weren't checking the TV errors closely). Then I fired up on 3561 kHz, 100W. This produced CRC errors and loss of sync. But the power level was much less than 600+ W that seemed to work OK at nearby frequency. No changes in wiring so far as I can tell. Similar result at 3551 kHz - 60 W.
- 11/27-29/2010 It's the phone connection!
Disconnecting my internal Ethernet distribution had little effect. Disconnecting the house telephone wiring (ie the VOIP telephone service) from the RG makes a huge improvement, bringing me back to ~ 1 kW operation at 3561 kHz with high FEC errors, but no CRC or dropped sync. The AT&T installer did not connect my DSL surge suppressor correctly, so I've been meaning to reorganize this wiring. Now, there's a little more urgency...
A series of measurements on 80 and 40 meters indicate that 100 W CW operations are generally going to be OK. There is always a noticeable increase in FEC errors, up to 400,000 per minute, but there are no CRC errors. According to my tests so far, the FEC rates do not cause any visible trouble with TV reception. (FEC [forward error correction] errors, as you might expect, are correctable.)
Operations (100 W and QRO) do affect the Residential Gateway's response however. See RF_Notching for some of these effects. Strong signals effectively force the RG (modem) to reassign its "bit load" from the affected carrier channels to unused channels elsewhere in the 0 - 8.4 MHz spectrum that is potentially available -- to the extent supported by your line quality. These channels apparently provide the "reserve bits" that are available for reassignment as needed. Note that channel reassignment only seems to occur as needed (by interference or other troubles); a gap caused by a short term interference problem will likely never be restored until the RG is rebooted or the RG recovers from a loss of sync. (E.g., if the DSL line is disconnected for a few seconds.) This makes our sensitivity testing problematic, since we're never dealing with exactly the same conditions unless we force the system back to initial conditions -- a time-consuming process.
Placing additional ferrite cores on incoming wires (Cat5 Ethernet, DC power, etc.) seem to have some modest effect, but it is hard to understand their impact on the RG after a lot of notching has occurred from previous testing. It might be better to reset/retrain the RG before each sensitivity test, but that would take a lot of patience.
- 12/2/2010 Upstream QRM?
The question arises whether U-Verse VDSL2 causes interference to amateur receivers. I tested the upstream band 3.77 - 5.02 MHz quickly, and found little if any interference over the general S3 - S4 noise level in this band. I tried this both with upstream idle and with FTP data transfer in progress.
- 12/2/2010 Single-Frequency Tests in 80 & 40M bands
Based on improved (?) understanding of the Dynamic Spectrum Management, I performed tests at a single frequency (~3545 kHz). First, at 20W in QSO for about 10 minutes, the bitloading graph showed a single tone channel was swapped. FEC was > 100,000 errors/min. Next, a 30 second carrier at 100W caused high FEC and CRC and lost sync. The bitloading following that had zeroed out all downloading in the 80 M band - a dramatic change in spectrum. Then a further 30 sec transmission at 100W produced zero FEC errors. Encouraging!
Now, to try QRO on the same frequency. Tuning up for ~30 sec at 185W -> FEC 0. Sending 30 sec at 745W produced FEC 71,000 but no CRC and no sync dropout. Repeating some minutes later produced FEC 51,000 and no CRC or dropout. Bitloading spectrum has not changed.
The upshot from this (at least on 80M) indicates that once the RG is trained to reject 80M, we are pretty safe to operate, even with high power.
A similar set of runs on 40M: 100W - lots of FEC errors, 100W again - fewer errors; 800W - many errors drop sync; 800W again - moderate FEC errors, no loss of sync, etc. However, looking at the bitloading graph, it is clear that a big channel reallocation has occurred: the 80M gap (that occurred after 80M QRO test) is filled in, and the high frequency (download 2) band is mostly zeroed out. It appears that the RG "knows" that a major interference event has happened, and it tries to zero out a large range of offending frequencies. It may even know about the amateur 80 and 40M bands as likely sources of such upsets. I will put up a new page to summarize the situation with relevant screenshots: Bitloading adapting to transmissions