Questions to Ask Thomas





1. The "frequency stuff" — what Portiloop is tuned to, and retuning it for FFR

Background for you: Portiloop was built to detect sleep spindles, which are slow, easy-to-see bursts around 12–16 Hz that last a second or two. FFR is a completely different kind of signal — it's a tiny, continuous oscillation that's phase-locked to a sound stimulus, often in the 100–500 Hz range, and it's not a discrete "event" you spot, it's something you have to average over hundreds of trials to see at all.

Questions to ask:

  • "The Portiloop's neural network was trained to detect spindles as discrete on/off events. FFR isn't really an 'event' — it's a continuous oscillation locked to a repeating stimulus. Does that mean we need a fundamentally different architecture, or can we adapt the existing one?"

  • "What's the actual sampling rate the hardware can record at, and is that fast enough to capture FFR frequencies faithfully?" (This matters a lot — the Portiloop paper says its EEG board samples around 250–500 Hz. If FFR content lives above ~125–250 Hz, that's a hard ceiling from Nyquist limits — you might not even be able to record the frequencies you want, let alone detect them.)

  • "The onboard filters were designed for the 0.5–30 Hz sleep-spindle range. If FFR content is at 100+ Hz, do we need to change the analog front-end filter settings, not just the software?"

  • "Is 'attuned to' about the neural network's training data, the hardware's sampling rate, or the filtering — or all three? Which one is the actual bottleneck for our use case?"

  • "Given the hardware limits, is there a specific FFR paradigm (e.g., a lower-pitched stimulus, or focusing on the envelope rather than fine structure) that would be more realistic for this device than a typical FFR protocol?"

2. MMN as a positive control

Background for you: MMN is a different (and much bigger, easier-to-detect) brain response than FFR — it happens in the cortex when your brain notices an "oddball" sound in a repeating sequence. The idea of using it as a "positive control" is: if Portiloop can't even pick up MMN, which is a well-established signal other cheap/portable devices can detect, then any failure to detect FFR is probably a hardware/setup problem, not something FFR-specific.

Questions to ask:

  • "Does it make sense to run an MMN oddball task as a sanity check before or alongside the FFR validation, so we have a known-detectable signal to benchmark the recording setup against?"

  • "Is there a risk that adding MMN just adds complexity/time to the protocol without giving us information we actually need?"

  • "If Portiloop can detect MMN but not FFR, what would that actually tell us — that the hardware needs different settings for different frequency bands, or something else?"

  • "Would you use the same electrode placement/reference for MMN and FFR, or does testing MMN properly require different electrode positions?"

3. Should we look at EFR too?

Background for you: EFR is basically the "envelope" component of FFR — it's the same broad family of steady-state, phase-locked responses, but evoked using amplitude-modulated tones rather than pure tones or speech syllables, and it's been used a lot as a hearing-loss biomarker.

Questions to ask:

  • "Is EFR essentially an easier version of FFR to detect, given the SNR constraints we'll have with this hardware? Would starting there be a smarter way to establish feasibility before attempting harder FFR paradigms?"

  • "Given the papers on EFR stimulus optimization (modulation depth, duty cycle), is there a stimulus design that would give us the best shot at a detectable signal on limited hardware?"

  • "Is EFR within scope for my thesis, or would including it dilute the focus too much? Should I treat it as a stretch goal rather than a core aim?"

  • "If we do include EFR, does that change what frequency range we need the Portiloop to be sensitive to, compared to speech-syllable FFR?"

4. Referencing and filtering basics (so you understand the jargon going forward)

Here's the dumbed-down version so you're not lost when he explains it:

  • Referencing: EEG doesn't measure absolute voltage — it measures the difference in voltage between two points. One electrode is designated the "reference," and every other channel's signal is really "this electrode minus the reference electrode." Where you put the reference changes what the recording looks like, because you're subtracting out whatever's happening at that reference site too. That's why the in-ear paper you read compared "average reference" (comparing each electrode to the average of all electrodes) against "T7 reference" (comparing to one specific ear-adjacent electrode) — different reference choices can make the same underlying brain activity look bigger, smaller, or even invisible.

  • Filtering: This is removing frequency ranges you don't want, so the signal you do care about is cleaner. A "band-pass filter" keeps a specific range (e.g., 0.5–30 Hz) and throws away everything above and below it. This matters enormously for you because if Portiloop's filters were built to keep 0.5–30 Hz (sleep-spindle range) and throw away everything above 30 Hz, and your FFR signal lives at 100+ Hz — the filter itself would be deleting the exact thing you're trying to measure before it ever reaches the neural network.

Questions to ask:

  • "Can you show me exactly where in the Portiloop pipeline referencing and filtering happen — is it in the analog hardware, or in software after the signal is digitized?"

  • "If we need different filter settings for FFR than for spindles, is that a simple software config change, or does it require touching the hardware/firmware?"

  • "What reference electrode placement would you recommend for FFR specifically, given Portiloop's current electrode setup?"

One overarching question worth asking early in the meeting

"Given the hardware constraints (sampling rate, filtering, single/limited channels, and no trial-averaging built in), what's your honest read on whether full FFR is feasible on this device as-is — versus whether we should scope the thesis around EFR, or around demonstrating why it doesn't work and what would need to change?" This isn't a bad thing to ask directly — it'll help you and your advisor set realistic thesis boundaries rather than discovering hardware showstoppers halfway through data collection.