I'm in the process of writing a CoreBluetooth driver in Swift, and I'm discovering services and characteristics.
One thing that I've noticed, is that the Apple operating system always returns standard Bluetooth characteristics and services as strings instead of raw UUIDs, identifying them.
For example, instead of saying "180A", the log will say "Device Information," or somesuch.
I see these in English. I have no idea if they are localized.
I'd like to be able to access these values for my own purposes (logging and debugging), but I can't find them listed anywhere.
Is there a known, standard place that publishes a glossary that I could use? The best, of course, would be if I could access the Apple pages, but I don't see anything in CoreBluetooth that describes this.
Otherwise, I need to set up my own glossary.
Related
Rather new to Bluetooth Low-energy devices, and having recently purchased a bunch of trackers off Amazon, decided to write a little application to see what type of information I can get from these.
The trackers are from a Chinese company, and they don't have a ton of information around advertisement information, so I'm playing by best guess here.
What I've been able to achieve so far, through Flutter Reactive BLE, is to find the devices by their ID (filter out additional noise I don't care about) and pull information like RSSI, Name and ID from it.
Now I want to interpret the manufacturerData object, screenshot attached of just one of them, and can't seem to get anything concrete from it.
I half assumed that reactive_ble would've stripped the leading checks and only supplied the the necessary portions of the data object that's relevant to interpret, however, this does not seem to be the case.
My first feel was to just convert this UInt8List to String utf8.decode(device.manufacturerData), however, this returns either a 1x spaced string or nothing at all.
I've tried using ByteData with a start of 3 and end of 4, and that's not very helpful either.
Is there something I'm missing in it's interpretation? I've read the Bluetooth spec and as I don't come from a CompSci background, is rather foreign to me, so would appreciate a layman response.
The first 16 bits (little endian) in manufacturer data contain the manufacturer id (Bluetooth SIG's web site has a list). The layout of the rest of the bytes are totally up to the manufacturer. If you can't guess what they mean, you'll have to ask the manufacturer.
I'm working on a Bluetooth LE project, and it's going fairly well.
However, I am now up to supporting a Kiwi device, and the rules are changing a bit.
Before, I would use various combinations of BLE read and BLE write properties on vendor-specific GATT characteristics, but I think that Kiwi might use the Indicate property.
I can find almost no documentation on Indicate, and how to work with it. Apple doesn't seem to have any mention of it in their docs, and the Bluetooth spec barely mentions it.
I must have missed the documents on that property, and how it differs from read. From reading the (very short) blurbs on it, it sounds just like read, but my explorations of the Kiwi device don't seem to be supporting it.
I know that this is a bit of an "open-ended" question, but I need to learn more about Indicate, and how it is supported in CoreBluetooth.
I would really appreciate any pointers. I just need a bit of a breadcrumb trail that I can follow.
Thanks!
Indicate and Notify are similar; They provide a new characteristic value to the central when the peripheral changes that value without the central needing to perform inefficient polling. The difference at the Bluetooth layers is that the central needs to acknowledge receipt of an Indicate to the peripheral, while with Notify no such acknowledgement takes place.
Since the Core Bluetooth framework abstracts the underlying Bluetooth stack from your app you don't need to worry about the difference between Indicate and Notify - Core Bluetooth handles it for you.
All,
Apologies in advance - this question might be too open-ended for SO.
Anyway... A friend of mine (an engineer and entrepreneur) is in the process of building a high-tech piece of lab equipment. He's asked me about the feasibility of building an iPhone/iPad/iPod application that would allow users to control the device via Bluetooth, so I'm helping him gather some information. I'm hoping to get a few pointers on how to get started. Specifically:
Would this require a native app, or could this be accomplished with HTML5 (with or without something like PhoneGap?)
Can you point me to a good primer on bluetooth networking? Everything I've found assumed a VERY high level of pre-existing knowledge.
What are the basics on how something like this is accomplished? Is there a single, established protocol for how one device "controls" another, or is bluetooth more like SSL - just a pipe that allows you to convey any type of message?
I realize this question is incredibly broad and detailed - so I'm not really looking for specifics. But obvious Google searches don't turn up much, and I'm otherwise having a hard time finding a good starting point.
Thanks in advance.
You can communicate via bluetooth in two ways: One is using the Low Energy Bluetooth capabilities of iOS 5 and newer iPhone/ipads.
https://developer.apple.com/library/ios/#documentation/CoreBluetooth/Reference/CoreBluetooth_Framework/_index.html#//apple_ref/doc/uid/TP40011295
Unfortunately the documentation is sparse and will require some hacking away. If you choose this route I would consider starting here and learning as much as you can about how the protocols work before hacking into the framework:
http://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx
The limitations of this route are that it might not be best for sending a lot of data. I have only built stuff that sent simple commands which it does work great for.
The other option is the external accessory framework. This will require you to get an mfi license from apple (not fun). You will also need to pay royalties. But it will do what you want. You won't need to concern yourself much with underlying protocols if you use this, the framework provides a friendly api for processing streams.
http://developer.apple.com/library/ios/#documentation/ExternalAccessory/Reference/ExternalAccessoryFrameworkReference/_index.html
I am looking at UUID generation in Blackberrys.
I need to be able to generate 128 bit UUIDs from last generation Blackberrys.
I have just looked through the API and it looks like the javax.bluetooth.UUID class is the way to go.
Can I assume that this API will be available for all Blackberrys? Is there another, more standard/better, way of generating 128 bit UUIDs from a Blackberry?
Edit: I also found this other class net.rim.device.api.synchronization. UIDGenerator. All I need to know is if this is available for all new Blackberries, since I'm not going to develop the app but require a 3rd party developing it to send me a 128 bit UUID.
The Bluetooth UUID class doesn't actually generated UUIDs, it's just a data representation of a UUID for Bluetooth purposes. I don't think there's a native API on the BlackBerry for actually generating UUIDs - you may need a third party library for that.
UUIDs (depending on the definition) are usually just a hash sum of the current time and the hardware (MAC) address (as those are considered being unique) of a/the network device, e.g. bluetooth or WiFi devices. If you don't need to build UUIDs conforming with specific UUID algorithms but just need unique IDs, you could just roll your own easily. Otherwise it shouldn't be too hard to implement a standardized algorithm either.
Look here for some UUID algorithms: http://en.wikipedia.org/wiki/Universally_Unique_Identifier (there are also links to Java libraries for generating UUIDs)
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.