02. September 2012 · 5 comments · Categories: Uncategorized

Last week I was lucky enough to visit my first UHF RFID library installation at the University of  Pécs in Hungary. My host for the morning, Tamás Markó  is the current head of the Informatics Department and oversaw the implementation of RFID in the magnificent new library building.

The system was supplied by ODIN Technologies of Budapest who have a growing number of clients in Hungary and its neighbours. Interestingly ODIN also operate in Tokyo – another market showing a keen interest in using UHF for library installations.

Pécs followed the example of other Hungarian libraries in choosing to use UHF tags rather than the 13.56 MHz HF tags used by the majority of UK libraries. Cost was one factor in making the decision – UHF tags typically cost only 30% of the cost of HF tags – but my host acknowledged that a major factor in making his choice was the precedent of other libraries having done the same. There is something very comforting in seeing an operation working – it is after all the reason why most UK librarians chose to follow the example of their peers in choosing HF for their libraries.

So what are the obvious differences between UHF and HF?

Well for a start the tags look very different to HF. Over a million tags like the one pictured left were inserted into stock by the staff at the university which runs libraries on a number of sites across the city. Barcodes are still in use since many sites do not yet have RFID facilities. Since UHF tags carry no data (unlike HF) the library managements system (LMS) – Voyager – has had to build a new table in the database to match the unique ID in the tag created at the time of manufacture with the item ID already used internally – the barcode number.

The communication of tag information is also rather different. Voyager and ODIN have created their own protocol for exchanging data. Endeavor was rather late to implement SIP and many sites – including Pécs – don’t use SIP for communication. Whether this will change with Voyager now being in Ex Libris ownership – or with the future of SIP being rather uncertain – remains to be seen.

Another striking difference – for me – was the positioning of the self-service units. Tamás was kind enough to walk me through the issue process at one of the units positioned on each floor of the library building. Units are positioned as far from the shelves as possible to reduce any risk of reading items not being borrowed. The units themselves also use a ‘V’ shaped wedge to limit the number of items that can be placed on a reader simultaneously.

Every floor still has a large issue desk with at least two staff attending to the needs of library users. The library is in fact a joint venture between the university and the public library of Pécs and I found that staff in most areas worked in pairs from both organisations. The presence of so many issue desks prompted me to ask what percentage of items were circulated using self-service. The answer – about 5% – might surprise many UK librarians.

I asked if staff liked the self-service units and was not too surprised to hear the same view I have been hearing for some time now in libraries all over the world – “they are worried about losing heir jobs.”

The actual process of issuing items and clearing security is also very different. All library users carry an RFID access card which is used to trigger the loan process. Items for loan are placed on the reading table and are read only after the user places their membership card on a small reader adjacent to it.

The security process is entirely managed by the LMS. Since UHF tags carry no data they cannot be used – like HF tags – to carry a security bit. In most HF based systems items presented for issue will be checked against the LMS to determine whether or not they may be borrowed and if they are the RFID unit will be instructed to set a data bit to “clear” to allow the item to leave the library without setting off the alarm system.

With UHF this doesn’t happen. A small scanner set into the ceiling near the exit gates constantly monitors all the items it can ‘see’ in the exit area. This includes a number of items in a display case opposite the gates. False alarms were common until staff issued all the items on display to a ‘dummy’ borrower. A borrower passing the gates must wait for the scanner to read all their items as well as all the items in the display cabinet – check with the LMS that all the items it can detect have been issued – and then allow the gate to open. Library users have to scan their membership card as well. It was not clear to me what happened when more than one user tried to pass the gates with prohibited items at the same time.

