IDBLUE Frequently Asked Questions

If any of these questions don’t seem to apply to your issue, please contact IDBLUE Support and we can walk you through any issues you might be encountering.


Software and Development

I have established connection to the device and having successful reads. However, the information of my reads is not being communicated back to my host application.

For Developers:

When developing this can happen for a few reasons:

  • The IDBLUE device sends the information back to the host application asynchronously via the established Bluetooth connection. Ensure that the connection is active and that the application is properly processing the asynchronous information from the IDBLUE device. Refer to the IDBLUE Firmware Interface Guide on our IDBLUE Documentation page for more information.
  • The IDBLUE device must be configured in a Connected Mode to retrieve the asynchronous tag information. Refer to the section Connected Operating Mode in our IDBLUE Users Guide on our IDBLUE Documentation page for more information.

For End Users:

This can happen due to improper device configuration settings. Please try power cycling your device and retry. If that doesn’t work, please try a Factory Reset which can be done from our IDBLUE RFID app. This will reset all configurable device properties back to their default settings.

Permalink.

What platforms are supported by IDBLUE.HF and IDBLUE.UHF?

IDBLUE devices are compatible with the following Bluetooth stacks:

  • Microsoft®
  • Broadcomm
  • Toshiba

IDBLUE provides out of the box support for:

  • Microsoft Windows 7, 8®, Microsoft Windows Vista®, Microsoft Windows XP®
  • Microsoft Windows Mobile 2003®, Windows Mobile 5® and Windows Mobile 6®
  • Apple iPad and iPhone

IDBLUE provides development tools for:

  • Microsoft Visual Studio.NET 2005®
  • Microsoft Visual Studio.NET 2008®
  • Apple XCode
  • Google Android

For other platforms, IDBLUE provides all of the necessary interface documentation required for communication with the IDBLUE device.

Permalink.

What software tools are available for IDBLUE devices?

IDBLUE provides multiple software packages as a free download for use with IDBLUE RFID reader:

  • IDBLUE Developer’s Toolkit: A toolkit to be used by developers of RFID applications. The toolkit contains:
    • Drivers and sample applications with source code for Visual Studio.NET® development
    • Developer Documentation including a Developer’s Guide and .NET Reference Guide
    • USB Driver for charging IDBLUE devices from a computer
  • IDBLUE Demonstration Package: A number of demonstration applications to showcase the use of IDBLUE devices. These include:
    • An Asset Management demonstration for Windows Mobile®
    • An RFID Workflow demonstration for Windows Mobile®
  • IDBLUE Serial API Document: For developers using a platform other than Visual Studio .NET. IDBLUE also provides the Serial API Document which provides the required information to communicate directly with an IDBLUE device. It’s available on our IDBLUE Documentation page

The IDBLUE software packages may be downloaded from our Drivers/Software page.

Permalink.

What kind of APIs does IDBLUE provide for developing applications for IDBLUE devices?

IDBLUE provides .NET and iOS APIs along with sample applications. In addition, IDBLUE provides the IDBLUE Serial API Document which provides the firmware commands to communicate directly with an IDBLUE device.

Permalink.

Do I need to do anything before submitting an App to iTunes Store with support for IDBLUE devices?

When working with any MFI accessory, the end user must register their app with the accessory manufacturer first as we need to whitelist your iOS app before you can submit it to the Apple App Store for approval. This is a requirement by Apple and stated in the iOS Developer Program License Agreement (as of  6/10/13).

iOS Accessories:
3.3.27 Your Application may interface, communicate, or otherwise interoperate with or control an
iOS Accessory (as defined above) through Bluetooth or Apple’s 30-pin dock connector only if

  • (i) such iOS Accessory is licensed under Apple’s MFi Licensing Program at the time that You initially submit Your Application,
  • (ii) the MFi Licensee has added Your Application to a list of those approved for interoperability with their iOS Accessory, and
  • (iii) the MFi Licensee has received approval from the Apple MFi Licensing Program for such addition.

You must supply IDBLUE with information regarding your App which we must register with Apple for approval  before your app will be whitelisted.

Requirements:

  • Your application must only start communication between your app and IDBLUE readers on an explicit action in the UI. It cannot auto­start upon connect and it must stop whenever the user stops using your application.
  • com.idblue.r8 is the only external accessory protocol that can be used by 3rd party apps. Make sure this is listed in your Info.plist in the UISupportedExternalAccessoryProtocols array.
  • After we have confirmed whitelisting of your app, you will need to add the following information to the “Review Notes” section of your Apple app submission: MFI PPID 111609-0001

NOTE: Your iOS app does not need to be re-whitelisted every time you release an update. However, we do reserve the right to remove an application from our whitelist if it appears that the app no longer meets requirements.

What are “Whitelisted” apps?

A key aspect of Mobile Application Management (MAM) is Whitelisted apps. Whitelisted apps are applications manufacturers/developers have deemed as safe to use on iPads and iPhones (Apple iOS devices) or Android phones and tablets.

