User Tools

Site Tools


ref:backscatter

Backscatter

This page contains a brief reference for implementing backscatter using the EPC Gen II UHF RFID specification. A link to the specification can be found here.

Backscatter is a very low power option for wireless networking. In backscatter, a single high powered reader device transmits a wireless carrier, and modulates this carrier in typical ways to achieve reader → tag communications. For the tag → reader path, however, the reader still transmits the carrier but the tag modulates by tuning and de-tuning its antenna (in practice de-tuning is achieved by simply pulling the antenna to GND through a transistor). When the antenna is de-tuned the RF energy from the carrier is reflected back (backscattered) from the tag, and this reflection can be detected by the reader. This modulation requires very little power, meaning the tag can operate on very small power budgets.

Terms

First, the following terms are important in understanding backscatter operation:

  • Reader - High power device that generates the carrier for both reader → tag and tag → reader communications.
  • Tag - Lower power device that modulates the carrier for tag → reader communications by tuning and de-tuning its antenna.
  • EPC - Unique tag identifier. Specified by the manufacturer and unique to each tag.
  • RN16 - 16-bit random number generated by the tag, used during inventory round and for tag identification. Also called the handle.

Operational Overview

The EPC Gen II spec is a robust protocol capable of dense readings (30+ tags in view) over long (2m+) ranges. Although there are many modes and messages not described here, this section details the aspects of the protocol that we became familiar with while implementing PowerBlade. The following section, PowerBlade Implementation, describes further simplifications that we took during our implementation.

  • Inventory Round Initial contact between the reader and all tags in view (range) of the reader happens via an Inventory. The purpose of an Inventory is for the reader to establish all the tags that are within range, and store their EPC for later reference. An Inventory starts with a Query, the result of which is a single tag's EPC stored, and continues with more Queries until no more tags respond.
    • Query At the start of an Inventory Round, the reader sends a Query (see spec section 6.3.2.12.2.1). This Query contains information about the response format, including bits per second and modulation format, and also provides a Q value used to determine when, after the Query, the tag should respond. A Q of 0 means immediate. Our reader (the Impinj Speedway R420) starts an Inventory with a Query containing Q = 0 just in case only one tag is in range, but if there are multiple they will collide in their response (and negate each other). The R420 attempts with a larger Q if no valid responses are recorded after that initial Query.
    • QueryAdjust and QueryRep If the specified Q is non-zero, tags will not respond immediately to the Query, and will instead wait for the Q to be reduced. This reduction is accomplished via these two commands, but we did not use this feature. See the specification for more information.
  • Access Commands When all tags have been inventoried, the reader has a list of all tags in view (range) and can identify them by their EPC or RN16 (handle). At this point there are several data manipulation commands provided in the spec, but we did not implement any of these. A brief description of some of these is included here for completeness, but see the spec for more information.
    • Req_RN This command is used by the reader to indicate to the tag to backscatter a new RN16.
    • Read This is the appropriate method in the spec for getting data from tag → reader. The reader sends a read command specifying the RN16 or handle of the tag, and the tag responds with its data.
    • Write Similar to read, this allows the reader to write data to the tag.

PowerBlade Implementation

The backscatter implementation found in PowerBlade is not the full EPC Gen II spec. This is due to several reasons including device limitations, system requirements, and ease of implementation. We implemented it this way because our goal was to prove the concept of backscattering in this form factor, not to re-implement all of RFID. In our version of the specification, we make the following simplifications:

  • Query We ignore the Q value associated with the query, and always respond immediately. In other words, we respond to the first Query where Q = 0 and collide with other RFID tags. Then when the reader tries again with a larger Q, we still respond immediately and, assuming no others do, succeed. If another tag does respond to that subsequent Query and we collide again, the reader will attempt again and we will respond immediately again. We will eventually prevail in a setting that contains only correct-functioning devices. This was purely due to ease of evaluating using a logic analyzer - we always wanted our response and the Query to be visible in the same Saleae window. Expanding our protocol to include the slot counter, particularly since the debugging intensive steps are now complete, would be trivial.
  • Read In the spec, there is an explicit read command separate from Query. However getting through the Query and Acks to the Read is complicated, and technically not required for this proof of concept. As such, we opportunistically place our data as the last three words (six bytes) of our EPC, and utilize only the Inventory commands in the Impinj Reader. With each new Query the Impinj thinks it has discovered a new device, when in fact the changing EPC was from the same device with new data. Post processing allows us to understand this functionality correctly.
ref/backscatter.txt · Last modified: 2015/01/06 15:11 by sdebruin