So you're new to lab? Cool, welcome. Like any new environment, there's a lot of new stuff to learn and it's all probably pretty overwhelming. Unlike jobs or internships you may have had in the past, however, getting started in academic research can be harder. We don't have “New Employee Onboarding”, we don't have an HR department, and your advisor is not your manager.
Ubiquitous computing is an interdisciplinary field. However, our lab's main focus to-date has been on a) embedded systems side of things and b) AR/VR. This means that at some point you will most likely be doing board design and fabrication. If you do not have these and other relevant skills (soldering, etc.), it is your responsibility to learn them and to say something if you get stuck.
A major part of grad school is learning when to ask for help, and when to figure things out yourself. On the one hand, success in academia requires being self-motivated and self-reliant. By definition, if you are doing cutting edge research, you are attempting to solve a problem or to answer a question that literally no one else in the world knows the answer to. If you have made it this far, you are probably an independent problem solver, and certainly nothing less will be expected from you as you progress in your career. However, even for independent problem solvers there exist common tasks that often pose difficulties, despite the stupidity of something so common still being so difficult. For a long time, installing a cross-compiler was an excellent example of this. Installing TinyOS is another great example. In embedded systems especially, you're lucky if a thousand people in the world have ever tried to use a given tool, which makes finding external and maintaining internal documentation challenging. In cases like these, help from a colleague can avoid hours of frustration.
That said, the lab is predominately populated with experienced computer engineers, who often assume that everyone else in lab shares their background. If you are missing large parts of a computer engineering or embedded systems background, when asking others in lab for help you need to make explicitly clear what you have tried, what you have figured out, and what you still specifically need help with. This will give the others some insight into where you are mentally and increase the likelihood that you will receive a helpful and complete answer, rather than a vague one that relies on background that you do not have to fill in the details.
There are many tutorials on this wiki for using tools, setting up environments, and even institutional processes like ordering lunch. If you have a question, check the wiki first and see if the answer is there.
We have a lot of them. And this list (being a list on a wiki that rarely sees updates) will likely be incomplete, but hopefully it serves as a good starting point.
TLDR: If you want access to lab resources - Please mail Pat/Branden the following:
a) Your preferred username.
b) Your github handle.
c) Your public SSH key.
~/shed/ $ tree -L 1 . |-- classes Materials for courses we've worked on. Mostly a convenient repository that was already set up. |-- eagle Useful tools for using EagleCAD (see further below). **Not** projects. |-- externals Legacy. Do not use. |-- funding All of the fellowship applications anyone from our lab has submitted. Good resource for finding fellowships to apply for, seeing example essays, and reviews. |-- generally_useful Some random things that don't fit the other categories. Notes from meetings are tracked here. |-- papers All of the papers our lab has written. | |-- create_paper_tup.sh Use this script to create a new paper. |-- projects Older projects from our lab before migrating to github. Some things in here are still used. |-- scripts Some useful scripts for making life easier. It is recommended to add this to your path (e.g. in your .bashrc, PATH="$PATH:~/shed/scripts") |-- sdr The uSDR project. This should probably be moved. `-- tinyos Legacy. Do not use.
svn co svn+ssh://energy.eecs.umich.edu/svnroot/shed
svn co svn+ssh://nuclear.eecs.umich.edu/svn/shed-media
svn co svn+ssh://nuclear.eecs.umich.edu/svn/shed-data
\\winsww.eecs.berkeley.edu\macswwand login as
EECS\<iris-username>(need to use the EECS domain).
Library Access and Full Tunnel), EECS software (see above) and license activation checks (e.g. Windows 10), and as a VPN when traveling (tends to be blocked less than large commercial ones).
aspell -c intro.tex(or w/e), it will fix your problems.
imagesfolder, not figs.
Habits we've formed over time that have proven to be a good idea, loosely organized.
All of our projects live in project boxes. A project box contains all the extra boards, extra parts, working boards, documentation, etc to build a project. Project boxes are sorted alphabetically and live on the back storage shelf. Don't take things from other people's projects without asking. If you need a project box, ask.
All of the parts for your project should live in your project box. Digikey (and other supplies) ships you each part in well-sized bag. Keep this bag. Digikey staples labels to the bags, these have been known to fall off. The label is a sticker, however. When you get parts, stick the label to the bag itself.
We (loosely) have a repository per-project. All repositories are part of our github organization (github.com/lab11). Do not put things in Dropbox. Do not just keep things on your local machine. Learn how to use version control and use it.
For the most part, this is whatever you'd like. The only exception is when building boards. We have some conventions that you have to follow for all of the scripts to work.
The following layout is an example of one project, with several boards–some with multiple revisions–, some supporting software, and other information:
[bash] Sun 27 Oct 19:22 [ppannuto:pfet-v2[master] ~/code/lab11/gecko] $ tree -d . . |-- contiki | |-- apps | | |-- adctest | | |-- framtest | | |-- SEHmonjolo | | |-- SEHpacket | | `-- spitest | `-- platform | `-- sehnsor | `-- dev |-- hardware | |-- datasheets | |-- gecko | | |-- rev_a | | |-- rev_b | | `-- rev_c | |-- gecko_power_supply | | |-- rev_a | | |-- rev_b | | |-- rev_c | | |-- rev_d | | `-- rev_e | |-- impulse | | |-- rev_a | | |-- rev_b | | `-- rev_c | |-- sEHnsor | | `-- rev_a | `-- solar_panel_mount | |-- rev_a | `-- rev_b `-- media
An example from the above project would be:
[bash] Sun 27 Oct 21:18 [ppannuto:pfet-v2[master] ~/code/lab11/gecko/hardware/gecko/rev_c] $ tree . . |-- gecko_bom.xls |-- gecko.brd `-- gecko.sch
EagleCAD is… okay software. It has a few properties that are nice:
This matters. One of the more fundamental tenets of science is the reproducibility of experimental results. Frustratingly, academic experiments are notoriously hard to replicate. We try to do better than our peers in this regard. This is the reason that all of our work goes into a repository and why that repository is available to the public. Initially, the availability of Eagle was a motivation for choosing it. The reality is that people have the CAD software they have. Our reasons for sticking with it now are mostly that we have a reasonable corpus of experience with it and it's cross-platform.
Eagle is not a tool for “thinking” out a circuit. It is for capturing a final design and producing it. Fundamentally, it is a CAD tool, it is not a circuit design tool. The brainstorming / design / etc stage should be done on pen and paper, or whiteboard, or something like SPICE if you need to actually model circuits. This means that by the time you're opening Eagle, you already know what your schematic is going to look like, because…
In order to create a schematic, you have to have parts to place on the schematic. While Eagle has built in basics (resistors, caps, etc), they do not have parts for every IC ever conceived 1). While there are some crowdsourced part libraries online, the unfortunate reality is that the crowd is pretty bad at making parts well, or even making them correctly. Once you start getting comfortable making your own parts, this will really be a pretty quick part of the process, but to some degree it will always be a little annoying.
When you make a new part, in the Package editor (the last step where you connected pins to pads), there is an option at the bottom of the screen to add Attributes to you part. For every part you make, add an attribute indicating the supplier and the supplier part number (e.g. name = “DIGIKEY” and value = “ND-101”). This is the supplier, not the manufacturer. This will make your life easier when you generate a bill of materials (BOM).
We have a small library of parts we use often in
shed/eagle/lbr. You can “trust” these parts. We've used them on boards and they have been proven to work. We also have a copy of the sparkfun part library here. These parts tend to be usually good, but you should give them a once over.
Schematics should be clean and well organized. A new Eagle file is completely blank. Start by adding a frame from our
shed/eagle/lbr/frames.lbr. This frame will ensure relevant information ends up on your schematic (your name, board name, page numbers, etc). Next you should add a Block M from
shed/eagle/lbr/logos.lbr. Branding is important, it helps associate our work and is good for promoting you as a researcher. For the same reason, your name should be on the board when you're done. Don't forget to fill in your name on the frame part.
Draw your schematic in a way that is useful, such that someone unfamiliar with your design could glance over an figure out. Learn what named nets are and use them—you shouldn't need to cross wires on a schematic.
Your board doesn't need to be 4 layers, 2 is enough. If your first board is a 4 layer board, it's probably going to be too complicated to get right.
Ask someone about these things if you don't know what they mean:
Use the smash command liberally. Move labels around so they are somewhere useful. Values aren't that useful in practice, they're just noise.
Make sure all your silkscreen is vector font, 12%, and at least .004, .003 if you really must but readability will suffer.
Put your name on the board. Make sure there is a Block M on the board. Put the date on the board. Put the revision on the board.
Once you're ready to go, use the
eagle.py script (located in github.com/lab11/eagle/scripts). This creates a nice zip file you can upload to the board house with everything you need.
Check this file into version control. Yes, on the surface this violates the “don't check in built files” rule of version control. In this case, however, you are checking in files that should never change. These files capture the state of exactly what you built. If you want to build more copies of this board, you should use exactly these files, you should not recreate them. If you need to change something (even something tiny, “one little airwire I missed”), then you create a new revision. This is non-negotiable. A shipped board is a golden master. It is unchangeable.
We primarily order from Sunstone, we also use Advanced Circuits from time to time. If you're ordering from Sunstone, we have a collection of the coupons they send us available here. You can only use one per order, but you can use it on multiple orders (they seem to time out every couple months or so). The free expedite coupons are the most useful.