What is the reason for “Whitelisting” apps?

Whitelisted apps are added to ensure that the applications being used are in fact the authorized apps and not malicious or otherwise inappropriate. These apps can be the same for all users or can be unique to each individual device group.

Additional links:

Please contact IDBLUE Support for more information.

Permalink.

Can I export HF/UHF tag data with IDBLUE devices?

You can export data from a tag to an application. If you need to read the HF tag’s UID or UHF tag’s EPC data, you can do it via

  • our Bluetooth SPP profile RFID devices using our software offerings (mentioned below) or
  • our Bluetooth HID profile RFID devices which integrate as a Bluetooth keyboard wedge across all supported platforms.

If you need something else from tag memory, it would require our IDBLUE SDK to be integrated within an application. To choose which Bluetooth Profile RFID device required for your project, it would depend on your timeline and your in-house development support.

On our IDBLUE Software page, we offer a Keyboard Wedge for Windows and Keyboard Wedge for Android which both send the HF tag UID or UHF EPC data via our SPP profile devices to any program as text output. We also provide Toolkits/SDK’s for integration into .NET, Android and iOS applications.

NOTE: Since iOS doesn’t allow native background processing (for keyboard wedge functionality as a background process), Developers using our SPP version devices would have to integrate our IDBLUE Driver/SDK into an existing iOS application to get the same information on your platform. Alternately, you can use the IDBLUE HID version to display tag information in any application.

For more information, contact our IDBLUE Sales Team.

Permalink.

How do I read or write to a UHF tag using IDBLUE.UHF?

In order to use our IDBLUE.UHF device, each UHF tag has to conform to the EPC Gen2 Class1 specification . Tag memory is logically separated into four distinct banks, each of which may comprise zero or more memory words. Memory within each memory bank is divided into 2-byte blocks.

  • Bank 00: Reserved – This memory bank stores the kill password and the access password (each are 32 bits). Most users do not use this memory area unless their applications contain sensitive data. It cannot store information besides the two codes.
  • Bank 01: EPC – This memory bank stores the EPC code, or the Electronic Product Code. It has a minimum of 96 bits of writable memory. The EPC memory is what is typically used in most applications if they only need 96 bits of memory. There are some tags that have the capability of allocating more bits to the EPC memory from the user memory. EPC memory is your first writable memory bank.
  • Bank 10: TID – This memory is used only to store the unique tag ID number by the manufacturer when the IC is manufactured and also has read and write capabilities.
  • Bank 11: User Memory – If the user needs more memory than the EPC section has available, certain ICs have extended user memory which can store more information. When it comes to user memory, there is no standard in how many bits of memory are writable on each tag.

To write to an EPC Gen2 Class1 UHF tag, you need 4 requirements:

  • EPC Bank
  • Bank Address (Index)
  • Number of words
  • Data to write

Once you have the information, you can use our epcRead and epcWrite commands in our IDBLUE SDK API’s.

//Setup the uhfResponseHandler as needed
IUhfResponseHandler _uhfResponseHandler = new UhfResponseHandler() {		
	@Override
	public void epcWriteTagResponse(IDBlueCommand command, EpcWriteTagResponse response) {			
		Log.i(TAG, "Write Bank Succeeded");
	}
	
	@Override
	public void epcWriteTagFailed(IDBlueCommand command, NackResponse response) {
		Log.i(TAG, "Write Bank Failed");
	}

	@Override
	public void epcReadTagResponse(IDBlueCommand command, EpcReadTagResponse response) {			
		Log.i(TAG, "Read Bank Succeeded");
		string epcHexData = HexConverter.toHexString(response.tagData().data());
	}
	
	@Override
	public void epcReadTagFailed(IDBlueCommand command, NackResponse response) {
		Log.i(TAG, "Read Bank Failed");
	}
};

com.idblue.core.IDBlueCoreApi api = new com.idblue.core.IDBlueUhfApi(new com.idblue.android.AndroidSession(getApplicationContext()));
short bank = 2;
short addr = 0;
short numWords = 1;
com.idblue.utilities.CByteArray data = new CByteArray("0000");

// Sample EPC Tag Read
com.idblue.core.SendStatus status = api.epcRead(bank, addr, numWords, _uhfResponseHandler);

// Sample EPC Tag Write
com.idblue.core.SendStatus status = api.epcWrite(bank, addr, numWords, data, _uhfResponseHandler);

Permalink.

Which operating modes do the IDBLUE devices support?

(This information is taken from the IDBLUE Serial Interface Specification on the IDBLUE Documentation page. The firmware commands referenced below have respective calls in each Developer SDK which can be called to set the desired modes. For more detailed information, please refer to the document above or the respective SDK interface guide.)

