Hi Mark,

The SDK currently doesn’t support setting the timeout programmatically (currently hard coded). Thanks for bringing this to our attention, I will begin adding this option. We will add several modes of operation to manage power and allow for long timeouts for cases in which the reader is connected to a power source.

In the case of FloBLE devices the API would be
1) connect to BLE and stay connected with NFC field off
2) connect to BLE and stay connected with NFC field on
3) disconnect after tag detect and reconnect when needed only.

Each of these three options has different power draws so will allow you flexibility to maximize use of battery life (option 3) vs. operating in a plugged in powered manner (option 2).

Cheers,
Scott

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

Hey Mark, we don’t expose the Escape Command APDU interface in order to talk to the ACS reader from outside the Flomio SDK so we’d have to add that in anyway. Fastest way to solve your problem is simply provide you with a custom SDK with the Sleep timer disabled. That’s simple enough and not something that should block your development. I understand it’s annoying to have to hit the side button every 180secs during development but you can be confident that this will not be an issue in the field. Scott should have the SDK with the configs he mentioned about very soon as it’s not a lot of code to write. Stand by for that update.

Richard

Hi Malik, if you have FloBLE Plus devices with FWV 1.16.03 and are running Flomio SDK v2.1 or later, you should not be experiencing timeout events. In particular the SDK should be configured with Power Operation set to kAutoPollingControl or kBluetoothConnectionControl:

NSDictionary *configurationDictionary = @{
     @"Scan Sound" : @1,
     @"Scan Period" : @1000,
     @"Reader State" : [NSNumber numberWithInt:kReadUuid], 
     @"Power Operation" : [NSNumber numberWithInt:kAutoPollingControl], //or kBluetoothConnectionControl will work
     @"Allow Multiconnect" : @0,
};

[readerManager setConfiguration: configurationDictionary];

After configuring the SDK in this way the FloBLE Plus should not go to sleep. If this is not the functionality you are observing then let us know.

thanks,
Richard

Hey Malik, I just checked the SDK you’re using and can confirm that it does not have the sleep mode disabled. Please download the latest SDK v2.2 (beta) to pick up this functionality. We hope to get it officially released by the end of the month, so send us any issues you encounter with it.

best,
Richard

Our process is to not pass out one-off SDKs that don’t get merged to mainline. Assuming Scott followed that rule (most likely the case) then the issues resolved with you would have been included in v2.2. Scott is offline for another 4 hours but he can confirm this when he reconnects in case you rather wait. I’ll let him know to checkin on this thread either way.

best,
Richard

Your issue is that you’re reader firmware has not been upgraded to FMV 1.16.03… from your log:

2016-11-16 13:08:15.800 TimeClock[2921:609272] Firmware: FWV 1.16.00

Use this tool in order to upgrade your reader. You’ll need a Windiws 7 or XP machine to go through it.

best,
Richard

As I mentioned, the tool only works with Windows 7 and XP. Yeah it sucks, but what we have to work with.

best,
Richard

I took a snapshot of the Update Tool. Here is the link

Hi Richard,

Thanks for pointing that out. I was able to update the firmware and it started working with SDK 2.2. The sleep timeout is indeed disabled in this one. But now it has a new problem. With the firmware 1.16.03, when I stop the reader with StopReader function and start it again with StartReader function, it takes longer to allow tag reading. I can see in the console that it is sending a bunch of commands as mentioned below

2016-11-17 09:05:37.258 TimeClock[3077:657478] Escape APDU:E0 00 00 20 01 01
2016-11-17 09:05:37.312 TimeClock[3077:656523] EscapeResponse <e1000000 0101>2016-11-17 09:05:37.574 TimeClock[3077:657478] Escape APDU:E0 00 00 48 04
2016-11-17 09:05:37.687 TimeClock[3077:656523] EscapeResponse <e1000000 0104>
2016-11-17 09:05:37.959 TimeClock[3077:657394] Escape APDU:E0 00 00 40 01
2016-11-17 09:05:38.062 TimeClock[3077:656523] EscapeResponse <e1000040 01>
2016-11-17 09:05:38.175 TimeClock[3077:656523] Change Status:Absent
2016-11-17 09:05:38.338 TimeClock[3077:657309] Escape APDU:E0 00 00 48 04
2016-11-17 09:05:38.400 TimeClock[3077:656523] EscapeResponse <e1000000 0104>
2016-11-17 09:05:38.674 TimeClock[3077:657302] Escape APDU:E0 00 00 49 00
2016-11-17 09:05:38.775 TimeClock[3077:656523] EscapeResponse <e1000000 0100>

