This project is submitted for

Description

I started this project at the end of 2013 as some of my clients would really like to deploy data collection terminals into their factory to allow real time data collection but are put off by the relatively high cost of the hardware.

The project simplifies the system to produce a modular battery powered device for under $100 it achieves it by offloading hard processing from the terminal onto the server and thus can use a lower cost processor and minimal parts.

Project has changed over the revisions and now uses the 13Mhz RC522 RFID card. Hardware is 100% complete, tested and working, firmware and example software on github.

My Newest version of this uses LoRa, 125Khz RFID, a smaller 8-bit processor and a slightly simpler design and achieves several weeks of normal battery life. It is on my website I will probably publish it as a complete project once I get the back-end software working.

Details

Anything that requires data capture (RFID, barcode or numeric input) shops, warehouses and factories are good environments for this.

Specifically?

Well since you ask, almost every factory and Production Facility in the world from large to small would benefit from extending their office production system onto the factory floor where real time updates and status changes can save time on QC checking and prevent data duplication.

For example at my customers winery in New Zealand, job sheets are written and printed by the winemakers in their office and given out to the supervisors. Supervisors then assign the work to an operator and signs the job on and off for QC purposes. The job sheets are usually hand written on with tank levels and additions made etc and then returned to the winemakers to update stock and inventory systems and ultimately the financial systems. Bar codes and RFID tags are used extensively to identify paperwork and assets such as barrels and tanks, but they are not utilised as much as they could be to prevent errors.

In an ideal system every operator and every supervisor would be issued with a data collection terminal so in our winery example:

The operator scans the job barcode to check the job is still the correct status, as this is real time the office staff can un-issue the job and prevent it going any further.

If the job is OK the operator can then scan the tank or barrel RFID/Barcode and the system will confirm they have the correct tank, this will provide a padlock unlock code to them

Connecting pipes between tanks are used for transfers and are barcoded, these can be scanned to ensure the correct path is in place before transferring wines

Additives to be added to tanks are in barcoded bags, these can also be scanned before the padlock codes are issued

The tank levels at the end of the job can be entered in real time.

Each terminal also knows who its user is as it is activated and assigned from the office, so each issued terminal can have a different set of permissions or programs, eg a normal operator can have a different program to a lab technician who will be able to enter temperatures or analysis results.

Similarly in the storeroom and warehouse the storeman could scan the product barcodes and real time enter new stock counts.

Note this wont be a finished project in the way others may be, simply for the reason that any final software and firmware will need to be highly customised to the system it will be used on, it will be a fully developed hardware system with a set of simple demonstrations on how it will connect to one of my clients systems, specifically to show everyone out there that none of this stuff is rocket-science and to give others the confidence to attempt it.

The thing that has stopped this is current barcode enabled data terminals have been really expensive and cheap ones poorly documented, Proper Industrial grade mobile terminals with bar-code scanners are upwards of US$1000, they 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:

They are generally not ruggedised

Most do not have bar code scanners and RFID. Some people have tried to get cameras to read the barcode but it is rarely seamless or intuitive for operators.

Tablets/Phones 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

The Operating system is also subject to updates which may or may not break the device.

Project Logs

The firmware is simply all the hardware parts working with a simple menu to scan barcodes, scan RFID tags and do some basic wifi comms which should be enough for you guys to run with.

The development from this point on gets very specific to my clients manufacturing and operational requirements and it wont really make much sense to publish it, it is not that I don't want to it is just that the MRP program it is interfacing to is like most production software not open source and not publicly documented.

There are several paths open to people who want to build on this project, I am thinking that the most suitable if you do not want to build your own server is to use one of the many MQTT implementations, the ESP8266 has several flavours of client for this and lots of back-end broker services are documented using it.

I am in the process of writing an open MRP system for another client, however this has a very open ended timetable as other projects allow, I will be porting the data collection terminal to it sometime down the line though if people want to keep updated via my web-site.

The final version of the hardware using the new RFID card is now working. Circuit and PCB are available on the EasyEDA site