The IDBLUE device supports a number of different operating modes that govern its behavior when the action button is pressed. These operating modes are used to streamline the user experience of interacting with the device and to improve scanning performance. Choosing the appropriate operating modes for a given scenario and workflow is a crucial aspect of good IDBLUE integration. This section outlines what the various operating modes do and how they are best applied. The device supports two sets of operating modes; those for use when the device has an active connection to a host device (Connected mode) and when the device is operating independently (Disconnected mode). An IDBLUE device supports three scanning modes:

  • Single Scan. When the user of an IDBLUE device presses the Action Button, the IDBLUE device will scan a single tag.
  • Hold to Scan. The user of an IDBLUE device can press and hold the Action Button to continuously scan multiple tags.
  • Continuous Scan. The IDBLUE device can also be configured for a continuous scan mode whereby pressing the Action Button will activate continuously scanning tags. The IDBLUE device will continuously scan tags until the Action Button is pressed again, or until the Continuous Scan Timeout elapses without scanning any tag. Continuous Scan will take precedence over the Hold To Scan.

The IDBLUE device can also be configured to prevent repeatedly scanning tags within a certain timeframe. The duplication elimination property specifies the timeframe for which subsequent scans of a particular tag will be ignored. This is particularly important in the Hold to Scan and Continuous Scan modes of operation where tags will likely be scanned multiple times by the IDBLUE device.

Connected

The IDBLUE device supports five connected operating modes.

Normal Mode

The purpose of this mode is to streamline tag inventory scenarios wherein user data (i.e. data stored in user memory sections of RFID tags) is not required. In normal mode (also known as TAG_ID mode), when the Action Button is pressed and released the device will:

  • Indicate a start of RFID operations by turning the Action LED blue.
  • Attempt to scan a tag using the currently configured RFID protocol.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).
  • An asynchronous GET_TAG_ID response packet will be sent to the connected host.

If the Continuous Scanning Enabled property is set to true, the device will:

  • Enter continuous scanning mode when the Action Button is pressed and released.
  • Attempt to scan a tag using the currently configured RFID protocol.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).
  • An asynchronous GET_TAG_ID response packet will be sent to the host.
  • Attempt to scan another tag

The device will exit continuous scanning mode if:

  • The Continuous Scanning Timeout period elapses without a successful tag scan.
  • The action button is pressed and released.

Reactive Mode

The purpose of this mode is to handle non-trivial RFID interaction scenarios involving sequences of commands. In Reactive mode (also known as BUTTON PRESS mode), when the Action Button is pressed and released the device will:

  • Indicate a start of RFID operations by turning the Action LED blue.
  • Send an asynchronous button pressed packet to the connected host.

The host can then send more complex custom commands as desired to the device for an interactive user experience (for example, read a block of data, increment the value, write back to the tag, and issue a beep command to indicate success).

After an elapsed timeout of 1 second, with no commands received from the host, the device will:

  • Indicate an unsuccessful end of RFID operations by flashing the Action LED red.

The host application should issue an END_COMMANDS command after all RFID commands have been sent (in response to the asynchronous button press event) to signal that the host is finished sending commands. The Continuous Scanning Enabled property has no effect in Reactive mode.

Read Block N Mode (HF Only)

The purpose of this mode is to streamline tag inventory scenarios wherein a small amount of user data (i.e. data stored in user memory sections of RFID tags) is required. In Read Block N mode, when the Action Button is pressed and released, the device will:

  • Indicate a start of RFID operations by turning the Action LED blue.
  • Attempt to read block N (where N is the current value of the BlockIndex property) using the currently configured RFID protocol.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).
  • An asynchronous READ_BLOCK response packet will be sent to the connected host.

If the Continuous Scanning Enabled property is set to true, the device will attempt to scan another tag. The device will exit continuous scanning mode if:

  • The Continuous Scanning Timeout period elapses without a successful tag scan.
  • The Action Button is pressed and released.

Write Block N Mode (HF Only)

The purpose of this mode is to streamline tag inventory scenarios wherein one wishes to initialize a small amount of user data (i.e. data stored in user memory sections of RFID tags). In Write Block N mode, when the Action Button is pressed, the device will:

  • Indicate a start of RFID operations by turning the Action LED blue
  • Attempt to write block N (where N is the current value of the BlockIndex property) using the currently configured RFID protocol, using the Block data found in the BlockData property.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).
  • An asynchronous WROTE_BLOCK response packet will be sent to the connected host.

If the Continuous Scanning Enabled property is set to true, the device will attempt to scan another tag. The device will exit continuous scanning mode if:

  • The Continuous Scanning Timeout period elapses without a successful tag scan.
  • The Action Button is pressed and released.

Read Blocks Mode (HF Only)

The purpose of this mode is to streamline tag inventory scenarios wherein a moderate amount of user data (i.e. data stored in user memory sections of RFID tags) is required. In Read Blocks mode, when the Action Button is pressed, the device will:

  • Indicate a start of RFID operations by turning the Action LED blue
  • Attempt to read block N+M (where N is the current value of the BlockIndex property and M is the number of blocks to read from the BlockCount property) using the currently configured RFID protocol.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).
  • An asynchronous READ_BLOCKS response packet will be sent to the connected host.

