Proving once again why it pays to keep it simple

The best solution to any problem is almost always the simplest.

Scanning a barcode

When Aston Barclay, one of the country’s largest car auction houses, asked us to update the technology that underpinned its systems, it set us an interesting side task. It needed a reliable means of tracking every vehicle from the point it rolled off a low loader until its new owner drove it home.
We settled on one of the most simple technologies out there: barcodes.

Aston Barclay’s four sites each have blanket Wi-Fi, covering their buildings and the marshalling yards where they store the lots for each auction. Mindful of using this to our advantage, we set up a network of inexpensive scanners. Effectively low-end smartphones in waterproof cases, we used them to capture linear barcodes stuck to each vehicle’s windscreen.

Linear barcodes, like the ones you find on supermarket foods, are less intelligent than their square QR cousins. While sticking to alpha-numerics lets you store up to 4000 characters in a QR block, linear codes are nothing but serial numbers, which in this instance was all that Aston Barclay needed. Every time a member of staff scanned the code on a vehicle’s windscreen, it retrieved the matching data out of Aston Barclay’s transactional database to reveal who was selling, who was buying, its spec and its status.

Not only simple, but practical, too

Yet the relatively simple implementation wasn’t the only reason we opted for a linear system rather than QR codes. There is also the question of practicality.

When you try and pack too much information into a barcode, you’re cutting down your hardware options. Resolution doesn’t really matter, but reading a QR code with any degree of accuracy does demand a better lens and the ability to focus from less than a metre away. That puts some older devices, such as early iPads, and many low-end smartphones out of the equation. It’s also possible to read linear barcodes with a laser scanner, linked to a smartphone by Bluetooth, for maximum reliability in poor lighting.

Further, as they are more than just a serial number, you can’t buy in QR codes the way you can with a roll of linear barcodes, which means Aston Barclay would have needed to invest in software to generate its own, and label printers to produce them.

So, while it may have been hooking into a far larger, more complex system, this relatively simple integration enormously extended Aston Barclay’s stock control, proving conclusively that the most technically-advanced solution isn’t always the most appropriate, and that what would once have cost several thousand pounds to implement can now be achieved for just a few hundred.

To find out how Humboldt Solution can help you simplify your workflow and manage your inventory more effectively, call us on 01276 415787 or email

Tech is coming full circle – and that’s a good thing

Fashion is cyclical – and so is technology.

Humboldt Solutions’ roots go back more than twenty years, to a time before widespread broadband, solid-state hard drives and almost unlimited memory. As experts in low-powered computing, we specialised in building compact devices with conservative specs that would run and run, sometimes without intervention, for years.

We are still doing that, and with the world finally catching up, we are able to apply our two decades of expertise to a whole new generation of smaller, friendlier, more efficient products.

Miniaturisation for the masses

You might recognise a Raspberry Pi, but you may not notice how much it has changed since its initial incarnation.

When it first appeared, it was lacking a number of fundamentals. Most obviously, it didn’t have any mounting holes to screw it into a case. The developers probably didn’t think there was any need, but with hindsight we can see that they got it wrong.

Customers, who were increasingly using the Pi as the basis of larger, more ambitious projects, started to improvise clamps that would fix it into a shell. The Raspberry Pi Foundation spotted what was happening and responded by incorporating mounting holes in the second and subsequent editions. It also moved from full-size SD cards, which protruded from the motherboard and could be shaken out, to micro SD cards, which are locked in place.

So, as they worked on evolving the board, they also made it easier to build it into something else, and went on to produce models like the Pi Compute and Pi Zero, which are designed specifically to be used as the starting point of a larger integrated device.

The Foundation has achieved an awful lot in a very short time, but to my mind, one of its most admirable accomplishments is bringing a new level of acceptance to the idea of low-powered computing. Mainstream interest in the ability to produce single-task computers using miniature motherboards like the Raspberry Pi is an exciting advance, which should result in lower costs and less obsolescence across the industry. Ultimately that will have an environmental pay-back, too.

Ultra-small, ultra-inexpensive devices

We use the Raspberry Pi platform for building prototypes, and in a recent example, attached one to a client’s network so it could remotely monitor and send back diagnostic reports for in-depth analysis. The Pi, including its case and power source, is so small that it could continue working unobtrusively for as long as necessary without ever getting in the client’s way or interrupting their ongoing work.

Yet the Raspberry Pi is a full Linux-based system, and in some cases even this might be overkill – particularly when you can get even smaller modules, with built in Wi-Fi, a handful of interfaces and the ability to load your own software, for less than £5.

Called Arduino in the UK and US, and Genuino elsewhere, these logic boards support just a few kilobytes of usable memory, and as such they hark back to the earliest days of home computing. The key difference, though, is their dimensions. At around half the size of a Raspberry Pi and capable of running off a button battery for several months, they are many times smaller than a computer of equivalent power from the days of Humboldt’s founding, which makes them an even better starting point for a bespoke, single-use project.

History repeating

Having seen embedded technology go through a period of growth (and, some might say, bloat), components like the Arduino seem to be completing the circle.

This renewed focus on low power computing is particularly exciting, as for years the rule has been that the smaller a device is, the more it costs. That is because manufacturers have been focused on shrinking down the whole package in each instance, rather than just a subset of its features.

By looking to strip away unnecessary specs while shrinking the host components, the companies producing these simple starting points are enabling a far wider range of projects than ever before. They are also accelerating the development process by saving us, and others, starting from scratch each time.
Our experience of working within the constraints of these diminutive devices, while maximising the possibilities of their conservative features, is allowing us to satisfy our clients’ demands more quickly and at more competitive prices than ever before. That’s why they, not us, are the real beneficiaries of the low powered computer revolution.

Are you struggling to adapt bloated, off-the-shelf hardware to perform relatively simple jobs? Find out how you can do it more cheaply while being kinder to the environment by switching to a low-powered alternative. Call Humboldt Solutions today on 01276 415787 or email

Five questions to ask your Internet of Things contractor

The Internet of Things (IoT) is trending right now, but it isn’t actually new. At Humboldt Solutions, we’ve been designing always-on, always connected hardware for years. The only thing that’s changed is that it now has a catchy name – and with a catchy name comes interest from the consumer space.

This is both good news and bad, for while greater visibility will encourage innovation, the kind of IoT devices you find on the high street are poorly thought-out and woefully supported. A lack of uniformity means you can rarely mix hardware from different manufacturers and security is normally lax, with the same simple password rolled out to a whole batch of products.

Worse, the sector is built on a trust that hasn’t yet been earned. When you take home a consumer device, the first thing it does is talk to its developer’s server. Only if the server stays on line will your hardware be happy. Bear this in mind as you consider how short an outlook most of these companies have – and the fact that many are still burning venture capital with little idea of when, or even if, they’re going to turn a profit.

If that’s left you asking where the positives lie, look to the business space where IoT-like systems have been around for years – without the fancy marketing and unfulfilled promises. Some of our own implementations have been running unattended for a decade or more, and each is fully documented so our clients know that in the unlikely event we disappear, the service will continue.

Before you draw up plans for your own IoT device, be sure your contractor can answer these questions before you go any further.

1. How will it connect back to base?

Make sure your supplier has a clear idea of how the network will work. Ask whether they see it involving a lot of direct connections, or a hub that links each device and acts as a gateway to the net. What are their inventory management plans? You need to know what you’ve got on the network, where it is and how you address it if you’re going to upgrade, control or download data from a specific device on demand.

2. What hardware should I be using?

There’s a reason why we’ve put this second: it’s important, but doesn’t outweigh the fundamentals issues of connections and comms. At the same time, what you need your hardware to do is more important than how it does it, and you can now achieve a lot with a simple off-the-shelf chip on a board. Integrated units that include a sensor, switch and processor cost a couple of dollars apiece and although they aren’t as powerful as the diminutive Raspberry Pi, they’re the perfect solution to remotely controlling something simple, like a value in a pumping station.