Last minute changes include using filter glass to enhance the performance of the bar-code scanner, I tried both samples of commercial filter glass ($4 a piece!) but the red transparent films used for hobby and crafts you get off eBay seem to do just as good a job (I cannot measure the filter but I guess it hits that 625nm sweet spot for the CCD just as sweet. I have also updated the MPU to the PIC32MX250 as there are some USB boot loaders already available for this.

The RC522 RFID chip already has some public domain C++ libraries and seems easy to use (though a bit complex for what I need) with the move to 13Mhz I can now program the SSID, password and encryption keys directly into the RFID tags so security is as good as it gets and much better than I actually require due to other factors.

First unit is still a collection of drivers and test procedures which I will eventually put on git hub (I don't really use git-hub properly. one day I will get around to learning it but for now its a place to throw releases when I think I've hit a milestone)

Pictures below.

First picture showing the unit with the RFID card fitted. The ESP-01 module is right at the bottom and under the main PCB, bar-code reader is about 1cm from antenna but does not seem to affect performance.

Second picture (above) is with the RFID removed exposing the guts of the unit. ESP-01 module can be seen flush with top of case (PCB is screwed to top of case with LCD mounted on the back)

Last picture

I am getting some cases cut in black ABS, the grey is so 1980's in most peoples opinion! The window is actually more orange but it filters some of the flash colour.

Note all the parts work and have been tested individually, the next step is finish off programming and to get 30 boards assembled and into the hands of my hopefully eager users!

Just as I get the prototype working, we have decided to move from the 125khz EM4100 RFID to the 13.7Mhz Mitac RFID standard. the reason is two fold

We wanted to simplify configuration and improve security by having the SSID, password and host in the tag as opposed to three different bar-codes and also have part of the encryption key in the RFID tag. That means one swipe of the tag can configure the terminal. The RFID tags have 700bytes of storage will be secret sauce though)

The main client is moving to this standard and away from EM4100

There is actually a plus to this in that you can get per-assembled RFID readers for about $3 (I actually just bought 50 RC522 readers off aliexpress for $132 including delivery - how do they even do that!) the new readers are SPI bus and there are loads of libraries already available in the Arduino community.

5 of the new PCB's are being made and hand assembled at smart-prototyping at a cost of $40 each should have them returned in a week or two.

I have also ordered some filter glass as opposed to the plain glass, this should improve the performance of the bar-code reader and block out the inside PCB to pesky users, should also make it all look a bit more professional.

All the changes will require a fairly big re-write so while I am about it I am also going to try and get the USB boot-loader working, there is code for the AVR dude programmer and PIC32/Chipkit system which I am hoping to be able to modify.

This is my busiest time of the year supporting several wineries during their vintage, it is now coming to an end and should give the time I need to finish everything.

Note the PCB and schematic have been updated to this new version of RFID, the previous version is still available if you search my projects on EasyEDA

The only bad news for me is that using a single 14500 3.7V 1200mAH AA battery instead of 2xHiMH batteries will effectively half the battery life (probably less as popular opinion seems to say these type of batteries exaggerate their mAH figures by about 50%) , though I'm happily still getting several days use during my testing, As I have effectively had the cases already made I am restricted to using an AA sized battery for this version, shame as there are some nice 2000mAH ones out there for less.

Picture below of the prototype, as you can see it is very low density and I have widened the spacings between most components to make it more hand solder friendly.

The wires sticking out are the ICSP programming cable which wont be in the normal version, luckily they fold under the battery cover for testing.

The ESP-01 (ESP8266) module fits perfectly at the top, away from all obstructions. the reason I chose the ESP-01 over the SMT versions of it was because I can program and test the firmware and module before soldering as my opinion of the quality of this unit is still not 100% I am using the V0.9.5.0 firmware which has V2.0 AT Command set. I will put this firmware bin file along with the documentation and on github once I'm happy it is at least as stable as the previous version.

