ATR in FloBLE SDK

[BenjaminParticipant]

Hi Flomies,

I have a FloBLE Plus and use the SDK. I want to detect which tag was recognized. Normally I do this by using the ATR. But I haven’t found the ATR offered through FmSessionManager and FmDevice. The only way I found was to use DidReturnAtr directly from ABTBluetoothReaderDelegate. I could set the Delegate of FmSessionManagers field BtManager, but I thought this would make problems since the WeakDelegate is bound to the FmSessionManager…

I am using Xamarin.iOS and have build my own wrapper library for the official SDK 2.0 and it works. Just not finding a good solution to use the SDK and still get the ATR…

Thanks in advance!

[RichardKeymaster]

Hi Ben, the typical workflow of a “dumb reader” like many that we sell is to return an ATR once a tag is detected and then take a command to query for other pieces of data on the card. This can all be done via the reader drivers published in our public GitHub repos for iOS and Android. Most of our customers don’t want to fuss with this workflow and just want the data off the card (most commonly an id or URL). The Flomio SDK was constructed on top of the published drivers to handle the reader workflow and return more meaningful data easily. The Flomio SDK is very much like the Android native NFC stack in that regard and perhaps what you aim to achieve with your Xamarin.iOS wrapper (which I think is awesome, BTW).

That said, I don’t think it makes sense for us to surface the raw ATR in the Flomio SDK interface but rather details about it that you’re interested in like Tag Type, # of memory blocks, etc. If you tell us what you’re looking to achieve we can add it in as time allows. If you rather work directly with the published drivers, we’d be glad to provide guidance on issues we’ve encountered with integrating with them ourselves.

best,
Richard

[BenjaminParticipant]

Hi Richard,

thanks for your answer. I wanted to get the card name out of it to verify that it is a NTAG215 tag or at least to see that it can be talked to as Mifare Ultralight tag.

What I am looking into right now is to get some of the NfcA commands to work. I had no problems using the APDUs described for the ACR to read the data and so on. But since I also wanted to talk to another device which has own commands accessible through NfcA, this would be the easiest way. I haven’t found a way to send direct commands to the tag though. Is there an APDU for this? On android natively, I used NfcA.transceive for this. I wanted to look more into the ISO Standards for instructions but didn’t find the time yet.

[BenjaminParticipant]

I still have problems to get this working… I just want to get the NfcA command to work. For example the FAST_READ command from http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf page 39. On native android, I used

NfcA.transceive(new byte[] { 0x3A, 0x00, 0x01 });

