Reading and writing with FloBLE Plus

[ErikParticipant]

Hi!

I’ve made a lot of progress with the FloBle and your SDK. I have a few questions though.

1. Reading, when the tag has a NDEF message the reading is superfast, under 100 ms. But when the tag i empty it reads the whole memory (4 APDU commands) which makes it slow, 500-600ms. I only want to read write on the first 16 bytes, can I make the SDK stop after only one APDU command and return an empty NDEF?

2. Writing and delay. The flow is the following: I read the tag and looks for a NDEF message, then do a FF CA 00 00 00 to get the UUID, then I write with 2 APDU commands and lastly I do a FF B0 00 04 10 to read the memory again.
The writing sometimes breaks resulting in a 63 00, but I have the feeling that this happens less often if I put a delay between the last read and the write APDU’s. Right now I’ve set this to 100ms. Should I use such a delay or is this something that i can solve in another way.

3. Writing errors. Sometimes every 10th or 20th read/write or something like that the writing is erroneous time after time (63 00). If i try with another tag, or restart the device or something like that it always works again. It doesn’t seem to happen with the same tags, more like its a hickup with the FloBle.

[RichardKeymaster]

Hi Erik, sounds like great progress indeed. Some thoughts on your points:

1. Right now we have kReadUuid and kReadData as possible tag discovery options. If you choose kReadUuid then tag scans will fire the didFindATagUuid delegate with the tag UUID and ATR returned. If you choose you choose kReadData the didFindTagWithData fires with NDEF parsed data if it finds any, otherwise just raw data. For your case, the later approach is flawed since it forces long read times when no NDEF is found. We are moving to a simpler and more capable approach where we have only one generic delegate didFindTag that returns a generic payload that is either UUID or raw data depending on how tag discovery is set. In the case of kReadData an additional startBlock and blockCount will need to be define as well to better control the tag read times. Our NDEF parser will be moved out of the SDK library and into a Services library we will publish separately. We expect to release these changes in our next release v2.3 sometime next month. If you’re interested we can send you a beta version for you to try.

2. This could be a bug in the hardware, firmware, driver, tag IC or Flomio SDK code. The FloBLE Plus has explicit hardware limits of processing APDUs with 10ms delay between each. We have execution management inside the SDK to assure this requirement is met but it may be failing in your case. To root cause the issue we will need to replicate your sequence at our bench with the same tags you’re using. It’s worth noting that the issue could be completely hardware related since making consecutive APDU calls to an NFC target can deplete it’s internal potential if the reader field power is not enough to support the operation. This is often a problem in APDU intensive security applications. Can you send us details about the NFC tags you’re using and the full sequence of APDUs you’re issuing along with time delays between calls.

3. Similar to #2 this is tough to root cause without reproducing in our lab. It definitely sounds like a bug. If you can capture it on video along with the Console Log output from you app we’d be able to make a lot out of the problem. I understand if it’s a lot to ask for but any details you can send us will allow us to help.

Thanks for posting your issues. I’m confident we can correct them.
Richard

[ErikParticipant]

We are going to use the first version of the app next week, so I don’t think i have time to change to the beta SDK. But it seems interesting! Please send me the beta and I can test it.

1, 2, 3 seems to be closely related, its when I read/write clean memory tags (4 consecutive APDU’s to read) the writing sometimes fail. When the tags already have an NDEF message it almost never fails with a 63 00. I seems like something (hardware, firmware, driver, tag IC or Flomio SDK code =) ) hangs when doing to many consecutive APDU’s. I use Mifare Ultralight EV1.

I’ve done 2 things to work around this.

I do the writing like this:

[readerManager sendApdu:[NSString stringWithFormat:@"FF D6 00 04 08 03 04 D1 01 01 54 %@ FE", [NSString stringWithFormat:@"%02X", tickets]] toDevice: deviceId];

With only 1 write APDU its easier to handle errors and it seems to fail less often. I’ve read somewhere that the FloBle and Mifare Ultralight wouldn’t be able to handle writing 8 bytes in one APDU, but it seems to work well in my case!

When i detect 2x “63 00” i a row i [readerManager createReaders]; to reconnect the FloBle and this seems to solve the issue.

I think I will get the overall solution to an acceptable level, and thanks for all the input. Ill see if I have time to collect some data on the bugs.

[RichardKeymaster]

Hi Erik, thanks for the feedback. It’s concerning that you’re calling [readerManager createReaders]; more than once in your code. This is an initialization routing and is creating another instance of the reader class. Over time this will slow your app since it’s essentially a memory leak. We have another customer that’s made this same build approach and it’s been causing havoc in his solution.

For now we will test the scenario you describe above and see what may be causing the issue inside the SDK. Regarding writing more than 8 bytes, that was a limitation of FloBLE Plus firmware 1.16.00 and below. The units we shipped to you had latest firmware that corrects the 8 byte APDU limit so that’s why you’re not seeing issues with that.

best,
Richard

[ErikParticipant]

I noted the problems with createReaders and ditched that idea :), but really close to a working sollution now. I use a 400 ms delay when writing to a empty memory and no delay when writing to a already written one. Almost no 63 00 now.

[RichardKeymaster]

Hey Erik, since you got this working for your event I’m going to close this thread for now. Let me know if you still having timing issues and we can re-open.

best,
Richard

[Author]

Posts