Knowledge base · On site
Working offline on site: what has to keep working without a signal
In short
- Signal often drops out in basements, sheds and unfinished developments, and a bar that loads nothing is worse than no signal.
- As long as the model is already on the device, viewing, measuring, checking layers and noting comments keep working without a connection.
- An old copy looks the same as a fresh copy, so it helps to sync before leaving and check the version shown.
You step into the basement to check the pipework, or walk to the back of the shed where the roof panels are stacked, and the signal bar on your screen drops from four bars to one, then to nothing. The screen you were just using to check where a service opening goes now sits on a loading icon. You wait, tap the screen again as if that helps, and put the device down.
That moment happens on most sites a few times a day, and it is rarely dramatic. You already know the spot, you know it always struggles there, and most of the time you manage with what you already know. But sometimes it drops out at the exact moment you need a dimension you do not know off the top of your head, and then a small inconvenience suddenly becomes a real delay.
Getting signal everywhere on a site is a fight you will not win. What you do control is what keeps working the moment the connection drops, and what can safely wait until it is back.
Where the signal drops out
A basement or underground car park is the classic case: concrete all around and above your head, and the signal simply cannot get through. A service shaft is no better. In a shed with a metal roof and a steel frame, the same principle plays out at a different scale: the building itself blocks the signal. Facade insulation with a reflective foil does something similar, sometimes acting like a cage around the space behind it. On a housing development or an industrial estate still being built, there is often simply no decent coverage. And the site hut’s wifi reaches, at best, halfway across the site; beyond that you are back to whatever the mobile network gives you, or nothing at all.
More treacherous than no signal at all is one bar that shows but carries nothing. Your device thinks it is connected, tries to load and hangs, while you wait for something that never arrives. It is better for a device to fall back on its local copy straight away, rather than keep trying endlessly.
What has to keep working regardless
Without a connection you need to at least open the model and navigate it, switch layers on and off to see what sits underneath a finish, tap an element and see what it is, pull up a dimension, view the matching drawing, and record a comment or a photo to pass on later. That is the core, and it has to hold regardless of what the network is doing at that moment.
There is a condition attached to that. All of it only works if the model is already on your device before you head onto the site. A device that only fetches the model once you are on site is, at the moment you need it, as useless as no device at all. With Field-Viewer, viewing, measuring and noting a comment all work without a connection, and as soon as wifi or a mobile network returns, everything syncs automatically. What else happens on a screen like that is covered on the page about the viewer itself.
What can safely wait
Not everything has to happen straight away. The distinction that matters here is simple: looking things up has to happen now, exchanging data can wait. Sending your measurements and comments back can wait until you have a signal again. Fetching a new version can wait. Giving someone access to a project can wait. And a project you have never opened before is simply not something you would download without a signal.
What you should not expect from working offline is that you suddenly see, on site, a change the drawing office made an hour earlier. That change waits until there is a connection again, and as long as there is not, you simply work with what was already on your device.
Knowing which version you are looking at
Without a connection you are, by definition, looking at a copy, never at the original. That in itself is not a problem, as long as you know which copy it is. The screen therefore needs to show which version it is displaying and when it was last fetched, because an old copy looks, at first glance, the same as a fresh one.
The habit that goes with this is not complicated: sync before you leave, using the wifi at the office or the workshop, not in the car on the way there with whatever mobile signal you happen to catch. And if you are unsure on site about a detail that really matters, it is better to make a quick call, even if the screen looks convincing. A convincing screen is no guarantee that it is correct, it is only a guarantee that it has loaded.
The arrangements that go with it
Technology only solves half of this, the other half sits in arrangements between the drawing office and the team. Someone has to make sure the right project is on the device before the team leaves, not en route. The drawing office needs to know when it publishes, so a morning sync delivers something. For an urgent change during the day, a phone call is still needed: an offline team only receives it once the device reconnects, and the drawing office has no automatic way of knowing whether that has happened. Someone also has to check afterwards whether a sync succeeded, so measurements and comments do not sit on a device for a week unseen.
Then there is the device that has not synced in a while, belonging to a colleague on leave, or a tablet left in a cupboard. Taking that device along without syncing it first sends someone onto the site with a project that is long out of date. How these tasks get divided between the drawing office and the site on an ordinary day is described in a day on site with the model to hand.
What working offline does not solve
Working offline does not bring an outdated model up to date. All it does is let you carry on without a signal with what you already have, which is exactly why syncing before you leave and a visible version matter. Whatever was not in the model at the moment you left is not there offline either, no matter how smoothly the device otherwise runs.
Signal on a site is, in the end, something you learn to live with, not a fault you fix with an extra device in the hut. What you do control is what goes out in the morning: the right project on the device, with the version visible alongside it. The rest of the day depends on that.