RFID Liason


University of Arkansas – CSCE Department

RFID Agent Middleware – Final Report – Fall 2006

RFID Lab Liason

Sean Bruce

Abstract

I am responsible for three main things: communication with the RFID lab, helping to facilitate testing at the lab, and research.

Problem

How do we encourage the RFID lab to use our software? How do we communicate effectively with the lab? How do we access information that only the lab has access to?

Objective

The objective of this position is to achieve a level of interaction and cooperation not achieved before with our RFID testing center. Email alone has shown itself to be relatively worthless. Through personal interaction, by making our presence known and felt we hope to achieve these goals.

Approach

Background

No known cases of the RFID class using liaisons exist. All interactions up until this point have been sporadic trips to the center and email.

Requirements

The person in this position should make an effort to visit the testing center at least once a week. Face-to-face interaction is the best route to achieving an understanding of the center’s perceptions and needs. These can then be communicated to the class or project leaders.

Achievements

In the three categories of objectives, testing, communication, and research I believe a number of things were achieved through this position:

Testing

I helped facilitate the middleware testing in the RFID lab, including installing new versions, encouraging use, and performing some experiments designed by Joe on actual test equipment at the lab.

Communication

Feedback was gathered from anyone who had used the software; this was then communicated to the RFID class, resulting in a large list of bugs and potential improvements. I believe that a face to face connection is superior to email in that it made the RFID class’ presence known and felt at the center. Also, I gathered progress reports/updates about the center’s current projects and testing.

Research

I was able to use the centers resources to gather API’s and developer documents that our class did not have access to. I also was able to understand and relate functional issues of the equipment through interacting with the testers.

Tasks

  1. Understand the RFID Class’ direction and purpose
  2. Understand the RFID Testing Center’s direction and purpose
  3. Find common ground and promote a plan that will benefit both parties.
  4. Test software changes and test cases
  5. Report/Communicate back with RFID project members

Schedule

Fall
1. Understanding … /
2. Understanding … /
3. Find … /
4. Test … /
5. Report /

Deliverables

·  Reports

·  Related Test Cases

·  Final Presentation

Key Personnel

Sean Bruce – Bruce is a senior Computer Engineering major in the Computer Science and Computer Engineering Department at the University of Arkansas. He has completed relevant courses.

References

[1] Architecture document (??)


9/9/2006

