Two practical hardware architectures for locating containers between arrival and departure

Ports and open storage yards do not have a simple tracking problem. A container may move several times, sit beneath other units, and leave days or weeks later. The operations team still needs to answer one question: where is it now?

That sounds like a job for GPS. Sometimes it is. Yet dense steel stacks can block or reflect satellite signals, and frequent GNSS fixes consume more power. Bluetooth can reduce device cost and extend battery life, but received signal strength, or RSSI, estimates proximity rather than exact distance. ^{(1) (2)} 

For container yard tracking, we see two practical hardware architectures:

1. A Cat-1 GNSS tracker attached to each container.
2. UM Farol Bluetooth on each container, paired with a Gateway Bluetooth on the handling crane.

Both can work. They answer slightly different operational questions, though, and that distinction matters more than the headline accuracy figure.

Start With the Location Event You Actually Need

“Real-time location” can mean several things. Do you need a fresh coordinate every few minutes, or is the last confirmed placement enough while a container remains stationary? Must the system identify the row, bay, and vertical tier? Does tracking continue after the container leaves?

The answers determine the architecture. A tracker attached to the container can continue operating beyond the yard. A crane-based Bluetooth design instead records where the crane released the container and treats that position as valid until the next move.

That second model is closer to event-based inventory than continuous positioning. We think that is often a strength. The location changes when the crane moves the container, so the placement event is what matters. This fits the wider shift toward structured whereabouts and operational events reflected in the DCSA Track & Trace standard. ⁽³⁾ 

Option 1: Cat-1 GNSS Tracking on Every Container

The first architecture assigns one Lansitec Rastreador de contêineres Cat-1 to every container. The device obtains a GNSS position and sends the data directly to the customer’s server through an LTE Cat-1 network using MQTT, HTTP(S), TCP, or UDP.

O Rastreador de contêineres Cat-1, part number 100-00C11, combines multi-constellation GNSS, Bluetooth 5.0, a 3D accelerometer, tamper detection, vibration monitoring, and an IP68 enclosure. Two 4,000 mAh Li/SOCl2 batteries provide 8,000 mAh in total. Configurable reporting helps balance location freshness against energy use.

Why movement-based reporting matters

A container normally spends more time stationary than moving. The accelerometer lets the application request a position when movement starts or stops, then reduce reporting during storage.

The preliminary recommendation uses a four-hour interval to preserve battery life. The final setting should follow a pilot because movement frequency, GNSS fix time, cellular signal quality, retries, temperature, and heartbeat policy all affect consumption.

Open-sky accuracy is not yard-wide accuracy

The catalog specifies GNSS accuracy below 2.5 m CEP. That is a device specification, not a yard-wide promise. GPS.gov notes that signal blockage and multipath reflections reduce accuracy near large structures. ⁽¹⁾ Steel stacks create the same concern.

In clear sky, the tracker may produce a precise fix. Between high rows or beneath stacked containers, it may return a weaker result or no fresh fix. Cat-1 may still carry data there, but a cellular link cannot replace a missing satellite measurement.

A sensible application should therefore preserve the last reliable movement or stop position, show the age and quality of the fix, and avoid presenting an old coordinate as a new measurement.

Mounting and security

The correspondence proposes removable magnetic mounting for fast deployment, with screw mounting where theft or accidental removal presents a higher risk. The tracker also supports tamper detection, allowing the server to raise an alert if someone removes the device.

A quick-release mount speeds assignment and reuse, while a fixed mount improves security. In both cases, the operating procedure must associate the tracker ID with the container ID.

Option 2: Record Container Placement Through the Crane

The second architecture changes the logic. Each container carries a B005 Farol Bluetooth, while each crane carries a LoRaWAN Gateway Bluetooth. The gateway listens for the beacon during handling and forwards observations to a LoRaWAN network gateway, which sends the data to the customer’s server.

O B005, part number 100-02395, has an IP68 enclosure, 2,000 mAh total battery capacity, and a 100 ms to 10 second advertising interval. At 0 dBm and a one-second interval, the catalog rates it for 119 months with an accelerometer or 124 months without one, roughly ten years under the stated conditions.

