There is much debate over the benefits of RFID technology versus Bar Code technology. The AIDC 100 held a forum on October 20, 2004 called “Truth in Technologies 2004: RFID & Bar Codes”, that addressed this subject in detail. The Forum was a tremendous success and spurred many thoughts, comments, and opinions subsequent to the event. Comments prior to and subsequent to the forum are listed below.

The following expressed comments and OPINIONS are those of various AIDC 100 members and do not necessarily reflect the position of the AIDC 100. We encourage anyone interested in the subject to send their opinion to Dick Meyers (dickmeyers@mindspring.com) for posting on the site.

For more information and the qualifications of our members, click here.

February 17, 2006
RFID or Barcode
Chris Kapsambelis

RFID and Barcode are becoming interchangeable. Recently, I read an article in RFID Journal titled “Wal-Mart Explores New RFID Form Factors”. The article stated that Wal-Mart was rolling out handheld RFID interrogators, mobile computers that can read RFID tags, forklift mounted RFID readers, and even RFID readers that an employee might wear. The article also mentioned that these new devices can read Barcode. All of these rollouts are aimed at helping Wal-Mart with inventory control. In addition to reading RFID tags on pallets and cases, these devices can also be used to read shelf tags or location tags, presumably to record Put-away, and Picking transactions.

What struck me about the article was the fact that all these devices are operated manually and require a human interface in order to function. In recalling the Technology Guide, published by the Auto-ID Center at MIT around the year 2003, and currently located in the archives of www.EPCGlobalInc.org, the emphasis for selecting RFID was its superior capability for Automatic Data Capture. The fact that RFID required no “Line of Sight”, and the ability to simultaneously read large groups of tags, would lead to a global network of stationary readers, that would automatically read items, and track them within the Supply Chain, in what was described as a Network of Things.

The higher cost of RFID was to be justified by the increase in productivity that would result from saving the labor needed in manually scanning bar codes, and the reduction in operating costs due to the higher level of accuracy that only full automation can provide. Manual scanning would disappear, RFID equipped portals would automatically read pallet loads of cases leaving a factory, and similar portal readers would receive them when they arrived at destination. Within a given facility, storage bays equipped with readers were to take instant and continuous inventory of every thing in the warehouse. Similarly, shelf readers were to perform the same function for the sales floor. With this system in place, near-perfect supply chain visibility was assured, and this would result in unprecedented levels of productivity throughout the Supply Chain.

Today, the Department of Defense (DoD) has concluded that human intervention is required to be sure that RFID readings are complete. See article No Silver Bullets. Wal-Mart is moving from portal, and shelf interrogators to dual capability manual readers. The concept of hands-free, full automation is being abandoned in the interest of economics. Manual interrogators can fulfill multiple roles. At one time they can be used to capture Receiving Transactions, while at another time, the same hardware can be used to capture Shipping Transactions. Similarly, a much smaller set of RFID hardware can be utilized to capture all the data needed for the operation of the Supply Chain. The concept of full automation with RFID is moving in the direction of manually reading items one at a time very similar to what is done with Barcode. See article Six Sigma and the Single Tag

Currently, the EPC data on each tag is also printed in barcode using the GTIN, SSCC, and other standards. The Association for Automatic Identification and Mobility (AIM)’s RFID Experts Group (REG) and Technical Symbology Committee (TSC) have been working on recommendations to use barcode as backup in the event of tag failure. AIM announced recently, that the recommendations have been forwarded to EPCglobal’s Tag Data Standards (TDS) group for final review and publication. The final specification is due to be released within the next two months. When this is done, every RFID tag will also have a barcode symbol.

While DoD, Wal-Mart and others will undoubtedly demand their suppliers continue to tag pallets and cases with RFID, It appears that most users will have a choice as to which technology to use for Data Collection. Since items in the Supply Chain are being labeled with RFID, Barcode, or both, a user will be able to choose which manual data collection technology is more suitable. In the end, the choice between RFID and Barcode will be selected by popular demand.

October 28, 2004
New EPC Symbol
Chris Kapsambelis

First, let me thank everyone who has responded positively for the need for an EPCSymbol designed to back-up RFID, and act as an alternative method for retrieving the EPC Number.