If the Continuous Scanning Enabled property is set to true, the device will attempt to scan another tag. The device will exit continuous scanning mode if:

  • The Continuous Scanning Timeout period elapses without a successful tag scan.
  • The Action Button is pressed and released.

Disconnected

The IDBLUE device supports two disconnected operating modes.

Tag Verify Mode

The purpose of this mode is to streamline tag inventory scenarios wherein user data (i.e. data stored in user memory sections of RFID tags) is not required, and the data does not need to be recorded. In Tag Verify mode, when the Action Button is pressed and released, the device will:

  • Indicate a start of RFID operations by turning the Action LED blue
  • Attempt to scan a tag using the currently configured RFID protocol.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).

If the Continuous Scanning Enabled property is set to true, the device will attempt to scan another tag. The device will exit continuous scanning mode if:

  • The Continuous Scanning Timeout period elapses without a successful tag scan.
  • The Action Button is pressed and released.

Store Timestamp + Tag Id + Block 0 Data Mode (HF Only)

The purpose of this mode is to streamline tag inventory and recording scenarios wherein user data (i.e. data stored in user memory sections of RFID tags) is not required, and the data does need to be recorded and saved. In Tag Store mode (aka Store Timestamp + Tag Id + Block 0 Data), when the Action Button is pressed and released, the device will:

  • Check for a valid timestamp value¹.
  • If no valid timestamp is present (i.e. the device’s timestamp has not been set), the LED will blink double-yellow.
  • If a valid timestamp is present, the device will indicate a start of RFID operations by turning the Action LED blue.
  • Attempt to read block 0 from a tag using the currently configured RFID protocol.
  • If a tag is successfully scanned, the device will indicate with a green LED and audio beep (if audio feedback is enabled).

The current timestamp, tag ID, and contents of byte 0 (in block 0) on the tag will then be stored in the internal tag database (see Tag Store for details). This data can later be accessed through the GET_ENTRY command. If the Continuous Scanning Enabled property is set to true, the device will attempt to scan another tag. The device will exit continuous scanning mode if:

  • The Continuous Scanning Timeout period elapses without a successful tag scan.
  • The Action Button is pressed and released.

Note that disabling Duplicate Elimination and/or setting the Duplicate Elimination timeout to 0 while Continuous Scan or Hold To Scan are enabled will quickly fill up the Tag Store memory of the IDBLUE device. It is not recommended to enable Continuous Scan or Hold To Scan without enabling Duplicate Elimination and setting a Duplicate Elimination timeout.

¹ This check can be disabled through the TimeStampRequired property.

Permalink.

What configurable properties are available for IDBLUE devices?

(This information is taken from the IDBLUE Serial Interface Specification on the IDBLUE Documentation page. The firmware commands referenced below have respective calls in each Developer SDK which can be called to set the desired properties. For more detailed information, please refer to the document above or the respective SDK interface guide.)

