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 .1.3.6.1.2.1.10.127.1.2.2.1.17.2
    SNMPv2-SMI::transmission.127.1.2.2.1.17.2 = 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 http://kaigal-v6.cablelabs.com/cablemodem/specifications/ri_implementations.html

    Also, a web demo is available from Cablelabs at http://www.cablelabs.com/PNM/PreEqDemoWeb.html
    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
    0801180000000000000AFFFFFFF70004000BFFFEFFE2000100310000FF90FFF707DA013C0070FF77FFE9FFFE00060003FFF700030005FFFFFFFF0000FFFFFFFFFFFC0000FFFDFFFE0001FFFA00030000FFFB000100000002FFFD0000FFFF0004FFFAFFFC
    ARRIS DOCSIS 3.0 / SIP 2.0 Touchstone Telephony Gateway HW_REV: 1; SW_REV: 7.5.63B.SIP; MODEL: TG862A
    08011800FFF70004000CFFFBFFF3FFF700070008FFFDFFF500010022FFF9FFB407FD000FFFFC0003FFF0FFF30007000D000300070006000FFFF9FFF1FFFF000300060000FFFB0006000D00020004FFFB00060002FFFEFFFDFFFF000500040008000C0005
    VENDOR: Motorola; BOOTR: PSPU-Boot(25CLK) 1.0.12.18m3; SW_REV: SB612X-1.0.5.2-SCM01-NOSH; MODEL: SB6121
    080118000000FFFC00050002FFFEFFFA00030004FFF9FFF600010010FFEAFFD807FE00000010FFFBFFFF000EFFF300180000FFFAFFFC0007FFFFFFFA0005FFFEFFFEFFFEFFFFFFFF0000FFF80006FFFA0004FFFF000200020006FFFFFFFE000100000000
    ARRIS DOCSIS 2.0 / SIP 2.0 Touchstone Telephony Modem BOOTR: 6.23; SW_REV: 6.1.134T.SIP; MODEL: TM602A
    0801180000060000FFFE00060008FFF4FFF200100019FFDFFFEE0044001DFF4307F20000002D0031FFF80002FFE10010FFF4FFE70000FFF2FFFCFFFA000400020004FFFC0002FFFCFFFC00060006000200040002FFFC000200020004FFF8000200060000
  • Bad data - Main tap with negative value
  • Cisco DOCSIS Cable Modem HW_REV: 2.0; SW_REV: dpq2160-v202r12811-090206as; MODEL: DPQ2160
    080118000053005FFF0C00B40070FEE1005500C50003FF28FFCC00F5FFE7FD817FD50000FFEC04D2FFD7FE40005F00B10016FF16001A008300180026FFF10010FF9400280035FFCBFFF00073FF98FFD8005D008100B7FFC3FFEEFFE6FFEEFFE1FFE4FF40
    VENDOR: Motorola Corporation; BOOTR: 2.3.1; SW_REV: SVG1202S-2.10.3.0-GA-00-016-LTSH; MODEL: SVG1202
    08011800000FFFBC0024003DFFEFFF96002400B00006FF220039021DFE95FACF7FB60000047003F7007CFF5800BA0054FF4FFF430029FFDBFFDE005A004EFFF6FF9F0003FFF70046FFD9005200420001FFEBFFF2FFE6FFDCFFDEFFE9FFF4FFC6FFA5FFAF
    HW_REV: 1; VENDOR: Motorola Corporation; BOOTR: 2164; SW_REV: SB5101-2.8.5.0-GA-03-501-NOSH; MODEL: SB5101
    08011800FFEAFFC300270071018C0076008A004E00700022FF98000201BAFF977FEF0000008101480226FFFC00320052001A0027FF5BFFE1FFF5005A0024FF6F00790022001EFFF4006F0060FFB0001DFF6CFFA00081FFF9FF70FF95FFB6FFEA0060FFAB
    Netgear Wireless Cable Modem Gateway HW_REV: V1.0; VENDOR: Netgear; BOOTR: 2.1.7k; SW_REV: V4.4.8R073-RG; MODEL: CGD24G-100NAS
    08011800002F00B80034008600CAFF130124005DFFF1FF8600250131FE92FB907FDC0000FE86FF53FF0BFFDD0097000FFFDD0021FFB6003AFF82003CFF5100BF006B0022FF89FFE4FFB0FFD1FF9F001DFFB3FFBC0000003E002A00A500CC005F008B009C