Writing a number to NFC

[ErikParticipant]

Hi!

I got my FloBle Plus working fine now. Reading UUIDs and polling with [readerManager sendApdu:@”FF CA 00 00 00″ toDevice: deviceId] is no problem.

Next thing I’m hoping to do is writing an int to the tag. Im not familiar with the APDU protocol. The tags we use is ULEV1.

Could you please point me in the right directing? Is this fairly simple or should i give up? =)

[ErikParticipant]

I made some progress, I thought this might be interesting for people new to NFC and NDEF like me. (Also Id like to know if Im on the right track or if this i REALLY STUPID?!) =)

This is a really basic way to store a byte in NDEF format and also wiping the data on the tag.

- (void)writeUsedTicket:(NSString *)ticket toDevice:(NSString *)deviceId {
    [readerManager sendApdu:@"FF D6 00 04 04 03 06 D1 01" toDevice: deviceId];
    [readerManager sendApdu:[NSString stringWithFormat:@"FF D6 00 05 04 01 54 %@ 01", ticket] toDevice: deviceId];
    [readerManager sendApdu:@"FF D6 00 06 04 FE 00 00 00" toDevice: deviceId];
}

- (void)clearData:(NSString *)deviceId {
    [readerManager sendApdu:@"FF D6 00 04 04 00 00 00 00" toDevice: deviceId];
    [readerManager sendApdu:@"FF D6 00 05 04 00 00 00 00" toDevice: deviceId];
    [readerManager sendApdu:@"FF D6 00 06 04 00 00 00 00" toDevice: deviceId];
}

[RichardKeymaster]

Hey Erik, that’s great progress indeed! Based on your set of 3 APDUs you’re writing the following to data blocks 4, 5, and 6:

Block 4: 03 06 D1 01 
Block 5: 01 54 00 01        // I set your %@ to 00 for analysis sake
Block 6: FE 00 00 00

Following the NDEF specification, a message starts with at the very least with a byte with most significant bit (MSB) set. In your case this would be D1.

D1 = 1 1 0 1 0 0 0 1 : (MB=1, ME=1, SR=1, TNF=1)

You have one record given your Message Begin (MB) and Message End (ME) bits are set, you’re using Short Record (SR) notation, and your Type Name Format (TNF) is Well Known Type. Given your choice of Well Known Type, you’ll need to choose from the Record Type Definitions (RTD) for your NDEF message. The length of the RTD name you’ve chosen is 01 and the length of the payload in your NDEF record is 01.

The 54 represents the ASCII representation of your chosen RTD or “T” for Text type. Per the Text RTD specification you are required to indicate the language code length and setting. This is often 02 and 65 6E (en for English). Because the English language code uses ASCII (UTF-8) as the encoding method, you would need to convert your Ticket Number to ASCII before writing it to the APDU. So for instance Ticket #00 would be 30 in hexadecimal. So your writeUsedTicket function should be:

- (void)writeUsedTicket:(NSString *)ticket toDevice:(NSString *)deviceId {
    [readerManager sendApdu:@"FF D6 00 04 04 03 06 D1 01" toDevice: deviceId];
    [readerManager sendApdu:@"FF D6 00 05 04 01 54 02 65" toDevice: deviceId];
    [readerManager sendApdu:[NSString stringWithFormat:@"FF D6 00 06 04 6E %c FE 00",[ticket characterAtIndex:0] toDevice: deviceId];
}

Note the %c (limits to one character) instead of %s (which could be a string stream). Also the charaterAtIndex: method works on NSString to change your Ticket number to an ASCII encoded value. Now after writing to a tag you should be able to confirm the right Ticket number is read using an Android NFC device.

Hope that helps,
Richard

[ErikParticipant]

Thanks a lot!

I got the writing working pretty good now.

Only thing I miss is being able to handle the apdu-responses. For instance check if i get a 63 00 or a 90 00. I can trigger “didFindADataBlockWithNdef” with [readerManager sendApdu:@”FF B0 00 04 10″ toDevice:deviceId]; and “didFindATagUuid” with [readerManager sendApdu:@”FF CA 00 00 00″ toDevice: deviceId];… But when I write or when the read is disturbed I get no callback. I see the responses in the console but “didRespondToApduCommand” or “didReceiveReaderError” doesnt seem to trigger.

How should i handle this? I use the 2.1 Pro SDK and currently on the 1.16.00. Is this something that is going to work better with the 1.16.03 firmware aswell?

[RichardKeymaster]

Hi Erik, this could be related to your dated firmware. You can update your firmware to the latest FWV 1.16.03 by following this guide. Then retry your test and let me know if still failing.

thanks,
Richard

[ErikParticipant]

I just get “warning: Not find any reader!” in the Firmware Update Tool V1.05. Up until everything has worked according to the manual.

[ErikParticipant]

Ive tried on two different computers with Windows 9 and Windows 10

[RichardKeymaster]

Ugghh, sorry for not being clear about that. The tools only work with Windows 7 or XP. Can you find one of those machines somewhere? The process shouldn’t take more than 10mins so borrowing a machine is feasible.

[ErikParticipant]

Didnt see that coming! Should be lots those lying around… 🙂

[ErikParticipant]

I found an old Windows 7 computer, started flashing the firmware, then in the middle of the progress the old piece of garbage died and now the ACR is stuck in limbo.

Both leds are lit up and its beeping while trying to connect it, so I guess I lost this fight. =)

[RichardKeymaster]

How bizarre. With another Windows 7 or XP machine you should be able to repair. Do you have another machine you can try with?

[ErikParticipant]

I got it working again. It work very well to flash the firmware with Virtual Box and Windows 7 from a Mac! Good to know!

[RichardKeymaster]

Good tip. I updated the firmware upgrade instructions to reflect that.

Now that you have updated firmware, are you getting all you APDU responses? Let us know if you are still encountering issues with that so we can further root cause it.

best,
Richard

[ErikParticipant]

I get the 63 00 APDUs with the new firmware. But not the 90 00. Maybe thats how its supposed to be?

[RichardKeymaster]

63 00 response is a common APDU command error and likely has to do with improperly formatted APDU command. What APDU are you sending that is causing this response? Would be helpful for you to copy/paste your console output for me to review. You should get 90 00 if the APDU command was executed successfully by the target NFC card.

[ErikParticipant]

I use the 63 00 to handle unsuccessful writing. Often happens when juggling around the tag while trying to write.

Never get any 90 00 to the callback function. Maybe a can try your latest beta SDK?

[RichardKeymaster]

Sure, you can download from here. You should definitely get 90 00 at the end of response APDUs if they were executed correctly.

[Author]

Posts