Fixed
Status Update
Comments
se...@google.com <se...@google.com>
se...@google.com <se...@google.com>
ap...@google.com <ap...@google.com> #2
Hi Xiangjun, do you know what is going on here?
se...@google.com <se...@google.com> #3
Make sure they use the same session ID/VendorID/STATIC STS IV/address on both sides.
de...@dyson.com <de...@dyson.com> #5
As far as we can tell, we are setting the same values, as Estimote / Qorvo don't actually publish any useful information on how to actually use their UWB beacons / DWM3000EVB running in Nearby mode.
The Bluetooth incoming data is in this format:
// 0x01, 0x01, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Fixed data
// 0x13, // configLen - 15
// 0x01, 0x00, 0x00, 0x00, 0x3f, 0xf5, 0x03, 0x00, 0xb8, // Fixed data
// 0x0b, 0x00, // Preamble - 25
// 0x00, 0x01, 0x09, // Fixed Data
// 0x09, 0x00, // Channel - 30
// 0x01,
// 0x7c, 0xd2, // Dest Addr - 33
So we get the Preamble / Channel / Dest Addr from the Bluetooth data.
The outgoing Bluetooth packet data is in this format:
// Android timings
val packetPayload = byteArrayOf(
0x01, 0x00, 0x00, 0x00, 0x17, 0x45, 0x55, // Fixed data
0x11.toByte(), 0x22.toByte(), 0x00, 0x00, // SessionID - 7
0x0b, // preamble - 11
0x09, // channel - 12
0x06, 0x00, // num slots - 13
0x60, 0x09, // slot duration - 15
0xf0.toByte(), 0x00, // block duration - 17
0x03, Fixed Data
0x11.toByte(), 0x22.toByte(), 0x33.toByte(), 0x44.toByte(), 0x55.toByte(), 0x66.toByte(), // STS IV - 20
0x46, 0x59.toByte(), // SRC_ADDR - 26
)
So we return the session ID and STS IV, although Android also needs the vendor Id which is set to 0x004c.
UWB seems to be the king of proprietary data with no documentation on anything... perhaps if you pay $5000/year to FiRA you get something, but as an application developer just wanting to use UWB ranging this shouldn't be necessary!
The Bluetooth incoming data is in this format:
// 0x01, 0x01, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Fixed data
// 0x13, // configLen - 15
// 0x01, 0x00, 0x00, 0x00, 0x3f, 0xf5, 0x03, 0x00, 0xb8, // Fixed data
// 0x0b, 0x00, // Preamble - 25
// 0x00, 0x01, 0x09, // Fixed Data
// 0x09, 0x00, // Channel - 30
// 0x01,
// 0x7c, 0xd2, // Dest Addr - 33
So we get the Preamble / Channel / Dest Addr from the Bluetooth data.
The outgoing Bluetooth packet data is in this format:
// Android timings
val packetPayload = byteArrayOf(
0x01, 0x00, 0x00, 0x00, 0x17, 0x45, 0x55, // Fixed data
0x11.toByte(), 0x22.toByte(), 0x00, 0x00, // SessionID - 7
0x0b, // preamble - 11
0x09, // channel - 12
0x06, 0x00, // num slots - 13
0x60, 0x09, // slot duration - 15
0xf0.toByte(), 0x00, // block duration - 17
0x03, Fixed Data
0x11.toByte(), 0x22.toByte(), 0x33.toByte(), 0x44.toByte(), 0x55.toByte(), 0x66.toByte(), // STS IV - 20
0x46, 0x59.toByte(), // SRC_ADDR - 26
)
So we return the session ID and STS IV, although Android also needs the vendor Id which is set to 0x004c.
UWB seems to be the king of proprietary data with no documentation on anything... perhaps if you pay $5000/year to FiRA you get something, but as an application developer just wanting to use UWB ranging this shouldn't be necessary!
Description
Jetpack Compose component used: ModalBottomSheet
Reproduction code
```
CompositionLocalProvider(
LocalLayoutDirection provides LayoutDirection.Rtl
) {
// other screen content
if (openBottomSheet) {
ModalBottomSheet(params...) { // sheet content }
}
}
```
The content within the bottom sheet continues to be LTR while the content outside the sheet is RTL. Also applies to LocalDensity changing the font scale