| submitted | available | document details (if available) | source link |
|---|---|---|---|
| July 04 2019 |
| various | User Manual | Users Manual | 269.02 KiB | / July 04 2019 |
HSP 3.0 Guide Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Table of Contents Note Regarding RF Exposure................................................................................................................3 FCC Notice and Cautions......................................................................................................................3 Compliance FCC Part 90 ......................................................................................................................3 Acceptable Frequencies.........................................................................................................................3 Migrating from Thinkify HSP2_0 to HSP3_0 firmware.......................................................................4 Overall command entry -..................................................................................................................4 Data entry of programming data -....................................................................................................4 System Type -...................................................................................................................................5 Config.ini File -................................................................................................................................5 The STATUS message -....................................................................................................................6 System Commands -.........................................................................................................................6 List of supported commands as of version 3.0.4 5-25-2018.............................................................6 Ethernet Communication between HOST and THINKIFY HSP3.0.....................................................8 Output and Status Messaging in the Thinkify HSP3.0 system............................................................10 IO and Timing control in the Thinkify HSP3.0 System......................................................................13 Trigger input................................................................................................................................13 Commands to adjust trigger timing............................................................................................13 Commands to further adjust timing within the programming loop.............................................14 STATUS Outputs.......................................................................................................................15 System Type Functions and control in the Thinkify HSP3.0 system..................................................16 Using the LOCK function in Thinkify HSP3.0...................................................................................20 Controlling the programming list database in the Thinkify HSP 3.0 system......................................21 Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Note Regarding RF Exposure. This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment. This equipment should be installed and operated with minimum distance of 20cm between the radiator (antenna) and your body. This transmitter must not be co-located or operating in conjunction with any other antenna or transmitter. FCC Notice and Cautions Any changes or modifications to this device not expressly approved by Thinkify, LLC could void the user's authority to operate the equipment. Compliance FCC Part 90 Thinkify RFID readers that have been configured by the manufacturer for the FCC Part 90 regulatory region. Pursuant to FCC Part 90.205, the Thinkify RFID readers radiated power is limited to +20dBm
(100 mWatts) ERP (Effective Radiated Power). Under all conditions, the Thinkify RFID reader will operate will below the maximum limit of Part 90 devices. Acceptable Frequencies 917 to 923.25 MHz Operation outside of these limits in Japan is not authorized!
Three preferred frequencies are:
917 MHz 920 MHz 923.25 MHz Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Migrating from Thinkify HSP2_0 to HSP3_0 firmware The 3.0 firmware command interface is similar, but not backwards compatible with the interface used in the 2.0 system. Changes were made to add functionality, and improve the usability and consistency of the command structure. At the end of this document is a list of commands supported by the 3.0 system. Further details of these commands will be described in additional documents. Overall command entry -
In the 2.0 system several commands were redundantly provided both as PI level commands and TR65 commands, but were actually just pass through commands to the TR65 module. Then later on in the development of the 2.0 system it was determined there was just too many commands to support this way of doing things, and the concept of sending a command preceded by a '!' would result in a command directly sent to the TR65. The 3.0 system no longer supports this. For any command sent, the command interface parser in the 3.0 will first determine if this command is meant to be processed by the PI. If it is not recognized as a valid PI command it is then sent to the TR65. If the TR65 recognizes it as a valid command it executes it, otherwise reports UNKNOWN COMMAND. Therefore the whole concept of preceding the commands intended for the TR65 with a '!'
is eliminated. and the PI does not support any commands that are really direct TR65 control commands, but instead just directly sends these on to the TR65. Some examples of the commands this applies to are setting the attenuation and radio parameters and setting the trigger and delay parameters. Data entry of programming data -
The development process in the 2.0 evolved as time went on. In the beginning only 96 bit EPC programming was supported along with passwords. As development proceeded it became apparent that further functionality was desired - examples being the size of the EPC memory data field and the ability to program USER memory data. As these were attempted to be added to the 2.0 command interface, the control structure got cumbersome and difficult to use. There were multiple commands and setup procedures depending on the desired actions to the tags currently being run which were unable to be changed easily etc. The 3.0 system attempts to correct this. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. The concept approach in the 3.0 system is WYEIWYP (What You Enter Is What You Program).. A structure of 65536 (0x10000) programming database entries is maintained as a circular FIFO buffer. Each of these database entries can hold varying length data fields for the EPC and USER fields, data for the password fields, and data for the PC word. When a system trigger occurs to initiate a programming sequence, the next available entry is popped from the FIFO, and whatever data is included in that particular database entry is used in programming operations to the tag. Any programming operations for data fields of NULL length are simply not executed. In this way all operational control on a tag that has triggered the system, for any operations, depends solely on the data entered for that particular database entry - there is no need for modes and setup commands etc. In the initial release of the 3.0 system, this programming database can be created in two ways - through a series of WRITEITEM commands, or the system can automatically create a programming sequence list through a GENERATE command. Further control commands of this database include GETBUFFERCOUNT, READBUFFER, RESETBUFFER, and AUTOCLEAR. One further operation beyond the data programming which can optionally be performed during a triggered loop is LOCKING the tag. A separate document describes details of these database control commands, along with program flow and the LOCK operation control details. System Type -
Three different system types are supported in the 3.0 system. Any PI/TR65 combination can be defined as a VERIFIER, an ENCODER, or STANDALONE system. The specification of the system type is best done in the config.ini file, but a command also exists to specify the type during runtime. The exact differences in operations for these three types is described in a separate document. Config.ini File -
A file will exist in the /home/pi/HSP_3_0 folder of the Pi Linux file system. This file will specify parameters the program will initialize at reset for general system setup. It will allow setting the TCP port numbers used, the USB com port the TR65 is attached to, the overall system type, and the initial settings of the AUTOCLEAR mode and the TRIGGER type. The file is a simple text file and can be edited with any text editor. It is expected that parameters set in this file rarely change after initial system setup. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. The STATUS message -
As the set of operations performed in response to a trigger is concluded, a status message is sent indicating the success/failure of all operations performed during the interaction with this tag. This is similar to the HSPDONE message in the 2.0 system, but since a different set of operations is now available to be performed the syntax of this response is changed somewhat. It is also modified in an attempt to be a more informative. A separate document will describe the format and status codes used in this message. System Commands -
The DISENAGE and ENGAGE commands are used to enable the acceptance of triggers by the system. The behavior of the programming database during these commands is controlled by the AUTOCLEAR setting. Two further commands are provided - one to do a firmware update to the attached TR65, and one to easily modify the STARTUP MACRO settings in a TR65 to facilitate system setup. A separate document will describe details of these. List of supported commands as of version 3.0.4 5-25-2018 Programmer3.0 PI Internal Commands QUIT - Exit the program SYSTEMTYPE(= TYPE) - either GET the current setting of the system type, or set it to VER,ENC,or STA GETVERSIONS - PI and TR65 firmware version GETBUFFERCOUNT - Current number of PROG DATA STRUCT loaded READBUFFER - Display all PROG DATA STRUCT loaded RESETBUFFER - Clear PROG DATA STRUCT buffer WRITEITEM=<DATA LIST> - enter 1 item into PROG DATA STRUCT buffer GENERATE=<DATA LIST>,NUM(count) - create arbitrary number of items in PROG DATA STRUCT buffer AUTOCLEAR=<ON or OFF> - control clearing of PROG DATA STRUCT buffer on ENGAGE ENGAGE - START the trigger acceptance system DISENGAGE - STOP the trigger acceptance system TR65LOADER=<filename> - updates the firmware in the attached TR65 TR65MACROLOAD - loads the text file in the HSP_3_0 folder named TR65MacroList.txt as a STARTUP MACRO into the TR65 Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Programmer3.0 Specific TR65 Commands Any Normal TR65 command may also be sent (radio control etc) Send command with no parameters to GET the current value HC<2 ASCIIHEX> -- CORRECT Minimum loop time control - units are milliseconds HH<2 ASCIIHEX> -- HOLDOFF inhibit Trigger time control - units are milliseconds HI<ACTION RETRY COUNT (1 ASCIIHEX)><OPEN RETRY COUNT
(1 nibble)> -- ITERATE Controls looping retry paramters HL<OFF> -- LOCK Inhibit LOCK command in ENCODE loop HL<LOCK PAYLOAD (5 ASCIIHEX)> -- LOCK Set the LOCK command payload HP<2 ASCIIHEX> -- PAUSE Delay after Trigger time control - units are milliseconds HQ<1 ASCIIHEX> -- QUIET Delay after OPEN - units are milliseconds HT<OFF or R or F> -- TRIGGER Control TRIGGER INPUT - off or edge type RISING FALLING HW<1 ASCIIHEX> -- WAIT Override GEN2 ASYNC WAIT - units are milliseconds Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Ethernet Communication between HOST and THINKIFY HSP3.0 The communication between a HOST system and the Thinkify HSP3.0 system is performed over 3 Ethernet PORT connections. These port connections are simple ASCII protocol Telnet type connections. The three ports are used for command and control (called the CMD port), status of the operations inside the triggered programming loops (called the DATA port) and a diagnostic stream indicating timing and occurrence of various events in the HSP operation (called the DIAG port). It is very useful for the HOST to log all messages on the DIAG port - especially in cases of system setup and in the troubleshooting of problems. If the system is functioning properly there is no need to have the DIAG port open, but it is generally advised to do so. The ports are configured as SERVERS and expect the host to establish a CLIENT connection to initiate communication. The CMD port is full duplex - commands can be sent from the host and responses to commands received. The DATA and DIAG port are simplex - data is only sent from the system to the host - the only system reception on these ports is to perform the necessary TCP protocol handshaking and port termination. The server configuration will allow up to 5 simultaneous client connections on each port -
however - it is NEVER necessary to have more than one client connection to each. Code execution overhead is increased with each client connection so it is advised to only have one connection open during operation. There is NEVER any need during the program flow to disconnect and reconnect port. Connections should be done ONCE at the beginning of the operation and left connected until it is desired to completely exit the system. However if more than one client connection is opened for some reason - the CMD port will only send responses to the CMD port which sent the command being responded to, the DATA and DIAG ports will send identical data to all open ports. There are also some diagnostic messaging on the Linux console port - mainly concerning initialization operations before the ports are connected and status of the port connections. It can be useful to have access to this console port either through the HDMI port of the PI or through a SSH connection into the Linux system. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. The system default for the port numbers are 5000 for the CMD port, 5001 for the DATA port and 5003 for the DIAG port, but these can be changed to any desired available port number in the config.ini file provided. Syntax of the messaging formats is described in other documents but in general all messaging is simple ASCII with CRLF delimiting. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Output and Status Messaging in the Thinkify HSP3.0 system As each triggered programming loop terminates one or more messages are sent out to inform the host of the data and status of the event in that loop. The type and format of the messages varies dependant on the SYSTEMTYPE. All three system types allow the option of defining extra memory reads through the setup of the four READ DESCRIPTORS in the TR65. If enabled these reads will occur at the very end of the programming loop. If any of these are enabled, the first set of messages will be the results of these extra reads Possible messages will be (one for each descriptor enabled) P3READ<descriptor number>=<data read> or <FAIL> or <errorcode from tag>
If the SYSTEMTYPE is verifier If the OPEN of the tag was successful the first message sent will be the EPC data read during the ACK command. Format --
ENTRYEPC=<ASCII HEX><CRLF>
If the READ of the TID was successful (of course this only occurs if the OPEN was successful) the next message will be the data read from this memory area. Format --
TID=<ASCIIHEX><CRLF>
or TID= READFAIL<CRLF>
The Final message is the overall status codes of the operations performed Format --
VERDONE=ALL:<statusbyte>,OPN:< statusbyte >,TID:< statusbyte ><CRLF>
The values and meanings of the statusbyte fields is given at the end of this document. If the SYSTEMTYPE is ENCODER Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Only one termination message is given indicating status ENCDONE=ALL<statusbyte>,OPN<statusbyte>,TID<statusbyte>,EPC<statusbyte>,KIL
: <statusbyte>,ACC: <statusbyte>,USR: <statusbyte>,PCW<statusbyte>,LCK:
<statusbyte><CRLF>
The values and meanings of the statusbyte fields is given at the end of this document. If the SYSTEMTYPE is STANDALONE If the OPEN of the tag was successful the first message sent will be the EPC data read during the ACK command. Format --
ENTRYEPC=<ASCII HEX><CRLF>
If the READ of the TID was successful (of course this only occurs if the OPEN was successful) the next message will be the data read from this memory area. Format --
TID=<ASCIIHEX><CRLF>
or TID= READFAIL<CRLF>
If all the programming operation enabled by the current programming database structure are successful, the EPC memory will be read after all programming operations complete and the status of this read will be reported. Format --
EXITEPC=<ASCIIHEX><CRLF>
or EXITEPC = READFAIL<CRLF>
Finally the termination status message will be sent STADONE=ALL<statusbyte>,OPN<statusbyte>,TID<statusbyte>,EPC<statusbyte>,KIL
: <statusbyte>,ACC: <statusbyte>,USR: <statusbyte>,PCW<statusbyte>,LCK:
<statusbyte><CRLF>
Status message byte meanings and values Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. In the final status message the fields are ALL: - this is the code for the overall success/fail of all enabled actions the entire loop OPN: - this is the success/fail of the OPEN sequence to bring the tag to OPEN/SECURE TID: - success/fail of the read of the TID memory area EPC: - success/fail of the write to the EPC memory area KIL: - success/fail of the write to the KILL password memory area ACC: - success/fail of the wrie to the ACCESS password memory area USR - success/fail of the write to the USER memory area PCW: - success/fail of the write to the PC word LCK: - success/fail of the LOCK operation The bytewide codes for each field are similar in function to the HSP2.0 system but have different values to avoid confusion between the two systems 0x00 - SUCCESS 0x90 - indeterminate - no valid response was processed for this operation 0x9F - action for this field was not enabled 0x9E - action for this field was enabled but not executed (probably due to previous error) 0xCe - the action was performed but the tag returned an ERROR response e Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. IO and Timing control in the Thinkify HSP3.0 System The TR65 module in the Thinkify HSP3.0 has two logic level inputs and 2 logic level outputs. In the HSP3.0 system INPUT0 is used to as the source of the trigger input signal that initiates a programming loop for any specific tag. The two outputs provide signals indicating the programming loop is in progress, and at the end of the loop the success or failure of operation in the loop. Trigger input The INPUT0 is a TTL level driven signal. It is not optically isolated, and it is recommended that any triggering device employ external opto-isolation. Electrical specification of this port can be found in the normal TR65 documentation. Minimum timing requirement for the trigger pulse is 3ms duration. The acceptance of a trigger is edge triggered , and can be command defined as either using a rising or a falling edge. The TR65 module supports several commands that allow modifying some aspects of the loop timing to achieve best performance for a tag - this allows some degree of adjustment for optimization for different sizes and shapes of tags as they are passed through the system. Commands to adjust trigger timing HT[<OFF> or <R (rising)> or <F (falling)>] controls the trigger state examples HT GETS the current setting for TRIGGER HTOFF turns off triggering HTR enables a rising edge trigger and HTF enables a falling edge trigger No triggers are recognized when the system is in DISENGAGE state HP[<delay (2 ASCII HEX)>] controls delay of programming loop after a trigger is received - this allows time for the tag to be in the optimum relation to the RF antenna for the RF operations. Units are in milliseconds from 0x00 to 0xFF examples HP GETS the current setting for trigger PAUSE HP0A delay 10 milliseconds after trigger before entering programming loop HH[<delay (2 ASCII HEX)>] controls minimum timing between triggers - this can be used to prevent spurious triggers. Units are milliseconds from 0x00 to 0xFF. examples HH GETS the current setting for trigger HOLDOFF HH32 inhibits triggers for 50ms after a trigger is received Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Commands to further adjust timing within the programming loop HC[<delay (2 ASCII HEX)>] controls the minimum time of the programming loop. The elapsed time a programming loop - defined as the time between the trigger and the final output messages indicating completion - can vary widely dependant on what operations are performed and the success or failure of these operations. For example if a tag fails to OPEN the loop can complete in just a few milliseconds compared with 100 or more if all operations in the loop succeeds. This variation in timing can cause problems with host systems. By setting the minimum time for the loop these variations can be minimized. Normal setting would be somewhat less than the normal elapsed time for the current set of programming actions being performed if they all succeed. examples HC GETS the current setting for loop time CORRECTION HC64 sets the minimum time between trigger and output messages to 100ms HQ[<delay (1 ASCII HEX)>] allows the insertion of a small delay to be inserted after the tag OPEN sequence completes and the READS/WRITES defined in the current programming loop occur. The purpose of this delay is to allow host systems a bit more time the input the desired programming data. In most cases this can be left at 0. Units are milliseconds from 0x0 to 0xF HW[<delay (1 ASCII HEX)>] controls the ASYNC RESPONSE DELAY for write and lock operations. The GEN2 specification states the tag will respond with a status at any time within 20ms from the end of any command that changes internal EE memory of the tag. In normal operation an interrogator must always wait until either a response is received or this timeout occurs. However in reality most tags return their status response much more quickly than this - many within just a few milliseconds. This command can be used to shorten the time the TR65 will wait looking for a response from the tag in any write or lock operation. This is to minimize the time added to the loop in the case of a missed response. However user must be aware this setting does cause operational violation of the specification the tag is designed to - care must be taken to ensure that for the particular tag IC being used, the wait time is long enough for any normal response to be acquired examples HW GETS the current setting for async response WAIT HWA sets the maximum time for the async response WAIT to 10ms HI<ACTION RETRY COUNT (1 ASCIIHEX)><OPEN RETRY COUNT
(1 nibble)> controls RETRY iteration control of the actions within a programming loop. Since the programming loop consists of several RF modulated commands to tag, then reception of backscatter response from tag, it is possible random events can cause an operation to fail. If a failure occurs in any of these discrete RF interactions, the entire programming loop is deemed to have failed. This command makes it possible to retry any failed event N times. However user must be aware that each retry can cause elapsed time of loop to increase - if retry is enabled, the spacing between trigger events must be Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. adjusted for worst case timing of all retries occurring. This setting is a tradeoff off between throughput time and throughput success rate. This command is more useful in a STOP-AND-GO transport mechanism than in a continuous flow transport mechanism. Two parameters are supported - the ACTION retry count, and the OPEN retry count. The ACTION retry will apply to any6 read/write actions enabled after the tag OPEN sequence is performed. The OPEN retry will apply to the actions need to move the tag to OPEN/SECURE. Units are N+1 where N can be a count value of 0x0 to 0xF HI GETS the ITERATION counts HI12 would iterate 1 time on all loop action failures after open, and iterate 2 times on OPEN failures STATUS Outputs Hardware signals are provide to allow user to monitor the timing of the programming loop, and receive an indication of the overall success of failure of the loop with any particular tag. if desired. The signal on OUTPUT0 of the TR65 will go high on reception of a valid trigger and will go low after the loop terminates (the final status message is sent) If the program loop was successful in all operations OUTPUT1 of the TR65 will go high 2ms before the falling edge of OUPUT0. In this way OUTPUT0 falling edge can be used to latch the status of the loop indicated on OUTPUT1. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. System Type Functions and control in the Thinkify HSP3.0 system The firmware in the PI and TR65 in the HSP3.0 system allows configuring for 3 specific purposes. These are VERIFIER, ENCODE, and STANDALONE. This document describes the control commands to specify the system type, and program flow differences between the three types. The system type can be specified in the config.ini file to configure the system at power up reset - this is the expected way to configure a system, since it is unlikely to change once defined for the current tag transport mechanism. A runtime command is also provided to change it - syntax SYSTEMTYPE= <VER, ENC, or STA>. Issuing a SYSTEMTYPE command with no parameters will return the current setting. In the splash messages sent to console port on power up reset the current setting in the config.ini will be reported. Historically the concept of the system having different types comes from the initial HSP2.0 transport hardware. Most if not all HSP2.0 systems have at least 2 verifiers and one encoder type system in the transport mechanism. The first verifier reads the pre-programmed value of the EPC field and the TID field of the tag, then the encoder performs programming operations, then the second verifier again reads the EPC and TID fields to check the validity of the programming operation. Some transport systems provide a third verifier for various purposes. To support backwards compatibility with these type of systems the HSP3.0 system will allow system setup options to offer this same functionality (along with all the new functionality provided). Advantages of this approach are throughput speed since each system has fewer overall operations to perform and very robust data integrity verification. of at least the EPC data. Disadvantages are system cost, complexity and the need for the host controller to access and control multiple systems with very stringent timing control. Initial HSP2.0 systems only allowed 96 bit EPC programming. As desire to add different EPC lengths, and USER bank programming was expressed the configuration and control of multiple systems becomes more cumbersome and complicated. Also even in earlier systems the programming functions of the PASSWORD fields was never re-checked by the verifier which decreased the robustness of the approach. To overcome these disadvantages, the HSP3.0 system offers a third system type - the STANDALONE. If a system is configured this way it will do all of the different tag access operations internally, which allows an overall system to only have one PI/TR65 combination. This can make a large difference in overall system cost and host control Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. complexity, But since many more RF-tag interactions are necessary it will affect the necessary time the tag is in the antenna rf field pattern - and depending on many factors may slow down the throughput speed somewhat. A user must weigh the advantages and disadvantages in determining the configuration to use with their tag transport mechanism and host software control system. Program Flow of the System Types -
All systems start off in DISENAGE mode - in this mode the TRIGGER is disabled. All timing, trigger, and general RF control commands should be sent. A suggested and superior way to perform all of these setup tasks is through the use of a reader STARTUP MACRO (described in a different document) To start operation of all system types an ENGAGE command must be sent. The system will then wait for a valid trigger to indicate interaction with a tag should begin. All operations with a GEN2 tag must first INVENTORY the tag to get it into OPEN or SECURE state, all system types will perform the necessary RF operations for this process. See description at end of this document for details of these operations, and controls a user can issue. Most users can just use default operational settings. The INVENTORY will return the EPC data of length defined by the PC word, and the HANDLE to be used in all subsequent operations - see GEN2 specification. If the INVENTORY operation fails there is no way to interact with this tag - the programming loop will terminate with no further actions. The status message will indicate this has occurred. If a system type is configured as a VERIFIER After tag reaches OPEN/SECURE, a read of 6 words starting at address 0 of the TID memory bank is performed. If the TID READ fails, the loop terminates and a status message is sent indicating this failure. Since to get to this point the INVENTORY was by definition successful, the EPC data acquired will be reported along with a message indicating the TID read failure. The HSP3.0 extends VERIFIER operation beyond the 2.0 system. If the TID read is successful, the four READ descriptors in the TR65 are checked. If any are enabled further reads of up to four memory areas defined in these read descriptors is performed. This allows memory areas such as passwords, or user memory, or EPC memory beyond the length defined by the PC word to be also be read during the triggered operation. Of course any additional RF operations enabled require extra time to execute and will impact the throughput rate of the verifier. The setup of the read descriptors is beyond the scope of this document - refer to the normal TR65 user manual. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. The system then issues a series of messages and returns to looping waiting for a trigger. These messages will include the EPC data from the INVENTORY (if successful), The TID data from the READ, any data from descriptor driven reads and finally a status message indicating the failure/success of all operations. If a system type is configured as an ENCODER After tag reaches OPEN/SECURE, the programming structure database is checked for having a valid entry. If it has one, it is read from the FIFO and any non-NULL length fields will drive write operations. The check for non-NULL length and RF operations will occur in the order EPC KILL PASSWORD ACCESS PASSWORD USER MEMORY PCWORD In the event any of these operations are enabled but fail (as indicated by either nonreception of the tag status message or reception of the tag status message with error indication) the ENCODE loop will terminate immediately and no subsequent programming operations will occur even if enabled by non-NULL length fields. The status message will indicate this failure and any operations enabled but not performed. If all programming operations are successful, the status of the LOCK enable is checked. If it is enabled a LOCK operation will occur. A separate document will describe enabling the lock and setting the lock payload. If the LOCK operation is successful the 3.0 system again extends the functionality of the system by checking the TR65 4 READ descriptors as described above for the VERIFIER. The ENCODER will always terminate it's loop with the status message and then idle waiting for the next trigger to occur. If a system type is configured as STANDALONE After tag reaches OPEN/SECURE, the actions of both the verifier and encoder are performed. The TID is read, the programming data base is accessed, all enabled programming actions occur, the lock occurs. A standalone system will then do final read of the EPC data, then do the check of the 4 read descriptors. upon success of all these operations the ENTRY EPC is reported, the TID read is reported, the EXIT EPC is reported, any READ descriptor results are reported and finally a status message is sent indicating all success and failures. Appendix - description and control of the INVENTORY process Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. In most cases the user can just use the default settings for the inventory process. There are two aspects of this that can be controlled for fine tuning a system if desired. These include controlling the SELECT used and allowing an ACCESS operation to occur. Only fairly non-standard use cases would use these TODOTODO - add details of these - TODOTODO for now just use the defaults In general the default INVENTORY used consists of the RF operations SELECT ALL, QUERY, with Q of 0, ACK, REQRN to bring the tag to OPEN/SECURE. See Gen2 spec for description of these and the inventory process. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Using the LOCK function in Thinkify HSP3.0 In any 3.0 system configured as an ENCODER or STANDALONE the GEN2 LOCK functionality can be added to any tag programmed. See GEN2 spec for the full description of the LOCK functionality. If the LOCK is enabled it will be the last thing programmed to the tag after all other enabled memory areas are complete. Since the 3.0 programming aborts on any error this means only tags fully programmed with all desired data will be issued a LOCK command. From a power up reset the LOCK functionality is disabled. If desired a TR65 STARTUP MACRO command could override this and enable the LOCK by setting a payload. Or at any time the host can issue a command to enable and specify the LOCK function. The LOCK command is a TR65 command - HL[<payload>]. HL alone returns the current setting of the lock PAYLOAD. If the command is entered with a payload of OFF the lock is disabled. If the payload is 5 ASCII HEX characters the LOCK function is enabled and the payload entered defines the characteristic of the lock as defined in the GEN2 specification. Any LOCK payload setting is applied to all subsequent tags until explicitly overwritten or a reset of the TR65 occurs. Interest has been expressed in the possible addition of other command formats to minimize the need for the user to fully understand how a lock payload is formed. This may be added in future versions, but the direct payload entry will always be supported. It is a characteristic of the GEN2 specification that there is no means to read back the value of the lock payload as set into the tag. If the tag returns a valid response of either OK or ERROR in response to a LOCK command then the status of the lock payload in the tag is deterministic - if the response is missed or unreadable then the status is undetermined. The status message at the end of the programming loop will indicate the result. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. Controlling the programming list database in the Thinkify HSP 3.0 system The data to be programmed in to a series of tags in the HSP3.0 system is controlled by a database of data strings for the various fields supported by the EPC gen2 specification. This database exists in systems that have been defined as ENCODERS or STANDALONE, Systems defined as VERIFIERS do not support this database. This database is organized as a circular FIFO of 0x10000 entries, with each entry a structure possibly holding data to be written into the EPC memory bank, the USER memory bank, The ACCESS PASSWORD, the KILL PASSWORD, and the PC word. The EPC and the USER data fields in each structure can be varying length - in unit of 16 bit words, from 1 word to 8 words. Further the base address of the first word in the field can be specified - then all other words will be written to consecutive addresses. The Password fields must be exactly 2 16 bit words, and the PC field must be exactly 1 16 bit word. Any field can also have NULL length if it is desired to not do operations on that memory area for this particular tag. As tags are processed by the system in response to input triggers, the next available programming structure is popped from FIFO database, and the data of any field of non-
NULL length is attempted to be written into the tag memory. If the database UNDERFLOWS - i.e. there is no available entry when a valid trigger occurs an ERROR will be logged in the status message and diagnostic stream. No programming operations will occur. If the database OVERFLOWS - i.e. more entries than the 0x10000 allowed are attempted to be entered, an error message will indicate this condition and the entry will be ignored. In the sequence of operations on any particular tag - if any error occurs all subsequent operations will be aborted. The status message will show the results of all possible operations. As an entry in the database is used for a programming sequence, all fields in that entry will be reset to NULL length so they cannot be reused. Some interest has been expressed in allowing the reuse of an entry in the case of a tag failing a programming operation, such that the next tag will then use the same database entry - this is being evaluated and may be added in future versions. Two commands exist to enter data fields into the database structure entries. WRITEITEM=<datalist>
and Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. GENERATE=<datalist>,NUM<number of entries to create>
The WRITEITEM command is used to enter the data for one database indexed structure. The GENERATE command can automatically create an arbitrary number of database structure entries - up to the full 0x10000 allowed with one command. The GENERATE command was created in HSP3.0 because it was noted that a common tag programming scenario is to program a fixed set of data and one incrementing word into tags as they trigger the system. The GENERATE command allows filling the database with data that follows this pattern. Using it frees up the host system from having to enter data for every tag as it triggers the system - instead the database can be created for a whole field of tags with one command. This relaxes the communication timing requirements of the system considerably. The command would be sent before the transport mechanism is started, then as tags trigger the programming loop subsequent enteries would be programmed into each tag. The WRITEITEM command can be sent at any time as tags are triggering the system -
the only requirement is that at least database entry has been filled at the time the GEN2 OPEN sequence of RF commands is complete. If there is no database entry available at this time an UNDERFLOW will occur and the tag will not be programmed. The condition will be flagged in the STATUS message, and in the diagnostic stream. Multiple memory area data can be entered as sub-fields into the <datalist> of either command. Each memory area sub-field is comma delimited in the <datalist>. To specify the memory area to be used for the data in the comma delimited sub-field the first three characters must be one of the following EPC for data in bank1 of the GEN2 tag USR for data in bank3 of the GEN2 tag KIL for the kill password ACC for the access password PCW for the PC word Following this 3 character memory area code, data should be entered as ASCII HEX. All data is WORD based so must be in multiples of 4 ASCII HEX characters. EPC and USR fields may have any number of words from 1 to 8 (4 to 32 characters). Passwords must have exactly two words (8 characters). PC word must be exactly 4 characters for one word. These sub field specifiers may be sent in any order inside the <datalist> as long as they are comma delimited. Any sub-field not specified within a <datalist> will result in a NULL length field for that database entry - when this entry is used as a tag triggers the system, no programming action will occur for that memory area. There is a data modifier for the EPC and the USR sub-fields which will specify the start Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. address within the bank. Multiple word in either bank will then be written at contiguous addresses from the start address. If no address modifier is given it is assumed the start address for the EPC is address2 of bank1, and the start address for the USR is address0 of bank3. To specify a non-default start address surround 4 ASCII hex characters in parenthesis immediately after the 3 character memory area specifier and before the data field. In the GENERATE command there is one further data modifier. If any 4character WORD is preceded by a ! (ASCII 0x21) this word will be incremented by one for each subsequent entry generated. EXAMPLES of WRITEITEM commands----
To specify one database entry for programming 96 bits of EPC only WRITEITEM=EPC111122223333444455556666 To specify one database entry for programming 128 bits of EPC only WRITEITEM=EPC11112222333344445555666677778888 To specify one database entry for programming 96 bits of EPC and ACCESSPASSWORD of 0xDEADBEEF WRITEITEM=EPC111122223333444455556666,ACCDEADBEEF To specify the above but also with KILLPASSWORD of 0xF00DFACE WRITEITEM=EPC111122223333444455556666,ACCDEADBEEF,KILFOODFACE To specify the above and also program user memory from address 0 with 0x123456789ABC WRITEITEM=EPC111122223333444455556666,ACCDEADBEEF,KILFOODFACE,U SR123456789ABC To program one word with value 0xB00B of EPC at address4 of EPC memory WRITEITEM=EPC(0004)B00B EXAMPLES of GENERATE commands----
The NUM field in the GENERATE command specifies how many database entries to create, and is in ASCII DECIMAL To GENERATE 10000 database entries with 80 bits of 0x11112222333344445555 then an incrementing field from 0x0000 to 0x270F GENERATE=EPC11112222333344445555!0000,NUM10000 To GENERATE 10000 database entries with 80 bits of 0x11112222333344445555 then an incrementing field from 0x0000 to 0x270F and also program the KILL PASSWORD with ABCDEF01 GENERATE=EPC11112222333344445555!0000,KILABCDEF01,NUM10000 To GENERATE 1000 entries programming only address8 of USR memory with incrementing values from 0x2000 to 0x23E7 GENERATE=USR(00080)!2000,NUM1000 Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved. As the data entry commands are executed they will be written to the database in ascending order in a circular addressing fashion from 0x0000 to 0xFFFF, and conversely when triggers occur entries will retrieved in a FIFO manner - the oldest unused database entry will be used first. Four other commands will affect the database. RESETBUFFER is somewhat self explanatory - all entries in the database will be reset to NULL length and the available buffer entry count will be set to zero. READBUFFER - All data in database will be reported - user should be aware this could result in a very long communication stream if the generate command has been used to fill a large number of database structures GETBUFFERCOUNT will return the number of currently filled but unused database structure entries AUTOCLEAR=<ON or OFF> controls the behavior of the buffer when the system triggering is enabled/disabled through a ENGAGE or DISENGAGE. If it is ON any transition from ENGAGE to DISENAGE or vice versa will result in a RESETBUFFER being executed. Thinkify, LLC, 18450 Technology Drive, Suite E1, Morgan Hill, Ca. 95037, www.thinkifyit.com 408-782-7111 Copyright 2014 Thinkify LLC. All Rights Reserved.
This product uses the FCC Data API but is not endorsed or certified by the FCC