Hey guys,
Thanks to Doug helping us create a test app, we were able to verify that BlueMesh is working as expected after the code refactor. We are going to do another week or two of testing before we go ahead and release our next alpha version just to ensure that everything is working as we want it to.
There are still a few small features we are going to implement (mostly optional arguments when building bms) that will be in the new release that we will be doing this week.
Support for Windows, Linux, and OS X will most likely not make it into this alpha, but we will have another alpha release soon after this one with all those features included.
Stay posted for exciting mesh networking news on BlueMesh!
Jerry
Monday, October 22, 2012
Monday, September 24, 2012
BlueMesh Test App
Hello,
As Jerry mentioned last week, I've been working on an application to test the basic functionality of BlueMesh. I'm still learning the Android API and the BlueMesh code base, so my confidence in my work is not astoundingly high. However, I have a first draft of something which is at least a good step towards working. I'll be spending the next couple of days making sure that it does what it needs to.
As of right now, I have the test results simply displayed as a Toast message. Ideally, I would like to set up a full graphical interface of some sort, with a list of the tests performed and checkboxes (or something) indicating whether each was successful. I'll also be looking to expand the set of tests as I get more familiar with what the service is capable of, and as the features themselves are expanded.
-Doug
As Jerry mentioned last week, I've been working on an application to test the basic functionality of BlueMesh. I'm still learning the Android API and the BlueMesh code base, so my confidence in my work is not astoundingly high. However, I have a first draft of something which is at least a good step towards working. I'll be spending the next couple of days making sure that it does what it needs to.
As of right now, I have the test results simply displayed as a Toast message. Ideally, I would like to set up a full graphical interface of some sort, with a list of the tests performed and checkboxes (or something) indicating whether each was successful. I'll also be looking to expand the set of tests as I get more familiar with what the service is capable of, and as the features themselves are expanded.
-Doug
Monday, September 17, 2012
New Developers
Hey Guys,
As you may know, BlueMesh has been in development for just over a year! It began with a lonely group of one (me) and remained as such for about 4 months. For the past 9 months Sean joined the team and we were two. As of a few weeks ago BlueMesh has attained 2 new developers: Doug and Zach!
Over the next few weeks...
Doug will be working on writing a test application for BlueMesh that we will use to ensure that our master and dev branches are in a working state.
Zach will be working on updating our wiki to reflect our new API (sorry) and all of the new features that we are implementing.
Sean and I will be working on BlueMesh core functionality. First we will be adding support for Windows and maybe Linux and OS X.
Contact us with any questions you may have,
Jerry
As you may know, BlueMesh has been in development for just over a year! It began with a lonely group of one (me) and remained as such for about 4 months. For the past 9 months Sean joined the team and we were two. As of a few weeks ago BlueMesh has attained 2 new developers: Doug and Zach!
Over the next few weeks...
Doug will be working on writing a test application for BlueMesh that we will use to ensure that our master and dev branches are in a working state.
Zach will be working on updating our wiki to reflect our new API (sorry) and all of the new features that we are implementing.
Sean and I will be working on BlueMesh core functionality. First we will be adding support for Windows and maybe Linux and OS X.
Contact us with any questions you may have,
Jerry
Sunday, September 9, 2012
Builder Pattern
Hey guys,
I recently change BlueMesh so that when constructing BlueMeshService objects, rather than using a constructor method you now use a builder. This makes it a lot easier to add new features to BlueMesh such as support for WIFI or other operating systems. In addition, it is now a lot easier to configure BlueMesh to exactly how you want it. Here is a short example of how it works:
-Jerry
I recently change BlueMesh so that when constructing BlueMeshService objects, rather than using a constructor method you now use a builder. This makes it a lot easier to add new features to BlueMesh such as support for WIFI or other operating systems. In addition, it is now a lot easier to configure BlueMesh to exactly how you want it. Here is a short example of how it works:
BlueMeshService bms;
BlueMeshServiceBuilder bmsb = new BlueMeshServiceBuilder();
bms = bmsb.uuid(UUID.fromString("fa87c0d0-afac-11de-8a39-0800200c9a66"))
.bluetooth(true)
.build();
We will be updating the documentation to reflect these new changes soon and also have some new tutorials about how to use BlueMesh.-Jerry
Wednesday, September 5, 2012
Another Code Restructure!
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
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, 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.
Subscribe to:
Posts (Atom)