RifidiWiki - User contributions [en]

Talk:Cloud Jumpstart

2014-07-01T17:43:17Z

Redfern3141: Forgot to sign post.

Question: The content of this page suggests that the example uses Amazon SimpleDB, yet the code sample at the bottom of the page and in the SVN repo uses DynamoDB. Is that intentional, or just a mismatch? [[User:Redfern3141|Redfern3141]] ([[User talk:Redfern3141|talk]]) 10:43, 1 July 2014 (MST)

Talk:Cloud Jumpstart

2014-07-01T17:41:57Z

Redfern3141: Created page with "Question: The content of this page suggests that the example uses Amazon SimpleDB, yet the code sample at the bottom of the page and in the SVN repo uses DynamoDB. Is that int..."

Alien Autonomous Edge Server Guide

2014-06-30T22:13:05Z

Redfern3141: Undo revision 5879 by StevenCollins (talk) - Removing advertising and spam edits

==Getting started==

This guide will help you quickly get an Alien reader up and reading tags on Rifidi Edge. The supported Alien readers are the 9800, the 9900, the 8800, and the 9600. Other versions haven't been tested, but may still work.

*Start the edge server and the edge client. Connect the client to the server.
*Right click on the 'Edge Server' icon in the 'Edge Server View' and select 'New Reader'.
*Select 'Alien' from the drop-down and click 'Next'.
*Type in the IP and port of the reader you wish to in their respective boxes. If you are using an emulated Alien, you can check this in the emulator itself. If you are connecting to a physical reader, you might need to use the discovery tool in the Alien software to find out what the IP and port are if you don't know them offhand.
*Set the username and password of the reader. The default is 'alien' and 'password', respectively.
*Select the reconnect interval (in milliseconds). If you want the Edge Server to keep trying to connect if the reader loses connection while running or if it can't connect to start with, you can set this value to what you want (in milliseconds). If you are unsure, you can just leave it at the default 500.
*Select the maximum number of times the server will try to connect to an unresponsive reader. -1 means it will keep going until it gets a connection. To turn this feature off, set it to 0.

==Setting up an Alien Autonomous server==

To read Autonomously, the Alien requires an autonomous server be set up. If you are unsure of how the Alien Autonomous mode works, consult the Alien documentation.

*Right click on the 'Edge Server' icon in the 'Edge Server View' and select 'New Reader'.
*Select 'Alien Autonomous' from the drop-down and click 'Next'.
*Type in the name you want the reader to show up as on the window, the number of readers you want to be able to connect to the autonomous server concurrently, and set up the port you want the server to listen on on the local machine, then press 'Finish'.

==Reading Tags==

Now that the reader is set up, its time to actually connect to it and read some tags.

*First, click on the reader icon that has appeared under the 'Edge Server'. It probably looks something like 'Alien_1'. Now look at the 'properties' tab at the bottom. There are many properties here, some of which can be adjusted. If you wish to adjust a property, type in the new value you want, press 'enter', then right click on the reader and select 'Commit Property Changes'. If you wish to learn more about a specific property, consult the Alien documentation.
*Right click the reader and press 'create session'. If the IP is correct and the reader is turned on, the session should go to 'green'. If something is wrong, it will stay yellow or go back to red. Check and make sure the IP and port are correct and the reader is turned on if you have trouble connecting.
*Now go to the bottom left window, the 'Command View'. Right click on the 'Alien-Push-Start' folder and click 'create command template'.
*Click on the command you just created, and set the options you wish in the same way you set the reader properties (just with the command instead). You will need to set the AutoStopTimer value (check the Alien documentation if you wish to know more on how the Autonomous mode works), and you will also have to set the IP and port of the machine the autonomous listener server you created is on.
*Now right click on the session you created under the reader and press 'submit job'. Select the 'Alien-Push-Start' job you created, select 'One Time Execution', and press 'Finish'.
*Congratulations! You are now reading tags from an Alien reader.

Alien Example Client

2014-06-30T22:12:37Z

Redfern3141: Removing advertising and spam edits

