P1394b Working Group Meeting,
Ft. Lauderdale Marriott North,
Ft. Lauderdale, Florida
December 2 & 3, 1997

Chairman:   David Wooten, david.wooten@compaq.com, (281)518-7231
Secretary:  Richard Churchill, richard.churchill@compaq.com, (281)514-6984

Group Web-page:  http://www.zayante.com/p1394b/
Group FTP site:  ftp://ftp.zayante.com/p1394b/          (for MS-IE users)
                 ftp://ftp.zayante.com/ftp/pub/p1394b/  (for Netscape users)

Group reflector: p1394b@zayante.com

 1. Introductions
 2. Agenda
 3. Procedures
 3.1  Voting
 3.2  Price/Pricing
 3.3  Call for Patents
 4. Review of minutes
 5. PMD Liaison reports
 5.1  Cheap and Fast (S100)
 5.2  Fast and Cheap (S800)
 6. Task group reports (Review of spec additions and issues)
 6.1  PHY-LINK Interface - Martin Sodos
 6.2  Upstarts - Colin Whitby-Strevens
 6.3  Standard protocol - Alistair Coles
 6.4  Standard electrical - Eric Hannah
 6.5  Cable/Connector - Max Bassler
 7. Holes in the Spec. - Eric Hannah
 8. Extra Items
 8.1  500V Isolation - Eric Hannah
 8.2  Amp Cable test results
 9. Meeting Schedule
 9.1  January (Houston - 1/6&7)
 9.2  February
 9.3  March
 9.4  April/May
 9.5  June
 9.6  July
 9.7  August
 9.8  September
 9.9  October


