Hacking and Making, Lost Arts?

Published on 18 Nov 2011 at 11:09 am. No Comments.
Filed under Uncategorized.

As technology has advanced, we seem to have lost something important along the way. We used to be creators of technological things but there’s now an increasing tendency for us to be consumers. Back in the 70s if you wanted a computer you had to make one. At least by then there were LSI chips and kits like the one that famously inspired Bill Gates and Paul Allen. Making things was an excellent and inspirational way of learning about technology.  Increasingly now, we buy the tech we need. This is a lot less fun and it leaves a significant gap between the way we’d like things done and the devices we have to live with.

For some reason the desire to make what you can’t buy appears to be gradually returning, as evidenced by the advent of “hackspaces”, “fablabs” and home hacking in general.  This is despite the resistance created by health and safety issues associated with tools, soldering etc.  Groups like “Open Source Hardware User Group (OSHUG)” are appearing.

I was glad to discover a BBC program on this on Radio 4 recently (hopefully still on iPlayer by the time you read this). This contains coverage of the excellent London Hackspace (well done guys) and a reference to the “FabLab” work of the MIT Media Lab’s Bits and Atoms programme, capably explained by Neil Gershenfeld in this TED Talk of a few years ago.

One of the first things that the Beeb commentator had to explain was that the term “hacking” originally referred not to acts of greed or malice but simply making things work in ways that were not originally intended - “just for fun” (also the title of Linus Torvald’s book”. See MIT’s gallery of hacks for some examples of old-style hacks.  I guess both of these meanings will inevitably stick but, to us, hacking is benign.

Mobile App development is one of the few areas inspiring the digital generations to innovate. I attended this year’s “OverTheAir” “hackathon” at Bletchley Park recently.  Great venue, interesting talks and hundreds of people hacking interesting stuff over a 2-day event.  (Visit this venue anytime to see some fabulous tech history.)

Just as I was thinking that I had all the mobile app I’d ever need, Google made Android into a platform for physical device innovation with their Android Accessory Development Kit (ADK). It’s early days for this architecture that bridges the mobile world with that of electronics and I hope to see some interesting innovation around this.  Our hack at OverTheAir make use of this to build an “Internet of Things” device based on an Android phone.  That became the orb mentioned on this blog recently.

I really do hope that this dying art of the the “maker” is in a sustainable revival. I particularly hope that kids will get the kind of support and encouragement that we did back in the 60s when making things was a more respected pastime. “Maker Faires” that attract young and old makers alike are cropping up across the globe.  It would be great to see a return within the educational system to practical science teaching that inspires, enables and supports innovation.

Building an “Ambient Orb” for IoT Apps

Published on 17 Oct 2011 at 5:31 pm. No Comments.
Filed under Uncategorized.

This is going to be a long-running project as there are so many ways to do this. The objective is to provide an unobtrusive yet effective way to communicate with people around a home or office. The idea is not new and you can buy one of these from Ambient Devices. However, this one is quite different in the way it gets its information. Specifically, I wanted it to be pachube-compatible so it can be used in numerous types of projects where people have full control over the back-end processing and several choices of communication medium.

The specification(s):

  • low-cost components
  • on-board processing possibilities
  • wired or wireless options
  • standards-based connectivity
  • option to run on battery power
  • brightness control

I made one to evaluate the idea:

  • glass dome (IKEA or B&Q)
  • base unit (painted wood for prototype)
  • Microcontroller (MCU) and comms board stored in base
  • Power LEDs (RGB), drivers and heatsink (yes, even LEDs get hot)

Output devices/ actuators should not poll as this just chews up power; feels wasteful and is.  I chose the TCP Socket protocol provided by pachube. This features a publish and subscribe mechanism so the MCU does not have to keep polling for data. Instead, it is alerted when the data changes.

The candidate MCUs were AVR (Arduino) and MBED, the latter being chosen for the first version because the socket libraries were available and there’s plenty of RAM allowing for communication in JSON format. This one uses wired Ethernet. Another version will most likely be built with a Nanode. This will allow a cost saving at the expense of more work on the software. One interesting option would be to use a low-cost wireless receiver instead of wired Ethernet. I also made a version based on a Seeeduino ADK board that communicates via an Android phone.  I’m going to try that with an old Android I know longer use.  Also with an old USB dongle if I can figure out how to drive that.  I was pleasantly surprised to be able to use the Android phone as a gateway although this needs two background async processes - a bit complicated.

BTW. Many thx to @dcuartielles or getting me off base with ADK and to the guys at #londroid for pushing eclipse as the way to go for Android dev.

The LEDs were a tricolor power LED module (LX1610RGBW/A) and the driver was in a quad DIL package (DS3658). For simplicity, the first version limited the current to the LEDs so was not very bright. Subsequent versions will have a larger heatsink and, optionally, be able to run these LEDs at full power. A current-control circuit will probably be needed to do this safely, given the risk of doing everything through software and accidentally over-driving the LEDs.

The firmware is made simpler by using the MCUs pulse-width-modulated (PWM) outputs to control the relative power to each LED. Most of the work is in setting up the connection to the server and dealing with data as it arrives. As firmware is easily loaded from PC or Mac we made a version that cycles the colour values while testing.

In order to control this while testing we made a web page with a colour table selector that sends colour settings to pachube.

colours table

In real applications one would take sensor data and process it before sending an appropriate colour to the orb.

Watch this space for future versions and applications.

How smart will your smart meter really be?

Published on 4 Oct 2011 at 1:23 pm. No Comments.
Filed under Uncategorized.

I had been thinking about this and was spurred into action by this item from Horizon Digital Economy Research.  I have commented on a lot of articles about smart meters and decided it was time to set down some thoughts. As I was putting pen to paper another article arrived from the Guardian with a number of interesting points.

Smart meters are coming our way, despite any objections such as those being raised in the US (they are really worried about radio - or is it political?). In the medium term the data derived from this will not only reduce meter reading costs and improve billing but will become the lifeblood of a new smart grid.

For reasons best known to the utilities, the chosen data transmission system is to use the GSM (mobile) netwrork and send data at low (30 minute) resolution. Consumer access to this data is not guaranteed and there are suggestions that, at best, it will be available in some digested form on utility company websites. There is an obligation for them to provide in-home energy monitors but these are unlikely to be any more effective that those currently in use. (Initial interest quickly wanes, as do the savings.)

This may make the utilities comfortable but it does not provide a basis for ordinary, non-fanatical, consumers to save significant amounts of energy. Given the enormous cost of the meter rollout, this is at best a massive missed opportunity.

I say this after two years’ study of the home energy-saving challenge in which I and a colleague have achieved savings of 25-30%. This is the kind of saving that is and will continue to be only available to enthusiasts who are prepared to sink a lot of time into the challenge.

To enable the majority to achieve similar savings we believe that the following is necessary:

1. Data must be available instantaneously and must have a resolution in the order of 20 seconds or better.

2. Data capture must be fully automatic and accurate (unless the consumer is super-fanatical enough to do it manually)

3. Data must be available to consumers for their own use or to release to third parties at their discretion.

4. Social tools are needed to help people to support their peers on their journeys to home energy efficiency.

The social tools will come (from 3rd party sources) as and when the data are available to drive them.

The above are blindingly obvious to anyone who has made a serious effort to understand their energy consumption. We hear a lot of complaints about tariff complexity but that’s nothing compared to the problem of figuring out whether your boiler or freezer are delivering reasonable efficiency. The most important devices to understand are those for heating and cooling that normally control themselves.

This is where frequently-updated data comes into its own. Measuring the daily consumption of a boiler or a freezer tells you that it’s consuming too much but not why. However, with more detailed information such as precise on and off times you can decide what to do about it.

Not only does the current plan (a spec would be nice) seem to meet none of 1 to 3 above, it will also further exacerbate the already severe congestion of the GSM network and do nothing to advance the need for ubiquitous, fast (wired/ cabled) broadband in this country. It’s hard to get to the bottom of the decision to use GSM. Is it data security paranoia on the part of the suppliers or is it fear that incompetent installers would mess up anything not wireless?

This looks like yet another episode in the sad saga of government-led projects that either over-run financially, fail to meet their objectives, get cancelled or all three.

.. and they call this Smart?

TSB Consultation on TIC for Future Internet

Published on 8 Jul 2011 at 7:53 am. No Comments.
Filed under Uncategorized.

I attended this session yesterday (and appreciated the invite given my micro-business status).  Consultation on a possible Technology Innovation Center.  It was well-run and met my expectations (information and networking) so what’s not to like?  On reflection I can think of a few points that seem to be worth recording.

The session itself

The introductory talks added little value because most people in the room were aware of the state of technology and pundit predictions for the future.  This would have better handled with read-before material and much shorter presentations.  The Q&As were welcome (although most of the questioners pontificated instead of asking questions).

The discussions

Interactivity is always the good part of consultations and this was no exception.  You get the opportunity for discussion with people with a variety of backgrounds and interests.  The general drift was that a “Future Internet” TIC could be valuable as it would add a longer-term, more strategic dimension to existing government funded R&D and offered the possibility of a vision for how the UK can lead in certain areas.  Without such an activity we are doomed to follow.

The TIC formulation

There seemed to be general agreement that this TIC would need to be cross-sector and cross-discipline.  There would need to be be good leadership and continuity over a much longer period than is usual for government-backed projects.  It was difficult to address the “why would they come” question without representatives of sector-based clients in the room.  I surmised that they needed to understand the 1+1=3 collaboration proposition - a hard one to prove.  Clearly SMEs would only come if the TIC evidently provided business opportunities.

The after-lunch session

A lot of “what is a TIC” questions had been fended off in the morning but these were addressed after lunhc.  Again, this would have been better as pre-reading.  Such reading was available but too voluminous so, judging by the questions, most people had not read it.  We now learned about the funding model (one third private) which is certain to present the major challenge.  We need to understand why, given the overheads, sponsors would use this vehicle rather than fund it themselves - in other words are the benefits of collaboration understood and believable?

Conclusion

This was useful and thought-provoking.  The next step should involve client organisations.  The idea of an opportunity brokerage for SMEs should also be explored.

Hackathon @ Pachube

Published on 9 Apr 2011 at 9:15 am. No Comments.
Filed under Uncategorized.

Just a quick temporary post before I get my head down. We had a ton of fun at Pachube’s first international hackathon.

I built one of the first Pachube Apps called “Averager”. It takes any user-submitted gas and electricity datastreams (kW only) and posts 15 minute averages on feed 22414.

This is rather crude to say the least but it works thanks to stirling help from Ben and Paul. (Writing jquery when knackered is not my strong suit). Code samples are needed and I’ll post one in due course if no one else gets there first.

Future plans include making the results secure to participants only. (The basis for socialmeter.)

I need to sort out a couple of things such as picking up submitters’ icons and doing a nice visualisation (another Pachube app using websockets - watch this space). [PS. Have done a multi-stream graphing tool and will put it up when I figure out how.] Hopefully the icons can be referenced through with the app’s “user” attribute. If “Install App” is not extensible this could be done with an email dialogue.

My big question is how to make the app configurable so that each group of users will have their own feed for averages. The answer seems to lie within Pachube Groups once I have permission to create and maintain one (Ben please). The group will give registered users access to the Averager feed which will otherwise be private.

So all these features of the platform show the usual Pachube prescience.

Add some “how to” here. Basically just find apps on beta.api.pachube.com, log in and follow the instructions. Psychic powers always useful. It’s under the heading of “mashups and converters”.

… to be continued …

Enjoy :-)

