Inside KUMA:
The Challenge of Hardware.
The roadmap page describes Hardware in a few careful paragraphs, on purpose. It is genuinely the earliest-stage item we have, and we would rather say plainly that most of it is unsolved than describe partnerships and specs that do not exist yet. This page is the longer, messier version of that thinking. We are not linking it from the blog index or the homepage. If you found it, you followed it here from the roadmap itself.
Internally we have been calling the device KUMA, short for Kernel Unified Maritime Analytics. It is a working name, not an announcement. Everything below is research, not a spec sheet.
The problem KUMA is trying to close
SEALUTION's routing already checks real depth against datasets like GEBCO, which we wrote about in detail. That is a static snapshot of the seafloor, not a live reading of what is actually under a specific keel on a specific day. Separately, a lot of vessels run on GPS and AIS equipment that is old, inconsistent, or reports infrequently, and once a vessel is genuinely offshore, getting any of that data back to shore is its own unsolved problem.
KUMA is one retrofit device meant to close both gaps at once: a sonar depth sensor, marine-grade GPS and AIS, and a connectivity module, feeding live data back into the platform instead of relying on static charts and whatever equipment happened to ship with the vessel.
What the device actually is
That offline branch matters more than it might look. A vessel can be out of any coverage, 4G, LEO, all of it, for hours at a time, and the edge processor keeps writing depth, position, and engine readings to a small local memory the entire time, exactly as if it were connected. Nothing pauses and nothing is lost waiting for a signal. The moment any connectivity tier reconnects, whatever queued up gets pushed to the platform in one batch, and local storage clears back out. The vessel's own log is never the bottleneck, the network is.
The sonar reading itself is the part people usually picture wrong, it is not one component but a round trip. A pulse goes out, the platform waits, and whatever comes back gets turned into a number.
Depth comes out of one plain calculation: time for the echo to return, multiplied by the speed of sound in water (roughly 1,500 m/s), divided by two. Everything else in the chain exists to make that one number trustworthy, boosting a signal that left as a sharp pulse and came back as a faint echo, at a frequency low enough to travel far or high enough to resolve fine detail, never both.
Sonar depth
A piezoelectric transducer, a transmit driver to fire a short high-voltage pulse, and a receive amplifier tuned to the operating frequency. Lower frequencies carry further, higher frequencies resolve finer detail. The tradeoff gets picked per vessel type.
Depth target and frequency
Most of the conversation around sonar depth gets stuck on the wrong number. The question is not how deep the ocean is. It is how deep the water gets in the places where depth actually changes what a vessel can safely do.
For KUMA's purpose that answer is roughly 1,000 metres. Every strait, every coastal approach, every inter-island route in Indonesian and Southeast Asian waters where shallow water is a genuine navigation decision sits inside that range. Open ocean beyond 1,000 metres is where vessels are already safe by definition, not because the seafloor is irrelevant but because nothing navigationally dangerous lives there.
Getting to 1,000 metres in a fairing block form factor requires picking the right frequency, and frequency is a direct tradeoff between range and resolution.
Lower frequency, longer range
Carries further in seawater with less attenuation. A well-driven 50 kHz transducer reaches 800–1,000 metres without exotic hardware. The resolution is coarser, you will not resolve a 20cm rock at 600 metres, but for under-keel clearance and route depth certification the number itself is what matters, not a fine-grained image of the bottom.
Higher frequency, sharper resolution
Gives sharper resolution and faster ping rates but attenuates quickly. Effective range drops to roughly 150–200 metres. In shallow coastal water and harbour approaches, that is exactly what you want: a fast, precise reading under the keel right now.
The practical answer is running both. Dual-frequency transducer elements exist as off-the-shelf components, one physical unit driven at two frequencies depending on depth. KUMA's edge processor reads depth automatically in 200 kHz mode in shallow water, switches to 50 kHz when depth exceeds roughly 200 metres, and blends them at the crossover. The transducer itself is compact enough to sit inside the fairing block described earlier.
At 1,000 metres the round-trip travel time for a sonar pulse is approximately 1.33 seconds. That is not exotic timing, it is well inside what a standard ESP32 handles with room to spare.
What this is not: deep-sea bathymetry. Resolving the seafloor at 5,000 metres or 10,000 metres requires low-frequency transducers physically measured in metres, kilowatt transmit power, and signal processing that belongs on a research vessel, not a retrofit device. KUMA does not do that, and does not need to. The 0–1,000 metre window covers every navigation decision in our clients' actual operations.
Marine GPS & AIS
Dedicated marine-grade units, built for the job the way a standalone chartplotter is, rather than a phone doing its best in a wheelhouse.
Edge processor & local storage
Handles time-of-flight calculation and holds a rolling local log whenever the vessel has no connectivity, so nothing collected offline is ever lost, just delayed until the next sync. Runs on a wide-input supply (roughly 9–36V) so it works on any vessel's house bank without configuration, with a small backup cell so a position fix is never lost mid-shutdown at port.
Power
A vessel is not a clean electrical environment. When a diesel engine cranks, the bus voltage spikes. When a generator transfers load, it sags. A device that works fine on a bench at 12V and dies on the first engine start in a real wheelhouse is not a marine product, it is a prototype that passed the wrong test.
KUMA's power chain has four stages, in order.
Protection
A fuse sized to the device's actual draw, a reverse-polarity MOSFET so a backwards connection from an installer does not destroy the board, and a transient voltage suppressor clamping the spikes a diesel crank produces. Total BOM cost for these three: a few dollars. The cost of skipping them: a dead device and a return visit by whoever installed it.
Regulation
A wide-input DC-DC converter accepting 9–36V and outputting clean regulated voltage for the electronics. This single component means KUMA works on any vessel's house bank, 12V, 24V, or anything in between, without any configuration change at installation. Indonesian inter-island vessels in particular can run low at port when the house bank is heavily loaded. 9V is the floor the converter is specced to handle gracefully, not 12V nominal.
Backup
A small LiFePO4 cell, lithium iron phosphate rather than standard lithium, because it handles heat and vibration better and is safer in an enclosed marine enclosure. Its job is narrow: keep the edge processor alive for 2–4 hours when the vessel cuts main power at port. Long enough to finish writing the local log, push whatever is queued if connectivity is available, and shut down cleanly rather than hard-crashing mid-write. Without it, the GPS trail has a gap every time the vessel ties up. With it, the trail is continuous.
Sleep mode
A vessel at anchor for twelve hours with KUMA running at full power draws on the house bank all night and the crew notices. A power management IC puts the device into a configurable low-power state when there is nothing urgent to do: sonar off, connectivity radio in listen mode, GPS sampling at one-minute intervals instead of continuous. Total idle draw drops from roughly 8–15W active to under 1W. Active draw of 8–15W at 12V is under 1.5 amps, a routine load for any vessel DC panel.
All four stages sit on a single PCB inside the device enclosure. The installer connects two wires, positive and negative, to the vessel's DC panel on a dedicated breaker. Everything else is internal. The vessel's electrician does not need to understand the power chain, just connect it correctly and fuse it to spec.
One note for steel and aluminium hulls specifically. The electronics chassis must be bonded into the vessel's common grounding and bonding system, not left floating. An unbonded chassis on a metal hull creates a stray current path. Stray current causes galvanic corrosion at the nearest metal fitting in salt water, which in KUMA's case is the cable gland at the hull. This is a routine requirement for any marine electronics installation and is covered in the install stages above, but it is worth naming here: the ground bond is not optional.
Connectivity module
Whatever gets the readings back to shore while the vessel is still at sea. This is the hardest problem on the whole device, covered further down.
Where KUMA plugs into the platform
KUMA is not a standalone gadget, every reading it takes is meant to land inside a module SEALUTION already ships. Nothing here is a new product, it is existing modules getting a better data source.
| KUMA feeds | Into this module | What changes |
|---|---|---|
| Sonar depth | Routing Engine 2.0 | Live bathymetry under the actual keel, not just a static GEBCO chart |
| Marine GPS | GPS tracking | A live trail, not a periodic AIS ping |
| Engine & fuel sensors | Fleet registry | Engine hours and fuel consumption logged automatically |
| GPS + engine data | Voyage scheduling | ETA calculated from actual speed, not the timetable's assumption |
| Depth + position | Alerts & documents | Shallow-water warnings, certificate expiry tied to real vessel activity |
| GPS + connectivity | Customer app | A live position for the client watching their cargo, not an estimate |
Every vessel running KUMA feeds live depth data back into Route Engine 2.0. The more vessels carrying it, the smarter every client's routing gets, including clients who never bought the device themselves. That network effect is the actual strategic reason this is worth building, not the hardware margin.
What the depth data actually becomes: route certification
The platform integration table above describes what KUMA feeds into each module. What it does not describe is what happens when many vessels feed the same modules over time, because that is where the value compounds in a way a single-vessel reading does not.
Every depth ping KUMA takes is tagged with the GPS position at that exact moment. Lat, lon, depth, timestamp, vessel draft. The platform compares the depth against the registered draft of the vessel that took the reading, plus a configurable safety margin, typically 1.5 to 2 times draft depending on the operator. If the reading clears the margin, that coordinate is marked safe. String enough safe coordinates together along a route corridor and the platform has something no static chart provides: a confirmed, real-vessel, real-date depth clearance along a specific line.
We call these OK lines internally. They are not our invention as a concept, the hydrographic surveying world has done route certification for decades. What is different here is that OK lines are produced continuously and automatically by vessels already sailing the route for their own purposes, not by a dedicated survey ship sent out to measure it.
The logic the platform applies to each ping is straightforward:
- Depth reading comes in from KUMA
- Platform looks up the vessel's registered draft
- Applies the configured safety margin for that vessel
- If depth exceeds draft plus margin: coordinate marked safe, added to the OK line for that route corridor
- If depth falls below the threshold: alert generated, reroute suggestion triggered, coordinate flagged
Different vessels with different drafts produce different results from the same reading. A 2-metre-draft ferry and a 9-metre-draft bulk carrier sailing the same corridor are not navigating the same water even if the GPS track looks identical. The platform handles this per vessel, automatically, using the draft already registered in the fleet registry.
The network effect this produces is the actual reason KUMA is worth building.
A vessel sails a route it was always going to sail, for its own cargo, for its own client. Along the way it confirms 200 depth readings. Those readings become part of the route's OK line on the platform. The next vessel routing through the same corridor routes against real-vessel-confirmed depth, not a GEBCO chart surveyed years ago. Clients who never purchased KUMA benefit from OK lines built by clients who did.
Static charts like GEBCO are snapshots. Sedimentation, underwater landslides, debris, objects on the seafloor: none of that updates a published chart on a useful timescale. An OK line built last week reflects what was actually under the keel last week.
This is also where the 1,000 metre ceiling makes sense commercially rather than just technically. A depth reading of 1,000 metres on a coastal approach means the route is clear for any vessel in our client base. The platform does not need 3,000 metres of precision to say that. It needs enough range to confirm clearance across the full range of water our clients actually navigate, and 1,000 metres covers it.
The part that scares people: cutting the hull
Every vessel-mounted sonar needs the transducer physically in contact with the water, and every honest conversation about that starts with the same worry: does this mean cutting into the hull? The answer is it depends which of three mounting methods you use, and they carry very different risk.
In-hull, shoot-through
The transducer sits inside the vessel and fires straight through solid fiberglass. No penetration at all. Only works on solid FRP hulls, not steel, aluminum, or cored fiberglass, and signal loss is higher.
Fairing block
An epoxy or polyurethane block is bonded to the outside of the hull. The transducer lives inside it, fully surrounded by water. The only penetration needed is one small cable gland, roughly 20–25mm, about the size of a standard bilge fitting.
Through-hull
A 50–80mm hole is cut, a bronze or plastic fitting installed, and the transducer mounts flush. Best signal quality, but it needs a certified shipwright, a seacock as a safety net, and a sound, corrosion-free hull.
A through-hull fitting, done right, does not weaken the hull, the fitting is stiffer than the surrounding plate. But given that our client vessels are already purchased, already sailing, and already carrying cargo, the fairing block is the default we are planning around: near-zero structural risk, and it works regardless of hull material.
How the install actually runs
This is not a job for vessel crew. It needs a certified shipwright for hull work, a certified marine electrician for wiring, and ideally a marine surveyor to sign off before and after. A straightforward single-transducer fairing block installation on a mid-size vessel runs roughly 2–4 days of skilled labor in a yard.
Click a stage below for what actually happens.
Planning & hull survey
A surveyor or shipwright checks hull thickness, corrosion, and pulls structural drawings to confirm there are no frames, tanks, or keel bolts behind the target spot. The classification society is checked for whether the mount triggers a formal survey notation. This step is what most expensive mistakes skip.
- Marine surveyor or qualified shipwright
- Vessel's original structural drawings
- A clean, sound spot for the fairing block
- Whether the mount needs a class notation
Fairing block bonding
The vessel goes into dry-dock. The hull area is ground back to bare material, the block is shaped to match the hull curvature, bonded with structural marine epoxy, and clamped while it cures, usually 24 hours. Voids under the block are the main long-term failure mode, so surface prep matters more than the drilling ever does.
- Boatyard for the haul-out
- Certified shipwright for the bonding
- Air voids under the block, causes delamination later
- Poor surface prep, weak bond over time
Cable & gland
One small hole, 20–25mm, is drilled near the fairing block, about 2 minutes' work with the right bit. A cable gland seals it watertight, the transducer cable runs through the bilge to the electronics space, secured every 30–40cm and kept clear of chafe points and standing water.
- Certified shipwright
- A large hull penetration, this one is pencil-sized
- Cable chafe against sharp hull edges
Power & electronics
The device draws power from a dedicated, correctly fused breaker on the ship's DC bus, protected against the voltage spikes a diesel engine crank produces. The electronics chassis gets bonded into the vessel's grounding system, unbonded electronics on a steel or aluminum hull can create stray currents that eat the hull from the inside.
- Certified marine electrician
- A dead device on the first engine start
- Galvanic corrosion from stray current
Testing & commissioning
Before relaunch, a wet test checks for leaks at the fitting. Once afloat, depth readings are cross-checked against a known chart sounding, and other onboard electronics, GPS, VHF, autopilot, are checked for interference. A common first-launch snag is a trapped air pocket under the transducer face, fixed with a small angle adjustment or vent hole.
- Shipwright and marine electrician
- Marine surveyor for sign-off
- No leaks, accurate readings, no interference
- Ready to record in the vessel's class certificate and SOLAS log
Who actually installs it: us, a vendor, or the client?
The install section above answers what has to happen physically. It does not answer who does it, and that is a staffing question, not a technical one.
Our own install team
We are a small team, four directors, no support queue. Flying an internal crew to every dry-dock across an archipelago, or eventually multiple countries, does not scale past a handful of vessels.
Client self-install
Already answered earlier on this page: hull work needs a certified shipwright, wiring needs a certified marine electrician. This was never a job for vessel crew, and that has not changed.
A certified partner network
Shipwrights, marine electricians, and surveyors already work at every port a client's vessel visits. The realistic model is vetting local partners against one SEALUTION install spec, the same partner-not-build instinct behind the connectivity thinking below.
Maintenance splits the same way, by what can travel over the connectivity link and what cannot.
Firmware & software
Updates, bug fixes, and calibration changes push over the same connectivity module already reporting depth and position. No yard visit, no partner network needed for this half.
The physical unit
Marine growth on the transducer face, antifouling touch-ups, connector corrosion, a failed sensor swap. This is where the same certified partner network doing installs comes back into the picture, and where the platform's own diagnostics decide whether a visit is actually needed before anyone travels anywhere.
The connectivity problem, honestly
A depth sensor is only useful if its reading reaches shore while the vessel is still at sea, and for a lot of Indonesian waters, and especially for multinational voyages, no single technology covers the whole trip. The current thinking is a hybrid stack that switches automatically depending on where the vessel actually is.
4G / LTE
Cheap, fast, reliable within roughly 50km of a coast. A multi-carrier roaming eSIM handles switching between local carriers across countries without swapping SIM cards.
LEO satellite
Starlink Maritime and similar low-earth-orbit services, usable latency (20–60ms) for real two-way sync. The likely primary for deep-sea and multinational routes, hardware cost is the main current barrier.
LoRa
Extremely low power, but range is only 10–40km from a gateway. Useful as a cheap heartbeat between Indonesian islands, not a primary for open water.
GEO satellite ping
A minimal position ping every 15–30 minutes when nothing else is available, so the platform never fully loses a vessel, even mid-storm with a blocked LEO antenna.
Laid out against actual distance from shore, the gaps each technology needs to cover become clearer:
4G is cheapest by far, LoRa is nearly free but genuinely local, LEO is the only technology with real global reach at usable latency, GEO is the expensive always-on insurance policy underneath all of it.
Four tiers, one core device
The sensors and the edge processor stay the same across every vessel. What changes is which connectivity module gets plugged into the same slot, so pricing and coverage scale with how far a client's vessels actually travel, not a one-size-fits-all radio nobody needed.
4G / LTE only
Multi-carrier eSIM. Built for coastal and inter-island Indonesian operations that rarely leave port-to-port range.
4G + LEO
Auto-failover between the two. Fits regional routes across Southeast Asia and the Pacific where 4G coverage gets patchy but never fully disappears for long.
4G + LEO + GEO
Full ocean coverage with the GEO ping as a dead-man's switch. For genuinely multinational, deep-sea voyages, the tier most of this page has been describing.
Ethernet / LAN
Plugs into a vessel's own existing VSAT system instead of adding a second subscription. For operators who already pay for satellite connectivity and just need KUMA's sensors to use it.
This is exactly the part the roadmap page calls unsolved, and it still is. The current lean is toward partnering with an existing satellite or connectivity provider rather than building our own network, the same way the roadmap already says. Which provider, on what commercial terms, and for which part of our client base first, is genuinely undecided. The tiers above are a shape for the thinking, not a priced product.
Explore the whole device
Everything above walked through one subsystem at a time. This is the same device as one interactive model, physical form, power chain, sensor stack, connectivity, and data flow, so you can click through it instead of scrolling back up. Switch layers with the tabs, click any block for its full spec.
What we're learning from, with credit
None of this is being figured out in a vacuum. A handful of open-source hobbyist and maker projects have already proven out pieces of what KUMA needs, and it would be dishonest to write a page like this without naming them.
Open Echo
An open-source sonar hardware and software stack built around an Arduino shield, supporting transducers from 40 kHz to 1000 kHz, marine in-hull units included, with depth performance tested past 50 meters and NMEA0183 output any chartplotter already reads. The closest existing reference to the transmit/receive chain described earlier on this page.
OpenMarine DIY fishfinder thread
A long-running forum thread where builders compare real results: one project reports 20–30cm resolution to about 15 meters depth on a 120V transducer drive, another (Open Echo's own author) reports echoes from 46 meters on 25V with the TUSS4470 chip. Real, working transducers like the Airmar P319 come up repeatedly, along with plans to feed results into OpenCPN and OpenPlotter. Useful as a reality check against our own numbers.
arduino-lora
An MIT-licensed Arduino library for Semtech SX1276/77/78/79 LoRa radios, direct radio-to-radio, no LoRaWAN gateway required. Close to exactly the kind of lightweight link the LoRa tier described above would actually run on.
AIS-Radar
A GPL-3.0 project turning a Raspberry Pi Pico, a GPS module, and an AIS receiver into a radar-style display tracking nearby vessels with a close-quarters alarm. A working, credited example of the kind of compact marine AIS unit KUMA's identity layer is modeled on.
AIS_IoT_4G
A board and Arduino library pairing an ESP32 with a SIM7600E 4G module, MQTT and HTTP support included. The closest existing open reference to KUMA's own edge-processor-plus-4G-module pairing.
Arduino or ESP32?
Worth noticing: the projects above do not agree on a chip, and the disagreement is informative. Open Echo runs on a plain Arduino Uno, an 8-bit AVR chip at roughly 16 MHz with about 2KB of RAM and no radio of its own, which is genuinely enough to drive a transducer and time an echo. AIS_IoT_4G reaches for an ESP32 instead, dual-core, roughly 240 MHz, 520KB of RAM, with WiFi and Bluetooth built in, because it also has to run a 4G modem and speak MQTT.
Arduino Uno class
One job, done tightly: fire a pulse, time an echo, convert it to a number. An 8-bit AVR chip with 2KB of RAM is not a limitation here, it is plenty.
ESP32 class
Sonar timing, GPS parsing, offline local storage, and managing a connectivity module, all at once. The sonar pulse itself is simple. Everything happening around it is not, and that pushes the edge processor toward the ESP32 side of this line.
The fundamentals, before any marine hardware
None of the pulse-echo timing at the center of this is exotic. It is the same principle a $2 HC-SR04 module teaches an ESP32 in a beginner tutorial, 2cm to 4 meters, in air, nothing waterproof about it, and the same wireless sensor-to-display pattern shows up in hobbyist builds like a 360° ESP32 radar that spins a cheap ultrasonic sensor on a stepper motor and streams angle-distance pairs over WiFi to a live PC display. Neither project is marine-grade. But pulse out, timed echo back, streamed to a display, is exactly the shape KUMA scales up, with a real transducer instead of a hobby sensor and a real connectivity link instead of a home WiFi socket.
ESP32 + HC-SR04 tutorial
A standard beginner walkthrough: wire an HC-SR04 to an ESP32, read distance over serial. Not waterproof, not marine, but the exact timing logic every sonar build starts from.
360° ESP32 radar
An MIT-licensed project rotating an ultrasonic sensor with a stepper motor and streaming angle-distance readings over WiFi to a live radar-style display. A small, credited example of exactly the sensor-to-display data path KUMA scales up.
Why share any of this at all?
A fair question. Publishing mounting methods, component chains, a cost breakdown, and a working price target means someone could read this page and go build their own version. That is true, and we are genuinely fine with it.
None of the hard technical pieces here are secret or proprietary. This product, in one shape or another, already exists: hobbyists have been building sonar depth sensors, AIS units, and LoRa links in garages for years, we did not invent pulse-echo depth sensing, and neither did the open-source projects we cited above, they are standing on decades of established sonar and radio engineering too. A determined competitor could build a similar box without ever reading this page, and several probably already have.
What actually makes KUMA worth building is not the hardware. It is that this specific device is built to plug straight into a platform a client is already running their fleet on, feeding Routing Engine 2.0, GPS tracking, fleet registry, and the network effect described earlier. Anyone can build a sonar box. Nobody else can make it feed directly into the routing engine underneath a specific client's operation. That is the actual reason to build our own device rather than resell someone else's, and publishing an install diagram does not give it away.
Could KUMA be the whole bridge, not just a sensor?
I keep getting asked a version of the same question, and I have been chewing on it myself: could we sell KUMA on its own, not as an add-on to a platform a client already runs, but as a vessel's actual primary navigation system? Sold to a shipyard or a builder who fits it on a newbuild as the main instrument on the bridge, the way a chartplotter or an ECDIS is fitted today?
The honest answer is that the hardware could get there, but “primary navigation” is a much bigger promise than “a smart depth sensor,” and most of the distance between the two is not electronics.
It would need a screen
The KUMA on this page is deliberately headless, no display, every reading lives on the platform and the crew looks at a phone or a bridge PC. A device that is somebody's main navigation cannot be headless. It needs its own marine display in the wheelhouse: chart, position, under-keel depth, AIS traffic and alarms, readable in direct sun and at night, on hardware rated for a wet, vibrating bridge. That is a real product in its own right, not a firmware change.
Type approval, not just software
As a primary system it stops being a sensor and becomes a chartplotter: licensed electronic charts, route planning, an AIS overlay, collision and grounding alarms, and certification. Anything sold as primary navigation on a commercial vessel runs into SOLAS and IMO carriage rules and, for the chart display, ECDIS-class type approval, slow, costly and unforgiving. That is a completely different kind of work from building a good sensor.
Then there is size. One transducer at one point on the hull tells you the depth under that one point. On a small vessel that is basically the whole keel. On a 200-metre bulk carrier it is not, the bow can be in clear water while the stern, sitting deeper and near the screws, is the part that actually grounds. A big ship needs more than one sonar.
The way that scales is not one giant sensor but several KUMA transducer nodes, bow, amidships and stern, and on very wide hulls port and stern quarters too, hung off a single networked backbone. NMEA 2000 is the obvious choice; it is already the standard data bus on commercial bridges. One edge processor reads every node, takes the shallowest reading as the governing under-keel clearance, and builds a clearance profile along the length of the hull instead of a single number. The same OK-line logic then certifies against the worst-case point, not an average.
So can we do it? The sensing and the networking, yes, multiple nodes on one bus feeding one processor is ordinary marine engineering, and we would build the big-ship version that way regardless. The standalone-bridge product, with its own certified display and chart stack, is a much larger and slower thing, and it is honestly a different, company-shaped decision from the retrofit device this page is about. For now KUMA stays what it is: a retrofit sensor-and-connectivity unit that feeds the platform. But an OEM “bridge” variant, sold to builders who want it as the main system on a newbuild, is a real fork in the road we have started sketching, and the multi-sonar scaling above is the first piece of it that already makes sense on its own.
Where this actually sits
KUMA is planned as a separate, optional purchase, not bundled into the All-in-One license. A client who already owns the platform can add it later, and it connects to any existing SEALUTION installation. Nothing about it changes what the software already does on its own.
Neither number is final. The bill of materials is not locked, the connectivity tier changes it substantially (an entry Module A unit costs meaningfully less to build than a Module C with GEO satellite hardware), and real manufacturing volume could move either number in either direction. This is where our own internal thinking sits today, stated with the same honesty as everything else on this page, not a price list.
Everything on this page is research and reasoning, not a finalized spec, not a sourced component list, and not a commitment to any partner named above. We are documenting our own thinking honestly, in the same spirit as the roadmap page itself. If any of this becomes real, it gets its own proper announcement when there is something real to announce.
Operate the device in your browser, live sonar waterfall, rotating radar, the power chain surviving an engine crank, connectivity by distance from shore, and OK lines building along a voyage.
Ask us about KUMA directly.
This is early, honest research, not a pitch. If you want to talk through it, or you have a fleet that would be a good testbed, we'd rather hear from you now than after it's finished.