FloJack BZR not supported with FlomioSDK 1.9

[AmitParticipant]

Hello

I’m facing an issue with the FloJack BZR devices I recently purchased not being able to read tags using the FlomioSDK 1.9. I talked with Richard on this and we were able to confirm that the issue wasn’t with the devices themselves, but likely with the version of the FlomioSDK I was using – given that the FlomioTest TestFlight app worked and was able to scan a tag right away. The TestFlight app referenced build version of 1.9(24) which is not the one I’m using. This site references a dropbox link to SDK 1.9 (17).

Based on Richard’s assessment – this is likely the cause of the issue. So, please can I get the latest updated SDK that supports the FloJack BZR devices?

Thanks
Amit

[JacobParticipant]

I am experiencing the same issue. Our ACR35 works fine, but the BZR’s that we just purchased are not connecting with the SDK.

The outputs show that it finds a reader, but keeps saying the app is not connected, and also that’s in active.

Is a new SDK required?

console.log from Xcode
=====
2016-03-29 20:05:31.716 Flomio[4126:1482720] Init FloJack
2016-03-29 20:05:32.125 Flomio[4126:1482720] Updated settings for reader 0x15ed65250
2016-03-29 20:05:32.128 Flomio[4126:1482754] Created reader 0x15ed65250
2016-03-29 20:05:32.130 Flomio[4126:1482720] App Activated
2016-03-29 20:05:32.130 Flomio[4126:1482720] Found existing reader 0x15ed65250
2016-03-29 20:05:37.005 Flomio[4126:1482720] connected: 0
2016-03-29 20:05:38.668 Flomio[4126:1482754] Found existing reader 0x15ed65250
HeadsetInOut
2016-03-29 20:05:39.673 Flomio[4126:1482720] app inactive
=====

[JacobParticipant]

Just wanted to confirm that the READ ME on the SDK i am using also specifies
**Stable tag**: 1.9 (17)

Need new SDK asap. We have 4 BZR readers and none of them are working

[ScottKeymaster]

Hi Amit and Jacob,

Sorry for the delay in getting the SDK to you. Here it is with added Flomio BZR (aR530) support: FlomioSDKv1.9(24)

Note: The aR530 required the MediaPlayer.framework, follow the steps in the Readme to add this.

Looking forward to hearing your feedback, and fire any questions at me also. Thanks for your patience.

-Scott

• This reply was modified 8 years, 8 months ago by  Richard. Reason: Scott messed up the Dropbox link, also failed to add in Android files

[AmitParticipant]

Hi Scott

Could you confirm that the dropbox link has been updated with the correct version? Doesn’t seem to work – and I’m noticing that the README still refers to the 1.9(17) version. Also, dropbox mentions it as changed 9 days ago. So something’s out of sync possibly with the upload.

Please confirm.

Thanks
Amit

[RichardKeymaster]

Hi Amit, Scott messed up in the bundling and linking .. I just corrected it. Try it and let us know if that doesn’t get you going.

[JacobParticipant]

@Richard, with this new SDK what would be the right Device for AR35 that we are still using in prod since kFlojack is no longer an option

[JacobParticipant]

Getting Errors in Xcode with Latest SDK