You can see a list of possible alien commands by sending the 'help' command to the alien reader. However, not all of these commands are implemented in rifidi. See this [[Alien_9800#Supported Commands | List of supported commands]].

<pre>
/*
* AlienExampleClient.java
*
* Created: Dec 6, 2007
* Project: RiFidi Emulator - A Software Simulation Tool for RFID Devices
* http://www.rifidi.org
* http://rifidi.sourceforge.net
* Copyright: Pramari LLC and the Rifidi Project
* License: Lesser GNU Public License (LGPL)
* http://www.opensource.org/licenses/lgpl-license.html
* Author: Kyle Neumeier - kyle@pramari.com
*/
package sandbox;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

/**
* This class shows how to create a program to talk to the alien reader.
*
* @author Kyle Neumeier - kyle@pramari.com
*
*/
public class AlienExampleClient {

public static final String IP_ADDRESS = new String("127.0.0.1");
public static final int READER_PORT = 20000;
private static Socket connection = null;

private static PrintWriter out = null;
private static BufferedReader in = null;

/**
* Initialize the connection and send username/password
* @throws IOException
* @throws InterruptedException
*/
private void init() throws IOException, InterruptedException{
connection = new Socket("127.0.0.1", READER_PORT);

in = new BufferedReader(new InputStreamReader(connection
.getInputStream()));
out = new PrintWriter(connection.getOutputStream());

Thread.sleep(500);
System.out.println(readFromReader(in));
out.write("alien\n");
out.flush();
System.out.println(readFromReader(in));
Thread.sleep(500);
out.write("password\n");
out.flush();
System.out.println(readFromReader(in));
}

/**
* Tear down the connection
* @throws IOException
*/
private void tearDown() throws IOException{
out.write("q");
out.flush();
connection.close();
}

/**
* Get tags back from the alien reader
* @return
* @throws IOException
*/
private String getTags() throws IOException{
String command = "t";
out.write(command + "\n");
out.flush();
String returnVal = readFromReader(in);
return returnVal;
}

/**
* @param args
* @throws InterruptedException
* @throws IOException
*/
public static void main(String[] args) throws IOException, InterruptedException {
AlienExampleClient client = new AlienExampleClient();
client.init();
Thread.sleep(500);
String tags = client.getTags();
System.out.println(tags);
Thread.sleep(500);
client.tearDown();

}

/**
* Read responses from the socket
* @param inBuf
* @return
* @throws IOException
*/
public static String readFromReader(BufferedReader inBuf) throws IOException{
StringBuffer buf=new StringBuffer();
int ch=inBuf.read();
while((char)ch!='\0'){
buf.append((char)ch);
ch=inBuf.read();
}
return buf.toString();
}

}

</pre>

AWID Edge Server Guide

2014-06-30T22:11:23Z

Redfern3141: Undo revision 5882 by StevenCollins (talk) - Removing advertising and spam edits

Awid MPR

2014-06-30T22:11:07Z

Redfern3141: Undo revision 5883 by StevenCollins (talk) - Removing advertising and spam edits

[[Category:developerDoc]][[Category:EmulatorDoc]][[Category:userDoc]]

==Introduction==
The Awid MPR 2010 is produced by Applied Wireless ID. It is a simple serial-based reader that can read Gen 1 and Gen 2 tags.

;Model Number:
:MPR 2010
;Network Protocol:
:Serial
;Communication:
:RS-232
;Antennas:
:1 built-in Antenna, 1 extra port
;General Purpose I/O:
: None

==Basis of Virtual Reader==
The virtual reader is based off of the PDF
===Client Tools===
The main client tools used for testing this program:
;Awid Tool
:The Awid Tool is a client program that ships with the reader. It is the easiest tool to connect with the reader,
;Others
:You can use other tools if you wish, such as the BEA tool, but for any tool that normally connects through TCP-IP, you will need to use a TCP to Serial bridge program. As of right now we have no support for any of these tools from Rifidi, although if you can configure them correctly they should work.

==Getting Started==

===Serial Port Emulation===

This guide was written assuming you are connecting on a Windows XP machine. It may work for other operating systems, but that is not guaranteed.

To get started with the AWID reader, first download and install Rifidi Emulator. Then download and install com0com, a serial-port emulation tool that will allow you to connect with and read tags from any readers you create. In the install options for com0com, uncheck the option where it automatically installs serial ports CNCA and CNCB. While not necessary, doing this will make the creation and maintenance of virtual serial ports less confusing.

http://sourceforge.net/projects/com0com/files/

For a more advanced use of com0com, type 'help' into the command prompt and/or check their documentation. However, for this example we will only create 2 serial ports and link them together.

To do this, open the command prompt with the "Setup command prompt" option in the start menu. Then create 2 linked serial ports by typing in

<pre>install PortName=COM6 PortName=COM7</pre>

You can chose any numbers you wish for your ports instead of 6 and 7, however if your computer already has serial ports some numbers may be taken. For instance, if your computer has 2 serial ports, COM1 and COM2 are probably physical ports in the system, and those ports will not be available.

After you create the ports, windows will let you know that new hardware has been found (twice, one for each port). Let it connect to the internet and automatically install any software it needs, then to back to the command prompt and type

<pre>list</pre>

into the prompt. The ports you created should show up in the list, in which case you are ready to create virtual AWID readers, You can now close the command prompt, unless you want to create more virtual ports.

You should only need to create the ports with com0com once, they will persist indefinitely.

===Creating an AWID===
Now that you are done creating the serial ports, it is time to create an AWID reader. Start up Emulator, click on the '+' sign next to the "ReaderView" tab in the top left, and select "AWIDMPR" from the given list. Press next, give the reader a name, and type in the name of one of the COM ports you created before. If you selected COM6 and COM7 for instance, type in one of those. Click finish, and the reader should create successfully.

[[Image:Awid1.png]]

Now, right click on the reader you have created (the icon in the top left), and click "Start". The reader should now show as "running". Press the "+" button next to the TagsView, and create several GEN2 tags with whatever data type you wish. Select and drag those tags onto the AWID antenna in the middle, and the reader is now ready.

[[Image:Awid3.png]]

===Testing the AWID===
Turn on your MPR Demo software (or whatever you want to use to connect with the AWID), and select the opposite port that you picked to create the AWID on from the ports you created. For example, if you created ports 6 and 7, and you created the AWID with port 6, select COM7 in the MPR Demo. Click connect, and they should connect successfully! If they don't, check to make sure it says "running" next to the reader's icon.

[[Image:Awid4.png]]

If you connected successfully, you should see red and green output in the console view of the reader. The red represents commands coming in, and the green represents outgoing data. After this, you are free to read tags! Click on 'Command', go to 'Read single tag ID', and select 'EPC C1 GEN2'. You should see green output on the console of the tags going back to the MPR demo.

Documentation Guidelines

2014-06-30T22:10:44Z

Redfern3141: Undo revision 5884 by StevenCollins (talk) - Removing advertising and spam edits

[[Category:developerDoc]][[category:wiki]][[category:help]]
=Contributing to the Wiki=
As an open source project, Rifidi welcomes contributions of any kinds from its user community. If you would like to contribute to the wiki, you will need to first register and then log in using the links at the top right hand corner of the page. If you have not edited wikis, before, it may be helpful to visit some of the links that we have provided on our wiki home page.

=Structure of the Rifidi Wiki=
In order to keep the wiki somewhat structured, information should be attempted to put into one of several categories. Try to use the <tt><nowiki>[[category:]]</nowiki>]</tt> at the top of pages so that things are easier to find. The basic structure of the wiki is as follows:

*'''User documentation''' - This docuemtation describes how to obtain and run Rifidi. Please use the <tt><nowiki>[[category:userDoc]</nowiki>]</tt> at the top of any page in this category
*'''Developer documentation''' - This documentation should be used for anything that is helpful for developers, including but not limited to, how to get the source, how to compile, architecture diagrams, and implementation documents. Please tag pages in this category with <tt><nowiki>[[category:developerDoc]]</nowiki>]</tt>
**'''Emulator documentation''' - This category if for developer documentation that describes the emulator Please tag it with <tt><nowiki>[[category:developerDoc]][[category:emulatorDoc]]</nowiki>]</tt>
**'''Designer documentation''' - This category if for developer documentation that describes the Designer tool Please tag it with <tt><nowiki>[[category:developerDoc]][[category:designerDoc]]</nowiki>]</tt>
*'''Idea Box''' - The idea box is for any random thoughts that do not fit in to any other category well. Tag with <tt><nowiki>[[category:ideaBox]]</nowiki>]</tt>
*'''Wiki''' Help - Any useful information for newbies on how to edit the wiki. Tag with <tt><nowiki>[[category:wiki]]</nowiki>]</tt>

Note that pages can fall into several categories, such as this page, which is both a developer doc and a wiki help page. Use your best judgment, but in the end it is better to make the information available rather than worrying too much about the structure.

=Categories in the Rifidi Wiki=
* '''<tt><nowiki>[[category:userDoc]]</nowiki></tt>'''
This category should be used for anything that is helpful for users.

* '''<tt><nowiki>[[category:developerDoc]]</nowiki></tt>'''
This category should be used for anything that is helpful for developers.

* '''<tt><nowiki>[[category:developerDoc]][[category:emulatorDoc]]</nowiki></tt>'''
This category if for developer documentation that describes the emulator

* '''<tt><nowiki>[[category:developerDoc]][[category:designerDoc]]</nowiki></tt>'''
This category if for developer documentation that describes the Designer tool.

* '''<tt><nowiki>[[category:ideaBox]]</nowiki></tt>'''
This category is for any random thoughts that do not fit in to any other category well.

* '''<tt><nowiki>[[category:help]]</nowiki></tt>'''
This category is for everything helpful to new Users starting with the Rifidi Wiki.

Edge Server Architecture

2014-06-30T22:10:00Z

Redfern3141: Undo revision 5885 by StevenCollins (talk) - Removing advertising and spam edits

This page describes several aspects of the Rifidi Edge Server Core. It is intended for developers to understand how the core is structured.
=Overview=
There are two main aspects to understanding the edge server. The first is the three architectural layers that facilitate the flow of data from sensor to a designated endpoint. The second is the runtime and how it uses service oriented architecture and OSGi to be dynamic and light weight.
==Layers==
This section shows the three conceptual architectural layers that data passes through on its journey from sensors to whatever endpoint the user chooses.

[[Image:Dataflow3.png|thumbnail|400px|Dataflow through the three Architectural layers in the Rifidi Edge Server]]

