1) It seems like there is already a synchronized clock (part of 802.11 specification) called a "local TSF timer". Is there any way to access it?
Android's ScanResult includes a timestamp described as "Time Synchronization Function (tsf) timestamp in microseconds when this result was last seen." Can this timestamp help me to synchronize?
2) If not, is there any easy way to accurately synchronize clocks between 2 Android devices connected to same WLAN?
3) What about synchronizing between iOS and Android devices?
r
Related
I have read a lot of information regarding the foreground/background scan periods and issues for long scans on Android 7 but I am confused as to what should be configured for best results in the latest alt-beacon library ( 2.15.4 ).
We have implemented a foreground service and bootstrapping and require the library to do the following:
App in Foreground scan for 1100ms, sleep 0 ms
App in Background scan and 1100ms, sleep 10000ms
We are aware that there will be edge cases when beacons are not detected due to start/stop scanning but would prefer this over the potential of the app scanning being killed by the OS due to long running scans.
What setForeground... setBackground... values should be used for the above requirements? OR should we not use these methods and just use the defaults?
Will this cause the "Scanning to frequently" issue and how would we get around this with settings as close as possible to our requirements?
The scan rates you describe will work on most phones by doing this:
beaconManager.setForegroundScanPeriod(1100); // Default, so this line not needed
beaconManager.setForegroundBetweenScanPeriod(0); // Default, so this line not needed
beaconManager.setBackgroundScanPeriod(1100);
beaconManager.setBackgroundBetweenScanPeriod(10000);
BackgroundPowerSaver bps = new BackgroundPowerSaver();
However, on Android 8+, time between scans will be throttled to about ~15 minutes by the operating system. If you cannot accept this, then the only alternative is to instruct the library to use a foreground service. If you do configure a foreground service, then you can get that exact background rate of scanning you want even on Android 8+.
I say this works on "most phones" because big Chinese manufacturers (e.g. Huawei, OnePlus, Xiaomi ) have started forking their Android versions starting in late 2017 to implement aggressive power saving features that block beacon scanning in the background. The proprietary forks either block scanning when the screen is off (Huawei see here and here) (Xiaomi see here) or block foreground services (OnePlus see here). These effectively break Android apps from working properly on their operating system forks.
After spending hours around the web, I cannot find any documentation about the background BLE scanning rules used by IOS.
As it is not possible to set the scan window on IOS, I am looking for the rules defined by Apple when IOS is scanning in background.
Context
I am working on a wearable peripheral which can be disconnected sometimes when it is out of reach with the phone. The goal is to reconnect quickly (less than 5s) when the peripheral is close enough to the phone. The peripheral has battery constraints so I cannot advertise every 20ms forever, so I am looking for a clever way to reconnect my peripheral to the phone.
If I know how the background scanning mode is working, I would be able to define a smart advertising interval in order to save battery.
Use case
If my peripheral advertises every 1285ms, how long does it will take to be discovered by my IOS application in background mode for 10 minutes?
Not sure exactly what your question is.
I suppose you have read Apple's "Bluetooth Accessory Design Guidelines for Apple Products"?
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
In it, they state:
3.5 Advertising Interval
The advertising interval of the accessory should be carefully
considered, because it affects the time to discovery and connect
performance. For a battery-powered accessory, its battery resources
should also be considered.
To be discovered by the Apple product, the accessory should first use
the recommended advertising interval of 20 ms for at least 30 seconds.
If it is not discovered within the initial 30 seconds, Apple
recommends using one of the following longer intervals to increase
chances of discovery by the Apple product:
152.5 ms
211.25 ms
318.75 ms
417.5 ms
546.25 ms
760 ms
852.5 ms
1022.5 ms
1285 ms
Note: Longer advertising intervals usually result in longer discovery and connect times.
Upon discovering the BLE device, iOS will notify apps that are looking for it (based on the advertised service UUID), which will then be able to connect to it.
Apple recommend a 100 ms interval for iBeacons.
This (pretty old, from 2012) discussion states that:
the median discovery time when the phone is in standby is about 60
times the advertising interval. The 95-percentile discovery time when
the phone is in standby mode is about 300 times the advertising
interval
This (slightly more recent, but from Dec 2013) answer states that:
While scanning in the foreground will likely immediately discover a
device advertising next to it, discovery in the background can take up
to ~60 times longer.
There's a problem when (average) advertising interval is near to an integer multiple of the scan interval, then chances are that discovery-time can rise infinitely (, i.e. scanner will never see the advertising, as ADV always occurs outside the scan window).
Probably the ADV-interval list from Apple's design guideline shows optimum values, but it does not tell how to determine discovery-times. That's a mess!
I'd even go further and say: If the Smartphone (Apple or any other) manufacturer does not exactly specify the scan parameters (interval, window, and eventually filter settings) for each power mode, then you're lost and cannot correctly estimate discovery performance.
I know the default connection interval for CoreBluetooth is 30 ms. I've read couple of articles that claim they can reduce it 30 ms > by changing the min and max of the interval. I didn't see any explanation of how they were changing the parameters of it? I am assuming this is all in the iOS end.
Currently I am working on a project where the iOS device is sending packets to the bluetooth le device. When I was writing without response, there were a lot of packets being dropped so I added a handshake so once the bluetooth device receives a packet the iOS sends the next packet. This is currently taking a long time to upload a file since the connection interval is 30 ms which I am trying to reduce.
Any suggestions would be helpful
td;lr How do I change the connection interval on iOS
Solution So after doing research there is no public API that allows iOS devices to request for a connection interval change request. For Android this is possible.
There is no API on iOS for a app as master (using CBCentralManager) to modify the initial Connection Parameters when connecting to a peripheral.
However, the slave can suggest new connection parameters using a L2CAP Connection Parameter Update Request (see Bluetooth 4.0 specification, Volume 3, Part A, Section 4.20), which iOS will accept if they are reasonable (see Bluetooth Accessory Design Guidelines for Apple Products section 3.6 “Connection Parameters”). Peripherals should do this because different operating systems have different default connection parameters that might not be optimal for a particular peripheral. For example, if you rare implementing your peripheral in iOS or OSX, call -[CBPeripheralManager setDesiredConnectionLatency:forCentral:. Or, if you are using the TI BLE stack to program a CC2540 or the like, call the function L2CAP_ConnParamUpdateReq.
I am developing an application on two iOS clients. But both two iOS clients may not able to connect to the Internet, that's make query the same network time difficult. If I send one time stamp to another via wireless or bluebooth or something else, it may have a time delay, like this:
Device A, get the timestamp from the Device A.
Device A send the information to Device B.
Device B mark the timestamp.
Device B receive the timestamp information from Device A.
Device B create a new timestamp, and add back the timestamp different between transferring data.
I am afraid that the create timestamp, and object creation will use some time that cannot be logged. And the application is very time critical. Is there any ways to improve that? Thanks.
I think the right way is
Device A sends information to Device B (without timestamp)
Device B responses to Device A timestamp of reception.
Device A receives the timestamp of data delivery.
In this case both Device A and Device B will receive same timestamp of data sharing.
We need in our project to detect the proximity of an iPhone that is running a custom APP that is using Bluetooth LE.
The detector (Scanner, Central...) will be implemented using a BLE Integrated Circuit (from Texas or Nordic). I mean that the scanner is not another IOS device... running Core Bluetooth as a Central..
For the detector to guess the proximity, the idea is very simple, just advertise a service with an UUID proprietary.
While in foreground all works OK, and the UUID and a Local name are advertised (The UUID in the main advertise packet, and the Local Name in the SCAN Response packet....), and our scanner is able to decide if this iOS device is running our App.
The problem arises when going to background .....
The iOS stops broadcasting UUID and Local Name. (As the documentation of Core Bluetooth Explains... I Know...)
At this moment (Background), IOS begin to broadcast a SPECIAL MANUFACTURER DATA in the main advertise packet, and nothing in the SCAN Response packet)
The data packet we see using a Bluetooth Sniffer is :
0x14 (length of packet not including this byte).
0xFF (Manufacturer specific data AD Type).
And then :
0x4C, 0x00 (this data is the manufacturer identifier, if the packet is compliant with BLE 4.0 specification).
0x01, 0x00,0x00, 0x00, 0x00,0x00,0x80, and ten 0x00 more....
I know Apple says that while in background ONLY ANOTHER IOS DEVICE SEARCHING FOR A SPECIFIC SERVICE CAN DISCOVER IT. (Really I do not know how they can achieve that, unless they connect to the peripheral and retrieve the services, or if the peripheral knows about other IOS device is scanning because of it´s Address in the SCAN REQUEST and then changes the advertisement data in background).
The main questions are :
Is there any documentation or knowledge of what this manufacturer data means....Perhaps it would be possible to the scanner to know based on this info that this is an iOS device advertising in background and then connect to look if the custom service is there. (Not a quick and clean solution...but I do not see any other workaround....)
Does anybody worked with this scenario...and found a clean solution .....
I have heard from people that forces the application not to go to background.
This limitation, will stop a lot of possible projects.