Also note that as we power on the ESP8266 only to send queries we have to wait for the connection to establish each time so there is about a 2-4 second pause before the query can get processed (the SQL part to run several queries and return the results only takes 100mS or so) this is not really that noticeable to the user and has many advantages for me as it completely removes power to the ESP8266 effectively starting from a power on reset each time so we shouldn't get any cumulative stability problems introduced and power consumption is nil when we are not communicating. Same goes for the barcode scanner.

I have cut away a side hole for the USB connector which is a little messy.

Note there is a big whoops as I must have used the new sandbox version of EasyEDA to do my latest PCB routing as it does not show in the current link. unfortunately there is no backward compatibility with the old version but hopefully by the time you read this Dillon (the writer of the software) will have updated EasyEDA

You can also order a PCB from them (and help finance the project) by clicking on their shopping cart, the PCB's are made by seed studio and are really good quality) you can also fork off the PCB for editing and/or download the gerbers from here.

I have used the prototype and conducted a real life end-to-end test already ie

1. Scanned a barcode from a job sheet

2. Sent query via wifi to server and had server parse the query and return the details of the job

3. Updated the job status by selecting from a menu item

4. Send query via wifi to update job status and logs

This proves the concept is sound. There is also a blog post on the higher level stuff at my web site http://rodyne.com/?p=611

Note: I have not gotten around to testing the RFID, though this all worked fine in older prototypes so I don't expect any problems.

After several days of cussing and pulling out hair I have finally figured the problem with the power and wifi.

The NCP1421 works OK but cannot handle the sudden load of 250mA+ put on it by the ESP8266 wifi quick enough to prevent a brown out on the other parts of the circuit. As I will be switching power off and on the ESP8266 every time this is a problem. I tried putting capacitors on the Vcc up to 1500uf but it was getting a bit ridiculous so I thought I would try and stop the brown out by isolating the CPU/LCD 3.3V behind a diode (D1)/capacitor (c6) which will charge and buffer Vcc (PIC+LCD=24mA when not in sleep) and when the sudden drop occurs the schottky diode (d1) will not conduct and (hopefully and with careful selection) C6 will hold Vcc for the few milliseconds until the power stabilises.

As this is more a hack than a design I have also reverted to an old design using a LiPo 3.7V cell, both boards will be produced simultaneously so I can work a bit quicker as its getting toward XMAS I've updated the details on my website here

Man this module sucks, it is so not ready for any project where you expect to solder it in and work. I know there is a lot of work going into getting it reliable but for now I'm seriously thinking of ditching it and going back to the lower spec (but reliable and useable) USR module I originally used. I will give it one more try to get it working.

I think I know the boost converter problem, basically the WIFI module wants 250mA on power on and I had the wrong size inductor in the boost converter to give this, dropped the value from 10uH to 5.6uH and much better now, though still not happy with a 250mA surge as I have had to pop in some big caps and the boost converter may not start at the end of its charge. Lets see!

I will update the BOM and circuit once I get through the wifi nastiness I'm having. Maybe at some future date someone will produce reliable hardware and firmware for the ESP8266 but for now early adopters beware!

After a few private emails I have changed the MPU to the PIC32MX2xx and have added a USB port, the reasons being that

1. We can now support a USB bootloader and possibly some of the Arduino like pic32 environments like the chipkit

2. I can add a small NiMH battery charger circuit to recharge the AA cells via the usb.

The original prototype way back used a bigger chip and supported USB but all were removed in the simplification that followed. I've decided to risk adding it to the new PCB for completeness.

The new circuit and board have been updated to Rev5 for anyone interested so you can check out the changes which are:

1. Changed from PIC32MX1xx to PIC32MX2xx and added USB. 4 pins are lost due to USB support on this chip so I have had a bit of a shuffle around of the pins and removed the LCD_RESET which was not really necessary IMHO. K5, K6 and K7 have also been displaced and the scan/power on is only used for powering on the boost converter now (though I was toying with connecting it to the reset MCLR pin for a soft reset)

