Help reading data from rfid data blocks and returning it as keyboard emulation

Help reading data from rfid data blocks and returning it as keyboard emulation


I am trying to modify the WindowlessRfidDefaultHandlerImpl.cpp to make it work a bit differently.
Basically I do not want it to return the RFID UID but the data in the tag.
I am struggling and I have very limited amount of time.

Basically I do not understand how to mix these things together to achieve what I explained:

RF_SetDataReadRange(mRfidHandle, 21, 10);

stat = RF_GetTagData(mRfidHandle, tagHandle, tag->data, &tagDataSize[bcd->data.rfid.count]); // I took this from DefaultHandlerImpl.cpp

Besides, how is data saved in tag->data, from the API it looks like it is 1 BYTE. What if data read is bigger (like in my case 10 bytes).

Can you please help me .


5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hello nosf,Can you tell us what version of the MCA software you are developing with? Also, can you provide more background info on the reason for the change so we can understand what your end goal is?Thanks,Steve


I am using 3.0.0 build 35538 (both the sdk and the mca config editor on my motion c5v report this version).

I need to read an RFID wirstband. Inside it there is a medical record code.
This code is 10 bytes (10 numbers) and is saved into 10 contigous bytes starting from byte 21 of the tag.

I need to read this value and return it as keyboard input (keyboard emulation).

I thought I might start with the windowlessrfiddefaulthanlder, so I had a look at the code at the function:

int WindowlessRfidDefaultHandlerImpl::GrabData(ButtonCapturedData_t** ppData)

I want to modify it (and also the function that calls it) so that I can return my data in the keyboard buffer.

I am working on it. If you have any idea please let me know.


I managed to read the data blocks and return them in the keyboard input buffer.
I basically modified the WindowlessRfidDefaultHandlerImpl.cpp to achieve what I wanted .

Here is an extract of what I did in the function GrabData:

// read in the tags
BCD_Tag_t* tag = (BCD_Tag_t*)dataBuf;
DWORD tagIdSize = _countof(tag->id);

//Custom Code

//stat = RF_GetTagId(mRfidHandle, tagHandle, tag->id, &tagIdSize);

BYTE* tagData = NULL;
DWORD tagDataSize1 = 10;

HCStatus returnStatus = RF_SetDataReadRange(mRfidHandle, 24, 10);

BH_LOG_ERROR(L" MYDEBUG size %d",tagDataSize1);

tagData = new BYTE[tagDataSize1+1];

// Get the tag data
stat = RF_GetTagData(mRfidHandle, tagHandle, tagData, &tagDataSize1);
// Do something with tag data

WCHAR mystring[50];

for (DWORD count = 0; count < tagDataSize1; count++) {

BH_LOG_ERROR(L" MYDEBUG %c", tagData[count]);
mystring[count]=(WCHAR)tagData[count] ;

for(int i=10;i<50;i++)

BH_LOG_ERROR(L" MYDEBUG %s", mystring);

memcpy((void *)tag->id, (void *)mystring,50);

delete [] tagData;

//END Custom Code


It is not a clean solution (it needs error checking and code improvement) but it works.


Hi nosf,

You are going in the right direction to achieve the specified solution. Here is some guidance to help and maintain the code in long run:

1. Are you trying to write a default handler and configure the same as the acting default handler? If so, the code changes would achieve the required functionality. If you need to develop an application that would be used independently or as an button application then default handler is not an option. Please check the documentation in the MCA SDK developers guide when a default handler is execute.

2. The id field in the BCD_Tag_t is designed for holding a UID data and its size is very much specific to the UID length. In case your requirement changes in future to read a bigger data field, you might a face problem. Rename the field name to reflect that it holds data portion and have a size variable defined in a common place to use the same in all the places such as memory allocation, copying etc. In the future if you need to change on this variable whenever you required to handle large value.

3. In the existing code there is a portion where the pre-read mode is set to false. When pre-read mode set to false, the UID portion is read when the first read is done. The same tag need to be present in front of the reader when the data portion is requested later. Please set the pre-read mode to true as you are required to read the data portion.

4. Try not to keep the same name for your default handler (windowlessrfiddefaulthanlder) while distributing it to the market as the same name will clash with the Intel provided one and user might expect an UID portion as per Intel documentation. If you face some problem while configuring your default handler after renaming it, please let us know.


Leave a Comment

Please sign in to add a comment. Not a member? Join today