I’m looking forward to renewing my acquaintance with Tamás when we both speak in Berlin later this month. I’ve already thought of some more questions I should have asked!




  1. For reasons that are unclear to me very few people comment on my blog preferring instead to email me directly.

    This is a shame as it makes it difficult to enter into an open dialogue on important issues in a public forum. So, just for a change I’m publishing these comments from Gary Kirk of Tech Logic that were sent to me and the UK and US lists earlier today – so I can respond here at a later date.


    Wow! I am happy that UHF is working for that university. I have a few observations that I would like to share. But before anyone comes to the conclusion that I am biased, let me be clear that I have nothing against UHF as a solution for libraries. Sure, I provide HF solutions for libraries but I have no problem accepting the evolution and improvement of technology.

    So UHF tags are one third the price of HF tags. Now that HF tags are priced in the mid teens (as in cents), tag prices no longer determine whether a library decides to invest in RFID. But the price difference of equipment (readers, antennas, security gates and portable devices) between UHF and HF is usually significant with UHF being MUCH more costly.

    The checkout process you described seems very cumbersome and puts a lot of responsibility on the patron. And the security process? Making the patron stand in a holding area while big brother (overhead reader) scans you from above before a gate opens to let you leave? Really?

    That process might be acceptable in a university with low circulation volume. But I suspect public libraries in the US would have a difficult time coping with that. Most libraries we work with are trying to achieve as close to 100% self service as possible by making self service easy. Given the process described in your blog, it’s really no wonder that self service is only reaching 5%. It makes me question why any library would invest in technology with such a small ROI.

    That said, having closely observed the evolution of RFID technology for the past ten years, I am confident that both UHF and HF will only get better and better with time.


  2. I had a number of responses to this post of which Gary’s was the longest and most helpful.

    I’d just like to be clear that I wasn’t in any way suggesting that UHF offers advantages over HF for all those libraries that have invested heavily in HF. It’s a choice the librarians make for themselves. My hope is that they make these choices based on need and understanding but – as I think the Pecs implementation demonstrates – they often simply choose to follow the example of their peers.

    In itself that may not be a bad thing. There may be characteristics of the market in which they operate that dictate – or at least suggest – a different approach might work better locally. In this case the desire was to invest in state of the art technology. The only other example in Hungary was already UHF so they went with that solution. The criteria against which they judged success were very different to those that might (but often aren’t) used in the UK (or other English speaking markets it would seem). The fact that only 5% of circulation is carried out using RFID was not a concern. Neither was the continued presence of issue desks on every floor – staffed by university and public library staff – or indeed the human resources to man them.

    We could point out that their choices may be limited in the future as a result of using UHF – but no more than the choices of most UK libraries in having elected to use proprietary HF solutions in their libraries. Luckily for those making that decision there is a way out of their dilemma if they want to take it. Not the case for most UHF solutions since the tags themselves differ considerably. Most HF solutions use tags that can support data and at least one security option (AFI or EAS) many UHF tags – like those in Pecs – carry only an ID, and have to be checked against the LMS to manage security.

    Suppliers almost always over-simplify any difficulties with RFID, librarians almost always underestimate both its complexity and its potential. I think Pecs has a solution that satisfies their main requirement very well, but it is very hard to see how a busy public library in the UK could make it work for them.

  3. You asked for comments on your blog, so I have added some technical points to ponder here rather than post them on the list.

    The main problem with UHF library implementations to date is that they have been undertaken independently of considering many of the standards that are in place or in development. I am not talking of the recently approved ISO TS 28560-4 for libraries, but long-standing ISO RFID standards for hardware, software and communication protocols.

    There has also been a drive for a cheap and cheerful basic UHF tag that, as you indicated in this Hungarian example, only supports the encoding of a unique item identifier. The facts are fundamentally different for UHF technology:

     There are UHF tags available with sufficient memory to encode the basic requirements of data elements supported in ISO 28560-1.

     In fact, the proposal for ISO/TS 28560-4 from BSI provides encoding rules for all of the data elements supported by ISO 28560, with the flexibility for libraries to pick and choose which data elements are more appropriate for their application. This proposal would not have been made if there were no products on the market to support this.

     The speed of data transfer for the UHF technology is significantly greater than with the present HF technology being used by libraries today, so completely different business functions could be conceived for producing a better ROI. Limiting the use of UHF to circulation control is probably not the best way to achieve even medium term ROI.

     There are security mechanisms that can be implemented in the UHF tag. Some even exist in the basic tag that only supports a unique item identifier. Whilst these will necessarily differ from those for HF, they are there to be exploited and I expect them to be defined in ISO TS28560-4.

     One of the replies on the list proposed using a proprietary EAS mechanism. I guess this means that the UHF library world will have to address the complexity of what is interoperable and not for security that was necessary when developing ISO 28560 for HF applications.

    One thing that completely puzzled me about the Pécs implementation is the issue about having to “build a new table in the database to match the unique ID in the tag created at the time of manufacture with the item ID already used internally – the bar code number”. This just seems to be completely illogical as the UHF tag in question should come with a completely blank unique item identifier field. This is another example of not looking at existing standards to see how things can and should be done. The GS1 EPC system, airline baggage handling, automotive parts and containers, aircraft components, US Department of Defense and NATO, to name but a few, are all able to encode their own numbering system within the UHF tag. There is nothing within the technology that constrains a plain vanilla library bar code number and the unique item identifier in the tag being equivalent to one another. This has already been addressed in the proposal for ISO/TS 28560-4. But the “bar code number” could have been done in a proprietary manner for this Hungarian library.

    You also mentioned the communication of tag information. There is already a well-documented set of standards – some even supported with open-source software – for communicating the data (all or any of the data) from the UHF tag to an application. By its nature, such standards are generic and agnostic of applications, so obviously are different from SIP. The point to make is that they do not need to be proprietary.

    The issue will arise as UHF technology is adopted in a standardised way in libraries whether the standardised UHF communication protocols are used or whether SIP or any other accepted protocol in the library community is used. What is probably more likely is that the basic communication from the interrogator to a front-end application will use ISO communication protocols and then there will need to be mechanisms to interface with SIP. We also have to recognise that SIP, or any of the other library protocols, do a lot more than read data from a bar code or an RFID tag. Another option is to by-pass SIP and communicate with the ILS/LMS – but taking full account of ALL the data elements defined in ISO 28560-1.

    There are other technology based points raised in your blog which I find a little puzzling:

     I am in a similar mind to Gary Kirk of Tech Logic about being a little mystified about how the security system works and the need for it to control the open of gates. This is certainly not the modus operandi of other UHF systems in libraries that you have reported on in the past.

     If UHF readers are such that they interfer and read items on shelves as well as a self-service checkout (as cited in your blog) then how can a baggage sortation system in an airport read the details of an RFID tag on luggage moving at the fastest conveyor speed distinguish between the tags (and therefore the sortation decision) between two items of luggage that are less than a metre apart? The answer is that the system has to be configured in such a way as to achieve the business operational functions. As RFID is introduced into the retail sector, it would seem crazy that the shopping for the Jones family is accidentally scanned and charged to the Smith family’s purchases. Any retailer – and RFID technology – would rapidly lose reputation if this issue was not addressed and designed-out.

    It seems that there is a lot more to do than standardise the encoding to get the benefits of UHF in libraries.

    Paul Chartier
    Managing Director
    Convergent Software Ltd

  4. Thanks for the comments Paul – here and on the lists. As I said in the original post I have a great many more questions to ask in Berlin next week!

    To address the point raised by both you and Gary – the scanner. My picture doesn’t make clear that there was a single scanner fixed to the ceiling that I was told constantly scanned the exit area. The items that had to be “issued” were in cabinets about 5 metres from the exit gates – which were in fact turnstiles that required the borrower’s card to be presented to another scanner (I think these were Mifare cards) – to operate. What was not clear – and which was probably lost in translation – was whether the gates opened on presentation of the borrower card anyway – and what happened when the overhead scanner detected an un-issued item. I will try to find out next week.

    I am aware that other UHF installations use the technology in different ways – and that there are scanners that read at much shorter range than on this site. I was merely reporting what happens in Pecs. Similarly I don’t know why Endeavor decided to build an extra table in the database.

    As you suggest – there is clearly a lot of work to do to develop systems that can be more readily developed to deliver real innovation – but I think that applies equally to HF as UHF. The key point I was trying to get across was the need for librarians to get to grips with the technology themselves rather than passively accepting whatever they are offered.

  5. I fully appreciate that you were simply reporting and I was not challenging that nor your knowledge of RFID. What concerned me – and obviously Gary – was that this particular implementation had some rather unusual features. I was trying to explain to your followers that this was not a function of UHF technology, but of the implemtation design.

    I can see that you have lots of questions for next week.


Have a view? Please share!