Building a Private Wi-Fi AIS Station for Direct Streaming to Navigation Applications

We have completed and successfully tested a new Pilot Plug project: a compact “local AIS receiving station capable of streaming live AIS data directly over Wi-Fi to Pilot Plug or other compatible navigation applications using standard TCP/IP”.

The objective was not to create another internet AIS service.

It was almost the opposite.

We wanted to build a station that could receive AIS transmissions locally, create its own Wi-Fi network, and deliver the vessel data directly to a tablet, phone or computer without requiring a cloud service, remote server or permanent internet connection.

The result is now a working and real-world-tested system.

The Basic Architecture

The complete data path is straightforward:

“AIS antenna → SDR AIS receiver → Raspberry Pi → AIS-catcher → TCP/IP → private Wi-Fi → navigation application”

The current station uses an AIS antenna connected to an RTL-SDR receiver.

The SDR is connected by USB to a Raspberry Pi, where AIS-catcher receives and demodulates the two AIS radio channels.

Instead of forwarding the information to an internet server, AIS-catcher provides the standard AIS NMEA stream directly through a local TCP server.

The Raspberry Pi simultaneously creates its own Wi-Fi access point.

A tablet, phone or computer connects directly to that network and receives AIS data from the station.

Our tested configuration uses:

“Protocol:” TCP
“Station IP:” 192.168.50.1
“Port:” 10110

The Pilot Plug Android application then receives the live AIS messages directly from the station.

No intermediate server is necessary.

Standard AIS Data Instead of a Proprietary Protocol

One of the important design decisions was to keep the output conventional.

The station provides standard AIS NMEA messages such as:

`!AIVDM,…`

We deliberately did not create a proprietary communications format between the station and Pilot Plug.

Pilot Plug is our primary tested application, but technically the station is not limited to Pilot Plug.

Any software capable of receiving compatible AIS/NMEA data through a TCP connection can potentially use the same stream.

This creates a useful separation between the receiver and the display.

The AIS station is responsible for receiving and delivering the data.

The navigation software is responsible for decoding, displaying and using that information.

That makes the station much more flexible.

A Completely Local AIS Network

The system has been designed around local operation.

During normal use:

* no internet connection is required;
* no mobile connection is required;
* no cloud AIS provider is required;
* no external AIS server is required;
* the receiving device communicates directly with the station;
* AIS information remains inside the local Wi-Fi network.

This means the station can continue functioning even where internet access is unavailable or unreliable.

As long as the station can receive AIS radio transmissions, the local AIS picture remains available.

For a vessel, marina, shore installation or temporary maritime operation, this can be an important advantage.

Moving the Station to 5 GHz

We therefore moved the onboard Wi-Fi access point from 2.4 GHz to 5 GHz.

The difference was immediately noticeable.

With the Raspberry Pi configured for:

“5 GHz
Channel 36
20 MHz bandwidth
Wi-Fi power saving disabled”

the TCP Send-Q remained consistently around zero.

During the clean tests:

* Send-Q remained at `0`;
* occasional very small queue values disappeared immediately;
* Wi-Fi transmission failures remained at zero;
* live ferry movement looked correct;
* distant AIS targets became visible again;
* target age returned to normal.

The onboard 5 GHz configuration therefore became the default configuration for the project.

This was one of the reasons we considered real-world testing important.

On paper, both Wi-Fi configurations could carry the tiny bandwidth required for AIS.

In practice, the difference was substantial.

Optional External 5 GHz Wi-Fi

We also tested the station with an external AXE3000 USB Wi-Fi adapter.

The adapter uses the Linux `mt7921u` driver and supports access-point operation.

The external adapter was tested on 5 GHz and performed reliably.

During testing we observed:

* TCP Send-Q consistently at zero;
* zero transmission failures;
* stable operation even at relatively weak signal levels;
* good practical data rates;
* reliable AIS updates in the connected application.

This gave us another possibility.

Instead of forcing every station to use either the Raspberry Pi Wi-Fi or an external adapter, we developed automatic selection logic.

Automatic Wi-Fi Selection and Fallback

The station checks its available Wi-Fi hardware during startup.

If the supported external Wi-Fi adapter is connected and operational, the station uses it.

If the adapter is not available, the Raspberry Pi automatically falls back to its built-in Wi-Fi.

The important part is that the user does not need to reconfigure the navigation application.

Regardless of which radio is being used, the station keeps the same:

“Wi-Fi network name”

“IP address”

“TCP AIS port”

From the user’s point of view:

“External adapter present → station uses external Wi-Fi”

“External adapter absent → station uses onboard Wi-Fi”

“Pilot Plug settings → unchanged”

Both configurations have now been cold-boot tested successfully.

This makes the external adapter an optional improvement rather than a dependency.

Privacy by Design

Another important objective was to ensure that the station was genuinely local.

Simply disconnecting an internet cable would not have been enough for the architecture we wanted.

The previous server-forwarding components were removed, and the station now operates as an independent local AIS receiver.

We also implemented a local firewall.

Devices connected to the Pilot Plug AIS Wi-Fi network can access the Raspberry Pi itself and therefore receive the TCP AIS stream.

However, the Wi-Fi clients are prevented from being routed through the Raspberry Pi toward another network.

Conceptually the firewall allows:

“tablet → AIS station”

but blocks:

