ADSL2+ Woes: What’s in a Training Signal?

Visitors who have explored the site quite a bit will probably know that I’ve got a bit of a thing for modems – specifically, the sound and behaviour of different dial-up modems. The sound of the modem handshake, formally known as the training signal, was a unique and essential part of the “early” days of internet access. Experienced ears could tell what sort of connection speeds and modulation modes were used just by listening to the connection.

Since the vast majority of internet access in developed countries have moved away from the humble dial-up modem, we no longer have the sounds of a dial-up modem to delight in. But what about the ADSL modem? What does one sound like?

An ADSL Primer

It might have have been a thought that has passed your head – why am I staring at a blinking Sync light on my modem, waiting for it to go solid, all in silence? What’s happening?

ADSL, short for Asymmetric Digital Subscriber Line, is a system which uses old fashioned POTS lines to transport digital data. Numerous versions exist, however, they all have a few features in common.

One is that they utilize frequencies up to 2.208Mhz for ADSL2+ modes, or up to 1.104Mhz for ADSL/ADSL2 modes. This is done by modulating orthogonal frequency carriers spaced by 4.3125khz.

In order to co-exist with regular POTS phone service, normally a guard band is employed, thus ADSL signals are often modulated starting at 24.875khz (for Annex A service). What is a “line filter” is merely a low-pass filter which lets your phones “enjoy” the signals from 0-4khz, while filtering the signals 24khz+ out of the phone, thus allowing both services to co-exist on the same line. You can think of this as a sort of FDM (frequency division multiplexing).

If you haven’t noticed already, 24.875khz is outside the human hearing range. There really is no point fitting a speaker, because you won’t hear anything.

The Motivation

Around the time of my Pico Technologies PicoScope 2205A RoadTest, I was contacted by an unnamed friend in regards to his ADSL2+ service. Since the technicians had hooked up a neighbouring line, they had disturbed his line and his sync rates had plummeted to below 1Mit/s from a former high of 18Mbit/s. He had performed the necessary isolation tests, but the ISP insisted his old modem was at fault.

Most modems give you a basic run-down of the line statistics in the form of the following figures:

  • Sync Rate – the speed at which a connection was achieved.
  • Attainable Line Rate – the speed at which the line *could* run, without any margin.
  • SNR Margin – the headroom, or how much attenuation could increase by, before the link would fail.
  • Attenuation – the amount of signal loss in the path.
  • Errored Seconds – the number of seconds where the line had uncorrectable errors.
  • Severely Errored Seconds – the number of seconds where a threshold of continuous errored seconds or errored blocks had been breached.

Unfortunately, this only gives you a crude image of the line – in fact, his case was very special because his figures looked JUST LIKE BEFORE, but the line just didn’t perform.

Who else was he to call upon, but the guy with some surplus goods he could put towards the cause.

Broadcom Chipset based ADSL2+ Modems

The first form of diagnostic, believe it or not, is to use a “special” modem. Modems blessed with particular Broadcom chipsets, such as the D-Link DSL-2740B, may not be great general purpose modems due to firmware bugs, but enabling Telnet access on them allows for advanced diagnostics to be performed through the Broadcom Command Line Interface.

I wouldn’t recommend enabling the Telnet interface on non-completely-trusted networks, due to lack of security against snooping, but it does provide a specific command of use.


Specifically, the adsl command. Executing adsl info –SNR and adsl info –Bits (both case-sensitive) gives you a much better idea of what your line is like. It dumps out the bin number (i.e. the frequency) and the SNR measured at the frequency, or the Bit-loading at that frequency respectively.

This shows you how the line is responding at each frequency. The sync rate is basically the sum of all bit-loads across all-bins, and the SNR, SNR Margin is based upon measurements at one bin only.


The above plot is my home connection, which is fairly healthy. Note that I’ve used two modems, a D-Link DSL-2740B and a D-Link DSL-2642B. Notice how the two modems have slightly different opinions of the line – this is why some modems “sync faster” than others. The DSL-2740B might have a noisy switching supply causing RF noise at harmonically related bins, resulting in the periodic SNR dipping. It might also haev an older chipset, which doesn’t report SNRs below a certain value, and instead clips them to 0.

In general, you need 6dB for the minimum 2-bits per bin, so the bin is actually used, but you need a further 6dB which forms the buffer margin which allows for operation where the noise floor may vary up to 6db before failure. Every 3dB above this contributes an extra bit to the bin.

