Share My Creation Advertently -The Blah Blah in BLE

see post #7 for update. i've uploaded current version (now at v0.0004) to drive. Advertently

i have no particular interest in bluetooth, except insofar as i like to know if there are any such devices waiting for me when i walk into a room, and if they are talking about me.

although there are a number of standards relating to bluetooth communications, adherance to the standards by manufacturers is often voluntary. in addition, some of the standards themselves defeat the very purpose of communication.

as a result, interest quickly evaporates, at least for me. this is not unlike "reading" nfc credit cards where - for obvious reasons - one can basically derive more information from a credit card by actually looking at it than by "discovering" it with an nfc tag reader. and the use of proprietary information and encrypted data render reading moot in any case.

so it is, i discovered, with bluetooth. so-called ble devices are supposed to broadcast an "advertisement" touting their features. this is supposed to enable interested parties to learn about the device without going through the trouble of connecting to it (only, presumbably, to learn that one has no interest in the device). the problem is: the space allocated to the advertisement by the controlling parties is limited and, as a result, often conveys little or no useful information about the device. in addition, the advertisement may indicate that the device cannot be connected to (why, then, advertise?) or can be connected to even though this is not the case (and you have to wait 20 seconds before finding this out).

devices which indicate that they accept a connection are a little more forthcoming with their personal data, even though a lot of those data are hidden behind so-called uuid's. many of these uuid's are standardized, and many are customized. devices you connect to will tell you about the "services" they offer, their "characteristics", "descriptors" and associated values. some devices readily share these values with you.

i found scanning for devices to be fun. much like wifi "war driving" of 30 years ago when you could park your car on a strange street and borrow a few hours of precious wifi from somebody's open wifi host. from my little atelier, i can see windows laptop computers, neighbors' apple iphones, printers, giant tv's, speakers, washing machines, "nest" doorbells, "nanny cams", and many other devices whose identities are undisclosed in spite of their claiming to advertise their presence.

it is with the above in mind that i present Advertently, a bluetooth scanner and connector. it reads and decodes (where possible) ble device advertisements. it knows what the various uuid's and their bit-shifted cryptic values mean. it can connect to connectable devices and see what they have to say. and there are actually devices - eg, a heart monitor - whose data can be read without a connection, provided you know which characteristic it uses for such output. advertently can help you find that characteristic. technically, it could write to devices, but i would only provoke my neighbors.

assorted screen shots are attached. although advertisements are relatively short, full connection data can be quite long, longer than our ide log permits. i've saved a sample output to a text file, also attached.
 

Attachments

  • 1.png
    1.png
    52.8 KB · Views: 281
  • 2.png
    2.png
    55.2 KB · Views: 101
  • 3.png
    3.png
    50.8 KB · Views: 80
  • 4.png
    4.png
    42.3 KB · Views: 79
  • 5.png
    5.png
    48.8 KB · Views: 77
  • 6.png
    6.png
    39.7 KB · Views: 110
  • json_output.txt
    8.2 KB · Views: 24
Last edited:

drgottjr

Expert
Licensed User
Longtime User
yeah, i think i'll upload it after a little more work. it hasn't crashed so far, and i just learned about "subscribing" to notifications from devices, so i'd like to add that.

due to overwhelming demand, i've uploaded version 0.0002: Advertently 0.0002 this includes subscribing to notifications and indications
it assumes android 12 min. could run on earlier, but there's a whole thing about bt permissions as sdk's advanced. my test devices are 12 and 15; app behaves the same on either. i don't know why it's called "result.apk" that what b4a ide calls it. speaking of which: b4a 13, jkd 19.0.2.
 
Last edited:
Just a small note: While it does detect if location is not on, It doesn't detect if bluetooth is off.
 

drgottjr

Expert
Licensed User
Longtime User
much of the ble advertisement data is either propretary, encrypted or - at best - meaningless without maufacturer's data sheet. however, some of the so-called manufacturer-specific data can at least be identified. for example, apple devices can broadcast data indicating they are in ibeacon format or data relating to its "continuity" and "nearby" protocols. advertently has updated its cache of apple-related data and is ready to share. it may be of interest to have an idea of what a device is doing. the deeper i dig, the more i find non-standard behavior within what are supposed to be bluetooth standards. it makes it difficult to implement a parser based on published standards, only to find a manufacturer that follows its own rules. it was safer - although less informative - to show an unparsed sequence of bytes.

in any case v0.0003 is now available at drive. see post #1
 

drgottjr

Expert
Licensed User
Longtime User
i've uploaded advertently v0.0004 to drive. see post #1. i've added a few "signatures" for devices broadcasting manufacturer-specific data (other than apple's - previously uploaded). these would be for google, ruuvitag and altbeacon. tuuvitag might be the most useful, as it is open source and is used for things like broadcasting the temperature. i don't see any nearby devices broadcasting the new data, so i can't report on what things looks like.
 

drgottjr

Expert
Licensed User
Longtime User
i have uploaded advertently v0.0005 to drive. see post #1.

the ble advertisement has a so-called "appearance" entry. it's supposed to tell us what the device is: Thermometer, Ear Thermometer, Heart Rate Sensor, Heart Rate Belt, Blood Pressure, Arm Blood Pressure, Human Interface Device, etc, etc.
but that would make life too simple. instead:
1) manufacturers rarely use the appearance entry (it only takes up 2 bytes).
2) those that bother simply indicate "unknown" (0x0000).

there are over 300 appearance types. luckily, i can see a device which advertises its type, so i've been able to test what i see against the sig database. so i've added more information relating to the appearance entry in the scanning output.
note: as a result, i had to modify my database, so you need to uninstall any previous version you've downloaded. if you happen to scan a device that broadcasts an appearance type and you crash, that means an earlier release of the app is running. i've tested with the latest version.

i've also tidied up the scanning output to give you a better idea of what is captured.

the connection output can be saved (from the drop-down menu). initially, i used the date and time to set the file's name. i've changed that to use the mac address of the device to which the connection was made. since ":" is an illegal character in a file name, that has been changed to a "-".

i've revived a 20 second connection timer and progress dialog. the connection attempt can linger (usually if the connection will not be successful). during that time, the screen sits blank(ly). so i put a progress dialog. when there is a change in the connection status, the progress dialog disappears. if there is no change in status after 20 seconds, the progress dialog disappears and the connection attempt is closed. this mostly works. the problem is: even when a connection is made and the progress dialog disappears, communications between the scanner and the device can linger. so even after the connection is made, the screen may sit empty while the scanner and the device sort things out. this doesn't happen often, but it's annoying, and it's why i removed the timer in the first place. it's hard to know why communications hang after connection, but the device may be expecting something from the scanner. if it doesn't get it, it closes the connection. obviously, one would have to know what any given device is expecting, which is beyond the purpose of the scanner.

in addition to the motley selection of devices coming and going in my neighborhood, i recently captured someone's sleep apnea machine broadcasting. perhaps the owner was driving by my home while using the device.
 

drgottjr

Expert
Licensed User
Longtime User