NDEF parsing problem

[JeremyParticipant]

Hi,
I’m using v1.8 of the SDK after purchasing the non-pro version. I setup a test app as described in the readme file and got that running.

My goal is to place a tag against an ACS-35 and grab the string stored within that tag which I had previously written.

After researching the technical details of NFC and NDEF, I tweaked the demo to turn on isFlojackEnabled (to enable active scanning since Floble didn’t seem to notice my tag). Also changed operational state to kReadDataBlocks and the startBlock from 8 to 4 since that’s where the data starts. After that, the app would recognize the tag no problem and read 16 bytes of data starting from the starting block.

The problem I’m having is after doing this:
NDEFMessage *newMessage = [[NDEFMessage alloc] initWithByteBuffer:tag.data];
I would expect to see a record within the NDEF message object that would have my string but I don’t.

The data on the tag is as follows:
04 88 f3 f7 c2 43 2f 80 2e 48 00 00 e1 10 12 00
01 03 a0 10 44 03 2a d1 01 26 54 01 7b 22 55 6e
69 71 75 65 45 78 74 65 72 6e 61 6c 49 64 22 3a
22 53 61 6d 70 6c 65 41 50 49 41 73 73 65 74 22
7d fe

Visually parsing the data from block 4, there are 2 NDEF TLVs – a Lock Control TLV (0x01) and a NDEF Message TLV (0x03). initWithByteBuffer gives me just 1 record and the type and payload are parsed incorrectly. The type contains 0x032ad1 and the payload contains 0x01.

Here’s the code to view the records:
case kReadDataBlocks: {
NSLog(@”%@”,tag.data); // Log the Data
NDEFMessage *newMessage = [[NDEFMessage alloc] initWithByteBuffer:tag.data];
NSLog(@”%@”,newMessage); // Log the NDEF

for (NDEFRecord* record in newMessage.ndefRecords)
{
NSLog(@”%@”,record);
NSLog(@”record.type: %@”,record.type);
NSLog(@”record.payload: %@”,record.payload);
}
break;
}

and here’s the log:
2015-12-23 15:37:55.236 FlomioJackTest[788:503692] Polling for tags
2015-12-23 15:37:55.495 FlomioJackTest[788:503692] Polling for tags
2015-12-23 15:37:55.547 FlomioJackTest[788:503692] Type:Mifare Ultralight
2015-12-23 15:37:55.549 FlomioJackTest[788:503692] ::commandApdu = <ffb00004 10>
2015-12-23 15:37:55.750 FlomioJackTest[788:503692] Type:Mifare Ultralight
2015-12-23 15:37:55.751 FlomioJackTest[788:503692] ::commandApdu = <ffb00004 10>
2015-12-23 15:37:55.895 FlomioJackTest[788:503689] *** -[NSLock unlock]: lock (<NSLock: 0x14763fc40> ‘(null)’) unlocked from thread which did not lock it
2015-12-23 15:37:55.896 FlomioJackTest[788:503689] *** Break on _NSLockError() to debug.
2015-12-23 15:37:55.896 FlomioJackTest[788:503689] Suspend scan timer 0x14752e020
2015-12-23 15:37:56.289 FlomioJackTest[788:503674] <0103a010 44032ad1 01265401 7b22556e>
2015-12-23 15:37:56.291 FlomioJackTest[788:503674] <NDEFMessage: 0x1475506f0>
2015-12-23 15:37:56.292 FlomioJackTest[788:503674] <NDEFRecord: 0x147561980>
2015-12-23 15:38:50.531 FlomioJackTest[788:503674] record.type: <032ad1>
2015-12-23 15:38:53.103 FlomioJackTest[788:503674] record.payload: <01>

I assume the ReaderManager would normally start with the first TLV and continue reading blocks as needed (since only 16 bytes at a time ran be read). And to parse each record until the end is reached (0xFE in this case)?

thanks in the help in advance:)

[ScottKeymaster]

Thanks for your detailed post, Jeremy.

As you mentioned, the problem with NDEF when it comes to the FloJack (and soon the FloBLE devices we will sell) is that we can only read/write 16 bytes of data per APDU command. You’re right, there’s a need to add a data block enumeration engine to our SDK that will hold a virtual data space of what is read or needs to be written to a tag and then loop through the read/writes to get out or put in the bytes (and validate they were written correctly). I am currently building a parser for payment TLV APDUs but I will be moving onto a NDEF parser integrated with a Data Block Enumeration engine to meet your specific case.

One thing that is worth being aware of is that the FloJack has an inherent latency when executing command/response APDUs due to the slow audio interface. It takes roughly 300ms for 16 byte APDUs to be transacted.
More details on APDU timing with FloJack on this Forum post. FloBLE devices which are on sale now are 4x faster and will be shipping in January, 2016.

[Author]

Posts