All of the configurable behavior of the IDBLUE device is managed through the use of device properties. These properties are configured via the Get Property, Set Property, Load Properties and Save Properties commands.

  • Continuous Scanning – Whether or not continuous scanning mode is enabled. Refer to section Operating Modes on continuous scanning mode. Format:
    • Disabled (00h) (Default)
    • Enabled (01h)
  • Timestamp Required – Whether or not a valid timestamp (i.e. the timestamp property has been set since the device has been turned on) is required when storing tag ID’s in disconnected mode. Format:
    • Disabled (00h)
    • Enabled (01h) (Default)
  • Duplicate Elimination Timeout – When scanning tags, this property specifies the timeout (in milliseconds) between reads that duplicate scans of the same tag will be ignored. Format:
    • 0 = no timeout (Default)
    • 100 = 100 ms
    • Maximum value is 10000 (10 seconds).
  • Time – The timestamp stored on the device. When the device first turns on, the device will not know what time it is and will start tracking time from 0000-00-00 00:00:00. Once this property is set, the device will keep track of time until it is turned off.
  • Disconnected Mode – (HF Only) Configures the disconnected (i.e. not connected to a host via USB or Bluetooth) operating mode of the IDBLUE device. For more information, please read Operating Modes FAQ.
    • Default: Tag Verify (00)
  • Connected Mode – (HF Only) Configures the connected (i.e. connected to a host via USB or Bluetooth) operating mode of the IDBLUE device.  For more information, please read Operating Modes FAQ.
    • Default: Tag ID (03)
  • RFID Protocol – (Read Only) The currently selected RFID Protocol. More information about the supported RFID protocols is available in section Supported Protocols.
    • IDBLUE.HF = ISO15693 (01h)
    • IDBLUE.UHF = EPC Gen 2, ISO 18000-6C (02h)
  • Buzzer – Whether or not the on-board audio buzzer is enabled. Format:
    • Disabled (00h)
    • Enabled (01h) (Default)
  • Device Timeout – The idle time (in minutes) before the device shuts down. A value of 0 means that the device will not shut down automatically.
    • 0 – No timeout
    • Values values: 1-255
    • Default: 10 minutes
  • RFID Timeout – The time in seconds before an RFID operation (select tag, read block, etc) times out. The timer begins as soon as the RFID operation begins and the operation will fail (timeout) if the timeout elapses before the operation is complete.
    • Min value: 1 second
    • Max value: 16 seconds
    • Default: 4 seconds
  • Bluetooth Timeout – The time in minutes before the Bluetooth link times out and shuts down. Note: this only applies when the device does not have an active Bluetooth connection.
    • Valid values: 1-255 minutes
    • 0 = no timeout (Default)
  • Continuous Scanning Timeout – In continuous scanning mode, this property controls how long the device will “scan” without finding a tag before ceasing continuous operations.
    • Valid values: 1-255 seconds
    • 0 = no timeout
    • Default: 16 seconds
  • Block Index – (HF Only) For connected modes Read Block N and Write Block N this property configures which block index is used for the operation.
    • Valid values: 0-255
    • Default: 0
  • Block Data – (HF Only) For connected mode Write Block N this property sets the block data used for the operation.
    • The maximum length is 8 bytes.
    • Default: 00 00 00 00
  • Block Count – (HF Only) For connected mode Read Blocks, this property configures the block count (i.e. number of blocks read).
    • Valid values: 1-255
    • Default: 1
  • Version Information – (Read Only) Extended versioning information. Contains full major/minor/build information for both hardware and firmware versions, as well as a version comment string.
  • Hold To Scan – Specifies whether Hold To Scan is enabled. Format:
    • Disabled (00h)
    • Enabled (01h) (Default)
  • Action Button – Enable or Disable the front Action button. Format:
    • Disabled (00h)
    • Enabled (01h) (Default)
  • AutoConnect to Host – When enabled, this will attempt to connect to the last known iOS host automatically when powered on. Format:
    • Disabled (00h)
    • Enabled (01h) (Default)

In addition, you can set the following properties directly:

  • Set Bluetooth PIN – This command assigns a PIN code (passkey) for Bluetooth connectivity. The Bluetooth security PIN (also known as a passkey) for connecting to the IDBLUE device and is a series of ASCII characters, of length up to 16 characters.
  • Default: 0000
  • Set/Get Bluetooth Name – Assign a new or fetch the display name of the IDBLUE device. This identifying name will be displayed when a host scans for Bluetooth devices. The name has a maximum length  of 16 ASCII characters (bytes).
    • Default: IDBLUE-HF-<last 4 characters of Bluetooth MAC address> or IDBLUE-UHF-<last 4 characters of Bluetooth MAC address>

The Factory Default Settings are set to the below values. Your device can be reset back to the default properties by performing a Factory Reset command. The following values are not reset as they either don’t change or unaffected.

  • Time
  • RFID Protocol
  • Version Information

Permalink.

What firmware commands can I send to an IDBLUE HF and UHF device?

(This information is taken from the IDBLUE Serial Interface Specification on the IDBLUE Documentation page. The firmware commands referenced below have respective calls in each Developer SDK which can be called to set the desired effect. For more detailed information, please refer to the document above or the respective SDK interface guide.)

Communication between the IDBLUE device and host occurs using a series of requests and responses.

  • Requests are packets sent to the IDBLUE device from the host. They are used by the host to ask for information or for the device to perform some task.
  • Responses are sent from the IDBLUE device. They are the result sent back to the host after a request has been issued (or after an asynchronous event has occurred). Responses indicate either success and return information or indicate failure and an indication of the reason for failure.
    • The Developer SDK has a response handler for a success and failure event which the developer refers to when waiting for a response.

IDBLUE devices will queue most commands and process them in sequential order, with the exception of SET_SCANNING which stops a continuous scan operation.

Asynchronous Events

In addition to the standard request/response packets, the IDBLUE device also supports a set of asynchronous notifications. These notifications are typically generated in response to the user pressing the Action Button on the device.

When the user presses the Action Button on the device, an asynchronous event is created, sending a response packet to the host. To designate this packet as an asynchronous event and not a possible response to an earlier command issued over the serial connection, a special packet (ASYNC) is sent before the main packet to indicate that it is an asynchronous event.

This is true for all modes of operation during a button press. Applications (and driver libraries) should interpret the response packet immediately following an ASYNCH (asynchronous header) packet as an asynchronous event.

Supported IDBLUE Commands

The table below provides a summary of all currently supported IDBLUE commands. Driver developers should incorporate support for all of these commands into any offering.