In an effort to focus the discussion I would like to make the following points:

  • The EPC number is part of a concept to provide unique identification for every item used in the transportation of goods in the Supply Chain.
  • RFID was chosen because it was believed to have properties, unlike barcode, that will permit the complete automation of the process by not requiring manual scanning for data capture.
  • On July 30, 2004 I wrote on this BLOG that the current form of passive RFID had properties that were the same as barcode, and therefore would be no better in reading pallet loads of cases.
  • 0n October 29, 2004, at the “Truth in Technologies 2004: RFID & Bar Codes” forum, it was verified by a number of speakers that the read rate at RFID equipped portals, where pallets are being received, varies from 50% to 80%, and the emphasis will be on the acquisition of accurate ASNs to make up for the shortcomings of RFID.

In the spirit of retaining the emphasis on automation that RFID and EPC promise, The EPCSymbol should be designed for high speed fixed position scanning. That means an X dimension of about 20 mils and an aspect ratio of at least 2:1.

Everything that Sprague Ackley says in his analysis of my code that was submitted as an EPCSymbol is true. However, not necessarily relevant. In an effort to reduce the code to its smallest possible size, I chose to forgo the use of the super redundancy included in Code128 and others. Instead I am relying on the fact that the symbol will be printed on a white label with thermal transfer printers resulting in an ANSI Grade of A.. Given that the symbol will be fixed length and scanned exclusively by laser scanners in motion, I believe that 100% accuracy can be guaranteed by depending on the scanner to provide the needed redundancy through multiple scan comparisons. The super redundancy came into use as a result of poor printing with early dot-matrix printers using faded ink ribbons, and printing directly on Kraft paper cartons. Given today’s printing technology super redundancy is probably unnecessary.

I realize that this is a controversial point of view, and that the only way to prove the point is with extensive side-by-side testing. In my initial email to Clive Hohberger, I mentioned that Code128 Subset C can be used to code the decimal equivalent of the EPC number with about a 10% increase in code size. I believe Sprague Ackley, in his analysis mentions this as a possibility.

I, therefore, recommend that Code128 Subset C be adopted to encode the EPCSymbol.

Ted Williams responded by suggesting an RSS expanded symbol. Now that we have Ted Williams(who under my command invented Code128) engaged, perhaps Ted can suggest any modifications that can be made that preserve the ability of existing scanners to read the symbol, while at the same time allows future scanner designs to improve the symbol’s readability. I suggest that one of Code128’s function codes be embedded in the center to act as both a unique identifier and a center marker. This will permit future scanner designs to independently decode each half of the symbol, and will remove the need for excessive code orientation.

As to Sprague Ackley’s suggestion to consider Code 93i, I am at a loss since I do not know anything about it. Sprague’s description of its properties sounds too good to be true. Before it is adopted, several applications, where it is used for high speed fixed position scanning, should be examined to determine read rate, and accuracy. I do not think that there is any question on this point relative to Code128.

October 25, 2004
New EPC Symbol
Bert Moore


Admittedly, I’m not aware of the naissance of this specific thread (I’ve seen the e-mails but don’t know how Rick somehow initiated it) so I’m wondering if there has already been a discussion about where the bar code scanner would be connected — and that’s the basis of my question.

That is, would it be connected to the bar code side of the host software (since not all units, presumably will be EPC tagged) or will it be somehow be routed to the RFID edge server for interpretation?

If it’s the former, wouldn’t an SSCC-18 serve adequately for retail users — at least in the interim until the vast majority of items are, in fact, EPC tagged?

October 25, 2004
New EPC Symbol
Tom Brady

I support the use of RSS Expanded as indicated by Ted Williams.

RSS capable scanners have been delivered for at least the last 2 years. Our Global Standards Management Process (GSMP) has recommended an open date for the use of RSS as January 2008. It is estimated over 80% of scanners will be RSS capable by that date.

Various user groups are planning applications using the AIs in addition to the GTIN. Such applications will be released for open use as their implementation is proven.

As an example, the Joint Industry Coupon Committee is working on RSS expanded for US coupon applications with an open use date of October 2008 (look at our Web page www.uc-council.org, search for “coupons” if you are interested in a copy of the current draft proposal and background material).

One of the work items as Gen 2 and future standards are completed is the method of carrying the AIs in expanded tags and their relationship to the EAN.UCC keys (SGTIN,etc). It seems to me that RSS expanded is well suited to co-exist with EPC Tags.

The questions about parsing are still open to be resolved most likely through the new EPC Architecture Review Committee (ARC). These are items which must be resolved. There will certainly be co-existence with current bar codes as well as the proposed EPC structures proposed here.