Ok, I've been thinking about this ... Let me preface all of this by saying, coding is probably one of my weakest areas, and I've never coded in Java. Now that that's out of the way, let me say how I think I can help the project.
It seems to me that this project is primarily (at least now) aimed at RFID testing labs and in particular our own testing center. (obviously, right?) In order to get them using our software we have to do a few things ...
1-We have to make the software attractive to use. --- it needs to make their life easier and address their specific tasks that they do from a day to day basis. If this hasn't been done, I'd like to spend a few "days-in-the-life" of these guys and figure out what they do most, and how we can make the software more tailored for their use.
2- It needs to be simple. By that I mean, intuitive and as few clicks as possible.
3- They need encouragement to use the software.
So here's what I propose to fulfill my 2 credit hours ... I know Justin (I've had a few classes with him), and we seem to get along alright. I'd like to work with him and the center in addressing their specific needs. I'd like to help encourage our software use with them through a hands on approach where I can find out how to make the software as attractive as possible for them to use. -- This means that my objectives could change ... one objective might be as simple as the reordering of the menu/commands to be more intuitive ... it could be something like figuring out if we can auto-identify readers and their IP's. One thing is for sure, whatever the objective, it will come directly (or perhaps indirectly) from the feedback of the lab testers.
In the process of this, I could also get some testing done since I'll be down there anyway.
The main goal is to have the center using our software by the end of the term (if you guys think it's ready). One part salesman, one part concierge, one part intelligence gathering/implementation, one part testing.

9/21/06

I just got back from visiting the RFID lab and got some good feedback. I figured sine it's fresh on my mind now, I'd sit down and write out what we talked about at the lab.
They're in the middle of doing a huge test run on all types of readers with all types of tags and middleware. The good news, TagCentric appears to be the favorite of the lab testers by far (although they have not had a chance to test MS software yet - problems getting it to run I think). We also seem to perform quite well on unfiltered 200ms runs; performing as well, if not better than the manufacturers own middleware. We don't fare quite as well when we run any type of filtering, or at the 1000ms mark (filtered or not). Of course, not all the data is in yet, they're just a little under halfway through. I've collected the percentages so far and I'll give them to you guys when we meet next.
Joe, you asked about the upcoming test they were going to be performing at the lab. Justin explained to me that basically they were going have a walkthrough simulation of tags entering and leaving various stages of the inventory process. i.e. - Distro center dock doors, store receiving, and POS ... etc. So basically they're going to use our software to monitor 7 different readers at once, and the DB output is going to a third part software package to show manipulation of that data (tag tracking, etc). Justin hasn't picked out a DB software package yet, but he said he would be doing so soon based upon the DB's that OUR software can support. :)
Ok, I'll go into TagCentric feedback now. These guys are basically doing tons testing for us in all kinds of situations in a very systematic way. The number one issue for them seems to be Impinj reader support. If they had this, they would be able to complete all tasks using TagCentric. -- This was emphasized as their number one priority, and all other issues are listed below as "little issues" that need some attention in their view (after Impinj support)... some bugs, some functional issues, etc:
1 - When loading a query, on the second dialog box, if nothing is selected and cancel is pressed, an error appears "no.input received."
2 - It would also be more convenient if loaded queries automatically executed when selected, instead of the user having to press 'submit query.'
3 - They would really appreciate if runs started from '1' and not '0.' For them (as they're not computer scientist), it's not intuitive to start from 0.
4 - They believe that polling should default to 200ms, as almost all 1000ms reads are not acceptable.
5 - Also, filtering seems to degrade results from all readers significantly, sometimes by as much as 20%.
6 - In performing runs, it would be useful to have the start/stop buttons as one toggle button, instead of two separate buttons.
7 - Also in testing, they sometimes perform up to 30 batch runs. If they mess something up on the 29th run they either have start over again, or edit out the data from the output. They would like some kind of undo/redo feature to erase the last run and redo it.
8 - Occasionally when you start up the DB agent the window background is blank.
---- Feature Requests ----
One of the variables that's affecting testing that's currently unaccounted for is speed of the tags through the readers. Though it's probably low on the priority list, they would like some way to measure this. Perhaps setup an electronic eye that would measure the in and out time of the pallet/product to assess the velocity of the tag through the reader?
So there you have it, my first visit seemed pretty productive. The next question is, how are we going to address these concerns?

9/26/06

Set up basecamp project management website http://tagcentric.projectpath.com

10/5/06

Today I brought the new version of TagCentric to the testing center. They were in the middle of running a test, so I was unable to install it for them, but I did, however, make the files and left them with the JAR and instructions to install. Joe, you or I may get an email if they have any difficulties, but it shouldn't be a problem.

Justin informed me that our Impinj guy is waiting on his higher-ups to ok the release of the API to us. Since we have no working agreement with them (as we do with the other manufacturers), it makes this kind of thing more difficult.

I also have the latest test numbers for all the readers which I'll share with you guys next time we meet.

They had a few more bugs/issues to report:

1-The first issue (not really a bug), mainly concerns Alien readers, but would be a welcome feature on the other readers as well. Essentially, the way that alien's firmware is setup, one has to manually change in the firmware how many antennas are connected. (Anywhere from 0-4 ... other readers auto-detect the antenna's). This is problematic with TagCentric because there is no way in our software to do this. The testers must load Alien's gateway software and change the antenna numbers any time they want to reconfigure their test setup, which happens a lot. Nick also reports that Impinj will be setup this way as well.

2-It appears that our Symbol agent queries readers suboptimally. Nick reports that while reading through their API he discovered a query string that should theoretically improve our read rates. The native poll period of the reader is somewhere along the lines of 2-3ms. Right now the way our Symbol agent is written, queries occur every 200ms or 1000ms, instead of the reader reporting all tags it has read in the last 200ms or 1000ms, it only performs reads at THOSE intervals. (hence the huge disparity in testing results from symbol readers when moving from 200ms to 1000ms) He reports that the following is a query combination that will show all the tags since last read (storing them in a buffer, reading at the native 2-3ms) and the second command will only show us the tags from the last run (important for testing purposes):

...queryTag & invtag=1

cgi-bin/dataProxy?Open=purgeAllTags.

He believes that the prefix of the first canned query can remain the same as what we currently have, and we just need to add the '& invtag=1.' The second command will clear out all reads at that point. Check the API for a more detailed explanation.

*Little Bugs*

3- If a reader is on and connected in TC, and the reader is unplugged, the DB switches to another reader, and TC basically glitches out ... introducing weird spacing problems in the interface.

4- If you're using a reader and then you disable it. If you attempt to kill the reader after it's disabled, TC won't let you. (basically if the reader has ever been used, you can't kill it).

5- When you start the database you have to hit refresh to populate the reader panel. (annoyance)

11/7/06

Nick reports that the lab is using the MC-9000 series reader. The model on the bottom of the mobile reader says: MC-906R. We could not find an API on their website, only a reference manual for normal use. He's going to get his Symbol interns to check for an API and email it to me if there is one available. We might be able to put an agent on the reader itself, we won't really know for sure what our possibilties are until we can get our hands on an API.

As far as software needs go for tagcentric (besides the antenna configuration problem) Nick reports that it would be nice to be able to tell which antenna the read is coming from, but he thinks the problem is virually impossible to solve. It still might be worth checking into though.

They haven't been testing the software lately as their spectrum analyzer is down, and things have been pretty busy around the lab as of late.

XXX