3. Is redundancy really an issue?

Installing a backup system increases your costs, so ask your supplier to perform a cost-benefit analysis before they recommend on-site redundancy. Only then will you know for sure whether you’d do better to leave a failed unit in situ until someone can attend it in person for repair or replacement. Often, it’s more important to consider backup systems for the control unit and servers than your remote devices, as if they fail the whole system goes dark.

4. Where will the system be hosted?

Be wary if your supplier will only countenance using their own servers. That will lock you in to using their services for as long as the system is running – often at cost. If you don’t want to use your own infrastructure, ask your contractor about cloud hosting. AWS (Amazon Web Services) is approaching ubiquity in this area, with many providers choosing to employ Amazon’s high-speed, high-capacity rented cloud service as the conduit over which industrial IoT hardware gathers and transmits data.

5. How will you manage issues that arise during its working life?

It’s not only hardware that has an expected service lifetime: software becomes prone to vulnerabilities over time, and security certificates almost always expire after a specified period. This can be as little as five years, which may be considerably less than the hardware’s anticipated service window. When this happens, it can put your whole system out of action. Ask your supplier both how you’ll monitor the firmware on each device, and how you can keep an accurate inventory of certificates and the dates they’re set to expire.

Humboldt Solutions has been developing for the ‘Internet of Things’ since before it even existed. Call us on 01276 415787 or email to discuss how IoT can work for your business, your clients and their customers.

Humboldt Solutions is helping its clients keep their systems patched and secure with regular, remote updates

One of the first things we ask a client when we’re designing a bespoke system is how it’s going to be maintained. Vulnerabilities can and do arise over time, requirements change, new features need to be added, and often these factors can only be addressed without direct access to the hardware we’re putting together.

At Humboldt Solutions, we have years of experience when it comes to rolling out timely updates on all manner of systems – and the way we do it, as you’ll see here, guarantees a swift response and the absolute minimum downtime.

Building for the future

Many of our clients need bespoke hardware for use in specific locations. Whether they’re data uplinks for media use or control systems for public utilities, they are often installed in secured premises to which staff have limited access. In environments like these, accessing them remotely is usually the only practical means of keeping them up to date.

This has become a more realistic proposition over the last two decades, with the roll-out, first, of reliable dial-up connections, and latterly of near-universal always-on broadband.

But these are far from the only options.

Satellite-connected devices, the best known of which are television set-top boxes, can be set to listen for updates around the clock. Where this isn’t practical, or where a device has no need of a satellite connection, we can instead integrate a wireless data link using a private 3G or 4G network.

Private mobile networks offer a secure alternative to sending data over public services by connecting directly to a company’s in house systems. The two-way connection allows the device in which it’s installed to initiate a call back to base to check for available updates, or for a base station to dial in as soon as a patch is ready.

Predictable, stable platform designs

We can deploy any operating system on the devices we build, but our preferred solution – as implemented in the majority of our hardware – is a custom Linux system running on components that have been chosen specifically for the length of their projected service life and slow, predictable evolution.

By only sourcing components that we know will be supported by their original manufacturers, often for ten years or more, we can be sure that should a system require a repair we’ll be able to source appropriate spares and keep downtime to a minimum.

Further, rolling out a tailored operating system means we can exclude any packages that aren’t required for the task at hand. Not only does this reduce the risk of the system being compromised, and the number of patches that need to be applied over time; it also means that when we next need to intervene we can say with absolute certainty how the new software will work with what’s already running on that system – and on any other devices that connect to it.

Remote upgrades in the real world

We maintain a closed-box satellite uplink service for a UK-based data distributor, which seeds local broadcasters with text files, audio samples and interviews for adding context to the bulletins they put together in-house. The system has been running hands-off for several years, and in the last month we rolled out its first major update in a decade.

This was done remotely, without physical access to either the base station or the reception points, which are white label PC systems located in radio stations around the country. Due to the nature of the business, the updates had to be conducted in such a way that they wouldn’t interrupt any station’s output, which meant timing them to fit between regular transmissions.

By administering the update from a central location, local station staff didn’t need to play any part themselves, while the savings made through not dispatching engineers to work on site greatly reduced the cost of the operation overall.

As far as the listener was concerned – and, in many cases, those who worked with the systems that were being updated – nothing had changed, and although it will likely be many more years before the next major intervention will be required, our clients enjoy the peace of mind of knowing that a quick, off-site fix can be applied should any issues arise.

If you’re planning a new project, or you need to upgrade your existing infrastructure to handle remote patches, call Humboldt Solutions on 01276 415 768, or email to discuss how we can simplify your ongoing systems maintenance.

How Tailored Tech Can Save You Time

PCs are now so versatile that there’s very little they can’t do. Whether you’re streaming 4K video or controlling the pumps of a treatment plant, off-the-shelf PCs can be the quickest, simplest solution. The key to making them the focus of your project is tailoring the software they run.

By rolling tailored operating systems onto white-label boxes designed to meet a client’s specific requirements, we’ve been producing tightly-focused kit for years. It is less expensive and less involved than you might imagine.

The process

It all starts with a business plan. Before you commission a bespoke system, you need to know what you want to get out of it and, crucially, how it’s going to be powered. This will often be determined by the way it’s going to be used.

Fixed-location appliances, such as controls for utilities, are usually the cheapest, simplest projects, as less time needs to be spent on miniaturisation and paring down power consumption.

Portable hardware, such as boxes for streaming live events, is moved from site to site and only powered when in use. Although some miniaturisation may be necessary to make them easier to transport, they are still powered through the mains.

In either case, we use mainstream kit wherever possible – so-called COTS, Commercial Off The Shelf – specifically choosing components with a long roadmap and slow, plotted evolution. This way we can guarantee your bespoke hardware the longest possible working life and we will be able to start work on the initial design and build more quickly.

Software considerations

Once the hardware spec has been finalised, we can focus on the software, where our preferred approach would be to produce a customised Linux distribution. This way, we maintain full control of the manufacturing process, know exactly what’s running on the system and can be sure it’s properly licensed.

We’ll pare down the code to remove any unnecessary features that aren’t required and may pose a security risk. Then we provide a custom installer for the manufacturing process, which puts exactly the right software onto the box.

The benefits of working this way don’t only apply during the initial build, though. By keeping focus on the exact make-up of the software, we can more easily diagnose potential problems, implement updates and devise a field upgrade process that can be performed remotely to minimise downtime once the equipment is live. The result is a reliable, stable, tailored box that can automate repetitive tasks or become the hub of your whole operation.

By pairing off-the-shelf industrialised systems with customised software, we keep control of the project spec, guaranteeing stability without incurring the risks and costs of undertaking a custom hardware design.

Are you running your systems on mainstream, consumer hardware? Call us today on 01276 415787 or email to see how a tailored device could save you time and money.

Flexibility is at the core of what we do

In our previous post we outlined the steps involved in setting up a new project, from first discussions to signing off on a Statement of Work. These can take from a couple of weeks to a month or more to complete – it all depends how clearly you’ve worked through your plans, and whether you need us to help you define the ultimate goal.

Running a preparatory project

If we’re working to a fixed price, it’s important that the end goal is clear. It will sometimes therefore be necessary to commission a preparatory project that will explore the problem, process and proposed solution in greater depth. As part of this groundwork we’ll be able to outline the steps involved and ensure you’re happy with our quote.

This will take place – and be billed for – separately from the main work, and you have the option not to proceed once the preparatory process is complete should your needs change or you feel the project needs to be reassessed.
Alternatively, we can place the larger project on hold at this point, giving you time for more in-depth internal discussions. We’ll happy to revisit it whenever you’re ready.

Two-way feedback

Once the primary project is underway we’ll keep you involved at every step. You’ll receive regular updates, and if we’re working on software or reshaping a business process for you we’ll ship interim builds for testing at agreed intervals or when we reach a milestone.

Naturally we’ll test the product locally first, for which we may need access to your own systems or a copy of your data. We prefer to use anonymised resources wherever possible and will happily work with dummy data sets if you are able to provide them.

Where the finished product is designed to interface with a third-party product or service, we can deal directly with the appropriate providers on your behalf, subject to your authorisation.

Alternatively, should you prefer for security or other reasons, we can hand over responsibility for the initial testing to yourselves, but this would require an advanced in-house test set-up and reverse liaison, in which you would feed back to us on any changes that are required. Naturally this process would need to be established at the outset.

Ongoing support

If we’re working to a fixed price we’ll have agreed the terms on which the project will be considered complete prior to the start of work. For an agile project, on the other hand, in which the ultimate goal will evolve as the work progresses, it will be up to you how long you retain our services.

In either case, the initial statement of work can optionally include a monthly baseline fee for which we will provide a defined level of support at completion, plus agreed pricing for additional work as and when needed. It’s useful to consider this in the initial stages as it allows you to allocate a realistic budget within your interim or annual accounts.
Ongoing support will often include a specified number of incidents on top of bug fixes. These are provided in addition to our assistance in rolling out the software or hardware and fixing any initial issues that present themselves in the first few days of testing.

Longer term, we can help you deal with larger system updates – including changes to your operating system. Much of our software and many of our interfaces are written to run on Linux, and we may also use a bespoke Linux distribution for our hardware builds. We will strip this down prior to installation, both to guarantee that there will be no conflicts, and so that we can more effectively identify when changes are required over time.

A tried and tested routine

We’ve been working in the fields of hardware and software engineering for 20 years, and refined our processes in response to customer feedback. Our clients include some of the biggest names in broadcasting, electronics and business solutions. See our testimonials page to read more about their experiences of working with Humboldt Solutions.

We pride ourselves on making the process of defining, agreeing and running a project as pain-free as possible. To learn more about how we can develop your ideas together, call 01276 415787 or email

How we make it easy for you to work with Humboldt Solutions

We pride ourselves on always being open and approachable, avoiding jargon while helping clients resolve technical issues within their organisations. If you haven’t worked with us before, you may be surprised how easy it is.

Beginning with the basics

We can start with as little as an outline – an idea of a single pain point that hardware, software or automation can fix. If you have a fleshed-out working document, we’re happy to use that to guide our initial discussions, but it is by no means a requirement.

We aren’t business improvement consultants, so we’re not here to look at your overall organisation and pick out the part that’s failing. What we will do, though, is help you identify which of the problems you’ve highlighted can be solved through the application of our expertise.

All we need at the outset, then, is a fairly broad brief, which we’ll work on together until we’ve agreed on an outcome.

What kind of projects do we work on?

We’re an automation and integration specialist working in broadcast, electronics and business solutions. Our clients include the British Forces Broadcasting Service, Arqiva, and Royal Holloway University, for whom we produce a mix of bespoke hardware, and software interfaces for existing third-party products.

You’ll find further details in our case studies.

Agreeing on a price

We can work on a fixed fee basis, or adopt an agile pricing strategy. How you prefer to be billed affects more than just the overall price, though: it also determines the project’s day-to-day running.

Working to a fixed fee can give you the peace of mind, as it means we’ll deliver a finished product by a set date while working within your budget. We guarantee that any project developed this way will satisfy what you asked for – so long as you’re sure from the outset what you want to achieve. We can also work on an initial side project to clarify those needs should you require it, and this will help to determine the overall price.

It’s possible to negotiate changes during the development process, but if you’re unsure of the outcome you’re after, we would recommend opting for agile pricing instead. We also also recommend considering an agile approach if the project is set to run for a longer period – six months or more, for example – in which case changes within the market and other external factors may require that we re-assess the original project goals.

Agile pricing for agile projects

The fixed-price model works well for developing hardware and smaller, tightly-defined projects, but agile pricing is more appropriate when developing business processes that evolve as they’re refined.