October 24, 2004
New EPC Symbol
Ted Williams

Assuming a 2-digit AI to identify the 96-bit EPC data application, and 96-bit binary to 29-digit numeric conversion, the attached is a 151X RSS expanded symbol that would back up a 96-bit EPC tag.

I recommend this as it is already supported by newer point-of-sale scanners for omnidirectional scanning. It is also a supported symbology in the General EAN.UCC Specifications. So it would require the least modification to the EAN.UCC system – only the definition of a new AI for EPC-96.


Overview of Symbologies Suitable for EPC Encoding
By Sprague Ackley
24 October 2004

Many thanks to Chris Kapsambelis for suggesting a symbol capable of encoding EPC data. I, too, was questioned regarding encoding exactly the EPC bytes (on 15 September 2004) and replied that there is only one public domain linear symbology capable of encoding bytes in a uniform fashion but that there are other possible solutions. At that time and still the case, the EAN/UCC technical committee has not begun any work on the subject. At that time, I contacted the UCC and informed them of the concern.

Chris has now called the question by proposing a symbol. I felt compelled to make some comments on his suggestion as well as to do a simple analysis of the possibilities using published symbologies.

Chris’ symbol

Chris claims that his symbol is the shortest possible symbol encoding 12 bytes (he actually encodes 24 hex characters). Chris’ symbol encodes 24 (7,2) characters inside weak start, stop and guard patterns. Forced to use 16 of the 20 characters in the (7,2) set, he therefore has chosen to utilize non-self-checking characters and he has not added any check characters. His symbol would be at least 100s of times more likely to suffer character substitution errors than UPC-E. Furthermore, a single error in the last bar which provides scan direction information renders the symbol un-decodable. In order to make the symbol resistant to character substitution errors at similar security levels to other symbologies without character self-checking, he would need at least three check characters. For symmetry sake, I have used four in this comparison. I have not added any compensation for the “Achilles heal” in the start and stop patterns. I am calling the resulting symbol Chriscode.

Fine print

I have attached my symbology worksheet. It is possible that there are errors and I encourage anyone so inclined to check my math. I only considered the EPC-96 data here but I did the calculations for EPC-64 also. An EPC-96 data string contains exactly 12 bytes. All the symbol lengths used in this comparison are in terms of X. I have not included the Quiet Zones, but all symbols will need at least one and should have two. It would be possible to design an entirely new symbology using large (n,k) characters without quiet zones that would be shorter than any in this comparison of Chriscode and the published symbologies.

Encoding bytes directly

People that I talked to wanted to encode bytes directly. That means that the output of the decoder is exactly 12 bytes, not Chris’ solution of 24 bytes. The only public domain linear symbologies capable of this trick are Code 128 and 93i. In both cases, there are virtually no available printers or readers that support this feature. Needless to say, adoption of a byte-capable symbology by EAN.UCC would inspire vendors to supply conforming products in a very short time. The best solution here is 93i at 208X. 93i is not only the shortest symbol (by 58X, on average) but it is a fixed length, whereas a Code 128 symbol length can vary by over 50% forcing the use of larger label stock and taller bars. The Code 128 byte feature with AIs is specifically not allowed according to the current standard.

Encoding digits or hex characters

If users do not mind post-processing hex characters or digits into byte values, then there are several options. The shortest symbol both compresses the bytes into a 30-digit integer and then encodes the digits using code set C in Code 128. The resulting symbol is 200X. Encoding decimal bytes in Code 128 results in a symbol that is 247X. Assuming the AI standard was modified and a 2-digit AI assigned, an EAN/UCC-128 symbol would be 222X using a compressed integer and 269X using decimal bytes. Chriscode is the smallest symbol for encoding hex characters at 209X. By comparison, an EAN/UCC ITF-14 symbol is 120.5X.

Error correction for a better solution for automated scanning

If users are really ready to encode serialized information on shipping containers, then they should seriously consider 93i with error correction. 93i is the only public domain linear symbology with error correction and as mentioned earlier, it is the only one that can encode bytes uniformly. A 93i symbol can sustain complete obliteration to either the start or stop plus additional characters or up to six symbol characters and be fully readable. A 93i symbol with error correction would nearly eliminate no-reads from automated scanning applications and display less that 1% of the substitution errors of ITF-14. A 93i symbol with error correction encoding 12 bytes is 244X.