Core Functions

  • NO_OP – No operation; used to check for the presence of a connected device.
  • GET_STATUS – Requests an information snapshot of the device’s current status (includes battery level and hardware and firmware versions).
  • BEGIN_COMMANDS – Informs the device that a connected host application is about to issue a series of RFID commands. The device then displays appropriate audible and visual feedback to the user.
  • END_COMMANDS – Informs the device that a connected host application has finished issuing a series of RFID commands. The device then displays appropriate audible and visual feedback to the user.
  • POWER_DOWN – Powers down the IDBLUE device.
  • BEEP – Causes the device to emit one of the standard audio tone sequences.
  • BLUETOOTH_OFF – Turns off the Bluetooth transmitter.
  • SET_SCANNING – When the device is in continuous scanning mode, start or stop scanning for tags using the current connected mode.

Configuration Commands

  • SET_PROPERTY – Sets one of the device’s configuration properties. These values are volatile unless saved by issuing a SAVE_PROPERTIES command.
  • GET_PROPERTY – Gets the current value of one of the device’s configurable properties.
  • SAVE_PROPERTIES – Saves the current configuration properties to FLASH (i.e. these values will be stored when the device is powered down).
  • LOAD_PROPERTIES – Load the stored configuration properties.
  • FACTORY_RESET – Resets all properties to factory defaults.
  • SET_BT_PIN – Sets the Bluetooth PIN.
  • SET_BT_NAME – Assigns a Bluetooth device display name.
  • GET_BT_NAME – Returns the Bluetooth device display name.
  • ENABLE_CHANNEL – Enables or disables the logical communication channel.

To list what configurable properties are available, please check the Configurable Properties Article.

Common RFID Commands

  • GET_TAG_ID – Performs a tag inventory and returns the tag id of the RFID tag in the RF field.
    • For HF tags, it returns the HF tag’s ID
    • For UHF tags, it returns the UHF tag’s EPC bank data. Why?

HF RFID Commands

  • READ_BLOCK – Reads a single block of tag memory from a specified tag ID.
  • READ_BLOCKS – Read multiple blocks of tag memory from a specified tag ID.
  • WRITE_BLOCK – Write a single block of data to a specified tag ID.
  • WRITE_BLOCKS – Write multiple blocks of data to a specified tag ID.
  • GET_TAG_INFO – Returns information about the tag in the field.

HF Stored Tag Functions

  • GET_ENTRY_COUNT – Returns the number of tags stored on the device. Each tag record contains the tag ID, an optional timestamp and a single byte of data from the tag.
  • GET_ENTRY – Retrieves a specific stored tag record from the device.
  • CLEAR_ENTRIES – Deletes all stored tag information on the device.

UHF RFID Commands

  • EPC_WRITE_TAG – Write to a memory bank on an EPC Gen 2 tag.
  • EPC_READ_TAG – Read a memory bank from an EPC Gen 2 tag.
  • EPC_LOCK_BITS – Lock an EPC Gen 2 tag.
  • EPC_SET_KILL_PASSWORD – Sets the kill password for an EPC Gen 2 tag.
  • EPC_KILL_TAG – Kill an EPC Gen 2 tag.

Permalink.

Why does Normal Connected Mode (or using GetTagID command) on IDBLUE.UHF return EPC and not TID bank information?

NOTE: This also applies to the Keyboard Sender for Windows, Keyboard Wedge for Android and the HID version of our IDBLUE.UHF as they all use the GetTagID command in order to return tag information.

There are potential issues using TID bank data over EPC bank data… It is not a requirement in the EPC Gen2 specification to have a serial number programmed in the TID bank by the manufacturer. Therefore, certain EPC Gen2 tags that are not serialized had the same data in the TID bank. This is different over HF as the Tag UID in ISO15693/HF TID bank where they were uniquely serialized and locked when manufactured.

If you want to make sure the EPC bank doesn’t get modified, you can (set the EPC memory and)  lock the tag to make it unalterable but always readable.

If you are still interested in reading TID memory, we recommend setting the device to Reactive Connected Mode and doing an epcRead command to return the desired information you need.

According to the EPC Gen2 V2 specification: (NOTE: bolded for emphasis)

6.3.2.1 Tag memory

EPC memory shall contain a StoredCRC at memory addresses 00h to 0Fh, a StoredPC at addresses 10h to 1Fh, a code (such as an EPC, and hereafter referred to as an EPC) that identifies the object to which the Tag is or will be attached beginning at address 20h, and if the Tag implements Extended Protocol Control (XPC) then either one or two XPC word(s) beginning at address 210h. See 6.3.2.1.2.

TID memory shall contain an 8-bit ISO/IEC 15963 allocation class identifier at memory locations 00h to 07h. TID memory shall contain sufficient identifying information above 07h for an Interrogator to uniquely identify the custom commands and/or optional features that a Tag supports. See 6.3.2.1.3

6.3.2.1.3 TID Memory