“tablet → AIS station → external network”

This creates a very simple privacy model:

“receive locally → distribute locally → display locally”

The Raspberry Pi is an AIS station, not an internet gateway.

Live AIS Testing

The system has now progressed considerably beyond a theoretical prototype.

The complete chain has been tested with real AIS traffic.

The verified elements include:

* RTL-SDR AIS reception;
* AIS-catcher operation;
* live AIS NMEA output;
* TCP server on port 10110;
* Pilot Plug receiving live AIS targets;
* Raspberry Pi onboard 5 GHz Wi-Fi;
* external 5 GHz Wi-Fi;
* automatic external-radio detection;
* automatic onboard-radio fallback;
* cold-boot operation;
* local-only firewall operation;
* disabled public/community AIS sharing;
* stable TCP transmission;
* normal target ages;
* real-time vessel movement.

During the final clean tests the TCP transmit queue remained essentially at zero.

This is important because the purpose of the project is not simply to produce AIS messages.

The objective is to deliver those messages to the navigation application without gradually creating an invisible delay.

More Than Just a Pilot Plug Accessory

Initially this project was closely connected with Pilot Plug.

The idea was to create another independent AIS source for the Android application.

But once the complete system started working, the broader possibilities became obvious.

The station is not really an application accessory.

It is a “network AIS source”.

Pilot Plug happens to be one application capable of using it.

That means the same principle can potentially be used by different users for very different purposes.

A small vessel may use it as an independent AIS receiving system.
A marina may use it to monitor nearby vessel movements.
A shore facility may use it to create a local AIS picture.
A temporary maritime project may deploy one only for the duration of an operation.
A training facility may use one without requiring access to a vessel’s existing navigation network.

And because the station communicates using standard AIS NMEA over TCP/IP, different compatible applications can potentially connect to it.

The Vision: Your Own AIS Picture, Wherever You Need It

This is where we believe the project becomes particularly interesting.

Imagine being able to create your own AIS monitoring point almost anywhere.

At a marina.
At a small port.
On your boat.
At a coastal house.
At a temporary work site.
At a remote shoreline.
Or simply somewhere where you want to know what vessels are moving nearby.

Install an AIS antenna.

Connect the antenna to the AIS station.

Power the station.

Connect your phone, tablet or computer to its Wi-Fi network.

And you have your own live AIS receiving point.

There is no requirement to depend on the coverage of somebody else’s AIS receiving station.
There is no requirement to depend on a commercial AIS website.

The station receives the AIS transmissions directly from vessels within radio range.

The concept can be summarized very simply:

“Your antenna.”

“Your receiver.”

“Your Wi-Fi.”

“Your AIS data.”

Pilot Plug can turn that data into a live vessel display, while other compatible applications can use exactly the same network AIS stream.

This changes the question from:

“Is AIS coverage available here?”

to:

“Can I install my own AIS receiver here?”

If the answer is yes, then you can potentially create your own local AIS coverage.

Examples of What This Could Enable

Consider a small marina.

It may not require a sophisticated vessel traffic management installation.

But an AIS antenna mounted in a good position, connected to a small local station, could provide the marina office with a live picture of AIS-equipped vessels around the entrance and surrounding waters.

Or consider a boat owner.

Instead of installing another dedicated navigation display, the owner could connect an existing Android tablet to the station’s Wi-Fi and receive live AIS information.

A coastal property owner could install an antenna at height and create a private AIS monitoring point for passing traffic.

A survey team or marine contractor could temporarily deploy a station close to a working area.

Once the work is finished, the station could simply be moved somewhere else.

The concept is portable because the infrastructure can travel with the user.

AIS Range Still Depends on Radio Physics

Naturally, creating your own station does not mean unlimited AIS coverage.

AIS operates on VHF frequencies.

Reception range therefore depends heavily on:

* antenna height;
* antenna quality;
* receiver installation;
* surrounding terrain;
* buildings and obstructions;
* vessel antenna height;
* local radio conditions.

A low antenna placed inside a building will not perform like an antenna installed high above an unobstructed shoreline.

The project does not change those basic radio principles.

What it does change is who controls the receiving station.

Where AIS signals can be received, the user can create the receiving point.

A Small Independent AIS Ecosystem

The final architecture is deliberately simple:

“AIS antenna”

↓

“AIS receiver”

↓

“Raspberry Pi AIS station”

↓

“Private 5 GHz Wi-Fi”

↓

“TCP AIS stream”

↓

“Pilot Plug or another compatible application”

There is something attractive about that simplicity.

The system does not need to know where an internet server is located.

It does not need somebody else’s receiving infrastructure.

It does not need a cloud account to continue operating.

The AIS radio signal arrives at the antenna and travels only a few metres through the station before appearing on the user’s screen.

That creates a small, independent AIS ecosystem.

Conclusion

What started as another experiment within the Pilot Plug project has now become a fully working and tested local AIS station.

The station successfully receives live AIS transmissions, distributes standard AIS NMEA data over TCP/IP, creates its own 5 GHz Wi-Fi network and supplies live vessel information directly to Pilot Plug.

It also operates with other compatible network AIS software in principle because the output remains based on standard AIS/NMEA rather than a proprietary protocol.

The project is therefore no longer simply an idea.

It is a working system.

And perhaps the most interesting part is not the hardware itself.

It is the possibility the hardware creates: