Slow or won't read NFC

[JeffParticipant]

We had purchased 25 FloJack BZR for our iPad kiosk app, and after a month of testing with customers scanning using an NFC NDEF formatted badge, the reader takes awhile to read the NFC badge and has overall issues scanning it. I have implemented the SDK just fine, since if I hold the card just right over the scanner it works perfectly, but the complaint is that our customers have to scan multiple times for it to read, or move the card around all over the scanner to get it to scan. Is this normal behavior?

My second question is, is your FloBLE Plus scanner better at scanning NFC badges based on proximity and speed? To compare it to, if I scan the badges with my iPhone’s built in Core NFC, it reads instantly and quickly when the badge comes close to the iPhone, where the FloJack does not, it must remain very close and move the card around the scanner till it can read it. If the FloBLE Plus acts more like the iPhone’s CoreNFC reader on speed, can we have one for testing since we just ordered 25 of the FloJacks?

[ScottKeymaster]

Hi Jeff,

To answer your questions, reading tag data has had mixed performance on the FloJack readers, they are reliable for getting tag Uids, but reading NDEF data can be slower and less responsive than desired especially when payloads are large.
Yes the FloBLE Plus speed is more similar to CoreNFC and is considerably quicker and more reliable than FloJack readers for reading tag data. This is due to the data throughput of the audiojack compared to BLE.

I will have to get back to you regarding a FloBLE plus for testing.

Scott

[ScottKeymaster]

Hi Jeff,

To answer your questions, reading tag data has had mixed performance on the FloJack readers, they are reliable for getting tag Uids, but reading NDEF data can be slower and less responsive than desired especially when payloads are large.
Yes the FloBLE Plus speed is more similar to CoreNFC and is considerably quicker and more reliable than FloJack readers for reading tag data. This is due to the data throughput of the audiojack compared to BLE.

I will have to get back to you regarding a FloBLE plus for testing.

Scott

[JeffParticipant]

ok thank you, if you can, please send us a FloBLE plus for testing! if it works, we will most likely send back the 25 FloJacks and purchase 25 FloBLE from you!

[ScottKeymaster]

Hi Jeff,

What’s the size of the NDEF data you are trying to read?
The FloBLE Plus will perform similar to CoreNFC if the payload is small but for larger payloads, best performance (comparable to CoreNFC) can be achieved with the device plugged in via USB. It is worth testing but I expect you will be happy with the performance if the NDEF data is not very large.

What was your order number so we can locate it? So you’re aware, we have a 30 day return policy.

Scott

[JeffParticipant]

Thank you, here’s our invoice #62854

We are simply reading a GUID from the NDEF, so it shouldn’t be large at all, i’m thinking it’s a string around 16 characters in length. It looks like we are passed the window of the 30 day return policy, is there anyway since we are ordering a large amount we could swap readers out if the FloBLE works?

And could we get one to test with?

[ScottKeymaster]

Just to determine if there is a way that you will be happy with your current BZRs, are you aware that you can read tag UIDs without reading more NDEF data? This would be quicker and more reliable that reading tag data. It seems you have a proprietary GUID that is stored in NDEF format, which would mean you would need to read that, but I would just like to exhaust options to improve your experience with the BZR.
Which version of the SDK are you using?

As for getting a test FloBLE Plus, I can’t promise one to test with yet. Leave it with me for the moment and I will see if this is a large enough batch to justify a sample along with the swapped BZRs.
Note: as you are beyond the 30 return policy, you likely will not be able to return them.

Scott

• This reply was modified 6 years, 4 months ago by  Scott.

[JeffParticipant]

I believe i’m actually only using the readers to read the UID, not the NDEF already. Also we have only used 2 of the readers out of the 25, we started out at 2 locations first for testing. Not quite sure where to find the version, but i believe in the README file it says **Stable tag**: 2.1 (1)

//Initialize the reader in viewDidLoad:
readerManager = [FmSessionManager sharedManager];
readerManager.selectedDeviceType = kFlojackBzr;
readerManager.specificDeviceId = nil;
readerManager.delegate = self;
NSDictionary *configurationDictionary = @{
@”Scan Sound” : @NO,
@”Scan Period” : @1000,
@”Reader State” : [NSNumber numberWithInt:kReadUuid], //kReadData for NDEF
@”Power Operation” : [NSNumber numberWithInt:kAutoPollingControl], //kBluetoothConnectionControl low power usage
@”Transmit Power” : [NSNumber numberWithInt: kHighPower],
@”Allow Multiconnect” : @0, //control whether multiple FloBLE devices can connect
};

[readerManager setConfiguration: configurationDictionary];
[readerManager createReaders];

– (void)didFindTagWithUuid:(NSString *)Uuid fromDevice:(NSString *)deviceId withAtr:(NSString *)Atr withError:(NSError *)error{
NSLog(@”%@”, Uuid);
}

[ScottKeymaster]

Ok, that’s promising as I suspect you will get better performance if you don’t try read NDEF data.
If you continue to use the 2.1, you should use kReadUuid for Reader State.
You should also try updating the SDK to the latest version 3.0. Using Cocoapods, you can test using the sample apps in that linked repo.

Let me know if you run into any issues.
Scott

[JeffParticipant]

ok, so i’m already using kReadUuid, I believe i also had tried the 3.0 SDK before we launched and had a few other issues with it, so i kept with 2.1 for now. note above the reference to NDEF is commented out //

[ScottKeymaster]

One thing that has me curious, if your tags are not using NDEF data, CoreNFC should not pick them up, is this the case? CoreNFC only works if the tag contains NDEF data and does not return the tag Uid (well in fact, they do return it but it’s a private API the last time I checked).

[ScottKeymaster]

Another thing to attempt is to decrease the “Scan Period”, you may be able to get it to be a bit quicker doing that, but 1000ms is what we settled on recommending.

• This reply was modified 6 years, 4 months ago by  Scott.

[JeffParticipant]

correct, i was future proofing ourselves, we are printing customer badges that simply have a GUID as the ID, that your current readers scan and read just fine. I was hoping iOS 12 (now it looks like I have to wait for iOS 13) to hope that Core NFC would have been opened up on the iPads. In hoping that was the case, I had the badges NDEF formatted with the same ID, so they can be read by an iPhone Core NFC.

[ScottKeymaster]

Hi Jeff,

Unfortunately we cannot offer a free sample for the batch size you’re looking for. Also, because the 30 days return policy window has passed, we unfortunately cannot offer to swap your devices.

Scott

[Author]

Posts