FloBLE continuous operation issue

Tagged: charging, connection loss, FloBLE, Sleep

Viewing 17 posts - 1 through 17 (of 17 total)

Author

Posts
July 18, 2017 at 1:58 am #60405
Malik
Participant
Hi Flomies,

I’ve been having this issue with the FloBLE readers where the readers go into some sort of sleep mode and stop registering tags after some time. I raised this issue before and since then, we’ve ruled out the power levels as a suspect among other things. Here is the information at hand:

– There is only one session manager created at the app launch
– Our app connects to the FloBLE device just fine and the two stay connected
– Due to the nature of the app, both the app and the FloBLE need to be connected 24/7 so there is no usage of startReaders()/stopReaders() in the app
– To accomodate for the above mentioned functionality, both the readers and the iPad are always connected to a wall charger
– At an unknown time (sometimes a day or two), the FloBLE stops the blue blinking light and stops registering tags. (We have an icon in the app that is displayed when the reader is connected. The icon still shows the reader as connected but it stops registering tags)
– At this point, the reader needs to be turned off and back on again

We have the application out in the field and we are getting a lot of reports from clients of this behaviour. Could you please look into this issue?

Regards,
Malik

P.S. I’m not entirely sure but could it be related to the FloBLE being continuously connected (to power or to the app)?
- This topic was modified 7 years, 5 months ago by Malik. Reason: Formatting
July 19, 2017 at 10:26 pm #60418

Malik
Participant

bump?

July 25, 2017 at 9:46 am #60473

Richard
Keymaster

Hi Malik, this is something we haven’t encountered but I will ask Scott to try to reproduce on our end. It may take some time since we have some pressing deliverables this month and next but we will be working on it.

best,
Richard

July 25, 2017 at 9:50 am #60474
Scott
Keymaster
Hi Malik,

What SDK version are you using? Have you been able to reproduce this with logs? Is there any delegate methods that gets called when it happens?

Scott
- This reply was modified 7 years, 4 months ago by Scott.
July 25, 2017 at 10:09 am #60476

Malik
Participant

Hey guys,
Thanks for your response. I’m using the latest SDK (v2.2 if I’m not mistaken). I had a theory and wanted to run it past you and see if that could be the case.
As mentioned in my initial post, because of the nature of the app, the NFC reader and the app run 24/7 so the startReader and stopReader methods are never used. I’ve also noticed that a device can be in one of three states namely connected, disconnected, and scanning(the three enum values). As per my understanding, the disconnected state means that the device is disconnected while the scanning state means that the device is paired and waiting for tags to be scanned (which can be seen by logging the device state). However, I have not encountered the device to be in connected state so I don’t know what it means. My theory is that in this case, after an indeterminate time, the device goes into connected state which means that it is still paired (as can be seen by the highlighted bluetooth icon in the status bar) but has stopped actively scanning for tags. Could that be the case?
And if so, would calling startReaders at that point set it back to scanning state?

P.S. I have added analytics to record if or when a device changes state but as luck would have it, the reader has been working fine for now.

July 25, 2017 at 10:12 am #60477

Scott
Keymaster

Your logic is correct and yes, calling startReaders at that point is definitely worth a try and I am hopeful that it would solve your issue.

If you manage to get some logs of the event, please post them here.

Scott

July 25, 2017 at 10:14 am #60478

Malik
Participant

Cheers. I’ll give it a go and post the logs when it happens.

July 25, 2017 at 10:15 am #60479

Malik
Participant

Just an additional question, do I just call startReaders or call the stopReaders first and then startReaders?

July 25, 2017 at 10:19 am #60480

Scott
Keymaster

Just startReaders. To shed more light on the API for you, the Connected state is connected via bluetooth but NFC polling is off. Scanning is both connected via BT and NFC polling is on. So startReaders controls the NFC polling when in kAutoPollingControl configuration state. Please let me know if there are any issues for you.

Scott

July 31, 2017 at 10:11 pm #60542

Michael
Participant

Hey Malik,

