The problem with being unable to even send a program to the chip was only the start of my problems. One little understood problem with Bluetooth is the proprietary nature of what is called the "Bluetooth Stack". The Bluetooth Stack is based on specifications from the Bluetooth SIG and it is a framework of different data structures and functions that are normally associated with different hardware such as keyboards, mice, audio players and an extensive list of other types of devices. Needless to say, the data and functions exchanged or required would be differ from a Bluetooth keyboard to those required by a Bluetooth bicycle computer. And on top of all those differences their are different versions of Bluetooth to contend with. As if I didn't have enough ambiguity then there is the problem of different versions of operating systems, each of which has their own Bluetooth stack. Not only do they have their own stack they are also in the process of rewriting it for various reasons.
The reason that I finally swore off working on a Microsoft based computer and switched to Linux (I use Ubuntu) was an incident where I was installing a Bluetooth based set of headphones. I would go through the install and they would work flawlessly until I rebooted the computer. When I rebooted they were nowhere to be seen or heard from. After doing it a few times thinking that I must not have done something right I decided to watch the reboot closely and I discovered that Windows discovered that a new Bluetooth stack had been installed and it uninstalled it and installed it's own version which didn't support the headphones. The lesson that I learned is that if both the manufacturer and the operating system are not on the same page Bluetooth won't work properly. Even worse, it might work until one of them decides to change their software.
For whatever reason they give, neither the manufacturer of the chip nor the the operating system (other than Linux) will show you the source code for their Bluetooth stacks. An analogy that comes to mind is that it is like two black boxes communicating via smoke signals. You may be able to see he smoke but you are left to guess as to what was meant by one black box and what is inferred by the other. Added to that is the fact that Bluetooth communicates using what is called Adaptive Frequency Hopping where each smoke signal appears (maybe, but not always) on different frequency. So now it becomes like reading smoke signals on a windy day. And now the problem of security comes up and they want to encrypt the packets too!
Please keep in mind that my projects were to investigate two things, an indoor guidance system for the visually impaired and ans an unobtrusive product information beacon. I want to design a cheap hardware system to send minimal information like a geographic location and or navigation hazards. All of this was desire was based on the lure of Bluetooth Low energy devices. Despite all of the hype you might hear I can tell you that there are significant barriers to designing such a system.
So what's a guy like me supposed to do?
I am working on what I call Anonymous Bluetooth. By understanding the communications between the host and the client I am trying to design a system to craft packets that will bypass the security and complexities of the Bluetooth stacks.
The way I plan to get it to work is by using a robust protocol (the original) called SPP Serial Port Protocol. It is universally supported by every Bluetooth stack that I have ever seen. What I intend to do is to craft packets using a cheap Arduino computer and transmit them to channels that I know will be received by the client.
By properly choreographing the packets the client's implementation of Bluetooth will be happy. The way it will work in practice is the client will pair once with one of my computers and it will appear to be a SPP device with a known UUID or MAC address. All of the relevant pairing data is passed to the neighboring beacons. The neighboring beacons monitor the RSSI (signal strength) and packets being passed. If the client device is in another beacon's reach the tow beacons communicate on another channel (not necessarily using Bluetooth protocols) and they mutually decide to hand off the client to the new beacon. Any pending communications are exchanged between the beacons and the client has no idea that it is not still communicating with the new beacon.
Basically what I intend to do is bypass the Bluetooth stack on the beacon side and spoof packets to the client side while keeping track of where the client is.
In practice this is how it will work for the visually impaired. The visually impaired person is informed of the system and helped to initiate a pairing with a beacon. They now want to go from eye department to the x;ray department. Since the Arduino that I am testing has been outfitted wit SD Card reader (currently 4 G byte) it will have an extensive list of destinations and hazards to watch out for during the journey. Hopefully their device will have a magnetometer to tell them the direction of their next way point. The Arduino based beacons can send both audio and visual cues to the client on demand. The client's current location is passed token ring style to a master server so that the client's progress can be followed. The client's destination beacon is informed that it has a client coming. A missing client search can be conducted by passing a token around to which with a location and time stamp information is added.
The way it will work for commercial applications is very similar. A client pairs with the 'real' device at the door of the business. The client is once again passed from beacon to beacon only this time the beacons have a list of products and or specials in it's domain along with the shortest route from one beacon to another.
No comments:
Post a Comment