So good so far? Well, lets take a look at the unnamed friend’s line …


My modem wouldn’t even contemplate negotiating an ADSL2+ connection, and stubbornly sat in G.DMT mode. It’s clear the line doesn’t eclipse 12dB SNR for many bins, and is very erattic. The actual peak SNR isn’t very high either, resulting in low rates/low-bit loading. It’s definitely a line problem, and not a modem issue. Glad we sorted that out.

DMT Tool

If you don’t want to go to the lengths of actually going to the CLI and keying in commands youself, capturing the data, and plotting it, owners of appropriate Broadcom modems can download DMT Tool and use that instead. It’s quite nifty, however, the DSL-2642B cannot be used with DMT Tool due to a Text CAPTCHA on the Telnet interface that cannot be disabled.


But What’s in a Training Signal?

Astute readers would note that I haven’t actually yet addressed the big question – what’s in an ADSL2+ training signal. This is where the PicoScope comes in handy. While you should never connect non Austel approved equipment to a Telephone Line in Australia, I suppose if you’re careful, you can probably get away with it.

I decided to use the Picoscope with the probe set to 10x (to present a high impedance and thus, not impact the modem’s operation). I connected it to my Acer Iconia W3 Windows 8.1 tablet operating off battery, isolated from ground, to ensure safety. I cut up some old phone cord, and plugged it in.

Frequency Mode was selected, as the signal is a complex signal made of orthogonal frequency components. Analyzing it in oscilloscope mode would not make sense. Further to this, as I realized the PicoScope has a lot more sampling rate to spare, I engaged the maximum level of resolution enhancement to improve the dynamic range of the plot, although technically, the modems are probably even more sensitive as they’re properly matched.

I used the reference waveform feature to capture the “peak” training waveform for comparison, and coloured the reference waveform light-green.

You can watch the animation of the training happening here – a 20.5Mb Animated GIF.

For everyone else, there’s a few important snapshots below. We start off with the line “silent” – all modems are off.

All Modems Off

The line is quiet, but there seems to be periodic pips on the line that indicate the presence of a modem. The modems then decide to probe the line with some very specific frequencies before then proceeding to push specific waveforms. This one tests all the up-stream carriers.


Meanwhile, that is followed by a different one transmitted by the remote modem which tests all the down-stream bins. Note that I have selected to limit the bandwidth of the recording as the bins fall into the noise, so there’s no point capturing more, otherwise it’d be at the cost of frequency resolution.


A zoomed in look at the upstream and downstream tests show the bin widths to be pretty much as expected, matching ADSL specifications.

ADSL-UP-probing-signal ADSL-DOWN-probing-signal

Interesting, there is a frequency offset to some of the signals sent – for example this one.


After the connection is established, the connection goes into ‘scrambled data’ mode, where discrete frequency components are less visible.


The animated version really does do the process justice, but alas, instead of hearing a handshake, you’re seeing the handshake happen before your eyes. Pretty cool – I never knew how involved ADSL training is.

Much thanks to my PicoScope for not only uncovering this for me, but for making it so easy to see what was actually happening. My other alternatives are not so good – too much noise floor, no bits enhancement, no Animated GIF, no reference waveform … the PicoScope really excels here.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Telecommunications and tagged , , , . Bookmark the permalink.

2 Responses to ADSL2+ Woes: What’s in a Training Signal?

  1. GrammBuck says:

    [Why do I get an Error: Comment is Missing! heading on the page?]
    Okay, but what about the human story, Sheldon? Did your friend resolve his line speed problem, aided by your analysis data?

    • lui_gough says:

      [The error is not an error, merely a tongue-in-cheek way of saying “leave a comment!”]

      The problem was resolved, by calling out a technician from the telco at long last, which swapped pairs to one which did not have such poor characteristics. The analysis was mainly of interest because the ISP seldom believes the customer, especially when a technician has already been called out once, but has made a repair that still does not resolve the root cause – that is, some kind of line trouble (e.g. capacitance) which affects the SNR at high frequencies. Backed with the data, we have confidence that the cause is not the modem, as suggested by the ISP, but was indeed the line.

      This can be very important in the case where a consumer has to pay for “no-fault-found” call-outs, as proof that a fault was detected even after the appropriate measures have been taken (isolation test, test at the demarc).

      – Gough

Error: Comment is Missing!