As you know by now, I'm working pure free software implementation of RFID support for our library. This time, I decided to tackle problem of printing RFID cards using EVOLIS Dualys printer.

This is experimental support for EVOLIS Dualys 3 printer with black ribbon (K) to provide pixel-exact driver with support for two-side printing.

Existing cups driver is available at

http://www.evolis.com/eng/Drivers-Support/Product-support/Dualys-3

but I haven't been able to make it print on both sides of cards, partly because using duplex option in cups seems to segfault GhostScript and/or rastertoevolis cups filter depending on combination of duplex options.

I also needed pixel perfect transfer to printer, and cups bitmap format is always in color, leaving final pixel modifications down to cups filter which always produced differences between file sent to printer and perfect black and white rendition of it.

SCRIPTS

Current toolset consists of following scripts:

• inkscape-render.pl card/template.svg 201008159999 login Name Surname

  Generate pdf files from Inkscape SVG template in card/ using print-front and print-back object IDs. Layers doesn't work since we can't toggle visilbity easily. To print more than one object gruop them and change ID of group.

  After pdf files are created, GhostScript is used to rasterize them into pbm (monochrome) bitmaps.

• evolis-driver.pl front.pbm back.pbm > evolis.commands

  Provides driver which generates printer command stream to print two-sided card from pbm files.

• evolis-simulator.pl evolis

  Simulator for EVOLIS printer commands which is useful for development. It creates one pbm file per page printed.

• scripts/evolis-command.pl

  Command-line interface to send commands to printer and receive responses. Supports readline for editing and history. Requires local parallel port connection, probably to USB parallel device.

EXAMPLE

Following is simple walk-through from svg image in Inkscape to evolis command stream which can be executed in top-level directory of this distribution:

  ./scripts/inkscape-render.pl card/ffzg-2010.svg 201008159999 Ime Prezime
  ./scripts/evolis-driver.pl out/201008159999.front.pbm out/201008159999.back.pbm > evolis
  ./scripts/evolis-simulator.pl evolis
  qiv evolis*.pbm

Allmost two years ago, I began my experiments with RFID, writing support for 3M 810 RFID Reader. Then I tried to make web interface for RFID it in Koha.

This woked, but having separate Comet server was too much complexity for me, so I decided to implement JSONP directly in RFID driver code. Hack, I allready had HTTP server, and local JavaScript interface, so why not?

Move to JSONP allowed me to use original Koha web interface, and just overlay RFID information and form submission code as simple jQuery snippet.

But, two years of development and trying out different approaches produced not-quite-production-quality code. So, I began rewrite called Biblio::RFID. It splits RFID reader support from HTTP and JSONP servers and couples this with documentation and tests. I have production use for it this summer, involving programming of RFID cards as they are printed out, so expect it to change during next few weeks. After that I will push it to CPAN, but I would love to get feedback and comments before that.

Update: It's also availale at CPAN.

I had OmniKey CardMan 5321 reader sitting on my desk for quite some time. First time I tried it, I had problem with propitiatory binary driver which expected pcscd to be compiled without hal support to make it work.

Fortunately, we now have pcsc-omnikey package in Debian which should make usage of this reader much easier. But, I really wanted more low-level implementation, allowing me to muck with cards without need to pass through whole smart card stack (since I'm really only interested in RFID part of this reader).

So, I did some searching and found out that librfid - A Free Software RFID stack implements support for this reader, so here is a quick overview of how to get started:

# build dependency
dpavlin@klin:/rest/cvs/librfid$ sudo apt-get install libusb-dev

# checkout source
dpavlin@klin:/rest/cvs$ svn co https://svn.gnumonks.org/trunk/librfid/
dpavlin@klin:/rest/cvs$ cd librfid/
dpavlin@klin:/rest/cvs/librfid$ ./autogen.sh

# build
dpavlin@klin:/rest/cvs/librfid$ ./configure --enable-ccid
dpavlin@klin:/rest/cvs/librfid$ make

Now we can test if our reader is working:

dpavlin@klin:/rest/cvs/librfid$ sudo ./utils/librfid-tool -s
lt-librfid-tool - (C) 2005-2008 by Harald Welte
This program is Free Software and has ABSOLUTELY NO WARRANTY

initializing librfid
opening reader handle OpenPCD, CM5x21
No OpenPCD found
scanning for RFID token...
Layer 2 success (ISO 15693):  eb 6e 77 1f 00 01 04 e0

And, that's not all. We can also read content of our tag:

dpavlin@klin:/rest/cvs/librfid$ sudo ./utils/librfid-tool -r -1
lt-librfid-tool - (C) 2005-2008 by Harald Welte
This program is Free Software and has ABSOLUTELY NO WARRANTY

initializing librfid
opening reader handle OpenPCD, CM5x21
No OpenPCD found
Layer2 init ok
Layer 2 success (ISO 15693)[8]: ' eb 6e 77 1f 00 01 04 e0'
block[  0:00]sec:0x8 data(4):  04 11 00 01
block[  1:01]sec:0x8 data(4):  31 33 30 32
block[  2:02]sec:0x8 data(4):  30 32 39 37
block[  3:03]sec:0x8 data(4):  31 30 00 00
block[  4:04]sec:0x8 data(4):  00 00 00 00
...
block[ 26:1a]sec:0x8 data(4):  00 00 00 00
block[ 27:1b]sec:0x8 data(4):  57 5f 4f 4b
no data(read_block(28)>> -1)

It's exactly what I was looking for: ability to do low-level block transfer with RFID card.

This is great news since I don't have to carry bulky 3M reader and antenna with me to conferences to demonstrate RFID. Since I didn't find librfid first time I searched for software to drive this reader, I hope that this post will be helpful to someone.If you intend to buy RFID reader, take a look at OpenPCD instead of this one :-)

