God's Eye View: what's live, what's delayed, and what's simulated?

In God's Eye View a plane glides across the globe, cars stream through a city and a rocket climbs to orbit. It all moves, so it all feels live. Some of it is close to live, some of it is deliberately shown a little late, and some of it is animation. Prompted by Bilawal Sidhu's demonstration with Matt Wolfe, we examined how the public version handles flight positions, camera images and animated traffic. We read the code and ran three small tests of our own.

This is the fourth article in our series on God's Eye View, after what it does and what you need and what you may share in screenshots and video.

Three different things that all look "live"

When something moves on screen, three separate clocks are involved. We keep them apart in this article.

• How often the app asks. The app requests new data on a schedule, for example every 30 seconds.
• How old the source's answer is. The provider may answer with a position from half a second ago, or a camera image that last changed minutes ago. Code cannot tell you this. You have to measure it.
• What the app does in between. To avoid jumpy movement, an app can wait, interpolate between two known points, or animate something that was never measured at all.

Smooth movement alone tells you none of these timings.

Planes: real positions, shown one step behind

In the video Matt Wolfe asks how up to the minute the planes are. Sidhu's answer, in our paraphrase: the display runs one step behind, so that planes can follow a smooth path (around 8:40). That matches what we found.

The app asks for civil flights every 30 seconds and for military aircraft every 15. It then draws every aircraft one interval behind real time: the setting is called RENDER_DELAY_SEC and is 30 for civil flights and 15 for military ones. With two known positions in hand the app can glide a plane from one to the other instead of guessing where it is now. The project's README says so openly: "Live feeds arrive every 15–30s; the globe renders one interval behind real time and interpolates between known fixes. Dead reckoning fills the gaps." Dead reckoning means estimating from the last known speed and direction. The code limits it to short gaps: one minute as a rule, five minutes at most.

So how old is the source itself? We tested the military layer, which uses adsb.lol only, for six minutes on 17 September 2026. The app received 26 answers, one about every 15 seconds, each with 415 to 444 aircraft.

Two numbers matter here, and they add up. Each answer says how long ago every position was last updated, counted back from the moment the answer was made. The middle value of that was 0.3 to 0.5 seconds. The answer itself then needs time to reach the browser. For 21 of the 26 answers, the two together put the typical position at about one second old on arrival, between 0.8 and 2.2 seconds. Every answer also contained positions of up to a minute old. These figures depend on our laptop's clock, which was within a tenth of a second of internet time when we checked it afterwards.

So in most of this short test the source was far fresher than the 15 seconds the app adds on purpose. That was not always the case. For the other 5 answers, the app's server passed on the same, older answer again, which made the typical position 15 to 45 seconds old on arrival. This happened in two spells of about half a minute. The app noticed. Its layer panel switched from "just now" to "STALE · adsb.lol · 18s ago", then 33 and 48 seconds. We did not cause that and cannot say why it happened. We can say the warning worked.

We did not enable the civil flights layer during this test. It uses the OpenSky Network, whose terms we describe in our third article. OpenSky replied briefly to our inquiry, but did not address the individual questions separately. The code shows that the app keeps OpenSky's answer for 9 seconds by default, and for up to 5 minutes when the free daily allowance runs low. It switches to adsb.lol when OpenSky's data is more than two minutes old. We did not measure any of that.

Some visual details are not based on measurements in the flight data used by this app. The cockpit view uses a fixed camera angle, and we found no pitch or roll data anywhere in the flight code. The 3D aircraft models turn with the plane's heading, and we found nothing in the code that banks them in a turn.

Cars: the dots are always animation

This is the layer where the picture is most convincing and least literal. In his own tour of the app, Wolfe describes the traffic layer as showing where the cars are driving right now (around 18:35). That is an understandable reading of what the screen shows. Earlier in the same video Sidhu explains what is behind it: TomTom supplies how busy each stretch of road is, and he colours the roads accordingly (around 10:55). Sidhu's description is the one the code supports.

No dot on the map is a real car, with or without a key. The README is plain about it: "Simulated vehicles on OSM roads. With TomTom, live flow speeds drive the simulation and congestion colors below ~8 km; individual vehicle positions are not live observations."

What is real and what is not:

The code describes each dot as placed "at a random position along the road" with "a randomized speed", and it pauses dots near the end of a road "to simulate stop-light behaviour".

The app does label this. Without a key it shows a banner, "SIMULATED — ADD TOMTOM KEY FOR LIVE", which you can see in our cover image. We do not have a TomTom key, so we did not test the live mode.

Our own test showed something else. Even simulated traffic needs real road data, and that comes from free community servers for OpenStreetMap. On the evening of 17 September 2026 those servers did not answer the app in any of our three attempts. The app reported "Road data temporarily unavailable" and drew no dots at all. That is why our cover image shows a label and no traffic.

Cameras: reloaded every 10 seconds, changed every few minutes

In the video Sidhu says that the public cameras in Austin deliver roughly one frame every ten minutes, and he limits that remark to Austin (around 10:27). We could not find a publishing interval for Austin anywhere in the project, so we measured.

First the app's side. When you select a camera, the app reloads its picture every 10 seconds, and every 60 seconds when idle. The small camera cards around the map reload every 3 to 10 minutes, depending on the provider. Only one provider has a documented publishing rhythm in the project: Finland's Fintraffic, at 600 seconds.

