Goodbye Modbus Droid, Hello Mobile Modbus

I’ve been really busy with some new and exciting stuff for a while now. This year I saw my frist child, a daughter born, around that same time I shifted from being an Electrical Design Engineer, to an Engineering Supervisor at Veeco. And then, in September, I was offered a Software Engineering position at Trane in their commercial Climate Solutions division.

In all this time I haven’t had much of an opportunity to get back to my hobby project, ModbusDroid. I’ve had ideas for a while on how to improve it, and I even started working some on a fragment API (Android 3.0+ UI guidelines), but never got very far with it because of all the craziness with life this year.

So, I’ve decided it is time to get back on the wagon and start back to it – but with some caveats and a few notes.

1) In all the computer transition, and a minor server hard drive glitch, I lost the key files to the original ModBus Droid, so I currently can’t upload any updates to the Google Play store. Also, a while ago, I started working on a re-name of the project for porting the app to the BlackBerry playbook, and I’ve decided I like the somewhat more generic naming – Mobile Modbus. So for the time being, the app is going to be a brand new app, not a 2.0 of ModBus Droid. Mobile Modbus might stick as a name, it might not – I’m open to suggestions so send them my way.

2) Very early on, after I layout some rough frame-work and UI for the app, I’m going to do the development out in the open on GitHub. A lot of this is going to be re-written from scratch or heavily refactored. So, to all my friends who have been telling me that they were thinking about getting into Android development – get your github accounts set up – and follow me there. Install git on your PC, and the Android SDK, and import the old version of modbusdroid from github so you know you are set up and good to go. There has never been a better time – they even started bundling eclipse with the android SDK to make it easier to get started – and github has great GUI git clients for both windows and mac.

3) Part of this refactor is about being a better open source citizen. We make heavy use of the Modbus4J library in the app – a pretty great library that does batching (which we don’t currently use), and I made some non-trivial, but not major either, changes and additions the library. Rather than being awesome and contributing patches back to the main repository, I just dropped a rev of the source code right into the projects source and never really looked back. This time I’m going to clone the CVS and convert it to Git (done actually) and publish that to github with links back to the original project. I would contribute right back to the sourceforge page, but honestly – CVS… in 2012/2013… I hate CVS, not gonna happen any time soon. Call me lazy, but at least I’m going to make it easier to seperate out what I did vs what was from the original project. I plan on tracking it better too.

We’re also going to be using the ActionBarSherlock and SlidingMenu libraries, and I’ll make a fork of those on github if we need to change anything in them.

4) I really really want to get a few features into this 1.0 release of this app that weren’t in the original Modbus Droid. First off, I want to get Modbus RTU over TCP in there, and lay the groundwork for eventual bluetooth serial port adapters (SPP) with straight ModbusRTU. I also want at least lay in the foundations for saving some favorites in terms of configurations / IP addresses, and the possibility of giving registers names. Finally, I also want to get in something that could write out updates to a file for data logging. I’m contemplating some of the more advanced features would be in and ‘advanced mode’ in the settings or something like that to keep from cluttering the simple interface for people who just want to get in and out quickly while/after monitoring some registers. Only when the advanced mode was on would we expose some of these UI elements to enable these features. To see some of the design patterns for the new versions of android, and some neat extensions to them, check out Android Views.

So anyway, this is where I’m taking things. Hopefully over the next few weeks during the holidays I can get a few commits into github and you can all start to see where this is going. And if you are feeling adventurous, read up on Modbus, the Modbus4J library, and Android development – and feel free to jump in by forking the project on Github once it is on there (I will tweet/G+/blog about it when it is up).

ModbusDroid now on GitHub

All work on ModbusDroid, the modbus scanner/polling client app I wrote for android, will now take place using the GitHub.

The last released version – 1.0 – will remain available on, but will not be maintained there anymore. When I have a minute I’ll update the blog posts and pages with this info. But there are probably like 2 or 3 people in the world who care that I’m starting to hack away on a tablet/Android 3.0/4.0+ version that uses fragments and the action bar APIs, and I thought you precious few, my beloved audience, might be interested in this change.

Again, just as before – PLEASE – do not post questions on my blog about the app, post them on github so I can better answer them for all people who might be interested in the answers.

ModbusDroid 1.0 Release!

After working on another app for a start-up and some half-written project ideas, I decided to return to my original app ModbusDroid and finally clean up some stuff that was obnoxious about my first go at it.

