https://developer.android.com/about/versions/10/features#bluetooth-le-coc
Android 10 has the BLE CoC, and it will enable apps to transfer larger data streams. So What's the max throughput of BLE CoC.
Is it better than BLE with Data Length Extension(DLE)?
CoC has nothing to do with LE Length Extension (it's like asking if WebSockets are faster than IPv6). It is just a more convenient way of sending a stream of data than for example with GATT. You will get more or less the same throughput as with GATT notifications/write without response.
An actually good thing with CoC is that the remote device can decrease the incoming throughput if it is not capable of handling the incoming data in time using the Credit system. With GATT notifications or write without response that is not possible and if you follow the GATT standard strictly packets will be dropped if they can't be handled in time.
Related
Consider the example of a download stream that can be throttled (eg. torrent client, dropbox sync, etc). How does a program apply backpressure to the network?
My thoughts are that, from a software perspective you can choose to read from a socket at a certain speed. But how does the socket you're reading from know that you only want your device to receive data so quickly? Does the actual NIC apply backpressure over the network somehow? If so, by what mechanism?
Backpressure is embedded in TCP/IP protocol. If slow consumer does not read bytes from connection in timely manner, producer is unable to put more bytes than there are buffer memory on sending and receiving sides.
In contrast, UDP messages are not counted and can be dropped if there is no free memory on receiver side to store them.
I have a remote sensor that talks to the world via a low bandwidth TCP connection over GSM. It can often be in a location with extremely patchy GSM connectivity though. At the moment, the remote sensor waits for a GPRS network and then initiates a TCP connection with the server and then listens for commands (which are only a dozen or so bytes every hour or so)
Is an SMS more or less likely to get through to the remote sensor than being able complete a TCP connection? I guess I'm wondering how likely it is that a network signal strength is sufficient for SMS but not for TCP.
Using standard text messaging services for M2M is good idea if you can fit your data in 140 bytes. For short transmissions, opening an GPRS/1xRTT (2G) IP session, transmitting the data to a server and closing the session is less efficient and more likely to go wrong than sending an SMS.
As a side note, you can also use SMS (MT-SMS) to bring IoT device online (mechanism called "Shoulder-Taps" ).
Compared to data (or voice), SMS use only the signaling part of the mobile network. It's a quite cheap operation in terms of network resources reservation so you'll more likely get through with an SMS than with a data connection in a weak signal environment. One additional advantage is much lower power consumption of your terminal which might be important for M2M context.
As stated by #Jarek previously, you need to be able to pack your data into 140 bytes or to forge "long" SMSes which are kind of concatenation of "simple" 140-bytes SMSes
Is there a maximum in specifications,do they start to interfer if many try to connect at the same time?
what are the modes of communication is there a secured mode or something else ?
Maximum packet size ?
can I send an image or a sound using ble ?
There is no limit in the specification. In reality at least around a millisecond must be allocated to serve each connection event. So if you use a 7.5 ms connection interval you could not expect more than at maximum 10 connections without getting dropped packets (and therefore larger latency). Connection setup/scanning will also miss a large amount of packets if the radio is busy handling current connections.
The maximum packet length is 31 bytes for advertisements (up to Bluetooth 4.2). While connected the longest packet length is 27 bytes. Bluetooth 4.2 defines a packet length extension allowing larger packets but far from all implementations support that.
The security that BLE offers is the bonding procedure. After bonding the devices have established a shared secret key which is then used to encrypt and sign all data being sent.
Sending normal-sized images or sounds will take several seconds since the throughput is quite low.
I think you should really read the Bluetooth specification or some summary to get the answer to your questions.
Say I have a BLE device that is both a server(has info) and a peripheral(needs to access outside info), that upon receiving or generating it's own data has to share with other Server/Peripherals in it's vicinity.
Would it be beneficial that I only attempt to connect to the devices through BLE when their is data to be transfered "even though it periodically connects to each server sequentially to see if it can" or would it be better to keep connections simultaneously use callbacks to determine when connected and simply transfer data when required to(through from what i understand the devices that I use can only process on gatt operation at a time meaning having 4 connections to quickly transfer data is irrelevant).
In other words is it beneficial to continually reconnect and disconnect a peripheral and server or simply have a connection to as many servers as I need(even though apparently I can only perform one gatt operation at a time i.e 1 characteristic read/wright).
balanced requirements.
If possible, instead of reading to see if there's data available, I would stay in connection with the devices and have them use Bluetooth notifications to communicate data when it becomes available.
Alternatively you could consider having the Peripherals advertise only when they have data to invite the Central mode device to connect. It would need to be periodically scanning to detect this however.
Advantages/disadvantages depend on your priorities and the nature of the two types of device.
FYI you're mixing terminology a little btw. When discovering devices you have a GAP Peripheral which advertises and a GAP Central which scans. After the Central connects to the Peripheral connect you have a GATT Client and a GATT Server. Usually the GAP Peripheral becomes the GATT Server but it does not need to be this way. The GAP Peripheral can just as easily become the GATT Client. It's the GATT Server that has the state data in an attribute table in the form of Services, Characteristics and Descriptors.
What exactly is a BLE scan response packet?
Since there is almost nothing to be found online, we would like to now this.
Does a scan response packet, respond on a device scan or is it like the advertisement packet sent every x seconds?
A BLE scan response is the packet that is sent by the advertising device (peripheral) upon the reception of scanning requests (i.e. yes, it is a response to a device scan). The scan response usually has more data than the advertising packets. In other words, central devices send scan requests to the advertising device in order to get additional user data through the scan response. Please also note that scan responses are considered to have fixed 'static' data relative to the more dynamic advertising data.
Advertising packets and scan response share the same format, and are transmitted over the same three physical channels (they are both sent as advertising events), but are otherwise two different things.
For more information, I recommend reading about scan response packets in the SIG's core specification found here.
I hope this helps
An important addition to yousif saeed's answer:
According to the Bluetooth 4.x specification, Peripheral devices accepting Scan Requests,
Must advertise this by using a specific Advertising Type value in the protocol header.
Must use advertising intervals of equal or bigger than, at least, 100 ms, so that the Central/Peripheral devices can exchange the Scan Request/Response packets in the time between two consecutive advertising packets (advertising interval).
Keep in mind, also, that depending on your particular hardware platform and Bluetooth Low Energy software stack,
You may find that a peripheral device accepting Scan Requests is non connectable, that is, may be limited to behave as a pure beacon (connection-less).
I was just looking for this information and it is difficult to find good technical resources beyond the basic description.
There is a great few pages on one of the manufacturer's sites that goes into the details of how their hardware interacts with these communications.
The scan response packet consists of:
Device name,
Transmission power,
Beacon ID,
Firmware version,
Battery level
https://support.kontakt.io/hc/en-gb/articles/201492492-iBeacon-advertising-packet-structure
https://support.kontakt.io/hc/en-gb/articles/201493072-Beacon-services
https://support.kontakt.io/hc/en-gb/articles/201492492-iBeacon-advertising-packet-structure
I am not promoting Kontakt.io, but they did a pretty good job of providing this answer in good detail.
Yes it does depend on device scan.
I recently had this experience.
I was working with Nordic device and started sending advertising packets which included scan rsp data. But either I was getting no scan rsp packet or hardly any packet. The issue was I was not scanning from my other nordic device. Once I started scanning from another device, scan rsp packets started coming quickly.