I already blogged about RFID readers but now I really need to replace antique 3M software with something better. So, basically, I started with specification:

User should put RFID tag on reader and get output from Koha

Nice and simple. However, readers are connected to Windows machine. And we need some way for reader to push data about new tag to browser. Hmmm... push? Sound like Comet, doesn't it?

Let's see what we need:

1. Comet server to display page in web browser and push updates
2. RFID reader program installable on Windows to communicate with serial port and push messages to Comet server
3. User with a browser

Again, seems somewhat reasonable. Can perl do it? It seems it can:

1. Meteor server provides perl comet server which required one additional file to provide integration with Koha.
   I needed comet server to deliver Koha data because of single origin security in browsers which doesn't allow me to make AJAX requests to Koha directly. On the other hand, this gave me excuse to try out HTML::Query to extract part of page which I needed on server.
   I liked this split between Koha and Comet server (even on different boxes and/or network segments), but it came with a price: every page generated in Koha took more than 2 seconds, which was just too slow for nice interactive demo. So, I implemented on-disk caching which is also really nice for debugging. In production version, requests for Koha data might be implemented as forkers (since browser uses AJAX request for it, it makes sense) or I will issue queries directly over Koha's database.
2. Next step was to add push from my perl RFID reader to Meteor.
   This also turned out to be simple: one socket connection to Meteor, and few revisions later I had more or less following protocol which reader could push to comet server as pipe | encoded string:

   meteor( 'info', "Found reader hardware $hw_ver" );
   meteor( 'info-none-in-range' );
   meteor( 'info-in-range', join(' ',@tags));
   meteor( 'in-range', $tag );
   meteor( 'read', $tag ); 
   meteor( 'removed', $tag ); 
   

3. I also needed web interface in browser.
   When I need to do something quickly I often turn to jQuery as long time readers of my blog already know. One additional javascript file in Meteor's public_html directory and we have a working interface.
   At first, I created JavaScript object (like hash in perl :-) to keep track of visible tags on screen. But, since each tag is div which has id set to SID of tag, it was easier (and shorter) to just use jQuery to ask DOM if there is element on page. KISS wins again...

So how does it look, you might ask? (You might want to turn volume down, because AudioSwap feature of YouTube should be really considered harmful :-)

This might help solve question is perl dead. Only if it means dead easy. it's 4k of perl code, 4k of JavaScript and 4k of CSS.

Last week I was playing around with understanding serial protocol between RFID reader and computer. For a start, I had a windows application which could communicate with RFID reader over USB serial adapter (which is included in device, so device looks like USB device).

First, I needed to sniff USB serial traffic under Windows to understand protocol between device and program.

Then I wrote a simple script to reformat output from portmon to more readable format, and found out that packets have two byte checksum in them.

After I tried all simple combinations to produce valid checksum, I decided to ask a question about checksum guessing at stackoverflow.com. This was great idea, because selwyn stepped in and confirmed that my checksum is CCITT.

Having all that parts in place, next step was to write perl script using Device::SerialPort to communicate with serial port, and thus RFID reader. Right now, I'm pondering how to integrate it with Koha, but that's topic for another post...