And sometimes, after StartReader function is called, it doesn’t start the reader. It just sits there. I don’t hear a beep and it doesn’t scan any tags. It still works if I use a device with firmware 1.16.00 and SDK 2.1.
Any ideas???

Hey Malik, I’m convinced that the instability issue is directly related to the Escape APDU behavior that is evident between tag scans in you console log. As a sanity check you can perform the same workflow you described and see if the system works as expected. Either that or create a sample project that you can share with us that exhibits the same issue so that we can diagnose on our end. Basically, the same approach that I discussed on this thread.

thanks,
Richard

Ok great, prepare a simple project showing that behavior and we will troubleshoot for you. Our sample apps don’t behave that way, either we 1.16.00 orr 1.16.03 or across different SDKs.

Standing by for something we can replicate on our side so we can give you the support you need.

Best,
Richard

Hi Malik,
I am testing this now. You should not send the method ‘createReaders()’ more than once. I think this may be the root of your issue. When the device is turned off you should see “Disconnected peripheral ACR1255U-J1-000120” in the log, then when it is turned on, it will reinitialize. Calling createReaders() more than once within the same ViewController causes issues.

To explain the slight lag seen with startReaders() in AutoPollingControl mode:
When stopReader() is sent, the SDK will send an escape command to turn off NFC to save power, it remains connected to bluetooth.
When startReader() is sent, the SDK will send escape commands to turn on NFC.

Can you confirm with me whether you still see issues when createReaders() is only called once within your ViewController?

Kind Regards,
Scott

I understand you were using that to try connect to your reader previously but I would recommend against it. If you do need to retry, i would recommend re-initializing FmSessionManager (your readerManager) rather than calling createReaders() on the same FmSessionManager instance.

Please let me know how you get on. Thank you again for your continued patience on these issues!

Kind Regards,
Scott

Hi Malik,

Here is an updated build of the Flomio SDK v2.2 (beta). It is more stable but it does not change anything regarding connecting to FloBLE Plus readers.
Because it’s a singleton you’ve implemented and because your implementation doesn’t allow for NFCReader to be nil, I don’t recommend using a button to trigger it connecting. I recommend removing the @IBAction ‘btnPressedConnect’ which is used to call ‘tryConnection()’. I recommend completely removing your tryConnection() method along with your custom method ‘createReader()’ from your class NFCReader.

I was wrong to suggest reinitializing FmSessionManager as you’ve implemented it as a singleton. I suggest not connecting it to a button ‘connect’ and just initialize NFC reader with FmSessionManager’s method createReaders() called in the init. This starts searching for Floble Plus devices and will handle connection and disconnection.

Here is the NFCReader class with these changes.

import Foundation

class NFCReader: NSObject, FmSessionManagerDelegate {
    
    let readerManager = FmSessionManager()
    var readerPaired : Bool!
    var UUID : String!
    var connectionTries : Int = 0
    var batteryLevel : Int = 0
    
    class var sharedInstance: NFCReader {
        struct Singleton {
            static let instance = NFCReader()
        }
        return Singleton.instance
    }
    
    override init() {
        super.init()
        readerPaired = false
        /*NFC Reader*/
        readerManager!.selectedDeviceType = .FloBlePlus
        readerManager!.delegate = self
        let configurationDictionary =
            ["Scan Sound" : 1,
            "Scan Period" : 1000,
            "Reader State" : ReaderStateType.ReadUuid.rawValue, //readData for NDEF
            "Power Operation" : PowerOperation.AutoPollingControl.rawValue, //bluetoothConnectionControl low power usage
            "Allow Multiconnect" : false]
        
        readerManager.setConfiguration(configurationDictionary as [NSObject : AnyObject])
        readerManager.createReaders()
        /*NFC Reader*/
        
    }
    