In this instance we would work in a series of short cycles, each of which would allow us to adjust the working document every time we deliver a new feature that brings you closer to your goal.

Working this way will be a little more demanding of your time because we’ll need you to engage with each iteration, and it also means that while we’ll be able to set a date for finishing, the desired features can be less clearly defined at the outset. This is a benefit, as it means that you’re guaranteed to get what you need, rather than just what you’ve asked for, as the view of the finished product becomes clearer over time.

Signing off and starting work

Once we’ve agreed on a specification we’ll draw up a Statement of Work. This is a one-page summary of the detailed outline, which defines agreed milestones on a fixed price project, and interim handover points when working on an agile basis.

For an agile project, the specification that accompanies the Statement of Work will be a versioned document that tracks each change to the project spec. This way, we can roll back to see who implemented an amendment and understand the rationale.

By this point, with a detailed brief to work towards, and agreed milestones or targets, we’ll be ready to start work on your project. Naturally we’ll keep the channels of communication open between your organisation and our development team, and we’d recommend that you assign a single staff member to handle this important task.

In the next post, we’ll follow the project through to completion. If this has helped you to identify an area where we can help to advance your business, call us on 01276 415787 or email

How we helped a client get more from its data, for less

Flexible, accessible data is key to running an agile business. Re-using it wherever possible, in as many different ways as you can, is the smartest way to turn a profit while keeping your customers happy.

The real challenge comes when you need to link your online records with a real-world operation, as one of our clients did at the end of 2015.

Its website was underpinned by cache of customer records, product descriptions and transaction details, all of which needed to be accessible, both online and in person. Added to this was the fact that the same system had to update – in real time – in response to a series of fast-moving auctions, in which customers could bid both in person at the auction house, and from home through a browser.

Our client tasked us with coding a background application that would open up the data while complying with its established business rules and keeping its customers’ private details safe.
This is how we did it.

The Problem

Our client is one of the UK’s biggest car auction houses, and having worked with it for years, we already understood the way its data was structured. We used that as a starting-point, and identified the issues it was facing:

  • It needed a new customer-accessible website, populated with fresh catalogue data drawn down from an in-house system.
  • It didn’t want to give web developers access to the core data to protect customers’ private details.
  • Earlier attempts to link the website to the database had introduced inefficient queries, which had slowed it down.
  • For the in-house team, the fact that external agents had access to the data constrained them in that, to make any changes, they would need to synchronise their amendments with multiple interested parties.

The fix

It was obvious from the start that the core data was the company’s primary asset, yet the route it was accessed was proving to be a serious pinch point. Because anyone who could draw on it was only ever presented with a set of raw results, it was up to them to work out how they could translate the output into understandable, useful content for the web, showroom catalogues, live bidding systems and so on.

Each developer worked on its own implementation, often overloading the database with more requests than were strictly necessary, and repeating work that someone else had already done elsewhere in a different content. Combined, it was an inefficient drain on both time and resources.

It soon became clear that the answer was to create a bespoke API (application program interface) to sit between the data and the client’s out-of-house developers. Doing so meant we could shift responsibility for a lot of the leg-work to the server itself, which would output fully-formed answers, ready for immediate use in any format and any media while fielding fewer incoming queries.

Further, because the API acted like a digital clean room between the developers and our client’s key asset – its data – it was easy to keep a handle on what was, and wasn’t, made public. Private data, such as customers’ pricing details, past sales and so on, was quarantined, and that freed up our client to provide the API and associated documentation to any third parties who wanted to produce their own bolt-on applications.
The data was now more flexible and more valuable than ever.

The future

It took us no more than a couple of weeks to get an initial draft spec written up, and we had a prototype ready within a month of start of starting work. We iterated it several times based on developers’ feature requests in the run-up to making it live at the end of March.

By limiting the number of routes into the client’s database, we’ve reinvented how it works with – and gives access to – its data. The API itself runs as a completely stand-alone process that can be started and stopped without affecting existing business systems, and it finally gives the in-house team freedom to work on the data without reference to third-parties.

