Consolidated Instructions Coming Soon (NOT)


Doug & Christina have prompted the team to work to bring together the existing instructions (some of which are on the website, some in Google Docs) into a single Google Doc as the master, with a web page and/or PDF file generated from the doc. We’ve produced an outline that has section titles for the content we want in the document, some of which exists already, much of which does not (mostly related to what happens after you’ve built the components). We’re now working to populate the doc with the content from the existing instructions for both the mechanical and electronic parts. This will still leave us with lots of empty sections that we’ll need help to populate. Please speak up if you want to chip in!

Note that this first version of the document will be based on the January 2017 design because we have several build teams that have ordered parts for this version of the design. Once we’ve got the existing content put together, along with some testing and assembly instructions, we’ll then make a copy of the document and update it with instructions for the March 2018 design; this has a different designs for the Camera Box (to accommodate larger cameras) and Pier (a narrower pier and top plate, reducing collisions between the camera box and the pier).



After working on the consolidated instructions for a few weeks, it became clear that this was an unwieldy solution. The team generally agreed that we should split the consolidated doc up because it was too large to manage, as well as being rather overwhelming for a new builder. This will make it easier to have multiple versions of instructions for one part of the system, without needing to do the same for all of the instructions. Along with the component instructions files, we’d also need to have an overview document that has links to the component instructions, along with links to the parts list(s). The overview will include a suggested order for the build. I expect that we’ll have documents covering at least the following topics:

  • Power Supply (used in later electronics testing)
  • Computer Setup (used in later electronics testing)
  • Camera Box Fabrication (includes mounting plates)
  • Camera Electronics (either legacy proto-board or new Interface Board)
  • Camera Box Assembly & Testing
  • Control Box Fabrication
  • Power Electronics (either legacy Telemetry+Power Boards or new Interface Board)
  • Control Box Assembly & Testing
  • Indoor System Assembly & Testing
  • Mount Weatherproofing
  • Pier Fabrication
  • Daytime Outdoor Setup (includes rough polar alignment)
  • Precise Polar Alignment (includes focusing)
  • Automated Operation

Nem has suggested that we include version numbers in the file names of the instructions (e.g. v1 for the original, non-PCB power board, v2 for the first PCB power board, and v3 for the new interface board under development). My inclination is to use year and month (e.g. 2017.01 for the first PCB power board, and 2018.xy for the new interface board, where we’ll pick xy based on the month when the new PCB is deemed ready for production). When such a file becomes invalid, we can update the name to indicate the last month when it was valid (something that can’t be done with version numbers). For example:

Camera Electronics Instructions - 2017.01 to 2018.08
Camera Electronics Instructions - 2018.09

This approach allows us to indicate when a component is no longer included:

Telemetry Board Instructions - 2017.01 to 2018.02
Telemetry Board Instructions - 2018.03 to 2018.08

(The telemetry board won’t be needed once the new Interface Board is ready.)

I’m also wondering about whether or not to split the parts list in exactly the same way, so for each version of a component instruction file we have a corresponding parts list. This would make it easier for the designers to manage the files, but would make it harder for builders to find a single list; we could write a script to generate a consolidated parts list.

I’d appreciate feedback on all aspects of this topic.


This is a good idea. The dates make it unambiguous which is nice. This also solves the issue that we have different versions of the head unit and other parts which are not in sync. with the electronics versions.

As per our discussions this week, maybe we could have a single document, possibly 2-3 pages long introducing people to the build, with some nice images, and a table of contents that lists the topics you have above for the items that need to be built with each item linked to the document for building that part? That way people dont even need to go looking for the files. They only need access to the first one.

This first 2-3 page document could also specify the difference of the various builds (i.e. old head unit has limited space so only works with 2 cameras and only small ones, new head unit can accommodate all sorts of cameras). Then people can make a decision and link to the build they want and the relevant parts list?

In regards to the parts list you could

  1. have a single parts list with very carefully labelled tabs or
  2. have a separate parts list for various versions of the build
  3. have a different parts list for hardware and electronics perhaps.
    In terms of being able to maintain the parts lists its always better to have a less. Generating a full parts list for a build would be great but I dont know how hard this is to do.