Bar height and automated scanning

Another feature of 93i with error correction is that the symbol can be scanned unambiguously in halves. This means that the symbol behaves as if it has bars that are nearly twice as tall as other symbologies to an automated scanner for a given X-dimension. When compared to existing applications of ITF-14 using the same X-dimension, the bars would be the same height as the ITF-14 symbol allowing similar scanner tilt angles. Needless to say, proprietary “stitching” techniques in use today could be used with even greater performance improvement when coupled with the error correction capability of 93i.


Chris Kapsambelis has opened the eyes of the industry with his insightful proposal for scanning EPC-96 data in a bar code symbol. While the shortest symbol for encoding hex characters is Chriscode at 209X, the best solution for encoding the exact same data found in an EPC tag is by using the published AIM symbology 93i at 208X. Once the industry considers a new symbology for encoding automated scanning data, the error correction feature of 93i encoded in 244X makes it ideally suited for the task. 93i can both sustain damage and use the same bar height as is now employed with ITF-14. Alternately, an EAN/UCC-128 symbol at either 222X or 269X without error correction and with bars that are twice as high for the same X-dimension as the symbol used today could do the job without introducing another symbology into the EAN.UCC system.

October 22, 2004
RFID & Bar Codes
Pail Chartier

Fellow AIDC 100 Members,

Sorry that I could not be with you at the recent meeting, but I am working on a UK Government initiative to roll out RFID centres. I have been following the thread of the arguments, and I know that Craig is concerned with having a back-up data capture system. So let me review some of the arguments.

1. For non-standard pallets there is a direct linkage between the SSCC in bar code and in the EPC tag, so we have a extant bar code solution that requires no new investment.

2. For cases we need something to distinguish between the different RF tags to support anti-collision. ISO has solutions that do not require a serialised item code, so the 14-digit SCC is a valid fallback. A fundamental question that still has to be addressed is why have a serialised GTIN? At least it has not been properly answered.

3. If there is a need for the SGTIN, then the EAN.UCC GSMP group should be looking at serialising the GTIN for encoding in bar code. We already have sound symbologies that can achieve this. The problem is that we all seem to be hung up on encoding exactly the same bit string in the back-up bar code as in the RF tag. We are using two fundamentally different data capture technologies and do not have to merge the logic at the lowest level.

4. Furthermore, I can see lots of product manufacturers baulking at the idea of adding serialisation to product codes that are incorporated as part of the product packaging at decimal fractions of a cent per impression. What happens when the serialised bar code does not verify? Do we expect online verifiers on every filling line?

5. The migration from EAN/UPC, or Interleaved 2 of 5, or Code 128 scanning to RFID is not going to happen overnight. So these old but robust data carriers and their data capture infrastructure will still be in place in 5 to 10 years time. Now some are proposing to add a DIFFERENT bar code symbology in addition to these and the EPC RF tag. Do we really expect the retailers and others in the supply chain to invest in both RFID data capture and install or upgrade to a new scanner base?

6. A final point for now. Those of us who remember the 1970s and even the 1980s know that we did not solve all the bar code data capture problems on day one. EPC has been over-hyped as providing fully automated data capture when it – as yet – cannot do this in all cases. RFID brings considerable benefits in a number of applications. With more work on the technology it will be increasingly successful. The problem is that the Internet of Things has been reduced to a mantra that has little foundation on sound AIDC technology and experience. We should be addressing the real problem and educating the world to the benefits of two great technologies.

October 22, 2004
New EPC Symbol

Dear Rick,

We are all in agreement that there should be a method to represent the tag data in bar code and human readable form. However, we believe that the work already done by the AIM RFID Experts Group has sufficiently covered this issue.

Best regards,

Tom Thatcher
President, Tharo Systems, Inc.

October 22, 2004
New EPC Symbol
Rick Bushnell

Chris, Clive and Craig, et al,

Since I’m the one who raised the question (wow, I had no idea what hell it was raise, I guess it was on a lot of people’s minds) I’d like to remind you all that I first discussed this with:

Will Garcia
Product Manager
Tharo Systems, Inc
(330) 273-4408

I really think that you should contact him because he has already done some of this work.

By the way I think the back up is a fantastic idea and I have put Chris’s email below for Will’s review.

October 22, 2004
New EPC Symbol
Chris Kapsambelis

Hello Clive:

As a result of your call to use barcode as backup for the RFID EPC tag in the commercial sector. I designed a new barcode symbol that encodes the 96 bit EPC number in the smallest possible length of any barcode symbology.

My first version of this symbol is attached.

I am willing to place the symbol in the public domain and sign all necessary waivers for its free use.

Since the symbol can be printed in a 4 x 2 inch space using a 20 mil. X dimension, it can easily be fitted on a 4X6 inch label.

The 20 mil. X dimension coupled with the two-part design ala UPC, will permit reading cases over a 360 degrees of orientation, traveling at very high speed, on conveyors, by fixed position scanners. There are many distribution centers, as well as UPS and FedEx, that are reading similar size barcodes at high speeds for sortation purposes

As a result of what was learned at the Forum: Truth in Technologies, I believe that the need to have a barcode on the EPC tag, that can be read in motion on a conveyor, will become a crucial alternative. Given that the read rate of pallet loads with RFID is now shown to be between 50% and 80%, the need for automated palletizes instrumented with readers that can generate 100% perfect ASNs will become a paramount element of the overall process.

The EPCsymbol will give users the choice of using fixed position scanners, ala UPS or FedEx, or RFID. Furthermore Manual pallet loading operations can use hand held portable scanners to generate the ASNs accurately.

There is a danger to going without barcode backup for the EPC tag. If RFID fails to meet its promise, it will be discarded, and if it is discarded, the whole concept of the EPC network for tracking goods in the supply chain will probably be abandoned as well. The use of barcode as backup, will give added assurance that the concept will survive regardless of the effectiveness of RFID.

The problem of introducing a new symbol is that none of the existing scanners can read the barcode. To address this problem, I am working on an alternative that makes use of Code 128 Subset C that can be read by any of the existing scanners. Unfortunately, this will require about 10% more space which will have to be compensated by a proportionate reduction of the X dimension. However, on the long run, this may be a better compromise.

If there is any interest in any of this, perhaps some testing is in order to prove out the concept, and finalize all the parameters.

Please let me know what you think.

October 22, 2004
RFID & Bar Codes
Craig K. Harmon


Since it was my presentation, let me tell you what I said and what I meant. I said, there is no EPC bar code . . . further that there is no convention for recording a human readable interpretation of EPC.

I am aware that there are many bar codes that can record a numeric or alphanumeric equivalent. I am also aware of Andy’s 1994 patent. The issue is that there is “no accepted means for an EPC back-up, be it a bar code, two-dimensional symbol, or HRI.” While there may be solutions, there is nothing that has been embraced.

October 22, 2004
RFID & Bar Codes
Andy Longacre

Gents —

The final sentence in this review, otherwise useful and excellent, cannot go unchallenged! Perhaps it’s useful to start by saying that most communications channels in use today cannot (taken literally) transmit and receive “binary codes” … instead, most transmit streams of 8-bit packets called bytes, and a stream 12 bytes can, of course, represent 96 bits. (Please note, one might prefer to use hexadecimal representation, which then requires 24 characters.) AND of course Many barcodes today can encode any stream of 12 bytes or 24 characters that one wishes. The very thought that barcode systems can’t “read and output binary codes” (while RFID readers presumably can) is sure poppycock!

— Andy Longacre

BTW — there -are- linear symbologies that encode data in unadulterated binary form (see U.S. Patent 5,479,515 e.g.) for what that’s worth.

October 22, 2004
RFID & Bar Codes
Chris Kapsambelis

At the recent forum, titled “Truth in Technologies 2004: RFID & Bar Codes” and hosted by the AIDC100, I and others raised many of the points that have been the subject of discussion on this Opinion Page. The following are some of the important points that were raised and the responses, as I understand them:

Several members of the audience indicated that the RFID read rate for cases loaded on pallets ranged from 50% to 80%. The question was raised as to how this shortfall in data collection was going to be handled? The response was that an Advance Shipment Notice(ASN) will be required. The ASN will be used at Receiving to fill in the missing data. A pallet load can be received even if only one of the tags on the pallet was read. This led to an observation that most errors in the make up of the ASN will go undetected.

Given that the 100% read rate for pallet loads is no longer required, why can’t the less expensive barcodes be used to identify pallets and cases using fixed position scanners? The response to this point was twofold

It is anticipated that in the future there will be a requirement to uses Read/Write tags.

RFID is expected to be more effective in capturing data from cases as pallets are broken up into fast moving inventories in the back rooms of department stores. How is this any different from barcode is not clear to me.

