When bluetooth is on, It blocks Network call with SDK 1.0.8

Proximity
#1

Hi Team,

I am facing an issue with the beacons. If I make the bluetooth on for the beacons, it holds my Web Service calls. And if I make bluetooth off it works perfectly.

Can anyone suggest me the solution?

Thanks in advance.

#2

Hey Nilesh!

First off, could you upgrade to the latest version of the SDK (1.4.1)? If that doesn’t help with the issue, we can work from there.

Cheers!

#3

HI Raphael,

I have upgraded to the version 1.4.1, but I am still facing the issue.
The device what I am using is,

Device : https://www.zebra.com/us/en/support-downloads/mobile-computers/handheld/tc75.html
OS: 5.1.1

Thanks,
Nilesh

#4

Any chance you can check with any other device? Just to figure out if the problem originates with the device/hardware, or with the code/SDK.

#5

Yeah, Already tested with the OS 7 and 8 it works fine, the only problem is in this perticular device, with OS 5.1 ?

#6

Gotcha, thanks for testing & sharing. To be perfectly honest, if this is some problem with the device’s own Bluetooth/networking stack, there might be little we can do. Many (if not most) smartphones out there use a single chip for both WiFi and Bluetooth, and if this is some old/early chip, maybe it just doesn’t cope too well with trying to do both at the same time.

One idea though: you could try configuring your ProximityObserver like that:

ProximityObserver proximityObserver = 
  new ProximityObserverBuilder(getApplicationContext(), cloudCredentials)
    .withLowPowerMode()
    .withTelemetryReportingDisabled()
    .withEstimoteSecureMonitoringDisabled()

LowPowerMode should use less aggressive Bluetooth scanning settings, potentially leaving more resources for WiFi. Disabling Telemetry and Secure Monitoring should also offload the Bluetooth stack a little. (Assuming of course that you’re not using Secure Monitoring, and that you’re okay with no telemetry being reported to Estimote Cloud = e.g. not being notified if your beacons are running low on battery.)

#7

Thank you for the quick response. I need few more suggestions,

I am not using Proximity Observer, Below code is used in my case

beaconManager.connect(new BeaconManager.ServiceReadyCallback() {
            @Override
            public void onServiceReady() {
                beaconManager.startConfigurableDevicesDiscovery();
                for (BeaconRegion region : regionsToMonitor) {
                    beaconManager.startMonitoring(region);
                }
            }
        });

Can you please suggest any solution for this code base?

Thanks,
Nilesh

#8

Ah, my bad, should’ve noticed you’re using the older SDK. Any reason not to use the Proximity SDK? We’re generally not going to be updating/improving the ranging/monitoring APIs in the older SDK, so if it’s not too late for you to switch, we’d recommend that.

If not, then a few questions/ideas for the older SDK:

  • Have you modified the scan intervals, that is, do you call beaconManager.setForegroundScanPeriod / setBackgroundScanPeriod anywhere?

  • What’s the reason you need to do the startConfigurableDevicesDiscovery? This should generally only be used if you want to connect to beacons and configure them. If that’s not the case, then startMonitoring calls should be enough, and removing startConfigurableDevicesDiscovery should lighten up the Bluetooth scanning a bit.

#9

Please provide some verbose level logs from logcat. Most importantly logs showing web service calls stalling.
How you are making web requests? Are using some kind of library (okhttp, apache, etc.)? Are they just failing with timeout or just handing indefinitely?
Why are you starting configurable devices discovery? Are you planning to connect to beacons? If not, this call is not needed here.
Is the code above the only thing necessary to hold web requests?
Is holding web requests limited to a single application? Can you switch to Chrome and open a web page when scanning?

#10

Sure, Let me try with new SDK, Can you pass some example links please.

Yes, I ahve modified the Scan intervals to 2 seconds, I need it in my application, as need to get the details from more than 2000 beacons.

What should be the ideal scan intervals?

#11

Please find my inline comments,

How you are making web requests? Are using some kind of library (okhttp, apache, etc.)? Are they just failing with timeout or just handing indefinitely?

  • I am using Retrofit 2 with OkHttp, Yes It gives me timeout exception, once connected to bluetooth.

Why are you starting configurable devices discovery? Are you planning to connect to beacons? If not, this call is not needed here.

  • Removed
    Is the code above the only thing necessary to hold web requests?
  • Not sure on this, but once connected to bluetooth and if tha pplication is up, then it gives timeout for all the requests,

Is holding web requests limited to a single application? Can you switch to Chrome and open a web page when scanning?

  • Yes tested this scenario, if application is up and bluetooth is on, then it hold all the network requests, the chrome requests as well.
  • But if we dont open the app and if bluetooth is ON then everything works fine.
#12

@heypiotr
No luck with the new sdk, it is the same behaviour.

#13

It looks like it is an issue of that particular phone. There are some phones that have dual WiFi and Bluetooth modem since those technologies shares the same frequency. This can cause WiFi to slow down when bluetooth is scanning. Newer Androids usually have this issue fixed. Looking at the phone specs is highly likely that this is the case.
Try to run scan from this app nrfConnect and see if Chrome is working during scanning. This way we can confirm it is a phone issue. Note: This app stops scan after some time, unless you change it settings to continuous scanning.
For temporary workaround you can try to increase scan wait period:

beaconManager.setBackgroundScanPeriod(2000, 10000);
beaconManager.setForegroundScanPeriod(2000, 10000);

This should stop scanning for 10s and allow web requests to go through.