As an aid for me I created an Open Office diagram a little while back explaining how this will work in one of my customers case, this diagram can be found here as a PDF (Link to Open Office Document here ) Obviously each implementation will be different but not much so as most MRP systems are fairly similar in concept.

The document shows that in order to make the system work I need to write 3 lots of code:

1. The PIC32 Firmware which will use a proprietary (i.e. I made it up) messaging protocol  sending and receiving very simple messages on TCP Port 2001 (or any number of your choosing). These messages have at there root a couple of key fields, ie MRP system job and asset numbers which can uniquely retrieve job data for the factory. Eg when the barcode scanner scans a job sheet it then sends the unique jobid to the MRP system to request job statuses etc.
2. In order for the above to work we need a PC program (a service or daemon as it does not need to be visual) which listens to port 2001 and interprets this simple message into a MySQL query which will retrieve the Job record from the MRP system and package the results into a simple message that the terminal can easily parse.The message trace above is from my work in progress implementation of this program, it shows the message sent by the mobile and the reply received from the server (in this case bugger off as the terminal was not assigned to a user!) I have extracted the thread where the action takes place here this will be the easiest place to start if your converting it to another language. The current working/test (lazarus/freepascal) code and PC program is: Mobile Service (FreePascal Program and Code). Note this version does not include the additional security checks I envisage, this will come.
3. As this will form an integrated part of the MRP system we also need a way for a supervisor to assign a terminal to an operator on the factory floor and to put a user friendly face to the program at the back-end office. eg in my case I will build a module to my Bulls-i MRP system which allows the assigning of a user to a terminal before it will work and to log all transactions back to the supervisor terminal. ie they can assign the terminal to Fred and as Fred scans jobs and completes tasks these will be displayed real-time on the supervisors PC program. this program will also print the configuration sheets for the mobile (ie the barcodes for SSID, security and Host program) that it uses to set up the WiFi and Host connection. I need to write this in Pascal as the MRP system is written in Delphi (shot below).The last picture is especially interesting as it shows the screen where I edit the functions/queries, I’ve included a test button which will open a socket to the mobile server and actually test it end-to-end, quite a good idea to eliminate stupid problems.
4. I will certainly release the source for the server on github, however unfortunately the MRP system it goes to is not open source so some guessing on the part of the builder is required until I publish a stand alone item. Still anyone familiar with the concepts should be able to decipher it quite easy and each MRP system will probably be unique.
5. The SQL to create the mobile DB is mobile-db.sql

If you don’t have the code for the system you are integrating it into then it may also be possible to combine programs 2 and 3 into a single web based system. There is also no reason why you cannot use TCP port 80 for the mobile messages instead of port 2001. I’ve not written a web program for about 9 years so doing a complete open source demo may have to wait

Security is important these days, luckily we are already running a layer of security above the standard industrial systems such as MODBUS by using an encrypted wireless network (WPA2) this prevents eavesdropping but does not prevent spoofing (ie someone with malicious purposes pretending to be a mobile terminal) As I have published most of my secret source this would be relatively easy (assuming you were on the corporate network somehow) The got-cha here is that only certain combinations or job ID’s and asset ID’s in the MRP system will work, and this is a next to impossible task without a print-out of a in-progress job.  Also in the live system I will be adding another layer of authentication that the user will need to scan their RFID tag to do an update just as they have to do on the current touch screens. While not impossible, it does put deviousness outside the realms of your average hacker (I would find it quite difficult myself even as the author)

Do not dispare Hipsters and Pascal haters, the PC programs are relatively short and should be quite easy to read and covert to you favourite language de jour. I will post up the work-in-progress code in the next few days.

The above shot shows a completed PCB with the LCD and the ESP8266 WiFi module mounted on the reverse. As luck would have it the WiFi Module fits perfectly and the antenna is in a perfect position top dead centre. The Barcode reader is screwed on via the two screws in the far right.

Below is the component side of the board.

As you can see the barcode is mounted at a 25 degree angle so there is no internal reflection picked up off the case window. The RFID components are not mounted yet and I will do that last after I confirm it all works (I hate to count the number of Melexis RFID chips I have soldered on to bad boards and at $5 a pop its not nice to think about!)

The chip next to the Wifi (U3) is the new 3.3V LDO regulator dedicated to the ESP8266, I also ensured I tested and re-flashed the ESP-01 module before soldering it on.

In place of the 2 x HiMH AA cells I now have a single 14500 AA 3.7V LiPo cell which says 1200mAH on the side (The word on the internet is however that these blue Ultrafire batteries are actually only good for about half that) either way a bit of a come-down in battery life for the unit.

The only real problem is the USB connector does not have a cut-out on my case, so there is going to be a bit of cutting out involved.

If you note the circuit, you can see the PIC32 is correctly wired for the USB connector so it should be possible to implement some form of boot loader for the firmware. As I have also wired the ESP8266 GPIO0 pin to a PIC digital pin I can also toggle the flashing of the ESP-01 so again making it possible at some future time to implement a USB to serial converter and updating the ESP-01 firmware also (un-soldering it is not really going to be practical)