A point was raised that currently the specifications do not require that the EPCGlobal 96 bit binary number be printed on the label in barcode. The failure of any tag will result in either the total loss of identity or the need to key enter the 96 bit code. Many in the audience felt that the use of barcode as backup for tag failure was essential. It was also pointed out that non of the present barcode systems had the ability to read and output binary codes.

August 11, 2004
RFID & Bar Codes
Chris Kapsambelis

Based on recent press reports that have leaked out of the Wal-Mart pilot program in Dallas Texas, the reading of pallets loaded with RFID equipped tags is no where near 100%. This will force Wal-Mart to push the problem up the chain, and demand that suppliers provide pallet loads that are guaranteed to have 100% of readable pallets and cases, together with an advance computer record of the pallet and all the cases as a group. This will enable Wal-Mart to fall back to a position of reading any one of the tags on the pallet and use middleware to lookup the remainder.

While this sounds like a reasonable solution, there are a number of issues that are worthy of discussion:

Since Wal-Mart is unable to use the technology to effectively read pallets and cases as a group, how are the suppliers going to capture this data prior to shipping. If they “Slap & Ship”, the errors will not be caught until Wal-Mart begins to remove cases from the pallet. This is much too late in the supply chain to be finding errors. The suppliers will be forced to develop systems that can read each case individually as it is being loaded onto the pallet.

As a solution to the general supply chain problem, are companies, like Wal-Mart, willing to accept a system that depends largely on trust?

As cases are broken up for further distribution, how does Wal-Mart plan to capture partial pallet loads as they move around their facilities?

If the finding is that group reading of tags is not feasible, why is RFID better than Bar Code?

August 3, 2004
RFID & Bar Codes
Craig K. Harmon

REG Team Leader

Speaking for the RFID Experts Group (REG), we completely agree with Ed and Tom.

August 3, 2004

RFID & Bar Codes

Tom Brady

I fully support Ed’s message.

I propose the use of AIDC 100 knowledge in a very positive manner to build “initial installation” user analytical guidelines. These would be used to identify and quantify performance, ergonomic, and quality characteristics. Results would provide a solid foundation to build effective implementation of both bar codes and RFID, identify interoperability requirements, and point to further research needs. The guidelines can be based on “use case scenarios” now being developed.

To me, success will be the effective use of all AIDC technologies to improve “visibility” throughout supply chains. This includes network connectivity and supporting data collection and management. A much expanded AIDC vision.

August 2, 2004

RFID & Bar Codes

Bob Scaringe

The article suggests some solutions to the problems cited and illustrates the premise that the technical issues will be overcome. Nobody that I know of has come out and said there are stoppers that can’t be overcome. I don’t think you are saying that either Chris.

I have to tell you that the whole adoption cycle of RFID sounds eerily similar to the RFDC technical issues raised in the 80’s relative to interference from cell phones, security systems, fading due to reflections and even the non-technical issues of security of the data being transmitted and health concerns of more RF are all arguments we have heard before that were overcome.

The suggestion is: do we (as a group) believe the technical/soft issues will be overcome? Then, what position do we take (as a group) relative to its’ adoption. Maybe there should be a discussion and vote at the meeting.

August 2, 2004

RFID & Bar Codes

Chris Kapsambelis

In response to the message from Bob Scaringe, I would like to refer the membership to the article by H.L. van Eeden that appears on the latest issue of RFID Journal.


Mr. van Eeden goes into great detail concerning the problems associated with the use of multiple readers and antennas.

July 31, 2004

RFID & Bar Codes

Dick Meyers

Over recent months, I find most interesting many inaccurate articles in the press about the “coming” of RFID and the “death” of Bar Codes! We should put this movement into proper perspective without reinventing the wheel! This dialogue reminds me of the same events that occurred 20-30 years ago when the food industry dictated the use of UPC and the DoD/Auto industry dictated the use of Code 39. Many of the same discussions took place then that are now occurring on the topic of RFID.

As an industry, we should take advantage of what happened years ago and smooth the implementation of a newer technology in a complimentary fashion by using it where the APPLICATION warrants. It would be more efficient if both “users” and “suppliers” worked TOGETHER to formulate RFID schedules and marking levels along with the most effective applications. In addition, clarity should be established relative to the continued use of Bar Coding.

