Home › Forums › Ask the Flomies › ACR35 timing numbers
Tagged: ACR35, FloJack, Performance, Timing
-
AuthorPosts
-
November 18, 2014 at 12:43 pm #28198
Hi all —
We’ve been using the ACR35 quite a bit, and I wanted to throw down some timing numbers so that those curious might get some idea as to the speed of read/write that we have achieved.
Our use case is simple: We need to (1) read a NFCs tag’s ID, then (2) read 16 bytes of data, and (3) finally write back those 16 bytes (slightly modified). We have this down to 1 second, but would love to get it faster.
(1) We start by waking up the reader. We are using the iOS sdk, so we call resetWithCompletion()
In general this takes 2 seconds to respond. This is acceptable to us.
The user is generally slower than 2 seconds in bringing the tag to the reader anyway.
(2) Now we call piccPowerOnWithTimeout() to try and connect with the NFC tag
Really is a shame that the timeout can’t be above 5 seconds. Ideally we would do 30.
We basically have to keep calling piccPowerOnWithTimeout() every 5 seconds.
Time: It takes 0.254 seconds on average to connect once a wristband comes into the field
(3) We then send a read ID command: [0xFF, 0xCA, 0x00, 0x00, 0x00]
Time: It takes 0.195 seconds on average to receive the ID
(4) We then read the 16 bytes: [0xFF, 0xB0, 0x00, 0x06, 0x10]
Time: It takes about 0.252 seconds on average to receive the 16 bytes
(5) We then write back the 16 bytes: [0xFF, 0xD6, 0x00, 0x06, 0x10, [DATA]]
Time: It takes about 0.298 seconds on average to write back those 16 bytesOur total times ends up being 0.999 seconds. Because people actually need to hold their NFC tags at our reader for a second, this is a bit too slow for us still.
We hope that sharing these numbers helps those that may be curious as to the final end-to-end performance numbers you can achieve with the ACR35.
November 18, 2014 at 1:03 pm #28201Thanks Dave. All your measurements look accurate based on our experience. The issue is that the FloJack/ACR35 hardware is half-duplex by design and runs all the state logic on the Host device. This is different from our approach with the FloBLE, where we have the ability to queue up several commands. So for instance, the “read ID” and “read block” commands could collapse into one saving you 200ms. That said, your workflow won’t perform much better on any reader given the requirement of getting the id+block data to the Host before knowing what to write.
My recommendation would be to consider some specific tag features like NTAG203 counters and one-time-programmable data blocks. With the right approach you may be able to eliminate a command and save more on interaction time. You could also run a local centralized datastore amongst your readers and just read tag id’s while processing experiences remotely. This is effective at reducing the 1 second scan time to below 500ms.
Lastly, I would add that POS contactless terminals often take several seconds to complete a scanned transaction. Check out the time it takes for this reported to pay with Apple Pay:
The purpose of the LEDs and sound queues from the reader are meant to help customers keep their credential in the field while it’s being scanned. Although the FloJack/ACR35 doesn’t have a buzzer, it does have controllable LEDs and by way of some clever iOS coding you can get the Host device to play a scan sound as we discuss here:
November 18, 2014 at 1:55 pm #28216Do you have any idea as to why commands (connect / get id / read block / write block) generally take about 0.25 seconds each? Just curious if you have any information as to where the bottleneck is.
I assume (totally guessing here) that it is the audiojack protocol? I see that technologies like hijack [link] have a slow mode of 300 baud (37 bytes a second) — but they can also achieve speeds at 8,820 baud (1,100 bytes a second). The NFC protocol for Mifare Ultralight tends to be in the 100,000 baud (12,500 bytes a second) and the iOS SDK should be pretty darn fast. Perhaps moving away from audiojack would solve the majority of the speed issues?
November 24, 2014 at 3:59 pm #29408Hey David, the 250ms delay for each command is indeed due to the audio jack interface. We leveraged the HiJack project for the design of the original FloJack (v1) and the same is true for FloJack v2 (ACR35) done by Advanced Card Systems. The consensus is that the higher baud rates are not consistent or dependable across all the devices that require support. For instance the audio sampling hardware on an iPad is not the same Android Galaxy tablet. Even across Apple devices the data rates we could achieve varied significantly. This makes for a nightmare of compiler directives and spaghetti code. The lowest common denominator we were able to achieve was 96 bytes a second and hence the latency you’re witnessing.
It was this behavior along with the fact that iOS releases were breaking our FloJack driver that we have moved away from the audio jack and to BLE as an tethering solution. We get much better performance and the benefit of wireless mobility. The BLE interface is not only more dependable than the audio jack, but it’s consistent across all devices. With the FloBLE we’re currently getting over 100kbps (12,500 bytes a second) throughput with an iPodTouch 5th gen (consistently), making it match the Mifare Ultralight read speed. We can even multiplex up to 5 FloBLEs with 20kbps each. This makes the FloBLE much more flexible than the FloJack as well as compatible with PCs and other Smart appliances in the home/car/workplace.
November 26, 2014 at 3:58 am #29724Hi David,
Are you using swift or objective-c on flojack project? I run into some problems with build the acr35 lib in swift, so I wonder if you could help?
Thanks.November 26, 2014 at 3:41 pm #29797Hi Bosko,
Seems like a new thread is deserved for this topic. I will start one up here: https://flomio.com/forums/topic/flojack-v2-acr35-and-swift/
– David
-
AuthorPosts
You must be logged in to reply to this topic.