2. Added a charger circuit. note the charger circuit is pretty base as I will need to experiment with resistor and/or pulse settings to ensure safe charging, by default charging is off by setting the gate of the FET high, the idea is when I detect USB power (VUSB) then I will turn on the gate by setting it low for 5 seconds, turn it back off then check the voltage, this will repeat until I see the correct voltages on VBat (I put a resistor divider here but then realised the mav battery volts will always be less than 3.3V so really this is not required.

3. I have added a FET in the WiFi power line, I should have left this in from the last version but was deceived by the ESP8266 chip enable. There are a couple of big caps here, I will experiment with the values and/or if they are required (the ESP8266 has a bit of a surge voltage on transmit and power on) by default on power up the wifi is off, I will power it on -> send -> receive -> power off hopefully in a few seconds so each time it will boot from cold and hopefully get around some of the issues others are having with the firmware/quality of these devices.

As a note to self I will not solder in a wifi module until I test it connects and sends. I'm hoping the quality will improve as more manufacturers make these if not I will add the ESP8266 chip directly onto the circuit. This is a bit too much of a step at the moment as I still do not have all the time I wish on this project due to other commitments (ce'st la vie!)

4. I have removed the MOSFET for the backlight on the GLCD it is only using 10mA and can be easily sourced direct from the pic.

The new boards (and a stencil) are being manufactured now, fingers crossed I've got it right!

On the good side I'm getting quite familiar now with the PIC32 and MPLABX and I think I've discovered most of the problems I had in my original firmware and I"ve also met a mechanical engineer called Eddie who has a laser cutter and 3D printer so I can plan the mark 2 version without worrying about the case.

Finally managed to get a whole day back on the project after almost 2 months, almost seems 1 step back and two steps forward as:

Changing the layout of the barcode scanner so it hits the window at an angle worked well and so (thankfully) I wont have to re-design the case again

Changing the WiFi to an ESP8366 module is a double edged sword, the main thing is the reliability of the units and the large power on current.

The C code has legacy elements from the very first touchscreen version and I did an extensive re-write and re-documentation of the source as I fought my way back to understanding it.

There does seem to be a problem with the boost converter circuit which may be to do with the power demand of the wifi though I measured the max draw of the system at just under 300mA for several milliseconds which is well within the capability of the NCP1421, something else is causing the power to be unstable. I am not ruling out the construction as I had to hand solder this without a stencil.

So the ESP8266. The ESP01 is now under $4 per unit but there are some serious quality issues with the devices coming out of china, that makes me think both alpha-state firmware and shonky construction. Case in fact, my first 5 (yes 5) units all failed to work, these were the first version using the original ESP8266 chip and without the LED's or the extra lines broken out on the centre pins. Based on the fact a whole community of people is working on these I bit the bullet and bought another batch of the newer ESP8266EX units and most of these at least work. Some however dont! I have never been so impressed and so frustrated at a piece of electronics like this one. The rule seems to be to check the unit connects to a WiFi router before soldering it into a circuit.

The boost converter is also getting annoying, the system relies on the PIC32 setting the enable latch on the converter to keep power on, however if a brown out occurs this latch also drops and latches the power off. Now firstly there should not be any brown-out-resets (BOR) the fact they are happening is a worry and something I need to check, the second thing is I really need to look at someway that any glitch (due to low battery mainly) does not cause the system to behave erratically, this will also happen when I flash the device so I will need a way of holding the power on during flashing or a re-design!

I am currently powering the boost converter from a 2V 3A bench supply and I can see the max draw is about 410mA when everything is initially switched on, this may be too much for a low battery but not for a bench supply, bloody weird!

Bypassing the boost converter with 3.3V@3A directly into the system the power is stable and the max current as measured on my breyman multimeter (which is the best multimeter I have ever had including Flukes!) is 291mA which can be easily handled with the NCP1421.

Assuming I individually test all the ESP8266 modules before inserting them I will stick with these, after all there is a community out there at Hackaday.io and here (amongst others) with the development kits examining how to improve these for the hacker community so the situation should improve some.

