Innovation Lab
The lab is being built in the open
NEXISTEK has not published a project yet. This page is the standing account of what the lab is for, what it will build, and what every entry will have to contain before it appears here.
- 00 Projects published
- 00 Builds in progress
- 06 Build areas defined
Last reviewed when this page was written. The figures change when something is actually built, not before.
What this is
A working lab, not a portfolio
The Innovation Lab is where the training turns into built things — rigs, boards, control systems and small applications made to be wired, broken, measured and explained. It exists to give the teaching something physical to point at.
NEXISTEK is newly established, so there is nothing built to show. Rather than fill the page with stock projects or borrowed case studies, we have written down what the lab will build and how each project will be documented — so the first real one can be measured against it.
Every project published here will be one we actually built, with the parts that did not work left in.
Build areas
Six areas the lab will work in
These are the disciplines we teach and the kind of build each one produces. They describe intent — not one of them is a project that exists yet.
-
01
Industrial Automation
Control logic, sensors, actuators and the wiring between them — the systems that make a machine repeat a task safely and predictably.
A first build here would look like A bench rig where a PLC drives a short conveyor, with an emergency stop that is tested rather than assumed.
-
02
Monitoring and SCADA
Making a running process legible: data acquisition, dashboards, alarms and the trail someone reads when a process starts to drift.
A first build here would look like A dashboard reading a live sensor, showing the moment a machine goes outside its limits.
-
03
Robotics and Motion
Sensing, control and movement — the loop that turns a reading into motion, and the tuning that keeps that motion stable.
A first build here would look like A small autonomous rover, documented down to why its turn came out wider than planned.
-
04
Embedded and IoT
Microcontrollers, firmware, power budgets and radios: small devices that measure something real and report it somewhere useful.
A first build here would look like A battery-powered sensor node with its current draw measured on a bench supply, not estimated from a datasheet.
-
05
Applied AI
Machine learning pointed at an engineering problem rather than a benchmark — inspection, classification and prediction from real signals.
A first build here would look like A vision check on a moving part, with the cases it gets wrong shown as plainly as the ones it gets right.
-
06
Electronics and PCB
Schematic, layout, fabrication and bring-up — the path from a circuit that works on a breadboard to one that works on a board.
A first build here would look like A small board taken from schematic to assembled hardware, with every revision kept.
How a project runs
Five steps, and none of them skipped
The sequence every project on this page will have been through before it is allowed to appear on it.
-
01
Define the problem
Write down what the build has to do and how we will know it worked — before anything is ordered, wired or written.
-
02
Design it
Choose the approach, the components and the safety limits. Sketch the control logic, the circuit and the ways it can fail.
-
03
Build it
Wire it, program it, assemble it — on the bench, where the mistakes are cheap and worth making.
-
04
Test against the criteria
Run it against the measure set in step one and record what it does, not what it was supposed to do.
-
05
Document and publish
Write it up here: the problem, the stack, the numbers, and everything that failed on the way to the version that worked.
The build log
Nothing published yet
00 entries
The log is empty. When the first project lands it will carry every one of these, and any field we cannot fill will say so rather than be quietly left out.
- The problem it set out to solve
- The approach taken, and what was rejected
- Components, hardware and software stack
- What was measured, with the numbers
- What failed, and what changed because of it
- Who built it, and when