(Fun with) MBED, Pachube and Sockets

Published on 7 Apr 2011 at 8:29 pm. No Comments.
Filed under Uncategorized.

With the Pachube hackathon upcoming, I gave myself a deadline for moving forward with a couple things that had been brewing for a while.

  • Substituting MBED for Arduino where a little more horsepower is needed
  • Trying out Pachube’s raw sockets APIs to get a couple of key improvements

(At the hackathon I’m looking forward to familiarising myself with their new apps platform. More on this after the event.)

For those not familiar with MBED please see the doc on mbed.org. Highlights:

  • ARM chip on DIL carrier with decent amount of flash and RAM 
  • Has onboard USB for program loading/ power and Ethernet support - everything but the RJ45 connector. 
  • Online IDE compiler and docs - needs only browser and USB - no downloaded app - I find that rather convenient.
  • Libraries (official and contributed) - quite a wide range of peripheral device support
  • Cookbook pages - fast start for all the common things you might want to build
  • Contributed notes on hardware aspects and such things as how to roll your own IDE

This is not really open source as we know it. However, you get many of the benefits and you can see a good deal of contributed code. And you can join in of course if you have code to share. My main concern is that this could get very fragmented as, while there is good tech support,  there’s little in the way of curation of the contributed stuff. All in all it feels like a fairly productive way to do prototypes.

