Serial JPEG camera commands: snapshot vs get picture timing

Command-driven serial camera modules — the small JPEG boards you talk to over a UART with commands such as INITIAL, SNAPSHOT and GET PICTURE — are a straightforward way to put a still image on a microcontroller. Three questions decide whether one works in your machine: which resolution you configure, which of the two capture commands you send, and what paces the packets. The answers are short. Configure only the format you will fetch. SNAPSHOT freezes a frame while GET PICTURE grabs the one in flight. The acknowledgement from your host, not a camera timer, sets the packet interval. What follows is the timing math, the command sequence, and the point at which you should fit a board-level camera instead.

Do you need to set RAW resolution when you configure JPEG capture?

No — one INITIAL command carries the resolution for the format you will actually capture, so set the JPEG resolution and leave RAW unset; RAW matters only when you switch the module into raw-output mode.

The INITIAL exchange sets two things: the output format, and the resolution belonging to that format. For JPEG work that means one JPEG resolution, chosen from the fixed table in the module's command reference — these modules take a listed resolution, not a free width and height. The RAW resolution belongs to raw transfers, where sensor data leaves the module uncompressed, and nothing in a JPEG session reads it.

Raw mode is still worth one test on a new part: it shows what the sensor sees before the JPEG engine discards detail, and the checks are the ones described in camera module raw image capture: check before you code. If your defects survive JPEG compression, stay with JPEG — the frame you move is many times smaller.

Is SNAPSHOT the same as GET PICTURE with frames skipped?

No: GET PICTURE fetches the frame that is passing through the sensor at that moment, while SNAPSHOT freezes the current frame into the module's buffer so you can fetch it later, unchanged.

GET PICTURE is capture-and-fetch in one action. The frame you receive is whichever one the sensor is producing when the command is processed — the frame passing by. Nothing is skipped and nothing is discarded; the command simply does not choose an instant, it takes the one in progress.

SNAPSHOT is the instant-chooser. It freezes the current frame into the module's frame buffer and holds it; you then send GET PICTURE to move those bytes out whenever it suits you. Alone, GET PICTURE ties the capture instant to the moment your command lands. As a pair, SNAPSHOT fixes the instant — a trigger, a PLC signal, a button press — and the transfer happens afterwards, on your schedule.

That decoupling matters on a slow link. One frame takes about a second at default baud (the arithmetic is below), and a second is a long time on a moving line: freeze first, then move the bytes, and the image is the one you asked for.

What sets the time interval between data packets?

Your acknowledgement does: the module sends one data packet, then stops, and the next packet leaves only after your host acknowledges the previous one, so the interval is your ack turnaround, not a camera timer.

Image data leaves these modules packet by packet, and the acknowledge is the flow control. Nothing on the camera side configures a delay between packets; the module simply waits. If you need spacing — say, to let a slow storage write finish — hold the acknowledgement for that long and the line stays quiet until you release it.

The pacing is per packet, not per byte. Inside a packet the bytes arrive back to back at the line rate, so your read loop still has to keep up with the port while a packet is in flight. Acknowledgement pacing protects you between packets; only a fast read protects you inside one.

How long does one JPEG frame take to arrive?

Count on about 1.1 seconds for a 12 KB JPEG at 115200 baud in 512-byte packets: 24 packets at 11,520 bytes per second of line rate, plus your acknowledgement turnaround on each packet.

The arithmetic works for any baud and any frame size:

A worked example, with the numbers an engineer would check:

• Frame: a 640 × 480 JPEG compressed to 12 KB = 12,288 bytes.
• Packet payload: 512 bytes — an illustrative value; the command reference prints the real one. Packets: 12,288 / 512 = 24.
• Line rate: 115200 baud / 10 bits per byte = 11,520 bytes per second.
• Line time: 12,288 / 11,520 = 1.07 s.
• Acknowledgement: 2 ms per packet in this example, so 24 × 2 ms = 48 ms.
• Total: 1.07 s + 0.048 s ≈ 1.11 s per frame — a ceiling of about 0.9 frames per second, set by the link alone.

Raise the baud and the ceiling moves. At 921600 baud the same frame crosses in 12,288 / 92,160 = 0.13 s, plus the same 48 ms of acknowledgements — about 0.18 s, or 5.5 frames per second. That is a still-image link, not an inspection rate. The same sizing logic for faster transports is in full resolution image capture that stalls: size the data first, and the failure at the far end of slow serial links is laid out in camera image data over a Zigbee mesh: why serial transfer fails.

