Curated FAQs library page. Drop
FAQs
Frequently-asked questions across the community — short answers, with links to the in-depth guides when you need more.
Use the following
Community Profile Link to create or edit your profile here. Your profile is public and will be linked to on forum posts and other activity on this wiki. You can also click your account name in the top navigation bar and then click 'User Page'.
This one comes from
your rig, not your scope — specifically electrical noise coupling in through shared power or an external trigger.
The signature that identifies it: banding that moves up the sensor, present at
low to moderate LED values around 16–24 rather than only when the LED is high; sensitive to LED power and sometimes to the EWL, but
not to gain. That gain-independence is what separates it from
FAQ/Horizontal stripes from the EWL driver, which is worst at maximum gain. In the reported case only one person in a lab of several scopes was affected — the only one using an external trigger.
Causes identified: a 3.3 V trigger line from a Raspberry Pi running on its own switching power supply; and USB LED lighting sharing a USB bus with the DAQs, or simply running too close to them.
The fix that worked outright: power the Miniscope from the DAQ's power jack instead of over USB. This means opening the DAQ case and moving a jumper, and it resolved the problem completely.
Supporting mitigations: put USB lighting on its own supply, and plug the switching supply into the same power strip as the computer so everything shares a true ground.
In-depth: Guide/How to test and debug your Miniscope V4
From the
electrowetting lens driver. It generates a
roughly 70 V square wave at about 5 kHz, and on each swing there is a current inrush the 3.3 V regulator cannot keep up with. That noise propagates back up the 3.3 V line to the CMOS sensor, which is unusually sensitive to it. The noise itself is very small — the sensor amplifies it into visible banding. Ordinary bypass capacitors do not isolate it, because the swings are slow.
A 47 µF capacitor between 3.3 V and GND does remove it, and sits near the EWL driver on current V4 PCBs. Boards at v4.2 and v4.3 predate this: LabMaker sold a hot-fix PCB for them, and it is designed in from v4.4 onward.
Every V4 shows a trace of this at maximum CMOS gain; below maximum it is usually invisible.
Removing it in post is straightforward: the stripes occupy a very specific spatial frequency that is localised in the 2D FFT. Take the 2D FFT of each frame, find the one or two localised spots along the x or y axis, zero those bins, and inverse FFT. The
official denoising notebook does exactly this.
Same root cause as the ephys noise in
FAQ/Miniscope noise in ephys recordings — one driver, two symptoms. If your lines look different from this, see
FAQ/Striping artifact on V4 images,
FAQ/Lines and instability at high LED values and
FAQ/Banding from ground loops and shared power.
In-depth: Guide/How to test and debug your Miniscope V4, Guide/Fundamentals of miniscope optoelectronics and imaging, Guide/Anatomy of a miniscope recording
Very likely
the wrong class of GRIN lens. This has cost multiple labs entire cohorts.
The V4 needs a RELAY GRIN lens. Relay lenses have a pitch a little less than
0.5 × n (n = 1, 2, 3 …) and roughly 200 µm front and back working distance.
An OBJECTIVE GRIN lens will not work with the V4. Objective lenses — for example Edmund 64-519, 1.8 mm diameter, 0.25 pitch — are what the
V3 used, implanted directly into the brain, and they have a pitch slightly under 0.25. The two are easy to confuse because both are sold as implantable GRIN lenses. The V4 images through a cranial window with no external lens at all, or deeper via a relay lens.
All relay lenses sold by Inscopix are V4-compatible. Salvage for animals already implanted with an objective lens: stack a second GRIN lens on top of the implanted one — the pair then behaves as a relay, and you may get usable imaging out of the cohort. The symptom is total darkness with healthy optics, verified expression and correct aspiration depth: exactly the case that otherwise sends people hunting for inflammation or photobleaching. See also
FAQ/Catalogue working distance and pitch are not what you get.
In-depth: Guide/Miniscope V4 part procurement
A
short across the coax cable sends a power surge through the
L13 inductor on the DAQ and destroys it. The three DAQ LEDs still look normal, but the data crossing the coax is corrupted and the connection fails every time. The damage is cumulative:
one bad cable will kill every DAQ it is plugged into, and at least one lab lost several before realising. Another had a cable that shorted only when bent into a particular position.
Test the cable: with the coax disconnected from everything, put a multimeter in continuity mode and touch the outer and inner conductors — or the SMA body and the centre pin. It should read open circuit; a beep means a short. Shorts are usually at one of the ends near the connectors, or along the length if the cable has been damaged. Trim back and redo the connector, or discard the cable.
Repair the DAQ: replace the L13 inductor on every affected board —
Digikey CBC3225T101MR. Two independent labs confirmed this recovers the boards. Occasionally it is not recoverable: if the short drew enough current to damage other components or the PCB, replacing L13 twice still failed in one case.
Desoldering tip: 390 °C is enough even for lead-free solder. If it will not melt, the iron tip is oxidised — add fresh solder to the tip first, then touch the inductor.
In-depth: Guide/How to test and debug your Miniscope V4
Use a commutator. The two most recommended options are: 1) OEPS torque-free coaxial commutator: uses the V4's onboard head orientation sensor to actively de-rotate the cable. We have had great experience using it and have also heard very positive reviews from the community. Requires Bonsai (with Jon Newman's Miniscope plugin) to control the Miniscope, because the commutator and Miniscope DAQ software cannot both own the USB data stream at the same time. 2) LabMaker open-MAC commutator is s a low-torque, Motorized All-in-one Commutator. It operates in torque-based mode with minimal audible noise due to its dual magnetic Hall sensors. The system accommodates 128-256 recording channels for electrophysiology and miniature endoscope (miniscope) / optogenetics applications. Passive commutators from DragonFly and Neurotek have also been used. Some older passive designs make image striping artifacts more frequent.
V4.5 (sold by OEPS) adds voltage-detection circuitry intended to work with an upcoming OEPS DAQ revision that will provide active over-voltage protection and regulated power delivery. With the current DAQ the new feature is inactive and V4.5 behaves identically to V4.4. Imaging hardware, optics, and the assembly procedure are unchanged. V4.4 and V4.5 are fully interchangeable within the same experimental setup. Contact OEPS for more information.
Miniscope V4 is the current generation (as of mid 2026). Key differences vs. V3: 1)
Electrowetting lens (EWL): V4 has a built-in EWL that lets you adjust focus electronically across roughly a 200 µm range. V3 had a fixed focal plane set by mechanical lens placement. 2)
Optics: V4 uses achromatic optics, dramatically reducing chromatic aberration in the objective itself. V3 used a 2 mm objective GRIN. 3)
Head-orientation sensor: V4 includes a Bosch BNO055 9-axis IMU. V3 does not. 4)
GRIN compatibility: V4 is designed for ~0.5-pitch relay GRIN lenses (Inscopix-compatible). V3's optical path used a 2 mm objective GRIN. For new projects, default to V4 (as of mid 2026) unless you have a specific reason to use V3 (e.g. an inherited surgical pipeline built around V3 optics).
This FAQ's answer lives on its page rather than in the Has answer field. In-depth: Guide/UCLA 2P Miniscope Assembly
Fully assembled V4 Miniscopes, assembly kits, DAQ boxes, baseplates, and coaxial cables are sold by Open Ephys Production Site,
OEPS and
LabMaker. Both vendors track the reference UCLA design. OEPS sells the most recent V4.5 board revision. Machined parts and a wide range of accessories are also available from
Miniscope Parts (Shylo Stiteler).
The most common source is Miniscope specific cabling from OEPS or LabMaker. That said, the community has had good experience with the 1.13 mm SMA-to-U.FL cables from data-alliance.net. They are flexible enough for free movement but stiff enough that passive commutators rotate them properly. DIY cables made from Cooner wire work, but soldering U.FL connectors reliably can be tricky and bad cables can damage your DAQ (see the L13 inductor FAQ).
into a content page (e.g. the wiki's FAQs page) to
render a searchable, filterable accordion view of every page in
Category:FAQ.
Renders, top to bottom:
- Header — h1 title + lead paragraph + a stat strip showing
total FAQ count and distinct guide-topic count.
- Filtered FAQ list — an SRF
format=filtered ask
that pairs the Template:UI/faqs_library/entry row partial
with client-side filter controls for Guide topic, Workflow stage,
Audience level, and Project. Each row renders as an
mw-collapsible accordion: question always visible
(clickable as a page link), answer expanded inline on toggle.
Project (Has project, Page-typed, multi-valued) is
surfaced as a sidebar-only facet — useful filter, but the chip
would clutter the row. Same pattern as Keyword + Project in
Template:UI/publications_library: positional arg passed by
the parent #ask so SRF can see the values, row
partial ignores it.
Why format=filtered for FAQs
FAQs are the canonical "I have a single question and want to find
it" use case. Faceting by topic / workflow stage / audience level
turns the page into a directory; collapsed-by-default rows keep the
page scannable when there are 50+ entries. Same SRF dependency as
the publications library — the deployment must ship Semantic
Result Formats with the filtered format enabled and
its JS/CSS module loaded.
If a future deployment ships without SRF, the fallback is a plain
format=template list using
Template:UI/faqs_library/entry (still functional — the row
partial degrades to "always-expanded" because the
mw-collapsible class is inert without MW's JS module).
There's no chip-strip + Special:SearchByProperty
no-JS path here; the page-fork to SearchByProperty is
worse UX for an FAQ list than just rendering every answer inline.
Why the filtered-list entry partial takes positional args
Same rationale as Template:UI/publications_library: SRF's
list view named args=yes prefixes every param name
with a literal ?, which makes the row template
read etc. — fragile if SRF changes
that convention. Dropping list view named args=yes
and using positional {{{1}}}..{{{N}}} is the cleaner
shape. SRF guarantees positional order matches the declared
printout order, so the contract is stable.
Printout aliases (=Topic, =Stage,
=Audience, =Project) are still set
because SRF uses them as the filter sidebar labels. Pretty labels
for filters; positional args for rendering.
Why the answer is a property, not the page body
The library renders Has answer inline so the user
never leaves the page when they expand a row. An FAQ whose answer
lives only in the page body (free-form wikitext below the
dispatcher template) will still appear in the library, but its
expanded row falls back to a "View full answer on page →" link —
see Template:UI/faqs_library/entry for the empty-answer
handling.
Parameters (all optional)
heading — page heading (default: "FAQs"). Empty
string suppresses the <h1>.
lead — short intro paragraph below the heading
(default: a generic explainer about Q+A topics).
limit — how many FAQs to load into the filtered
list (default: 200). Set higher than a normal feed because
filtering happens client-side over the loaded result set: too
low a limit hides matching FAQs from the filter UI.
Cross-template dependencies
filtered list.
- Template:UI/kpi_card — used for the stat strip.
- Semantic Result Formats with the filtered format enabled
($srfgFormats includes filtered). The
filtered-format JS/CSS resources must be loaded; without them
the list will render but the filter sidebar will be inert.
- MediaWiki's
mediawiki.page.collapsible module must
be loadable on the target wiki — it's part of core, so this is
effectively always satisfied. Without it, the accordion rows
stay always-expanded (functional, just verbose).