Description - How I can get the number of BLE connection in iOS.
I want to restrict a user to add more BLE sensor after a particular number of BLE connection. I want to get the number of a BLE connection a device can handle.
A connection represents state, not traffic. The count of connections will be bound by either memory or the data structures used by the Bluetooth stack to manage them, both unknown. My answer is, "As many as it can and no more."
Packets represent traffic and each is handled one at a time. From this perspective, my answer is, "One."
However, if a packet cannot be processed out of the critical paths in the chip and protocol stack fast enough to begin processing the next packet, packets can be dropped. Experience has shown these critical paths in iOS are dependent on the traffic's packet size and rate. Additionally, other devices in the area not connected to your BLE stack may be flooding the radio spectrum and causing packet collisions outside the stack. I have seen BLE traffic go to hell with an excess of 20 connections and as few as one. From this perspective my answer is, "It depends."
Related
When the device is in confirmed mode, it waits for a downlink confirmation (ACK) from the network after each uplink. If the confirmation is not received by the device, it will repeat (up to a maximum of 8 times and increasing the SF of the UL if it was lowered before) the uplink until it receives a confirmation. It may take about 30 seconds to send the 8 repetitions.
If the device does not see a confirmation and needs to send another uplink (e.g. alarm or new periodic measurement), it will send the new uplink and forget the previous one. To operate in confirmed mode, the device must be declared in confirmed mode (or ACK) on the network platform. You can activate it via the IoT configurator in the network parameters
Be aware that this operation consumes much more battery power than a traditional operation, even more, if the network quality is poor.
If the transmitter loses a lot of frames, it would be better to reposition the transmitter (if possible) or the GW (if possible) to improve the transmission rather than activating the ACK which will drain the battery faster than "expected" depending on the network condition.
Is this answer correct or not?
If probe response packets announces the capabilities of a network,
then what is the purpose of Beacon frames in wireless 802.11 ?
Among other things, beacons allow a device to passively scan all channels for available Access Points so that a list may be presented to a user showing signal strength. They also allow a device to detect if there is another Access Point on the same network and presumably on a different channel with a better signal.
Is it possible to send only 1 iBeacon packet? I have tried using CBPeripheralManager,but since there are only 2 method to start and stop advertising, so I can't control how many packet is being broadcast.
What I want to try to do is use an iBeacon packet as a command, instead of just a broadcasting some ID. So I could send 1 iBeacon packet, and if the receiver got the message, it can send back Acknowledgement with another iBeacon packet. The intention is to avoid the pairing of bluetooth to send very simple data. The information will be linked to UUID, major, and minor of the packet.
Or are there better ways to do this than using iBeacon.
Yes, you can use iBeacon technology to send information back and forth between two iOS devices without pairing. If you have two devices, Device A and Device B, you set both of them up to range for beacons with a common ProximityUUID, say, E2C56DB5-DFFB-48D2-B060-D0F5A71096E0. And then you can exchange information in the two byte major and minor fields.
What you can't do is control the transmitter enough to send only a single iBeacon advertisement. The transmitter in iOS sends out 10 advertisement packets per second, so the best you could do is start the transmitter then stop it on a timer about 100ms later. (You probably shouldn't do this, because there is no guarantee that a single iBeacon advertising packet will be received successfully by the other device -- it may be lost due to a CRC error in the radio noise. You are probably better off letting the packet continue to transmit until you can confirm from a response from the other device that it was received.)
You can see an example of starting and stopping a transmitter on a timer in my answer here.
Of course, there may be easier and more robust ways of accomplishing what you want with built-in Bluetooth data exchange mechanisms. But that doesn't change the fact that what you propose is certainly possible.
No you can't since iBeacon is uni-direction device
Apologise for the probably use of the wrong word in my question but for the life of me I can't think of the right one.
Anyway, I've been playing about with the Bluetooth Low Energy and I'm trying to create something that is going to use the RSSI signal strength the BLE device emits. For this, I need it to emit its pulse multiple times per second.
Is there a way I can up the amount of times my devices either scan for a signal, or broadcast their signal through code on iOS devices?
No, there is no API for you to change the advertisement speed or radio power.
This aspect is fully controlled by the system. You can only start and stop the advertisement and add some metadata to the packets: device local name, advertised services, etc. Moreover, the contents of the advertisement packets will differ depending on whether your app is in the background or foreground and, additionally, in background it will be slowed down. These effects have been documented in various SO questions and in the header files.
If your clients are iOS applications, then they should use either the RSSI in the advertisement packets (centralManager:didDiscoverPeripheral:advertisementData:RSSI: method) or when connected, the readRSSI method on the peripheral object (just make sure you don't call it too often).
I'm building a portion of an app that will require the user to download files of varying size. Currently, I'm using Apple's Reachability code to let me know if I have a connection.
(http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html)
While the reachability code can keep track of 'having a connection', it doesn't have an ability to let me know of a worsening connection. It would seem that I need to expand on the functionality of the Apple code to meet my requirement. Is it possible for me to measure the number or percentage of dropped packets during the data transfer? This would be helpful so I could message the user and be able to pause or stop the download.
There is no iOS API available that hooks deep into the networking stack that tells you when and why packets are dropped. It could be dropped at a router or it could be dropped locally because of a checksum error.
What kind of data is it? I assume TCP.
You might be able to infer the quality of the connection by examining the throughput rate. You can count how many bytes you receive per second.
TCP has something called congestion control and the end hosts (iOS devices) will throttle back their throughput as packets are dropped and go unacknowledged. So throughput may correlate with network quality. However, your throughput rate may vary for many reasons such as network congestion, packet shaping, QoS, etc.
iOS does not have a public API to monitor the wifi signal strength. There is a private API but your app would not be approved in the app store if you use the private API.