GS1 DataMatrix: FNC1 versus GS as the Variable-Length Field Separator Character

George Wright IV

The four special bar code Function Characters (FNC1, FNC2, FNC3, and FNC4) trace their origins to the invention and introduction in 1981 of Code 128. According to the original Code 128 international symbology specification ISO/IEC 15417, these Code 128 symbology characters “define instructions to the bar code reading device to allow for special operations and applications.” These four symbol characters have no ASCII equivalent and are not intended to be transmitted. Many linear and 2-D symbologies invented subsequent to Code 128, including the popular 2-D symbologies Data Matrix ECC200, Aztec Code, and QR Code, incorporate these same characters and their defined functionality.

For example, according to ISO/IEC 15417, “FNC2 (Message Append) instructs the bar code reader to store temporarily the data from the symbol containing the FNC2 charac-ter and transmit them as a prefix to the data of the next symbol. This may be used to concatenate several symbols before transmission.” Similarly, “FNC3 (Initialise) instructs the bar code reader to interpret the data from the symbol containing the FNC3 character as instructions for initialization or reprogramming of the bar code reader. The data from the symbol shall not be transmitted by the bar code reader.” FNC4 has similar reader control functions. Because these function characters have no ASCII character equivalent, they cannot be directly represented in a data message transmitted by a scan-ner; nor with one exception are they ever supposed to be represented in transmitted data.

The exception is FNC1, which has two distinct roles. The first is to be a “flag” character to the reader indicating that the encoded message conforms to a specific data format convention. According to the spec, “FNC1 in Code 128 symbols in the first symbol character position following the Start character has been reserved exclusively” to define data conforming to the GS1 system. This same role is defined for FNC1 in Data Matrix ECC200 and other symbologies that support the GS1 system data structures. The FNC1 symbology character is the only character that can perform this function.

These two GS1 DataMatrix symbols both encode the same GTIN, SN, and QTY data. They have different patterns because the upper symbol uses FNC1 as the Separator Character between AI(21) and AI(30) while the lower symbol uses GS as the Separator Character. In both cases, the overall symbol size and the data transmitted by the scanner are exactly the same.

All scanners/readers are required to “key” on FNC1 in this first position. When a scanner is so enabled–as called for by GS1 specifica-tions–it transmits as a prefix to the encoded data the three-character ISO Symbology Identifier denoting a GS1 data structure. For GS1-128 it is “]C1” versus “]C0” for “plain” Code 128. For GS1 DataMatrix the symbology identifier is “]d2” versus “]d1” for Data Matrix ECC200 in general use.

For the second use of FNC1 the Code 128 symbology specification stipulates that “FNC1 in the third or subsequent character position is transmitted as the ASCII character GS (ASCII value 29).” This is the “nonprinting” character named Group Separator. The same functionality and scanner behavior is stipu-lated for FNC1 in GS1 DataMatrix.

In the GS1 system, a variable-length Application Identifier data field that is not the last field must have a delimiter following the last data character to indicate where that data character ends and the subsequent Application Identifier begins. This would be the case, for example, for AI(21) Serial Number followed by AI(30) Quantity.

Whether in GS1-128 or GS1 DataMatrix, an encoded FNC1 symbology character is specified to perform this function. Section 7.9.3, the Function 1 Symbol Character (FNC1) of the current GS1 General Specification (v9.1), reads as follows:
 “Only when used as a Separator Character is the Function 1 Symbol Character (FNC1) transmitted in the decoded data string as <GS> (ASCII character 29, seven-bit character set ISO 646). All Element Strings of variable length…must be followed by an FNC1 when followed by another Element String in a single bar code symbol. An FNC1 is not required at the end of the last Element String represented in a bar code symbol or for certain AI combinations defined by the symbology specification (e.g., some types of GS1 DataBar).”

Because of its historical function in data processing and the fact that it is not a valid data character in the GS1 system, “GS” (ASCII value 029) was chosen as the “alias” to represent an FNC1 character encoded as a field delimiter, or “Separator Character” to use GS1 terminology.

This convention that the bar code reader shall transmit an FNC1 encoded in the 3rd or subsequent position following the start character as GS is enshrined in all of the applicable symbology specifications. And, as is plainly mandated in section 7.9.3 of the General Specification cited above, it is required that one encode the symbology character FNC1 as the Separator Character.
However, it is also possible to encode the GS character literally in any symbology that supports these four Function Characters. But because of the arcane way some bar code label design software implements how a user inputs FNC1, it is sometimes much easier to encode GS directly rather than FNC1 as the Separator Character. The key point, however, is this: the data transmitted from the scanner–and received by the application–is identical. The Separator Character is transmitted as GS (Group Separator, ASCII 29) whether one encodes the character FNC1 or GS.

It should be noted that in GS1-128 encoding FNC1 versus GS almost always results in a shorter symbol. In GS1 DataMatrix, however, the symbol size is usually the same regardless of which character is encoded.

From a verifier manufacturer’s perspective, given the clear requirement to encode (only) FNC1 as the Separator Character, it would be perfectly appropriate to “Fail” a GS1-128 or GS1 DataMatrix symbol for data format conformance (if the verifier offers such checking) if it encodes the bar/space pattern or 2-D codeword for GS literally and not FNC1. As a practical matter, however, it makes no difference at all and one can argue that at most a verifier should warn or merely note that GS,  not FNC1, is encoded.

Others agree that it makes no difference in the supply chain which of the two characters is encoded. In fact, a formal GS1 General Specification change request (CR # 09-177) to allow the encodation of either GS or FNC1 as the Separator Character has been submitted on behalf of several of the national GS1 Member Organizations. This CR is now working its way through GS1’s Global Standards Management Process. There is some resistance to this change by “purists” on the grounds that FNC1 is the established field delimiter and that people simply ought to learn how to use their software tools properly. It is unclear which camp will prevail. It is this author’s opinion that there is good reason to make this proposed change to the GS1 General Specification. If it makes no difference which character is encoded, and it is easier for label designers to use GS rather than FNC1, then use of GS instead of FNC1 as the Separator Character will continue–and expand–whether GS1 changes the GenSpec or not.

At the moment, however, the GenSpec is clear. One could appropriately challenge the statement that a symbol encoding GS and not FNC1 is “correctly formatted.” In fact, it is not correctly encoded. However, it is unequivocal that the transmitted data are correctly formatted.

For the present, the fact remains: FNC1 is specifically called for in the GS1 GenSpec; Group Separator is not permitted. Does it really make a difference which one is used? No. The data coming from the scanner are the same. It takes a verifier or other diagnostic bar code tool to know which character is actually encoded.

George Wright IV is vice president of Product Identification & Processing Systems Inc. Questions, comments, or requests for application assistance should be emailed to the author at gw4@pips.com. Look for a follow-up article on bar code Symbology Identifiers and data capture application design in a forthcoming issue of PMP News.