For the crane, the LoRaWAN Macro Gateway Bluetooth is the most obvious catalog candidate for review because it combines an IP66 enclosure with a 38,000 mAh battery. The final model and mounting arrangement still depend on power availability, environment, reporting policy, and the type of crane.

How the placement event is calculated

As the crane moves a container, the gateway receives its beacon ID and RSSI values. The application combines that data with the crane’s known movement or orientation. When the crane releases the container and moves away, the system records the placement event.

This avoids repeated GNSS fixes and records a useful operational truth: “crane X placed container Y in zone Z at this time.”

It does not produce an exact coordinate by itself. RSSI indicates whether a transmitter is nearby and approximately how close it may be.^[2] Steel surfaces, antenna orientation, obstruction, interference, and gateway position affect the result. Treat the proposed 15 to 20 m range as a pilot target, not a guarantee.

The crane data is essential

The gateway does not know the crane’s rotation angle, trolley position, travel coordinate, or hoist height. The integration must obtain that data from the crane control system, a separate positioning source, or another sensor.

RSSI also cannot reliably identify the vertical tier. If stack height matters, the application needs hoist-height data or another validated vertical input.

Plan for beacon density and LoRaWAN coverage

A crane may hear many faróis. The application must identify the handled container and filter unrelated advertisements. The Macro Gateway Bluetooth catalog lists 105 faróis, with up to 15 beacon messages in one LoRaWAN packet at SF9, and advises contacting Lansitec when more are needed.

Before scaling, test simultaneous beacon density, Leitura Bluetooth settings, edge filters, LoRaWAN payload size, duty-cycle constraints, packet loss, and coverage across the crane’s route.

The architecture also needs a suitable LoRaWAN network gateway. Lansitec provides tracking hardware, not the end-user platform. The customer or integrator must map messages to container IDs, yard coordinates, movement events, and the interface.

GNSS and Crane-Based Bluetooth Compared

Decision factor	Cat-1 GNSS tracker	Crane-mounted Gateway Bluetooth
Primary output	Independent position reports from each container	A placement zone or handling event derived during crane movement
Infrastructure	Cellular coverage and a server endpoint	Beacon per container, gateway per crane, LoRaWAN coverage, and crane-position data
Tracking beyond the yard	Yes, where the configured Cat-1 service is available	No, unless the destination has compatible infrastructure
Position behavior in dense stacks	GNSS quality may fall because of blockage and reflections	RSSI remains approximate and requires calibration in the steel environment
Vertical tier	Not reliably determined by standard GNSS	Requires crane hoist-height data or another vertical input
Container-side battery strategy	Movement-aware GNSS and configurable reporting	Low-power beacon advertising, rated at roughly ten years under specified conditions
Security features	Tamper, movement, and vibration detection	Attachment procedure and beacon association handled by the deployment workflow
Melhor ajuste	Independent, wider-area tracking with fewer yard integrations	Cost-sensitive yard inventory where cranes control every placement event

Which Architecture Should You Choose?

Choose Cat-1 GNSS when containers must remain visible outside the yard, crane telemetry is unavailable, or each container must report independently. It is the simpler architecture, although container-side cost and energy use are higher.

Choose crane-based Bluetooth for yard inventory when every move passes through an instrumented crane and crane-position data is available. It offers lighter container hardware and long beacon life, but needs more integration and calibration.

A hybrid can use Cat-1 GNSS for high-value or outbound assets and Bluetooth placement records for the wider yard. The software must make the two workflows and confidence levels clear.

Pilot Before You Scale

We would not size either design from a desk. A short yard pilot should answer four questions:

1. How often does GNSS produce a usable fix in open lanes, beside stacks, and beneath stacked containers?
2. Can the crane workflow identify the handled beacon without confusing it with nearby units?
3. Can the available crane data resolve the required row, bay, and tier?
4. Do cellular and LoRaWAN links cover the full maneuvering area with acceptable retries and latency?

The pilot should also measure battery consumption under real reporting behavior. Once those results are available, the team can set defensible accuracy, latency, and battery targets instead of relying on one ideal laboratory number.

Referências e leitura complementar:

1. GPS.gov, GPS Accuracy
2. Bluetooth SIG, Enhancing Bluetooth Location Services with Direction Finding
3. Digital Container Shipping Association, Track & Trace Standard