One number decides your read loop: a 512-byte packet is on the wire for 512 × 10 / 115200 = 44 ms, and it does not fit a typical microcontroller UART buffer. Drain the port while the packet arrives; the acknowledgement you send afterwards is what holds back the next one.

How do you sequence the commands for one clean frame?

Send INITIAL with the JPEG resolution, take a SNAPSHOT at the moment you want frozen, then send GET PICTURE and acknowledge every packet as it arrives; that sequence gives you one known frame.

1. Run any wake-up or sync handshake the command reference lists after reset — several of these modules expect one before they accept INITIAL.
2. Send INITIAL with the JPEG resolution from the module's table. Read the acknowledgement and confirm it; when no reply arrives inside your timeout, send the command again rather than proceed.
3. Send SNAPSHOT at the instant that matters — the trigger event, not the transfer slot.
4. Send GET PICTURE. These transfers announce the image size before the data begins; note it, because it is your byte count to hit.
5. Read one packet, store it, send the acknowledgement, repeat. Hold the acknowledgement when you want the line quiet.
6. Stop when the received bytes equal the announced size and the JPEG end marker 0xFF 0xD9 sits in the last bytes. A short count means a lost packet or a noisy line: retake the frame rather than patch the stream.

Check every reply, every time. A response occasionally fails to arrive on these links, and the protocol hands you the check for free — a command you can resend is worth more than an assumption. On the host side, the read-loop discipline that keeps the packets flowing is the same one behind camera module serial frame streaming: fix the Python 3 grab.

Clean wiring does more for you than fast code. Level-shift between a 5 V TTL module and a 3.3 V host, tie the grounds, and keep the leads short — clean serial data for JPEG capture covers the habits. When corruption still gets through, start from pink corrupt JPEG images from a camera module.

When is a serial JPEG module the wrong camera?

When you need more than roughly one frame per second, a deterministic trigger, or real control of exposure and gain: a USB3 or GigE board-level camera moves the same picture in milliseconds, not seconds.

The decision splits on three needs:

The small sensors behind serial modules also read out line by line, so parts that move during exposure shear. That is fine for a stationary part in a jig and wrong for anything on a conveyor.

Frame rate is where the crossover bites. The LS-BCM-0003 is a 3.1 MP USB3 board-level camera with the IMX252 sensor, a 1/1.8-inch format and a global shutter at 120 fps — on USB3 the transfer bottleneck that defines the serial module does not exist, and a global shutter removes the shear from moving parts.

In the same footprint class, the LS-BCM-0047 is a 1.3 MP USB3 board camera with a C-mount, and the LS-BCM-0060 is a 2.3 MP pen mini camera on GigE with an M12 mount. For long cable runs, the MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera with the IMX296 sensor, a global shutter and an M12 lens mount.

When the cell has no host at all, put the decision on the device: the LS-SMC-0063 is a 1.6 MP smart camera that inspects on board at 60 fps with a 16 mm lens and its own white light source.

Browse the board-level cameras, area scan cameras and smart cameras categories, or start from the camera finder.

What should you check before ordering the module?

Check the command reference of the exact module generation you are buying for three things — packet payload size, maximum baud rate, and whether the JPEG engine is present at all — because one later generation of these modules dropped JPEG and outputs RAW only.

Then run the list:

• Format list. JPEG present, or RAW only, for the generation in hand.
• Packet payload. The reference prints it; put it into the transfer formula and recompute your seconds per frame.
• Baud ceiling. The highest rate the module and your host UART both run; 921600 baud turns a 1.11 s transfer into 0.18 s on the same frame.
• Drain time. Your read loop must empty one packet within its line time — 44 ms at 115200 baud for 512 bytes.
• Resolution table. The fixed list must cover the field of view you need at the working distance you have; if it does not, that is a board-camera problem, not a settings problem.
• Levels and grounding. TTL level matching, one common ground, short leads — the electrical habits that keep JPEGs whole.

If the arithmetic points you away from the serial module, walk the system configurator from the camera step, or send us the numbers through the contact page for a configuration check. More capture-side timing pieces sit on the systems topic page.