Board review: the depth-to-haptic-matrix specification

A section-by-section review of the founder's submission, "Technical Specification and Architectural Framework for Real-Time Spatial Depth to Tactile Haptic Matrix Conversion Systems". The submission is published beside this review, unedited. The board adopted what stands, amended what almost stands, and declined what the evidence contradicts, with a reason and a source every time.

House rules kept: short plain sentences, no long dashes, every number has a source, and the build is described as in development. Where a seat disagreed, the record says so in that seat's own words and says how it was settled. Where the review touches a Council decision, it names it; D1 to D12 are the twelve decisions in the Council's record. Where the review leans on the placement evidence, it cites the full-body haptic map.

A word to the founder before the verdicts. This is a serious piece of engineering. The circuit sections would pass review at most hardware companies with one correction, the firmware section is right in every register it names, and the power section describes the rails the kit should have had written down already. The board declines two things: the headline latency number, and the idea that a dense matrix driven from a phone should be the channel a person walks by. The rest enters TEK, some of it as written and some with changes, and several parts of the current design change to match the submission.

Who sat

1. The embedded and power electronics engineer, who has shipped a Class I medical device. Sections 2, 3 and most of 6 are this seat's.
2. The haptics psychophysicist, who measures what skin feels. Section 4 and every question about motors and skin are this seat's.
3. The real-time systems engineer, who does the timing arithmetic and the bus budgets. Sections 1, 5 and the concurrency half of 6 lean on this seat.
4. The Chair of the Council of Four, an orientation and mobility master instructor, who keeps this review consistent with the Council's twelve decisions and holds the pen.

The verdict in one paragraph

Six of the eight sections enter TEK with amendments and two are declined. Of 55 concrete claims the board could test, 27 stand as written, 17 stand with an amendment, and 11 fall. What falls is concentrated in three places. First, "under 30 milliseconds glass to vibration" cannot be true of the chain described; summed honestly from the camera's frame period, the USB transfer, the phone's processing and scheduling, the link to the microcontroller, the 50 Hz loop and the coin motor's own spin-up, the chain is about 110 to 220 milliseconds to half amplitude, against the Council's modeled 70 milliseconds for the kit's laser grid path with a resonant motor (D1). Second, the phone and its camera sit inside the warning path, which the founder's own binding words to the Council forbid ("the wearer's phone as an optional camera, never in the safety loop") and which the kit's four tiers of trust place above the isolation boundary. Third, dense actuator matrices as the channel a person walks by run against the strongest placement evidence the project has: eight motors around the waist are localized 98 percent of the time and twelve only 74 percent; one head motor is counted correctly 94 percent of the time and five motors 5 percent; and people cannot count more than two or three vibrations at once anywhere on the body (D6, D12). What stands is most of the electronics: the dual rail with a star ground, the low-side switch with its flyback diode and pull-down, the decoupling, the hardware output-enable kill (with its pull direction reversed so that it fails safe), the register sequence and block writes for the PCA9685, the two-core firmware split, minimum depth pooling for the ground grid, and USB-C power pass-through for the phone mount. The same pipeline the board declines as a safety channel it adopts, re-homed above the boundary, as an exploration mode for standing still and for the hand-scanning glove, in development and off while walking.

Scorecard

How to read the verdicts

ADOPT means it enters TEK as written. ADOPT WITH AMENDMENTS means it enters TEK with the listed changes. DECLINE means it does not enter TEK, with reasons and sources; where the founder's own words or a Council decision are involved the record says so, and where the evidence is not overwhelming the final call is marked "founder's call".

1. Architecture and the six tiers

Verdict: DECLINE as the kit's safety architecture. ADOPT the same pipeline as an exploration mode above the isolation boundary.

What the section says. A USB camera (UVC, the standard webcam protocol) or a depth camera streams frames at up to 60 per second into an Android phone. The phone crops, pools, filters and maps depth to intensity. It sends a matrix to an ESP32 running FreeRTOS, which drives chained PCA9685 boards over I2C (the two-wire control bus) at 50 Hz, and each PCA9685 output switches a coin motor through a transistor. The whole chain is claimed to run under 30 milliseconds from glass to vibration.

The latency claim, accounted honestly. The real-time systems engineer's ledger. Every number is from a datasheet or a published measurement; the ranges are best, typical and worst.

So the chain as described is about 110 to 220 ms to half amplitude, with a typical value near 160 ms. The Council's modeled figure for the kit's own path is about 65 to 75 ms in 4x4 mode to full amplitude: a 17 ms frame, 3 to 7 ms of trimmed readout, under 1 ms of compute, 0.7 ms of driver start, and a resonant motor that moves after 11 ms and reaches full amplitude at 37 ms (UM3109, table 2; DRV2605L datasheet; C10-100 datasheet; D1). At the default walking pace of 1.4 m/s, 160 ms is about 22 cm of travel; 70 ms is about 10 cm.

There is a reading of "under 30 ms" that is true. The ESP32's own share, from a parsed frame to the last I2C byte, is under 1 ms of parsing, at most 20 ms of waiting for the tick, and 1.5 ms of bus time: under 23 ms worst case. If that is what the founder meant, the board agrees, and asks that it be labeled the way the Council labels the kit's controller share: "the controller adds under 5 ms of its own" became the public sentence because the whole chain is what a wearer feels (D1). Question 1 to the founder asks this.

The bandwidth claim. The submission names 4K sensors at 60 frames per second on a USB 2.0 High-Speed link of 480 Mbit/s. Uncompressed 1080p at 60 frames per second in the common YUY2 format needs about 1 Gbit/s; 4K needs four times that. Every USB 2.0 camera that claims 4K sends compressed MJPEG, and decoding MJPEG is exactly the CPU work that adds the Android milliseconds above (USB bandwidth explainer). Android's own external camera support says it "is not designed to support performance-intensive, complex tasks involving high-resolution and high-speed streaming" (Android Open Source Project, external USB cameras). A depth camera at 640 by 480 or lower fits USB 2.0 and is the honest version of this tier.

The phone inside the warning path. The Chair. The founder's words that bound the Council were "the wearer's phone as an optional camera, never in the safety loop." Section 1 puts the phone's USB port, its operating system and its battery in series with every buzz. The board does not read this as a change of mind; it reads it as a specification written for a different device, a research rig, and asks (question 3). The kit's rule stands: the distance sensors carry the warning, the phone may add a buzz and never milestones one (haptic map, section 9; sensors section of the site). The board adds one clarification the founder is owed: structured-light and time-of-flight depth cameras are direct distance sensing, by timing light or by triangulating a projected pattern, not by recognizing what things are; a time-of-flight camera is the same physics as the kit's laser grid. Nothing in the objection is about "AI". The objection is latency, an operating system without timing guarantees, a thermal and power coupling through one USB port, and the isolation boundary in the kit's own architecture, which puts anything on a phone or a Linux box above the line and anything that can cause a buzz below it (kit dossier, section 6).

Dense matrices as the walking channel. The haptics psychophysicist. The section scales from 16 to 992 channels and speaks of "high-density physical actuator arrays". The published evidence runs the other way for a person who is walking. Around the waist, eight motors 107 mm apart are localized 98 percent of the time; twelve motors 72 mm apart drop to 74 percent (Cholewiak, Brill and Schwab, quoted with the numbers in the haptic map, section 1). Around the head, one active motor is counted correctly 94 percent of the time, two motors 40 percent, five motors 5 percent (Dobrzynski et al.). Across the hand, three sites are told apart 97 percent of the time and five sites 71 percent (IEEE Transactions on Haptics). Counting simultaneous vibrations anywhere on the body passes 30 percent error at three and reaches chance at four (Gallace, Tan and Spence). And people react more slowly when a buzz can come from any of several sites than when they know where to attend (Karuei et al.). The Council built the kit on those numbers: at most two regions at once, a 100 ms stagger, a fixed injury-ranked order (D6), three distance bands (D12), few signals at well-chosen sites. A 64-cell depth image on the chest while walking is 64 sites competing for a channel that resolves two.

Where a matrix is right. Three places, and the board means this as an adoption, not a consolation.

1. The hand-scanning glove (D10). The hand is the one place the evidence allows more than one site per lane, and the glove already carries three motors across the palm: the belt's left, center, right logic shrunk to the hand. A 3 by 3 palm grid is localized 91 percent of the time (palm vibration study), so a 3 by 3 is the ceiling if the founder wants to reopen the count. Founder's call.
2. A chest "depth image" for exploration when standing still. Dense arrays have a real history when the person sits still and trains: a 400-point array on the back let trained users recognize objects after hours of practice (Bach-y-Rita et al., vision substitution by tactile image projection). Nobody has read one while walking. As a mode the wearer switches on when stopped, driven from the phone, above the boundary, with the pod's inertial sensor turning it off the moment the wearer moves through space (the same rule D7 uses for training mode), the founder's pipeline is exactly the right tool. The psychophysicist's reservation is recorded below.
3. Bench research. The rig in section 1 is a good instrument for measuring what skin can read from a matrix. It should be built and used as one.

Where a matrix is wrong: the walking safety channel, for the reasons above and by D6 and D12.

Dissent. The haptics psychophysicist: "Even standing still, pattern reading on the trunk is poor, and the back array took hours of training in a laboratory. I would not promise the wearer a picture. I would promise a scan: sweep the phone, feel the nearest thing in each cell, and learn to read a doorway." The real-time systems engineer: "Above the boundary it can do no harm, so let it be tried." The Chair: "Taught after mobility aid skills, seated, indoors, like the glove, and never the default. On those terms it goes on the roadmap as in development." Settled on the Chair's terms.

What changes in TEK if adopted. The roadmap gains an exploration mode, "a depth image you read when you stop", in development, above the boundary, phone-driven, off while walking. Its pipeline is the founder's: crop, minimum pooling, temporal median, inverted transfer. Owners: firmware for the mode flag and the inertial milestone, site for the honest wording, bench for the readability study.

2. Circuits and interconnects

Verdict: ADOPT WITH AMENDMENTS.

The embedded and power electronics engineer. This section is the strongest in the submission. Each claim was checked against the datasheets.

What stands as written.

• Hardware I2C on the ESP32's default pins, GPIO21 for data and GPIO22 for clock. Correct for the classic ESP32.
• 4.7 kΩ metal-film pull-ups to the 3.3 V rail for 400 kHz on a short bus. Correct; the I2C specification allows 400 pF per line and 4.7 kΩ suits a board-sized bus well under that (NXP UM10204).
• The PCA9685 runs from 2.3 V to 5.5 V and its inputs and outputs are 5.5 V tolerant, so with its logic supply at 3.3 V no level shifter is needed (PCA9685 datasheet).
• The PCA9685 cannot drive a motor. Its outputs sink 25 mA and source 10 mA per channel with 400 mA for the whole package, and the coin motor in the founder's table draws 80 mA running and 180 mA at start (same datasheet; the 10 mm coin motor the board checked draws 58 mA rated and 106 mA typical at start, 310-103 datasheet). An external switch per channel is mandatory. Correct.
• The low-side switch cell: a series base or milestone resistor, a pull-down to ground so the switch is off through reset, a flyback diode across the motor so the coil's stored energy has somewhere to go when the switch opens, a bulk electrolytic on the motor rail and a ceramic near each branch. This is the textbook cell and it is right. The BC337 (45 V, 800 mA) and 1N4001 (50 V, 1 A) values in the table are correct.

