Where the time actually goes
A drone survey day ends with several cards or drives of imagery, LiDAR and flight logs. Before an engineer or analyst can use any of it, the data passes through four stages. Teams usually notice the upload, but the other stages add their own delays.
| Stage | What slows it down | What helps |
|---|---|---|
| Offload from cards | Slow card readers, USB 2 drives, copying one card at a time | Fast card readers, an NVMe SSD, a checksum on every copy |
| Upload from the site | Weak cellular or satellite links, thousands of files, restarts after a dropped connection | Resumable transfer, sending the whole capture as one package, uploading overnight |
| Arrival and checks | Nobody confirms the data arrived complete until processing fails | A file-count and size check on arrival, before the cards are cleared |
| Delivery onward | Sending large outputs to clients, engineers or pole owners on their systems | Links recipients can open in a browser without an account, with a download record |
How long should the upload take?
Start with arithmetic. Multiply the dataset size in gigabytes by 8,000 to get megabits, then divide by your sustained upload speed in megabits per second. The answer is the best case in seconds, assuming the link runs flat out the whole time.
| Capture size | 10 Mbps upload | 50 Mbps upload | 200 Mbps upload |
|---|---|---|---|
| 50 GB | about 11 hours | about 2.2 hours | about 33 minutes |
| 200 GB | about 44 hours | about 9 hours | about 2.2 hours |
| 500 GB | about 4.6 days | about 22 hours | about 5.6 hours |
If the floor is already longer than your deadline allows, no software will fix it. Reduce what you send from the field, find a faster link, or ship a drive. If the floor fits but real uploads take much longer, the transfer method is the problem worth fixing.
Why field uploads are slower than the arithmetic
- Latency and packet loss: cellular, satellite and rural links have long round trips and drop packets. Standard TCP-based uploads cut their speed every time a packet is lost and recover slowly, so they use only a fraction of the link.
- Thousands of files: a capture is many images, tiles or point-cloud chunks. Tools that handle each file separately pay a delay per file, which adds up to hours on a long link.
- Restarts: if the connection drops and the upload starts again from the beginning, every interruption costs the time already spent.
- Shared connections: a hotel or site network shared with others gives you an unpredictable share of its upload capacity.
The first three are properties of the transfer method, not the link. That is why the same connection can feel unusable with one tool and workable with another.
The four ways teams move a capture home
| Option | Works well when | Watch out for |
|---|---|---|
| Ship or carry drives | The dataset is far larger than the link can move before the deadline | Days in transit, lost or damaged drives, no copy in the office until it arrives |
| Upload to a cloud drive or your processing platform's uploader | Captures are modest, the link is decent, and processing already runs in that platform | Some uploaders restart after a dropped connection, per-file overhead on large folders, file-size limits on some plans |
| Folder sync tools | The same machines exchange files continuously | Sync is not a delivery: it is harder to tell when a specific capture is complete |
| Accelerated transfer to your own server | Captures are large, links are poor, and you need a clear record that each capture arrived | Needs a server or cloud machine you control at the receiving end |
Many teams combine them: accelerated transfer for the daily capture, drives for the occasional dataset too large for any link, and their processing platform's own uploader once the data is in the office.
A field-to-office routine that holds up
- 1Offload each card to a fast SSD at the end of the flight day, and keep the cards untouched.
- 2Check the copy: compare file counts and total size between the card and the SSD.
- 3Send the whole capture folder as one package, with the folder structure kept, so processing finds files where it expects them.
- 4Start the upload from the site, the truck or the hotel as soon as the copy is checked, and let it run overnight if needed.
- 5Use a method that resumes after a dropped connection instead of starting again.
- 6Have the office confirm the file count and total size on arrival before anyone clears a card.
- 7Record when the capture arrived and who received it, so the delivery date can be shown to the client.
Where Ripton Cloud fits
Ripton Desktop, on macOS, Windows and Linux, sends a capture folder as one encrypted package to a Ripton node at your office or in your own cloud account. The protocol is UDP-based with its own rate control and retransmission, designed for high-latency, lossy links. If the connection drops, the package resumes from where it stopped. Finished deliverables can go to clients and engineers as packages they download from a browser, without an account, with a record of the download.
Ripton Cloud moves the data. Photogrammetry, point-cloud processing and GIS publishing stay in the tools you already use.
Test it on your own route
| Bring | Why it matters |
|---|---|
| One real capture: total size and file count | A single test file hides the per-file overhead of a full capture |
| Where the upload starts: site, truck, hotel or regional office | The field link is what you are trying to improve |
| Your current method and how long it takes | The baseline the test is compared against |
| Where the data must arrive and who needs it next | Defines when the handoff counts as complete |
Run the same capture both ways on the same day and compare the time, the number of restarts and whether the office could confirm the data arrived complete.