in Bluetooth, I am going to send a big file which divides into 3 packets (p1, p2, p3). Each packet has the max ATT payloads.
My question is that in one connection interval, there would be a Master-slave request and then the slave would send all the packets of the file one after each other with Interframe Space (IFS) between every two packets (M -> S, IFPS, S->M(p1), IFPS, S->M(p2), IFPS, S->M(p3))?
or there it is like (M -> S, IFPS, S->M(p1), IFPS, M -> S, IFPS, S->M(p2), IFPS,M -> S, IFPS, S->M(p3), IFPS)?
In Bluetooth Low Energy, every packet in a connection is acknowledged. This is mentioned in the Bluetooth Specification, v5.2, Vol 1, Part A, Section 3.1.3.2 (LE reliability):
Like BR/EDR, in poor RF environments, the LE system should be
considered inherently unreliable. To counteract this, the system
provides levels of protection at each layer. The LL packet uses a
24-bit cyclic redundancy error check (CRC) to cover the contents of
the packet payload. If the CRC verification fails on the packet
payload, the packet is not acknowledged by the receiver and the packet
gets retransmitted by the sender.
So if the choice is between one of the two examples you provided, the more accurate one would be:-
(M -> S, IFPS, S->M(p1), IFPS, M -> S, IFPS, S->M(p2), IFPS,M -> S, IFPS, S->M(p3), IFPS)
However, it's not as clear cut as this because most of this happens under the hood in the baseband layer and there are other things to consider (e.g. number of packets per connection interval). If you haven't seen them already, have a look at the following links to get a better picture of how throughput is measured in BLE:-
A practical guide to BLE throughput
Maximising BLE throughput on iOS and Android
Maximising BLE throughput: Everything you need to know
Bluetooth 5 speed: How to achieve maximum throughput
Evaluating BLE for time-critical industrial IoT applications
Related
I observe wifi station TX bandwidth to be reduced from 160MHz to 80MHz while the station is farther away versus it is closer to AP. I'm using "iw wlan0 station dump" command to check that. AP is forced to 160MHz and it actually use 160MHz for downlink for both cases. But the AX200 station is using 80MHz for uplink after the RSSI is lower than say about -60dBm.
I've checked this with Intel AX200 card. To confirm this is not a card related I also checked Broadcom Xeon 1200 card. Same here. Also a number of different AP was tested. All results are consistent.
Since Intel AX200 uses Intel proprietary Rate Control Algorithm "iwl-mvm-rs" and Broadcom use some other, I know the bandwidth limitation must be introduced by linux itself (mac80211 / cfg80211?). Which part it could be? Can I fix it to 160MHz?
This bandwidth reduction is probably the part of Rate Control Algorithm but the strange thing is that AP downlink bitrate is for example 500Mbits/s (160MHz) while in the same time uplink is 250Mbits/s (80MHz). On the closer locations the bitrate is the same e.g. 1000Mbits/s (160MHz) for both downlink and uplink. Thus this might be some kind of a bug to reduce the bandwidth too early.
Bluetooth 5.1 introduced special direction finding signals, where a constant tone extension (CTE) is appended at the end of a certain packet. The CTE itself consists of only digital ones, so the whole CTE is transmitted on the same frequency and same wavelength, which of course boosts the accuracy of the localization.
I have 2 questions about this process and I cannot find answers in literature or Bluetooth specifications:
Having two connected devices A and B, is it possible to do two-way direction finding in a time-division duplex manner.
Example: let's say we configure the CTE exchange to happen over multiple packets, can we do the following:
1 - A sends CTE to B (B estimates the location of A)
2 - B sends CTE to A (A estimates the location of B)
3 - A sends CTE to B (B estimates the location of A)
4 - B sends CTE to A (A estimates the location of B)
and so on?
Does the devices perform frequency hopping during the CTE exchange?
Example: Instead of sending a single CTE on a single frequency (in step 1 and 3 from the previous question), is it possible that A sends multiple CTEs over multiple frequency (Same for device B in steps 2 and 4)?
Any suggestions/information is welcome.
well technically df could be bidirectional. BUT it requires multiple antennas at all receivers.
the CTE enables phase shift detection at the receiver. it 'knows' what the waveform 'should' look like (constant signal value at a known frequency) so it can sample multiple antennas to detect the differences
but no general purpose devices (phones, computers, laptops) have antenna arrays. that is why AoA is the 'easiest' to implement. add a few specialized receivers, and voila!...
currently the antenna array I have for testing is just under 4 inches square.
I don't know the signal processing limits on miniaturizing such arrays while still having them be effective
I've been working doing some reverse engineering to different BLE based devices and I have a weight scale where I can't find a pattern to find/decode/interpret the weight value that I can get from the android app. I was also able to get the services and characteristics of this device but did not found a SIG standard match with the UUIDs from the bluetooth site.
I'm using an nRF51 dongle to sniffing data packets between the android app and the weight scale and I can look the ble traffic, but there are several events during the communication that I can't really understand what's the relation and I can't be able to convert those values to readable weight in kg or pounds.
My target value is: 71.3kg readed from the weight scale app.
Let me show you what I get from the ble sniffer.
first I see that the master is sending notification/indication requests to the handles 0x0009(notify), 0x000c(indication) and 0x000f(notify) in each characteristic of one service.
Then I start to read notification/indications values mixed with write commands. At the end of the communication, I see some packets that I feel that they are the ones with the weight scale data and BMI.
Packets number 574, 672 and 674 in the image.
So that give us the following candidates:
1st. packet_number_574 = '000002c9070002
2nd. packet_number_672 = '420001000000005ed12059007f02c9011d01f101'
3rd. packet_number_674 = '42018c016b00070237057d001a01bc001d007c'
1st packet during the communication exchange looks more like a counter/RT/clock than a real measurement because of the data behavior, so I feel this one is not a real option.
2nd and 3rd looks more like real candidates, I have split them and convert them to decimal values and I have not found a relation, even combining bytes since this values are floating point data types. So my real question is, Am I missing something that you might see with this information? Do you know if there is a relation between this data packets and my target?
Thank you for taking your time reading me and any help could be good, thanks!
EDIT:
I have a python script that allows me to check the services and their characteristics hierarchy and some useful data like properties, their handles and descriptors.
Service 'fff0' (0000fff0-0000-1000-8000-00805f9b34fb):
Characteristic 'fff1' (0000fff1-0000-1000-8000-00805f9b34fb):
Handle: 8 (8)
Readable: False
Pro+perties: WRITE NOTIFY
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0x9; uuid 00002902-0000-1000-8000-00805f9b34fb)
Characteristic 'fff2' (0000fff2-0000-1000-8000-00805f9b34fb):
Handle: 11 (b)
Readable: False
Properties: WRITE NO RESPONSE INDICATE
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0xc; uuid 00002902-0000-1000-8000-00805f9b34fb)
Characteristic 'fff3' (0000fff3-0000-1000-8000-00805f9b34fb):
Handle: 14 (e)
Readable: False
Properties: NOTIFY
Descriptor: Descriptor <Client Characteristic Configuration> (handle 0xf; uuid 00002902-0000-1000-8000-00805f9b34fb)
This are the characteristics related to the notifications and indications that I see in wireshark. I think the packet number 574 (which characteristics has only a notifiy property) is more important than I think.
I solve it by myself.
This post gives me the idea to take the values (2 bytes) and multiply them by 0.1, that way I could get the weight.
In bytes I could look for my target value without decimals 713, which is in hex = 0x02c9
If we look at the packet number 574:
000002c9070002 and split it 00:00:02:c9:07:00:02
I could see that 2nd and 3rd bytes match with this pattern!
The only thing required to do is to group this bytes and multiply the decimal value 713 x 0.1 = 71.3. I made different tests and found that this pattern is constant so I feel is accurate for my solution. Hope this could help someone in the future.
As far as I unterstand BLE uses two 1-bit fields for applying sequence numbers to packets (SN, NESN). From my (admittedly basic) knowledge about (wireless) communication a 1-bit sequence number is perfectly fine as long as a sender does not continue sending data until the last message is acknowledged by the receiver.
Because of that it is trivial to understand how BLE works with a one-packet-per-interval scheme. However BLE allows multiple packets in a single connection interval. So far I couldn't find any information on how this scenario is handled without allocating more bits for larger sequence numbers.
Any pointers in the right direction on where I'm going wrong or where I can read up on this would be appreciated.
I'm implementing a LIN protocol on a Linux SBC that transmits over a UART. I don't have time to develop a complete LIN stack, so I'm just implementing a frame structure for messages as defined by the protocol. The problem is that the protocol requires a "Break" field which makes the slave devices on the bus listen. This field consists of zeros for 13 bit-times. Any ideas how to send zeros 13 bit-times over UART, when serial data transmission requires complete bytes?
Per Wiki:
LIN (Local Interconnect Network) is a serial network protocol used for
communication between components in vehicles. The need for a cheap
serial network arose as the technologies and the facilities
implemented in the car grew, while the CAN bus was too expensive to
implement for every component in the car. European car manufacturers
started using different serial communication topologies, which led to
compatibility problems.
If you would have paid attention at class you would have known that:
Data is transferred across the bus in fixed form messages of
selectable lengths. The master task transmits a header that consists
of a break signal followed by synchronization and identifier fields.
The slaves respond with a data frame that consists of between 2, 4 and
8 data bytes plus 3 bytes of control information.
You should just send an echo of 0x0000 following by CR/LF.