Amendments.

1. The output-enable pull is inverted for safety. The PCA9685's OE pin is active low: low enables the outputs, high forces them to the state set by the OUTNE bits in MODE2 (PCA9685 datasheet, section 7.4). The submission pulls OE low through a resistor and calls it an instant shutdown for faults and boot. Pulled low, the outputs are enabled the moment power arrives, before the ESP32 has booted, and stay enabled if the ESP32 hangs. For a kill line to fail safe it must pull the other way: OE to 3.3 V through 10 kΩ, so the outputs are off until the controller actively drives OE low, and OUTNE set to 00 so that "off" means logic 0 at every output rather than a floating pin. The per-channel pull-down on each transistor base already protects the boot moment; the OE default should agree with it. Better still, drive OE from a hardware watchdog output, so a hung phone or a hung ESP32 silences every motor within the Council's 250 ms (D8). This is the one change the Class I seat would not sign without.
2. The MOSFET is the default switch, not the BC337. With a 1 kΩ base resistor and 3.3 V logic the base current is about 2.6 mA. At 80 mA of collector current that is a forced gain near 30, which is not hard saturation; the transistor runs warm and drops a few hundred millivolts the motor never sees. The AO3400 at a 3.3 V milestone has an on-resistance of tens of milliohms and drops almost nothing. Keep the BC337 as the fallback where a MOSFET is not to hand.
3. Prefer the Schottky. The 1N4001 is a slow rectifier. At a 200 Hz chop it is adequate; the 1N5819 Schottky in the founder's own text is the better default at any switching rate.
4. 62 boards is an address count, not a bus budget. Six address pins allow 62 devices (datasheet). A 16-channel block write is 66 bytes at 9 clocks each, about 1.5 ms at 400 kHz. A 20 ms period fits 13 boards, 208 channels; at 100 Hz it fits six. At 1 MHz Fast-mode Plus the bus fits 33 boards, but the ESP32's documented I2C ceiling is 400 kHz (ESP-IDF I2C reference), and Fast-mode Plus needs about 1 kΩ pull-ups and Fm+ drivers on every device on the wire. So "16 to 992 channels" should read "16 to about 200 channels at 50 Hz on one 400 kHz bus", which is still ten times more than the kit will ever fire. The Council caps channels per band for other reasons (D8).
5. Inrush is a scheduling problem before it is a capacitor problem. Sixteen motors starting together draw about 2.9 A for a few tens of milliseconds (16 times 180 mA). The kit never does this while walking: the scheduler renders at most two regions and never starts two within 100 ms (D6). The only moments many motors start together are the roll call and the run profile's all-zones stop (D7, D11); ramp those in firmware over a few milliseconds per motor and the inrush sum disappears at its root.

What changes in TEK. The low-side cell (AO3400, 1 kΩ milestone resistor, 10 kΩ pull-down, Schottky across the motor, 0.1 µF at the branch, bulk capacitance per band) becomes the reference drive for the coin ERM in the G0b bench set, and the reference for any ERM that later earns a place in a puck. A hardware "outputs off" line on every driver, pulled to off by default and driven on only while a watchdog is fed, enters the band controller specification; on the DRV2605L that line is EN, on the PCA9685 it is OE. Owners: hardware, firmware.

3. Power, the star ground, and USB-C pass-through

Verdict: ADOPT WITH AMENDMENTS.

The embedded and power electronics engineer.

What stands as written.

• The failure mechanism. Motors starting on the same rail as the controller pull the rail down, the ESP32's brownout detector resets it, the PCA9685 loses its registers, and a USB link on the same rail drops. That is a correct description of the most common failure in student haptic builds, including, the founder will recognize, the first generation.
• Two rails. A 3.3 V logic rail from a low-dropout regulator for the ESP32, the pull-ups and the PCA9685 logic; a 5 V actuator rail from a supply rated for the inrush sum, straight to the motor switches, never through the controller's regulator. The table's 3 A class supply matches the 2.9 A inrush arithmetic.
• A single-point star ground: digital ground and motor ground joined only at the supply input. Correct, and it belongs in the PCB rules for the band controller and the hub.
• A 470 µF low-ESR electrolytic across the actuator rail with 0.1 µF ceramics per branch. A good starting value; the bench sizes it by looking at the rail on a scope during the roll call.
• "Standard OTG places the phone in host mode and makes it supply power." Correct: with a plain On-The-Go adapter the phone is the source and its battery runs the camera.
• Data lines routed straight from the camera to the phone as a 480 Mbit/s USB 2.0 High-Speed link. Correct, and the reason the depth camera must be a 640 by 480 class device (section 1).

Amendments.

