USB NRZI encoding and bit stuffing question

Discussion in 'VHDL' started by cxu_dl@yahoo.com, Jun 27, 2007.

  1. Guest

    I'm Looking at the USB D+ line with a Tektronix digital storage scope,
    the connection is from a PC
    to a fake "USB function" (by pulling up the D+ line with a 1.5k
    resistor to 3.3V supply, and nothing else). The enumeration process
    starts and I observed this pattern shortly after SYNC field:
    ---------------_____________----------------------_____________
    |<--664ns ------>|<---664ns----->|<---664ns------->|
    that is , D+ is high for 664ns, then low for 664ns, then high for
    another 664ns. This happens in one
    single packet right after the SOF packet. I can not understand this,
    since 664ns is precisely EIGHT bit-time. so that's a bit stuffing
    error, according to USB spec 2.0, page 157, which says "if the
    receiver see SEVEN consecutive ones anywhere in the packet, then a bit
    stuffing error has occured...". I don't believe this is a error
    because it seems to happen for every packet except the SOF packet. The
    signal quality is fairly good, with rise time and fall time of about
    6ns, some over shoot and no under shoot. To verify it is not a bad
    link, I hooked up a USB flash disk, and observed the same pattern, and
    the computer was able to detect the flash disk with no problem. Has
    anyone actually seen this and know why it is happening? or is it that
    I misunderstood the NRZI encoding and bitstuffing? Thanks in
    advance...

    Xu
     
    , Jun 27, 2007
    #1
    1. Advertising

  2. wrote:
    > is it that
    > I misunderstood the NRZI encoding and bitstuffing?


    Yes. I have to decode the NRZI before I
    can even see the bits.

    -- Mike Treseler
     
    Mike Treseler, Jun 27, 2007
    #2
    1. Advertising

  3. Guest

    On Jun 27, 9:46 am, Mike Treseler <> wrote:
    > wrote:
    > > is it that
    > > I misunderstood the NRZI encoding and bitstuffing?

    >
    > Yes. I have to decode the NRZI before I
    > can even see the bits.
    >
    > -- Mike Treseler


    While we're on the subject; I'm confused about NRZI and how it's used
    with USB.

    In the "encoding dictionary" (http://www.interfacebus.com/
    Definitions.html) it says:
    "NRZI [Non-Return-to-Zero-Inverted Encoding]: A '0' is encoded as no
    change in the level."

    In a USB Protocol specification (http://www.faculty.iu-bremen.de/birk/
    lectures/PC101-2003/14usb/FINAL%20VERSION/usb_protocol.html):
    "In NRZI encoding, a 1 is represented by no change in level "

    Which is it?

    Thanks,
    G.
     
    , Jun 27, 2007
    #3
  4. wrote:

    > In the "encoding dictionary" (http://www.interfacebus.com/
    > Definitions.html) it says:
    > "NRZI [Non-Return-to-Zero-Inverted Encoding]: A '0' is encoded as no
    > change in the level."
    >
    > In a USB Protocol specification (http://www.faculty.iu-bremen.de/birk/
    > lectures/PC101-2003/14usb/FINAL%20VERSION/usb_protocol.html):
    > "In NRZI encoding, a 1 is represented by no change in level "
    >
    > Which is it?



    The first is used for telcom,
    the second for usb, but the
    difference is just an inverter.

    Stir in some active high, active low,
    D+, D- etc. for extra confusion.

    -- Mike Treseler
     
    Mike Treseler, Jun 28, 2007
    #4
  5. Guest

    On 6 28 , 12 46 , Mike Treseler <> wrote:
    > wrote:
    > > is it that
    > > I misunderstood the NRZI encoding and bitstuffing?

    >
    > Yes. I have to decode the NRZI before I
    > can even see the bits.
    >
    > -- Mike Treseler



    ------------__________________----------------__________________
    |<--664ns ------>|<---664ns----->|<---664ns------->|
    the above NRZI encoded sequence docodes to:
    011111110111111101111111
    a 0 is inserted after every 7 consecutive ones, instead of the
    expected six ones. the standard says a 0 should be inserted for every
    6 consecutive ones. where am I wrong?
     
    , Jun 28, 2007
    #5
  6. wrote:
    > On 6 28 , 12 46 , Mike Treseler <> wrote:
    >> wrote:
    >>> is it that
    >>> I misunderstood the NRZI encoding and bitstuffing?

    >> Yes. I have to decode the NRZI before I
    >> can even see the bits.
    >>
    >> -- Mike Treseler

    >
    >
    > ------------__________________----------------__________________
    > |<--664ns ------>|<---664ns----->|<---664ns------->|
    > the above NRZI encoded sequence docodes to:
    > 011111110111111101111111
    > a 0 is inserted after every 7 consecutive ones, instead of the
    > expected six ones. the standard says a 0 should be inserted for every
    > 6 consecutive ones. where am I wrong?



    "if the receiver see SEVEN consecutive
    ones anywhere in the packet, then a
    bit stuffing error has occured...".

    Maybe that sample is not inside a packet.
    Could be idle flags.

    -- Mike Treseler
     
    Mike Treseler, Jun 28, 2007
    #6
  7. Pinhas Guest

    On Jun 27, 7:50 pm, Mike Treseler <> wrote:
    > wrote:
    > > On 6 28 , 12 46 , Mike Treseler <> wrote:
    > >> wrote:
    > >>> is it that
    > >>> I misunderstood the NRZI encoding and bitstuffing?
    > >> Yes. I have to decode the NRZI before I
    > >> can even see the bits.

    >
    > >> -- Mike Treseler

    >
    > > ------------__________________----------------__________________
    > > |<--664ns ------>|<---664ns----->|<---664ns------->|
    > > the above NRZI encoded sequence docodes to:
    > > 011111110111111101111111
    > > a 0 is inserted after every 7 consecutive ones, instead of the
    > > expected six ones. the standard says a 0 should be inserted for every
    > > 6 consecutive ones. where am I wrong?

    >
    > "if the receiver see SEVEN consecutive
    > ones anywhere in the packet, then a
    > bit stuffing error has occured...".
    >
    > Maybe that sample is not inside a packet.
    > Could be idle flags.
    >
    > -- Mike Treseler


    I started to document a USB full speed project.
    NRZI is discussed at http://bknpk.no-ip.biz/usb_8_tx_nrzi.html.
    Some waves are at http://bknpk.no-ip.biz/usb_8_tx_wave_1.html.

    Some un-finished data on the receive as well.
    regards,
    Pinhas
    http://bknpk.no-ip.biz
     
    Pinhas, Jun 28, 2007
    #7
  8. Guest

    On 6 28 , 7 50 , Mike Treseler <> wrote:
    > wrote:
    > > On 6 28 , 12 46 , Mike Treseler <> wrote:
    > >> wrote:
    > >>> is it that
    > >>> I misunderstood the NRZI encoding and bitstuffing?
    > >> Yes. I have to decode the NRZI before I
    > >> can even see the bits.

    >
    > >> -- Mike Treseler

    >
    > > ------------__________________----------------__________________
    > > |<--664ns ------>|<---664ns----->|<---664ns------->|
    > > the above NRZI encoded sequence docodes to:
    > > 011111110111111101111111
    > > a 0 is inserted after every 7 consecutive ones, instead of the
    > > expected six ones. the standard says a 0 should be inserted for every
    > > 6 consecutive ones. where am I wrong?

    >
    > "if the receiver see SEVEN consecutive
    > ones anywhere in the packet, then a
    > bit stuffing error has occured...".
    >
    > Maybe that sample is not inside a packet.
    > Could be idle flags.
    >
    > -- Mike Treseler


    I just discovered it's a preamble packet followed by low speed
    signaling.
    that's why it's 8 times longer.
    But why does the computer send me low speed packets when the connected
    device
    is full speed? I tried a hp printer,
    a video camera, a flash disk, and my fake device, all the same...
    does anyone know the reason?
     
    , Jun 28, 2007
    #8
  9. a écrit :
    > [...]
    > But why does the computer send me low speed packets when the connected
    > device
    > is full speed? I tried a hp printer,
    > a video camera, a flash disk, and my fake device, all the same...
    > does anyone know the reason?


    Probably for compatibility with slow speed USB.

    A low speed pattern is always reconized, by the fast USB devices as by the
    slower one.

    This is very common in multi-speed busses and comunications.

    Pascal
     
    Pascal Peyremorte, Jun 28, 2007
    #9
  10. Andy Peters Guest

    On Jun 28, 6:46 am, wrote:
    > I just discovered it's a preamble packet followed by low speed
    > signaling.
    > that's why it's 8 times longer.
    > But why does the computer send me low speed packets when the connected
    > device
    > is full speed? I tried a hp printer,
    > a video camera, a flash disk, and my fake device, all the same...
    > does anyone know the reason?


    Because the host needs to determine whether the new device is a low-
    speed or full-speed device before it can communicate.
    -a
     
    Andy Peters, Jul 3, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kumar
    Replies:
    8
    Views:
    3,619
    Vikram
    Feb 17, 2004
  2. jpereira

    Bit stuffing in a Crc encoder

    jpereira, May 25, 2005, in forum: VHDL
    Replies:
    4
    Views:
    1,469
    Mike Treseler
    May 31, 2005
  3. Bit stuffing in C Language

    , Mar 3, 2005, in forum: C Programming
    Replies:
    4
    Views:
    5,844
    tigervamp
    Mar 3, 2005
  4. galapogos
    Replies:
    4
    Views:
    411
    Kenny McCormack
    May 11, 2007
  5. blackpadme

    bit stuffing

    blackpadme, Aug 24, 2008, in forum: VHDL
    Replies:
    5
    Views:
    986
    blackpadme
    Aug 25, 2008
Loading...

Share This Page