Elmer / Zeus (HomeNet)

Elmer and Zeus were demonstration enclosures for WebTV’s HomeNet program. They brought existing boards, purchased cards and custom adapters together to demonstrate functions intended for a future home network. The mechanical task was to make that changing arrangement buildable, then carry useful Elmer work into Zeus while redefining the interfaces that had changed.

Through Mechanistic, I developed the enclosure and bezel geometry in Pro/ENGINEER, coordinated component and board interfaces, and worked with the prototype and sheet-metal suppliers. WebTV supplied product requirements, electrical design and component inputs. Industrial design, model making and system assembly had their own contributors.

The opening image is a November 2000 review layout, with original handwritten perforation changes. It captures the practical work between a component arrangement and a part ready to fabricate. The complete annotated layout retains the review legend and questions.

Establishing the interfaces

In September, I proposed that WebTV have PSDA or another industrial designer develop the bezel concept, while I concentrated on the component database, mechanical design and prototype coordination. My job was to implement the selected design in Pro/ENGINEER. The inputs I requested were concrete: PCB outlines, drive dimensions, fasteners, finish specifications and reference component geometry. I also asked which components ran hot, whether the board had been thermally evaluated and whether a fan was needed.

The starting geometry also had to be recovered. Frank Salinas requested current Mercury sheet-metal files from Bermo; Ron Draeger explained that his files represented older part revisions. I wanted usable reference geometry to prepare quick-turn quotations. Ron later reported recreating the base and preparing an assembly with a dummy board for spacing. That supplier work remained distinct from my adaptation of the Elmer enclosure.

Leonard Bernal supplied an Elmer prototype DXF. On September 19, I reported a clean import and that I had given PSDA the outline dimensions. Getting usable information into the model was an early milestone; it still left finish, component and fabrication decisions to resolve.

The Mercury-based worksheet shows this work at component level. It crosses out unused assemblies, identifies custom bezel and sheet-metal work, and includes a column labeled Spec?. A specification entry is not proof that the part was installed. Its power-supply row illustrates the distinction: the list includes a Mercury supply, while a later row excludes a support because a different supply was being used. This was a reference inventory with exceptions, not a final Zeus bill of materials.

Reworking the Elmer hardware

By late October, the work had moved into bezel and enclosure revisions. The status correspondence assigns the Pro/ENGINEER bezel assembly to me and physical assembly and finishing to Val Kasvin at Sputnik Models. Export logs from October 26-27 preserve the bezel, glass, lens and foot geometry work under my user name.

The team also considered a double-height combination of Elmer and Mercury. The October 25 update explicitly dropped that alternative in favor of the existing Elmer box. The correspondence records the decision without establishing a thermal or structural reason for it.

On October 31, WebTV reported five Elmer enclosures in review. I was preparing the modification list for the PCI card, reset switch and related interfaces. A larger repeater IR receiver and a new lens required bezel rework. The team planned viewing-angle and distance tests. The November 1 update records lens-fit work and my enclosure-modification handoff to Val, without reporting a completed optical test.

Turning Elmer into Zeus

Zeus brought another component arrangement into the same enclosure lineage. Leslie Leland’s November 1 explanation distinguishes the demonstrator from the intended product: off-the-shelf hardware would simulate functions planned for future custom chips. Zeus was the server demonstrator, with Pluto identified separately as the node.

The November 5 proposal made reuse conditional. WebTV wanted to preserve the Elmer bezel assembly and top cover where possible, while the different I/O required a remade base. The mechanical scope included component modeling, additional PCB retention, board placement, I/O changes, prototype release and direct vendor support. Its 100 planned hours describe the proposed work allocation, not measured elapsed effort.

The reuse objective did not leave every part unchanged. The later supplier correspondence makes that distinction explicit: the top had a minor change, the base had several changes and the fan bracket was new.

Connector identity drove the rear boundary

One small correction shows why the I/O panel needed real component data. In November, I asked Keva Nelson to verify the Mercury connector specifications. Her initial reply supplied a single D-sub reference. The next day she corrected it to the stacked 310-01022-100.

