Project
Field Nodes
Small, modular sensing systems designed to extend CapnCoil beyond the vehicle.
Why
The mobile platform is one measurement point in a building.
A vehicle can carry a great deal of sensing, but it can only be in one place at a time. Anything that needs to observe a fixed location — whether a door is being used, what the temperature does overnight, whether equipment is actually running — needs something that can stay.
Field Nodes are an answer to that: small, cheap, self-sufficient sensing hardware placed around a site and left there, feeding the same event system the van already uses.
That reuse is the entire design goal, and it is worth stating plainly: the reason to build this is to feed the existing Perception pipeline rather than to stand up a parallel one. Anything needing its own software, its own dashboard, and its own integration would not be worth building.
What would have to be true
A node is only worth having here if it survives what the mobile platform survives — cold, wet, and unattended — and costs less to deploy than the question it answers is worth. Neither is established.
The honest position: the sensing requirements are understood and the hardware is not designed. Everything below is a list of candidate applications, not a specification.
Candidate applications
What they might eventually measure.
None of these are built. They are the measurements that seem worth making, listed so the idea can be judged on whether it is worth building at all.
Door counting
Motion detection
Environmental monitoring
Temperature
Humidity
Vibration
Occupancy
Equipment monitoring
Remote sensing
Experimental instrumentation
Constraints
Why this is harder than it sounds.
A node left somewhere for months has to survive on a battery, through winter, without anyone visiting it. That constraint decides almost everything else: how it communicates, how often it samples, what it is allowed to assume, and whether it can still be trusted after sitting unattended long enough to drift.
The mobile platform solves this with a person. A node has to solve it with a power budget.
Open questions
- How long does a node survive between services at -30°C?
- What does it do when connectivity is intermittent for weeks?
- How is drift detected when nobody is there to notice it?
- Does a node need to be trustworthy enough to act on, or only to record?
- Is this viable at a per-node cost that beats the alternative?
None of these are answered. They are written down so the concept is evaluated rather than assumed.
How it would fit
Nodes, then the same event stream.
If this is ever built, the value is in the reuse: a node feeds the existing perception and event system rather than becoming a system of its own. The diagram below is the intent, not an implementation.
-
Stage 1 of 5: Fixed location
A place that needs watching after the mobile platform has driven away.
-
Stage 2 of 5: Field node
Self-sufficient sensing hardware on a power budget, not a mains budget. Concept only.
-
Stage 3 of 5: Communications
Getting an event out of a place with intermittent connectivity. Not designed.
-
Stage 4 of 5: Perception and events
The existing pipeline and event stream a node would feed into. Built.
-
Stage 5 of 5: Operator and storage
Where those events are read and kept. Built.
Still a concept
Have something this could measure?
If you have a sensing problem that has to keep running in a fixed place, that is worth a conversation even though the hardware does not exist — the requirements are what would drive the design.