1. The charge-while-host mechanism is a power role swap, and many phones refuse it. On USB-C, a device that wants to be powered exposes 5.1 kΩ pull-downs (Rd) on its CC pins; a device that offers power exposes pull-ups (Rp) (Benson Leung on the configuration channel; ST AN5225). If the splitter shows the phone Rd, the phone becomes the data host and the power source, and its battery drains. To charge the phone while it stays host, a Power Delivery controller must run a Power Role Swap, or present Rp and then run a Data Role Swap (Renesas, USB Type-C and role swap). These are Power Delivery control messages, not Vendor Defined Messages; VDMs carry alternate modes and proprietary schemes. The named scheme in the founder's references, SimulCharge, is one vendor's proprietary method for particular Samsung models with a custom cable (LAVA SimulCharge). Whether a given phone accepts a role swap while it is the USB host depends on that phone's policy engine; flagship phones mostly do, many mid-range phones do not (Infineon community thread on charging a tablet in host mode). The kit's community carries Androids, many of them mid-range (the Council's Android-first note). So: adopt USB-C Power Delivery pass-through for the phone mount as an option, checked at fitting, and design so that nothing in the kit depends on it. The phone runs the exploration mode on its own battery if its port cannot swap.
2. Nothing on the kit's rails ever comes from the phone, and nothing on the phone ever powers a warning. The kit's certified bank, the coulomb counter, the keep-alive floor, the eFuse per branch and the separate regulators for the reflex domain and the radio stay exactly as D8 wrote them. The founder's two rails sit inside that scheme: they are the band-level rails D8 asked for, now with the ground rule written down.
3. Drop the trademark. The section should say "USB-C Power Delivery pass-through with a power role swap", not "SimulCharge", which names one company's product.

What changes in TEK. The band controller and hub PCB rules gain the founder's text almost verbatim: a separate logic LDO, a motor rail that bypasses it, one star point, bulk capacitance sized on the bench. The phone mount in development gains an optional PD pass-through with a role-swap-capable controller and a one-line fitting check, "does your phone charge while the camera is plugged in". Owners: hardware, site.

4. Psychophysics and spacing

Verdict: ADOPT WITH AMENDMENTS.

The haptics psychophysicist.

What stands as written.

• The four classes of skin receptor and their bands are textbook and broadly right. The Pacinian channel is most sensitive near 250 Hz and covers roughly 40 to 400 Hz; the rapidly adapting Meissner channel carries flutter in the tens of hertz; the slowly adapting channels carry pressure and stretch (Bolanowski et al., four channels mediate the mechanical aspects of touch; Verrillo on the Pacinian frequency response).
• The two-point thresholds, read as the standard values: fingertip 2 to 3 mm, forearm 35 to 40 mm, back and torso about 40 mm (Weinstein, summarized; the haptic map's table carries every site).
• Wider spacing for vests than for arm bands. Right in direction.

Amendments.

1. Two-point pressure thresholds are the wrong yardstick for vibration. Vibration spreads through skin as a surface wave and is localized by landmarks, not by receptor spacing. Trunk skin tells two vibration points apart at 30 mm with 91 percent accuracy and at 13 mm with 64 percent (Johannesson et al.); around the waist, localization depends on the navel and the spine far more than on distance (Cholewiak, Brill and Schwab). On the forearm, "at least 40 mm" is too close: two simultaneous vibrations are best told apart at about 90 mm and 80 mm avoids interference (Sofia and Jones; arm propagation study), which is why the map puts one motor per limb site. And spacing is necessary but not sufficient: an array where every pair is distinguishable is still unreadable if more than two cells fire at once (Gallace, Tan and Spence). The binding limit on array geometry is how many cells are active together, not how far apart they sit.
2. The 200 Hz PWM argument does not hold for an ERM. An eccentric rotating mass motor spins an off-center weight. Its vibration frequency is its rotation rate, and its rotation rate is set by the average voltage across it. PWM (switching the supply on and off fast so the average sets the speed) changes that average; the PWM rate itself is not the vibration rate. Frequency and amplitude are locked together by the physics, force equals mass times radius times speed squared, so neither can be set on its own (Precision Microdrives AB-004; AB-029). The founder's intuition has a true kernel: a 3 V coin motor at rated voltage spins at 12,000 rpm, which is 200 Hz, inside the Pacinian band (310-101 datasheet). But turn the duty down to make it gentler and the frequency falls with the amplitude; turn it below the start voltage and it stops. The 200 Hz chop of the supply current adds a faint hum and a torque ripple, not the felt vibration. For a linear resonant actuator (LRA, a motor that vibrates at one fixed resonant frequency) the Pacinian argument does hold: a 175 Hz or 235 Hz LRA driven at resonance speaks to that channel at every amplitude. That drive needs an H-bridge at the resonant frequency with resonance tracking, which the PCA9685 cannot do and the DRV2605L does (DRV2605L datasheet, auto-resonance engine). The ERM's PWM rate is an engineering choice about ripple and audible noise; the bench should listen to the puck at 200 Hz and at the PCA9685's ceiling of 1526 Hz and pick by ear.
3. "Align everything with the Pacinian peak" is the wrong rule for the ground channel. The Pacinian channel is exactly what age, cold skin and diabetic neuropathy attack: thresholds at 250 Hz rise steeply with Pacinian loss, and cold skin is nearly deaf at 150 to 250 Hz and barely changed at 30 Hz (D2 and its sources). That is why the Council's bench set carries a low-frequency element for the ankles beside the 175 Hz part (D2, D8). The trunk may live at 175 to 250 Hz; the ground channel must be able to speak flutter.
4. Stevens' power law does not give linear scaling, and 12 bits of duty buys nothing the skin can use. The exponent for vibration changes with frequency: about 0.95 at 60 Hz and about 0.6 at 250 Hz (Stevens, tactile vibration, change of exponent with frequency). At the Pacinian peak the compression is strong, and an ERM's amplitude rises with the square of its speed, so duty to sensation is not a straight line at any frequency. More to the point, people identify only about 1.76 bits of vibration intensity, three to four levels (Tan). The Council chose three distance bands with hysteresis, rhythm as the primary cue and intensity as the redundant one (D12). Keep the 12-bit resolution for per-puck calibration floors and gains; quantize what the wearer feels to three steps.

Dissent. None among the seats. The Chair records that the founder's motor choice, an ERM, is a choice the Council explicitly left to the G0b bench: a 175 Hz LRA, a 235 Hz LRA, a 12 mm LRA, a coin ERM and a low-frequency element, each in the same puck, measured on the skin side through a shirt while marching (D8). The founder's drive cell in section 2 is what makes the ERM candidate testable on that bench, so the ERM stays in the set, and the bench decides. Two facts weigh against it before the bench: the coin ERM the board checked takes 115 ms to stop on its own and 45 ms with active braking, which a low-side switch cannot provide, and the ankle sweep (120 ms bursts, 80 ms onset gaps) smears into one long buzz on a motor that starts in 40 ms and stops in 115 (310-103 datasheet; haptic map, open question 8). The LRA is no free lunch: the C10-100 stops in 177 ms without braking, which is why the kit's driver brakes (C10-100 datasheet).

What changes in TEK. The map's section 1 gains one sentence the founder's section earns: the receptor bands in plain words, so that "flutter for the ankles, hum for the trunk" has its physiology written down. Owners: site.

5. Pooling, the median, and the transfer function

Verdict: ADOPT WITH AMENDMENTS.

The real-time systems engineer, with the haptics psychophysicist on the last part.

Minimum depth pooling. ADOPT. Each actuator cell takes the nearest reading inside its patch of the depth frame, not the average, so a pole or a hanging branch that fills one pixel is not averaged away. This is right, and it is likely right for the kit's own sensors too. The down-tilted 8 by 8 laser grid must turn 64 zones into "left, center, right, and the ground", and the nearest valid zone in each lane is the honest reducer. Two guards: milestone each zone by its target status before pooling, because a single bad zone reading "near" makes a phantom hazard out of a minimum (the VL53L8CX reports a status per zone, UM3109); and on a camera depth frame, which has far more pixels and more dropouts, take a low percentile or erode single pixels before the minimum.

The 3-frame temporal median. ADOPT WITH AN HONEST COST. Taking the middle of the last three readings removes a one-frame flicker. It also delays every real change by one frame: a new value must appear in two of three frames before the median follows it. At 60 frames per second that is 17 ms; at the ground grid's 15 Hz it is 67 ms; at a 30 frame per second depth camera it is 33 ms. "Without adding noticeable phase delay" is true for a flicker and false for a step. The Council's fusion rule, two frames to turn on and four to turn off (D12), pays a similar price for the same reason. The bench should run the two side by side on the ground grid and write the winner's cost into the one latency config the site reads (D1).

The inverted transfer function. ADOPT THE SHAPE, QUANTIZE THE OUTPUT. Closer is stronger; a hazard distance maps to the maximum; an outer boundary maps to the minimum active drive; a gamma shapes the curve. That is the kit's second law, "how strong is how close", and the site's own code today is a straight ramp from zero at the range edge to full at contact. The Council changed both to three bands with hysteresis (D12), and the founder's formula needs the same change: the hazard threshold and the outer boundary become the near and far band edges, a middle edge is added, gamma stays a bench parameter for the exploration mode only. One more practical floor: an ERM below its start voltage does not turn, so the minimum active duty is set by the datasheet's start voltage, not by preference; for a 3 V motor with a 2.3 V start on a 5 V rail the usable window is roughly 46 to 60 percent duty, a narrow band that 12 bits cannot widen (310-101 datasheet).

What changes in TEK. Minimum pooling gated by target status becomes the lane reducer for both laser grids. The median goes on the bench against the two-on, four-off rule. The site's ramp and the founder's formula both become three bands. Owners: firmware, bench, site.

6. Firmware and registers

Verdict: ADOPT WITH AMENDMENTS.

The embedded engineer checked every register; the real-time systems engineer took the concurrency.

What stands as written, and it is a lot.

• The prescaler. The PCA9685 runs a 25 MHz oscillator; the prescale value is round(25 MHz / (4096 × f)) minus 1; for 200 Hz that is 30, written as 0x1E, which is also the chip's power-on default; the hardware forces a minimum of 3, giving 1526 Hz, and 0xFF gives 24 Hz (PCA9685 datasheet, section 7.3.5). The actual rate at prescale 30 is 25 MHz / (4096 × 31), about 197 Hz.
• The MODE1 sequence. Writes to PRE_SCALE are blocked unless SLEEP is set; after clearing SLEEP the oscillator needs up to 500 µs; RESTART must not be written until SLEEP has been clear for 500 µs; auto-increment is bit 5. Every step in the submission matches the datasheet's own procedure, and the placeholder delay is 500 µs (the common library waits 5 ms, which is fine).
• Auto-increment block writes. Sixteen channels, four registers each, ON set to zero and OFF holding the 12-bit count, one 64-byte transaction: about 1.5 ms at 400 kHz. Correct, and adopted as the way any I2C driver in the kit is configured.
• Core 0 for communication and parsing, core 1 for the deterministic loop, a double-buffered queue between them, checksums on the wire. ESP-IDF's FreeRTOS gives 25 priority levels, so priority 24 is the top (ESP-IDF FreeRTOS). The design matches the Council's own two-controller split and the tiny link protocol in the hardware panel's idea 18: a fixed tick, age stamps, static memory.
• The register table. Every address and bitmask is correct. One addition below on OUTNE.

Amendments.

1. 100 Hz, not 50. A 20 ms period puts up to 20 ms of waiting in front of every frame before a single byte moves. The Council's reflex loop ticks at 100 Hz with age stamps and a 250 ms watchdog (D8). At 100 Hz one 400 kHz bus still fits six PCA9685 boards, 96 channels, more than the kit will ever carry on one band.
2. The hard loop belongs on a controller with no radio. The ESP32 as described runs Wi-Fi or Bluetooth on core 0 and the deterministic loop on core 1. Sharing a die, a power domain and a heap between a radio stack and a warning loop is a weaker isolation than the kit's architecture requires: the reflex controller has no radio at all, the radio lives on the logging controller, and the two sit in separate power domains (D8, D10, the hardware panel's idea 24). As described, the founder's ESP32 is a spine or a bench controller, and a good one. Its two-core split is adopted for the kit's ESP32-S3 spine: comms on core 0, logging and the link on core 1.
3. Frame age and a dead-man rule. When frames stop arriving from above the boundary, the matrix must decay to zero within the watchdog period, and OE must go high from a hardware watchdog, not from software that may itself have hung.
4. OUTNE = 00, and totem pole for a milestone. With OE high the outputs must be driven low, not left floating, so that a motor cannot be held on through a floating milestone. MODE2's OUTDRV = 1 (totem pole) is the right choice for a MOSFET milestone because the active pull-up gives clean edges.
5. No heap in the loop, and bus recovery. Static buffers, per-segment bus error counters and the nine-clock bus clear, as the Council wrote for the reflex firmware (D8).

What changes in TEK. The PCA9685 init sequence and block write become the reference code for the ERM bench board. The spine's firmware adopts the core split. The band controller specification gains the frame-age decay and the hardware watchdog on the enable line. Owners: firmware, bench.

7. The performance table

Verdict: ADOPT WITH AMENDMENTS.

The Chair. The table is a fair summary sheet of the submission's design values, and the board keeps it as one. Its middle column is headed "Measured Metric", and nothing in it was measured. The Council's first decision made this the rule for every number the project publishes: modeled until the bench measures it, then measured, in one place, from one config file (D1). The column becomes "Design value, modeled". Three rows change and four are added.

• "Drive frequency 200 Hz, matches Pacinian frequency peak" becomes "PWM rate 197 Hz (prescale 30); sets the supply chop, not the felt frequency on an ERM" (section 4).
• "Camera stream" gains its honest limits: 640 by 480 class depth over USB 2.0, compressed above that.
• "Tactile resolution, array spacing" gains "and at most two cells active at once while walking" (D6).
• Added: world to skin, about 110 to 220 ms to half amplitude for the pipeline as drawn, modeled (section 1).
• Added: bus budget, one PCA9685 block write 1.5 ms at 400 kHz, 13 boards per 20 ms period, 6 per 10 ms.
• Added: motor timing, ERM lag 40 ms, rise 87 ms, stop 115 ms, brake 45 ms; LRA lag 11 ms, rise 37 ms, stop 177 ms unbraked.
• Added: the kill line, OE pulled high by default, driven low by a watchdog-fed pin.

What changes in TEK. Nothing on the site; the site's latency strip already reads the one config (D1). Owners: none beyond the amended sheet itself.

8. Synthesis and outlook

Verdict: DECLINE.

The synthesis restates sections 2, 3 and 6, which the board adopts, and inherits the Pacinian error from section 4. The board's decline is aimed at the outlook: "scaling matrix densities beyond [the present] arrays to high-resolution wearable tactile grids" over SPI or CAN-FD with compression, "to preserve real-time responsiveness for spatial awareness and non-visual navigation".

Why. Every study the project holds on localization says that adding motors to a walking display subtracts information: 8 to 12 around the waist drops localization from 98 to 74 percent; 1 to 5 around the head drops counting from 94 to 5 percent; three to five sites on the hand drops from 97 to 71 percent; simultaneous vibrations anywhere reach chance at four (Cholewiak, Brill and Schwab; Dobrzynski et al.; IEEE Transactions on Haptics; Gallace, Tan and Spence). Spreading a display across more sites slows reaction (Karuei et al.). The map's rule for any new zone is that it must sit where the body would be hit or where a hand reaches, and the skin there must read vibration while the wearer is moving (haptic map, section 12). A denser grid fails the second test by construction. The bus problem the outlook wants to solve with SPI and CAN-FD is a problem only a dense grid has.

Where the outlook is right. As a bench research line, "what can skin read from a matrix when the person stands still", with the founder's rig as the instrument (section 1). And the founder is right that a faster, wider bus belongs in the kit: the Council already moved the laser grids to SPI or 1 MHz I2C on the hub, and put a serial link to each band, for the sensors' sake (D8, hardware panel idea 14).

Founder's call. The Council's decisions rest on the founder's own words, "vibration across the whole body, placed by evidence". The evidence here is as strong as any the project has, and the board says so plainly. Whether Third Eye Worldwide also funds a research line into dense tactile displays for exploration is his to decide, and nothing in this review argues against it as research.

What enters TEK now

Concrete adoptions, with the owner who acts.

Hardware.

• The low-side drive cell: AO3400 (BC337 as fallback), 1 kΩ milestone resistor, 10 kΩ pull-down, 1N5819 Schottky across the motor, 0.1 µF at each branch, bulk electrolytic per band sized on the bench. Reference drive for the coin ERM in the G0b set and for any ERM that later earns a puck (sections 2, 4).
• A hardware "outputs off" line on every driver, pulled to off by default, driven on only while a watchdog is fed: OE on the PCA9685, EN on the DRV2605L. Enters the band controller specification (sections 2, 6).
• Two rails and one ground point: a logic LDO, a motor rail that bypasses it, digital and motor grounds joined only at the supply input. Enters the band controller and hub PCB rules under D8's existing regulator-per-band and eFuse-per-branch lines (section 3).
• USB-C Power Delivery pass-through with a role-swap-capable controller as an option on the phone mount in development, with a fitting check; nothing in the kit depends on it (section 3).

Firmware.

• Minimum depth pooling gated by per-zone target status as the lane reducer for both laser grids (section 5).
• The 3-frame median as a bench alternative to the two-on, four-off rule on the ground grid, the winner's delay written to the latency config (section 5).
• Three distance bands with hysteresis in place of the continuous ramp, in the reflex firmware and in the site's haptics.ts; the founder's hazard and boundary distances become the near and far band edges (section 5, D12).
• PCA9685 init sequence and auto-increment block writes as the reference for configuring any I2C driver at boot; I2C at boot only, PWM in the loop (section 6, D8).
• The two-core split for the ESP32-S3 spine: comms on core 0, logging and the link on core 1. The reflex loop stays on a controller with no radio, ticking at 100 Hz (section 6, D8).
• Frame-age decay to zero and a hardware watchdog on the enable line (section 6).
• An exploration mode flag, "depth image when stopped", gated off by the pod's inertial sensor the moment the wearer moves through space (section 1, in development).

Site.

• The founder's submission and this review published under research, linked to each other.
• The map's section 1 gains one plain-words sentence on receptor bands: flutter for the ankles, hum for the trunk (section 4).
• The roadmap names the exploration mode as in development, above the boundary, phone-driven, off while walking (section 1).
• No change to the sensors section's phone wording or to the honest limits panel; both already say what this review says.

Bench.

• G0b gains a row: the coin ERM under the founder's low-side cell against the same ERM under the DRV2605L's open-loop drive with overdrive and braking, rise and stop measured on the skin side (sections 2, 4).
• Listen to the ERM puck at 197 Hz and at 1526 Hz PWM; pick by ear (section 4).
• The median against two-on, four-off on the ground grid (section 5).
• The readability of a chest matrix when standing still, with the founder's rig as the instrument (sections 1, 8).

Reconstructed values

The paste lost values and formulas, shown as . What the board read each as, and how sure it is.

Not recoverable: the depth frame resolution, the exact matrix size in the worked example, the two distances d_min and d_max, the minimum active duty, the Stevens exponent the founder used, the exact two-point numbers he wrote, the base resistor and pull-down values, and the target grid sizes in the outlook. Question 7 and question 2 ask for the two that matter most.

Questions for the founder

Eight, each answerable by voice in one sentence.

1. Is "under 30 milliseconds" the ESP32's own share, from a parsed frame to the last I2C byte, or the whole chain from light on the camera to vibration on the skin?
2. Which depth camera do you have in hand or in mind, and does it output depth at 640 by 480 or lower over USB 2.0?
3. Is the matrix meant to be read while walking, or when you stop and face something to explore it?
4. Should the first board's 16 channels drive the kit's own eight belt pucks and four collar pucks, or a separate chest patch for the exploration mode?
5. Which phone do you carry day to day, so the bench can test whether it accepts a power role swap while it stays the USB host?
6. Do you accept 100 Hz for the control tick in place of 50 Hz, and a hardware watchdog on the output-enable line?
7. The coin motor in your table: do you have a part number and a datasheet, or should the bench use the 10 mm coin ERM already in the G0b set?
8. If the G0b bench shows the coin ERM cannot run the ankle sweep because it starts in 40 ms and stops in 115, do you keep the ERM for the steady trunk zones and let an LRA take the ankles, or do you want one motor family everywhere?

Citation quality, and replacements

The submission's reference list repeats a retail listing four times, a discussion forum thread three times, and a hobby blog once; the two research papers cited for the architecture are about drone obstacle mapping and mobile robot navigation, not tactile displays; the Frontiers paper on mechanoreceptors and the DepthLab paper on phone depth are sound. Retail pages and forum threads are where the founder found working examples, which is fair, but they are not sources a specification can rest on. The board recommends these replacements, all already cited in this review or in the project's own studies.

• For the PCA9685: the NXP datasheet.
• For motor timing and current: the manufacturer datasheets, 310-101, 310-103, C10-100, and the application notes AB-004 and AB-029.
• For the haptic driver comparison: the DRV2605L datasheet.
• For the I2C bus: NXP UM10204.
• For USB-C and Power Delivery: ST AN5225 and the Renesas role-swap primer.
• For Android camera latency: the inovex measurement and Android's external camera documentation.
• For the psychophysics: Bolanowski et al., Stevens, Cholewiak, Brill and Schwab, Dobrzynski et al., Gallace, Tan and Spence, Johannesson et al., Karuei et al., Tan, and for dense arrays at rest, Bach-y-Rita et al..

References

1. NXP, PCA9685 16-channel 12-bit PWM Fm+ I2C-bus LED controller, datasheet. https://www.nxp.com/docs/en/data-sheet/PCA9685.pdf
2. Texas Instruments, DRV2605L haptic driver, datasheet. https://www.ti.com/lit/ds/symlink/drv2605l.pdf
3. Precision Microdrives, 310-101 10 mm coin vibration motor, datasheet. https://cdn.sparkfun.com/assets/4/a/9/8/2/310-101_datasheet.pdf
4. Precision Microdrives, 310-103 10 mm coin vibration motor, datasheet. https://precisionmicrodrives.com/cdn/catalog_product/89437681-576e-46e1-97cf-5ae185adeb1c/310-103-datasheet.pdf
5. Precision Microdrives, C10-100 linear resonant actuator, datasheet. https://www.precisionmicrodrives.com/datasheets/C10-100%20-%20datasheet-006.pdf
6. Precision Microdrives, AB-004, understanding ERM vibration motor characteristics. https://www.precisionmicrodrives.com/ab-004
7. Precision Microdrives, AB-029, vibration motors: voltage versus frequency versus amplitude. https://www.precisionmicrodrives.com/ab-029
8. STMicroelectronics, UM3109, a guide for using the VL53L8CX. https://www.st.com/resource/en/user_manual/um3109-a-guide-for-using-the-vl53l8cx-lowpower-highperformance-timeofflight-multizone-ranging-sensor-stmicroelectronics.pdf
9. Pololu, VL53L8CX carrier product page. https://www.pololu.com/product/3419
10. NXP, UM10204, I2C-bus specification and user manual. https://www.nxp.com/docs/en/user-guide/UM10204.pdf
11. Espressif, ESP-IDF I2C driver reference. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/i2c.html
12. Espressif, ESP-IDF FreeRTOS reference. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/freertos_idf.html
13. inovex, glass-to-glass latency on Android. https://www.inovex.de/de/blog/the-glass-to-glass-latency-on-android/
14. Android Open Source Project, external USB cameras. https://source.android.com/docs/core/camera/external-usb-cameras
15. Kiloview, what is streaming through your USB webcam. https://www.kiloview.com/en/usb-audio-video-whats-actually-streaming-through-your-usb-webcam/
16. Punch Through, maximizing BLE throughput on iOS and Android. https://punchthrough.com/maximizing-ble-throughput-on-ios-and-android/
17. Benson Leung, USB Type-C's configuration channel. https://medium.com/@leung.benson/usb-type-c-s-configuration-channel-31e08047677d
18. STMicroelectronics, AN5225, introduction to USB Type-C Power Delivery. https://www.st.com/resource/en/application_note/an5225-introduction-to-usb-typec-power-delivery-for-stm32-mcus-and-mpus-stmicroelectronics.pdf
19. Renesas, USB Power Delivery: USB Type-C and role swap. https://www.renesas.com/en/support/engineer-school/usb-power-delivery-03
20. Infineon community, USB-C Android tablet charging in host mode. https://community.infineon.com/t5/USB-EZ-PD-Type-C/USB-C-Android-Tablet-Charging-in-Host-mode/td-p/223569
21. LAVA, SimulCharge technology. https://lavalink.com/lavaaccessory/simulcharge-technology/
22. Bolanowski, Gescheider, Verrillo and Checkosky, four channels mediate the mechanical aspects of touch. https://www.researchgate.net/publication/19946072_Four_channels_mediate_the_mechanical_aspects_of_touch
23. Verrillo, vibrotactile sensitivity and the frequency response of the Pacinian corpuscle. https://www.researchgate.net/publication/272013262_Vibrotactile_Sensitivity_and_the_Frequency_Response_of_the_Pacinian_Corpuscle
24. Stevens, tactile vibration: change of exponent with frequency. https://link.springer.com/article/10.3758/BF03212732
25. Cholewiak, Brill and Schwab, vibrotactile localization on the abdomen: effects of place and space. https://pubmed.ncbi.nlm.nih.gov/15675645/
26. Dobrzynski et al., quantifying information transfer through a head-attached vibrotactile display. https://pubmed.ncbi.nlm.nih.gov/22547452/
27. Gallace, Tan and Spence, numerosity judgments for tactile stimuli distributed over the body surface. https://pubmed.ncbi.nlm.nih.gov/16583769/
28. Johannesson et al., relative vibrotactile spatial acuity of the torso. https://pmc.ncbi.nlm.nih.gov/articles/PMC5649388/
29. Karuei et al., detecting vibrations across the body in mobile contexts. https://www.cs.ubc.ca/labs/spin/sites/default/files/local_pdfs/2011_DetectingVibrationsAcrosstheBody.pdf
30. Sofia and Jones, mechanical and psychophysical studies of surface wave propagation during vibrotactile stimulation. https://pubmed.ncbi.nlm.nih.gov/24808328/
31. Arm vibration propagation study. https://pmc.ncbi.nlm.nih.gov/articles/PMC8493869/
32. Tan, information transmission with a multi-finger tactual display, chapter 1. https://engineering.purdue.edu/~hongtan/pubs/PhDThesis/tan.chap1.pdf
33. Hand localization with five sites, IEEE Transactions on Haptics. https://ieeexplore.ieee.org/document/10100896
34. Palm vibration localization study. https://arxiv.org/abs/2302.08820
35. Bach-y-Rita et al., vision substitution by tactile image projection. https://www.nature.com/articles/221963a0
36. Weinstein's two-point thresholds, summarized. https://pmc.ncbi.nlm.nih.gov/articles/PMC2276213/
37. The Council's decisions. /research/council
38. The full-body haptic map. /research/full-body-haptic-map