The aforementioned goals are precisely what “Truth in Technologies 2004: RFID & Bar Codes” on October 20th are all about. Attend and learn the real truth from the prime players including users, suppliers, consultants, technology providers plus many expert members from the AIDC 100! Participate in this unique forum and contribute to the enhancement of the AIDC industry. You will be richly rewarded.

July 30, 2004

RFID & Bar Codes

Chris Kapsambelis

I was disappointed with the agenda for the above subject. The simple fact is that RFID, in the form that is proposed for use in the supply chain between large retailers and their suppliers, offers no advantage over Bar Code, and is more costly. The agenda focuses on problems of RFID implementation and compliance, and fails to mention anything about the merits of Bar Code. Where is the “Truth” implied in the title?

Proponents of RFID point to the fact that RFID does not require a Direct Line of Sight to read a tag, while Bar Code does. This is the property of RFID that, proponents say, will permit the complete reading of Item tags, Case Tags, and Pallet Tags as they pass RFID readers at strategically located portals. I maintain that, in its current form, RFID does require a Direct Line of Sight and, therefore, is not superior to Bar Code. A closer examination of the proposed form of RFID technology will show why the above statement is true.

In order to achieve the low cost requirement for RFID, the focus is on passive tags with a printed circuit, high Q, tuned, loop antenna. By its very nature, this results in a two dimensional tag very similar to a barcode label. Some traditional barcode printer suppliers have introduced printers that can print and encode labels/tags with some of their printers.

Radio loop antennas are highly directional, and require that the face of the label/tag be orthogonal to the reader in a straight line. Otherwise, they fail to read. This is the same technology that has been used for Radio Direction Finding(RDF). We are all familiar with old movies showing German army vans with a loop antenna on the roof being rotated slowly to determine the direction of the spy’s radio transmitter frantically sending a message in Morse Code.

The directivity of these tags renders them equivalent in performance to Bar Code labels with the exception that RFID can read through some non-conductive materials such as wood and plastic. However, since they cannot read through or around metal, metal film, and practically all liquids, this property is almost useless. With Bar Code, you can at least see what you are reading.

The need to ensure an orientation in a straight line, unobstructed by metal or liquid, between the reader and all the tags, as well as, the requirement that all tags must be facing the reader, makes the task of reliably reading a pallet of cases completely impossible.

As far as using Singulation and Aggregation to make up for unreadable tags, these techniques can also be used with Bar Code, and the solution is both cheaper and more flexible.

As for the concepts of PML, ONS, and SAVANT they apply equally to Bar Code and RFID. If they can be justified for RFID, they can be justified for Bar Code.

One of the truths that has to come out of this conference is that unless the use of active tags with dipole antennas, oriented vertically, similar to cell phones, are adopted, very little of the hype associated with RFID will come to pass.

There is no need to continue testing the current form of RFID. Anyone with a rudimentary knowledge of Radio Frequency Electromagnetic Waves and their propagation can easily analyze this technology and come to the conclusion that it will not work as currently proposed.

There are many other differences that favor Bar Code, but if what I have said so far does not concern anyone, there is no point in continuing the debate.

July 30, 2004

RFID & Bar Codes

Ed Barkan

Nobody is more pro-barcode than I am, but I am concerned that we, as a group, can be so intent on pointing out the flaws and misconceptions of RFID that we fail to acknowledge that it will probably find useful applications, and many of them may well have been impractical to do with barcodes. When this ultimately happens, we don’t want to be perceived as having taken the position that RFID is only a dream that will never amount to anything, or we will lose credibility as an organization.

I think our duty at this time is to be perfectly honest and open about the relative merits of barcodes and RFID. This will make it clear that much of what is said in the popular press, such as RFID replacing barcodes at POS, is unlikely to be practical in the foreseeable future.

I would also hesitate to claim that some of the issues pointed out here are insurmountable. For example, there has been discussion about the fact that the antennas on RFID tags are directional. This is true, but some of the greatest interest in RFID is coming from people who are interested in tracking objects that are moved through a portal, either on a conveyor belt, a fork lift or even manually carried. In these situations it is quite practical to mount multiple antennas around the portal to compensate for the directionality of the tags. There may be ways around some of the other limitations of RFID tags as well, although they may limit the areas where deploying them will be practical.

July 30, 2004

RFID & Bar Codes

Clive Hohberger

While bar code are “Ooohhh… sooo 20th century!” as my college-age daughter would say… as one involved in both bar code and RFID for many years, and one involved in the REG developing guidelines for RFID deployment by DoD (read NATO), my view has become that I do NOT believe RFID can be successfully deployed without bar code back up… any more than we could have deployed bar code in the 70’s and 80’s without human readable back-up.

1) UHF RFID tag non-read rates are still too high, due to transponder damage, aging, RF effects of the packaging on the tag (a huge unrecognized problem), poor transponder antenna design, reader cross-interference, and tag sensitivity variations due to chip-to-chip and transponder manufacturing quality control issues. Pilot studies of UHF RFID have not anywhere approached the 99+% read reliability rates we saw with 13.56 MHz RFID in baggage handling.

2) Generation 1 Class 0 and 0+ UHF tags are read-performance focused, actually work quite well in pilots (and Zebra is supporting many pilots right now). My bet is that 96-bit Class 0+ tags are a good model for Generation 2 tag performance. This proves that Generation 1 tags CAN do the job, when transponders are performance optimized. But the successful Class 0 transponder designs are more expensive than most of the cost-oriented Generation 1 Class 1 designs, because…

3) The obsessive focus of Wal-Mart suppliers on reducing UHF tag cost has aggravated many of the transponder and smart label quality issues above. You can’t have sophisticated transponder antennas, test in quality and have low cost simultaneously. This just increases the probability of a non-read in practice, especially for cost-focused Generation 1 Class 1 tag designs.

4) Generation 1 tag designs are not nearly as well thought out as the Generation 2 Chicago Protocol in dealing with issues such as activation by multiple readers simultaneously in a cross-docking environment. Wide-scale Generation 2 production is probably mid 2005. This implies that…

5) Unfortunately, initial deployment will be with Generation 1 tags, a great deal of which will be cost-focused designs.

6) Most importantly, there is a huge sea change in the supply chain business model, which is why we are deploying RFID! A pallet no longer consists of 48 identical product code-labeled boxes. With RFID you have to deal with 48 serialized cases, each of which can and must be tracked separately once the pallet is broken. That’s the whole point of the technology change!

7) If you can’t read the RFID tag on a case, you lose the serialized information, as current EAN.UCC bar code standards don’t incorporate serialization. All you can retrieve from the bar code is the GTIN or product code.

8) Therefore on the DoD Military Shipping Label, we proposed adding a field to the master PDF-417 bar code using Data Identifier 96S to carry the EPCglobal or DoD tag data structure as a bar code back up to the RFID tag!

9) There is a raging discussion within the UCC and EPCglobal community about the need and form for bar code backup of the EPC tag in the commercial sector. It started last spring in the GSC meeting in Ft Lauderdale, and I believe this issue must be shaken out by the end of the year. Its basically an issue of providing CONTINUITY between EAN.UCC bar code standards and EPC RFID standards for supply chain management.

10) I believe that the change in business processes to individual serialized case tracking is so fundamental that bar code back-up is essential to the successful deployment of the current EPCglobal Generation 1 RFID technology. Otherwise, cases with unreadable tags will lose their serialized identity, and not fit into the new inventory management IT system.

Granted, there will be coexisting “bar code-based product code-only systems” and “serialized case code RFID-based systems” for a long time, but at the IT level you don’t want to deal with serialized cases being “lost” to the product code-only system just because the RFID tags gave a no-read. Aside from creating a nightmare inventory management problem, you lose the business benefit of the RFID tag, and the ability to recover its cost in the new business process. A back-up bar code for the EPCtag allows you to avoid the inventory management, and to keep the serialized case in the appropriate tracking system.

An Analogy: Think about last few visits you made to the supermarket… how many bar coded grocery items had to be entered from the human readable on the package? And how did the cashier.. and the store IT system… manually handle UPC or EAN-labeled items where the bar code on the label was missing, ripped or unreadable?

Now imagine how this must be done in a DC on a conveyor running at 500 feet per minute when an RFID tag gives a no read!

July 30, 2004

RFID & Bar Codes

Andy Longacre

One more interesting observation regarding RFID and it’s claimed advantage of not requiring line-of-sight reading: objects that would interfere with reading -also- need not be in sight! When a barcode is obscured from reading, the operator can know it. When an RFID tag is “obscured” from reading, the operator (a) might not be sure there’s even a tag to be read and even if so (b) might have not a clue what’s around to interfere with its being read. The out-of-sight character in RFID is also an Achilles heel.
Viva barcodes!