    /*NFC Reader Functions*/
    
    func didFindTagWithUuid(Uuid: String!, fromDevice deviceId: String!, withAtr Atr: String!, withError error: NSError!) {
        self.UUID = Uuid
        NSNotificationCenter.defaultCenter().postNotificationName("FoundTag", object: nil)
    }
    
    func didRespondToApduCommand(response: String!, fromDevice serialNumber: String!, withError error: NSError!) {
    }
    
    func didUpdateConnectedDevices(devices: [AnyObject]!) {
        var connected : FmDevice!
        for dev in devices {
            connected = dev as! FmDevice
            if connected.communicationStatus == .Disconnected {
                readerPaired = false
            } else {
                readerPaired = true
                break
            }
        }
        batteryLevel = Int(connected.batteryLevel)
        NSNotificationCenter.defaultCenter().postNotificationName("DeviceUpdated", object: nil)
    }
    
    func didChangeCardStatus(status: CardStatus, fromDevice device: String!) {
    }
    
    func didReceiveReaderError(error: NSError!) {
    }
    
    func didFindADataBlockWithNdef(ndef: NdefMessage!, fromDevice serialNumber: String!, withError error: NSError!) {
    }
    
    /*NFC Reader Functions*/
}

Kind Regards,
Scott

• This reply was modified 8 years ago by  Scott.

I’ve also tested your solution but the main problem still persists in the SDK v2.2 (the one that you shared). Mentioned below is the chain of events to trigger the issue.

When a tag is scanned, two things happen.
1- The app navigates to another view and stops the reader. It starts the reader again when the app navigates back to the main view.
2- didChangeCardStatus function is called

If the card status is Present when the app navigates to the next view (stop reader is called), going back to the main view (startReader is called) allows the reader to continue scanning the tags and the app works perfectly. If, however, the card status is Absent (removing the card quickly after a scan) when the app navigates to the next view, going back to the main view stops the reader from scanning a tag.

In simple terms, if the card status is Present at the time when the StopReader is called, it works fine. If the card status is Absent, the device stops reading tags. Can you please look into that as it confirms my theory that this has nothing to do with the createReaders being called again as in this experiment, it was only called once when the app initialized.

Hi Scott,
Yes I understand. The issue that I mentioned where the reader won’t read the Tags occured with v2.2 and createReaders being called only once. The edge case where it happens is as follows:
If the card is removed from the reader(ie didChangeCardStatus has a status of Absent) before the stopReader is called, the subsequent startReader call renders the reader unable to scan tags.

Hi Malik,

I have found a temporary workaround for the ‘absent tag: call stopReader’ problem. You will need to implement a slight delay before calling stopReader (I’d also wrap your StartReaders() call in a delay for good measure.)
In your viewWillDisappear method, wrap your stopReader() call using GCD

let delayTime = dispatch_time(DISPATCH_TIME_NOW, Int64(1 * Double(NSEC_PER_SEC)))
            dispatch_after(delayTime, dispatch_get_main_queue()) {
                self.reader.readerManager?.stopReaders()
            }

This will allow all UUID related calls to be settled, and then allow for device configuration to happen. I have no been able to replicate the problem while using a delay, I was able to replicate it without a delay.

Hopefully this helps.
Kind Regards,
Scott

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

Hi Malik, the updated SDK v2.2 is available here. It’s still in beta and continues to be a work in progress but we feel it’s more stable than previous incremental drops. Try it out and let us know if it addresses your issue.

best,
Richard

Nevermind. I got it to work through safari. I’ll keep you posted if I find any issues.

Cheers.

Malik, thanks for the feedback. It would be great if you could provide a review on the FloBLE product page. Feel free to include a link to this Forum thread. It will help customers understand the value we provide besides just selling hardware.

best,
Richard