===Sensor Abstraction Layer===
The purpose of the edge server is to connect to any kind of sensors (e.g. RFID readers, Barcode readers, Mobile Devices) and collect information from them. In many scenarios, this consists of connecting to a Gen2 fixed reader (such as Alien 9800, Motorolla LLRP, etc), and collecting EPC information. However, the edge server is designed in a way so that the edge server to collect many kinds of data (active, passive, etc) from many kinds of devices. This layer allows users to connect to devices in a sensor-agnostic way to collect the kind of data required for the application.

===Application Engine Layer===
For most applications it is not desirable to save every event that the sensors produce. Many sensors can send 1,000 of events a second, a large number of which might be duplicates. Most applications are interested in events that are one-level higher than the raw events produced by sensors. For examples, an ERP system is probably interested in the event of a box arriving in area 1, and it is not desirable for the ERP system to do the work of filtering and processing all of duplicate reads the sensor produces.

Complex Event Processing (CEP) is a paradigm of viewing data as ephemeral events (an event stream) and identifying meaningful (i.e. business) events from the stream using rules. Rifidi Edge Server uses a Complex Event Processor called Esper. It allows you to write queries using an SQL-like syntax:
<pre>
select * from ReadCycle where ReaderID='gate_1'
</pre>

One of the most important aspects of CEP is being able to use incorporate temporal knowledge into the queries. This allows you to phrase queries like "Send an order_complete event when an itemA event is followed by an itemb event" or "send an order_cancelled event when an itemb event is not seen within 10 min of a itemA event."

The Application Engine Layer is intended to let application developers build much of the functionality of their RFID applications using esper queries.

