Axis ANVE common mistakes
Axis ANVE · Understand the traps and how to avoid them.
Calculating required network bandwidth from resolution and frame rate alone, ignoring compression codec, bitrate control mode, and scene complexity.
Candidates treat resolution as a direct proxy for bitrate, a habit carried over from still-image intuition, and forget that H.264/H.265 with VBR can vary bitrate by an order of magnitude for the same resolution.
What to do instead
For any bandwidth or storage question, first identify codec, bitrate mode (CBR vs VBR), and whether a target bitrate is given; only estimate from resolution when the question explicitly supplies a per-stream bitrate.
Confusing Lux ratings across cameras as directly comparable without checking the measurement conditions (shutter speed, gain, and whether the rating is colour or monochrome).
Marketing figures are quoted as single numbers, so candidates compare them at face value and pick the 'lower Lux' camera as more light-sensitive.
What to do instead
When comparing low-light capability, check that colour vs monochrome mode, exposure time, and gain settings match; treat a Lux figure without stated conditions as non-comparable.
Assuming a single PoE standard covers all powered devices and budgeting switch power per port rather than against the switch's total power budget.
Candidates memorise 'PoE delivers up to X watts' as one number and overlook the difference between 802.3af/at/bt classes and the aggregate budget of the switch.
What to do instead
For power questions, identify the PoE class of each device, sum the class maxima, and compare to the switch's total PoE budget, not just per-port capability.
Designing storage by multiplying camera bitrate by recording hours without accounting for retention of motion-triggered vs continuous recording, pre/post buffers, and RAID or filesystem overhead.
The simple multiplication feels complete and candidates skip the recording-mode assumption and the usable-capacity reduction from RAID.
What to do instead
State the recording mode explicitly, add buffer and overhead allowances, and apply the RAID usable-capacity factor before comparing to the required retention period.
Placing a camera and choosing its lens/lens angle without verifying that the required pixel density at the target distance meets the identification or recognition criterion.
Candidates select fields of view by aesthetic coverage rather than by pixels-per-metre at the object, and skip the DORI-style calculation.
What to do instead
Work backwards from the task (detect/observe/recognise/identify), compute required pixels per metre at the farthest target distance, then derive the needed resolution and lens angle.
Treating HTTPS or a secure protocol as sufficient on its own while leaving default credentials, open ports, or unencrypted streams in the design.
Candidates equate 'encrypted transport' with 'secure system' and stop checking the other layers of the hardening checklist.
What to do instead
Walk the full hardening list for any security question: credential change, least-privilege accounts, disabled unused services, signed firmware, network segmentation, and encrypted protocols together.
Ignoring the difference between edge recording and central recording when answering resilience questions, and assuming the NVR is always the single point of failure.
Candidates picture the default centralised topology and forget that on-board storage or redundant recording changes the failure analysis.
What to do instead
For resilience questions, explicitly list where recordings live, what happens on network loss, and whether automatic re-synchronisation to the central recorder is configured.
Mixing up device discovery and addressing mechanisms, e.g. expecting a camera on a different subnet to be found by a broadcast-based tool without routing or manual addressing.
Candidates learn one discovery tool and assume it works across any network layout, ignoring broadcast domain boundaries.
What to do instead
Before answering, identify whether the tool uses broadcast or a routed protocol, and whether the camera and host share a subnet; if not, plan manual addressing or a routed discovery method.
Answering product-selection questions from memory of a single familiar model instead of matching stated requirements (environment, light, resolution, analytics, power) to the correct product family.
Candidates anchor on the camera they have used and force-fit the requirement to it rather than eliminating families by specification.
What to do instead
For product questions, extract the hard requirements first and eliminate product families that fail any one of them; only then compare the survivors on softer criteria.
Skipping the verification step in a troubleshooting scenario and jumping to a fix, without confirming which layer (power, link, addressing, stream, client) actually failed.
Candidates recognise a familiar symptom and pattern-match to a remembered cause, bypassing the diagnostic sequence the question is testing.
What to do instead
For troubleshooting questions, order the checks from physical layer upward and pick the answer that describes the next diagnostic step, not the most likely final repair.