Customer Spotlight: Nathanael Huffman of Oxide

 

For a long time, we have been fans of Oxide and what they do. That is why we are happy to introduce Nathanael, who works at Oxide, where they make servers as they should be. Their mission is to "Kick butt, have fun, don't cheat, love our customers and change computing forever.", and that borrowed mission is a concise expression of why they're here and how they operate. We hope you enjoy reading about how Oxide is aiming to do things right when it comes to building cloud computing that you own.

Don't forget to check out the Oxide and Friends Podcast that they host on YouTube. It is great!

Tell us a bit about yourself and what you make.

I'm an Electrical Engineer at Oxide Computer Company. We make rack-scale computers for companies that want cloud-like, API-driven compute resources but need the computers to be machines they own and host on-premises (either locally, or at a colocation datacenter of their choosing).

We aim to own and maintain the full stack, from the motherboards and circuit boards, which we design in-house, to the embedded software that provides system management, to the virtualization layer, controlplane, and web interface that the customer interacts with.

We have a pretty small hardware team, so we all wear many hats. You can find me designing and building test boards, writing FPGA code, doing rework and board bring-up, or writing ECOs (Engineering Change Orders) on any given day, depending on what is needed!

What are you building with your LumenPnP? 

I've primarily used the LumenPnP for smallish runs that fall into our "test board" category.  Our product boards are very large, many use somewhat exotic PCB materials, range from 18 to 26 layers, and can have more than 10,000 part placements. 

Throughout the design of our first and second generation server sleds, we've discovered that we often like to prototype some of the foundational embedded subsystems without the "rest" of the server sled. This has enabled early discovery and provides a much more convenient (and quiet!) means of allowing our hardware and embedded software teammates to work on enablement functions without needing the lab infrastructure for portions or all of a rack.

We're a remote-first company, so sending even slimmed-down rack-sized equipment to everyone's homes for their work doesn't scale well. We prototype these subsystems, where possible, with lower-tech, fast-turn PCBs, and I've used the LumenPnP on many of these. We also design and manufacture the end-of-the-line programming and test fixtures, and have a number of lower-complexity boards used there that have been built on the LumenPnP.

What is your favorite feature of the LumenPnP?

I love that it's open, though not strictly a "feature" of the machine vs the design.  I actually think this is key, you can buy other PnP machines, but they aren't open, so the limits of hackability and self-troubleshooting are in your own (or our internet friends') motivation to reverse engineer this stuff. With the LumenPnP, it's all open, no real reverse-engineering required! If I have to pick machine technical features, it's a toss-up between feeders and vision, but neither is sufficient without the other.

How many boards a month do you produce with your machines?

Since this is used primarily for test, debug and design our usage patterns are somewhat bursty where we'll build a number of units of a new design and distribute them and then have a bunch of downtime until we either get a new prototype design or need additional units or spares of something we've already built. Averaged out over the year, we're likely <10/month, but I might do 30+ units in a run, depending on what the demand is for a given design and to limit the amount of setup/teardown that needs to happen.

How were you building these boards before the LumenPnP?

Prior to the LumenPnP, we had some designs hand-placed for very low volumes (<5) and some done at a contract manufacturer. This is still the case, really, but we can now do larger "small" batches on the LumenPnP. Above a certain run size or complexity, it still makes sense to contract things out, and below a certain quantity, I'll still just hand-place since setup and teardown take real time.
 

What has the LumenPnP enabled you to do that you previously couldn't?

I like that I can set the job up and run a single board, push it through reflow, test it, and make adjustments with little downtime. When you go through a CM, it's more challenging to iterate, and you basically have to do the first one yourself before an assembly order for testing, or gamble that what you sent out will work well enough that you can afford to do a whole run.  

With the LumenPnP, I can run one, iterate/test/fix, etc., and then implement any needed changes and be running a larger lot much more quickly. While you can hand-place BGA parts or other small-pitch devices, having automation here helps the repeatability, allowing us to be more flexible in what kinds of parts we're willing to prototype with, even when we're not planning to produce at a CM.

What is the single most important piece of advice for people who are trying to get into PCBA production?

Solid fundamentals in rework and hand soldering of medium complexity designs pay off big in the intuition and understanding when troubleshooting reflow issues, as well as understanding what does and doesn't work in CAD from a design for manufacturing perspective.

Patience is required for doing setup, dry run testing, and dialing the machine and a given project in. Learn to panelize your designs yourself, and get a stencil "printer" or some other method of stencil repeatability. Good paste application is key to good end results!

What's your solder paste of choice? What do you use for a reflow oven?

Kester NP560 exclusively.

It's a bit pricey, but it's hands-down the best paste I've used, and I've tried most of the other common suggestions you find in the hobbyist/low-volume spaces. I currently have a toaster oven with a Controleo3 from Whizoo, but I'm looking at getting something a bit larger scale, as reflow in the toaster oven is my workflow bottleneck now when doing larger batches.