TID memory locations 00h to 07h shall contain either an E0h or E2h ISO/IEC 15963 class-identifier value. The Tag manufacturer assigns the class identifier (E0h or E2h), for which ISO/IEC 15963 defines the registration authority. The class-identifier does not specify the Application. TID memory locations above 07h shall be defined according to the registration authority defined by this class-identifier value and shall contain, at a minimum, sufficient information for an Interrogator to uniquely identify the custom commands and/or optional features that a Tag supports. TID memory may also contain Tag- and manufacturer-specific data (for example, a Tag serial number).

To further elaborate, there are more details described in the RFID Journal article “Identifying RFID’s Biggest Threats” (NOTE: bolded for emphasis):

What Changed With Gen 2

Part of the genius of EPC Gen 2 is that, upon being initially interrogated by a reader, the tag transmits an Electronic Product Code—a UII that identifies the product the tag to which it is attached—instead of transmitting a TID number assigned by the chip manufacturer (which just identified the tag). The “genius” is that it achieves two benefits over past designs: First, it assures that the initial read provides actual item identification, and second, it enables the UII to provide the key to a long list of business and consumer benefits, accessed via the Internet or some other network. The creation of EPC Gen 2 was the first time in RFID history that the TID was not read as the initial action between the reader and the chip. What’s more, the first supply of Gen 2 chips did not even contain a TID. This has been corrected, and the standards now support that a unique serial number can be written—and locked—to the TID in Gen 2 chips, thereby providing assurance that the tag’s data has not been duplicated into another tag (unique data = UII + TID).

Permalink.

How do I tell when a tag is scanned?

One of the features of IDBLUE.HF and IDBLUE.UHF is having an internal real-time clock to allow time-stamping of each tag scan. The IDBLUE driver/sdk returns the timestamp (and with HF, it also returns the tag UID) on a scan.

//Setup the hfResponseHandler as needed
IHfResponseHandler _hfResponseHandler = new HfResponseHandler() {
    @Override
    public void readTagIdResponse(IDBlueCommand command, ReadTagIdResponse response)
    {
        // response.async() indicates whether the tag scan resulted from
        // a button press of IDBLUE (async), or from a call to readTagId (sync).
        String async = response.async() ? "Async Tag ID" : "Sync Tag ID";

        RfidTag tag = response.rfidTag();
        IDBlueTimestamp scanTime = response.timestamp();

        String tagId = tag.toString();
        String ts = scanTime.toString();

        OnSuccess(READ_TAG_ID_MODE, String.format("%s: %s, Timestamp: %s.", async, tagId, ts));
    }
}

Note that the IDBLUE driver/sdk does not set the timestamp on the reader as it is the responsibility of the client app to call setTimestamp() at some point in order to setup a valid timestamp on the reader.

If you have any further questions, you can contact IDBLUE Support.

Permalink.

Do you have a plugin for Adobe AIR or Apache Cordova?

We don’t directly support an API/plugin for Adobe Air or Apache Cordova but if you have access to the Bluetooth SPP profile of our device, you can send and receive commands to the device directly. You can read our IDBLUE Serial Interface Specification on our IDBLUE Documentation page on how to send and receive firmware commands. As well, you can refer to our IDBLUE Developer Toolkit for Google Android on our IDBLUE Software page which includes our IDBLUE JAR driver and sample JAVA Eclipse application.

If you are using our reader to return HF’s Tag UID or UHF’s EPC bank similar to a keyboard wedge, our devices now support the Bluetooth HID Profile which might be a better fit for your solution. It requires no driver/development and is configured to connect using the Bluetooth HID Profile as an Input Device. The device will send the information using the keyboard buffer and automatically inserts it into the current focused text field.

For more information, please contact IDBLUE Support.

Permalink.

How do I initialize the IDBLUE iOS SDK?

NOTE: This is taken from the IDBLUE iOS SDK documentation. Please refer to the SDK documentation for more details.

In this example, we show you how to create your own class, IDBlueApi, that inherits from IDBlueHfApi. You can use this class to communicate with IDBLUE devices.

The IDBlueHfApi takes care of all of the leg work of initializing the SDK. All you need to do is override a few methods and make a few calls into the IDBlueHfApi (and IDBlueCoreApi). You should review IResponseHandler and ISessionHandler if you haven’t already done so.

Create a class named IDBlueApi that inherits from IDBlueHfApi, like so:

// IDBlueApi.h
#import <Foundation/Foundation.h>
#import "IDBlueHfApi.h"
#import "iOSSession.h"

// By sub-classing IDBlueHfApi, IDBlueApi is the only object from the IDBLUE
// iOS SDK you need to instantiate.
@interface IDBlueApi : IDBlueHfApi {
    iOSSession* _iosSession;
}

-(BOOL) openFirstIDBlueDevice;

@end

The corresponding implementation file should look like:

#import "IDBlueApi.h"
@implementation IDBlueApi
-(id) init {
    _iosSession = [[iOSSession alloc] init];
    self = [super initWithSession: _iosSession];
    if (self) {
        // Log the current version of the SDK we are using
        NSLog(@"%@", [self sdkVersion]);
        // add custom initialization here
    }
    return self;
}

