Mobile Terminal


Many Factories and Production Facilities would benefit from linking their ERP/MRP or production system onto the factory floor where real time updates and status changes can save time and prevent data duplication.

For example at the Indevin ( winery in Blenheim, New Zealand who are a large and modern producer of wines and who are one of my biggest customers, have a typical job order system which communicates work to be done by the cellar hands. These job sheets are produced by winemakers in their office and printed and given out to the cellar hands by the cellar supervisors. The Supervisor assigns the work and signs the job on and off for QC purposes. The job sheets are returned to the winemakers to update stock and inventory systems and ultimately the financial systems.

Bar codes are used extensively to identify paperwork and assets such as barrels and tanks. Touch screen stations have been used for a long time but require cellar hands to write things down on their paper job orders and input the data once back to a touch station. Each cellar hand is allocated an RFID fob to authenticate themselves to the touch screen which generally uses a simple cut-down version of windows or Linux and and runs a custom program which will do the communications back to the main database on a MySQL server and print such things as labels if required.

Mobile systems have been trialled and are used:

  1. To update job order statuses real-time to the wine-making back-office staff.
  2. Communicate tank volumes directly into the job system and thus allow real-time inventory checks
  3. Update movements of barrels
  4. Check real-time statuses and inventory of vessels
  5. Re-Print labels, dispatch advices etc. as required
  6. etc.

Ideally every Cellar hand and every supervisor would be issued with one of these, however they are really expensive and generally out of the reach of smaller companies. Proper Industrial grade mobile terminals with bar-code scanners are very expensive, upwards of US$1000 and generally more (the Indevin ones are around US$2000). These generally run Windows CE or mobile or Android and have custom software written for whichever OS and application required.

If you break these devices (and rugged devices still break quite easily) the repair is generally in the high hundreds as are all spare parts such as batteries. Clever people have tried with various degrees of success to use cheap android touch screens but these have a lot of drawbacks:

  1. They are generally not ruggedised
  2. They do not have bar code scanners and RFID. Some people have tried to get cameras to read the bar code but it is rarely seamless or intuitive for operators.

  3. tablets generally have a production lifespan of 6 months to a year before they are replaced as are the spares which are generally not easy to find and end-of-life’d regularly
  4. The Operating system is also subject to updates which may or may not break the device.
  5. There is a lot of temptation to steal these for home use if they have other uses such as web browsing
  6. They have to be extensively locked down to prevent abuse such as private internet browsing or running games
  7. They do not have the correct drivers to use printers, label printers, SQL databases and therefore you are generally restricted to running it in a web browser to a remote server.

As well as this both types of system generally have almost no information on the hardware and firmware for them, in fact generally everything below the operating system layer is  Secret-Sauce which means your stuck with the operating system and once the manufacturer withdraws support you generally have no choice but to upgrade.

Small software houses generally cannot compete with the big boys on this, eg if your a small team providing factory production software to a dozen customers you may know your system inside out but be intimidated by the above steps to try and support mobile devices on your system.

Lets face it, you are still going to require some sort of interface to your particular ERP, MRP or Production System, and unless this is in-house, open source or you know the database structure well enough to write your own interface to it then you are still going to require the system provider or a third party (a person such as me) to do this, and nothing here is going to be of any use to you. However if you are that person, or you know how to program,  know the interfaces to your systems then having the full plans for a mobile device will give you all the tools to get a mobile data system up and running.

What will be documented on the rest of the pages will be an open source, ie the Free blueprints to design and program your own wireless bar-code scanner. In other words the last piece of the puzzle for a cheap wireless enabled barcode terminal. You will need to understand C and you will probably need some electronics and assembly knowledge as well as understanding (or having someone else who can understand) your production software.

Even if you have all this or once you’ve tasked someone else to write this they will still have a lot of obstacles to overcome and this is where we come in to provide a fully open source mobile scanner, everything will be off the shelf and have full technical documents.

The Design

Concept Overview

The design relies on the fact that very little processing takes place on the actual terminal, in this way we do not need any form of drivers for databases, printer etc.  we simply need a program (preferably a Windows service or Linux daemon which sits in the background and interprets very simple messages to and from the terminal and turns them into SQL and reports.

In order to be useful the terminal must have a very low cost to produce, so the first and primary goal is to ensure the bill of materials (BOM) for each complete terminal system  will be under US$100.

The BOM cost for the first prototype is actually around US$80 due to sourcing some new but very cheap end of life bar-code scanner engines off eBay.

Everything is provided here for you to make the hardware or outsource them to be made, these include the schematics, PCB layouts, Gerber and CAM files if you want to order the PCB’s from your preferred supplier. These are provided without restriction. You can build and on-sell completed units if required.

Note that none of this will be useful unless you have information on you production system and can write an interface to it.

To summarise..


  1. Low cost per unit means you can have 10 units instead of 1
  2. Infinitely customisable, build the exact mobile for your requirement
  3. Nothing to go wrong, no operating system means instant on and nothing to distract the operator from their job.
  4. Complete open sourced documentation and schematics for hardware
  5. Mechanical drawings for basic cases which should help make the units a bit more professional. (currently I’m a CAD/CAM noobie so pictures and sketches may have to suffice until I’m better skilled)
  6. Open source libraries for a C programmer to easily get started on
  7. Manufacturers documentation for all hardware on the BOM
  8. Free Development environment
  9. Upgrade path for obsolete hardware if required.
  10. Lowest cost replacement parts, buy them direct and fit them yourself
  11. Good battery life. (I hope!) One of the stretch goals of the project is to reduce the power consumption to get several days use out of it, the first version should be easily good for a day or two
  12. Potential increase functionality and/or lower costs further as improvements to hardware and software occur.
  13. There are no restrictions on reselling any hardware, software or systems you create, though we do expect you to provide full documentation for any specific changes to hardware


  1. You will probably need to build it yourself. Early adopters please note!
  2. Support. This is the big one, you will need to RTFM and do it yourself or pay someone else to do it (it should be quite easy though, see point 3 above)
  3. You will still need to understand and be able to interface to your current production system. If you or someone you know cannot write an interface to it now don’t expect to be able to get anything useful from this project.
  4. Its still in design and nowhere near completion

This is also going to be a learning curve for me, while I’m pretty experienced in these matters there are quite a few areas I’ve never practically applied before such as very low power management which will mean I may go through a few iterations to get things right.

So why am I open sourcing this? For the simple reason that it might help others and importantly gives my clients confidence that if for any reason I cannot support them, all the information is available for another to take over the project or enhance it with the minimal of fuss.