More importantly I have been working on the rest of the project which I will explain in my next post later this week.

1. 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
2. Changing the WiFi to an ESP8366 module is a double edged sword, the main concern is the reliability of the units and the large power on current.
3. 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.
4. 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.

Like almost everything when your doing embedded design its normally down to a few stupid assumptions and oversights, so if you want a few tips on getting your pic32 to play happily in the microamp range read on..

For a battery powered device to work for a decent length of time, say a week of normal use, we need to do a little maths. regarding power source (AA batteries) boost converter efficiencies and minimum operational voltage and expected usage of the different modules, also how long the user is doing real work against doing nothing. Once you have done this you normally find that most handheld devices spend 99.9% of their time waiting for a user response, during that time you are generally wanting to be consuming as little power as possible, if possible during this time you will also we checking for timeouts such as if the user has decided to go home for the night so you can safely power off the device. If you can get your microcontroller and devices under 50uA during sleep then you can generally dispense with power switches, if you cannot achieve this for any reason then you want the ability to power off the devices when not required.

The notes below refer to a version of my data collection terminal schematic shown below, it has all the problems above. Because the WiFi and Barcode parts chosen are not that power efficient and do not have very good power management features, the terminal switches off power to them when not in use using P channel MOSFETs, on the Vcc line,  the buzzer and backlight are also MOSFET controlled, thus when powered off we should only have to worry about the PIC32, the LCD power consumption or do we?

Lets assuming you’ve done some operation in the above circuit and now want the pic to drop into a low power mode and wait for some event like an interrupt or keypress. You generally issue either a PowerSaveIdle() or a PowerSaveSleep() command.

Before you do this you will have first turned off all the interrupts you dont want to wake the device as any interrupt (with a priority greater than the CPU) will do this. This is the first mistake most people often make and it is easy to check by issuing an asm(“DI”) instruction before the powersavesleep() to ensure nothing else has woken it such as a timer, if you do this and the consumption goes down then all well and good, but what if it doesn’t go down or only drops by a few milliamps, is the pic faulty, are microchip lying?

Its usually only mentioned in passing, but the actual biggest consumer of power is your IO Pins, input pins generally are not the issue (as long as they are tied to a high/low state and not floating), however unless your output pin is driving a high impedance source such as a MOSFET (like above) then you are very likely supplying current into whatever you are driving and this includes such things as UART transmit pins, SPI enables, etc. For example in the circuit I remove power from the barcode MT700 module by setting M2’s gate high, I then remove power from the Wifi module by setting M1’s gate high, the backlight and buzzer are also completely disabled by setting their gates low (N-Channel MOSFETS) I then issue a PowerSaveIdle() and zap the power drops to under a milliamp?

Actually no, if thats all I did above the power actually only drops from 150mA to about 50mA!  So why is that?  Basically because I have forgot to also account for the pin states of the other inputs to these modules.  Both devices are have active low resets, triggers and tx pins, this means the PIC which has these pins high during normal operation is now sourcing the full current the pin can sink into these pins when the power is removed (dohhh!). If we set these pins to the same level (ie set them to 0) then the power drops to 7mA. This can also be achieved by using resistors in series to unknown inputs to reduce the current the port will sink/source in an unknown state.

Now, 7mA is better but its still going to waste your battery 10 times as quick, as say, 700uA which should be achievable. So discarding the LCD (which plays good actually takes about 400uA normally) where is the rest of this current going?

Strangely (and maddeningly) enough as I use the ICSP lines for other functions, about 4mA of that 7mA is actually being drawn by my PICKIT programmer when it is connected, which it normally is during development. This little nugget of information would have saved me hours of work a few years back!  So really your hardware is only actually taking about 2-3mA.

We are still using 2-3mA because PowerSaveIdle() removes the CPU clock but the peripherals UART, SPI, ADC, I2C etc are still powered and running at the peripheral clock frequency.  Luckily the PIC32 lets you power down unused peripherals, eg I use:

 PMD1bits.AD1MD = 1; // ADC Pwr off
 PMD1bits.CTMUMD = 1; // CTMU Off
 PMD1bits.CVRMD = 1; // CVR Off
 PMD2bits.CMP1MD = 1; // Comparator 1 off
 PMD2bits.CMP2MD = 1; // Comparator 2 off
 PMD2bits.CMP3MD = 1; // Comparator 3 off
 PMD3bits.IC1MD = 1; // Input compare 1 off
 PMD3bits.IC2MD = 1; // Input compare 2 off
 PMD3bits.IC3MD = 1; // Input compare 3 off
 PMD3bits.IC4MD = 1; // Input compare 4 off
 PMD3bits.IC5MD = 1; // Input compare 5 off
 PMD3bits.OC1MD = 1; // output compare 1 off
 PMD3bits.OC2MD = 1; // output compare 2 off
 PMD3bits.OC3MD = 1; // output compare 3 off
 PMD3bits.OC4MD = 1; // output compare 4 off
 PMD3bits.OC5MD = 1; // output compare 5 off
 PMD4bits.T2MD = 1; // timer2 off
 PMD4bits.T3MD = 1; // timer3 off
 PMD4bits.T4MD = 1; // timer4 off
 PMD4bits.T5MD = 1; // timer5 off
 PMD5bits.I2C1MD = 1; // I2C Off
 PMD5bits.I2C2MD = 1; // I2C Off
 PMD5bits.SPI2MD = 1; // SPI 2 off
 PMD6bits.PMPMD = 1; // Parallel Master Port off
 PMD6bits.REFOMD = 1; // ref clk out off