The verified supplier drawing shows the dual-port 9-pin-over-25-pin arrangement. A superficially similar connector name would have left a different physical envelope at the enclosure boundary.

Board mounting required the same precision. Erturk Kocalar and Leonard needed the Ethernet card’s mounting-hole locations and PCI pin A1 relative to the USB-adapter reference. The DC connector was still provisional near the intended sheet-metal release. I noted that jacks could be added in the lab if necessary; the surviving exchange does not establish whether that contingency was used.

Reviewing contact area and perforations

The thermal discussion centered on a tradeoff in the chassis bottom. Mark Carbone questioned whether a perforated region would leave enough metal in contact with the aluminum heat-spreader bar, especially if the chassis was not flat. Leslie discussed the compliance of the thermal material and asked for more openings in the gap between the PCB and power supply. Roy Askeland cautioned against closing holes with the information available and clarified that Mercury used one gap pad per heat spreader.

The annotated layout connects those comments to the actual drawing. It marks areas to remove and add perforations, retains questions about placement, and identifies the hatched regions as new perforations. The fax strip dates the underlying drawing to November 15. Leslie sent this exact image on November 16, saying the existing sinks and slugs would not require sheet-metal changes. Her November 17 follow-up states that she had asked me to remove perforations under the main PCB and increase them between the PCB and power supply.

This is a documented review and revision instruction. The record does not establish a newly added second thermal pad, final fan direction or a passed thermal test. Those distinctions keep the drawing useful: it shows what the team was deciding without turning the markup into an as-built thermal report.

From geometry to fabricated parts

Three November 19 export logs identify the top, base and fan bracket released from Pro/ENGINEER under my user name. The top export itself spans the program names: ELMER_TOP becomes a Zeus-top file.

On November 20, Shelly Evans acknowledged receiving the files. The November 22 reply explains that the Zeus top added a hole and a zinc-plating callout. WebTV ordered five enclosure sets. On December 1, the supplier announced delivery of five tops, bases and fan brackets, then confirmed delivery. Erturk acknowledged receiving the enclosures in his December 4 reply.

The supported endpoint is physical enclosure receipt and subsequent assembly support. Five received enclosure sets do not establish five operating systems. The correspondence also asks whether the parts were plated; the reviewed reply does not settle their delivered finish.

Assembly still had open details

Documentation had its own division of responsibility. The November 22 exchange separated a board-level BOM correction from the still-planned mechanical and system BOM. Leslie would assemble quantities and descriptions with me, Erturk offered component and standoff information, and Keva would assign sheet-metal part numbers and standardize and route the BOM in Agile. The board ECO was not a release of the entire mechanical assembly.

With the sheet metal received, Leslie circulated a preliminary Zeus BOM for a lab review. It combined the Mercury main and power-supply boards with adapter, PCI, Ethernet, drive and fan assemblies. Cable modifications, connector screws and inherited mounting references remained part of that review.

On December 5, I confirmed that Zeus used 4-40 hardware throughout. Erturk’s reply still called for shorter standoffs because some earlier ones were too long. The thread records the intended fastener standard and the remaining fit issue separately. It does not close the final standoff arrangement or establish an audited as-built standard.

People and responsibilities

Elmer and Zeus remain one project lineage here. The record shows a sustained mechanical contribution from supplied interfaces and selected industrial design to revised geometry, supplier handoff and received parts. Final standoff closure, thermal and IR qualification, and operation of complete systems remain unestablished in the reviewed material.

Source trail

• The November 5 Zeus proposal defines the reuse objective, mechanical scope, responsibility split and planned work.
• The native Portal Node worksheet preserves its column labels, formatting and component exceptions.
• September-December correspondence records the component, layout, prototype, thermal-review, fabrication and assembly sequence.
• The exact Perf.jpg attachment links the handwritten review layout to Leslie’s November 16 message.
• Native export logs and the supplier’s dated acknowledgment connect the top, base and fan-bracket geometry to fabrication.