Monthly Archives: May 2013

So, after receiving my replacement watch from the guys at Pebble, I cracked on with an idea for a watch face I’ve had since I backed the project last May. Presenting the ‘Potential Divider’ watchface!

DividerIn electronics, the potential divider is a simple circuit that lets you take one input voltage (here seen as a static 24 volts and step it down to a smaller value by dropping it across two resistors. The salient facts are that the larger of the two resistors gets the larger share of the input voltage. By choosing correct values for the two resistors, you can change (for example) the 24 volts to 12 volts on the output (right hand side) by setting the two resistances exactly equal. Half and half.

What I’ve done here is set the top resistor to the hours value, and the lower resistor to the minutes value, making the time shown here to be 20:46, or 8:46 PM. Thus R1 (top) has the value of 20 ohms, and R2 (bottom) a value of 46 ohms. The calculation of the output voltage is just an added detail that amuses me as an electronics student, but also has value in saying “Oh yes, it’s 17.6 volts o’clock”, to many facepalms. The maths is simple:

DividerMathsThe real challenges were getting that output voltage onto the screen. If you don’t know, at the moment Pebble watch faces are written in standard C, which is quite a complex, low level and generally confusing language to be introduced to programming in. It involves a lot of complexities that aren’t necessary to get across to someone starting their programming journey what a language is and how it works. But personal minor grievances aside, in C if you want to store text, it isn’t a simple String text = "This is my text!"; , it’s an array of characters: static char text[17] = "This is my text"; .

So what, you might ask? How does that make putting a number on the screen a challenge? Well the answer to that question is this: To take ‘17.6V’ and store it in a character array, because C is such a low level language, there is usually a pre-written function to take the floating point value and store it in a character array. But with the Pebble SDK in its current state, these standard string libraries aren’t linked, so they can’t be used (yet)!. So the solution was to do each character separately.

In the five character array used for 17.6V for example, characters 3 and 5 are always the same. 3 is always a decimal point, and 5 is always ‘V’. So outputText[3] = '.'; and outputText[5] = 'V'; are done. Easy. The others are not so simple. A method I already knew to get a character from a number is to simply do the modulo of that number by 10. So for the second character, I’d do int secondCharacter = 17.6 % 10; which would yield the remainder of 17.6 divided by 10, which equals 6. For the first character I’d divide the voltage by 10, then repeat the process. 17.6 / 10 = 1.76. 1.76 % 10 = 1. So now I can use outputText[1] = '0' + secondCharacter; for example. Same for the first decimal place, except that would require multiplying by 10 to get 176 % 10 = 6.

But once again the infantile nature of the Pebble SDK flies in the face of my ambitions. It also turns out that the Math.h library (also standard in C) isn’t linked either! So I would have to do the modulo function manually. This is easy. It can be seen in full in the source code at the end of this post, but the essence is this: for 17.6 modulo (%) 10, divide 17.6 by 10, subtract the integer part (1), then multiply by 10 again to get the remainder, which is 7. This ‘integer stripping’ part is done by iteratively comparing the result of the first division against one. When the iterative divisor results in less than one, the integer part is found. Here is the code fragment:

float stripInteger(float input) {
float stripLoopTemp = 0.0F, intResult = 0.0F, result = 0.0F;
float safeKeeping = input;
float i = 1.0F;
int maxInt = 100;

for(i=1.0F;i<maxInt;i++) {
stripLoopTemp = safeKeeping; //Keep original argument safe

stripLoopTemp /= i; //Divide by this iteration's divisor

if(stripLoopTemp < 1.0F) { //Found integer part! intResult = i - 1.0F; //For i = 3 -> 2.5/3 < 0 ==> integer part = i - 1 = 2
result = input - intResult;


This, in combination with the manual modulo, enabled me to slot the individual characters of the result float voltage value into the character array slots for display by the watch. Job done! Whew!

So, finally, we can see the results. Here is a YouTube video, showing the watch face in action, plus a little ‘electron seconds marker’ that travels around the circuit. I’ll leave the details on how that works for those who want to peek into the source code (link), because it is nothing innovative here. The source code download also includes the watchface package incase you want to use it yourself! Enjoy!


So, seeing as I enjoy programming and system integration more than semi-conductor physics (Here’s looking at you, exam!) I decided to find a new use for an old GDM1601c 16×1 LCD display from an old kit I had when I was younger.

From experience (Digital Logic labs from the second year of university) I know that these types of displays have a standard interface, so it was easy enough to make whatever text I wanted come up on the display, especially with help from the Arduino LCD library, which replicates the protocol I reverse engineered (almost) in that second year lab experiment. If there’s one thing you learn from practical electronic system integration, it’s never to trust a datasheet!

The main quirk with this ‘type’ of display is that the memory locations for the left half and right half of the display are not analogous with their real world counterparts. This means that characters 1 – 8 are the ‘top line’ and characters 9 – 16 are the ‘bottom line’. Apparently this means they are easier to manufacture (source: this article), and once again highlights the quirks of electronic manufacturing, another example being that CMOS logic used in most integrated circuits is all inverted (NAND instead of AND!). To get around this limitation (as can be seen in the source code attached), I wrote a function that decides how to display the input text based on its length. If its between 8 and 16, the function splits up the text into two halves, and draws them on the screen accordingly (Curse wordpress and not allowing indents in code sections!):

/* Print a string between 7 and 16 characters to a 'Type 1' 16x2 LCD
* Author: Chris Lewis
void printToLCD(String input) {
//Clear both sections
lcd.print(" ");
lcd.print(" ");

//Check message will fit
if(input.length() > 16) {

//If length between 8 and 16, split it up for displaying
else if(input.length() > 8) {
String firstHalf = input.substring(0,8);
String secondHalf = input.substring(8);

lcd.setCursor(0,8); //Crazy Type 1 Addressing...

//If length less than 8, just print it!
else if(input.length() < 8) {

Anyway, the real fun came when I modified the Arduino sketch to accept Serial data from a computer (a lá what was achieved in the third year MEng group project this year, which I may get around to writing an entry about, although it was the bane of my life for about six months, but well worth it in terms of what I learned from it) and show that Serial data on the display.


Again, this wasn’t a huge challenge, so I took it one step further, which to me was to write a Java class I could use in any general project to send text from a Java application to the LCD display. After some experimentation with the RXTX library I got this to work, and it was a nice novelty to type something into the command prompt and see it appear instantaneously on the LCD display.

So far so good, the class is ready for use in a more advanced project, such as a network enabled application. Examples that come into my head right now are:

  • An external health meter, ammo counter or score counter for a single/multiplater Java game
  • A notification display for received chat messages if I get around to finishing my Java chat client
  • Some sort of readout for a future project involving my Pebble watch, once I get my hands on the replacement.

So, without further adieu, here are some more pictures, and source code!



OSWL icon

So being forgetful sometimes, (not to mention opportunistic when I see one) I have been known to walk away from my laptop without locking it. Not that I have anything to hide, but I do have some frightening stories from a few years ago, when people would come across my session and take the opportunity to be deviant (be it people who might be of the disposition to enjoy a good Facebook hijacking session, or kids back in school who would take the opportunity when I was at the printer to send a few more hundred pages for kicks).

So with that slight character flaw in mind, and the fact I’d recently created an authenticated Android -> PC link capable of executing anything at all, I had an idea for what I’ve named the One-Shot Wi-Fi Lock app. Put simply, it uses all the classes I’ve developed over the last couple of projects to connect to my laptop over Wi-Fi, send the CMD lock command, then disconnect and quit the app. My student house Wi-Fi address always appears to be static in the form 192.168.1.XX, so it is hard coded in as a String.

So, if I walk away and forget to lock the session, I can just take out my phone, tap the app icon on my homescreen and after a brief flicker of an Activity, can be sound in the knowledge that the screen is now locked (After seeing the ‘Successful!’ toast, of course).

So I was in town earlier today, and I remembered that I’d forgotten to lock my laptop. No worries, I got out my phone and launched the Android Command App, typed in my IP and hit connect.

Now, I’d never tried it over HSDPA before, but I was delighted to see the top status bar turn green, and allow me to press the LOCK button. I then used the TeamViewer button to remotely launch TeamViewer and allow me to verify the LOCK command had worked. And it had!

Here is a screenshot showing a connection made over HSDPA (IP is changed for security, or something)


Since creating the client and server (detailed in the last post) I have made a few observations. Firstly, there was no security whatsoever. This means that if someone who had compiled the source code I released an knew my Internet IP address and when the server was up could have in theory obliterated my PC!

So for now I have put in a check using certain hardware characteristics of the incoming connection’s device against known values for my own phone. Thus in theory, only my phone can now use the server. I’ll verify this behavior once I get a hold of another device from a friend in the coming days.

Also, issuing the command 'cmd' appeared to be the only command that did nothing, but after a few button presses on the phone and some head scratching I came to realise that this was because the server was creating a silent cmd window using the silent cmd window. A look at Task Manager revealed this to be true.

Luckily, at the moment the server code waits for the ProcessBuilder that executed 'cmd' to wait for that child process to finish before returning, or I would have had quite a few processes to kill! Although while writing this it occurs to me that once the host java.exe process was ended, the child process would follow suit.

If you do compile and run the source code I released, please bear in mind that it is still UNSECURE in the manner I just described. If you would like the more secure version please send me a tweet. 

UPDATE: Source link now actually includes ALL the source code…

That proved to be much easier than expected… All it needed was modifying the Java server and implementing a NetConnection Thread class in an almost verbatim reproduction from the Networked Java game. I’m almost disappointed!

So without further adieu, here are the screenshots, with an explanation and source code below:

The PC runs the AndroidCommandServer jar file, and waits for a connection from the Android phone. Once a connection has been made, it waits for plain text ‘cmd’ commands and executes them when they arrive. For this demonstration, I simply sent ‘notepad’ to conjure up (almost as if by magic) a Notepad window! More usefully, this could be used for remotely locking the PC etc.

AndroidCommandServer Console

Here is a screenshot of the phone, post command issue (click for full size):


As you can see, the app is very rough and ready (and actually my first time using the Eclipse plugin’s graphical element editor, as previously for soundboards and the A* pathfinder I’d always done it in the pure XML view), and I may implement the reception of text from the PC (Which would appear where ‘TextView’ currently rears it’s ugly head) but it’s not needed at the moment.

Also, for simplicity and cleanliness the phone will terminate the connection on app suspend (onPause()) by sending #disconnect which instructs the server to end the I/O streams that side.

Here is the source, also a good clean first time app for any speculative Android app writers that want a simple example (excluding the Socket stuff, but that is simple enough to be instructive too, I guess)