===
“_OBJC_CLASS_$_MPMusicPlayerController”, referenced from:
objc-class-ref in libSDKClasses.a(FTAudioSession.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
====

[AmitParticipant]

Thanks Richard.

Jacob – Add the MediaPlayer framework.

Seems like I need to do some type of registration? Getting the following:
The device is not licensed. https://flomio.com/flojack/#getting_device_id

Thanks
Amit

[RichardKeymaster]

Hey Jacob, sorry for the confusion as we’ve been restructuring our product line lately, including naming as well as pricing. The ACR35 aka FloJack v2 has now been renamed to FloJack MSR (MSR = Mag Stripe Reader). The aR530 aka FloJack BZR (BZR = Buzzer) is our newer more affordable audio jack NFC reader. So as indicated in the README.md file in the SDK bundle you would configure your ReaderManager like so:

   // Set your reader type:
   [sharedManager setDeviceType:kFlojackBZR]; // For FloJack BZR
   [sharedManager setDeviceType:kFlojackMSR]; // For FloJack MSR
   [sharedManager setDeviceType:kFloBleEmv];  // For FloBLE EMV
   [sharedManager setDeviceType:kFloBlePlus]; // For FloBLE Plus

going forward we will be adding several more readers to our line up as well as evolving the Flomio SDK to adapt to their broad functions and features. Stay tuned.

best,
Richard

[RichardKeymaster]

@Amit, uggh… we shipped you our earliest Flomio BZRs so didn’t get a chance to add them to our license server… please launch the Test App I sent you over TestFlight yesterday, choose Flomio BZR, connect the readers you have, scan a tag, and send me the DeviceID listed…

sorry for this cluster$#%^,
Richard

[JacobParticipant]

Richard, I am getting the same error as Amit, my understanding was that by purchasing the BZR directly we wouldn’t have to provide device ids to use the sdk.

do you need the Ids of our readers to get this working?

[AmitParticipant]

Here’s the device id: C16C5DA8010004A2

Thanks
Amit

[RichardKeymaster]

@Jacob, yeah I’ll need your device IDs since I don’t think you’ve upgraded to Pro SDK licenses. If you send me your original order number I can double check that.

If you need the Test app, send me your Apple ID via email to info at flomio dot com and I’ll add you to our TestFlight account for you to get that.

best,
Richard

[RichardKeymaster]

@Amit, your device ID has been added… make sure to clean/rebuild your app in Xcode in order for the web cache to refresh. You can test to make sure your device is registered by going to:

https://developer.flomio.com/api/registered_devices/C16C5DA8010004A2

best,
Richard

[JacobParticipant]

@richard i need the test app to get the ID. my apple id was sent.

• This reply was modified 8 years, 8 months ago by  Richard. Reason: Removed customer email address so he won't get spammed

[JacobParticipant]

@richard

I have 2 BZR and they both have the same device id.

I quit the app in between testing to make sure. seems odd they have the same id

C16C6128010004A8
C16C6128010004A8

[AmitParticipant]

Couple of questions/observations on reading the tag. Firstly it looks like the call on a registered ReaderDelegate is not getting triggered correctly. The method signature called on the delegate is actually : didFindATagFromBZR versus didFindATag.

Getting past that, I’m now stuck on trying to figure out how exactly to read the scanned tag using the SDK. I’ve tried a couple of things, but nothing is giving me back the actual tag in the didFindATagFromBZR call.

FJNFCTag *nfcTag = [[FJNFCTag alloc] initWithUid:tag.data];
NSLog(@”%@”,nfcTag.uid);

NDEFMessage *newMessage = [[NDEFMessage alloc] initWithByteBuffer:tag.data];
for (NDEFRecord* record in newMessage.ndefRecords)
{
NSLog(@”%@”,record);
NSLog(@”Record type %@”,record.type);
NSLog(@”Record payload %@”,record.payload);
}

Also, does the startBlock need to start at 4 or 8? Tried both values, but no luck on either. The card type is a MiFARE 1K.

Appreciate help on this part of the API.

Thanks
Amit

[RichardKeymaster]

@Jacob, I registered the deviceIDs you sent me. You should be able to use the latest drop of the SDK with them now. Let us know if you have issues.

RE: Duplicate deviceIDs, this is definitely something that can appear to be the case if you don’t kill the app and relaunch once the new reader is connected. The reason deviceIDs aren’t refreshed on every scan is because the audio jack readers are inherently slow and querying for deviceID on every scan has a direct impact on user experience so we only check at the beginning of a session. That said, it’s entirely possible that the same deviceID is on two BZRs since this is our first batch with this manufacturer and we are still working out the kinks in quality control. Please check these deviceIDs again and confirm that in fact they are duplicates in order for us to get that feedback to the factory ASAP.

thanks,
Richard

[ScottKeymaster]

@Amit Thank you for pointing out the delegate method issue, that is resolved now and didFindATag now works for the Flomio BZR. FlomioSDKv1.9(25)

Also, regarding reading data blocks. You can manually send apdus to the card via

ReaderManager *sharedManager = [ReaderManager sharedManager];
NSString *apdu = @"00a404000a01020304050607080900"; //example apdu
[sharedManager sendAPDUtoDevice: apdu];

Our NDEF parser is currently not wired up nor tested for the BZR.. that’s something we’re still working on. You’ll have to rely on APDU command sequences of your own for the time being.

Thanks,
Scott

[AmitParticipant]

Thanks Scott. So I don’t mind doing the parsing of the APDU response block, but I need to understand how your API will call back. Currently upon firing an APDU command request, I don’t see much happening besides an nfs_card_open(), nfc_connect, and then sometimes effecting a crash in the code on an NFCTransmit. I’m not sure of the lifecycle that the API is adhering to for FloJack BZR devices. I was expecting to get a callback on the didRespondToAPDUCommand method. But it doesn’t get triggered either.

Thanks
Amit

[JacobParticipant]

@richard, i downloaded the latest files from what you mentioned is build 1.9(25)

https://www.dropbox.com/s/y5qloadwievtjp4/FlomioSDK.zip?dl=1

this still has the delegate error and the read me shows it as 1.9(24)

We are also still waiting on a working version of the PRO SDK to work the BZR readers.

We’ve been going back and forth and still waiting on a valid SDK. We have purchased multiple readers and paid for the PRO SDK to try and speed things up and it’s very frustrating that we keep getting downloads that aren’t working.

[RichardKeymaster]

@jacob, we’re doing everything we can to serve you. We’ve tested the Basic and Pro SDKs internally and they have passed all our tests. Either we don’t understand your issue or the SDK links you’re using are wrong. Can you separate out each issue explicitly for us to address directly? Emailing us won’t speed anything up further since the Forum emails come to our same inboxes.

You can also opt to call us at 9545536227 and we can walk through this over the phone.

Best,
Richard

[JacobParticipant]

1) We paid for the pro SDK and it initially didn’t have support for the BZR. they sent a new build that didn’t include the updated headers, and then later said the pro sdk was fixed, but every time i download it from the only URL i was given, it fails

