Implementing Variable RSSI filters

 

Using RSSI to filter out read events is a powerful feature to better control read zone behavior. Essentially this feature is used when nearby tags are being seen at a read point either a) prematurely before they actually arrive such as on a production line or work center, or b) being seen outside the read zone perimeter (e.g. rogue reads) when there is no intent for those tagged objects to be seen at all. Typically this would be a hallway/corridor were tagged assets are inadvertently being seen on the inside room antennas as they pass by. 

 

This feature depends on a common RSSI cut-off value at the reader level. If all the tags respond similarly when powered up, a common RSSI value will work effectively. However, there are situations where a single RSSI value may not do the job. Examples being... 

❖Where different tag types are being used based on the type of object (small/large, metal/non-metal, placement area, etc.). Each tag type can respond at different signal strengths (e.g. RSSI).

❖If the size/mass (e.g. form factor) of the object being tagged affects the tags performance (either negatively or positively) even if the same tag type is used.

❖Where multiple parts on a cart, rack, hanger, post, or fixture all read differently as they near a given RFID portal or Read Zone (due to their orientation relative to the read zone). This diversity of read timing can affect accurate 'singulation' of those parts as as a logical group to a given fixture or hanger/post.

 

To account for these situations as noted above, specialized filter keywords have been made available. Shown below is the workflow to implement:

1.Associate the Item/Part #'s with a Form Factor code in the TagNet Product Master. This can be any nomenclature up to 25 char that groups the object with respect to the readability factors listed above.  Typically, simple codes such as FFxx (Form Factor) can be used as detailed below in Step #1

2.Create an Event Filter definition that incorporates the FFxx values and their associated RSSI values. This is done using new Filter keywords of *RSSI  and *PRODTYPE as shown below in Step #2.

3.Associate the Event filter with the Event Binding as shown in Step #3. Currently this RSSI filter logic has been incorporated into the following Binding Functions: 

üRFDPEVG (Generic Binding for all inventory movements and PEV).

üRFDPLC1   (Event driven Socket communication to PLC Gateway with furtherance to robotics).

üRFDHDSP (HD Stored procedure that sends raw TagID's for both Product and Asset Objects.

üRFDPLC2   (combined logic of RFDPLC1 and RFDHDSP together).

 

Step #1. Build a Matrix of RSSI values

Shown below is an example matrix,  in preparation for implementing this feature you would want to document want the current RSSI values are for each part. To see how TagNet is logging current RSSI values for those parts, ensure RSSI logging this is enabled for the physical Reader.

 

 

Step #2. Associate Form Factor codes to your Parts

See example Product Master definition below in Figure 1a., in this case FF01 is being assigned to this particular Base Item (GTIN) that is linked to many assets of the same type. All Assets mapped to this GTIN of MT_3000 will inherit the Product Type Form Factor. Figure 1b. shows an example of a WIP Part definition, any part tags that are mapped to this Part # would be subject to the FFO2 form factor. Note: this Part example would also apply to a FG or RM Product/Item number as well.

 

Step #3. Building your Filter Definition

See example filter definition below in Figure 2., in this case it is evaluating (3) different form factor codes (FF01, FF02, & FF03). Note that these form factors could be assigned to many different Part Numbers as shown above. So if a Tag is read that is mapped to a Part # that has a 'FF01' product type, then it will be evaluated to see whether it should be included (or not) in the event payload based on its RSSI comparison value.

 

 

Rule =  If the actual RSSI of the tag is stronger than the RSSI Filter, it will be included (otherwise ignored)  Note: with respect to RSSI values, -26 is weaker than -25. So in the example above for FFO2, the tags RSSI must be GE than -30.30 to be included (e.g. -30.30, -30.29, -29, -28, etc.up to 0),

Also note that whether that tag meets the filter condition or not, it will always be included in the base logging which records all raw tag read events. It is the higher order 'Business Event' that filters out what should be included based on the Filter Rules.

 

Step #4. Linking your Filter Definition to a Schedule Event Binding

The final step is to link the Filter definition that you created in Step #2 with your Event Binding. Refer to Event Bindings on how to do this. Note that in the below example, two (2) Bindings are linked to this schedule, either one (or both) can be associated with an RSSI Filter definition.

 

 

 

 

Copyright © 2024 Stratum Global, Inc.