Hey Guys,
Over the next week I will be working on a code restructure of the entire project. I will be abstracting all classes that are currently dependent of Android APIs so that they can be implemented for different wireless communication stacks. I will also be making some of the larger and more complicated methods smaller and more readable.
After the restructure is done we will be adding support for the Windows Bluetooth stack and maybe another form of wireless communication. In addition, we will be developing some new apps that use BlueMesh to demonstrate its capabilities.
Stay tuned for more updates!
-Jerry
Wednesday, September 5, 2012
Wednesday, July 18, 2012
Addition of Routing in BlueMesh
The traditional Android-only BlueMesh now has functionality to route messages to certain devices on the network. The "write" method now has two versions. The first takes only the byte array as before. The second takes the byte array and a RemoteDevice of some target, and sends the byte array only to that target, if connected at the time.
The routing done is similar to how messages are sent normally, only a targeted message will be ignored by all but the target. This allows for information to be routed only to one device on the network through other, unrelated devices.
The message packet is constructed in a different way depending on whether or not it is a targeted message or not. The old packet construction was allocated so that byte 0 was the message level, bytes 1-4 were a message ID, and bytes 5-1028 are the message itself. Targeted messages are now laid out so that byte 0 is the message level, bytes 1-4 are a message ID, bytes 5-12 are the target, and bytes 13-1036 are the message. Keep in mind these distinctions are controlled by the Constants file and can be changed if necessary. Specifially, the MESSAGE_ID_LEN controls the number of bytes long the message ID is. TARGET_ID_LEN is the length of the target identification, which is a byte array representing the Bluetooth address of the device. MAX_MESSAGE_LEN controls the maximum length of a message, currently set to 1024 bytes.
Message chunking has not been implemented and may not be, since the heuristics to making sure that all of the pieces get where they need to in order are difficult. Instead, increasing MAX_MESSAGE_LEN can be used for reasonable values. I do plan on doing some testing to find what is reasonable for this purpose.
The Agnostic project has been started, but I've run into difficulties in determining what exactly the interface should supply and/or be required to supply. Since different versions of Bluetooth work so drastically differently, it may be better to simply rewrite BlueMesh for a different device. Included here and below is the pertinent information for writing BlueMesh for J2ME, and I'm unsure as to whether or not that will be my next project or not. If anyone is using BlueMesh and is in need of it for a different platform, that may be my next project instead.
Until then, I may just continue testing and debugging.
The routing done is similar to how messages are sent normally, only a targeted message will be ignored by all but the target. This allows for information to be routed only to one device on the network through other, unrelated devices.
The message packet is constructed in a different way depending on whether or not it is a targeted message or not. The old packet construction was allocated so that byte 0 was the message level, bytes 1-4 were a message ID, and bytes 5-1028 are the message itself. Targeted messages are now laid out so that byte 0 is the message level, bytes 1-4 are a message ID, bytes 5-12 are the target, and bytes 13-1036 are the message. Keep in mind these distinctions are controlled by the Constants file and can be changed if necessary. Specifially, the MESSAGE_ID_LEN controls the number of bytes long the message ID is. TARGET_ID_LEN is the length of the target identification, which is a byte array representing the Bluetooth address of the device. MAX_MESSAGE_LEN controls the maximum length of a message, currently set to 1024 bytes.
Message chunking has not been implemented and may not be, since the heuristics to making sure that all of the pieces get where they need to in order are difficult. Instead, increasing MAX_MESSAGE_LEN can be used for reasonable values. I do plan on doing some testing to find what is reasonable for this purpose.
The Agnostic project has been started, but I've run into difficulties in determining what exactly the interface should supply and/or be required to supply. Since different versions of Bluetooth work so drastically differently, it may be better to simply rewrite BlueMesh for a different device. Included here and below is the pertinent information for writing BlueMesh for J2ME, and I'm unsure as to whether or not that will be my next project or not. If anyone is using BlueMesh and is in need of it for a different platform, that may be my next project instead.
Until then, I may just continue testing and debugging.
Tuesday, July 17, 2012
Bluetooth Client and Server Information
In J2ME, the client in Bluetooth works through the DiscoveryListener interface. This means that the client-side must have some object that extends the DiscoveryListener interface. Meanwhile, the server has a DiscoveryAgent and does some things (as detailed in my last blog) to create an input-output stream between the server and client. However, the method for picking up the other (client) end of the steam was unknown. Below is a tutorial on how the J2ME client should look simply to get an input and output stream.
Note: Something followed by "()" is used to define it as a function in the API, but does not necessarily mean it has no arguments.
An action on the DiscoveryAgent on the client's side causes the four triggers in the DiscoveryListener, also on the client's side. To start, the startInquiry() method on the DiscoveryAgent will eventually call the deviceDiscovered() method in the DiscoveryListener whenever a server device is discovered. Then, the searchServices() method on the DiscoveryAgent finds services from the server and calls the servicesDiscovered() method once it has completed. This will return a ServiceRecord, which contains all the services that the server contains. To summarize, DiscoveryAgent.startInquiry() eventually calls DiscoveryListener.deviceDiscovered(), while DiscoveryAgent.searchServices() eventually calls DiscoveryListener.servicesDiscovered(), which contains as an argument a ServiceRecord.
This ServiceRecord can be used to be accessed all of the services, but the connection URL can be obtained with one line of code (Where servRecord is the instance of ServiceRecord):
String connectionURL = servRecord.getConnectionURL(0,false);
The URL returned is the RFCOMM URL that connects to this device. With this, a StreamConnection can be created with another line of code, which connects the devices and opens the stream between them:
StreamConnection con = (StreamConnection)Connector.open(connectionURL);
This StreamConnection can be broken down into an input and output stream, as in the server. These input-output stream pairs should communicate with each other, and will allow BlueMesh to pass data using the RFCOMM between the devices.
I am still uncertain as to whether the RemoteDevice's Bluetooth address or name should be used as a universal identifier to be passed to the router in BlueMesh. Both are easily accessible from the RemoteDevice. I am leaning towards the address, as the name can be duplicated, but I am unsure as to whether or not it is something that all API's (or at least the Android API) can also deliver.
Note: Something followed by "()" is used to define it as a function in the API, but does not necessarily mean it has no arguments.
An action on the DiscoveryAgent on the client's side causes the four triggers in the DiscoveryListener, also on the client's side. To start, the startInquiry() method on the DiscoveryAgent will eventually call the deviceDiscovered() method in the DiscoveryListener whenever a server device is discovered. Then, the searchServices() method on the DiscoveryAgent finds services from the server and calls the servicesDiscovered() method once it has completed. This will return a ServiceRecord, which contains all the services that the server contains. To summarize, DiscoveryAgent.startInquiry() eventually calls DiscoveryListener.deviceDiscovered(), while DiscoveryAgent.searchServices() eventually calls DiscoveryListener.servicesDiscovered(), which contains as an argument a ServiceRecord.
This ServiceRecord can be used to be accessed all of the services, but the connection URL can be obtained with one line of code (Where servRecord is the instance of ServiceRecord):
String connectionURL = servRecord.getConnectionURL(0,false);
The URL returned is the RFCOMM URL that connects to this device. With this, a StreamConnection can be created with another line of code, which connects the devices and opens the stream between them:
StreamConnection con = (StreamConnection)Connector.open(connectionURL);
This StreamConnection can be broken down into an input and output stream, as in the server. These input-output stream pairs should communicate with each other, and will allow BlueMesh to pass data using the RFCOMM between the devices.
I am still uncertain as to whether the RemoteDevice's Bluetooth address or name should be used as a universal identifier to be passed to the router in BlueMesh. Both are easily accessible from the RemoteDevice. I am leaning towards the address, as the name can be duplicated, but I am unsure as to whether or not it is something that all API's (or at least the Android API) can also deliver.
Thursday, June 21, 2012
Bluetooth ServerThread Interface Design
I've managed to work out BlueCove sufficiently enough to use it. Its syntax is identical to that of J2ME. J2ME is a version of Java that is designed to work with small devices, hence its built-in API support of Bluetooth. BlueCove, however, lets us use these same commands with J2SE (Standard Edition) and your basic computer running Windows or OSX.
I have also learned how to use these commands to write client-side and server-side algorithms to get devices to communicate. A useful, if slightly unclear, example can be found on CodeGuru.com. This gives us an input and output stream to work with. Since BlueMesh ultimately uses just an input & an output stream, this should be fine. However, BlueMesh's ServerThread currently passes a "BluetoothSocket" object instead, and that object is deconstructed to an input and output portion in the ReadWriteThread. So, BlueMesh is going to require a back-end redesign.
The ServerThread-like Interface will need to export an input and output stream. This is because the input and output streams are the lowest common denominator in the Android API and the J2ME API. The J2ME API gets these streams from the StreamConnection object, while the Android API gets them from the BluetoothAdapter object. Each object is specific to its own API, and cannot be included in an agnostic BlueMesh. So, the ServerThread will have to send only the input-output stream and some sort of device-identifying data (Device Name? Random Serial Number?) to the RouterObject. It will then be the RouterObject's job to find out if that device is already connected and to set up the ReadWriteThread for it.
Further, the way that J2ME handles clients is unusual. Specifically, it does not generate a BluetoothSocket object, so ClientThread will have to be reworked as well. The J2ME client is implemented with a virtual class, "DiscoveryListener", with four purely-virtual functions that are called when certain things happen, such as discovering a device. I am unsure as to whether or not this class is automatically a thread or really much about clients in J2ME at all. More research will have to be done.
Hopefully, I will just be able to extract from one of these functions/objects the input and output streams, so that the overall design of BlueMesh can be preserved. Otherwise, the ServerThread may be the only object able to set up communication and pass it to the router, meaning the client-side ClientThread will have to invoke the ServerThread to create two-way communication. I want to avoid this, so hopefully it won't be necessary.
Wednesday, May 30, 2012
Interfacing with others!
Hello, All!
As detailed in the last post, BlueMesh will be trying to make the move towards greater compatibility. Specifically, we're looking towards creating a Java interface that will encapsulate all of the proprietary portions of Bluetooth. So, if you are willing to write an interface class for your platform, then BlueMesh will work on it.
That's the vision. Practically, BlueMesh will have to come with a couple of common interfaces. Luckily, I found another open-source project, BlueCove, that will allow Microsoft, OS X, and a few other platforms to do just that. Specifically, I no longer have to write code for these machines specifically; I can use this program as a bridge. More importantly, I hope that BlueCove will give me some insight as to what exactly the BlueMesh interface should expect and contain, so that any interfaces can be written easily.
This task, as large as it is, is one of my greater priorities, for two reasons.
1) It will give BlueMesh greater compatibility and intercommunication
2) It will allow for testing with the library itself to be done one any one platform, and it can be a platform of choice. The Android SDK is nice enough, but doesn't allow for easy debugging. If this interface is successfully written, then BlueMesh can be tested, and eventually operated, between any two Bluetooth-enabled devices.
That's the vision. Practically, BlueMesh will have to come with a couple of common interfaces. Luckily, I found another open-source project, BlueCove, that will allow Microsoft, OS X, and a few other platforms to do just that. Specifically, I no longer have to write code for these machines specifically; I can use this program as a bridge. More importantly, I hope that BlueCove will give me some insight as to what exactly the BlueMesh interface should expect and contain, so that any interfaces can be written easily.
This task, as large as it is, is one of my greater priorities, for two reasons.
1) It will give BlueMesh greater compatibility and intercommunication
2) It will allow for testing with the library itself to be done one any one platform, and it can be a platform of choice. The Android SDK is nice enough, but doesn't allow for easy debugging. If this interface is successfully written, then BlueMesh can be tested, and eventually operated, between any two Bluetooth-enabled devices.
Monday, May 21, 2012
Over the summer
Hey guys,
I just wanted to write a quick post about what will be going on with BlueMesh this summer. Sean will be working on the project with RCOS at RPI and he has a lot of really awesome things that he plans to do. I will be working up by Boston this summer, but I will still try to help out as much as possible.
Some of the changes we hope to implement are as follows:
1) Port BlueMesh to Java. Currently BlueMesh only works on Android devices, we plan to port it to Java so it will run on PCs as well. This will make development much easier and quicker. Once we have a working version in Java it should be quick and painless to port it back to Android.
2) Implement message chunking. Message chunking will allow us to determine the optimum maximum size of a message and allow us to chunk messages into this maximum size in order to allow for maximum throughput.
3) Implement routing algorithm. This will allow for point to point communication rather than flooding the network with every write.
There are other changes that are also in speculation right now in addition to these three. I'm sure Sean will be updating us with his progress often and I look forward to seeing BlueMesh progress.
-Jerry
I just wanted to write a quick post about what will be going on with BlueMesh this summer. Sean will be working on the project with RCOS at RPI and he has a lot of really awesome things that he plans to do. I will be working up by Boston this summer, but I will still try to help out as much as possible.
Some of the changes we hope to implement are as follows:
1) Port BlueMesh to Java. Currently BlueMesh only works on Android devices, we plan to port it to Java so it will run on PCs as well. This will make development much easier and quicker. Once we have a working version in Java it should be quick and painless to port it back to Android.
2) Implement message chunking. Message chunking will allow us to determine the optimum maximum size of a message and allow us to chunk messages into this maximum size in order to allow for maximum throughput.
3) Implement routing algorithm. This will allow for point to point communication rather than flooding the network with every write.
There are other changes that are also in speculation right now in addition to these three. I'm sure Sean will be updating us with his progress often and I look forward to seeing BlueMesh progress.
-Jerry
Monday, April 23, 2012
So close to our first release!
Currently we are one bug fix away from our first release of BlueMesh!
This week I added in an argument to the BlueMeshService constructor so that you can specify a UUID for your program. This is important because you probably don't want your BlueMesh program to interact with other BlueMesh programs.
This is how you can call the constructor now:
A UUID is specified by hex digits in the following format 8-4-4-4-12. The UUID can also be used to enable or disable backwards compatibility of your app! If you would like a new version of your app to be able to talk to an older one, simply do not change the UUID between versions, however if your network protocol changes between versions you can specify a new UUID so that a new version will not communicate with an older version.
The bug we are still trying to fix involves not properly detecting a disconnection and deleting information about that device so that a re-connection will be attempted and successfully completed. I hope we will have this fixed within the next few weeks and we will try to keep you updated on what we think might be causing it.
This week I added in an argument to the BlueMeshService constructor so that you can specify a UUID for your program. This is important because you probably don't want your BlueMesh program to interact with other BlueMesh programs.
This is how you can call the constructor now:
bms = new BlueMeshService(UUID.fromString("fa87c0d0-afac-11de-8a39-0800200c9a66"));
A UUID is specified by hex digits in the following format 8-4-4-4-12. The UUID can also be used to enable or disable backwards compatibility of your app! If you would like a new version of your app to be able to talk to an older one, simply do not change the UUID between versions, however if your network protocol changes between versions you can specify a new UUID so that a new version will not communicate with an older version.
The bug we are still trying to fix involves not properly detecting a disconnection and deleting information about that device so that a re-connection will be attempted and successfully completed. I hope we will have this fixed within the next few weeks and we will try to keep you updated on what we think might be causing it.
Subscribe to:
Posts (Atom)