2) Alternatively i’ve been trying to test on the Basic SDK, but there are runtime errors because of a bad delegate call (this was mentioned in an earlier post on this thread) and a new download link was provided, but it’s still failing for me. Again, i’ve tried downloading after clearing cache and from different browsers. not sure if Amit is still experiencing an issue, but i just tried again and it failed

[AmitParticipant]

Jacob

The delegate does work ( though the README reflects a wrong version ).

My problem now, which looks to be what Scott is working on is on is deciphering the tag. Sending an APDU command doesn’t work either – or I’m doing the wrong sequence of calls. Waiting on Scott’s reply on that.

[ScottKeymaster]

@Jacob My initial idea is that you are using

- (void)ReaderManager:(Reader *)reader readerAlert:(UIImageView *)imageView
if (!reader.delegate)
   reader.delegate = self; 

any mention of the delegate in the method hsa been removed in the latest Readme and would cause a crash.

@Amit When transmitting an apdu, the reader uses the delegate didFindATag for the response data. I will continue working on this today, any additional information you can provide me would be great and provide you with an example as soon as possible!

Thanks,
Scott

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

[JacobParticipant]

I updated the code based on the latest read me.

However, this line:

sharedManager.BZROperationState = kAReadUUID;

has 2 errors. BZROperationState and KAReadUUID are both undefined or not included the latest PRO SDK drop i was given.

Also, by removing the line: `if (!reader.delegate)
reader.delegate = self; `

it never starts polling for tags. I have confirmed that all of my code matches the latest read me included in the pro sdk drop.

[ScottKeymaster]

@Jacob

You are now free to use sharedManager.operationState = kReadUUID for the BZR

[JacobParticipant]

@scott, I have already tried that as well, but the PRO SDK drop never starts polling for tags since I removed the line:

if (!reader.delegate)
reader.delegate = self; 

I have set the delegate as described in the README.

[AmitParticipant]

Hi Scott

Here’s the code sample I have.

//Sets the connected/disconnected image
– (void)ReaderManager:(Reader *)reader readerAlert:(UIImageView *)imageView {

if (!reader.delegate)
reader.delegate = self; // Set reader delagate once it’s clear reader’s connected

…….
}

– (void)didFindATag:(Tag *)tag withOperationState:(ReaderStateType)operationState fromDevice:(NSString *)deviceId withError:(NSError *)error {

NSLog(@”Here %@”,tag);

ReaderManager *sharedManager = [ReaderManager sharedManager];
NSString *apdu = @”00a404000a01020304050607080900″; //example apdu
[sharedManager sendAPDUtoDevice: apdu];
}

– (void)didRespondToAPDUCommand:(NSString *)UUID fromDevice:(NSString *)deviceId {
NSLog(@”%@”, UUID);
}