Better yet, it’s more efficient than the system it’s set to replace. That’s allowed us to offload the database, processes and websites onto a series of lighter-weight Amazon servers, which together provide a higher degree of fault tolerance – not to mention a significant cost-saving.

Are you facing similar issues? Call us today on 01276 415787 or email and let’s talk about how we can help you make the most of your data.

MDev_Reader app for those suffering with macular degeneration now available on Android platform

Following a successful project where Humboldt worked with a team at Royal Holloway University to build an app to help those suffering with macular degeneration to read text on an iPad, the company has just completed its second part of the project, an app for the Android platform.

Macular degeneration is a painless eye condition that leads to the gradual loss of central vision. Central vision is used to see what is directly in front of you, when reading or watching television for example. For those suffering with macular degeneration, the central vision becomes increasingly blurred leading to symptoms including difficulty reading printed or written text because it appears blurry, with less vibrant colours.

The original and new app has been designed to test ‘eccentric viewing’, which scrolls the text at a steady pace through the reader’s peripheral vision, enabling those with macular degeneration to read text. The app, which is free and now available for both Android and iPad, lets readers read text from an eBook (or any ePub document) to be scrolled in a single line, much like a news ticker tape. Users can adjust the speed of scrolling using the track pad to find a comfortable reading speed on the screen that suits them.

The app also means users can change text size, text colour and background colours as well as the speed of scrolling. It also includes a movable fixation point on the screen to help people to use their best point of vision. Text can also be scrolled backwards as well as forwards, so if a word is missed, the user can scroll backwards to recap. There is also a screen with a menu of all readable books and documents that is searchable.

To install the App, users will need a Google Play account. Once this has been set up, search for MDev_Reader on Google Play and follow the on screen instructions to download and install the app.

The Macular Society relies on donations and gifts to deliver its services and search for a cure for macular disease. To help people with central vision loss by making a donation visit their website at

For more information about eccentric viewing and steady eye, contact the Macular Society on 0300 30 30 111 or look at the website:

Know what you ship

If you’re planning to build any networked device, it’s likely to be an embedded Linux system. And using a kit from a board vendor makes it easy to start developing the system.  However, these packages rarely take you all the way to a polished commercial product.

In most cases the board vendor will supply a root filesystem and a compiler. This provides everything you need to boot a working Linux system and write your application. You’ll soon have a build process for your application, and shell scripts to run it when the device is turned on. It’s also easy to copy your application into a filesystem image, and program each device you manufacture.

But the filesystem will contain two risks. First, if you don’t know every package it contains, you won’t be able to tell whether the next major vulnerability, such as heartbleed, will affect your device.

Secondly, if you don’t know the contents, you’re probably shipping software under GPL licence.  Under the terms of the licence you need to offer your customers the GPL software source code, or you cannot distribute it. Take a look at this comprehensive guide, compiled by The Software Freedom Law Center, for more information on compliance.

The key message from this guidance is, you need to have the source code for the exact version of every GPL component before somebody asks for it. If you leave it too late, you may not be able to get the code from your vendor. For instance, how much do you trust that two years later they will still be able to provide the source you built your product on?

You also need to provide the correct version of source code for each version of device firmware you ship.

There are two good ways to make sure you know what you ship. Either base your product on a Linux distribution such as Debian, or build from scratch with a system such as Yocto.

Linux distribution solves the problem by providing a package manager that can find the source for every module in the filesystem and archive it for you. The embedded build system compiles everything from source code, guaranteeing the code you have is the correct version.

Finally, there’s a lot of value in taking human error out of the process. So, you may want to consider a fully automated build process that builds both your application and the complete operating system image.

Automated build avoids shipping a corrupt firmware version on the one day somebody mistypes. It also ensures that when your developers test a bug fix, they are testing the same system the end users will receive.

And it avoids depending on one developer and a single PC as the source of all builds. Because let’s face it, one day the developer will leave or the hard disk will fail!