-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pdu_type incorrect? #2
Comments
I disagree: according to table 2.1, the PDU type is (MSB->) 0010 (<-LSB). According to figure 2.3, the very first bit of the packet should be the LSB of the PDU type, followed by the rest of the bits in ascending order (0100) followed by 0010 (TX random bit set) - so 0x42 is actually correct IMHO. |
I understand. I've tried 0x42, 0x44, and a few others so far, mostly modeled after Dmitry's code, but with a few mods from yours. Nothing has worked with a couple BLE scanners I've tried on my Moto G. I plan to get a CC2540 dongle which supposedly can sniff BLE packets, which should resolve any questions of what is the correct over-the-air format. |
I think that the flaky reception on Android is due to some timing issue, see also #1. However, it seems to be highly random, so some investigation with a proper BTLE sniffer would be highly appreciated. |
Seems to be answered in #3 - de-tuned modules may be the culprit. |
The code sets PDU type to 0x42 == 0b01000010
buffer.pdu_type = 0x42;
The Bluetooth Specification Version 4.0, Volume 6, Part B, Section 2.3 Advertising Channel PDU defines ADV_NONCONN_IND as 0010 and tx addr random as the 7th (counting from 1) bit.
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737
This means the bits on the air (with first bit transmitted on the left) should be:
00100010
Which is 0x22, or 0x44 bit-reversed.
The text was updated successfully, but these errors were encountered: