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.
Related
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.
Recently, while developing an app on the iPhone, I came across the problem of tracking vehicles. It was easy to track the vehicles on a map if they were stationary using Parse ( although not sure if it was the best method) but the issue was tracking vehicles if they were moving. I didn't want to query for geopoints in Parse unnecessarily if the location of the vehicle did not change. I was steered towards using Twisted, and after doing some investigation, realized this might be a solution. Using the reactor loop, when locations were changed I could notify the other users and update their maps appropriately. Conceptually, I understand this problem but having trouble finding information or help regarding GPS with twisted.
I currently have been running the gps example from the site, http://twistedmatrix.com/documents/12.0.0/core/examples/gpsfix.py
Using my MacBook pro to test, I found the available serial port and it attempts to open as a NMEAReciever but I was expecting a GPS location to be written. Once I can understand how to interact with the GPS, I feel I could tackle communicating this information through the iPhone with NSStreams such in the fashion of this tutorial except instead of sending text messages, it will be sending GPS locations
http://www.raywenderlich.com/3932/networking-tutorial-for-ios-how-to-create-a-socket-based-iphone-app-and-server
Overall, my question is how can I access the GPS coordinates of a device using Twisted through the tutorial provided. I hope my question was detailed enough and I would be more than happy to correspond with someone any more details. Thank you
I (eventually) wrote twisted.positioning, which is essentially a better version of the twisted.protocols.gps thing you're using. It has much nicer abstractions over concepts like positions, as well as receivers. That may be interesting to you, because it provides abstractions that you can use to e.g. combine information from GPS and other sources (like compass). However, I think that in iOS-land, that job is already (mostly) handled by Core Location. I'd assume that the best course of action is too hook that up to twisted.positioning (shouldn't be particularly difficult, can't be anywhere nearly as hard as NMEA is, at least!). Lacking iOS development experience, I can't tell you how to access Core Location from Python; I can only point at the docs.
twisted.positioning is also an improvement when it comes to documentation. Unfortunately, that wasn't very difficult, because its predecessor came with none at all. I hope the one scant example that is provided helps, though; and I'd be more than happy to elaborate if it doesn't.
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 need to develop with BLE technology. I found some introductions and source code:
http://processors.wiki.ti.com/index.php/Category:IPhone4SBLEDemo
but I didn't find any tutorial to start from scratch with this technology (CoreBluetooth framework) from choose the sensor for testing, also WWDC 2011
Is there any tutorial to start with BLE technology on iOS?
Many Thanks!
Unfortunately there isn't much out there for the core bluetooth framework as it is relatively new. I would suggest acquiring a very solid understand of how bluetooth low energy works before writing any code.
A couple of decent resources:
Research around this site to start seeing where services and characteristics are located, and what they do.
http://developer.bluetooth.org/gatt/Pages/GATT-Specification-Documents.aspx
This site has the actual firmware implementation code of the services you will see on the bluetooth sites along with a more thorough explanation of how these things work with the supplied documentation.
http://www.ti.com/tool/cc2540dk
If all of that makes sense to you then I would obtain a device and start hacking away. The core bluetooth framework has sparse documentation but relies heavily on delegation. You will find that once you start discovering services in the delegate methods, that discovering and using characteristic values is a piece of cake.
You should look at the following:
CBCentralManager
Here is the Sample Code you can start with:
Temperature Sensor Example from Apple.
Also Make sure: You signed into Apple for Developer Provisiong profile in order to test your application into your iPhone.
Hope this helps.
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.