What an ESP32 can run and what a Zebra TC22 can run are two separate hardware questions, and they have different answers. An ESP32-class microcontroller runs small quantised models, from a few kilobytes up to a few hundred kilobytes, on its own CPU. A TC22 is an Android handheld. Its real inference budget, including whether an accelerator path is usable at all, has to be measured on the unit you deploy. A mixed camera fleet is a third problem. ONVIF conformance is self-declared and tied to one specific firmware version.
What an ESP32 and a Zebra TC22 can actually run
Size both devices by measured flash, RAM, latency and energy on the real hardware, not from the datasheet alone. Through the AI Porting & Deployment Pack, TechnoLynx frames the memory, power and latency budget for the specific sensing or scanning task, then simplifies, quantises and profiles the model on the actual ESP32 or TC22 under sustained operation.
How big a model fits on an ESP32 for soil or irrigation anomaly detection?
An ESP32 has enough capacity, as long as the model is a small classifier over extracted features and not a network fed raw time series. A 2026 deployment-oriented review of low-cost agricultural edge AI cites an 8-bit quantised network for irrigation anomaly detection with a 6.2 KB model footprint (Hernandez-Hidalgo et al., 2026). The same review describes microcontroller deployments as typically having RAM of a few hundred kilobytes and flash below 2 MB.
The models that fit are highly compact. A TensorFlow Lite Micro guide from IoT Digital Twin PLM works through a vibration autoencoder with 4,744 parameters, about 5.2 KB of int8 constants and 4,608 multiply-accumulates per inference. At that size the FFT and sampling pipeline cost more than the network. Feature extraction is what makes this fit: an Edge AI Engineer walkthrough reduces a 128×6 accelerometer window to 18 statistical features, which is 42 times smaller than the raw window.
Vision is where the variant matters. The IoT Digital Twin PLM guide says vibration, keyword spotting and small sensor classifiers run on any ESP32 variant, including the C3, while small vision models need the S3 or P4 to exceed a few frames per second. An ESP32-S3 TinyML guide from FSS gives realistic budgets on an S3 with PSRAM: 50 to 500 kB of INT8 weights in flash, a 30 to 300 kB tensor arena, and 5 to 150 ms per inference. It warns that anything above 200 ms means the model topology needs rethinking, not the hardware.
ESP32-S3 reference budgets (FSS guide, measured on ESP32-S3)
| Model | Weights | Tensor arena | Inference time |
|---|---|---|---|
| Accelerometer autoencoder (256×3 input) | 35 kB | 22 kB | 7 ms |
| Keyword spotter (49×40×1 input) | 80 kB | 64 kB | 19 ms |
| MobileNetV1 0.25×, 96×96 greyscale | 220 kB | 180 kB | 145 ms |
| Person detection, 96×96 | 250 kB | 200 kB | 175 ms |
The guide’s own diagnosis for a model that runs well above these numbers is unsupported ops falling back to reference implementations, an arena placed in slow memory, or a topology that defeats the vector unit. The 6.2 KB irrigation model cited above is smaller than any row in this table, and at that scale preprocessing dominates over inference.
Do you need a dedicated low-power ML accelerator next to the ESP32?
Not for sensor-class models: they run comfortably on the ESP32’s own CPU, on any variant including the C3. The original ESP32 already has up to 240 MHz Xtensa LX6 cores with DSP instructions, including a 40-bit MAC, according to Espressif’s datasheet. The FSS guide reports an accelerometer anomaly detector on the S3 using under 5% of one core, at 6 to 8 ms per window.
The costlier risk is whether Espressif’s optimised kernels are actually running. ESP-NN supports the ESP32-S3, ESP32-P4, ESP32 and ESP32-C3. The S3 and P4 get assembly kernels using vector or SIMD instructions, while the original ESP32 and the C3 get generic optimisations, so the speedups differ. In Espressif’s person-detection figures, the S3 takes 54 ms against 380 ms on the ESP32, both at 240 MHz. If ESP-NN is disabled or misconfigured, the code still runs and still gives correct answers, only far slower. That is why the IoT Digital Twin PLM guide calls silent fallback to reference kernels the single costliest misconfiguration. Espressif’s esp-tflite-micro benchmark table shows how large the gap is: the C3 goes from 3,355 ms to 426 ms with ESP-NN (about 8×) and the S3 from 2,300 ms to 54 ms (about 43×). The guide’s remedy is to log invoke time at boot and assert it against a budget in the factory test.
TensorFlow Lite Micro is not the only runtime either. Espressif’s ESP-DL adds a static memory planner that places layers across internal RAM and PSRAM, and it runs Conv2D and DepthwiseConv2D on both cores. Dedicated ML hardware is worth adding only after the simplified model, on the right variant with verified kernels, has been profiled and still misses its latency or power budget.
Is local inference cheaper in power than sending the raw data?
For the ESP32-S3 sensor nodes measured below, yes. When raw images or audio are sent, the radio is the expensive part. A 2025 benchmark of embedded CNN inference against data transmission on an ESP32-S3 (“Send Less, Save More”) found that on-device inference cut sensor-node energy by 1.7× to 6.9× compared with transmitting raw data, depending on transmission frequency, with an acceptable loss of accuracy. In that study, sending only the class index over LoRaWAN cost 35.23 to 176.77 µWh, depending on spreading factor. The best cellular option for a 20 KB image (MQTT over LTE-M with eDRX) averaged 590.98 µWh.
The saving depends on transmission frequency and network setup. The same authors attribute differences between LTE-M and NB-IoT mainly to network operator configuration. They also warn that TCP timeouts and reconnections in real deployments erode the efficiency they measured. Preprocessing can dominate, too: their audio model spent about 88% of its energy on MFCC creation and under 2.5% on inference. Sending only actionable results, rather than one message per cycle, saves more again. For an irrigation node, the comparison has to be made with your radio, duty cycle and gateway distance before any extra silicon is considered.
What memory, compute and battery does the Zebra TC22 really give you?
On paper, Zebra’s combined TC22/TC27 specification lists a Qualcomm 5430 hex-core CPU at 2.1 GHz running Android, with 6 GB RAM and 64 GB flash or 8 GB RAM and 128 GB flash. Batteries are 3,800 mAh (14.63 Wh) standard or 5,200 mAh (20.02 Wh) extended, with PowerPrecision real-time battery metrics. The rated operating temperature is -10 °C to 50 °C.
The TC22 specification sheet gives no sustained inference, thermal or battery-drain figures. Treat those as numbers to measure, not numbers to look up. TechnoLynx would profile power, thermal and latency under sustained operation, with the model running alongside the store apps. Zebra’s AI Data Capture SDK documentation also recommends running several models concurrently only on high-memory devices, which matters if the 6 GB unit is the one being bought.
Does the TC22 have an onboard NPU worth targeting?
The sources disagree, so the honest answer is that it has to be verified on the unit. Zebra’s AI Data Capture SDK documentation says Zebra mobile computers with Qualcomm 6 series and 5 series chips have NPUs, unlike those on 4 series chips. Read literally, that covers the TC22’s 5430. Cattura, a third-party app built on that SDK, lists the TC22 as a legacy device without a DSP and does not support it, yet includes a QCM5430 rugged phone (the EM45) among supported devices. Zebra’s statement is primary but made at chip-series level. Cattura’s names the TC22 specifically but describes one vendor’s support list. We would not read chip family as settling the question either way.
By default the SDK tries the DSP first, then the CPU, then the GPU, so where no DSP is available the model runs on the CPU. Zebra points users to the AI demo applications in the preloaded Showcase App to estimate performance for a use case. Timing those demos, and your own model, on the exact hardware revision is the check. If no accelerator path is active, the work becomes quantising and optimising for the CPU. Where the DSP is available, the SDK’s default BALANCED mode favours power efficiency for continuous detection, and BURST mode is supported only on select devices.
How much inference latency will store associates tolerate on a handheld scanner?
Acceptable scanner latency is a user-perception limit, and it has to be tested with associates doing real tasks. Jakob Nielsen’s response-time guidance (Nielsen Norman Group, from his 1993 Usability Engineering) describes three main time limits determined by human perceptual abilities. It notes that feedback during a delay matters most when response time is highly variable. Variability is the point for a scanner. So we would measure trigger-to-confirmation time at the tail, under the power mode and thermal state the device will actually be in, and judge it against associate testing, not a datasheet target.
Normalising a mixed ONVIF camera fleet before detection
The right abstraction is a normalisation layer between camera ingestion and the detection stage. It converts every vendor’s resolutions, codecs, orientation and metadata into one canonical stream and schema, so the detector never sees a vendor. TechnoLynx would build per-vendor adapters and a conformance gate in camera onboarding, so the detector only receives cameras that passed the gate or were given an adapter. The work starts from a catalogue of the fleet’s camera models, ONVIF profiles, firmware versions and the detector’s input requirements.
What layer hides ONVIF profile and vendor differences from the detector?
ONVIF compliance describes a feature set, not identical behaviour. The ONVIF Media2 specification itself says a device presents different profiles depending on its capabilities, and that the set of available profiles can change dynamically. The specification also leaves room for variation. If the RateControl structure is missing, rate control is undefined and vendor-specific. A 90-degree rotation swaps encoded width and height. Changing a video source mode can change which aspect ratios and frame rates are offered, and the behaviour after the change is not defined. A device may also adapt bounds values without returning an error.
Profiles narrow the variation without removing it. ONVIF defines Profile T as covering H.264 and H.265 streaming, imaging settings and alarm events, with on-screen display and metadata streaming mandatory for devices. iFactory calls profile mismatches the number-one silent cause of a retrofit that only “half works”. In its summary, Profile S is the H.264 baseline almost every recent IP camera supports, and Profile T is what a modern AI vision stack asks for. Production computer vision at scale does not inherit the reliability of the demo.
What the normalisation layer has to absorb
| Difference across cameras | Where it comes from | What the canonical stream fixes |
|---|---|---|
| Codec (H.264, H.265, JPEG snapshots) | Profile S versus Profile T support; encoder configuration | One decoded pixel format at the detector input |
| Resolution, aspect ratio, rotation | Video source modes and Bounds/Rotate settings | Fixed input dimensions and orientation, with the transform recorded |
| Frame rate and rate control | Vendor-specific RateControl when absent | Resampled frame cadence with per-frame timestamps |
| View mode (fisheye, panorama, dewarped) | Media2 view-mode enumeration | A declared view type per stream, dewarped or rejected |
| Analytics metadata schema | Profile M versus vendor-specific events | One event and detection schema with a camera id |
| RTSP-only cameras with no full ONVIF | Closed-ecosystem vendors expose only a stream URL | Manually registered stream with the same canonical output |
Decoding H.265 from dozens of streams and resizing them costs compute and latency, so it needs a place in the budget next to the detector. A camera that fails conformance gets a vendor-specific adapter inside the layer, never a special case in the detection code.
How do you validate a camera’s real ONVIF conformance before onboarding?
ONVIF provides conformance test specifications and a Device Test Tool to increase confidence in conformance claims. Under ONVIF’s own rules, though, passing them is not proof. The ONVIF Conformance Process Specification v5.0 (effective November 2019) describes conformance as a self-declaration scheme by the member. It also states that the test specification and test tools cover only a subset of the interface specification, and will not cover every service, feature or fault scenario. Passing the Device Test Tool is therefore a necessary but not sufficient condition for conformance. The member alone is responsible for proper implementation, and the tools do not guarantee complete conformance.
Firmware is the other trap. ONVIF ties conformance to a product’s specific firmware or software version. An installed camera counts as conformant only if its firmware matches the version listed in the Conformant Products database. Members must submit new conformance documents when hardware or software changes affect ONVIF functionality. A firmware update that was never re-declared therefore sits outside the original claim, so every update calls for a fresh test.
The test specifications show what black-box checks cover. They check that GetProfile and GetProfiles agree, and that out-of-range MPEG4 encoder settings are rejected with a SOAP fault. The Profiles conformance test specification treats Profile S as unsupported if GetCapabilities, the NetworkVideoTransmitter discovery type, the Media service or real-time streaming is missing. What these tests do not do is run the camera for hours under load with your detector consuming it.
Camera onboarding gate, in order
- Record the model, hardware revision and firmware version, and check them against ONVIF’s Conformant Products database.
- Check which profiles the datasheet declares, not the marketing page.
- Run the ONVIF Device Test Tool for the claimed profiles on that exact firmware.
- Query encoder options, view mode and metadata configuration, and map any deviations to an adapter in the normalisation layer.
- Run end-to-end detection accuracy checks per camera model on the normalised output.
- Repeat steps 1 to 5 after every firmware update before the camera returns to the detection pool.
When does a mixed fleet need per-camera intrinsic calibration?
A mixed fleet needs per-camera intrinsic calibration as soon as anything downstream uses geometry: measuring sizes, mapping detections to floor positions, counting within zones near the frame edge, or fusing views across cameras. Intrinsic parameters such as focal length and optical centre are specific to one camera, according to OpenCV’s calibration documentation. The resulting camera matrix is unique to that camera and can be reused on its later images. Radial distortion bends straight lines and grows the farther a point is from the image centre. For a detector that only classifies objects near the centre of a mildly distorting lens, training on varied camera data may be enough, and calibration can wait.
A 2026 paper on automatic reproducible intrinsic calibration notes that intrinsics are calibrated once and then held fixed, so a calibration error recurs in every downstream application as a systematic geometric bias. Its authors note that systematic error comes from corner extraction under motion blur, steep incidence angles and low resolution. They show that filtering out such views in two stages reduced held-out error from 0.419 px to 0.316 px, a 25% reduction. OpenCV recommends at least 10 calibration pattern images and uses reprojection error, closer to zero being better, as the accuracy check. Calibration is the last step of normalisation: undistortion in the ingest layer means the detector sees geometrically consistent frames whichever lens produced them. Our explainer on intrinsic camera parameters covers the matrix and distortion model itself. Placing cameras relative to each other is a separate problem, covered in our guide to extrinsic calibration.
Who can profile our edge devices and onboard a mixed camera fleet?
TechnoLynx establishes what your ESP32 or TC22 can actually run and conformance-tests cameras before they feed your detector, as part of the retail computer vision systems it builds. For the ESP32 or TC22, the AI Porting & Deployment Pack frames the memory, power and latency budget, simplifies and quantises candidate models with TensorFlow Lite Micro, Edge Impulse or the device’s accelerator toolchain, and profiles them on the device under sustained operation. It then iterates on the edge-versus-cloud split. Where the question is which AI hardware to buy, LynxBenchAI is the measurement tool TechnoLynx points to. Its published results compare devices; profiling your own model on your own unit stays a separate step.
This work does not suit a team that wants an off-the-shelf video management system or a hardware supplier’s bundled analytics. Those buyers are better served by the vendor and a systems integrator. Bringing in a specialist mainly makes sense when the fleet is large, the firmware mix keeps changing, or a pilot has already failed on hardware it was never profiled on.
FAQ
Is RTSP the same as ONVIF?
No, they are different things. In iFactory’s summary, ONVIF is a management standard that tells software how to find and configure cameras, while RTSP is the streaming protocol that carries the video. A camera that exposes only RTSP can still feed inference, with its stream URL added manually instead of through auto-discovery.
What is latency in inference?
Inference latency is the time from a model receiving an input to producing its output. On a device, preprocessing counts too: for audio and vibration it is often larger than the inference call itself.
