Updates and Results
Talks and Posters
Advice
Ideas
Important Figures
Write-Ups
Outreach
How-To
Funding Opportunities
GENETIS
Advice
Draft saved at 00:00:00
Fields marked with
*
are required
Entry time:
Wed May 23 09:17:37 2018
Author
*
:
Subject:
<p><u>Lessons Learned from a Year in ARA Hardware</u></p> <ul> <li> <p>Test samples, then build batches.</p> <ul> <li> <p>If building a new board, always build one to completion to verify functionality before building the rest.</p> </li> <li> <p>We lost lots of time to the ARAFERFv5 for this reason.</p> </li> </ul> </li> <li> <p>Building in batches is easier than building to order.</p> <ul> <li> <p>Maybe this should have been obvious, but it is easier to build 10 of something in an assembly line than to build 10 to completion individually.</p> </li> </ul> </li> <li> <p>Strain relief is essential.</p> <ul> <li> <p>We ran into problems on both the APWR and the ARAFE RF boards with not properly strain relief-ing these systems. They will be jostled, and worse, handled by overzealous grad students. Strain relief the heck out of everything. Sacrifice board space if you have to.</p> </li> </ul> </li> <li> <p>Lead times suck.</p> <ul> <li> <p>We use lots of proprietary technology that can have long lead times (LARK filters, IsoRate cables/adapters, SBC and SSDs…). Plan ahead, and order in at least 25% excess. If you need 12, order 16 to allow for failures.</p> </li> </ul> </li> <li> <p>You always need spares.</p> <ul> <li> <p>Things break, or don’t work how you’d like them to, and sometimes the only solution is outright replacement. Order spares in the quantity ~20%.</p> </li> <li> <p>If you run out, assume you need a spare, and order immediately. Waiting until you actually, desperately need the spare is a recipe for high cost and unnecessary stress.</p> </li> </ul> </li> <li> <p>It’s not done until it has been thermal tested.</p> <ul> <li> <p>Solder joints crack, transistors aren’t wired right, amps don’t behave quite like you expect. It all happened this year. We must thermal test and validate the results before assuming something is ready for pole.</p> </li> </ul> </li> <li> <p> “Quick start” manuals are essential.</p> <ul> <li> <p>It is not enough to tell people to “read the code”. If you write a new piece of software, put a “1-minute guide" to its compilation and use in the header.</p> </li> </ul> </li> <li> <p>Redundant, deep experience is necessary. Parallelized skill is better than cascaded.</p> <ul> <li> <p>Having only one person with deep knowledge of how a system is put together leads to bottlenecking.</p> </li> <li> <p>Good counterexample: TUFF construction had two people, Oindree and Jacob, that could both fully build and characterize a TUFF without consulting the other person. Jacob and Oindree were “clones” of one another, so when something broke/got stuck, both could fully debug without needing the other.</p> </li> <li> <p>“Extra hands”, e.g., <em>untrained</em> students, are not the solution. The solution is to bring on a <em>long-term</em> second person who can <em>become trained</em>. Interim visitors (~1 week) are not helpful, nor is mass help (lots of students) who don’t have the time (several weeks of only lab work) to dedicate to becoming skilled.</p> </li> </ul> </li> <li> <p>Special cases are bad.</p> <ul> <li> <p>When at all possible, eliminate special cases in how station elements are constructed.</p> </li> <li> <p>Wire connectors, boards, etc for maximum “swappability”. The power box for A4 should work for A6 with no changes, etc.</p> </li> </ul> </li> </ul>
Encoding
:
HTML
ELCode
plain
Suppress Email notification
Resubmit as new entry
Attachment 1:
Drop attachments here...
Draft saved at 00:00:00
ELOG V3.1.5-fc6679b