Regardless, we should limit the number of combinations there are so we dont have to maintain too many options. For example, once the 3rd gen electronics are ready, there is no need to advertise the 2nd gen ones. Also, there is no advantage of building the older head unit over the new one. So we should/could keep the drawings and parts lists, but we should push people towards gen3 electronics and the larger head unit. Less questions this way.


I’ve been whacking away at setting up the new structure for the instructions. You can find the results in the All Instructions folder on Google Drive. The folder and files in it are readable by anyone, so please do help out by reviewing them. If you want to comment on the docs or, even better, help with writing or updating the docs, please do let me know (you can reply here).

I wrote a document (About This Folder) that summarizes the general approach that we’ve agreed upon, has info about file permissions, and recommendations for the format of instructions documents.

There is still a lot to do, so to keep track of it I’ve started YAD (Yet Another Document) that has TODOs for this documentation project: Documentation TODOs.

I’ve also moved the multiple Parts List spreadsheets that the various active builders are using into this folder.


Great start James. As per our discussions today I thought Id summarize our vision on the forum for others.

James and I discussed the idea of simplifying the parts lists so that each module (camera box, camera board, etc), would have a separate google sheet, rather than a single tab in a sheet. Then a central google sheet would consist of four columns: 1) The module/step in the build, 2) the document name, 3) the link to the parts list for each individual module, and the 4) the link to the instruction set for that step. In this way, the main document outlining the build would simply be a 4-5 page overview with a link to this master sheet, where the builder would land and be confronted with a table that lists all the modules they will build, the parts needed and the instruction sets. Making it very clear what order to do things in and also easy for us to manage. This way everything would be managed for a simple 20-30 line spread sheet which gives the builder a great view of the build sequence.

We will start implementing this structure. Feedback and thoughts welcome.


Nem and I also discussed the benefit of having a diagram to show the build process, especially useful for the impatient (both of us) and those who find diagrams easier to absorb than lists of items (mostly true for me). I’ve been experimenting with using dot to produce a diagram showing the relationship of different build steps. For example:

The dot file (build_order.gv) for producing this looks like this:

digraph build_order {
  BuyParts [shape=box, label="Buy Parts"];
  BuyParts -> SetupComputer;
  BuyParts -> HookupUPS;
  BuyParts -> BuildCameraBoard;
  BuyParts -> BuildTelemetryBoard;
  BuyParts -> BuildPowerBoardV0;
  {SetupComputer HookupUPS BuildCameraBoard} -> TestCameraBoard;
  {SetupComputer HookupUPS BuildTelemetryBoard} -> TestTelemetryBoard;
  {SetupComputer HookupUPS BuildPowerBoardV0} -> TestPowerBoardV0;
  BuyParts -> CameraBoxFabrication;
  BuyParts -> ControlBoxFabrication;
  CameraBoxFabrication -> CameraBoxAssembly;
  TestCameraBoard -> CameraBoxAssembly;
  ControlBoxFabrication -> ControlBoxAssembly;
  TestPowerBoardV0 -> ControlBoxAssembly;
  TestTelemetryBoard -> ControlBoxAssembly;
  SetupComputer -> ControlBoxAssembly;
  HookupUPS -> ControlBoxAssembly;
  BuyParts -> BuildPier -> TelescopeAssembly;
  BuyParts -> WeatherproofMount -> TelescopeAssembly;
  TelescopeAssembly -> SystemAssembly;
  CameraBoxAssembly -> SystemAssembly;
  ControlBoxAssembly -> SystemAssembly;
  SystemAssembly -> SystemTesting -> Deploy -> PolarAlign -> FindExoplanets;
  FindExoplanets [label="Find\nExoplanets!",color=red];


As per discussion with Nem et al, I’ve put together a spreadsheet with links to the documents and parts list, in a reasonable build order. The first tab (2018.03) is intended to go with the current parts list (it does not yet assume that the new interface board is in use). If you look at it, you’ll see there are a number of TBD (i.e. missing) docs, and some In Progress notes related to the work that the PAN012 team is doing to update the docs to correspond to the 2018.03 parts list. Note that the spreadsheet includes tabs for the 2018.03 revision and the previous design that is still being built by some folks.