Then the source's side. On 17 September 2026 we asked the app for the same frames it shows, every 30 seconds for 30 minutes, for two cameras each in Austin, London and Finland. We kept only a fingerprint of each image file in memory, to see whether the file had changed. We stored no pictures and did not look at them.

We detected changes in the image files returned through the app roughly every five to ten minutes for five of the six sampled cameras. Between two changes, every check returned a file with the same fingerprint. At one reload every 10 seconds, that is about 30 reloads per change for Austin camera 2 and London camera 1, and about 60 for Finland.

It is worth being exact about what this does and does not show. A changed file tells us the provider served something different. It does not tell us when that image was captured, and we cannot rule out that a change was in the file's data and not in the scene. We also cannot see whether a cache between the camera and the app influenced the rhythm. So this is a measurement of how often the file changes, not of how old the picture is.

Finland matched the documented 600 seconds, which gives us some confidence in the method. For one Austin camera we detected no change in half an hour. We do not know whether it was frozen, under maintenance or simply slow. The project's own code notes a similar observation from July: in five minutes, a London camera republished once and an Austin one not at all.

Our roughly 5 minutes for one Austin camera differs from the roughly 10 minutes mentioned in the video. That does not make either number wrong. We sampled two cameras for half an hour, and a city can change its settings.

Two more things are worth knowing. The project states that frames are fetched when you look and are never stored, and the frame response we inspected was marked "no-store", an instruction not to keep a copy. And where a camera points is an estimate: the README calls the camera poses "estimated priors" that you can calibrate yourself.

Rockets and satellites: real events, calculated paths

The launches in the Space Missions view are real. They come from Launch Library 2, a public database of rocket launches. The path you see during a replay is not a recording. The project's documentation says Launch Library 2 "supplies launch context and event timing, not continuous ascent telemetry or live orbital state". The app draws a plausible climb and then a ring at a standard height for the type of orbit.

Sidhu says as much in the video, where he calls the trajectory approximate (around 12:50). More importantly, the app says it on screen. In our screenshot the mission panel reads "ASCENT PATH · RECONSTRUCTED ESTIMATE" and the label on the globe reads "PROJECTED ORBIT".

Satellites work differently again. This app calculates satellite positions from published orbital data rather than receiving continuous position reports. It takes that data from CelesTrak and works out each position itself, many times a second, with a standard model. The orbit data is refreshed every six hours. That is normal practice for satellite trackers.

How to read the screen

• Open the data layers panel. Every layer shows its source and how long ago it was updated, such as "CelesTrak · 44s ago". That line tells you more than the movement does.
• Look for the words the app uses itself: SIMULATED, STALE, UNAVAILABLE, ESTIMATE, PROJECTED. In our tests they appeared when they should.
• Treat movement between updates as drawing, not as data. A plane gliding smoothly is the app connecting two known points.
• Treat cars as a weather map for traffic. Colour and density can be real. Individual dots never are.
• Do not read a reload as a fresh picture. A recent reload does not establish when the image was captured.
• Be careful with words like "real time" in a caption or a video. The app intentionally delays rendering by 30 seconds for civil flights and 15 seconds for military flights. Data freshness can vary further. For cameras, "a still from a public camera" says enough.

How we checked

We reviewed the project's README, DATA_SOURCES.md and source code at commit 531ef52, and link to the files we quote. Settings in code can change with any update.

For the video, He Built The Ultimate Spy Tool (Free and Open-Source), published by Matt Wolfe on 16 September 2026, we worked from YouTube's automatically generated captions. The video has no other caption track. Automatic captions contain errors, so we do not quote them. We describe what is said in our own words and link to the moment; the timestamps are approximate. We worked out who is speaking from what is said, from the video description, in which Wolfe writes that he walks through the installation himself, and, for that part, from the picture, which shows a single presenter operating the app. Before publishing we listened to the five moments we refer to and checked both the speaker and the substance. Where a remark is Wolfe's and not Sidhu's, we say so.

Our tests ran on 17 September 2026 on the Windows laptop described in our first article. For the flight test we enabled only the military layer for six minutes. For each answer we recorded two values: the age the feed reports for each position ("seen_pos", counted back from the moment the answer was made) and the time between that moment and its arrival in our browser. We add the two. The second value relies on our laptop's clock. For the camera test we requested six cameras through the app every 30 seconds for 30 minutes and compared fingerprints of the image files; no picture was stored or viewed. A change within 30 seconds of another would have been counted once. Before that test we read the terms of the three camera providers: the City of Austin's open data terms, Transport for London's open data terms and Fintraffic's CC BY 4.0 licence. These are observations from one evening, two cameras per provider and one laptop, not a benchmark.

The screenshots were captured by us on 17 September 2026, without configured API keys. They have only been resized, except for the two details, which are cropped from the cover screenshot. The charts were drawn by us from our own measurement files, and the two diagrams are our own explanations; none of the images is AI-generated. Provider names in the captions were taken from the app's Data attribution panel.

Our review covers flights, street traffic, cameras, launches and satellites. It does not cover the civil flights layer in practice, the TomTom live mode, vessels, or the event reconstructions shown in the video. This is an editorial review of the sources we consulted and the tests we ran.