Next thing is to find the reasons for the boost converter problems and find a solution and once I have a base working system update my circuit, PCB and Github repositories. This may take another month or so due to outside work load so please be patient.

Tried a 3.579545Mhz XTAL as shown in the PIC32 family design reference with all the correct values for the baud rate generator and the wifi could not get a lock at 115200 baud, replaced the 8Mhz XTAL and upped the clock to 20mhz and all ok again.

I have since done a bit of research (wikipedia was quite good here) and it looks like 7.3728MHz crystals are the way to go as these divide down to 115200 exactly, luckily they are also plentiful and as cheap as chips, I just ordered 10 for a dollar, delivered to my NZ rural address! (How do they even do that, someone is really losing out somewhere in the chain and it ain't me!)

PS the saleae logic analyser is magic for finding things like this as you can set the channel as a 115200 baud serial and it will show the data stream gradually going out of frame, I have a feeling I'm going to get my moneys worth out of that analyser on this project!

Build Instructions

The project is mainly 0805 surface mount, the smallest parts are the FFC (Flat Flex Cable Connectors) which are 0.5mm, you will need to solder a 31 pin one for the GLCD and a 12 pin one for the barcode.

If you open the cad files in your browser and look at the PCB it doesn't have too many parts and can be assembled by just about anyone with decent soldering skills in a couple of hours, I have made up 2 boards, but for larger qty I would recommend going to an assembly house for the SMD parts.

Firmware updates are done via the exposed ICSP port. The PIC32 USB port has been broken out so a boot-loader can be written if required for the PIC and for the ESP-01 as I have broken out the ESP-01 GPIO pin for controlling the flashing to a PIC IO pin.

I would only recommend getting a membrane keyboard custom made if you are making a large qty, the alternative is to modify and extend the PCB to the full length of the case and mount SMD buttons on the LCD side of the PCB (the back) then make suitable holes in the case.

The barcode scanner must face the front window of the unit at an angle to prevent internal reflections from washing out the barcode signal. On this PCB I have mounted it at a 30 degree angle and this seems sufficient though a better design would be to change the case so that the window is angled from top-to-bottom (see the barcode documentation on this, it is important and a big trap for young and old players)

The ESP-01 will need to have the AT firmware flashed for my implementation, this must be done BEFORE the ESP-01 is mounted. I also recommend checking the ESP-01 connects using a serial terminal before soldering it in as these units are not very consistent for quality!

2

Step 2

Software Notes

Most of the configuration parameters such as SSID, username and password will need to be input on first use (don't code these in the firmware unless your prepared to re-flash every unit if your SSID/Password changes!) There are two easy ways to do this either using a pre-printed barcode sheet that the user will scan to set-up, or alternatively and more securely to encode the SSID/password into the RFID tag. Setting up the terminal with therefore be a matter of scanning a couple of barcodes or a single RFID card.

I have also set the output printer selection the same way so if your user wants to print something you can scan a barcode stuck on the printer and it will redirect the print there

The first version of the firmware I am now using has the user program and menus hard-coded, my original goal was to incorporate a simple byte code interpreter which will allow someone with no great knowledge to use something like a variation of tiny basic to use but I have found the functionality I need for now can be incorporated in a very simple menu program.

The second program you need to write will be the server one that interprets simple pre-determined queries (such as SQL or print requests) and actions them on the network, I have used Lazarus (Free-Pascal) for this this, but it could easily be done in something like PHP or Python or indeed any language that can listen on a TCP socket and send responses. This program is going to be very specific to the target MRP system you will want to interface to, I have made a very simple example which will hopefully give you the basics. The system I am interfacing to is proprietary not open source so I wont be publishing my specific program due to a NDA with the client.

Discussions

Become a Hackaday.io Member

Note this project is complete. I have however made a follow on project for another customer with a slightly simpler design and replaced the WiFi with 866/915Mhz LoRa and replaced the RFID with a 125Khz one, battery life is improved a lot. Preliminary information here => http://rodyne.com/?p=844

I made 30 units the end of last year and the parts cost worked out to $87 each. I had the PCB's manufactured and assembled in China and did the case assembly myself to achieve that.

I do not sell them so you will need to verify the design is right for your needs and then contact a contract manufacturer to make them in quantity for you. I suspect they could be easily manufactured for much less than I achieved.

Remember they do not come with finished firmware, just a simple test program you can customise for your own requirements, see the project description.

The design is Public Domain so feel free to send it to another party, modify or use any part of it without restrictions for any purpose.

Been using the finished prototypes off and on for a few weeks now as I add and test small functions linking the terminal to the clients MRP system, battery life is generally a few days without any real optimisations and though I am happy with the electronics I am less happy with the enclosure, saying that, it is not too ugly and most people have gotten used to the retro 1980's look :-)

One small change I noticed was that the PCB hole sizes I have put in are for the ali-express version of the camdenboss case and I have noticed the mounting holes are 56mm in the ali-express case and 58mm in the camdenboss one in the parts list. The solution is either to move the PCB holes out 2mm (there is enough space to do this on the PCB without any re-routing of tracks) or to buy a case off the ali-express supplier, (search for AK-H-03 on ali-express)

To answer a thought in most of your minds, at the time I created the system I never thought of basing it on a published 32 bit Arduino clone such as the UNO, ChipKit or Teensy3, in hindsight I probably should have done this so it would have been an easier entry to development for most makers. (I've always been a bit of a square peg, call it age!)

I wont be pursuing this on this version of the unit as I am now familiar with the hardware and IDE and need to get the project finished, but it should not be too hard for someone else to use the concepts and do this.

Finally got the ESP8266 working on my test PCB :-) Now having to juggle the move from HiMH to LiPo batteries in the case hardware so ordered some 14500 3.7V batteries as I can fit one in the AA slot without modification.

Short update. Back from my holidays to the UK and got a stack of work to catch up on then I can get back into the project.

Also having a quick diversionary look at the ESP8266 module featured as another project in HAD as a potential replacement for the USR wifi chip and have ordered a few to test, firmware on the modules seems very alpha and not having as much luck as some of the other guys on that project in getting it working so I won't let it distract me too much.

The next phase of the project will also be mainly coding and may slow down a little while I find a decent gap in my paid workload. Still aiming for a december finish though.

I emailed marson (www.marson.com.tw) direct and asked. Like all barcode OEM guys they are reluctant to work in single qtys but I said it was for evaluating for a project and they sent me 1 for $70! I eventually chose it and committed to 50 which brought the price down to $38. ($36 for 100 and $34 for 500)

I need at least 40 for my first run but will undoubtedly have a few spares so if you want one go to my web site and send me an email and I'll let you have it for $38 + post to wherever you are. I also have some 5V symbol SE1223 ones spare which use the same connector which use a laser and have better distance but these are larger (manuals for both on the documentation link) these would be $25 ea

I will also include the 12 way ffc connector and cable (same cable/connector for both types of scanner)

Thanks! I think I'll take your offer Boz. Actually I'm thinking of a small-ish application (almost contact like) so the 5 MIL resolution from 0 - 30 mm of the MT700 is what caught my eye. I'm gonna try to get the PCB one from www.marson.com.tw for "evaluation" or I'll email you for the FFC one.

The problem is that I'm in America and the shipping may take too much time. I thought you were too, but then I realized you don't.

Have updated the schematic and PCB and have updated the project link in the build instructions.

I Will be getting the PCB manufactured next week, which gives me a week to check it all looks good.

Changes that have been made are:

1. Some MPU Pin remapping to allow easier routing
2. Swapped position on barcode and wifi module on PCB (this is because scan switch wires were almost over the wifi module, Wifi module is now clear of any obstructions as per its data sheet.
3. NCP1421 replaces NCP1410 as per blog entry
4. Shortened PCB to allow easier cable entry

Having difficulty deleting the images in the build instructions without deleting everything so I'll leave it for now, however the link will point to latest CAD files