Why Code 39 readers strip the asterisk start/stop character

You built the receive frame around an asterisk header and an asterisk terminator, and no data ever arrives. The label is almost certainly fine. In Code 39 the asterisk is the start and stop character: the reader needs it to decode the symbol, then removes both copies before transmitting, so the bytes you framed on never cross the wire. This explainer covers what a Code 39 symbol really contains, exactly what reaches your PLC in hex, why 2A framing cannot match, what to check when a beeping reader delivers nothing, and the symbol-width arithmetic that decides which fixed reader fits your line.

What is the asterisk in a Code 39 symbol?

The asterisk is Code 39's start and stop character: one fixed pattern at each end of every symbol that tells the decoder where data begins and ends. It is 2A in hexadecimal, 42 in decimal, and it never counts as data.

Code 39 encodes 43 characters: the digits 0-9, the letters A-Z, minus, period, space, and the four pair characters — dollar, slash, plus and percent. The 44th pattern, the asterisk, is reserved for framing and cannot carry data. Each character is nine elements (five bars and four spaces) with exactly three wide, which is where the name comes from: three of nine. The character set and structure are documented in the Code 39 reference.

Full ASCII Code 39 stretches the set to all 128 ASCII characters by pairing a prefix (dollar, slash, plus or percent) with a second character. The reader must have that mode enabled to collapse the pairs; on a basic-mode reader the pair arrives as two ordinary data characters.

Why does the scanner strip the start and stop characters?

Because framing is the decoder's job, not the host's: the reader uses the two asterisk patterns to locate and decode the symbol, then transmits only the characters between them, so the default frame carries data alone.

The start and stop patterns tell the decoder where the symbol begins, where it ends, and that it reads the same in either direction. Once used, they carry no information for your program, and sending them would prepend and append the same constant byte to every message. Readers come from the factory with start/stop transmit off, and the decoder settings expose the switch: scanner SDKs group it under Code 39 decoder parameters, alongside the decoder's other settings, so check your SDK's Code 39 decoder parameter documentation for the start/stop transmit flag.

Whatever suffix you configure — CR (0D), LF (0A) or both — is the only framing the host sees. When those bytes land in PLC registers as words, converting hex words to ASCII text shows the payload before you write matching logic.

Why won't a 2A header and terminator ever match?

Because the bytes you framed on do not exist in the received string: with the asterisks stripped, no 2A byte ever crosses the line, so a receive instruction waiting for 2A, data, 2A waits forever.

Fix the host framing, not the barcode. Frame on bytes that are actually sent — the suffix is the usual anchor, and framing scanner data into an HMI serial port works through the same choice. Fixed-length payloads can frame on length alone. If you want the asterisks in the string, turn start/stop transmit on and frame on 2A at both ends; the reader setting and the host framing must move together, because a header-only match now leaves a trailing 2A glued to your data. For how receive instructions handle ASCII without headers — including the nulls and races that drop frames — read barcode data framing in the PLC receive buffer.

The reader beeps but the PLC sees nothing — what breaks?

The beep proves the barcode decoded, so the fault is electrical or serial, not the label: check, in order, a missing signal ground, crossed TX and RX, then a baud or parity mismatch — ground is the one most often skipped.

Ground first. An RS-232 link needs three conductors: TX, RX and signal ground. On a standard DB9 connector, pin 5 is ground. Map the reader's TX to the host's RX and the reader's RX to the host's TX — two devices wired as DTE need a crossover — and land the same ground pin at both ends. Serial ports on PLC CPUs and expansion modules do not always follow the reader cable's pinout, so map both ends pin by pin once.

Second, the line parameters. Reader and host must agree on baud rate, data bits, parity and stop bits; 9600 baud, 8 data bits, no parity, 1 stop bit is the usual pairing. Third, the interface mode: a reader set to USB or keyboard output sends nothing on its serial line, and a serial listener hears silence. The trade-offs among barcode scanner input methods to a PLC and the level details in wiring a barcode scanner RS232 ASCII string to a PLC serial port cover both checks.

If the reader does not beep at all, stop chasing the wire — the symbol itself is failing to decode. Modules printed too small, missing quiet zones and glare off laminate are the usual causes, and 1D barcode preprocessing for rotation, blur and glare covers the fixes.

How wide is a Code 39 symbol at a given module size?

With the usual 3:1 wide-to-narrow ratio, each Code 39 character occupies 15 narrow elements plus a 1-element gap, so an n-character payload prints (16n + 31) × X wide, X being the narrow element width.

