Decoding Docsis Pre-equalization information

Docsis Pre-equalization is very interesting to play with. First, the technology itself: compensating network impairments by modifying the transmitted signal can make the upstream path more reliable. Second, by inspecting the modems and grouping the pre-equalization data it is possible to understand how (and where) the impairments are affecting the upstream path. The concept is explained on Docsis PNM (Proactive Network Maintenance Using Pre-equalization) docs.
There is a reference implementation avaliable (link below), but I found it a little bit difficult to build (lots of components, and I'm not a Java fan), so I decided to check the docs and start coding.
I was also interested in check how changes on TAP energy levels will impact the frequency response. I added a table to view the intermediate values of the calculations required and added a feature to allow editing the TAP values on-the-fly. That makes the visualization of the changes easier.
Comments and findings are below.

App & Binaries

  • I just release the version 1.5 of the application. It tries to correct the strange behaviour observed in some modems (as discussed below on FAQ). File is here
    . (SHA256 of the file is 18630a9383437d319f1daa42d14c8c573cb7cccd)
  • The initial version of the application can be found here
    (SHA256 of the file is b8ff384a9c38b4e8121d2faf412272059f10abf0 ).

  • How to Use

  • Capture the pre-eq data from the modem, the result will be a string with 200 bytes

  • This is the quickest way to retrieve the data from the modem:
    snmpwalk -v 2c -c .
    SNMPv2-SMI::transmission. = Hex-STRING: 08 01 18 00 FF FF 00 00 00 0B FF FF FF FA FF FF 00 0B 00 05 FF E4 FF F9 00 34 FF FF FF 98 FF F7 07 F4 00 06 00 6C FF 88 FF D1 FF E3 00 13 00 14 FF F8 00 11 00 04 00 06 00 01 00 08 00 05 FF FE 00 01 00 01 00 00 FF FD FF FE FF FF 00 00 00 05 FF F9 FF FD 00 04 FF FC FF FB FF FE FF FF FF FF 00 01 00 0A
  • Paste the string on the application input box
  • Click "Calc"
  • If the values are ok, the graphs will appear as well as the PNM metrics. From this point on, you will be able to change the hex values of the Real and Imaginary coefficients of individual TAPs by double-clicking the cells
  • References

    There are some good sources about the subject. I used the following ones as references:
  • If you are not sure about what a reflection is, the following link will clarify it : AT&T Archives: Similiarities of Wave Behavior. Amazing, isn't it?
  • Docsis 3.0 PHY Specs
  • Proactive Network Maintenance Using Pre-equalization
  • Optimizing Upstream Throughput Using Equalization Coefficient Analysis

  • To calculate the frequency response, you will need an FFT algorithm. I decided to use Stockham to do the job. References can be found on DSP books, or you can check online here. If you want to go deeper on the math behind the FFT, a good choice is "The Scientist and Engineer's Guide to Digital Signal Processing" from Steven W. Smith. Easy to find on Amazon.

    A software piece is available from Cablelabs (PNM Reference Implementation), I guess it is only reachable through IPv6. Look at

    Also, a web demo is available from Cablelabs at
    UPDATE : it seems that both sites are unavailable now. I guess CableLabs moved the pages or restricted the access to registered members. (01/17)

    Questions & Comments

  • Will the application support/decode Docsis 1.1 modems?
  • No.

  • Sometimes the frequency response shows a crazy behaviour. What's going on?
  • Answer: There are some modems around whit inconsistent values on the main TAP. I guess they use a different/proprietary encoding, or just I was not able to figure out how to decode it. This is enough to confuse all the calculations.
    *** UPDATED: It seems that the mistery is solved now. Thanks to Mr. Wolfang Frick, who lead me to the right path. ****
    According to Cablelabs PNM Docs, "Since in current implementations the maximum value that a coefficient can take is always less than or equal 2047, the first nibble is never used and can be removed to generate a universal decoder". Also, it suggests that "Regarding maximum amplitude, CMs have maximum amplitude equal to 2047, 1023 or 511".
    What I found (by observation) is that there are some modems (as listed below) where these rules doesn't apply. The real value of the main TAP is something like 7Fxx, which is negative if you use the 3-nibble rule. However, if you consider it as a positive value and assumes the Main TAP Nominal Amplitude as the closest 2^n value (32767 in this case), it will decodes perfectly.
    It will be nice if someone with access to a proper documentation could share it with me.

    I captured sample Pre-eq data from some modems, you can try it on the application.
  • Good ones
  • Hitron Technologies; BOOTR: 1.1.1-RG; SW_REV: 4.05.07; MODEL: CDW30240
    ARRIS DOCSIS 3.0 / SIP 2.0 Touchstone Telephony Gateway HW_REV: 1; SW_REV: 7.5.63B.SIP; MODEL: TG862A
    VENDOR: Motorola; BOOTR: PSPU-Boot(25CLK); SW_REV: SB612X-; MODEL: SB6121
    ARRIS DOCSIS 2.0 / SIP 2.0 Touchstone Telephony Modem BOOTR: 6.23; SW_REV: 6.1.134T.SIP; MODEL: TM602A
  • Bad data - Main tap with negative value
  • Cisco DOCSIS Cable Modem HW_REV: 2.0; SW_REV: dpq2160-v202r12811-090206as; MODEL: DPQ2160
    VENDOR: Motorola Corporation; BOOTR: 2.3.1; SW_REV: SVG1202S-; MODEL: SVG1202
    HW_REV: 1; VENDOR: Motorola Corporation; BOOTR: 2164; SW_REV: SB5101-; MODEL: SB5101
    Netgear Wireless Cable Modem Gateway HW_REV: V1.0; VENDOR: Netgear; BOOTR: 2.1.7k; SW_REV: V4.4.8R073-RG; MODEL: CGD24G-100NAS