Find fields, depth and photos

What is saved with a find?

A find is a record you create inside a hunt. The shared iOS and Android record contains the following fields. A field being present in the data format does not mean it is a separately editable control.

Identity: documentID, routeID

A stable find identifier and the identifier of its owning hunt. These keep edits and associated images connected to the record.

Name: name

The title you give the find. It is not an app-generated object identification.

Notes: notes

Your free-text description or context. Details without dedicated fields can be written here, but are not turned into separately calculated statistics.

Category: category

The selected category name, stored as text. Category-based views and achievements depend on that saved text.

Time: timeFound

A timestamp created by the find-logging workflow, not a timestamp received from your metal detector.

Position: coord

A coordinate record with latitude (lat), longitude (long) and its own time. The coordinate type also supports a prevPaused segment marker used by route tracking; that marker is not a measured find property.

Depth: depth, depthUnit

A whole-number depth entered by you and a saved unit of cm or in. Older records may have no recognised unit. Zero is treated as no recorded depth for depth statistics.

Photo state: hasImage, hasSecondImage

Flags describing confirmed uploaded images for the first and optional second photo slots. The actual image files are separate from the route/find record. Adding find photos requires Premium.

There are no dedicated shared find fields for detector model, coil model, target ID, monetary value, soil type or automatically measured depth. You can describe such details in notes; LuckyFind does not infer them from the detector.

Where do the find pin and time come from?

Tap Log Find while standing at the find location. Both platforms require a usable location fix and hold the coordinate from when the form opens, so walking away while filling it in does not move that new find pin to your later position.

The saved find time comes from creating the find in the logging workflow. On iOS the new item is created for the form; Android creates its saved find timestamp when saving. Neither should be treated as the exact instant the detector first signalled. The saved coordinate and find timestamps serve different purposes.

The pin inherits the limits of phone GPS. It can be offset from the actual object location, especially under cover or near buildings. See GPS filtering and route gaps.

Depth keeps its original unit

New depth entries store a number and unit together. Both platforms default to inches for US, Liberia and Myanmar regions and centimetres elsewhere. This depth rule is separate from the route-distance rule.

When the saved unit is known, the app can convert it for display and statistics. For example, a find saved as 10 inches represents 25.4 centimetres even if a later display rounds it. Changing region must not reinterpret an old number as though it had been recorded in the new unit.

A legacy record with a positive depth but no recognised unit is displayed as “unit unknown”. The app does not guess whether that number meant inches or centimetres. Such records are excluded from average-depth, deepest-find and depth-achievement calculations until a known-unit depth is saved.

These figures describe the depth you entered, not a calibrated measurement made by LuckyFind. See how depth statistics work.

Default and custom categories

The default category set represents Bottle Cap, Button, Coin, Jewelry, Pull Tab, Ring, Scrap Metal and Toy. Display labels may be translated. You can add your own reusable category names.

Removing a category from the reusable picker does not erase existing finds with that saved category. Because categories are stored as names rather than a language-independent object taxonomy, custom spellings and translated names can remain separate groups. The current Coin Hunter achievement also uses a text match.

Two photo slots, with Premium

LuckyFind Premium supports up to two photos per find, selected through the app's camera or photo-picking flow. The photos are separate image files, not image bytes embedded in the route's shared data fields.

The apps stage pending photo data locally for upload. Seeing a preview on the phone does not prove that the image reached cloud storage. The confirmed photo flags are updated after upload; an upload can need a later retry even when the find text is already saved.

Reconnect and allow backup work to finish before changing accounts, clearing app data or removing the app. If an upload needs attention, keep the existing record and use the available retry controls. An export does not include the photo files.