Thermal imaging camera with LabVIEW on a PC: your interface options

A thermal imaging camera is the quickest way to add temperature mapping to a LabVIEW test station, but the interface decides the project before the first VI is written. Phone-attachment thermal modules look inexpensive until you count the bridge board, the glue firmware and the packaging they need. A camera with a documented GigE Vision or USB3 Vision interface opens in LabVIEW like any other machine-vision camera. This guide gives you the decision rule, the bandwidth arithmetic that sizes the PC side, the DLL route for SDK-only cameras, and the checks to run before you order. It assumes NI's Vision Acquisition driver stack, whose acquisition API is NI-IMAQdx, running on a Windows PC.

Can a phone-attachment thermal camera work with LabVIEW on a PC?

Not through any driver you can install. These modules ship neither GigE Vision nor USB3 Vision firmware and expose no GenICam feature map, so NI-IMAQdx finds nothing to open. You would be writing a reverse-engineered USB driver before your first frame.

The consumer modules were built to be driven by a phone app over a proprietary USB protocol. The connector fits your PC, but nothing on the PC side speaks the language. Some bridge boards present the sensor as a UVC webcam, and microcontroller boards read the module's SPI or I2C port; both are glue projects rather than camera interfaces.

In Measurement & Automation Explorer nothing enumerates, so there is no discovery step, no feature list and no buffer to read. If the requirement is a thermal image inside LabVIEW this month, the phone module is the wrong first purchase. The interface line on the data sheet is what to shop for instead.

When does LabVIEW open a thermal camera directly?

Whenever the camera follows the GigE Vision or USB3 Vision standards: NI's Vision Acquisition driver, whose acquisition API is NI-IMAQdx, opens both with the same discovery and read calls. A compliant thermal camera appears in Measurement & Automation Explorer like any other machine-vision camera.

This is the point that decides your build: one NI-IMAQdx API acquires from GigE Vision and USB3 Vision cameras alike, which is why interface compliance is the buying criterion — the driver work is already done. Both standards carry the same GenICam feature description, so the same acquisition VIs set exposure and frame rate, select the pixel format and pull buffers, whichever transport sits underneath.

What lands in the buffer is the camera's native pixel data. For a thermal camera that means high-bit-depth counts, converted to temperature in your own code, as covered in Export high bitdepth grayscale images from thermal cameras.

One client holds the stream at a time on both transports, so close the vendor viewer before your VI opens the camera. The same one-client rule is described in GigE camera works in the vendor viewer but not in MAX.

What do you install and plug in for the direct path?

Three things: NI's Vision Acquisition Software, which installs the NI-IMAQdx driver alongside LabVIEW; a dedicated GigE network interface card or, for a USB3 camera, a real USB 3.0 port; and stable power from the camera's own supply specification.

Vision Acquisition Software registers the driver so cameras enumerate in Measurement & Automation Explorer, and the discovery wizard names the camera for your VIs to reference. If you are still weighing a driver against an SDK, Camera acquisition software compatibility: integration options compares the routes.

Put a GigE camera on its own adapter or a private subnet. Compliant cameras come up on a link-local 169.254.x.x address by default, and sharing an adapter with office traffic invites packet loss at high frame rates. For one thermal camera at roughly 33 MB/s the standard adapter driver is enough; the packet-optimized driver pays when frames grow or cameras multiply, as measured in GigE Vision high performance NIC driver: how much you gain.

If you hope to power the camera over its data cable, check the port first — Does my camera support PoE: check the port before you buy walks the check.

If the acquisition is headed for a real-time target rather than Windows, check NI's published compatibility list for USB3 Vision cameras and real-time targets first. It names the tested camera-and-driver combinations, and anything off the list is unsupported.

How much bandwidth does a 640 × 512 thermal camera need?

About 33 MB/s: a 640 × 512 frame at 16 bits per pixel is 655,360 bytes, and 50 of those frames per second is roughly 33 MB/s, under a third of the ~118 MB/s a dedicated GigE link delivers in practice.

Worked through: 640 × 512 = 327,680 pixels; at 16 bits, 2 bytes each, one frame is 655,360 bytes, about 0.66 MB; at 50 Hz the stream is 655,360 × 50 = 32,768,000 B/s, or 32.8 MB/s. The two-byte plan is deliberate: raw thermal counts are typically 14-bit values carried in a 16-bit word.

A dedicated GigE link moves about 118 MB/s of payload in practice, so this camera sits near 28 % utilization with headroom to spare. Two follow-on numbers: keep planned traffic under roughly 80 % of a link so retransmissions never surface. If you record continuously, size storage to the same 32.8 MB/s — about 118 GB per hour of disk. Double the resolution and the figure doubles; send 8-bit display data instead of counts and it halves.

What if the camera only ships an SDK instead of a standard interface?

Then LabVIEW talks to the vendor's DLL through the Call Library Function Node: you declare each function's prototype, allocate the frame buffers yourself and call the SDK's open-acquire-close sequence from a wrapper VI layer, exactly as you would from C.

