I have inherited an application that connects to a ble device.
The app searches through devices that are scanned, and connects to the one that has a name that matches the expected name.
Pretty simple question...is this the standard way of connecting to a type of device?
Should I use something more specific like inspecting the services for the expected service ids?
The general approach is to filter the scan results using service uuid present in the advertising data. Name is not a good filter approach since it's supposed to be user friendly, and on many devices a user can put their own name, and potentially the same one as you are using.
Related
Can I have any 16-bit/32-bit UUID in advertisement packet for like filtering purpose?
Is it mandatory to have the list of service UUID listed in advertisement packet to be available in service discovery after connection?
Can I have standard GATT services to have unrelated service data in advertisement packet?
Can manufacturing data be made with custom manufacturer ID and data?
Where can i find the legality on these questions on both commercial and non-commercial purposes?
I want to make a BLE server in both android/iOS and also on a development board and I can't find relevant sources stating the legality on these standards.
The relevant source to look at is the Bluetooth Core Specification Supplement (CSS) which you can find here: https://www.bluetooth.com/specifications/bluetooth-core-specification/.
As you can see, it is very loosely specified. The Core Specification also does not say so much about the different AD types.
The spec says in the description "The Service UUID data type is used to include a list of Service or Service Class UUIDs." The spec then describes the different formats 16/32/128-bit UUIDs, incomplete or complete list. Other than that the spec doesn't say where this list comes from or what it represents. It however uses the formulation "If a device has no Service UUIDs of a certain size, ..." at one place. The spec though says that "16-bit and 32-bit UUIDs shall only be used if they are assigned by the Bluetooth SIG" so you can't pick any unassigned 16- or 32-bit UUID. So no you can not just pick any random 16- or 32-bit UUID, it must be an assigned one.
As in 1. the spec doesn't say which list should be advertised. But it is common knowledge that it should represent the list of GATT services that are present in the device's GATT database.
The spec for "Service Data" is very short. The description consists of one sentence: "The Service Data data type consists of a service UUID with the data associated with that service". For the data format it then says the data consists of the UUID followed by "additional service data". It is here, again common knowledge (I guess?) that the associated data must be defined by the specification of the particular service. for example, the Cycling Power Service defines the data as follows: "Cycling Power Service UUID followed by the Cycling Power Measurement characteristic value". So usually the associated service data consists of the characteristic value of a characteristic that has the Broadcast property enabled.
If the CSS is strictly followed (word by word), you could argue that it's possible to use a different list of service UUIDs than the ones in your GATT database. You could also argue that the manufacturer could put in its own "associated data" with a service in a Service Data record. I would say these are possible interpretations, but it's not what the one who wrote the spec intended.
The spec for "Manufacturer Specific Data" has the following description: "The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier from Assigned Numbers. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier." This means you cannot "steal" another company's identifier and use a data format defined by you.
Note that Bluetooth is way older than the smartphone era. In the beginning, everyone that implemented Bluetooth was for the purpose of selling a product that uses Bluetooth technology (earphones, speakers, phones). Still at this day, when making a Bluetooth "product", you need to be a Bluetooth SIG member (which is free but only companies can be Bluetooth SIG members) and when you use any of the Bluetooth trademarks with the product you need to get it qualified and listed at Bluetooth SIG. You can read at https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/ what actions and enforcements are taken if you fail to qualify a product. To qualify a product, you must follow the spec. There is a full test suite for qualification that you must pass. I'm pretty sure though it wouldn't catch if you use the wrong service list or "steal" a manufacturer's company id in manufacturer data. Developing software apps that run on already Bluetooth qualified smartphones is something that Bluetooth SIG hasn't thought of in my opinion. They have an option of qualifying as a "GATT-based Profile Client (app)" that costs $100 (https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/qualification-listing-fees/), but that apparently isn't for you since you implement the Server profile. I have so far not heard of anyone that has done this app qualification. So to me it's a bit unclear how smartphone apps should be treated.
In the end the idea is that everyone should follow the spec to ensure proper interoperability between different products.
For your particular case, if you just want to minimizie the Advertisement data, just request a Company ID from Bluetooth SIG (it's free) and use Manufacturer Specific Data.
I am currently having some issues with connecting to my peripheral. The bluetooth module in our peripheral does not seem to be advertising a name initially. I've have found that once I connect to the peripheral for the first time it will update the name and my scanner is then able to see the correct name.
I have no understanding why this is the case. I have also tried it using the Swift app we are developing, as well as a range of Bluetooth scanners on iOS and Android so I do not believe that this is an OS or programming error on the scanner side.
Is there a specific parameter that should be set on the peripheral. As I am just the app developer I do not have very much understanding about how the module is handing the process.
Any help would be much appreciated.
Just to confirm the scanner does not see a name for the peripheral until it has connected once. After this it will start displaying the name. Once the peripherals name is changed the old name is still being displayed until I have connected to it once again.
To display the name of device you need to see in advertisementData Dictionary which contains several keys depending on your device, in callback of didDiscoverPeripheral from CentralManager.
- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary<NSString *, id> *)advertisementData RSSI:(NSNumber *)RSSI
You can look for key CBAdvertisementDataLocalNameKey.
If you do not see the name, you can make changes in your firmware to include a name in GATT characteristic .
You can use LightBlue app to verify once. This is a good app on app-store to test your BLE device.
I am quite new to the jack audio software.
I was wondering, whether it is possible to specific applications to specific outputs.
I know could make a virtual device that I can connect anyway I want. But that only works if I am able to select the virtual device as output device within the application, right?
But not all applications have the option to chose outputs.
So the question is whether I can select an application in jack audio and route it the a device of my choice.
Being able to do this is the main reason why Jack exists. You can connect anything to anything with an external patch bay, you don't need to use the UI of the application.
Examples of graphical patch bays you can use are (my) Patchage, Catia, and qjackctl. You can also use jack_connect on the command line.
I use apps that interact with their specific devices. An example is Roku. The device is Roku and I use their Android App. Another is my Denon Audio receiver and it too has an app to control it. I'm looking to write app/hardware service. how does an app detect device on network and vice-versa?
Disclaimer: I don't know what Roku is but what you are describing sounds like service discovery as part of zeroconf.
One relatively known example is DNS-SD. You can think of it as sending periodically multicast UDP messages containing stuff such as "I am at address X and I provide service Y" to some well-known address. Whoever is interested will pick up the information associated.
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "