How is data length extension enabled? I have BlueZ on a Raspberry Pi 4B (the peripheral).
I want to maximise my L2CAP channel throughput and hence want to move from a data channel payload of 27 bytes to 251.
Is there a way to do this similar to how one changes the connection interval by editing
/sys/kernel/debug/bluetooth/hci0/conn_min_interval?
There are many articles explaining the concept but not how to actually enable it.
Related
I want to send some sensor data over BLE to multiple nodes.
I thought of changing advertising data at 4Hz. Can it be done?
Yes! It is a common approach to use a BLE beacon packet to advertise sensor data. A few points:
Embedded BLE platforms typically allow advertising at a minimum of 10Hz, and let you change the advertisement between transmissions. I have done this on the Nordic 52x chips, but hopefully STM32 supports it as well.
BLE 4.0 advertising packets are limited to 23 usable data bytes, but you typically need to reserve a few to indicate it is "your" transmission. There are significant further restrictions if you intend to use iOS devices to scan the transmissions. If using Android, Linux, or other embedded system scanners you can use nearly the full 23 bytes.
Keep in mind that anybody in radio range can scan for these advertisements and read the data. Make sure the sensor data are not sensitive enough to warrant a security layer.
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.
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.
I know that the definition of an iBeacon is a fixed specification of the advertising packet that it is transmitting:
9 bytes iBeacon prefix
16 byte UUID
2 bytes Major
2 bytes Minor
1 byte TX power
That being said, is there anything that would prevent a beacon from both sending out advertising iBeacon packets to wake up a phone's app and also transmit actual data content as part of a BLE packet? Would there be a lot of handshaking required in order to send / transmit additional data?
Is there some other way for a beacon to transmit data? One of my large concerns is spoofing of my beacons to falsify the data I am attempting to collect. I was hoping that being able to transmit some data along with an iBeacon packet would allow me to limit the spoofing.
Is something like that even feasible?
A few possibilities:
You can tack on one extra data byte to the end of the iBeacon transmission before it reaches its max advertisement length. This byte cannot be read by iOS devices, though, because Apple blocks reading raw data of iBeacon adverts. It would work on Android/Mac/Linux.
You can interleave a second advertisenent with mostly data fields and line the two up with a common identifier like the minor. The more bytes you allocate to lining up the advertisements, the fewer you have to use for data. You can't use the mac tobline them up, because that is unreadable in iOS for the iBeacon transmission.
You can make the beacon connectable via GATT, and read data fields with GATT attributes. The beacon will stop advertising, though, when connected. This limits throughput and reliability.
All of these options require you to build a custom BLE beacon that does multiple advertisements. It is not a trivial undertaking.
I'm currently building an application that is intended to run on an embedded system hooked up to a cellular data card. I've been made aware of some low-data plans from several carriers, and our application only generates about 5 bytes/second, lending itself to such plans.
However, I can't seem to figure out if the TCP/IP header overhead (about 40 bytes, give or take) is included in the calculation for data usage. Since I need real-time data, I've disabled Nagle's algorithm. This means for each 5 byte burst I send out, I'm sending out a new header. If TCP/IP headers are factored into the data usage pricing, it will dwarf the amount of data I'm sending.
I can't answer definitively, but I would assume they must. Otherwise this could be exploited by adding extra data to the headers. With TCP you send a 40 byte packet and then you receive a 40 byte acknowledgement packet. You could try using UDP instead of TCP so that you don't have to waste data with the acknowledgement packets.
According to an email from Sprint network engineering, "Any data that goes through our network, including network Header [sic.] would be billed or count towards your plan."