In my device startup to removes another milliamp or so.

Great, now we are down to around 1-2mA.. Most people would be happy with this, the PIC is working the LCD is working and we can still receive interrupts and get going immediately any work to do and we get a day or so on a battery, but what if there is another way we could squeeze that last milliamp out?  Remember removing that last milliamp will potentially double, treble, quadruple the battery life, this is the area where you can now work on a weeks battery life as opposed to a day so it is really worth the effort.

Well issuing PowerSaveSleep() will definately remove that last milliamp and get you down to around 600uA (including the LCD) this is because it removes the peripheral clock too, the CPU can still be woken up by watchdog timer (which uses the LPRC oscillator @ 31.25Khz) or an external interrupt, but remember all other peripherals and there interrupts are off.  But what if you still need to do some work, such as say timing the inactivity to power off the device after 30 minutes of no use or timing out the backlight properly after say 10 seconds? Well then you will need to do some more programming.

PowersaveSleep() is the lowest power mode and therefore the best way is to issue that and use the watchdog timer or the keyboard scan lines on an external interrupt to wake the CPU and do a few quick calculations then put it back to sleep. The watchdog timer really should only be enabled before sleep as if it is triggered during normal operation it resets the CPU, the watchdog timer is covered to death in the documentation and internet.   But there is also an alternative way which allows you to keep the CPU running and no PowerSaveIdle() or PowerSaveSleep() is required,  and this is to change the CPU clock right down to the lowest possible frequency to do the task you want and change it back up again when an external event is detected.

Now you need to be a bit careful if doing this as the Peripheral clock is derived from the system clock and timings for baud rates etc will be thrown out completely when the clock changes, also any code that does run will run really (really) slow so best to turn off all interrupts just in case. The code snippet below drops the power to 680uA, only 20uA more than using PowerSaveSleep() by using the LPRC (Low power Internal RC 31.25Khz) oscillator as the clock source while waiting for a keypress or timeout event then switching back to the normal clock when the event is detected.

uint8 WaitEvent(uint32 timeout) 
{
  static uint32 PowerOffTimer,BacklightTimeout;

 // power off all modules you can and disable the interrupts

 asm("di");

// change default states of output pins to peripheral devices so 
// that we are not accidentally supplying power through them

 IFS1bits.U1RXIF=0; // clear any current interrupt flags
 IFS1bits.U2RXIF=0; // clear any current interrupt flags

 // change down to 31khz for power save while waiting
 SYSKEY = 0xAA996655; // Write Key1 to SYSKEY
 SYSKEY = 0x556699AA; // Write Key2 to SYSKEY
 // OSCCON is now unlocked
 OSCCONbits.NOSC=0x5; // change to LPRC @ 31.25Khz
 OSCCONbits.OSWEN=1;
 while(OSCCONbits.OSWEN); // wait for osc switch to complete
 SYSKEY = 0; // ensure OSCCON is locked after

// now working really SLOOOOOOOW without interrupts, 
// so nothing complicated, just wait for keypress do timeouts

 PowerOffTimer = prg.OffTimeoutMs;
 BacklightTimeout = prg.DimTimeoutMs;
 while(1) // loop @ 31Khz..
 {
   BACKLIGHT(BacklightTimeout--); // time out backlight
   if(KEYSTROBE0 || KEYSTROBE1 || KEY_SCAN) break; // detected key
   if(!PowerOffTimer--) PWR_HOLD(0); // no activity so power off
 }

 // resume proper clock
 SYSKEY = 0xAA996655; // Write Key1 to SYSKEY
 // resume proper clock
 SYSKEY = 0xAA996655; // Write Key1 to SYSKEY
 SYSKEY = 0x556699AA; // Write Key2 to SYSKEY
 // OSCCON is now unlocked
 OSCCONbits.NOSC=0x2; // restore PRI HS Osc no pll
 OSCCONbits.OSWEN=1; 
 while(OSCCONbits.OSWEN); // wait for osc switch to complete 
 SYSKEY = 0; // ensure OSCCON is locked


// back to normal CPU speed so enable interrupts again
asm("EI");
BACKLIGHT(1);//restore any pins to normal states if required
// put uart tx pins back under uart control
U1STAbits.UTXEN=1;
U2STAbits.UTXEN=1;
return
}

Whether you use this or the watchdog timer depends upon what your doing during the idle time and how frequently you are doing it. I have yet to decide which method to use for the terminal but I thought I’d share these thoughts in case they can help anyone..