n is the data character count; the +2 adds the two framing asterisks, and the gaps run between characters. Quiet zones are mandatory at 10X per side.

Worked example: print LOT-4711, eight characters, at X = 0.25 mm (a 10 mil module). W = (16 × 8 + 31) × 0.25 mm = 159 × 0.25 mm = 39.75 mm of bars. Quiet zones add 10X each side — 2.5 mm + 2.5 mm — so the label needs 44.75 mm. Dropping to a 2.5:1 ratio narrows it to (14.5 × 8 + 28) × 0.25 mm = 36.0 mm, about 9% less, at some cost in decode margin.

Pixels decide whether a fixed imager reads it. Treat 2 pixels across the narrowest element as the floor and 3 as the design target. A sensor 1280 pixels wide — typical of a 1.2 MP reader — covering a 60 mm view delivers 60 mm ÷ 1280 = 0.047 mm per pixel, so a 0.25 mm module spans 5.3 pixels. Stretched over 150 mm, the same sensor gives 0.117 mm per pixel and 2.1 pixels per module: keep the view under about 150 mm at 10 mil with that sensor width, or buy more pixels. The camera resolution calculator runs the division for your numbers.

For wide views, more pixels buy the margin back. The LS-CRD-0028 prints 2560 × 2048 pixels with an 8 mm lens and reads up to 60 codes/s. Those 2560 pixels across the same 150 mm view give 0.059 mm per pixel, and a 0.25 mm module covers 4.3 pixels — comfortable. Module size and reading angle interact the same way in the denser symbology; Code 128 module size, reading angle and reader distance carries the numbers. Long payloads fail on width as often as on decode — the payload side is in Code 128 codeset B length limits.

Why did the asterisks disappear from my printed label?

Because word processors auto-format asterisk-delimited text as bold: type the payload between asterisks in a document and the formatting consumes the pair, so a barcode font prints a symbol with no start/stop at all.

Barcode fonts expect you to supply the framing: the font maps the asterisk to the start/stop pattern, so you type the payload wrapped in asterisks. Auto-formatting removes the pair before the font ever sees it, and the printed symbol has no framing — which is why no reader beeps on it. Turn the auto-formatting off, print from label software or a spreadsheet, or use one of the Code 39 fonts that maps an exclamation mark as the start/stop pair to dodge the formatting engine. Labeling software with a real Code 39 component adds the framing itself; type only the payload there.

When does the usual answer not hold?

Three cases: start/stop transmit turned on sends 2A at both ends; verification and grading tools display the asterisks while still stripping them from the data; and full-ASCII mode rewrites dollar, slash, plus and percent pairs into single characters.

• Start/stop transmit on. The frame becomes 2A, data, 2A, and a host framing of 2A header plus 2A terminator matches. Expect the payload to arrive bracketed, and keep both ends configured together.
• Verification and grading views. Quality tools show the payload wrapped in asterisks for readability while the transmitted string still excludes them. Copy the transmitted bytes into your matching logic, not the display.
• Full-ASCII mode on. Pair characters collapse: printed +A arrives as one lowercase a, and /J arrives as an asterisk. Payload length changes with it, which breaks fixed-length matching.

What should you check before ordering a fixed code reader?

Order by interface, then by optics: pick the output your controller actually accepts — Fast Ethernet, USB or serial — then confirm the pixels-per-module sum at your real field of view; decoder settings such as start/stop transmit are configurable afterwards.

The short list:

• Payload: the basic 43-character set unless your labels are printed in full ASCII; watch payloads that start with a dollar, slash, plus or percent sign.
• Interface: filter the code reader finder by the output your controller takes.
• Optics: reading distance and focal length set the view; run the width formula and the pixel check at that view before ordering.
• Decoder settings: enable Code 39, decide start/stop transmit once, and set a known suffix such as CR LF.
• Environment: covers and light boards for glare or washdown live in reader accessories.

For close-up static reads, the LS-CRD-0047 covers a 60-120 mm reading distance with a 1.2 MP sensor on USB 2.0.

For line-level installs, the LS-CRD-0052 is the dual-aviation-plug Ethernet model with a 1.2 MP sensor and a 12 mm focal length; the MV-ID3013PM-12M-WBN pairs a 12 mm focal length with a 1.3 MP sensor over Fast Ethernet:

Start from the fixed code readers category, or bring your label samples to us through the contact page — we will run the width and pixel math with you before you order.