So here you have it, I added a landscape layout that moves the Modbus controls to the left in their own column, and the data has its own column to the right. And I fixed the issue that disconnected from the server when rotated from portrait to landscape (or vice-versa), but it still disconnects if you exit the app to avoid doing any unnecessary draining of your battery. A few other nagging bugs – there seemed to be a few exceptions from bad inputs in the settings or register offset or lengths. So I set all the text-boxes to be numeric-only keyboards and inputs. Please report a bug on launchpad if you are able to enter any alpha characters into any of those boxes with any keyboards I don’t have installed (like swiftkey – I only have the stock keyboard and swype installed, and I don’t have a physical keyboard). I also fixed some annoying bug reports that came in from the market – for the record on those, if you put “crash” in the description that is not helpful at all – if you put what you were doing, that helps WAAAYYY more, and I’ll fix it as soon as I see it and can reproduce it.

Unfortunately I didn’t clean up everything I would like to (still have the stupid “JAVA: Socket Exception, timeout while trying to make a connection” error messages instead of a more friendly message). But maybe as time allows I’ll circle back to that.

All that being said, let me know what you think about the final 1.0 release, and I hope you find the minor tweaks I made an improvement.

Going beyond 1.0

I learned a lot about android, and real application development during this project as well as when I was working on Whooznear (the prototype App I put together w/ my friend Alec for the startup now named Primmo Apps). And in all that learning, as well as everything I’ve read and learned since then I’ve realized I could do a lot better at making this app a little more friendly, and easier to maintain and extend w/ new features.

Also, since then android 3.0 came out and brought w/ it the new fragment and action bar APIs, and just a few weeks ago android 4.0 brought those features to phones. And I got to thinking there were some usability improvements that could be had on this app if I leveraged those.

So I’m thinking re-write w/ new APIs when I can find the time (who knows when that will be – I’m having a kid early next year – but here’s to hoping anyway!). Something to expand a little nicer to a tablet layout – especially in layout mode. I’m thinking something more like a grid layout, where each column would have a register number and the value in it, and the number of columns would be screen size dependent (i.e. portrait on a phone would be 1 column, portrait on a tablet would be 2, layout on a tablet would be 2 or 3 – depending on the font). And maybe I’ll cook up some other niceties – if you have suggestions feel free to post them here, or to put them into launchpad (or github – read on for more info on that).

Besides that, I’ve gotten some requests for these features (or dreamed them up after some request made me think of them):

  • Data recording to a file
  • Real tested Slave support – for some TCP to RTU bridge devices you can have multiple slave IDs, so that might be useful for some people
  • RTU support for devices that can connect to your phone or tablet that have a COM port
  • RTU over TCP – this is a use-case for some people. Might be worth looking into
  • Modbus4J library changes to be posted separately – not a feature per-se, but still a request I think is worth doing
  • The ability to put ‘names’ at certain register locations instead of the register number

Now, I’m probably not going to be able to tackle all of these requests, but I’m hoping to re-architect how I did the app (again, if I can find time) for android 3.0+ devices to include some of these. And I definitely want to separate out my changes to the Modbus4J library so that I can more easily contribute back to the community that developed it originally, and so I can more easily track upstream changes as well. Right now when people ask me about it I’m forced to say “uhhhh…yeah, I just dumped the source code into my project folder for ModbusDroid and started hacking – I couldn’t tell you what I changed.” Since then I’ve gotten a lot better about knowing how to keep projects separated and yet connected, and use these new fan-dangled DVCS features like ‘branches’ to keep my changes separate from the upstream changes.

Switching source-code management and hosting
Finally – I keep pushing everyone to for the hosting of the project, and there are a lot of awesome things about Bzr and launchpad, but to be honest, since then I’ve kinda fallen in love w/ Git. And GitHub seems to have a better community and UX vibe going on (“Fork This” is a great banner). And, bazaar apparently messes w/ some of my work software (ePDM from Solidworks), and crashes that when I right-click on stuff inside of our company vault, so I had to uninstall it for now – making it a pain every time I want to upload changes in my source code to launchpad. So as soon as I commit the 1.0 release branch to launchpad (after I finish this blog post and upload the APK to the market), I’m going to switch the project to Git – the first commit will be the 1.0 branch – and then upload to github for my hosting. Look for an announcement about that sometime later this week, and I hope for a lot of you this will make it simpler to follow the project as I think Git (and to a lesser degree Mercurial) is gaining more and more traction all the time, and I hear less and less about Bazaar outside of Ubuntu.