I got hold of a couple of ways to prototype: breadboard with a few widgets and a small board with key connectors.

MBED

Ideally I would have liked the larger board with a solderable breadboard area but those seemed to be out of stock recently.

Anything for production would need a surface mount PCB.  On the upside, the MBED in its carrier costs a lot more than the chip on it so the cost of the board could be offset somewhat.  I’ll return to the question of cost in a later blog.

Arguably, you would not use an MBED if Arduino or PIC would do.  However, I have always wanted a platform that had more horsepower and better real-time support and MBED seems to promise that.  I’m unlikely to invest the effort in porting an RTOS but someone else might.  In any case, the speed and capacity of this platform would eliminate the headaches I had when working on a cheap heating control. (Of course I no longer need one - see blog on Intuition box). 

Putting it to work

Pachube have raw socket interfaces now.  This is excellent because it allows us to cut down on the protocol overhead for connected sensors and actuators.  Once you get the hang of this it’s a very tidy way to do things.  The really great bit is the ability to use publish and subscribe.  This is a very nice way to hook up an actuator.  Before, actuators had to poll the Pachube or had to be servers (with attendant firewall issues).  Now, they can listen on a socket which seems to me to be far more elegant.

In building a simple demo I hit a couple of issues:

  • Socket library doc could be better - it is automatically produced stuff that doesn’t explain how sockets should be used.  I plan to post something to help people not very familiar with socket programming.  Some of the available example code was not suited to my actuator requirement (i.e. socket client).
  • Pachube used JSON for these APIs.  This is goodness but it implies a need for decoder library.  The only one I found did not work in the MBED environment.  I lashed up something quick and dirty - will tidy that up and post when time allows.  Pachube provided their usual fast and very helpful answers to my questions about the new APIs on the forum.