Meeting came to order at about 1:45 PM

 1. Introductions

    Introductions were made, and an attendance list passed around

 2. Agenda

    The agenda was approved as revised.

 3. Procedures
 3.1  Voting
 3.2  Price/Pricing
 3.3  Call for Patents



 4. Review of minutes

    Minutes of the previous meeting were hard to find, though available.
    Approval of minutes of the previous meeting was deferred to a later
    meeting.

 5. PMD Liaison reports

 5.1  Cheap and Fast (S100)

    Report of the S100 long-haul committee was the same as presented to the
    S800 long-haul group

    Moved by Shuntaro Yamazaki (NEC) and seconded by Ted Inoue (Arch Tech)
    that "The P1394b committee specifies a unique connector optimized for
    POF/HPCF link in addition to a conector for GOF link.  This connector
    specification is to be added to the secion of POF/HPCF link in the P1394b
    draft, ver. 0.06 or later version of p1394b draft."

    <The chair opined that this motion is not entirely needed, as the S100
    group COULD do this without direction from the committee of the whole.
    Thus he asked that the motion be withdrawn.  This was agreed by both
    Shuntaro-san and Ted-san.>

    <This should lead to allocation of the time for S100 meetings at the next
    two p1394b general sessions.  This will allow others to gain voting rights
    by attending "two out of the three most recent meetings, including the
    current one," in time for the formal vote in February.  Comments were
    made that the connectors being considered should not be a surprise, as
    the S100 group has been reporting its progress.>

    <Let us require that adequate materials be presented at least two weeks
    prior to the vote.  Generally agreed.  Twenty minute presentations should
    be made at the January meeting.  Perhaps we should have a repeat of the
    presentations at the February meeting, so as to refresh people's memories
    much as was done this morning by the S800 group.>

    <The intent is to select a connector that does NOT mate with the S800
    connector.  Should we need a vote to include connectors like LC?  We
    should probably leave the proposals open until the January meeting,
    subject to the two-week rule for submitting information for the January
    presentations.>

    <What are the voting rules for the S100 group's voting rules?  Has used
    a simple majority rule for most votes, but the same as S800 and p1394b
    for formal votes.>

 5.2  Fast and Cheap (S800) - Colin Whitby-Strevens

    Colin conveyed the recommendation of the S800 group of the LC connector,
    and indicated that the group believes that the group has fulfilled its
    task, and should therefore be disbanded.

    <What does "based upon reference" mean?  You point to another specifi-
    cation and say, "just like that, except with the following differences."
    This can reference draft documents, to be revised to the formal documents
    after approval of the drafts.>

    Do you the committee of the whole accept the recommendation of the LC
    connector?  Moved by Richard Churchill and seconded by John Fuller that
    we accept the recommendation of the S800 task group regarding the LC
    fiber optic connector.

    <Various people were uncertain what would happen now.  Weren't we
    planning a reconciliation between S100 and S800 recommendations, etc.,
    at some point?  Previous products of the S800 group have been moved
    into the draft.  On the question of a connector, we can approve, refuse,
    defer, or table the acceptance of the recommendation of the LC connector.
    Some of these actions allow us to consider reconciliation.>

    Moved by Steve Bard and seconded by Richard Churchill that we defer a
    vote on the question regarding acceptance of the recommendation of the
    S800 group.

    <Acceptance does not mean we cannot address the question of reconcil-
    iation at a later date, so we should not defer.  We should allow the full
    S800 and S100 solutions to be completed, then reconcile, but this doesn't
    mean NOT accepting the recommendation, but a does mean that we may at a
    later point either accept or reject the finished S100 or S800 solutions.
    Would acceptance add to the difficulty of revising the product of our
    acceptance at a later date, but requiring a super majority perhaps?  No.>

    Votes for deferring were three, against were 34, and the motion to defer
    fails.

    <Does acceptance mean that we will only use an optical connector and only
    this one?  No, the LC connector is only the GLASS OPTICAL connector for
    LONG-HAUL.>

    A procedural motion to conduct a role-call vote was made.  On a voice-
    vote regarding whether to conduct a role-call, the nays won by a strong
    majority.  (Only two or three voted for a role-call.)


    There were 42 yes votes for the motion to accept the recommendation,
    and 10 no votes, from 56 qualified voters present.

    Comments from those voting no on the motion were ... that having a
    vote after lunch was hoped.  <Colin commented that the procedure had
    been available since Maui, as well as all salient information.>

 6. Task group reports (Review of spec additions and issues)

 6.1  PHY-LINK Interface - Martin Sodos

    A page of text was presented, titled "1 Beta extension of the 1394a PHY-
    LINK Interface Specification."
    ... (get the original and insert ...)
    1.1 Introduction
    The Beta PHY-LINK interface provides the ability to extend the existing
    1394a interface (as currently proposed) to support Beta mode signaling
    and features:
    1. Retention of the ability to provide isolation.
    2. Larely retains teh 1394a signaling protocol.
    3. Retention ...

    second page ... 1.1.2 Clocking

    third page ...

    fourth page ... (includes a recommended pin ordering)

    <LReq must remain synchronous to SClk return(?) ...>

    <At higher speeds, will you not need to put out LReq earlier ... ?
    Unless we find we have more time ...>

    <What about using both edges of a clock instead of just one, which
    reduces sundry frequencies ...  Everything in open to discussion.>

    PHY-LINK committee should have formal recommendations by the next
    meeting of the full p1394b working group.

    The PHY-LINK group reflector is 'bphylink@zayante.com'

 6.2  Upstarts - Colin Whitby-Strevens

    The main progress to report is that the chairman was delinquent, and
    did not have materials ready for the editor's deadline for inclusion
    of that material into the present draft.

    There was a meeting between b-port and upstarts chairmen, divvying up
    the respective responsibilities.

    We have a service interface between start-up and beta mode.

    slide ...
    P1394a Suspend/Resume State Machine (part, simpified) as per Maui
    meeting.  See appropriate file on ftp site.

    <This state machine was altered back to the original of the suspend/
    resume proposal.  On power on, though, we decide whether the port will
    be allowed to work in either beta, or D/S, or both. ...>

    P1394b Eager Beta/Lazy a Algorithm for P2: Disconnected
    - Immediately start well-spaced (low power) pulse-toning on TPB,
      listen on TPA (details later)
    - If we hear the tone, then we know we are Beta mode
      - set Beta mode and go to P6: ...
      ...

    So, we have a model, and C-code that captures the discussions in Maui.
    I would like to have a select meeting of all those from the Upstarts
    interested in connectivity management through an optical connection.
    This should start immediately upon finish of today's session, and be
    limited to those who expect to contribute actively to keep the group
    small.

    <Will these materials appear on the reflector?  (Items such as the
    outlawing of AC coupling ...)

    <If there is an interface between a PHY and an optical transceiver,
    then we have a new interface to define.>

    <There is an alternate proposal by Jim Skidmore that would use D/S
    to come up, then arbitration codes to move to Beta mode.  This has
    the problem that it will not work with AC coupled interconnects.>

 6.3  Standard protocol - Alistair Coles

    Standard Protocol report - Alistair Coles, HP Labs

    Scope Includes:
    - Define handling of arbitration and data signals through beta
      mode ports, i.e. 'normal operation'.
    - Define forwarding of packets between ports within a 1394b
      PHY (ports may be ...
      ...

    Activity
    - email discussion of:
      - speed signaling
      - error handling
      - port logic sharing (or not)
    - Liaison with Upstarts
    - Substantial additions to draft text

    Progress
    - Majority feel that sharing of port logic elements (specifically
      the 8B/10B data coder and scrambler) is not worthwhile
    - generated a proposal for an interface and service model.
    - New speed signaling proposal - removes facility to "update"
      S200 to S400 speed signals - onus is on Rcving DS port to make
      a definite decision.
    - Some unilateral (and therefore subject to group review and dis-
      cussion) actions by task group chair:
      - ...
      ...

    Model
    <<< diagram >>>

    Proposed BPORT services
    - Beta port activate request
      - Status: Active/Inactive. Operating speed.
    - Beta Port clock indication
    - Beta port training request
      - train/lock
    - Beta port control request
    - Beta port speed signal request
    - Beta port data request
    - Beta port control indication
    - Beta port speed signal indication
    - Beta port data indication
    - Beta port .... indication

    Proposed CM services
    - CM status indication
      - port mode: DS/Beta
      - port speed
      - port status: Disconnected/connected/fault
    - CM Action request
      - Action: Suspend/ ...
      ...

    Open Issues
    - Error handling
      - we want to add a signal at the PHY/LINK interface to indicate that
        the PHY has detected an error in a packet (which the CRC may not
        detect).
    - Port Conroller specification
      - buffering, retiming and forwarding of packets to multiple ports at
        multiple speeds and multiple moves (DS,beta)
    - Timing specifications - need to be observable to be testable
    - Refinement of draft text and c-code

    <How about adding an interrupt like we have in .a?  How about counters
    for errors?  We need to keep an eye on cost, because all these cost
    money.  Why keep error data if the rates are in the parts per trillion?
    Couldn't we do a self-test in the PHY?  That's kind of what I'm des-
    cribing ... How much of this information do we store, and how do we
    pass this up to the higher layers?  Is this needed for the standard,
    or is this something that should be left to vendors?  There are problems
    that may be revealed by the 8B/10B coding itself, and would not be
    revealed by the CRC.  We might see errors in idle signals, and in the
    arbitration, that may at some point indicate that the connection is
    failing, needs retraining, etc. ... It is a detected error situation,
    and should be indicated ... Doesn't this indicate that error indication
    is mandatory?  It protects the level of error detection we have in the
    existing 1394 standard.  CRC gives us a level of protection.  Is this
    too much, or do we need to retain the level we have. ...>

    Plan
    - Review and comments on current draft are invited.
    - Continue discussions of open issues via email:
      bport@zayante.com
      (see www.zayante.com/p1394b for joining instructions).

    For those interested in seeing 8B/10B as used in an S100 1394 prototype,
    please stay after the meeting ... It's over in the corner ...

    Wooten:  There are things to watch here ... Things like supporting .a
    LINKs means that there are things that might break in .b accelerations,
    if we are not careful.  Keep your eyes open for these cross issues ...


 6.4  Standard electrical - Eric Hannah

 6.4.1  Electical characteristics - Eric Hannah

    Eric started, indicating that he will present the electrical material,
    while Del Hanson will present the optical.  Extensive use was made of the
    existing material from GbEthernet.

    The only testability point planned is for bulk-heads.  Finer resolutions
    such as board and chip level are too detailed, and specific to vendors,
    etc., and so though strip-line and other such characteristics must be
    specified, for the most part lower level testing is not specified.

    [Slide 1 ... text page from the spec ... 5.2 Transmitter electrical
    specifications]

    He discussed various of the electrical characteristics, including cable
    losses.  We are working to a nominal cable length of 4.5 m.

    [Slide 2 ... text page ... Table 5-3]

    Cat-5 long-haul is optional ... The question is who is going to do the
    work in driving signals over copper (S100 data rates) to 50 m.  So long
    as it is not a major burden, we should gain from support of Cat-5 as an
    existing base.

    <Opinion was expressed by others that requiring long-haul copper is a
    serious burden, and not likely to reach 100 m at a reasonable cost.
    Questions were asked about the current topologies in homes, which Dick
    Scheel said is typically Star, though you don't know what might happen
    as far as a home owner putting in one additional hop to "the next room."
    Support for Cat-5 long-haul may well cause problems in providing an
    economical high-speed PHY.  There was a dissenting opinion on this,
    though.  Comment was made (facetiously) that some people have coax
    as their installed base -- Where is the coax group?>

    < comments about whether we will ever support GbEthernet rates over a
    Cat-5 wiring system >

    [Slide 3 ... text page ... with table 5-4, Copper jitter Budget]

    < comments on fact that GbEthernet is keying off of Fibre Channel work.>

    <Fibre Channel does site jitter budgets, etc., at various point down the
    line.  There are two documents on FC: the specification, which is now
    quite old; explications of the standard.  The jitter study group docu-
    ments also come in to play.>

    <Isn't the present GbEthernet based upon 30 m?  Current 1394 cable is
    lossy, and probably not good for any distance at GBaud rates ... We need
    a cable recommendation that works for the rates we are dealing with.
    Eric would like to have a standard such that at a plug-fest you can
    determine compliance, etc.  Comments that the table includes lines
    that are marked as mandatory (bold text) which should not be.  There is
    more work to be done, though we now have at least a reasonable set of
    numbers for the spec.>

    <We might be able to specify the testing of cables via eye-pattern
    requirements, rather than specifying skews, etc., which are harder to
    test.  We currently plan to have some of this ... Most standards do not
    deal with cables as complete assemblies.  The current 1394 spec. specifies
    the cable without the heads, not as a complete assembly.  We need to
    address assembly qualification ... TA and others addressing this for
    compliance to -1995 outside the TA (outside agency/contractor).>

    <We have questions and potential problems with isolation and coupling of
    the shielding on the connector at the bulkhead.  The current standard
    has recommendations of capacitors, etc. ... Capacitive coupling of the
    shield and cable is currently required.  This is all tied into the "green
    wire ground" problem.  Debate over how this is done ... Will be addressed
    later.  Still, must pass FCC class B.  1394a should deal with this.  The
    question has to do with whether or not 1394 will be the poor man's LAN,
    or not, and whether the green wire problem is real or not.  Data will
    presented later today.>

    <Request to remove "in-line splice" from line 36 of the page.>

    [Slide 4 ... text page ...]

    [Slide 5 ... text page ... 6. PHY test modes (Normative)]

    This could be contentious ... How do we provide a level of observability
    for identification of errors, problems and incompatibilities?  I think
    we need to define some test modes.  PHYs are too d*** smart, making it
    difficult to tell what has been going on, and to do simple tests of the
    transceivers, etc.

    <Have you looked at the Fibre Channel test patterns?  Some, but need to
    do more ... Would you expect these tests to be able to be used by any
    application software, such as by end-users?  No, not really.  Phy vendors
    need to know that they have something between the PHY and the buldhead,
    so as to know that they must do better than the margins defined for the
    bulkhead ... So, we have a bulkhead margin, and an indeterminant margin
    between the PHY and the bulkhead.  What do we tell the PHY vendors to
    build?  System designers need to determine the margins they need, and
    will determine which PHYs are acceptable, while the PHY vendors know that
    they must provide adequate margins to qualify for design-ins.  How do
    you tell that a camera has a bit error problem or an out-right failure?
    Colin expressed a concern about variants in these approaches.  FC calls
    for testing via use of legitimate packets.  Eric said that you need some
    means of loop-back, and of testing the device in a non-standard operation
    to tell what is happening on a node.  Eric - I'm trying to define a
    problem here ... please be patient.  How do you monitor retries, and such
    for identifying the problems in a real bus?  We can't, right now, and
    there are problems ... We need to put a few stakes in the ground that
    people can know they can test to.>


 6.4.2  Optical characteristics - Del Hanson

    [Slide 1 ... text page ... 7.2 PMD block diagram]

    We are examining relaxation of some GbEthernet parameters to reach a more
    economical solution.  (GbEthernet is on track for a completion in early
    Feb., 1998.)

    [Slide 2 ... text page ... 7.4 Tansmitter optical specifications]

    < ... Conditioned launch to prevent any two modes from dominating ...
    Look at how much power is in the cent of the fiber as opposed to total
    power in the fiber ... Testing in lab in progress.>

    [Slide 3 ... text page ... 7.5 Receiver optical specifications]

    <Receiver sentivity reduced by 1 dB to reduce cost.>

    [Slide 4 ... text page ... 7.7 Optical jitter specifications]

    <Numbers are scaled according to the corresponding line rates ...
    implementation to these numbers at 2 GBaud will be a challenge.  There
    is not a lot of margin in the jitter budgets, so giving up any is an
    issue.>

    [Slide 5 ... text page ... 7.8.4 Relative Intesity Noise (RIN)]

    [Slide 6 ... text page ... 7.8.6 ...]

    [Slide 7 ... text page ... 7.8.10 Coupled Power Ration Measurement]

    [Slide 8 ... text page ... 7.9.7 PHY labeling]

    [Slide 9 ... text page ... ????]

    [Slide 10 7.11]

    [Slide 11 7.11.6 Alternative ...]

    I encourage you to read these sections, and comment.

    <Just wanted to make sure that this specification allows one piece of
    equipment to operate at 1 GBaud and another at 2 GBaud, and interoperate
    well ... We are limited to 50 m by this  ... I thing you misunstood the
    question ... 200 m range discussed ... will not operate at 2 GBaud at
    200 m ... Length at 4 GBaud is 50 m over 50 um fiber. ... Yes, we will
    be able to support interoperability of disparate speed devices by
    stepping down the faster device.  It is not a major cost differential
    to support 100 m at 2 GBaud.  We can live with 50 m at 4 GBaud, so we
    need to ask about the hop distances we want to support at S1600.>

    Does the group want to save the 5 to 10 % on the cost of the transmitter
    for supporting 100 m, as opposed to only supporting 50 m?

    <Fuller - This depends on not trying to go faster on longer hops ...>

    To limit to 50 m?  17
    As far as speed permits? 20

    Group is basically undecided.

    <How hard is the range limit (50 m) at S3200?  Very hard.>

    <Could you add a column for 100 m at 2 GBaud, so we can look at the
    problem later?  Yes, in a couple of weeks.>

 6.5  Cable/Connector - Max Bassler

    IEEE p1394b Connector Task Group
    Copper Interface for 800, 1600 and 3200
    Fort Lauderdale Meeting
    Max Bassler, Chairman, mbassler@molex.com
    Bill Northey, Secretary, northeywa@bergelect.com

    Requirements
    - Standard 1394-1995 I/O user friendly model with latching option
    - cost is very important for both computer and consumer interests
    - speed is given - 800, 1600, and 3200 Mb/s
      - develop eht 1394-1995 ...
      ...

    Issues and Draft Requirements
    - address speeds of 800+1600 as a priority, plan for 3200
    - Cost to be competitive with current 6 ckt system (relative).
    - Features:
      - backward copatible shape
      - latching option required
      - mechanical ...
    ...

    Plug Compatible
    - Must be plug compatible with 6 ckt IEEE 1394-1995 I/O
      - Flat SMT socket has the bandwidth so it will be the model ...
      ...

    Action Items
    - Maintain plug compatible interface
      - determine if new interface is needed for 3200 Mb/s
    - Solicit cable manufacturers to show improved attenuation and xtalk
      construction fo the 1394-1995, 6 ckt I/O
    - decalre patent policy
      - IEEE letter on file to make proposals
      - License policy and terms for presentations
      ...

    Tentative Meeting Schedule
    - December 12, 1997, Chicago
    - December 22, 1997, Chicago
    - January 5, 1998, Houston (afternoon)
    - January 19, 1998, Chicago
    - February 9, 1998, California (afternoon)
    - February 16, 1998, Chicago

    <December 12 is excluded as too soon. ...>

    <You talked about the connector present bit.  If that is present, then
    we don't even have to look for a connection.  Now you are talking about
    determining what speed we can operate at.  What are you up to, and how
    does this affect the Upstarts?  You seem to be addressing this as given.
    We need to know what you are doing to properly coordinate.  Wooten - I
    don't think this is a given, just a possible.>

    <The connector group would like to meet at the adjournment of this
    meeting.>

 7. Holes in the Spec. - Eric Hannah

    Major Holes
    - Copper
      - Gigabit connector
      - Gigabit cable
      - New Annex K
    - Fiber
      - Glass
      - POF
      -Testing/qualifications procedures
    -

    Copper
    - gigabit connector
      - current, new plug compatible, new not compatible
      - Cross-talk, impedance profile specifications
    - Gigabit Cable
      - ditto
    - New Annex K procedures

    Fiber
    - Glass
      - Connector choice
      - Amateur friendly installation tools
    - POF
      - Connector choice
    - Testing/Qualification procedures

    <If you don't specify a fiber, you may (almost certain to) have
    compatibility problems in matching fibers, down to the interface
    qualities, the connector, etc. ... Colin - Perhaps I should withdraw
    the comment that started this ... There is a chance of a POF that
    would meet 4 GBaud requirements.  Seperate media should be in seperate
    sections of the standard.  Do this lead us to another connector?  If you
    come up with a connector for low-speed plastic fiber, that should work
    for all plastic fiber, shouldn't it?  This is not a good idea, since we
    would need yet another fiber.  The number of requirements for a fiber
    optic interconnect is much greater than for a copper interconnect ...>

    PHY-LINK
    - Scalable Interface
    - Isolation to 500 V
    - Signaling choice
    - Clocking choice

    Protocol
    - Startup
      - state machines
    - Suspend/Resume
      - Signaling scheme
    - Arbitration enhancements
      - Define and validate

    Positive ...
    ...

    4 GBaud Physical
    - The electro-optical story is non-existent
    - The copper story is suspect

    <There is work on a 4 GBaud FC by at least one Japanese company, with
    a presentation to be made soon. ...>

    <Do you think these are being PLUGGED?  Eric - I'm more optimistic than
    I was.  We are working hard to ensure that 1394b is not a 21st century
    solution.  EETimes pointed out that FC is gaining ground.  We don't have
    the time to address this as a study group.  There are real economic
    pressures pushing us to finish in a timely manner.>

 8. Extra Items

 8.1  500V Isolation - Eric Hannah

    500 V Isolation
    ...

    LAN versus SCSI?
    - SCSI/Parallel/Serial Port
      - Short cable runs, local peripherals only
      - copper shields tie directly to the PC bulkhead
      - same green wire ground assumption
      - ground loops, galvanic isolation are ignored
    - LAN's
      - Long cable runs, daisy chains of boxes, distant peripherals
      - green wire grounds are uncontrolled
      - ...
      ...

    <Is this something to do with lightening strikes, etc.?  No, this has to
    do with whether your electrician wired your house wrong.  You really can
    melt wires.  In England, wiring two phases incorrectly gives you nearly
    500 V, while in the US, standard three-phase 440 V is real close, too.>

    IEEE 1394-1995 Example Barrier
    <<< diagram >>>

    ????

    Equivalent Series Resister
    ...

    Realistic Capacitive Barrier
    <<< two diagrams >>>

    [Isolation doesn't solve the problem, but it does help.]

    <Do we care about the delay here?  No. ... It's small.

 8.2  AMP Cable test results

    Michael Fogg, AMP

    Impedance Characteristics
    <<< three graphs >>>
    - TDR and 250 ps (filtered) risetimes
    - R/A and Vertical Receptacles
    - With and without improved termination features

    Attenuation:
    Output Eye Patterns for 2^23-1 PRBS Input
    S100/S200/S400 tested
    - 4.5 m assembly
    ...

    Attenuation:
    Output Eye patterns from 2^23-1 PRBS Input
    S800/ ...
    ...

    Attenuation:
    output eye patterns from 2^23-1 PRBS input
    <<< two graphs >>>

    [Existing cable should fail at S1600.]
    <Why did you choose through-hole for these tests?  This chart is for
    the surface mount?  Is this your improved surface mount?  No.  We are
    looking at what happens if you improve the termination area ...>
    <We will retest this with the modified 8B/10B code ...>

    Eye Pattern Summary
    S800/S1600/S3200
    <<< table >>>
    ...

    <What is the "ui"?  A unit interval, as a means of normalizing times.>

    Cable Assembly Radiated Emissions
    <<< diagram >>>
    3 meter semi-anechoic chamber
    ...

    <This a very premium, proprietary solution ... We don't want to force
    people to buy a $60 cable assembly ... Volumes should help significantly
    reduce cable costs.

    EMI performance: Radiated emissions, Typical S100
    ...

    EMI Performance: Radiated Emissions, Typical S100 Application
    <<< graph >>>

    [We are 25 dB over FCC class B here.]
    <The bottom line is the noise floor, with the cable removed.>
    <Not using the chassis for EMI shielding makes things worse.>
    <This is +/- 400 mV, for an 800 mV range.>

    EMI Performance: Radiated Emissions, Typical S100 Application
    Radiated emissions (3m) 1394b cable, S100 ...
    <<< graph >>>

    EMI Performance:
    Capacitive Receptacle Termination
    Radiated Emissions (3m)
    ...

    [Still exceed FCC class B by about 20 dB.]

    EMI Performance:
    Ideal REceptacle Termination
    ....
    <<< graph >>>

    [This is much better.]

    Connector Transfer Impedance
    <<< diagram >>>

    Transfer Impedance  ...
    Receptacle to Enclosure
    <<< graph >>>
    - Baseline data
    - seperable interface
    - 1 point of contact
    - 4 points of contact
    - 8 points of contact

    Transfer Impedance Results
    Selected Features
    - Baseline data
    - Separable Interface
    - Braid capture area
    - Vertical receptacle to board
    - Horizontal ...
    <<< graph >>>

    [Conclusions are: It can probably be made to work at existing rates, ...
    Trying to find ways to quantify these so as to make it easier to meet
    FCC requirements ... There has been some 10 m work done, which should
    be presented tomorrow or Friday at the .a meeting.]

    <... Was this grounded 360 degrees around?

 8.3  Cat-5 task group

    Scope: Cat-5 UTP only, RJ-45 connector
           S100 only, 50 m goal (examine cost vs distance)
           Binary signaling only

    Objective:
           Determine level of interest and feasibility
           If appropriate, generate spec. for draft

    Membership:
           Signup sheet being passed

    Meetings:
           Initially email and ad hoc at 1394b meetings

 9. Meeting Schedule

 9.1  January (Houston - 1/6&7) (David Wooten and Richard Churchill)

 9.2  February (Monterey Bay/Santa Cruz area - 2/9-12) (Mike Teener)

 9.3  March (Phoenix - 3/18-19ish) (Steve Bard)

 9.4  April/May (Newport Beach - 4/28 to 3/1) (Brad Saunders)

 9.5  June (St. Petersburg - 6/9-12?) (Chuck Brill)

 9.6  July (Bath, UK - 7/13-14) (Colin Whitby-Strevens, 
           Alistair Coles and David Instone)

 9.7  August (Invitation from Steve Finch for South Lake Tahoe)

 9.8  September (St. Petersburg - 9/14-18) (Chuck Brill)

 9.9  October (Maui, Hawaii - October 19-23) (Masood Shariff)

 9.10 December (Invitation from Norm Harris for Fort Lauderdale)

10. Action Items

11. Adjournment
                          
=============================================================================
Attendance List

Tatsuya Arai
tatsuyaa@hiroseusa.com
805-522-7958

Bob Atkinson
rdatkins@amp.com
717-592-4274

Oleg Awsienko
oleg_awsienko@ccm.ch.intel.com
602-554-9666

Steve Bard
steve_bard@ccm.jf.intel.com
503-264-2923

David M. Barnum
dbarnum@stwconn.com
717-235-7512

Max Bassler
mbassler@molex.com
630-527-4490

Karl Bergstrom
mpeg007@aol.com
800-888-0211 x4563

Vilas Bhade
vilas@wipro.com
408-777-4723

Mike Borgman
mjbo@panduit.com
708-460-1800

Charles Brill
cebrill@amp.com
717-592-6198

Mike Brown
mike_brown@ccm.ch.intel.com
602-554-3713

Robert Campbell
rrcampbell@lucent.com
732-957-2669

Dao-Long Chen
dao-long.chen@symbios.com
970-223-5100 x9461

Richard Churchill
richard.churchill@compaq.com
281-514-6984

Dan Colegrove
colegrov@us.ibm.com
408-256-1978

Barry Colella
bcolella@neccsd.com
978-635-6380

Alistair Coles
anc@hplb.hpl.hp.com
+44 117 922 8750

Eric Deliot
ed@hplb.hpl.hp.com
+44 117 922 9539

Bill Duckwall
duck@zayante.com
408-461-4902

Firooz Farhoomand
firoozf@ix.netcom.com
408-653-4059

Stephen Finch
steve.finch@tus.ssil.com
714-573-6808

Mike Fogg
mike.fogg@amp.com
717-986-5802

Bill Frank
bill.frank@wdc.com
714-932-6402

John Fuller
jfuller@microsoft.com
425-703-3862

Dave Gampell
dave_gampell@hp.com
408-435-6680

Jon Hanmann
jhanmann@dt.wdc.com
714-932-5189

Eric Hannah
ehannah@mipos2.sc.intel.com
408-765-4441

Del Hanson
del.hanson@hp.com
408-435-6246

Norm Harris
nharris@corp.adaptec.com
408-957-2230

Jerry Hauck
jerry_hauck@ccm.sc.intel.com
408-765-5528

Keith Heilmann
kheilman@us.ibm.com
914-892-2413

John Hill
jhill@amp.com
717-592-6175

Jack Hollins
jack_hollins@eng.adaptec.com
408-957-2309

Derek Imschweiler
dimschweiler@stwconn.com
717-235-7512

Tatsuo Inoue
inoue@ba2.so-net.or.jp
+81 3 5545 7813

David Instone
dinstone@uk.xyratex.com
+44 1705 486363

David Johnson
dkjohnson@ti.com
972-480-3632

Prashant Kanhere
prashant@macrodesigns.com
510-668-1773

Marcus Kellerman
marcus.c.kellerman@wdc.com
714-932-5000

Al Kelley
akelley@tensolite.com
904-829-5600 x281

Dave LaFollette
dlafolle@mipos2.sc.intel.com
408-765-2587

Farrukh Latif
flatif@lucent.com
610-712-7546

Paul Levy
paul.levy@vlsi.com
602-752-6382

Francesco Liburdi
liburdif@hollingsworth.com
607-748-0025

Robert Liu
robert_liu@ccm.intel.com
408-765-6549

Daniel Meirsman
daniel.meirsman@leu.ce.philips.com
+32 16 390 733

Jack Merrow
jmerrow@leviton-telcom.com
425-486-2222

Akihiro Miyachi
amiyachi@molex.com
+81 462 65 2329

Takatoshi Mizoguchi
mizoguti@shino.sharp.com
+81 745 65 1161

Reza Moattar
reza.moattar@tsc.tdk.com
714-508-8731

Palanisamy Mohanraj
palanisamy_mohanraj@ccm.ch.intel.com
602-554-4243

Susumu Morikura
morikura@isl.mei.co.jp
+81 6 906 4896

Farrokh Mottahedin
fmottahe@qntm.com
408-324-7934

Kazuki Nakamura
kazuki-n@dtinet.or.jp
+81 8275 3 5320

Richard Nesin
nesin@lucent.com
610-712-6785

Yashiro Nieda
nieda@pluto.dti.ne.jp
+81 3 3245 8750

Bill Northey
northewa@bergelect.com
717-938-2119

Ozay Octay
ozay_oktay@cissc.canon.com
714-856-7180

Bill Pherigo
whp@fc.hp.com
970-229-3586

James Piccione
james.piccione@smi.siemens.com
408-895-5136

Bill Prouty
billp@hprnd.rose.hp.com
916-785-4631

Dick Scheel
dicks@lsi.sel.sony.com
408-955-4295

Masood Shariff
mshariff@lucent.com
732-957-5479

John Smolka
jsmolka@ti.com
972-480-2094

Ron Soderstrom
rows@vnet.ibm.com
507-253-6290

Martin Sodos
msodos@issiusa.com
408-969-4683

John Ta
john.ta@tus.ssil.com
714-573-6957

Ju-Ching Tang
jctang@corp.cirrus.com
510-623-8300 x5189

Peter Teng
pteng@mail.com
408-588-5555

Toru Ueda
ueda@slab.thr.sharp.co.jp
+81 743 65 4529

Sushant Verman
sushant@lsil.com
416-620-7400

Kenji Watanabe
mabeken@sslab.sony.co.jp
+81 3 5448 5362

Colin Whitby-Strevens
colinws@bristol.st.com
+44 1454 611500

Donald Wiencek
dsw@panduit.com
708-532-1800

Shuntaro Yamazaki
yamazaki@ccm.cl.nec.co.jp
+81 44 856 2082

Wan Yoon
wjy@aluxpo.lucent.com
610-712-2503

Phil Young
youngp@euk.nec.co.uk
+44 1908 837247

Michael Zarreii
mzarreii@????
717-767-8030

Peng Zhang
pzhang@ti.com
972-480-3109