Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Note: Forums will be making significant UX changes to address key usability improvements surrounding search, discoverability and navigation. To learn more about these changes please visit the announcement which can be found HERE.
Resources for IT Professionals >
> 
> 
> 
Rfidsink and TagIdAsHex column

Answered Rfidsink and TagIdAsHex column

  • Wednesday, June 09, 2010 8:33 PM
     
     
    Sign In to Vote
    0

    Hi.

    When reading tags with the readers test application, I get the tagid as a hex value; E005... something. When it comes down to the rfidsink the value is 0x44321...something.

    So what happens with the hex value during its way to the rfidsink?

    Regards,

    Arthur

     

All Replies

  • Friday, June 11, 2010 12:08 PM
     
     
    Sign In to Vote
    0

    Hi Arthur

    The TagID's are hexencoded using "HexUtilities.HexEncode()" on their way to the RFID Sink. (You ought to see the identical TagID's when you do ViewTags from RFID Manager)

    To help us understand why you are seeing different TagID's, can you provide us the exact hexvalue that you are seeing in the test application and the hexvalue you are seeing in RFID Sink? With this, we can check if the application is using a different encoding to display the tag id (for example, base64 encoding, or it might be hex-encoding the bytes in the reverse direction).

    Also, which provider are you using? BizTalk RFID relies on the Tag Id that is surfaced by the Provider you are using... so if you are seeing an incorrect value for the tag id, typically there is an issue in the Provider: to check whether this is actually the case, you can turn on verbose logging in the Provider (in the hope that the Provider logs the tag ids that it is seeing in this mode) and check if there is any kind of disparity between the ids being seen in the reader's test application and the ids being logged in the Provider logs.

    Thanks

    Vipul

     

     

    Vipul
     
  • Friday, June 11, 2010 1:52 PM
     
     
    Sign In to Vote
    0

    Hi Vipul.

     

    I am using a DLP-RFID reader for testing. When using the test application shipped with that one, I get this value reading a tag: E007000002DF94BC

    In the view tags in RFID manager and in the rfidsink I get: 45303037303030303032444639344243

    The provider I am using has the vendor Irving De la Cruz (irvingd@microsoft.com). I downloaded it from his blog. Microsoft.DlpDesignDevices.DSPI.dll.

    The reason why I got into this is that a customer wants to have a database column with the decimal values. So I tried to convert from hex to decimal with this value, 45303037303030303032444639344243. The decimal value I got was 4.3724624747578124e+30.

    Regards,

    Arthur

     

     
  • Friday, June 18, 2010 10:05 AM
     
     Answered Has Code
    Sign In to Vote
    0

    Hi Arthur,

    Sorry for the late response. This looks like a problem with the Provider.

    You might have noticed the relation between the two patterns already: The hex-value of the character 'E' in ASCII is 0x45, that of '0' is 0x30 and so on. What seems to be happening is: the provider hex-encoded the actual tag id bytes into a string once, and when it has to convert it back to a byte array, it simply interpreted each character in the string as a separate byte (instead of decoding the hex value).

    Ideally, this has to be fixed in the Provider. You can get the original tag id with some code along the following lines:

    byte[] ConvertToCorrectId(byte[] rcvd)
{
  char[] ch = new char[rcvd.Length];

  for (int i = 0; i < rcvd.Length; ++i)
  {
    ch[i] = Convert.ToChar(rcvd[i]);
  }

  string s = new string(ch);
  return HexUtilities.HexDecode(s);
}

    You can modify the provider code to call this method before an event is raised to the BizTalk RFID Service.

    -Kranthi.