See the unseen. Read the link before you build it.
Your sensors work Monday and die Thursday for no visible reason. A design gets signed off on faith. Emrysia makes the invisible field legible — I model your link, show exactly where it fails, and foretell the fix before a single board is fabricated.
Sub-GHz ISM 433 / 868 / 915 MHz · LoRa & LoRaWAN · BLE 2.4 GHz · Wi-Fi & 5 GHz PtP · Zigbee / Thread
Friis + log-distance path loss · ITU-R P.526 knife-edge diffraction · Fresnel-zone, EIRP & duty-cycle compliance
ESP32 · Nordic nRF · STM32 · Raspberry Pi · Semtech SX127x / SX126x · Arduino
A 6 dB shortfall, a band clash, a Fresnel zone clipped by a hill — none of it shows up in a photo of the install. You find out when the network is already in the ground.
Nobody argues with the invisible. Deployments get signed off on faith, then quietly under-perform. The cost isn't the failure — it's the truck rolls, the re-spins, the lost trust.
Every mythic claim on this site is backed by a number on screen — −6 dB, 915 vs 868, 1% duty cycle. Magic in the story, math in the work. That's the whole promise.
Most shops hand you a coverage map or a code fix — never both. I'm a wireless generalist: I diagnose the physics, correct the code that talks to the radio, and give you a package you can hand to a client or a manufacturer.
Multi-band link budgets (Friis + log-distance), coverage rings, margin in plain dB, terrain-aware diffraction that actually breaks a link over a hill.
Whole multi-node meshes with comms-drop tracing — find the exact broken hop, then place a repeater on high ground with clear line of sight.
ESP32, Nordic, STM32, RPi, Semtech LoRa. I read your firmware, find the wrong lines, and hand back corrected code + a diff.
MCU + antenna + protocol into a validated link package: a bill of materials, a reference config, and a report that says why it will stand.
The same five moves, whether it's a two-hour audit or a full device build. You bring the problem; I hand back the grimoire.
You describe the deployment — "our yard sensors keep dropping, it's like they're cursed." I drop your nodes onto the field with their real radios, bands, and antennas.
The invisible field blooms — coverage rings, the mesh, every link's margin in plain dB. The magic finally has a picture, and the weak spots are obvious.
A link glows gold: Node 4 is on 915, the gateway on 868 — they can't hear each other. The trace finds the exact broken hop and the reason it broke.
Corvus calls it. The optimizer foretells the working rig — antenna, power, cheapest legal path — before any hardware is bought or re-spun.
You get the deliverable: a PDF report, corrected firmware, a BOM. Your client thinks you lifted a curse. You showed them the math.
Behind every engagement is a real, offline-first RF workbench I built and use on live work. It's the proof of competence and the delivery differentiator — you don't just get an opinion, you get the model it came from.
The sweet spot is a specific, painful problem that's costing you truck rolls or a re-spin. If it's a vague "help us with wireless someday," I'm probably not your best fit — and I'll tell you.
Backhaul or coverage that models fine on paper but won't connect in the field — a ridge, a band clash, or a link that's quietly a few dB short.
Shipping a LoRa, BLE or sub-GHz device without in-house RF — you need the radio and firmware right before the first PCB run, not after.
Agriculture, industrial, and smart-building sensor networks where "it's cursed" is really a dead hop — and it's costing repeat site visits.
No open-ended hourly black holes. Each engagement is scoped, priced, and delivered as a package. Prices below are launch rates.
Sample engagements that show the method end to end. Demonstration projects — synthetic scenarios built with the tool while the first client case studies come in.
A 40-node soil-moisture mesh that dropped a third of its nodes after mid-day. Traced to a duty-cycle violation + a band mismatch. Fixed in firmware, no new hardware.
Read the case Case 02 · WISPA backhaul that modeled fine but never connected. Knife-edge diffraction showed a 31 dB terrain loss. A repeater on high ground restored +9 dB margin.
Read the case Case 03 · IoT productA BLE wearable over its EIRP cap. Caught before the fab run — antenna + power-table change kept it legal and saved a re-spin.
Read the caseFixed price per package, quoted in writing before anything starts — no open-ended hourly billing. Most RF shops make you contact them for a quote; I'd rather you know the number and the deliverable up front.
A package you can act on and forward: a PDF report in plain language, corrected firmware with a clean diff, a BOM of real sourced parts, and per-node config. It's yours to keep — not a dependency on me.
Sub-GHz ISM (433 / 868 / 915 MHz), LoRa & LoRaWAN, BLE 2.4 GHz, Wi-Fi and 5 GHz point-to-point, Zigbee / Thread — on ESP32, Nordic nRF, STM32, Raspberry Pi, Semtech SX127x/126x and Arduino.
No. I work remotely from your node locations, radios, and firmware. If you can send a map, a parts list, and the symptom, I can model it — deployments are often GPS-denied and offline anyway, which is exactly what the tooling is built for.
Every package includes a defined revision round, and the scope — including what's not included — is agreed in writing before work starts. If it's a 15-minute answer, I'll tell you that instead of selling you a project.
No — it's the instrument I build and run the work on, not a product you buy or install. What you get is its output on your deployment: the modeled link, the fault, the fix, and a package (report + corrected code + BOM) you keep.
Tell me what's dropping. I'll tell you what I see — and whether it's a two-hour audit or something bigger — before you spend a dollar on hardware.