Just my 2 cents. Out in the field, from our experience, what we have encountered is that some users tend to not just “tag” the reader. Some users might just leave it on the reader. When that happens the Floble will stop reading tags. I don’t know if that might be your issue but that is something we have come across.

Hope you get your issues resolved soon as we have events that require the Floble to read tags for 72 hours continuous.

Mike

August 1, 2017 at 11:43 am #60545

Richard
Keymaster

Michael, by “leave it on the reader” do you mean that the tag is permanently left on the reader or just for an extended period of time? In other words, if there’s a tag already in the field, then the reader will not read any other tag presented. I assumed that was obvious but perhaps not.

best,
Richard

August 1, 2017 at 9:06 pm #60551

Malik
Participant

Hi Mike,

Thanks for your input. As Richard mentioned, we are aware that the reader can only read one tag at a time. The tags are not being left on for an extended period of time (the users just tap & go). The Readers, however, are connected to to a power supply and connected to the iPAD 24/7 due to the nature of the app. That might be one of the reasons but I’m not quite sure.

@Scott,
This solution didn’t work. It happened again yesterday where the device was shown to be connected to the iPAD but it stopped reading tags and had to be restarted. I checked the logs this morning and at no point did the device go into Connected State. The only times that the didUpdateConnectedDevices was called was when the device was restarted (the logs only showed the device going into Disconnected state and then Scanning state when the device was restarted)

August 2, 2017 at 12:32 am #60554

Michael
Participant

Hey Richard,

The tag is left on there for it to read and complete whatever app function they need to complete. All in all about 10-15 secs but multiply that by hundreds reads per hour. For some reason it just kinda stalls and the blue light doesn’t flash anymore but remains on constantly and we would have to turn the Floble off and on to restore. Yes, ours(Ipad+Reader) was also plugged in 24/7, so figured it might be the same issue but guess not.

Sorry couldn’t have been more helpful Malik.

Mike

August 2, 2017 at 6:48 am #60557

Richard
Keymaster

Interesting, that’s a test case we haven’t really investigated. I will ask @scott to to run through a series of tests involving that scenario. So the steps would be:

1) Launch app
2) Pair with FloBLE Plus plugged into power
3) Place MiFare Ultralight on reader
4) Send APDU sequence for 15secs (any sequence in particular?)
5) Remove tag from reader
6) Repeat steps 3-5 until the FloBLE Plus stalls with solid blue LED condition

would that be an accurate test to reproduce??

best,
Richard

August 28, 2017 at 11:53 pm #60826

Malik
Participant

Hi guys,

As mentioned in my previous posts, I had added google analytics to see if any delegate methods are being called when the reader stops reading tags. I was also noting down the date and time stamps whenever I had to restart the reader because it stopped reading tags. Over the course of past month, the reader had to be restarted multiple times while showing no apparent pattern in date and time stamps.

Just to shed some light on what I’m talking about, here are some of the date and time stamps when the reader had to be restarted.

1st Aug 01:22 PM
2nd Aug 12:56 PM
3rd Aug 01:01 PM
9th Aug 02:56 PM
14th Aug 01:40 PM
15th Aug 12:18 PM
15th Aug 03:51 PM
16th Aug 01:01 PM
21st Aug 08:25 AM
21st Aug 10:06 AM

As you can see, there is no apparent behaviour to when it will happen (at least not one that I can see). Additionally, in all of these instances, the didUpdateConnectedDevices didn’t get called which tells me that the reader is not changing it’s state from scanning to connected as I had theorised before but for some reason stops reading tags if kept connected for long periods of time. Could you please look into that as we are getting numerous reports from the clients of this behaviour.

Regards,
Malik

January 14, 2018 at 3:58 pm #61980

Richard
Keymaster

Hi Malik, I wanted to check up on this issue and see if it’s still causing havoc in your deployments. Please confirm so I can close it out.

best,
Richard

January 14, 2018 at 7:51 pm #61981

Malik
Participant

Hi Richard,

You can close off this thread. Thank you for all your help.
Author

Posts