Services · Bespoke software

Bespoke software, built by engineers who know the job

When the system you need does not exist yet, we build it: integrations that join one vendor's equipment to another's, gateways, engines and design tools. We wrote every tool on this site, and we write the software that sits between your equipment and the people who rely on it.

  • ● 105 tools built and running
  • Any language the job needs
  • A fixed quote before work starts

What we build

Software for the parts of the job no product covers

Each one is something we have already built, and the link shows you where.

Integrations and gateways

Feeds polled or streamed in, translated, and sent on over MQTT or HTTP, with a vendor-neutral core so the next output is an addition, not a rewrite.

The drone traffic gateway →

Engines that follow the rules

Rules turned into code that runs the same way every time and keeps its working, so a reviewer can follow every number back to where it came from.

The coordination engine behind our ACMA work →

Design tools and calculators

Planners and calculators with the model, the standard it is cited to and the inputs in front of the people who sign off the design.

105 tools live on this site →

Data pipelines

Registers, terrain, weather and manufacturer catalogues brought in, cleaned and kept current, in a database you can query.

The ACMA register, searchable here →

3D and maps

Sites, coverage and safety zones in 3D and on maps, drawn from the same numbers as the report rather than a picture of them.

RF EME Exposure Modeller →

Reports and web applications

Reports that print their sources, and web applications with accounts, access control and billing, hosted and maintained.

This platform, its plans and reports →

Illustrations of the kind of work. The links show the real thing.

Things we have built

From the airspace over a mine to the cameras on a fence

What each one does, and where it stands.

Proof of concept · client not named

Crewed aircraft, in front of remote drone pilots

A drone survey operation on a mine site needed its remote pilots to see the crewed aircraft around them. The site's receivers already picked up ADS-B, and multilateration (MLAT) located the aircraft that do not broadcast their position. The pilots' DJI FlightHub 2 could show traffic. Nothing joined the two.

  • Reads ADS-B and MLAT aircraft from the site's Jetvision Radarcape receivers and their MLAT server.
  • Holds every aircraft in one vendor-neutral track picture, filtered to the site's range, so other outputs can be added without touching the core.
  • Sends the traffic to DJI FlightHub 2 through the DJI Edge SDK V2, by way of the drone's ground station, in the format and at the rate the SDK specifies.
  • A stand-in ground station checks every message against the SDK's published specification, so the whole path was tested with no DJI hardware on the bench.
~65aircraft within 100 km, from a live public receiver feed
2 sbetween updates, the rate the SDK specifies
Everymessage accepted by the specification check

A proof of concept: not yet run on the site's hardware. Built in Rust; moving to the real ground station is designed to change only its address and credentials.

Built for customer handover

Every camera's view, in every light, for the handover

Handing a CCTV system over means showing the customer what each camera actually sees, and a camera that is fine at noon can be useless at dusk. Capturing that by hand, camera by camera and visit by visit, is slow.

  • Connects to the cameras over the network and takes a snapshot from each one using its RTSP stream.
  • Works through every camera in the installation, so a whole site is captured in one pass.
  • Run in daylight, at dusk and after dark, it records each camera under each lighting condition.
  • The snapshots go into the customer's handover, camera by camera.
RTSPa snapshot from each camera's own stream, over the network
One passfor every camera in the installation
Day to nighteach view captured under each lighting condition

Works with cameras that serve an RTSP stream, as most IP cameras do. The handover shows the customer what each camera sees, in the light it will actually work in.

Built

Radio subscriber files, filled from the records you already hold

A radio network's subscriber database has to be filled out before the radios are of any use, and on a large system that is a lot of entries. The details are usually already in the customer's own databases and portfolios.

  • Reads the customer's existing databases and portfolios.
  • Fills out the radio subscriber files from them, rather than having someone type each entry.
  • Handles large subscriber databases in one pass, the same way every time.
  • Takes each entry from where the details already live, so nothing is retyped by hand, which is where mistakes creep in.
Existingcustomer databases and portfolios as the source
One passfor a large subscriber database
No retypingevery entry filled from the records

Built to work from the customer's own records, so the subscriber database matches what they already hold.

How a build runs

Scoped, quoted, proved, then built

Step 1 of 4

A free scoping call

Tell us the problem and the systems involved. It costs nothing, and you will know whether it is worth building.

Step 2 of 4

A fixed quote

Scope, price and timeline in writing before any work starts. Anything outside the scope is quoted before we do it.

Step 3 of 4

Discovery, then build

We prove the hard part first, often against a stand-in for the hardware, then build the rest on what that proved.

Step 4 of 4

Site test and handover

Tested where it will run, documented, and handed over to the people who will look after it.

Who owns the code is set in the statement of work for each job. Where it is silent, we keep our own tools and background IP, and you get a perpetual licence to use what we built for the purpose it was built for. (Terms, section 8)

Why us

Engineers who write software

We know the domain

RF, comms and electrical engineers, with an ACMA accredited person in the business. The specification is shorter when the developer already knows what a fade margin is.

We run our own software

This platform is ours: 105 tools, accounts, billing and reports, built and run by us in production every day.

Built to be added to

Vendor-neutral cores and plain interfaces, so the next feed, device or output is an addition rather than a rewrite.

Any language the job needs

We work in whatever language suits the job and the team who will look after it. Our own work runs on Rust, TypeScript, Python and PostgreSQL.

Need a system that does not exist yet? Let's scope it.

A scoping call is free, and you get a fixed quote before any work starts.