-(BOOL) openFirstIDBlueDevice {
    return [_iosSession openFirstIDBlueDevice];
}
@end

Now you’re ready to start using the IDBLUE SDK in your application. When you’re application starts, create an instance of IDBlueApi:

// Initializing the IDBLUE SDK is as simple as creating an instantiate of IDBlueApi
IDBlueApi* sdk = [[IDBlueApi alloc] init];

Before you can communicate with an IDBLUE device in your application, you need to open a session first. Since iPhone only supports one connected accessory at the moment, you can design your application to use the one and only IDBLUE device (if one is present).

To do this, use the openFirstIDBlueDevice method of iOSSession:

if ([sdk openFirstIDBlueDevice]) {
    // onSessionOpened callback method will be called when the session is open
}
else {
    // A session could not be opened. Is IDBLUE paired with the iPhone?
}

To get notifications of session events (such as session opened, session closed, etc.) you have 2 options:

  • Override the session event callback methods in IDBlueApi
  • Create a separate class that implements the protocol ISessionHandler and register it with the IDBlueiOSSdk using addSessionDelegate

Overriding the callback methods in IDBlueApi is the simpler method. To do that, add the following code to IDBlueApi.m:

// SessionHandler callback methods we are overriding
-(void) onSessionOpened: (id) session {
    [super onSessionOpened:session];
    NSLog(@"IDBLUE session opened");
}

-(void) onSessionClosed: (id) session {
    [super onSessionClosed:session];
    NSLog(@"IDBLUE session closed");
}

When using the IDBLUE iOS SDK, sessions should be managed as follows:

  • openFirstIDBlueDevice should be called when you application starts and when it resumes from the background
  • closeSession should be called when you application goes to the background and when it terminates
  • You can use the UIApplicationDelegate protocol to detect when your application resumes from the background, is going to the background and when it terminates.

Now that we have the communication completed, let’s turn our attention to sending commands to IDBLUE and handling responses.

The IDBLUE SDK is designed asynchronously. That is, when you send a command to IDBLUE, the IDBLUE SDK does not wait for a response. Applications are notified of responses via the IResponseHandler protocol. When a response is received from IDBLUE, all registered IResponseHandlers are notified of the response via the appropriate callback method.

Note: the IDBlueCoreApi is itself a ResponseHandler (a class that implements the IResponseHandler protocol). So when you want to listen for events from IDBLUE, it’s as simple as overriding the ResponseHandler methods in your IDBlueApi class.

For example:

You want IDBLUE to scan for an RFID tag, and return back the tag identifier to our application. To do this you would call readTagId. Asynchronously, one of 2 possible callback methods will be invoked: either readTagIdResponse or readTagIdFailed, depending on whether an RFID tag was read successfully or not.

// IDBlueApi.h
-(BOOL) getTagId;

// IDBlueApi.m
// Illustrates how to get IDBLUE to scan an RFID tag and give us back the tag id.
// If IDBLUE finds a tag, the readTagIdResponse callback method will be invoked.
// If no RFID tag was found or an error occurred, the readTagIdFailed callback
// method will be invoked.
-(BOOL) getTagId {
    SendStatus* status = [self readTagId:self];
    if ([status successful]) {
        NSLog(@"get tag id command sent to IDBLUE");
        return TRUE;
    }
    else {
        NSLog(@"failed to send get tag id command to IDBLUE");
        return FALSE;
    }
}

// ResponseHandler callback methods we are overriding
-(void) readTagIdResponse: (IDBlueCommand*) command
                         withResponse: (ReadTagIdResponse*) response {
        [super readTagIdResponse:command withResponse:response];
        RfidTag* tag = [response rfidTag];
        NSString* tagId = [tag toString];
        NSLog(@"Got tag id: %@", tagId);
}

-(void) readTagIdFailed: (IDBlueCommand*) command
                   withResponse: (NackResponse*) response {
        [super readTagIdFailed:command withResponse:response];
        NSLog(@"Get tag id failed");
}

Permalink.

When using the HID version of IDBLUE devices, I don’t have the onscreen keyboard anymore!

This is a known issue with HID profile devices in general. Our IDBLUE HID profile device is recognized as a secondary keyboard and, by default, a smartphone may disable viewing the onscreen keyboard.

iOS:

You can toggle the onscreen keyboard by pressing the power button when connected.

Android:

Once you pair with the IDBLUE HID device:

  • Go to Settings and select “Language and input”.
  • Click on “Default” (Or “Current Keyboard” in Android 5.0+) located just under the “Keyboard and input methods” heading to open the “Choose input method” dialog.
  • Turn the “Hardware physical keyboard” OFF (or on Android 5.0+, it’s referred to “Hardware: Show input method”.

This setting will toggle the onscreen keyboard when you select a text field when paired with our HID profile device. If you have any other questions, please contact IDBLUE Support.

Permalink.