Maya: Welcome to the Saturday edition of Monad Daily — Lab Journal day, the one morning a week where we put the paper stacks down and just ask: what actually happened in the lab this week? If you're new to the show, think of today as the behind-the-scenes cut — the meetings, the experiment setups, the small wins and the things still stuck on the whiteboard. This week felt unusually dense: two supervisor meetings with Igor, a student supervision with Lukas, a new GAT experiment sandbox, and somewhere between nine and ten reading batches that we are deliberately not recapping today. Theo, let's go chronological. Where did Monday land?
Theo: Monday was mostly carry-forward from the April architecture sprint. The big milestone from late April was getting the IndoorGML PostGIS schema scaffolded — that's the spatial database layer that lets us anchor CSI and BLE observations to actual room geometry rather than just abstract node IDs. By Monday that schema was stable enough to reference in the thesis chapter outline, which fed directly into the IP-060 thesis drafting run logged on the fifth. So Monday was partly writing, partly making sure the spatial foundation wouldn't need to be rebuilt before experiments start.
Maya: For students who haven't heard the IndoorGML thread before — what's the one-sentence version of why the spatial layer matters so much here?
Theo: IndoorGML is a standard for representing indoor spaces as a graph of navigable cells — rooms, corridors, doorways — and storing it in PostGIS means every sensor reading can be tagged with 'this observation came from cell 14, which is the seminar room on floor two,' rather than just a hardware address. That becomes essential the moment you want to generalise a crowd model across buildings, which is exactly what EXP-004 is designed to test.
Maya: Got it — the map isn't decorative, it's load-bearing for the science. Now Tuesday the sixth had the first Igor meeting. What was the agenda for that one?
Theo: The Tuesday meeting with Igor was a technical-report requirements walk-through. Igor is co-supervising the BLE positioning track and he wanted to pin down what the formal deliverable looks like — specifically whether the report should treat BLE as a standalone positioning system or as a calibration signal feeding the CSI pipeline. We settled on the latter framing: BLE provides periodic ground-truth anchors, CSI handles the continuous fine-grained occupancy estimation. That framing is now the stated architecture for EXP-001 through EXP-003.
Maya: So BLE is less 'we use Bluetooth for positioning' and more 'Bluetooth keeps the WiFi sensing honest over time.' That's a subtle but important distinction. Did any tension come up in that meeting about scope?
Theo: Yes, and it's worth naming. Igor pushed on whether EXP-002 — the drift measurement experiment — needs a full re-calibration campaign or just a lightweight RSSI fingerprint check. The honest answer is we don't know yet. The diary note from the sixth flags this as an open design decision: drift timescale is environment-dependent, and we haven't run enough longitudinal data in our target space to know whether weekly BLE sweeps are sufficient or whether we need something more frequent. That's still open.
Maya: And then Thursday the eighth was a double-meeting day — both Igor again and Lukas. That sounds like a heavy afternoon.
Theo: It was. The Thursday Igor session went deeper into architecture — specifically the antenna and NIC selection for the CSI capture side. There's a long-standing constraint in the setup: not every network card exposes CSI at the subcarrier level on Linux. The March network cards analysis diary entry is still the reference document here, and the Thursday meeting confirmed we're committing to the Nexmon-patched Raspberry Pi 4 path rather than Intel 5300 cards, partly because the Pi sniffer notes showed more predictable subcarrier behaviour in our corridor environment. That decision closes a fork that had been open since the Monad Fleet planning entry.
Maya: Interesting that a hardware decision from May 2025 only formally closed in a meeting this week. Does that feel like the research moved slowly, or is that just how embedded systems decisions actually go?
Theo: Honestly, it's the latter — and I think it's worth saying plainly for students listening. Hardware forks stay open until you have enough real-world signal to close them. The Intel 5300 path looked attractive on paper because it has a richer academic literature behind it, but when you're deploying a MonadCount 2.0-style fleet in a real building, maintainability and driver stability matter more than the number of papers citing the card. The Pi path is less exotic but more controllable. That's not a retreat, it's an engineering call.
Maya: That's a really honest framing. Okay, the second Thursday meeting — Lukas and Monad BP. What's that track about?
Theo: Lukas is an MSc student working on the Monad BP project — think of it as a business process layer that sits above the sensing infrastructure. The supervision session covered his current progress and, frankly, some scope alignment. He's been pulled toward a more general occupancy scheduling feature, but the supervision steered him back toward the sensing data pipeline — specifically making sure his output is consumable by the experiment stack rather than a standalone prototype. The action item from that meeting is his: produce a data interface specification by next Friday. That one is on my radar to chase.
Maya: Good — we'll come back to action items in a moment. But first, Friday the tenth: the GAT entry looks like the most technically new thing that landed this week. What is a GAT in this context, for someone who's never heard the term?
Theo: GAT stands for Graph Attention Network — a neural network that operates on graph-structured data, where nodes are locations or sensors and edges are relationships between them, like 'these two rooms share a wall' or 'these two APs overlap in coverage.' The diary entry from the tenth captures the design session where we worked out how the GAT would ingest both CSI subcarrier features and BLE RSSI observations simultaneously, with the indoor topology graph from the PostGIS schema as the structural backbone. It's the model architecture that ties the whole pipeline together.
Maya: And that connects to EXP-006, the co-simulation sandbox. Walk me through what that experiment is actually doing.
Theo: EXP-006 is a synthetic data generation environment: JuPedSim simulates pedestrian trajectories through a floor plan — how many people, where they walk, how they cluster — Sionna then ray-traces the RF propagation through that same environment given those pedestrian positions, and a BLE simulation layer adds RSSI observations consistent with the crowd state. The output is labelled synthetic data: 'here's what CSI and BLE look like when there are twelve people in room three.' That data pre-trains the GAT before we collect any real measurements. The motivation is that real ground-truth collection, which is EXP-001, is expensive and slow. Synthetic pre-training should dramatically reduce how much real data we need to reach usable accuracy.
Maya: That's an elegant strategy. What's the biggest uncertainty sitting inside EXP-006 right now?
Theo: The sim-to-real gap. Sionna's ray tracing is physically grounded but it models walls and furniture as simplified geometry. Real environments have people, chairs, whiteboards, and all of those absorb and scatter RF in ways the simulation doesn't fully capture. The open question — and this is explicitly flagged in the Friday notes — is whether the GAT learns features that are robust enough to transfer, or whether it over-fits to the clean synthetic signal. We won't know until we run EXP-001 real data through a synthetically pre-trained model and measure the accuracy drop. That's the experiment sequence that now anchors the next few months.
Maya: Okay, let's do the action item sweep. What's still open, and what's most overdue?
Theo: Three items at the top of the list. First, Lukas's data interface spec — due next Friday, not yet started as of Thursday's meeting, so that needs a nudge early next week. Second, the drift timescale question from the Igor Tuesday meeting — we need to pull any longitudinal CSI variance data we have from the Pi sniffer logs and make a provisional call on calibration frequency before EXP-003 can be fully designed. Third, and probably most overdue, is finalising the floorplan import into the PostGIS schema for the primary test environment — the April fifteenth diary entry flagged that as 'schema ready, data pending,' and six weeks later the actual building geometry still hasn't been committed. That's the one blocking the most downstream work.
Maya: Six weeks is a long time for a blocker. Is that a resource issue, an access issue, or just one of those tasks that keeps getting bumped?
Theo: Mostly the last one, honestly. The building geometry requires a site visit to verify that the as-built floorplan matches the one we have on file — rooms get subdivided, partitions get moved — and scheduling that has slipped. It's not technically hard, it just requires physical presence and a bit of measurement time. I'd say it's the task most likely to cause a downstream bottleneck if it doesn't happen in the next two weeks, because EXP-004 and EXP-005 both assume a validated multi-room topology exists.
Maya: That's a good thing to name out loud. Alright — stepping back for a moment, and this is the one question I get to ask on Saturdays: how did this week feel? A lot landed.
Theo: It felt productive but slightly fragmented. The reading batches — nine of them across the week — are necessary but they create a context-switching cost. You're in a deep architecture conversation with Igor on Thursday afternoon and then you're trying to read a paper on RF fingerprinting generalization Thursday evening, and those modes don't mix well. The GAT design session on Friday felt like the week finally converging on something concrete. That entry felt good to write. The floorplan blocker is the thing I'd like to resolve first next week, precisely because it's the kind of task that doesn't feel urgent until suddenly it's critical.
Maya: That tension between breadth-of-reading and depth-of-design is something every researcher I've spoken to recognises. Good to name it. So carrying forward into next week — the central open question is whether the synthetic data from EXP-006 will actually transfer to real environments, and everything else sequences around answering that. Tomorrow we shift gears completely: we're looking at the weekly recap and what the synthesis of all those reading batches — ten of them now — actually adds up to as a coherent picture of the field. Should be a good one.
Show notes
Topics covered:
- Technical-report requirements walk-through with Igor
- BLE positioning architecture review with Igor
- Monad BP supervision with Lukas
- 2026-05-10 - GAT for BLE-Calibrated CSI Crowd Sensing
- EXP-006 Synthetic GAT Sandbox
- EXP-001 BLE-Assisted CSI Ground Truth Collection
- EXP-002 CSI Model Drift Measurement Over Time
- EXP-003 Periodic BLE Calibration Campaigns
- EXP-004 Multi-Room Generalization with BLE Transfer
- EXP-005 Hybrid BLE+CSI Occupancy Estimation
- 2026-04-15 - IndoorGML PostGIS Schema and Spatial Foundation
- 2026-05-05 - IP-060 Thesis Drafting Run
- MonadCount 2.0
- CSI
Meetings referenced:
- Technical-report requirements walk-through with Igor
- BLE positioning architecture review with Igor
- Monad BP supervision with Lukas
Open question carried forward: The GAT sandbox in EXP-006 is coupling JuPedSim pedestrian trajectories with Sionna ray-tracing and BLE RSSI — but the ground-truth labels for crowd density haven't been validated against a real deployment yet. How do we establish that the synthetic labels are trustworthy enough to pre-train on before moving to EXP-001 real-world collection?