It is a workable route, sometimes the only one. OEM modules and older industrial thermal cameras expose rich calibration APIs as C functions that LabVIEW calls like any other library. The mechanics — pointer types, buffer allocation, callback registration — are walked through in Call a camera SDK DLL from LabVIEW: callbacks, buffers and snap, and event-driven SDKs are bridged with a small wrapper DLL as shown in Camera SDK callback wrapper DLL for LabVIEW: bridge events with C.

Two failure modes cause most lost days. The first is a 32-bit DLL handed to 64-bit LabVIEW, diagnosed step by step in LabVIEW camera DLL load error: check the bitness first. The second is an SDK update that quietly changed a prototype, so pin the SDK version and re-run the wrapper tests after every update. Feeding SDK frames into a measurement loop is the subject of Integrate a thermal camera into a DAQ application via its SDK.

The trade is real: you own buffer lifetimes and error codes, and no standard keeps the feature set comparable between cameras.

Why does a webcam-style USB module lose the measurement?

Because the UVC webcam path delivers processed 8-bit video: the bridge chip has already applied its own gain and scene-based optimization, and the raw radiometric counts you need for temperature work never reach the PC, whichever software grabs the stream.

A UVC device enumerates as a webcam, and some module bridge boards deliberately present their sensor that way to keep drivers simple. What arrives is the module's finished picture: the onboard engine has normalized the scene, so a cold part beside a hot one renders the same shade after the internal stretch. Display-only streams also clip or scale bit depth, and without the calibration registers the counts carry no temperature meaning.

That is acceptable for a hot-spot indicator on an operator panel and useless for a tolerance check in test equipment. If the module has an SDK that exposes the raw radiometric stream, you are back on the DLL route of the previous section. Otherwise no PC-side software can recover what the bridge discarded.

Is a short-wave infrared camera the same as a thermal camera?

No: a short-wave infrared (SWIR) camera detects reflected light around 0.9-1.7 μm and usually needs a light source, while a long-wave infrared thermal camera detects heat the object itself emits in the 8-14 μm band, so the two solve different inspections even though LabVIEW opens both the same way.

LWIR thermal cameras use microbolometer detectors that respond to emitted heat, need no illumination and work through the atmosphere's long-wave transmission window. SWIR cameras use indium gallium arsenide sensors that respond to reflected light, so contrast comes from reflectance and your lighting. Where each detector family sits, CMOS through microbolometer, is laid out in Camera sensor technologies by spectral range: CMOS to microbolometer.

The practical consequences: thermal imaging reads surface temperature, while SWIR reads what visible light struggles with, such as the bruise and fungus contrast behind Detect bruising and fungus on vegetables with SWIR and NIR. Both exist as GigE machine-vision cameras, so every decision above applies to both; only the measurand changes.

Which thermal camera do you buy for LabVIEW?

Buy a camera whose data sheet names the interface explicitly as GigE Vision or USB3 Vision and whose pixel data is high-bit-depth rather than display-only, because that single line decides whether NI-IMAQdx opens it natively or you spend weeks writing DLL wrappers.

Match the part to the case:

The infrared cameras category covers the first three cases in that table. The LS-IRC-0044 is a 640 × 512 LWIR thermal camera streaming 50 Hz over GigE, with an 8-14 μm response, a C-mount lens interface and a 9-24 V DC supply, and it is the reference part for the bandwidth arithmetic above.

The LS-IRC-0016 is a 640 × 512 LWIR module with a USB3 interface, the shape that suits a bench PC with no spare network slot. The LS-IRC-0026 is a 0.5 MP GigE thermal imaging camera for general line use, and the Hikrobot MV-CI013-GS-NN is a 1.3 MP SWIR camera on an IMX990 sensor, 1/2-inch format, C-mount, fanless, the reflected-light case from the table.

The camera finder filters the range by interface, resolution and spectrum, and the configurator walks the camera-to-PC decisions in order if you are sizing a whole station. For a GigE camera mounted away from the PC, plan the cable run too — the cables category covers the industrial Ethernet cabling that carries the stream.

When is the module-plus-microcontroller route still worth it?

Only for a one-off prototype that needs imagery rather than temperature: if a few low-resolution frames per second answer the question, a module on an SPI-to-serial bridge costs little, but you are trading away radiometric accuracy, documentation and every hour you will spend on the glue code.

The serial link sets the ceiling. A UART at 921,600 baud — the fastest common rate — moves about 92 kB/s once start and stop bits are counted, so one 655,360-byte radiometric frame takes about 7 s:

Bridge builds that show several frames per second are streaming compressed or downsampled thumbnails, not measurement frames. A compressed picture has the same problem as the UVC stream above: the counts are gone before LabVIEW sees them.

Add the glue firmware, the housing, the connectors and the documentation an assembled camera brings as standard, and the module route only wins when the deliverable is a demonstration that will never scale. If the project will ship or the number must be a temperature, order the camera with the documented interface and start from the discovery step instead.

If a data sheet leaves the interface line ambiguous, send it to us through the contact page and we will tell you which of the two paths it takes before you spend money. More acquisition-level fixes like the ones above are collected on the systems topic page.