Is it correct to send the APDU command in the didFindATag callback method? The “didFindATag” method does provide me a the “tag” object that I see has an NSData candidate attached, but I’m not sure as to what I need to do to convert those bytes into a UUID. I tried applying NDEFMessage to the nsdata value, but it returns back zero NDEFRecords.

Hope that clarifies further where I’m stuck at this point.

Thanks
Amit

[ScottKeymaster]

@Jacob, Regarding the zip you emailed me of your project, it worked for me so check some basics for me: make sure your Flomio BZR is sufficiently charged, the volume is up to the max and that you have the latest Xcode version. I also changed the deployment target to 9.0 which is unlikely to make a difference but worth mentioning. I also suggest you test your reader with the Test app to be sure it’s not a hardware issue. Keep me updated with these tests and I will continue to work with you to get this frustrating issue resolved.

@Amit Thanks for your code, I am currently reworking the BZR to make kReadDataBlocks stable but if all you’re looking for is the UUID, you can use
NSString *uuid = [NSString stringWithFormat:@"%@", tag.data]; while in operationState kReadUUID
from within didFindATag to retrieve the uuid. I will update you when kReadDataBlocks is updated and stable.

[ScottKeymaster]

@Jacob, Regarding the zip you emailed me of your project, it worked for me so check some basics for me: make sure your Flomio BZR is sufficiently charged, the volume is up to the max and that you have the latest Xcode version. I also changed the deployment target to 9.0 which is unlikely to make a difference but worth mentioning. I also suggest you test your reader with the Test app to be sure it’s not a hardware issue. Keep me updated with these tests and I will continue to work with you to get this frustrating issue resolved.

@Amit Thanks for your code, I am currently reworking the BZR to make kReadDataBlocks stable but if all you’re looking for is the UUID, you can use
NSString *uuid = [NSString stringWithFormat:@"%@", tag.data]; while in operationState kReadUUID
from within didFindATag to retrieve the uuid. I will update you when kReadDataBlocks is updated and stable.

[JacobParticipant]

@scott I just changed the target to 9.0 and that seemed to make a difference. it’s now polling, but