Thanks for your feedback so far, and keep it coming so we can make this a great piece of software for the other android faithful out there in the controls industry.


Introducing whooznear

As some of you know, my friend Alec Wojciechowski and I have been busting our humps for the last couple of months (while both of us are attending classes BTW – Alec for his masters, me for VLI) to turn out a prototype of an android app for a startup called Whooz Near.

The premise of this app is something called proximity networking. To break that down, the idea is that this app allows you to discover people you don’t know, who are in your immediate vicinity, while at the same time making yourself also available to be met.

It uses bluetooth to find the people near you, so it is limited by the 20-50ft range of most bluetooth devices. And it transmits the data over bluetooth, only storing it temporarily for display – the app does no permanent storage of the discovered devices or profile data – which helps it to not cross the ‘creepy line’ as Eric Schmidt so aptly put it.

As far as the development of this app goes, I have to say, Bluetooth in android is a fairly weak API, and hardware support is all over the map. We had some Samsung android 2.1 devices where the bluetooth wouldn’t discover anything around it. We were not getting any call-backs to our code after we started bluetooth discovery. Our phones could see those phones and make a connection, but not the other way around. And when the connection was made, it was flaky.

So, let that be a lesson to you, don’t buy cheap samsung phones stuck at android 2.1.

I don’t know exactly when this app will be available in the app store. That is up to the people at Whooz Near when they think it has been tested throughly enough. I’ll update this post with a market link when it comes out.

So, on to the picture gallery. Below you will see the Local Profile editing screen, and then the nearby screen without anyone near-by (because I didn’t get a chance to grab a screenshot last time Alec and I were working together). Eventually I’ll add some more pictures to show when two devices are connected – but the empty “Near By” screen will show a list with the name and tag-line (or status if you prefer) and a small picture.  Then if you touch that, you get a screen that looks almost just like the Local Profile screen, but shows their extended profile information.

Watch for it in the next few weeks on the Android Marketplace, and then let WhoozNear know what you think.


Introducing Modbus-Droid!

After much furious learning and coding between VLI semesters, I have finally churned out my first ever Android app.


Modbus-Droid is a Modbus TCP client / scanner, that is designed to scan a contiguous block of modbus registers at a regular interval.

Using the software:

All you do to get this going, is go to the settings page and set the IP address of the Modbus Server (or slave in old terminology), the TCP port you want to communicate on, and the polling time. Then set the register offset you want to start reading values at, the length (or quantity) of registers you want to read, and the register type (Holding Registers/Coils, Input Registers/Coils). Press Menu->Connect, and once it connects and receives modbus register data, it will display in a list. You can then change the settings for the offset, register range, or register length at any time, and the list will update on the next scan.

Finally, you can also change the data display – which is how the data you are reading is displayed on the screen. Coil data can, of course, only be displayed as binary – so I represent those as “True” or “False”. But the register data can be displayed as binary – a collection of 16 1’s or 0’s for each register, unsigned and signed integers (single register, double register, or quad register types), as well as floats and double floats (which are 32-bit and 64-bit respectively).

If you are displaying Holding Registers, you can write the values, and the write dialog displayed will be tailored to your data display. So if you have the binary display, you will get a list of 16 checkboxes, where you can set, or unset individual bits within the register. If you are displaying an unsigned int, it will not let you put in a decimal place or a negative sign. Similarly, it will let you put in a negative sign when you are displaying signed ints, and it will give you the decimal place when you are displaying floats. I just want to make sure that people, like me, don’t make a mistake when entering the data to be written.

Other aspects of the project that are interesting to me

One thing about this whole process that has really excited me is that this was a fun learning experience for me, and I feel pretty confident that whatever Alec (my friend who only lives a few blocks away, and who is also a hobby android developer – his app is called MeterMaid) and I cook up for our next project will go a little faster and we both are confident enough in our knowledge of the Android APIs to go quite a bit quicker.

I’m also excited to release my first ever open source project, which is based upon an open source library – Modbus4J. (To be fair, there is one component of the library, that the original creator has chosen to not open source).

I’ve used this project to learn a little about Launchpad project hosting site, and the Bazaar version control system. I’m definitely not an expert by any means on either system, so please give me any feedback on how to better manage this project, or better set up the launchpad site (or better utilize bazaar for code management).
Launchpad site for the project:
Report and view Bugs Here:

Finally you should note – this is still in beta. I’m sure there are bugs I haven’t found, and a couple of less than optimal things that I do know about. So please let me know by emailing me or filing a bug.