• Problem verifying J1 byte in SDH frame

    From jquinn60137@gmail.com@21:1/5 to All on Thu Feb 7 09:21:24 2019
    Hi,

    I'm working on a software tool to parse SDH frames and am running into a problem validating the J1 bytes.

    I have a SDH carrying AU-4/VC-4 payload. The J1 trace message is set to "abcdefghijklmno" (0x61-0x6f). From my understanding the trace information will be stored in the J1 byte over 16 frames. The first frame will contain the CRC-7 of the previous
    frame and the next 15 frames will transmit the 15 bytes in the trace message. The 15 frames of the trace message appear in the output, however, I can't get the CRC-7 to match my calculations.

    I've verified that my CRC-7 code calculates the same result as CRC-7 calculators online so I believe it is correct.

    Here is the test data I am using. I truncated the output after 80 columns for posting. The entire payload consists of 0xc3.

    f6 f6 f6 28 28 28 0d 00 00 6e c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 83 00 00 00 00 00 00 00 00 dc c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 fe c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 6a 93 93 0a ff ff 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 5d 26 f7 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 ff c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 0b 00 00 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3

    f6 f6 f6 28 28 28 0d 00 00 6f c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 24 00 00 00 00 00 00 00 00 b3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 fe c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 6a 93 93 0a ff ff 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 7a 89 58 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 ff c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 0b 00 00 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3

    f6 f6 f6 28 28 28 0d 00 00 -->d9<-- c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ca 00 00 00 00 00 00 00 00 dd c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 fe c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 6a 93 93 0a ff ff 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 33 26 f7 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 ff c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 0b 00 00 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3

    In this case the equipment I am using shows a CRC-7 value of 0xd9. However, when I calculate the CRC-7 over the 2430 bytes in the previous frame I get a value of 0x34.

    Is my understanding correct that this value should represent the CRC-7
    checksum of the previous frame?

    Thanks!

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Huub van Helvoort@21:1/5 to You on Fri Feb 8 00:04:09 2019
    Hello John,

    You wrote:

    I'm working on a software tool to parse SDH frames and am running into a problem validating the J1 bytes.

    I have a SDH carrying AU-4/VC-4 payload. The J1 trace message is set to "abcdefghijklmno" (0x61-0x6f). From my understanding the trace information will be stored in the J1 byte over 16 frames. The first frame will contain the CRC-7 of the previous
    frame and the next 15 frames will transmit the 15 bytes in the trace message. The 15 frames of the trace message appear in the output, however, I can't get the CRC-7 to match my calculations.

    I've verified that my CRC-7 code calculates the same result as CRC-7 calculators online so I believe it is correct.

    Here is the test data I am using. I truncated the output after 80 columns for posting. The entire payload consists of 0xc3.

    f6 f6 f6 28 28 28 0d 00 00 6e c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    83 00 00 00 00 00 00 00 00 dc c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 fe c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    6a 93 93 0a ff ff 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    5d 26 f7 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 ff c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    0b 00 00 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3

    f6 f6 f6 28 28 28 0d 00 00 6f c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    24 00 00 00 00 00 00 00 00 b3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 fe c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    6a 93 93 0a ff ff 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    7a 89 58 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 ff c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    0b 00 00 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3

    f6 f6 f6 28 28 28 0d 00 00 -->d9<-- c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ca 00 00 00 00 00 00 00 00 dd c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 fe c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    6a 93 93 0a ff ff 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    33 26 f7 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 ff c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    ff 00 00 ff 00 00 ff 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3
    0b 00 00 00 00 00 00 00 00 00 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3 c3

    In this case the equipment I am using shows a CRC-7 value of 0xd9. However, when I calculate the CRC-7 over the 2430 bytes in the previous frame I get a value of 0x34.

    Is my understanding correct that this value should represent the CRC-7 checksum of the previous frame?

    According to ITU-T G.707 the path trace Ji is a 16-byte frame
    described in clause 9.3.1.1, which is the same as the 16 byte
    section trace J0 described in clause 9.2.2.2.
    The calculation of the CRC is shown in table 9-1.

    In your case the CRC-7 should be calculated over the -- 16-byte --
    previous frame "xabcdefghijklmno" where x is the CRC-7 over
    the previous frame.
    Note the -- 16-byte -- path trace and not the -- 2430 -- byte
    SDH frame!

    Best regards, Huub.


    --
    reply to hhelvooort with 2 'o's ================================================================
    http://www.van-helvoort.eu/ ================================================================
    Always remember that you are unique...just like everyone else...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)