October 14, 2016 at 3:02 pm #56820
Scott, thanks for getting back to me. After talking to Richard we decided to go with the FloPlus.
The behavior is better, at least getting good error.
Any thoughts on this?
2016-10-14 11:57:24.514813 iCapture PS[1273:1137330] Reader Detected 2016-10-14 11:57:25.164506 iCapture PS[1273:1137330] Peripheral Successfully Attached 2016-10-14 11:57:25.224935 iCapture PS[1273:1137330] didChangeBatteryLevel 50 2016-10-14 11:57:25.285244 iCapture PS[1273:1137330] EscapeResponse <e1000045 008ed16e 915f8aab 0083feb7 9a60150f 6e> 2016-10-14 11:57:25.375673 iCapture PS[1273:1137330] EscapeResponse <e1000046 005787c7 bf50dd83 33bd83b8 c76e2a47 4c> 2016-10-14 11:57:25.375881 iCapture PS[1273:1137330] Peripheral Successfully Authenticated 2016-10-14 11:57:25.435113 iCapture PS[1273:1137330] Fimrware: FWV 1.16.00 2016-10-14 11:57:25.494464 iCapture PS[1273:1137330] Serial Number: RR330-000937 2016-10-14 11:57:25.494598 iCapture PS[1273:1137330] Verfied Pro license 2016-10-14 11:57:25.764966 iCapture PS[1273:1137387] Escape APDU:E0 00 00 40 01 2016-10-14 11:57:25.824341 iCapture PS[1273:1137330] EscapeResponse <e1000040 01> 2016-10-14 11:57:26.004672 iCapture PS[1273:1137330] Change Status:Absent 2016-10-14 11:57:29.335284 iCapture PS[1273:1137330] Change Status:Present 2016-10-14 11:57:29.396156 iCapture PS[1273:1137330] ATR Response: 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 03 00 00 00 00 68 2016-10-14 11:57:29.407826 iCapture PS[1273:1137387] Command APDU:FF B0 00 04 10 2016-10-14 11:57:29.456124 iCapture PS[1273:1137330] Response apdu:03 FF 01 1F 94 0F D3 62 63 61 72 64 2E 6E 65 74 90 00 2016-10-14 11:57:29.456688 iCapture PS[1273:1137330] Transmit Apdu: <ffb00008 10> 2016-10-14 11:57:29.469216 iCapture PS[1273:1137548] Command APDU:FF B0 00 08 10 2016-10-14 11:57:29.516620 iCapture PS[1273:1137330] Response apdu:3A 62 63 61 72 64 31 35 30 30 1E 31 37 34 31 1F 90 00 2016-10-14 11:57:29.517126 iCapture PS[1273:1137330] Transmit Apdu: <ffb0000c 10> 2016-10-14 11:57:29.528771 iCapture PS[1273:1137387] Command APDU:FF B0 00 0C 10 2016-10-14 11:57:29.576478 iCapture PS[1273:1137330] Response apdu:4D 73 2E 1F 4A 6F 1F 41 74 6B 69 6E 73 1F 50 1F 90 00 2016-10-14 11:57:29.577064 iCapture PS[1273:1137330] Transmit Apdu: <ffb00010 10> 2016-10-14 11:57:29.589882 iCapture PS[1273:1137548] Command APDU:FF B0 00 10 10 2016-10-14 11:57:29.635848 iCapture PS[1273:1137330] Response apdu:1F DC D8 F9 52 DD 1F E2 47 F0 A3 21 8A 23 F2 47 90 00 2016-10-14 11:57:29.636602 iCapture PS[1273:1137330] payload length greater than max
Thank you so much!October 14, 2016 at 3:08 pm #56826
Hey Dustin, this may be due to an ATR not in our stack. Can you FedEx some sample BCARDs to us so I can support you better on this issue? I’ll email you our FedEx account number for you to overnight them.
RichardOctober 14, 2016 at 3:45 pm #56834
I appreciate it. The Boise office will get it out today!October 14, 2016 at 3:48 pm #56835
Actually, I am getting a different error message with the type of ITN badge that is normally used.
2016-10-14 12:47:27.633116 iCapture PS[1287:1147301] Change Status:Present 2016-10-14 12:47:27.693172 iCapture PS[1287:1147301] ATR Response: 3B 81 80 01 80 80 2016-10-14 12:47:27.693294 iCapture PS[1287:1147301] Reading Data is not supported with Mifare Desfire 2kOctober 14, 2016 at 5:43 pm #56839
Reading DESfire 2k tags is not a trivial thing. Once we get the BCARDs will be able to assess what needs to be added to the Flomio SDK to support your use case. Thanks for sending samples. Will reach back out on this thread once we get them.
RichardOctober 15, 2016 at 11:26 am #56859
Hi Dustin, we received the sample ITN BCARDs you sent us. I understand the issues you posted about now. The Test card is an NFC Type 2 tag (MiFare Ultralight X) with two NDEF records on it, a Well Known Type (WKT) URL and an External (EXT) type. The Test Badge is an NFC Type 4 tag (MiFare DESFire EV1) and contains two of the same type of NDEF records as well, WKT and EXT.
The first issue is that we don’t support EXT NDEF types at the moment and the extra long 276 byte record stored there is overflowing our NDEF parser and preventing the next record, the WKT URL, from being found. Our NDEF parser shouldn’t fail to catch the WKT URL and that’s a bug that we have logged and will fix. Support for ITN’s BCARD EXT type is a more difficult task that we won’t be able to resolve in the immediate time frame. If this is business critical you can purchase Flomio Service hours and we will prioritize this work. Otherwise, you’re free to use the
sendAPDU()API from the Flomio SDK to read tag data blocks and parse the BCARD EXT type NDEF yourself.
Let me know if you have any questions.
RichardOctober 19, 2016 at 12:55 pm #56962
Left you a voicemail, would like to discuss moving forward with paid support.October 20, 2016 at 4:34 am #56983
Hey Dustin, thanks for the followup. I’ve been traveling at a conference so sorry for missing your call, I’ll be back at work tomorrow after 2pm EST if you’d like to speak then. Purchasing Flomio Service hours is pretty straight forward and really allows us to focus on your needs better. We’ll set up a private Slack channel for the team to engage with you and quickly resolve issues. We are committed to exceed your expectations but if at any point you feel you’re not getting the best value just let me know and we can adjust as needed.
RichardJanuary 26, 2018 at 3:10 pm #62089
You should really fix that bug. I just did a workaround for William from https://flomio.com/forums/topic/flomio-sdk-2/ after I got the Pro SDK wrapped for Xamarin. It’s a show stopper for people not knowing APDUs and NDEF parsing well enough.January 26, 2018 at 7:13 pm #62094
Ben, thanks for the feedback. I will update the issue logged to bring it to our highest priority. You’re right that the NDEF parser shouldn’t fail to get the URL record just because the EXT record is not supported yet. We have a more robust NDEF parser written in JS but have yet to port it over to Native for the Xamarin wrappers to benefit.
RichardFebruary 19, 2018 at 4:27 pm #62353
Just to clarify – is reading ITN cards and badges supported in the iOS SDK? I am not interested in the Xamarin implementation, just need to know if the Flomio SDK can read ITN Bcards or not?February 19, 2018 at 7:16 pm #62359
@Scott, most definitely the ITN Bcards are supported by the iOS SDK but it may require some byte to ASCII conversion. The more robust NDEF parser I mention above is in beta testing now and will support the EXT records needed for Bcards to be easier to interact with. Glad to share that with you if interested.
RichardFebruary 20, 2018 at 9:40 am #62362
Yes I would definitely like to use the beta SDK. I am not able to read the ITN Bcard NDEF records using the SDK – I posted a thread about this:February 21, 2018 at 9:19 am #62369
OK, will follow up on that thread instead.February 21, 2018 at 9:38 am #62370
Thanks Richard, I also purchased additional support to help with getting this up and running, I have an urgent need for this to be up and running in the next couple of days for a tradeshow coming up. How do we engage on this additional support?February 28, 2018 at 10:22 am #62425
Hi Scott, did you receive all the readers and support you ordered?? Please confirm to make sure we haven’t left anything incomplete.
RichardFebruary 28, 2018 at 10:25 am #62426
Hi Richard, Yes everything is complete. The newest version of the SDK supports reading the NFC Type 2 tag for both NDEF records present on the card, for future reference.
You must be logged in to reply to this topic.