and received the first two pages as R-APDU. How can I send those commands with FloBLE Plus using the SDK? On my other device (SLC010), I got it working with “T=CL user commands” (http://www.identive-infrastructure.com/pdf/usa/SCL01x.MANUAL.VER2.0.pdf page 42). Has the device a similar command like this “FF FE 00 00 03 3A 00 01” ?

[BenjaminParticipant]

Any news?

[RichardKeymaster]

Hi Benjamin, it took a while to sort out but it helped that you pinged ACS as they prioritized the response to us because of it. As you’re probably aware, the manufacturer of the FloBLE Plus hardware, ACS, doesn’t have the best documentation so we have to wait on their engineers to get answers sometimes. The FloBLE Plus (ACR1255U-J1) driver doesn’t have native support for accessing ISO14443-Layer 3 commands like the FAST_READ command on the NTAG21X tags (pg. 39). That said, the reader driver does support the PCSC v2.0 interface and Part 3 of that spec delineates a protocol by which you can transparently send/receive commands to the target tag without having to interact with any reader middleware in between. This in effect is synonymous to the NfcA.transceive command on Android and the T=CL command option on the SLC010 reader, however it’s a different APDU command structure and (notably) more complex.

Here is a simple example of an PCSC 2.0 Part 3 APDU command sequence that you can send through the Flomio SDK sendApduToDevice(deviceSerialNumber)(apdu) interface:

// Start Transparent Session
<< FF C2 00 00 04 81 00 84 00 
->> C0 03 00 90 00 90 00

// Switch to ISO14443-3 Type A
<< FF C2 00 02 04 8F 02 00 03 
->> C0 03 00 90 00 8F 01 00 90 00

// FAST_READ (e.g. Start Addr: 00h End Addr: 04h) (Timeout value: 00 00 80 00h)
<< FF C2 00 01 0C 5F 46 04 00 80 00 00 95 03 3A 00 04
->> C0 03 00 90 00 92 01 00 96 02 00 00 97 14 04 29 D2 77 7A 97 3C 80 51 48 00 00 E1 10 6D 00 04 00 00 04 90 00

// End Transparent Session
<< FF C2 00 00 02 82 00
->> C0 03 00 90 00 90 00

You can look through the PCSC spec to understand what settings were chosen for each of these command/response pairs. Most confusing is the fact that data objects in Manage Session, Transparent Exchange, and Switch Protocol functions can be bundled into one command. So for instance, in my “Start Transparent Session” command I’m starting the session and turning on the RF field in one command. Also, the Timer data object needs to be used along with the Transparent Exchange Transceive data object in order to allow time between transmit of the FAST_READ command and the receive of the response from the target tag. This is set to 32ms or 0x00008000 (note the endianness swapping in the command).

We will be adding the PCSC 2.0 Part 3 interface into the Flomio SDK API to match the Android stack more closely. I hope the info above helps you in the interim though.

best,
Richard

• This reply was modified 7 years, 9 months ago by  Daniel.

[BenjaminParticipant]

Great anwser, thanks! I’m totally aware that accessing the ISO14443-3 commands is a lot more complex than what a lot of your customers do (NDEF + TagID) and what your SDK is targeting right now. So I really appreciate your help here!

It’s a bit sad that there is no documentation of the transparent session stuff in the official documentation. It only states that it is PCSC compliant, but I thought that may only work when used via USB since the command was missing. I only found it in some of the other ACS devices manuals (ACR1252U) and thought they may have dropped the support on this device. This is why I had pinged them directly a week ago.

I will give it a try and report back. Really looking forward to your implementation in the SDK. Good to know that I can focus completely on the application logic and just workaround the commands right know instead of having to build the PCSC library myself this time 😉

PS: This is the document I found explaining the PCSC stuff (from ACR1252U): http://www.acs.com.hk/download-manual/6402/API-ACR1252U-1.08.pdf (page 15). So if anyone is also interessted in it 🙂 From a first quick glance, it looks to be compatible with what you wrote and seems to be based on the PCSC Workgroup document.

[BenjaminParticipant]

I found some time today and implemented the logic. I can use the transparent session now, but I still have some problems. Sending my custom commands works fine now, but there seems to be a limit on how much it can communicate. I tried various timer settings in the data object, but found no solution. If I only read 2 pages (8 bytes), everything works as expected. If I try to read more pages, I only get 9 bytes or sometimes only 1. This is consistent for all calls for a specific command, so it seems to be deterministic.

Have you experienced something like this? In your example, you got all data for the page range 0-4 (20 bytes). Have you changed any configuration using escape commands? Because I have the same behaviour using the driver directly or using your SDK.

It’s not like the reveiced message would be truncated, because I get a completely valid response with 90 00 as SW1-SW2 status code in the end. Also the data object with tag 97h (reponse data object) is a correct TLV data showing the correct length, but the length is shorter as requested.

When using the read binary block APDU (CLA=FF INS=B0 P1=00), I can request 16 bytes (4 pages) without any problems…

[BenjaminParticipant]

BTW, the device information says:
Model Number: ACR1255U-J1-000231
Firmware Revision: FWV 1.14.01
Hardware Revision: HWV 1.03

Just in case that there was a bug in the firmware…

[RichardKeymaster]

Hey Ben, I suspect it’s a firmware problem since I didn’t send any specific commands beyond the ones I listed in the example. Latest version we ship with is FWV 1.16.03. If you send us your unit with a return label, we can reflash it for you with latest firmware. I could downgrade one of our units to test before doing that but unfortunately we don’t have any NTAG215 tags handy. You can send it to:

Flomio, Inc.
c/o Richard Grundy
7171 Bay Dr. Ste 9
Miami Beach, FL 33141

best,
Richard

[BenjaminParticipant]

I’m from Germany, so sending it two ways should cost a fair amount of money. Is it possible to flash it somehow myself? I will check how much it cost and if it’s possible to include a return label for sending it international with my post office. Depending on the amount would I suggest, that I organize you first some tags from inside the states (online buying, shipping it to you) to check if this is the real cause to not waste a lot of money and time (will take weeks for sending it two ways).

I can also send you the snippet I used so that you can test it directly without having to put too much effort in. It’s based on the BTDemo from flomio_ios, just including some buttons and connecting directly without having to manually select and authenticate every try and change…

[RichardKeymaster]

Understood. We’re under contract with ACS to not share their flashing software as it could undermine their security model so we will have to update your unit internally. It might be cheaper and faster to purchase another unit on our site. Since you’re not really using the Flomio SDK, you can just purchase the ACR1255U-J1 as is. With shipping the cost would be just under $100.

If you send us some NTAG215s we’d gladly run your APDU sequence to check if the issue is still present in the latest firmware. We have an APDU scripting engine in our Test app that makes that pretty simple to do.

best,
Richard

[BenjaminParticipant]

So it would not work to use https://flomio.com/acr1255u-j1-flashtool/ ?

I will check to order you some tags the next days 🙂

[RichardKeymaster]

Yes it would! But can’t share the latest firmware build until ACS “releases” it. 🙁

[BenjaminParticipant]

At least it contains 1.15, maybe this will already help.

[RichardKeymaster]

Good observation, check that and let me know. If it still fails then we’ll need to test on the latest firmware before I can escalate the issue with the ACS engineering team to reproduce the problem and resolve it for you.

[BenjaminParticipant]

The downloader only show’s “>> warning: Not find any reader!” when I click on “Scan”. I changed the driver to Microsoft USBCCID as requested in the manual and followed every step. Is there something I could have missed?

If I just plug it in without the back-button hold, just LED2 is on, so I assume this just means battery loading as in the specification. When I hold the back-button, after the long sound, LED1 is on for around a minute before it switches back to the battery loading pattern (LED1 off, LED2 red on). I assume that this is when it switches back from DFU mode to regular “off” mode. It’s also possible to hold the button down longer for a second beeping sound. According to the registry, the escape command was enabled (EscapeCommandEnable is 1 for the correct VID/PID).

I also checked the PC/SC command SCardListReaders with my own program and it really returns no readers.

[RichardKeymaster]

The firmware flashing tool only works with Windows 7 and XP. If you’re using Windows 8 or 10 you will encounter driver issues like you described. Could that be your issue?

[BenjaminParticipant]

This could be the cause… Tried it using Win10. I will check if I have a Win7 machine around and try it again.

I just ordered you 3 NTAG215s, they should reach you within the next couple of days.

[BenjaminParticipant]

Firmware upgrade worked on Win7 (at least according to the tool). It erased successful and wrote successful. After looking at the device information via BT, it still tells:
Firmware Revision: FWV 1.14.01

Behavior is also the same (as expected since the firmware sayed the same). So it would be great if you could check it with the right firmware and with downgraded firmware after the tags arrive. Thanks again in advance.

[RichardKeymaster]

Ok, let’s wait for us to carry out the test with the NTAG215s … I’ll test with FWV 1.15.00 as well as latest beta 1.16.03. If it works with the officially supported version we can look into why your flash procedure is failing.

[RichardKeymaster]

Hey Ben, I received the NTAG215 tags today. Seems the issue you’re seeing is indeed related to outdated firmware. Below is the APDU sequences I sent to the tag along with results. I confirmed the FAST_READ results match the data found in the tags.

// Start Transparent Session
<< FF C2 00 00 04 81 00 84 00 
->> C0 03 00 90 00 90 00

// Switch to ISO14443-3 Type A
<< FF C2 00 02 04 8F 02 00 03 
->> C0 03 00 90 00 8F 01 00 90 00

// FAST_READ (e.g. Start Addr: 00h End Addr: 04h) (Timeout value: 00 00 80 00h)
FF C2 00 01 0C 5F 46 04 00 80 00 00 95 03 3A 00 04
C0 03 00 90 00 92 01 00 96 02 00 00 97 14 04 BE C2 F0 72 C2 3E 80 0E 48 00 00 E1 10 3E 00 03 00 FE 00 90 00

// FAST_READ (e.g. Start Addr: 04h End Addr: 08h) (Timeout value: 00 00 80 00h)
FF C2 00 01 0C 5F 46 04 00 80 00 00 95 03 3A 04 08
C0 03 00 90 00 92 01 00 96 02 00 00 97 14 03 00 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 00

// End Transparent Session
FF C2 00 00 02 82 00
C0 03 00 90 00 90 00

// Get Tag UUID, verify it matches with the block 00-01 data 
FF CA 00 00 00
04 BE C2 72 C2 3E 80 90 00

The last APDU command was just to get the tag UUID and verify that the first two data blocks returned from the FAST_READ command matched the data. Let me know if you will be sending us your reader to update for you or if you want to simply order some new ones from us.

best,
Richard

[BenjaminParticipant]

I would be really glad if you could also test with FWV 1.14.01 to really confirm it. If you can’t test it with this firmware, I will order a OEM one from within Germany since the shipping from you is $36 and due to the shipping time.

Nonetheless will I still recommend you as the reseller of choice for customers in the US once the project finishes 🙂

But before I buy a new one, I would still like to try to get mine to FWV 1.15 since you said it works for you with this firmware and since this firmware is already public.

[RichardKeymaster]

We only have FWV 1.15.00 beta1 in our repo so I was only able to downgrade to that for the confirmation test. Indeed the FAST_READ results are being truncated. Here’s another APDU sequence with the reader running FWV 1.15.00 beta1:

// Start Transparent Session
FF C2 00 00 04 81 00 84 00 
C0 03 00 90 00 90 00

// Switch to ISO14443-3 Type A
FF C2 00 02 04 8F 02 00 03
C0 03 00 90 00 8F 01 00 90 00

// FAST_READ (e.g. Start Addr: 00h End Addr: 04h) - RESULT TRUNCATED
FF C2 00 01 0C 5F 46 04 00 80 00 00 95 03 3A 00 04
C0 03 00 90 00 92 01 00 96 02 00 00 97 09 04 88 BE BA 72 C2 3E 80 0E 90 00

// FAST_READ (e.g. Start Addr: 04h End Addr: 08h) - RESULT TRUNCATED
FF C2 00 01 0C 5F 46 04 00 80 00 00 95 03 3A 04 08
C0 03 00 90 00 92 01 00 96 02 00 00 97 09 03 00 FE 00 00 00 00 00 00 90 00

// End Transparent Session
FF C2 00 00 02 82 00
C0 03 00 90 00 90 00

// Get Tag UUID, *does not* match the reported block 00-01 data 
FF CA 00 00 00
04 88 BE 72 C2 3E 80 90 00

I also checked the reported firmware version on the downgraded unit and it confirms what you found, the FWV is indeed misreported as 1.14.01. Seems like a flaw in ACS’s release process. I hope that clears things up for you to move forward with confidence. We’re here to help in any case.

Thanks for the willingness to refer customers our way. We’re really pushing for broad NFC adoption and feel closer to it than ever before. Please vocalize your support of our work on Facebook and Twitter as well as post product reviews for what you’ve purchased (click Review tab). It will certainly help keep our momentum going.

best,
Richard

[BenjaminParticipant]

I would appreciate if you could put a bit of pressure on ACS to make the FW update public, especially since this is a bug in the official product and not in your version of it.

This is what I sent them just now:
“With the version 1.14.01 (also declared as 1.15), the results of FAST_READs (and other long commands) are truncated. I was told by Flomio that firmware 1.16.03 fixes the problem, but that you have not made this version public yet. A firmware upgrade would cost $60 if I would have to send it Germany -> USA -> Germany, that is inacceptable. You sell it as device with upgradeable firmware but don’t supply me with the needed firmware to use your product properly. Therefore I request you, to supply me with the hex file to update it using your “ACR1255U-J1 Software Downloader” myself. Otherwise I will look into an RMA, since I still have waranty and without the needed firmware update, your product has to be seen as broken.

You can see the communication with Flomio and the steps they used to reproduce here:
https://flomio.com/forums/topic/atr-in-floble-sdk/#post-56810“

[BenjaminParticipant]

ACS sent me the tool and I’m on FWV1.16.03 now 🙂 Everything seems to work now! Thanks again for your great support.

[RichardKeymaster]

Glad you got it working and are running latest firmware now. Let us know once you get your Xamarin integration released so we can promote it on our site.

best,
Richard

[BenjaminParticipant]

The iOS wrapper is already fully working (current PoC of Amiibo Manager, https://youtu.be/X1mVqb0ZU9c) and the Android wrapper will be done by next week once I have finished working on the xamarin forms stuff 😉

I will post again once I have everything up on GitHub.

[Author]

Posts