To let the actuator switch 240VAC I used a ByeBye Standby socket and an AM Radio Tx chip.  This connects directly to the MBED with no other components required.

So my first demo is up and running.  Now what did I want this for? 

Practical Intro to MBED

Published on 22 Mar 2011 at 10:58 pm. No Comments.
Filed under Uncategorized.

Whilst Arduino is becoming a household word, MBED, it’s closest “rival” is not nearly as well known as yet.

Rather than use a shield approach MBED is a small DIL daughter-board with an ARM processor, a reasonable amount of RAM and flash and 0.1in pin spacing that conveniently slots into a breadboard. The IDE is cloud-based rather than downloadable. There are many libraries available, covering a range of peripheral devices and protocols. Much more detail here.

I was fortunate to attend a half-day briefing organised by the EKTN and led by Simon Ford of ARM. This allowed us to get our hands on a nice breadboarding kit for experimenters with the platform. Apart from Simon’s insights a key feature is an online cookbook with a lot of code examples which made it easy to get some quick results.

I have now done a few projects with the platform and am duly impressed with many aspects of the MBED approach.

So far, my issues have revolved around the libraries. Many of these are user-contributed and, while, mostly good enough for quick prototyping, leave much to be desired. The existence of multiple HTTPClient versions was problematic as there are several and they are not compatible. So if you find yourself using one and looking at the doc for another you are in a mess. In addition, the amount of doc varies. Some have good use case examples and others do not. At least there is a forum where you can (and I have) posted questions and observations.

