OpenDome is PortaDome’s lane for practical, documented, small-dome technology experiments. The goal is not to promise a finished low-cost planetarium system before the testing exists. The goal is to make each step visible, repeatable, and honest enough that operators and builders can learn from it.
Start With The Problem, Not The Parts
A useful OpenDome project begins by naming the problem it is trying to solve. That could be a projection bench, a fisheye adapter, a playback workflow, a transportable control kit, a calibration routine, or a documentation method for school setups.
Starting with the problem keeps the project grounded. A parts list without a test question can become interesting clutter; a clear test question can produce useful evidence even when the first build is imperfect.
Use A Controlled First Bench
The first OpenDome work should stay on a bench until the hardware path is understood. A bench test can document fit, signal path, software behavior, physical mounting questions, heat, cable routing, and obvious optical limits without pretending to be a full dome result.
Bench results should be labeled as bench results. They are useful, but they are not the same as tested dome performance.
- Name the test question before changing hardware.
- Photograph the setup from enough angles that someone can understand the path.
- Record exact hardware, adapters, software, and file formats.
- Separate observed facts from plans, guesses, and next steps.
- Stop short of claims about brightness, coverage, safety, reliability, or suitability until those have actually been tested.
Document The Whole Chain
A portable planetarium system is a chain. Content, playback hardware, software, cables, projector, lens or mirror, mount, dome, room, power, audio, and operator workflow all affect the result.
OpenDome notes should document the chain rather than isolate one exciting part. That makes later troubleshooting easier and prevents a single component from being treated as a complete solution.
Keep The Evidence Useful
Good OpenDome documentation is plain and concrete. It says what was tested, what happened, what is still unknown, and what the next controlled test should be.
Measurements should be included only when they were actually taken. If a measurement method is not ready yet, say that. A clear unknown is more useful than a polished guess.
A Starter Documentation Template
Each OpenDome lab note can use a simple structure. The format matters less than the habit of separating facts, observations, limits, and next actions.
- Purpose: the specific problem or question for this test.
- Hardware: exact models, adapters, mounts, and physical notes.
- Software: playback tools, versions, settings, and source files used.
- Setup: placement, signal path, power, audio, and control position.
- Observed result: what was actually seen, heard, measured, or confirmed.
- Limits: what was not tested and what should not be inferred yet.
- Next step: one small test that would reduce uncertainty.
What Belongs In Lab #001
The approved first OpenDome lab is a modular fisheye projection bench. It should document the real Peleng, projector, EF path, 3D-printed adapter work, and any actual fit or playback observations Rod is ready to share.
If the measurements, photos, or hardware details are not ready, the right move is to publish the starter path first and keep Lab #001 drafted until it can be specific.
What OpenDome Should Avoid
OpenDome should avoid fake certainty. It should not imply that a part is safe, compatible, bright enough, classroom-ready, or commercially reliable unless the evidence exists.
It should also avoid turning early experiments into procurement advice. Builders can learn from a path without being told to buy the same parts.
The Practical Path Forward
The first useful OpenDome sequence is simple: publish the starter path, assemble the Lab #001 evidence, document the bench, test one variable at a time, and convert real observations into reference notes.
That gives PortaDome a durable builder lane while protecting the project from invented specifications or premature claims.