July 18, 2017 at 1:58 am #60405
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?
P.S. I’m not entirely sure but could it be related to the FloBLE being continuously connected (to power or to the app)?
July 19, 2017 at 10:26 pm #60418
- This topic was modified 4 months ago by Malik. Reason: Formatting
bump?July 25, 2017 at 9:46 am #60473
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.
RichardJuly 25, 2017 at 9:50 am #60474
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?
July 25, 2017 at 10:09 am #60476
- This reply was modified 3 months, 3 weeks ago by Scott.
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
stopReadermethods 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
startReadersat 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
Your logic is correct and yes, calling
startReadersat 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.
ScottJuly 25, 2017 at 10:14 am #60478
Cheers. I’ll give it a go and post the logs when it happens.July 25, 2017 at 10:15 am #60479
Just an additional question, do I just call
startReadersor call the
stopReadersfirst and then
startReaders?July 25, 2017 at 10:19 am #60480
startReaders. To shed more light on the API for you, the
Connectedstate is connected via bluetooth but NFC polling is off.
Scanningis both connected via BT and NFC polling is on. So
startReaderscontrols the NFC polling when in
kAutoPollingControlconfiguration state. Please let me know if there are any issues for you.
ScottJuly 31, 2017 at 10:11 pm #60542
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.
MikeAugust 1, 2017 at 11:43 am #60545
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.
RichardAugust 1, 2017 at 9:06 pm #60551
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.
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
ConnectedState. The only times that the
didUpdateConnectedDeviceswas called was when the device was restarted (the logs only showed the device going into
Disconnectedstate and then
Scanningstate when the device was restarted)August 2, 2017 at 12:32 am #60554
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.
MikeAugust 2, 2017 at 6:48 am #60557
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??
RichardAugust 28, 2017 at 11:53 pm #60826
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
connectedas 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.
You must be logged in to reply to this topic.