What's all this gibberish about?

After a few readers asked why I wanted to read a webpage using my mBed dev board, which appeared to contain nothing but gibberish, it's probably time for a fuller explanation.

The idea was, of course, to get a simple prototype working, then post a series of blog entries detailing how we got it to work. But since we're not at that stage yet, and recent posts have stirred interest, here's what we're trying to do:

The mBed will form the heart of a switching unit.
We've already built something similar, years ago - a PIC based board which can activate (and de-activate) a number of relays. The relays provide isolation to a 240V mains supply - so we can use a microcontroller to switch things off and on around the house.

With the mBed we had hoped to take this a stage further.
The problem with the PIC-based approach was that it was a USB device, and so needed to be connected to a PC all the time. By using the ethernet support on the mBed, we could do away with the PC altogether - the microcontroller could talk to the web server directly and receive messages. (yes, this could be achieved with a bluetooth-to-serial type adapter, to talk to the router via wi-fi and relay messages back to the MCU over serial, but this project was originally to help us learn to use ethernet for something useful!)

Anyway, here's where we're up to:
We want to be able to send messages over the internet, to get the switching unit to turn things on and off. In fact, we wanted to take this idea further and to send text messages to our little switching unit. The final aim - and proof that it works - is to be able to send a text message on the journey home from one of our BuildBrighton meetings, and have the kettle/coffee pot switch on, so there's a nice hot cup of coffee waiting when we get in!

In the fullness of time (and when we've got two-way messaging working, so the switching unit can report back it's status) this sort of thing could actually be useful for vulnerable or disabled people, to help support them in their homes....

Anyway, while we're still trying to get the microcontroller to talk to the router, we ploughed on ahead to set up the text messaging side of the project. By using a text-to-web gateway, we can provide two means of accessing/controlling our switching unit while away from home. As before, other ways of achieving the same result exist (get the microcontroller to talk to a SIM card and send text messages directly to the unit) but we decided on the text-to-web approach and are determined to stick with it!

To send text messages to any internet connected device, we:

1) bought a keyword for a shared shortcode from textmarketer.co.uk
This costs about £6/month (because we picked the cheapest keyword they did)
2) created a script on our web server to capture messages and store them in a database
3) told the textmarketer.co.uk interface about the script

So what happens now is that whenever a message beginning with the keyword 2MBED is sent to 88802, it is forwarded (by the textmarketer server) to our web script which stores it in an online database (why the awkward keyword 2mbed? Keywords that begin with numbers cost £6/month, keywords beginning with letters cost £12/month - this is for a proof of concept, so we didn't want to go splashing the cash!).

We then built a separate web page which reads this database and displays any captured messages, using special characters as delimiters so we can break the data up for parsing at a later date. It is this web page that we want the mBed device to poll, and act on any messages received



As you can see from this screenshot, we've already captured a few text messages. The web output includes a number of messages in the form:

GUID (32-character globally unique id to identify the message)
Date message was received (in YYYY-MM-DD-hh-mm format)
Phone number the message was sent from (obscured for privacy reasons!)
The actual message (everything following 2MBED in the SMS body)

Each of these bits of data is stored separately in the database (the textmarketer web API also captures the network used to send the message if this is of any use). We write this data out to a web page, using the carat (^) symbol to denote the end of a field, and the hash character (#) to denote the end of an SMS message.

That's it really. Quite simple.
We've also added some extra trickery into the web script to allow you to try it out, without the need to pay for your own short code. Simply visit http://www.nerdclub.co.uk/mbed and follow the instructions to create your own keyword for a text-to-web interface.

Note: sending text messages to shortcode 88802 only works from within the UK

Never working is better than working sometimes

After trawling the mBed forum and trying out lots of different HTTP client type examples, I was shocked earlier today to actually see some HTML appear in a terminal window. Success!

The mBed successfully talked to the router, got an IP address via DHCP and made a request to my own server (I've set up a web page to broadcast messages when a username/password combination is sent).

Unlike previous attempts, I used the Twitter example which uses HTTP POST instead of HTTP GET to retrieve a response from a web server (it actually posts data to the server too, but I'm not interested in that side of things yet).



I was utterly amazed to see a response from the server appear in the terminal window. Finally, something was working and I could concentrate on building my web-enabled device. True, it was still a niggling concern that previous examples hadn't worked, but by now I just wanted a working solution (see how this whole library-based approach to development just makes you abandon understanding for the sake of getting something to work?!)

I was so thrilled, I wanted to see my web page contents appear again, so I pressed the reset button on the board and waited for it to get the data again.
Nothing.

It was assigned an IP address, then just sat there.
Very much like the previous attempts - it got to the HTTP POST command and just locked up!

I reset the board again.
Nothing.

Then again.



This time, some HTML appeared in the terminal window.
What the......
Exactly the same code running on exactly the same hardware, calling exactly the same web page (nothing changes between attempts) sometimes works and sometimes doesn't. A more frustrating scenario I can't imagine just at this time!

After repeating the experiment, I now have a sort-of-working HTTP client which can return data from a website, but only once every six or seven attempts.
Straight away, I thought hardware - dodgy soldering and loose wires - after all, if the software/firmware doesn't change between it working and not working, it must be something else.

I replaced my home-made RJ45 socket (which still works with other development boards, so I'm convinced it's not the problem, but just to be sure) with a pre-built breakout board, with all the connectors in place.



The result was the same. Resetting the device (or removing power from it completely) resulted in more locking up and occasionally a response written to screen.
All in all, a really frustrating week - I feel it would have been better spent building an ethernet device to connect to a PIC-based project myself! At least then, when it didn't work properly, I'd at least have some understanding about what was going on and maybe even why it wasn't working.

I've never been a fan of plug-n-play type development, as it discourages full understanding. And my experiences with the mBed development system haven't done much to change that view just yet!