===Communication Layer===
After data has been processed, it probably needs to be handed up to some kind of application-dependent system. For example, some users might want the data to be stored in an [http://physioactive.sg/ massage therapy singapore] database, others might want it to be pushed into an ERP system like SAP or handed to a [http://www.inleds.com/products/?cid=2 led downlight singapore] Rich User Interface of some sort. The edge server has several built in connectors to use, namely JMS and Web Services (via Spring's remoting framework). However, as this is application dependant, it is possible to write your own connector (such as a TCP/IP socket connection) if the application needs it.

In addition, the edge server also provides a [http://www.inleds.com/ singapore led lighting] built-in web container and MVC framework so that web applications can be deployed directly.

==OSGi==
OSGi is a dynamic modules system for Java. It provides several pieces of functionality including the following:
# A deployment unit (called a bundle), which is a [http://www.premier-football.net soccer jersey store] normal JAR with some extra information in the Manifest.
# A lightweight runtime that allows bundle lifecycle to be controlled. In other words, you can start, stop, and update bundles at [http://thepartyhub.com/Showcase party artists] runtime.
# Dependencies are explicitly stated in the Manifest either as "bundle dependencies" or "package dependencies".
# Classes are only visible to other bundles if their containing packages have been exposed. This allows developers to hide classes that should be strictly internal.
# The runtime provides a [http://thepartyhub.com/ event planners singapore] service registry -- a system-wide repository for bundles to provide functionality.

The edge server is simply a collection of bundles that run in an OSGi environment (Equinox). Functionality between bundles is shared by means of services that are available in the service registry. Because bundles can be started and stopped while the rest of the server is still running, we can update non-essential parts of the edge server without restarting it.

=Services=
In the Edge Server, services are POJOs that provide a specific piece of functionality to other components and are registered in the OSGi Registry. For more information see [[How to use OSGi Services]]
== Core Services==
The following services are provided by the core bundle.
===Reader Data Access Object===
'''Purpose''': Provide access to sensor configurations that have been created. 
'''Interface''': <tt>org.rifidi.edge.core.daos.ReaderDAO</tt> 
'''Methods''' 
* <tt>Set<AbstractSensor> getReaders()</tt> Get all available sensor configurations
* <tt>AbstractSensor getReaderByID(String ID)</tt> - Get the sensor with the supplied ID
* <tt>Set<AbstractSensorFactory> getReaderFactories()</tt> - Get all registered sensor factories
* <tt>AbstractSensorFactory getReaderFactoryByID()</tt> - Get the sensor factory with the supplied ID
===Command Data Access Object===
'''Purpose''': Provide access to command configurations that have been created. 
'''Interface''': <tt>org.rifidi.edge.core.daos.CommandDAO</tt> 
'''Methods''' 
* <tt>Set<AbstractCommandConfiguration> getCommands()</tt> Get all available command configurations
* <tt>AbstractCommandConfiguration getCommandByID(String ID)</tt> - Get the command configuration with the supplied ID
* <tt>Set<AbstractCommandConfigurationFactory> getCommandFactories()</tt> - Get all registered command configuration factories
* <tt>AbstractCommandConfigurationFactory getCommandFactoryByID(String ID)</tt> - Get the command configuration factory with the supplied ID
* <tt>AbstractCommandConfigurationFactory getCommandFactoryByReaderID(String ID)</tt> - Get the command configuration factory with the supplied sensor ID

===Configuration Service===
'''Purpose''': Provide a way to save and load configurations from persistence. Configurations (such as Sensor Configurations or Command Configurations) are created using a factory (that must be registered). Configurations have Attributes which can be changed via getters and setters. 
'''Interface''': <tt>org.rifidi.edge.core.configuration.services.ConfigurationService</tt> 
'''Methods''' 
*<tt>void storeConfiguration()</tt> - Store all configurations to persistence (i.e. xml file, database, etc).
*<tt>Configuration getConfiguration(String serviceID)</tt> - Get a configuration (i.e. Sensor Configuration or Command Configuration)by service ID.
*<tt>void createService(String factoryID, AttributeList attributes)</tt> - Create a new configuration using a factory with the supplied ID. Use the supplied AttributeList to override defaults.
*<tt>void destroyService(String serviceID)</tt> - Destroy a service with the supplied ID
*<tt>Set<Configuration> getConfigurations()</tt> - Return all Configurations.

===Sensor Management Service===
'''Purpose''': Since there is a concept of "Logical Sensors", it is possible to define a sensor that is a collection of physical sensors. This service allows sensors to be created, destroyed, grouped as part of a logical sensor, and subscribed to 
'''Interface''': <tt>org.rifidi.edge.core.sensors.management.SensorManagementService</tt> 
'''Methods''' 
*<tt>void createSensor(String sensorName)</tt> - Create a new sensor with the given name
*<tt>void destroySensor(String sensorName)</tt> - Destroy a sensor with the given name
*<tt>void createSensor(String sensorName, Collection<String> childSensors)</tt> - Create a new sensor with the given name and has the given child sensors
*<tt>void renameSensor(String oldName, String newName)</tt> - Rename a sensor
*<tt>void addChild(String sensorName, String childName)</tt> - Add the child sensor to this logical sensor
*<tt>void addChildren(String sensorName, Collection<String> childNames)</tt> - Add multiple children to this logical sensor
*<tt>void setChildren(String sensorName, Collection<String> childNames)</tt> - Set the children of this logical sensor to the supplied list
*<tt>void removeChild(String sensorName, String childName)</tt> - Remove the given child sensor from this logical sensor
*<tt>void removeChildren(String sensorName, Collection<String> childrenNames)</tt> - Remote all the given child sensors from this logical sensor
*<tt>Sensor subscribe(Object subscriber, String sensorName)</tt> - Subscribe an object to the sensor
*<tt>void unsubscribe(Object subscriber, String sensorName)</tt> - Unsubscribe an object from the sensor
*<tt>void publishToEsper(String sensorName)</tt> - Publish all tags produced by this sensor to esper under the given sensorName
*<tt>void unpublishFromEsper(String sensorName)</tt> - Stop publishing tags produced by this sensor to esper under the given SensorName
*<tt>SensorDTO getDTO(String sensorName)</tt> - Get the Data Transfer Object of the sensor with the given name
*<tt>Set<String> getSensors()</tt> - Get a list of all children sensors belonging to this one.

===JMX Service===
'''Purpose''': Exposes a Configuration via JMX 
'''Interface''': <tt>org.rifidi.edge.core.configuration.services.JMXService</tt> 
'''Methods''' 
*<tt>void publish(Configuration config)</tt> - Publishes the given Configuration to JMX
*<tt>void unpublish(Configuration config)</tt> - Removes the given Configuration from JMX
*<tt>public void setConfigurationControlMBean(ConfigurationControlMBean mbean)</tt>

==JMS Services==
The Edge server uses JMS internally to pass events. To learn how JMS is configured inside of the edge server, see [[EdgeServerJMS| JMS in the Edge Server]]. The following services are preconfigured JMS components that facilitate using JMS in other areas of the edge server. They are created and made available in the jms bundle
===Internal Destination===
'''Purpose''': A JMS Topic that serves as an internal high-speed message bus. Sensors will place tag reads on it. 
'''Interface''': <tt>javax.jms.Topic</tt> 
===External Tags Destination===
'''Purpose''': A JMS Topic that serves as destination for clients that run outside the edge server's JVM to receive tag reads. 
'''Interface''': <tt>javax.jms.Topic</tt> 
===External Notification Destination===
'''Purpose''': A JMS Topic that serves as destination for clients that run outside the edge server's JVM to receive notification events, such as when a sensor is created or deleted, or a session has been started or stopped. 
'''Interface''': <tt>javax.jms.Topic</tt> 
===Internal Broker Connection Factory===
'''Purpose''': A JMS Connection Factory that creates connections to the internal ActiveMQ Broker. 
'''Interface''': <tt>javax.jms.ConnectionFactory</tt> 
===External Broker Connection Factory===
'''Purpose''': A JMS Connection Factory that creates connections to the external ActiveMQ Broker. 
'''Interface''': <tt>javax.jms.ConnectionFactory</tt> 
===Internal JMS Template===
'''Purpose''': A Spring object that makes it easier to send messages to the internal broker 
'''Interface''': <tt>org.springframework.jms.core.JmsTemplate</tt> 
===External JMS Template===
'''Purpose''': A Spring object that makes it easier to send messages to the external broker 
'''Interface''': <tt>org.springframework.jms.core.JmsTemplate</tt> 

==Other Services==
There are a few other services that are important. The interfaces for these services can be found in the edge server services bundle, and each service will be implemented in its own bundle.
===Esper Management Service===
'''Purpose''': Provides access to esper 
'''Interface''': <tt>org.rifidi.edge.core.services.esper.EsperManagementService</tt> 
'''Methods''': 
*<tt>EPServiceProvider getProvider()</tt> - Get the EsperServiceProvider so that you can use esper.
===Notification Service===
'''Purpose''': Allows the edge server to notify external clients when an important state change happens (such as when a sensor configuration is created or when a sensor session is started). These methods should be called on this service when the corresponding event happens. For example, when a session is created, the addSessionEvent() method should be called. 
'''Interface''': <tt>org.rifidi.edge.core.services.notification.NotificationService</tt> 
'''Methods''': 
*<tt>void addSessionEvent(String readerID, String sessionID)</tt>
*<tt>void removeSessionEvent(String readerID, String sessionID)</tt>
*<tt>void addReaderEvent(String readerID)</tt>
*<tt>void removeReaderEvent(String readerID)</tt>
*<tt>void removeReaderEvent(String readerID)</tt>
*<tt>void addCommandEvent(String commandID)</tt>
*<tt>void removeCommandEvent(String commandID)</tt>
*<tt>void addReaderFactoryEvent(String readerFactoryID)</tt>
*<tt>void removeReaderFactoryEvent(String readerFactoryID)</tt>
*<tt>void sessionStatusChanged(String readerID, String sessionID,SessionStatus sessionStatus)</tt>
*<tt>void addCommandConfigFactoryEvent(String readerFactoryID,String commandConfigFactoryID)</tt>
*<tt>removeCommandConfigFactoryEvent(String readerFactoryID,String commandFactoryID)</tt>
*<tt>void jobSubmitted(String readerID, String sessionID, Integer jobID, String commandID)</tt>
*<tt>jobDeleted(String readerID, String sessionID, Integer jobID)</tt>
*<tt>attributesChanged(String configurationID, AttributeList attributes)</tt>

===Logging Service===
'''Purpose''': Allows the logging level to be changed at runtime. For more information, see [[How to change logging levels]] 
'''Interface''': <tt>org.rifidi.edge.core.services.logging.LoggingService</tt> 
'''Methods''': 
*<tt>setLoggingLevel(String loggerName, String level)</tt> - Change the logging level of the logger (class or package name) to the given logging level.

=Core Bundles=
The edge server is deployed as a set of OSGi bundles. The following bundles make up the core.
;org.rifidi.edge.api
: Provides core classes that are necessary for an outside UI to talk to the edge server via RMI and JMS, such as Data Transfer Objects (DTOs), JMS Notification Messages, RMI Interfaces, and Tag Messages.
;org.rifidi.edge.console
: Provides the ability to control the edge server using the OSGi console provided by eclipse equinox. For more information about how to control the console, see [[Edge_Server_Console]].
;org.rifidi.edge
: Contains the interfaces for several OSGi services used within the edge sever
;org.rifidi.edge.core.jms
:Configures JMS for the edge server. See [[EdgeServerJMS]] for more details
;org.rifidi.edge.core.services.logging
:Provides a service to modify the logging level at run time
;org.rifidi.edge.core.services.notifications
:Provides a service to notify external clients (such as UIs) about state changes inside the edge server

=Important Dependencies=
==Spring==
===Spring DM===
==SLF4J==
==Esper==
==ActiveMQ==

LLRP Reader

2014-06-30T22:07:27Z

Redfern3141: Removing advertising and spam edits

[[Category:developerDoc]][[Category:EmulatorDoc]][[Category:userDoc]]

==Introduction==

There has been a lot of buzz in the RFID world as of late around LLRP (Low Level Reader Protocol). It is an EPC Ratified Standard that describes a protocol for client to reader communication. It is called "Low Level" because it allows control of Air Protocol (such as class 1 gen 2) parameters as well as control of other hardware aspects of the reader. LLRP communicates via Messages -- the basic data unit -- that are encoded in a binary format and are sent over TCP. Using these messages, the client can control the various dynamic data structures (ROSpecs, AccessSpecs, etc.) and configure the reader.

;Network Protocol:
:TCP/IP
;Communication:
:Bit encoded messages over TCP

==Basis of Virtual Reader==
The LLRP virtual reader is based on the EPCGlobal spec found at [http://www.epcglobalinc.org/standards/llrp EPCGlobal's website]. Currently there are no hardware readers available.
===Documentation===
*[http://www.epcglobalinc.org/standards/llrp LLRP Specification]
*[http://www.impinj.com/uploadedFiles/RFID/Case_Studies_White_Papers/Impinj-LLRP_data_sheet(singlespages-web).pdf Overview of LLRP Protocol]

===Client Tools===
There are very few client tools available at the moment, as there are no hardware readers available. Because all LLRP commands are bit-encoded, communication with an LLRP reader is not trivial and it is not possible to simply telnet into the reader and issue commands.

;LLRPHelloWorld
:A simple [[LLRPHelloWorld|client]] developed for testing Rifid's LLRP reader that uses a java client library.
;XML Messages
:A collection of [[LLRP XML Messages]] that can be used to get started with LLRP

==Reader Design==
This section will give a brief overview of how the hardware reader operates for the purposes of emulation. It is the output of Stage 1 in the [[Readers#Stages of Building a Reader| Stages of Building a Reader]].
===Communication===
The LLRP Spec requires that LLRP Readers use bit encoded messages over a TCP connection. It explains how to build the messages by specifying in which order bits should be placed. To assist with the binary encoding/decoding of all the LLRP messages and parameters, see the [http://sourceforge.net/projects/llrp-toolkit/ LLRP-TK Sourceforge page].

LLRP readers use a TCP connection to communicate with the client. Additionally, readers may implement a secure connection using TLS.

====LLRP Communication Layer====
The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack. This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established. To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port. The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).

====Rifidi Admin Console====
To command the rifidi reader to either accept connections or make connections, a basic admin console has been provided. To use it, start the rifidi reader, and telnet into the reader. Then issue one of two commands:


'''For the (normal) ServerMode'''
 
In this mode the Reader works as a Server, listening for incoming connections on the given Port
* '''''mode server [PORT]'''''

'''For the ClientMode'''
 
In this mode the Reader works as a Client and tries to establish a connection to the ClientApplication which is running on the given IP and Port
* '''''mode client [IP] [PORT]'''''


===Memory Model===
The memory model of LLRP Readers is complex and different from other readers. There are two main data structures defined in the LLRP spec. The first is the ROSpec (Reader Operations Specification). The most important aspect of the ROSpec is that it contains contains a list of one or more of AISpecs (which define how to read EPC tags from the antennas) and RFSurveySpec (which define how to get operation information about the antennas such as power levels). In addition it contains a ReportSpec that has the parameters describing what information a report will contain. The other main data structure is the AccessSpec which defines how to read non-EPC information on a tag (such as
user defined data) as well as how to perform other operations on a tag, such as writing and killing. Currently the Rifidi virtual LLRP reader only supports ROSpecs with AISpecs (that is it supports getting epc numbers from tags).

It may help to imagine ROSpecs as processes inside an operating system. A ROSpec is like a single process, and it moves between three states -- disabled, inactive, and active. When the ROSpec is added to the reader, it is added in the disabled state. Then, a message from the client --the ENABLE_ROSPEC message -- moves the ROSpec to the inactive state. After that, a [[LLRPTrigger|trigger]] event (time based, message based, etc) moves the ROSpec into the active state, where it begins executing. When the ROSpec is executing, it goes through its list of specs to executes (AI and/or RFSurvey) and executes each one sequentially. It keeps repeating this cycle until its ROSpec stop trigger fires, at which time it moves back to the inactive state.

Tags are sent back as part of a Report Message. It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read". Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes. Once a tag is sent in a report, it is "deleted" from tag memory. This prevents the results of a single tag read from being a part of two reports. However if the same tag is read again after a tag read, it will appear in the next report.

===Getting Tags===

To get tags from a LLRP reader, a client must setup and send a ROSpec (which includes an AISpec) and begin the execution of it.

#Client Connects - In this stage, the client connects to the reader at the specified IP and port. Messages may now be sent between the client and the reader.
#Create ROSpec - In this stage, the client constructs the ROSpec object, which consists of numerous parameters specifying how the reader should read tags and send back results to the client. It is only through a ROSpec that a client can set up a reader. There is no concept of "telnetting" to the reader and using a command line in LLRP.
#Add ROSpec - In this stage, an ADD_ROSPEC message, which contains the newly created ROSpec, is sent to the reader to add it to its list of "ROSpecs to be processed." When a ROSpec is added, it is added to the reader's "disabled" queue.
#Enable ROSpec - A ROSpec must be enabled before it can be executed. The ENABLE_ROSPEC is a message sent from the client to the reader that moves the ROSpec from the "disabled" queue to the reader's "enabled" queue
#Start ROSpec - Once a ROSpec is enabled, it is listening for a start trigger. The simplest way to issue a start trigger is to send the START_ROSPEC message which will cause a reader to begin execution.
#Receive Reports from reader - When a ROSPec is in the execution phase, it can begin to send reports back to the client. Reports contain the information about the tags that the reader has seen, such as the EPC number, the first and last seen time, and the number of times the tag has been seen.

====Autonomous Mode====

The LLRP reader can be put in autonomous mode by specifying the stop trigger for an AISpec, the most straight-forward of which is the Time based trigger. For example, the the time based trigger is used, an AISpec will stop executing after N seconds. If the ROReport is configured to be sent after the AISpec stops execution, it will be sent then. After the execution of all the AISpecs, a ROSpec will stop. If there are no other ROSpecs waiting, it will begin to execute again. Thus if the Reader has only one ROSpec that has one AISpec, reports will be sent every N seconds.

====On-Demand Mode====

There is also a concept of an on-demand mode for getting tags, using the GET_REPORT message. If the reader is set to not send back reports at the end of a ROSpec or and AISpec (i.e. reporttrigger is null), then the reader is in an on-demand, or polling mode. Reports can only be obtained through the use of the GET_REPORT command.

===Login===
There is no concept of a "login" in the LLRP specification, as there is in some other readers such as the Alien or the Symbol. However, it would be possible to implement one through the use of custom messages.

==Supported Features==

The following is a list of important features of the LLRP reader that are properly emulated by Rifidi

===Messages Supported===
All LLRP Messages are supported, however some of the parameters inside the messages may not affect the reader. For example, the reader will not processes RFSurvesSpec parameters because the Rifidi Emulator does not emulate RF Functionality.

===Features Supported===
* Autonomous Mode & On-demand Mode as described in the Memory Model section above is supported.
* It is possible to read from more than on antenna and to specify which antennas to read from in the AISpec.
* Getting and Setting of Configuration Variables
* Getting of Capabilities
* Event Notifications
* LLRP Connection Layer
* Start and Stop Triggers for ROSpecs and AISpecs
* GPIO
** Enabling GPI Ports (using SET_READER_CONFIG)
** Writing to GPO Ports (using SET_READER_CONFIG)
** ROSpec start and stop trigger and AISPec stop trigger on GPI event
* Access specs
** Read non-epc memory
** Write memory
** Lock tag
** Kill tag

==Bugs and Unsupported Features==

===LLRP Toolkit===
Rifidi currently uses the toolkit developed at the University of Arkansas. However, there are a few limitations with this library that is being addressed by AutoID at MIT.
*Unsigned data types are not supported because java does not support them

===Other Unsupported Features===
*RFSurvey Specs

==Other Resources==
* [http://llrp.org LLRP Toolkit] - Open source implementations of LLRP Message encoders/decoders.
* [http://sourceforge.net/projects/llrp-toolkit/ LLRP-TK Sourceforge page] - Sourceforge page for LLRP Toolkit. Has a link to the mailing lists.
*[http://www.industrial-embedded.com/articles/id/?2392 Industry standards ease task of embedding RFID]
*[http://technet.microsoft.com/en-us/library/bb970584.aspx MS BizTalk LLRP documentation]]
*[http://www.rfidtribe.com/home/index.php?option=com_content&task=view&id=138 A Brief Introduction to LLRP]
*[http://www.aimglobal.org/members/news/templates/template.aspx?articleid=2887&zoneid=42 Interview with Rob Buck, co-chair of EPCGlobal Reader Operations Workgroup]

ReaderJunits

2014-06-30T22:03:27Z

Redfern3141: Undo revision 5893 by StevenCollins (talk) - spam & advertising edits

[[category:developerDoc]]
=Purpose of Junits=
Junits are automated tests that programatically test functionality. The advantage of them is that you can run the tests to make sure that as new functionality is added, old functionality doesn't break.

=Creating a new Junit in eclipse=
Currently our testing packages are stored internally to Pramari because they have dependencies to non-free libraries provided by RFID reader companies. We are currently working on opening up our tests. However, you can ignore the first step and add the test to a testing package contained in your reader's source code.
#Checkout org.rifidi.tests and org.rifidi.internal.dependencies from the internal repository
#Create a new package for your tests
#Add a new Junit in eclipse
##New->Other->Junit Test Case
##Fill in the information in the wizard. You need a Junit 4 test case with the SetUpBeforeClass() and TearDownAfterClass() methods generated.[[image:Newjunit.png]]

=Designing a Junit to Test a Virtual Reader=
The test that you are designing depends on which version of emulator you are running. To figure this out, open up the plugin.xml file for org.rifidi.emulator, and look at the plugin version

==Junit Guidelines==
* When creating a Junit, it is important to add comments to almost everything you do, because your test might not fail for months after you've written it, and it will be difficult to go in and figure out why it failed if there are no comments
* It is important to think through exactly what you want to test and make sure that you are testing it well. For example, The following test could be designed better, because it will not fail if more than one tag comes back from the alien reader for some reason after the getTaglist command is sent
* It is also important that one test not depend on the state of previously run test. All test methods should run independently and should only assume that SetUpBeforeClass() has finished without error. For example, if I added another test method to run after the <tt>getTaglistTest</tt> method, it should not assume that a tag is on the reader. Also this test method should have removed the tag after it was done.

==Junits for org.rifidi.emulator 1.x==
<pre>
/**
*
*/
package org.rifidi.tests.reader.alien;

import gnu.cajo.utils.extra.TransparentItemProxy;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;
import java.util.ArrayList;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.junit.AfterClass;
import org.junit.Assert;
import org.junit.BeforeClass;
import org.junit.Test;
import org.rifidi.emulator.reader.module.GeneralReaderPropertyHolder;
import org.rifidi.emulator.rmi.server.ReaderModuleManagerInterface;
import org.rifidi.emulator.rmi.server.RifidiManager;
import org.rifidi.emulator.rmi.server.RifidiManagerInterface;
import org.rifidi.emulator.tags.impl.C1G2Tag;
import org.rifidi.emulator.tags.impl.RifidiTag;
import org.rifidi.utilities.formatting.ByteAndHexConvertingUtility;

/**
*
* This Junit is designed to demonstrate how to write Junits for Rifidi Virtual
* Readers
*
* @author Kyle Neumeier - kyle@pramari.com
*
*/
public class AlienExample {

/**
* The logger for this class. Allows you to keep track of debug statements
* instead of using
*/
private static final Log logger = LogFactory.getLog(AlienExample.class);

public static final String READER_IP_ADDRESS = "127.0.0.1";
public static final int READER_PORT = 20000;
public static final String READER_NAME = "virtualAlienReader";

public static final String RMI_SERVER_IP_ADDRESS = "127.0.0.1";
public static final int RMI_SERVER_PORT = 1099;

/**
* The RMI Client Interface for the Alien Reader. It allows you to turn the
* reader on and off as well as add and remove tags to the antenna
*/
private static ReaderModuleManagerInterface alienManager;

/**
* The Interface for the RMI server
*/
private static RifidiManagerInterface RMIManager;

/**
* The client connection to the Alien reader
*/
private static Socket connection = null;
private static PrintWriter out = null;
private static BufferedReader in = null;

/**
* This method is run before any of the tests in this file
*
* @throws java.lang.Exception
*/
@BeforeClass
public static void setUpBeforeClass() throws Exception {
// set up RMI Server, Client, and Readers
RifidiManager.startManager(RMI_SERVER_IP_ADDRESS, RMI_SERVER_PORT);
RMIManager = RifidiManager.getManager();

/*
* The General Reader Property Holder contains information needed to
* instantiate the virutal reader. Note that the GRPH has a property map
* in it that is different for every reader. To find out which
* properties you should have in your reader, look at the required
* properties in the emulator.xml file in the reader project.
*/
GeneralReaderPropertyHolder alienGRPH = new GeneralReaderPropertyHolder();
alienGRPH.setNumAntennas(2);
alienGRPH.setNumGPIs(2);
alienGRPH.setNumGPOs(2);
alienGRPH.setReaderName(READER_NAME);
alienGRPH.setReaderClassName("org.rifidi.emulator.reader.alien.module.AlienReaderModule");
alienGRPH.setProperty("inet_address", READER_IP_ADDRESS + ":"+ READER_PORT);
alienGRPH.setProperty("heartbeat_address", READER_IP_ADDRESS + ":54321");

// create the reader
RMIManager.createReader(alienGRPH);

// get the reader manager from the RMI server
alienManager = (ReaderModuleManagerInterface) TransparentItemProxy
.getItem("//" + RMI_SERVER_IP_ADDRESS + ":" + RMI_SERVER_PORT + "/" + READER_NAME,
new Class[] { ReaderModuleManagerInterface.class });

// turn on the reader
alienManager.turnReaderOn();

// wait for reader to turn on
Thread.sleep(500);

// create a new client connection
connection = new Socket(READER_IP_ADDRESS, READER_PORT);

in = new BufferedReader(new InputStreamReader(connection.getInputStream()));
out = new PrintWriter(connection.getOutputStream());

try {
// read welcome message
System.out.println(readFromReader(in));
// send user name
out.write("alien\n");
out.flush();
// read resoponse
System.out.println(readFromReader(in));
Thread.sleep(500);
// send password
out.write("password\n");
out.flush();
System.out.println(readFromReader(in));
} catch (Exception e) {
Assert.fail(e.getMessage());
}
}

/**
* This class is run after all the tests in this class have been run. It
* should shut down the reader and tear down the RMI server
*
* @throws java.lang.Exception
*/
@AfterClass
public static void tearDownAfterClass() throws Exception {
out.write("q");
connection.close();
alienManager.turnReaderOff();
RMIManager.removeReader(READER_NAME);
RMIManager.cleanup();
}

/**
* This is a Junit Test. Use the "@Test" annotation above the class so that
* it will be run as a Junit.
*
* This Junit adds a tag to the reader, then sends a get taglist command to
* the reader. It then compares the response with the sent tag information
* and will fail if the information is not the same.
*
* @throws Exception
*/
@Test
public void getTaglistTest() throws Exception {
// make sure information comes back in the right format
String command1 = "\1set TagListFormat = TEXT\n";
out.write(command1);
out.flush();
String returnVal1 = readFromReader(in);
Assert.assertTrue(returnVal1.toLowerCase().contains("TagListFormat = TEXT".toLowerCase()));

// create a new tag
byte[] epcID = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C };
byte[] pass = { 0x00, 0x00, 0x00, 0x00 };
C1G2Tag t = new C1G2Tag(epcID, pass, pass.clone());
RifidiTag tag = new RifidiTag(t);
ArrayList<RifidiTag> tags = new ArrayList<RifidiTag>();
tags.add(tag);

// add tag to antenna 0 on the reader
alienManager.addTags(0, tags);

Thread.sleep(500);

// send a get taglist command
out.write("\1getTaglist\n");
out.flush();
String taglist = readFromReader(in);
logger.debug(taglist);

// process command and compare byte ids.
String[] info = taglist.split(",");
String id = info[0].split(":")[1];
byte[] byteID = ByteAndHexConvertingUtility.fromHexString(id.trim());
Assert.assertArrayEquals(epcID, byteID);

}

public static String readFromReader(BufferedReader inBuf)
throws IOException {
StringBuffer buf = new StringBuffer();
int ch = inBuf.read();
while ((char) ch != '\0') {
buf.append((char) ch);
ch = inBuf.read();
}
return buf.toString();
}

}
</pre>

==Junits for org.rifidi.emulator 2.x==
Creating Junits for emulator 2.x is similar to that. The main difference is how tags are created. An example is coming soon.

=Running the Junit Test Case=
#Right click the Junit in the tree on the left inside of eclipse
#Select RunAs -> Junit Plugin Test

Symbol XR440

2014-06-30T22:02:40Z

Redfern3141: Undo revision 5894 by StevenCollins (talk) - spam & advertising edits

[[Category:developerDoc]][[Category:EmulatorDoc]][[Category:userDoc]]

==Introduction==
The XR440 is manufactured by Motorola. It is a general purpose reader that can read Class 1 Gen 2 tags.

;Model Number:
XR440
;Network Protocol:
Bit Encoded Messages over TCP & HTTP over TCP
;Communication:
10/100 BaseT Ethernet – RJ45
;Antennas:
4 read points (4 transmit points, 4 receive points)
;General Purpose I/O:
N/A
==Basis of Virtual Reader==
The implementation of the virtual reader is based on the testing of an actual hardware reader. Testing was done using wireshark to capture the client-reader communication. This input output was then emulated.
===Documentation===
*[http://support.symbol.com/support/browse.do?WidgetName=BROWSE_PRODUCT&TaxoName=SG_SupportGoals&BROWSE_PRODUCT.isProductTaxonomy=true&BROWSE_PRODUCT.NodeId=SG_XR440_1_2&BROWSE_PRODUCT.thisPageUrl=%2Fproduct%2Fproducts.do&id=m4&BROWSE_PRODUCT.TaxoName=SG_SupportGoals&NodeType=leaf&NodeName=XR440&document=DT_PRODUCTMANUALS_1_1&BROWSE_PRODUCT.NodeType=leaf&NodeId=SG_XR440_1_2&AppContext=AC_ProductPage&param_document=sp| product manuals for the Symbol XR440]
===Client Tools===
The main client tools used for testing this program:
;BEA 2.2
:[[BEA]] is a commercial edgeware application. It communicates with the alien reader via "on demand" mode using the bit encoded messages over TCP. The new version of BEA (version 3.0), also has an option to use autonomous mode, which uses HTTP over TCP.
;Logic Alloy 1.0.10
:[[Logic Alloy]] ALE Server is an open source edgeware application. It uses HTTP to communicate with the reader.
;TagCentric
:[[TagCentric]] is an open source edgeware application that communicates with the alien reader HTTP.
;Motorola Showcase
:Motorola Showcase is a client tool provided by Motorola to use with their readers. It runs on .NET and communicates with the reader mainly using HTTP, but it is possible to get tags using the bit encoded messages.
;Web Browser
:Because the reader uses an HTTP interface, it is possible to use a simple web browser as a client to issue most commands.
==Reader Design==
This section will give a brief overview of how the hardware reader operates for the purposes of emulation.
===Communication===
The Symbol XR440 uses two methods for communication. The default port for HTTP is port 80, and the default port for bit-encoded messages is 3000.
====HTTP over TCP====
The main method for communicating with the reader is via HTTP over TCP. Almost all functionality can be accessed in this way.

The general syntax of an HTTP command is:

<pre>http://IP[:PORT]/cgi-bin/PROXY/oper=COMMAND[&PARAM=VAL]*</pre>

where

*[ ] indicate option items
*IP is a host name (can be of the form www.reader.com, or of 192.168.1.100)
*PORT is the port. If omitted, port 80 is assumed
*PROXY is either:
#loginProxy for commands dealing with logging into the Web-based admin console
#coreProxy for commands dealing with the backend, such as setting the date and time
#dataProxy for commands that interact with the host, such as getting tags
*COMMAND is the command to execute, such as "setDateTime" or "queryTags"
*PARAM=VALis a name-value pair of arguments. Each argument is separated by an ampersand. There can be 0 or more name-value pairs.

For example, to get tags, this command would be sent:

<code><pre>http://192.168.0.1/cgi-bin/dataProxy?oper=queryTags&raw=1</pre></code>

The resulting tag read looks like this:
<code><pre><Matrics>
<EventGroup>
<TagList>
<Tag raw='300833B2DDD9014035050000' time='46bb8b06' RPL='1'/>
</TagList>
</EventGroup>
</Matrics></pre></code>

====Byte Stream Messages====
In addition to the HTTP interface, the XR440 also supports a byte stream protocol. This interface is primarily for getting tags in an "on-demand" (i.e. polling) way. For example, the client will send the reader a command to "get tags", and the reader will respond with a tag list. Because the bit-encoded messages are smaller, they are more efficient to send over a network, and thus this protocol is a better choice than sending "queryTags" HTTP commands for polling the reader.

=====Structure of Byte Protocol Message=====
The general structure of a bit encoded message is the following:
*Byte 0 - Start of Frame (value is 0x01)
*Byte 1 - Node Address (Obsolete, value is 0x04)
*Byte 2 - Packet length, excluding the Start of Frame, but including CRC bytes
*Byte 3 - Command
*Bytes 4-N - Data
*Byte N+1 - LSB of CRC
*Byte N+2 - MSB of CRC

The reader will always respond with a similarly structured response message that echoes the command of the incoming message. In the case of the Read Full Field Command (22h), there are two response packets -- a Tag Data Packet, and a Final Packet.

===Memory Model===
The memory model for the Symbol reader is fairly simple. Tags are in one of three states: Visible, Invisible, or Unknown. Once a tag is read, it transitions from the Unknown state to the Visible state. If the tag goes outside the view of the antenna, it transitions to the invisible state. Then, if the re-enters the antenna's field of view, it transitions back to the Visible state. If the tag is in the Invisible state, and a purge command is called, it goes back to being unknown. The reader also generates events at each of these transitions.

When a client queries the reader using http, it can specify whether or not it wants the invisible tags by using the "invis" parameter.

===Getting Tags===

====On Demand====

====Autonomous Mode====

===Login===

==Supported Features==
So far, the only supported features are the following byte stream commands

*Get Parameter Block Command(24h)
*Ge Reader Status Command(14h)
*Read Full Command(22h)
*Set Parameter Block Command(23h)

In addition, it is only possible to read from antenna 1.

==Unsupported Features & Bugs==

ThingMagic

2014-06-30T22:01:13Z

Redfern3141: Undo revision 5895 by StevenCollins (talk) - spam & advertising edits

[[Category:developerDoc]][[Category:EmulatorDoc]][[Category:userDoc]]

==Introduction==

;Model Number:
4
;Network Protocol:
SQL like protocol that may be wrapped in ssh, web interface, RCP, and Linux shell login.
;Communication:
10/100 BaseT Ethernet – RJ45
;Antennas:
4 read points (4 transmit points, 4 receive points)
;General Purpose I/O:
(To Do)

==Basis of Virtual Reader==
The reader accepts SQL style protocol and returns the appropriate information.

===Documentation===

===Client Tools===
Telnet, SSH clients, and Tag Centric

==Reader Design==
This section will give a brief overview of how the hardware reader operates for the purposes of emulation.
Here is the architecture for the emulator: [[ThingMagic/Emulator_Architecture]] [Deprecated]
===Communication===

====Protocols====
The main method for communicating with the reader is via TCP, TCP+SSH on port 8080, web interface, and RCP.

===Memory Model===
The memory model is like a state based database.
===Getting Tags===
Getting tags is fairly simple just execute:
<pre><nowiki>
telnet [reader ip address] 8080
</nowiki></pre>
Then type:
<pre><nowiki>
select id from tag_id set time_out=[milliseconds];
</nowiki></pre>
Note: the semicolon at the end of each command is necessary.
 
One can also return multiple items:
<pre><nowiki>
select id, protocol_id from tag_id set time_out=[milliseconds];
</nowiki></pre>

Also add filters or conditionals:
<pre><nowiki>
select id from tag_id where [condition or filter] set time_out=[milliseconds];
</nowiki></pre>
Note: The where clause only works on tag_id or tag_data tables. Only '''protocol_id''' can have a string in the where clause.

In addition more than one statement can be put on more than one line.
<pre><nowiki>
select id from tag_id set time_out=[milliseconds]; select protocol from tag_id set time_out=[milliseconds];
</nowiki></pre> 

Tag Centric reads tags in the following manner:
<pre><nowiki>
select id,read_count from tag_id WHERE (protocol_id='EPC0' and protocol_id='EPC1' and protocol_id='GEN2') set time_out=200;
</nowiki></pre>
From this, one can tell if two conditions conjoined with 'AND' use the same column name, it counts as a logical 'OR'.
====Timer====

====Autonomous Mode and Cursors====
First create a cursor:
<pre><nowiki>
declare cursor_name cursor for select id, protocol_id from tag_table;
</nowiki></pre>

To use the cursor just once...
<pre><nowiki>
fetch cursor_name;
</nowiki></pre>
One may add more cursors to the fetch list by separating them by commas.

To turn on auto mode:
<pre><nowiki>
set auto cursorlist = ON;
</nowiki></pre>

To add in additional delay between one tag read operation and another:
<pre><nowiki>
set auto cursorlist = on, repeat = 500;
</nowiki></pre>
NOTE: 500 is the minimum time between the start of one tag read operation to the start of another. This ''includes'' any time_out value in the select command used for the cursor.

To set the delay between the end of the cursor list to the beginning of it repeating again, use:
<pre><nowiki>
SET repeat = 1000;
</nowiki></pre>

To turn auto mode off:
<pre><nowiki>
SET auto = OFF;
</nowiki></pre>
NOTE: Do not try to use any other command while auto mode is on; it may cause an ''undesirable undefined'' operation.

To delete a cursor:
<pre><nowiki>
close cursor_name;
</nowiki></pre>
NOTE: only one cursor can be close/deleted at a time, and no cursor lists are allowed in the syntax of this command.

====Reset====
To reset the reader as if there where no cursors defined and no tags read:
<pre><nowiki>
reset;
</nowiki></pre>

===Login===
By SSH log in.

===RQL Schema===
{| class="wikitable" border="1"
|+ tag_id
! Read/Write !! Field !! Type
|-
|R || protocol_id || Int
|-
|R || antenna_id || Int
|-
|R || read_count || Int
|-
| R/W || id || Hex String
|-
|W || killed || Int
|-
|W || password || Hex String
|-
|R || locked || Int
|-
|R || frequency || Int
|-
|R || dspmicros || Int
|-
|R || timestamp || String
|-
|}
 
{| class="wikitable" border="1"
|+ tag_data
! Read/Write !! Field !! Type
|-
|R || id || Hex String
|-
|R/W || block number || Int
|-
|R/W || data || Hex String
|-
|R || locked || Int
|-
|}
 
{| class="wikitable" border="1"
|+ settings
! Read/Write !! Field !! Type
|-
|R || current_time || String
|-
|R || version || String
|-
|R || supported_protocols || String
|-
|}
 
{| class="wikitable" border="1"
|+ io
!Read/Write !! Field !! Type
|-
|R/W || data || Hex String
|-
|}
 
{| class="wikitable" border="1"
|+ saved_settings
!Read/Write !! Field !! Type
|-
|R/W || hostname || String
|-
|R/W || iface || String
|-
|R/W || dhcpcd || String
|-
|R/W || ip_address || String
|-
|R/W || netmask || String
|-
|R/W || gateway || String
|-
|R/W || ntp_servers || String
|-
|R/W || 1tx_power || String
|-
|R/W || uhf_power_centidbm || String
|-
|R/W || epc1_id_length || String
|-
|R/W || primary_dns || String
|-
|R/W || secondary_dns || String
|-
|R/W || domain_name || String
|-
|R/W || reader_description || String
|-
|R/W || reader_role || String
|-
|R/W || ant1_readpoint_descr || String
|-
|R/W || ant2_readpoint_descr || String
|-
|R/W || ant3_readpoint_descr || String
|-
|R/W || ant4_readpoint_descr || String
|-
|}

==Supported Features==
All tables except tag_data are supported. Where clause only works on tag_id and tag_data on the real reader. Automode is working.

Only no-complex (simple) where clauses are supported now only for the '''select''' command, like:
<pre><nowiki>
select id,read_count from tag_id WHERE protocol_id='GEN2';
</nowiki></pre>

Adding and removing cursors works. Also automode works (see above examples).
==Unsupported Features & Bugs==
Tag_data table and compound conditions are not supported. ThingMagic, Mercury 5 reader RQL features are also not supported. Login by ssh is not supported. Also the time_out feature for reading tags is not supported yet. Complex where clauses are not currently supported but may be in a future release.

==Features that might never be supported==
Linux shell access to reader. This is fairly complex and require to emulate the entire hardware infrastructure of the reader and an ARM possessor. Also the web and RCP interface might be developed at a later time.