The free-for-all approach that allows developers to share code and fork libraries is a two-edged sword. I reckon this could get out of control if the curation is not stepped up a notch.

I’m also aware that some people do not like the cloud-based compiler approach, preferring tool chains of their own choosing. Departing from the mainstream approach is entirely feasible for those willing to put in the effort.

Next step: investigate various prototyping boards and see whether this could beat Arduino on cost for small quantity applications. It certainly does have seem to have the edge on processing capability.

Smart Heating Control Continued

Published on 15 Mar 2011 at 8:53 am. No Comments.
Filed under Uncategorized.

As described in my last post we are pleased to have Telepure’s “Intuition” system installed and running well. It is now running with 5 sensors around the house and I get real-time reports so I can see what’s happening at a detailed level. My ongoing task is to adjust the targets so that we are not overheating the air or water. We have seen that the system hits these targets with precision and properly compensates for the external temperature.

I have raised several points relating to the interfaces both for end users and for “energy stalwarts” like me who want confidence that the automation is delivering the results we need. Being one of the few trialists means that I get a great response to questions and suggestions. Going forward, the company is talking about a user forum and this will allow a scaleable way of dealing with the likes of me.

So far I have mainly used still-protoype web interfaces to access the system because flaky phone coverage means I generally use (cable) Internet when at home. I also like my large screen for graphs etc. However, I will also evaluate the smartphone interfaces in due course. It was good that I was able to easily construct reports that showed the Intuition’s data and other real time data that I collect on that same graph.

As this system reaches market the company faces the acid test of whether people will buy the payback proposition. However, with all the data being collected, this should not be difficult. I am building up measurements so that I will be able to talk numbers in due course.

Trialling Smart Heating Controller

Published on 28 Feb 2011 at 6:19 pm. No Comments.
Filed under Uncategorized.

Readers will have seen many mentions of my dissatisfaction with conventional heating controls. Even recent installations are primitive and consequently wasteful of energy unless you are minded to adjust the controls *daily* to compensate for weather and occupancy patterns.

So I have been waiting to make some changes. If I could not buy the necessary kit I decided I would have to make it. This is less fun than making monitoring gadgets as in a family home it *has* to work.

When Passivsystems announced a relevant product I tried to get one. However, it was clear that this was not aimed at consumers as I could not get the basic information needed to decide on an investment of almost 1K.

Enter a new player, Telepure, with a device that is not on the market yet but is clearly aimed at consumers. After a few discussions with the founders of this UK startup I wanted one and was offered the opportunity to trial a pre-production model. Yesterday we got it installed and running, replacing the timers and thermostat I had before and utilising mostly existing wiring. The largest part of this task was to replace cables that were wrongly installed by “professionals”. We hackers want things done properly.

Results: too early to say. However, I can say that I have no second thoughts at the moment. Watch this space. Telepure are at Ecobuild this week.

Introductory Course on MBED

Published on 27 Jan 2011 at 11:33 pm. No Comments.
Filed under Uncategorized.

Went on this course earlier in the week, kindly sponsored by RS and organised by the ESP KTN. The concept was impressive and it all worked well (apart from a rather major oversight concerning internet access which, for this course, is essential).

My own interest is around the thought of where do we go when Arduino runs out of steam? It’s excellent for educational purposes but has a few limitations when you want to field-test prototypes. MBED looks like it could be the answer. This course looked like a way to get things moving.

The kits handed out include the MED dev module and a great little breadboarding kit from Cool Components.

The MBED IDE is online which has advantages. This is acknowledged not to suit people who want to configure their own tool-chains. Hoever, it’s just fine for the likes of me who just want to get on and build some protoypes.

Simon Ford of ARM presented the main part of the course (at RS premises). He certainly knows his stuff and kept us moving at a good pace. The course materials are online and contain loads of worked examples - important for a fast start.

Strongly recommended for anyone about to do their first MBED project. No need for in depth knowledge but C++ experience useful.

Since then have been looking at more robust prototyping options. Seem to be plenty available, eg from Cool Components.

« Previous Entries