– (void)didFindATagUUID:(NSString *)UUID fromDevice:(NSString *)deviceId {
is never called.

it just shows the Type Output

2016-04-01 15:14:04.224 Flomio[1683:2393716] Reader 0x134661470 reset, start scan loop, scanSound 1
2016-04-01 15:14:04.224 Flomio[1683:2393716] Ran scan setup timer 0x13457f6a0
2016-04-01 15:14:04.225 Flomio[1683:2393803] timer running on <NSThread: 0x13457f430>{number = 8, name = (null)} thread
2016-04-01 15:14:04.225 Flomio[1683:2393803] Polling for tags
2016-04-01 15:14:05.425 Flomio[1683:2393782] timer running on <NSThread: 0x13460fe10>{number = 12, name = (null)} thread
2016-04-01 15:14:05.426 Flomio[1683:2393782] Polling for tags
2016-04-01 15:14:06.553 Flomio[1683:2393716] Type:Mifare 1K

Secondarily, there a way to disable all the console logs?

[ScottKeymaster]

@Jacob You are currently unable to disable the logs.

To get the UUID you can use

– (void)didFindATag:(Tag *)tag withOperationState:(ReaderStateType)operationState fromDevice:(NSString *)deviceId withError:(NSError *)error {

NSString *uuid = [NSString stringWithFormat:@"%@", tag.data];

}

while in operationState kReadUUID.

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

[JacobParticipant]

i just put this method in my view controller and it’s never hitting that method, though the tags are beeping

[ScottKeymaster]

Working on this now, I have duplicated the problem here and you’re correct. Will be resolved today.

[ScottKeymaster]

@Jacob @Amit

didFindATagUUID callback works for BZR now. Thank you for bringing these issues to our attention and allowing me the time to fix them.

Please note that operationState: kReadDataBlocks is still unstable for the BZR.

Please find new SDK version in Dropbox.
Jacob, you can download your updated Pro SDK from the same link we sent you last.

Thanks,
Scott

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

[JacobParticipant]

Thanks, I am seeing this work properly in the Basic SDK. I just tested the PRO SDK as well and there is missing headers. can you update that?

While this is reading tags now, sometimes the reader beeps, but no tag is actually read.

Is the scanPeriod too short at 500? should it listen for longer periods?

[ScottKeymaster]

@Jacob That’s updated now for you. You’re right, a scanPeriod of around 1200 works best.

[JacobParticipant]

Thanks, updated PRO SDK works and 1200 seems to be working well for scanning.

Is reading and writing data working well or is that something you are still working?

[AmitParticipant]

Hi Scott

Thanks for those updates. However, while the didFindATagUUID method now gets invoked, the UUID string is still a memory location and not the actual value – as in:

UUID __NSCFString * @”<8c4b4a7d>” 0x000000013fd3a5c0

Could you please take a look at this or let me know, what needs to change on my side. I’ve tried changing the startBlock to 8 ( or 4), but that doesn’t make a difference.

Thanks
Amit

[ScottKeymaster]

@Jacob Reading data is currently unstable but is being worked on and writing data will be added after. I will let you know when these are available.

@Amit In that case, it seems <8c4b4a7d> is the UUID of the card. Using didFindATagUUID, you can use the NSString UUID to get this value.

[JacobParticipant]

@scott what is realistic ETA on reading / writing data in the SDK?

[AmitParticipant]

Hi Scott,

I’ve been struggling with an issue with the SDK not reading the tag correctly as it looks like the tag read by the FloJack BZR reader does not NDEF parse the data, but just returns the information as is in a string format.We confirmed this with the card manufacturers.The value provided back by your API is not the actual value. Could you please confirm the issue.

Thanks
Amit

• This reply was modified 8 years, 8 months ago by  Amit.

[ScottKeymaster]

Hi Amit,

Can I ask you for a bit more information on the issue you are facing? Are you using the didFindATagUUID delegate method and if so, is it not providing you the tags UUID?

Reading and writing data is not currently supported for the BZR. We are working the Flojack BZR manufacturer to allow for reading and writing data as there are currently a number of issues with specific cards.

With regards to parsing NDEF, please see this forum post: ndef-parsing-problem/

The problem with NDEF when it comes to the FloJack is that we can only read/write 16 bytes of data per APDU command. You’re right, there’s a need to add a data block enumeration engine to our SDK that will hold a virtual data space of what is read or needs to be written to a tag and then loop through the read/writes to get out or put in the bytes (and validate they were written correctly).

This is currently being worked on, but getting reading and writing working on the BZR is the more immediately priority.

Cheers,
Scott

[AmitParticipant]

Hi Scott

Yes, I’m using the “didFindATagUUID:(NSString *)UUID fromDevice:(NSString *)deviceId” method. However the value returned “<8c4b4a7d>” is not the value of the actual tag on the card. It took a while to validate this, but I had mentioned the same earlier in my prior comm in this thread ( April 4, 2016 at 6:33 pm ).

Appreciate your help on this.

Thanks
Amit

[RichardKeymaster]

Amit, how are you reading the UUID off the card to know that isn’t matching what’s reported by the SDK? You indicated above that you’re using a MiFare Classic 1K tag which would match the 4 byte UUID reported (Classics have 4 byte UUIDs, Ultralights and NTAGs have 7 byte UUIDs). Are you still using the same tag type in your testing? Note that the SDK only supports reading NFC Type 2 tags at the moment which could be part of the problem. We have done extensive testing with MiFare Classic tags and the BZR is reporting UUIDs correctly from our side.

[ScottKeymaster]

Also, please redownload the SDK and try again as there has been a patch since April 4th which could resolve the issue.

[AmitParticipant]

We’re getting the cards from an authorized vendor. We have other NFC readers – just that your reader may be a better fit. The cards themselves are “NXP Mifare Classic 1K” compliant. I downloaded and tried again with the latest SDK out there and I still get the following value for the tag – <fc354d7d>.

That value is an actual number and not what looks to be a hex value. I tried converting the value to decimal but that does not give me the number either.

Thanks
Amit

[ScottKeymaster]

Hi Amit,

That seems to be operating as expected. fc354d7d seems to be the correct 4 byte hexadecimal UUID value that would be on your tag. The NFC Forum specification defines Tag UUID as a 4 byte, 7 byte, or 10 byte hexadecimal number. UUIDs are most often expressed in hex and so I believe the issue may be that you are looking for a piece of data that is not the UUID.

We have extensively tested NXP Mifare Classic 1K tags and they are returning the UUID. In order for us to best support your needs it would help to have a sampling of the cards you are using.

Scott

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

[Author]

Posts