Unmanned Rig

Standard

The last project of my undergraduate life was an industrial embedded system. Wabco, a major hydraulic system manufacturer, wanted a system that would continuously monitor a testing rig. Testing rigs are those machines that they use to test the hydraulics and this involves pressure and temperature parameters. The system should be able to monitor these parameters for sustained periods of time (24X7). The operator is required to give lower and higher threshold values for each parameter at the start of a testing cycle and then the system measures the parameters to see if they are within the 2 thresholds. If not, then there is an abnormality and in the event of any abnormality, the system should report it to the operator through a SMS and stop the rig. For completeness, the board has a display that sequentially displays the parameter values. The embedded system is designed to handle 6 pressure values from 6 pressure transducers and 2 temperatures from K-type thermocouples.

A major feature of the board is an indigenous solution to a local problem we have in Tamil Nadu – power cuts. The board is designed to detect these power cuts and intimate the operator and when the power resumes, the rig is automatically restarted without manual intervention – automation.

The major components of my design were an MSP430G2553 microcontroller (for central processing), an ATMega16 microcontroller (to provide display data for the 7 segment displays through IC7447 decoders), a GSM module interface (to send the SMS), a MAX4617 multiplexer (to channel the 8 sensor values), a relay (works in tandem with the rig’s control switch to stop or start it) and on-board power regulators for the power supply. After the schematic development, PCB layout & manufacture and assembly of components – the result is:

IMG-20160327-WA0000

The embedded system’s top side (above) and the bottom side (below)

IMG-20160318-WA0007

 

For ‘industrial reasons’, I wasn’t allowed to take my phone to record the video of the board working with the rig, but here is the next best video I have – the testing of the board with 1 pressure and 1 temperature monitoring.

The curious thing about doing an industrial project is preparing and analyzing FMEA – Failure Mode and Effect Analysis to evaluate the performance of the system. This is my FMEA for the Unmanned Rig

The Notion of Embedded Chaos

Standard

Encryption has been an important field of science ever since communications became prominent.  Today, all transfers that occur through the internet are encrypted in some way or the other. A similar requirement to encrypt data transfers exists in embedded systems as well. Typically for such applications, encryption is done in software.  The downside of this technique is – it consumes processing time and given that microcontrollers don’t generally have a lot of processing capability, there comes a necessity for hardware based encryption. The current trend of data transfer schemes has no provision for built-in encryption techniques. So if a built-in technique were to be used, these would be its requisites:

  • The encryption has to occur with as minimal hardware usage as possible, which will reduce die space during implementation.
  • The encryption should be able to secure or abstract the data from external or undesired observers.
  • The data should be recovered using least amount of hardware with the highest possible fidelity.

To achieve all these constraints for a hardware based encryption technique, I used the logistic map equation from Chaos theory.

                x(n+1) = x(n) * r * [1-x(n)]

If an initial for x(n), between 0 to 1 (other than 0, 0.25, 0.5, 0.75 & 1), is applied to the equation with a suitable coefficient r value as 4, then x(n+1) will be another value between 0 to 1. This x(n+1) will be the next x(n) and the equation iterates. The specialty of this map is that the sequence of x(n) values will look seemingly random. Why? Avoiding the math it suffices to say, It’s chaos.

I used this map and simplified it even further by fixing r=4. If r=4, the map produces chaotic values but in its binary implementation we reduce the need of a multiplier by 1 since multiplying anything by 4 in the binary domain is simple left shifting by two steps and adding zeros. This is similar to decimal multiplication, where multiplying anything by 100 is left shifting by two steps and adding zeros. This results in the following binary chaos map.Binary structure

The register at the top contains x(n) values. A bit wise negation of the bits and adding a small offset provides a value equivalent to [1-x(n)] and this is multiplied with x(n). The resulting product is to be left shifted by 2 positions for multiplying by 4. But to avoid left shifting delays, it is more optimized to consider bits 13-6 as x(n+1). Thus the binary map produces chaotic codes which are used to encrypt or decrypt data with a mixer/extractor. A simple mixer/extractor is a bit-wise XOR between the chaotic code and the data.

During development, there were a few issues with how the data transfers would require different code cycling depending on simplex or duplex modes.  Irrespective of the transfer modes, the number of nodes to which data is to be transferred, is also important in maintaining sync. This is critical in single master to multiple slaves configurations, as supported by protocols like I2C, SPI etc. For simplicity, I am going to skip the technical details of how these issues are handled. This entire process provides the micro-architecture for embedded chaos.

Architecture

The analytical performance of the technique was verified using python and Matlab and the results were in favor of the idea – a simplified architecture for hardware based encryption. To verify it practically, two Xilinx Spartan 6 FPGA Development boards are used for encryption and decryption. 4 bit data from 4 switches is encrypted into 8 bits and transferred out where the other FPGA decrypts the 4 bit data and drives 4 LEDs accordingly. An interface board with an 8 bit DAC is used to represent the 8 bit encrypted data in an analog form. This analog signal is seen in the computer based digital oscilloscope.

FPGA demo

This was my final year project for my Bachelor’s degree in Electronics & Communication engineering. The technique and architecture developed are a suggested prospect for embedded encryption as built-in solution, due to its least hardware requirement. The correlation of the signals and the analysis shows that the message is sufficiently mixed up with a noise like varying-signal (in the analog version) that cannot be decrypted as long as the initial key is not known, ensuring security.

Hybrid Power Supply

Standard

With the world’s  energy crisis only getting worse as days go by, the importance of renewable energy sources like solar power is becoming much more prominent. Solar power typically provides direct current (DC) while most commercial power supplies provide alternating current (AC). So, if a house were to be provided with solar power and utilized commercial power whenever the solar power wasn’t enough, then the appliances should be able to work on both AC and DC supplies. Also, typically solar power voltages are substantially lower than commercial AC supplies. So there is quite some diversity in the kind of power being supplied.

Most appliances today including computers, inverter ACs, TVs and even batteries etc., all work based on DC. Typically for these DC based appliances, batteries use an inverter to provide AC (to be compatible with commercial supply) and then the appliance rectifies it back to DC for its use – with energy wasted during these conversions.  So, the requirement would be an universal power supply that can take in any voltage from 40-240V AC or DC and provide any voltage between 40-240V DC, such that it can be used with any appliance to work with any given supply. That is what the hybrid power supply does.

Technically, it is a microcontroller based Buck-Boost network with an input stage bridge rectifier. The schematic is as seen below.

Schematic

The circuit works by converting AC or DC to DC through the rectifying bridge. Then a linear regulation provides a 5V supply so that the microcontroller can turn on. Once the microcontroller turns on, depending on the position of switch S1, the buck-boost network is controlled. The output voltage is fed back to the microcontroller as a form of closed loop control and depending on the output voltage, the microcontroller accordingly adjusts the Pulse Width Modulation (PWM) signals to the transistors Q1 and Q2. This schematic was initially developed for a mixer grinder operation, hence the use of switch S1.

To make it truly universal, I added a resistor divider network in the input stage to see what the DC input is and a potentiometer for the user to set what output voltage is required. The microcontroller sees the requirement and the supply and accordingly bucks or boosts the input voltage in an open loop way without a feedback as illustrated in the block diagram.

block diagram

Practically, problems arose in the form of huge ripples because the microcontroller’s PWM frequency was just not high enough. So I added a 1Mhz 5V triangular wave oscillator and a low pass filter to the microcontroller’s PWM output to provide a threshold voltage.  When the threshold voltage is given to a comparator along with the triangular wave, it would produce a 1Mhz PWM with the required duty cycle. So, the new schematic became something like this.

sch

Naturally the next step would be to fabricate the circuit with power electronic components – a huge inductor, a couple of high voltage capacitors, high voltage MOSFETs and diodes. The circuit is fabricated on a prototype board.

This slideshow requires JavaScript.

The results of what should happen and what actually happened are summed up in this video with a simulation and the practical output as well.

Actually the buck operation didn’t perform well and so did the boost as well. On inspection, it became apparently clear that although the design was sound and the logic was correct, the execution was not perfect. The imperfect execution was also not because of the fabrication on my part, but due to the stray effects at high frequencies.

5

For boosting the input from, say, 13.4V to 30.8V which is more than 3 times the input, the ripple in the output becomes very high. So to reduce ripple a high frequency PWM is required. This is why a 1Mhz triangular wave is required to generate such a PWM. 1Mhz is almost at the cusp of radio frequencies which creates stray or non-ideal effects in the components used. This results in the waveform not being completely triangular. There are significant undershoots (below 0V) and overshoots (above 5V) which create undesired PWM generation that tampers with the output. It is because of this, I didn’t risk testing it at the voltages (40-240V) that the circuit is designed to handle. Yes, unlike other projects of mine, this one doesn’t work perfectly but it is a fair performance considering this is my first power electronics project. In any case, by design, it is an innovative solution for a valid problem of powering appliances in ‘intelligent’ houses.

 

IoT based Remote Health Checkups

Standard

Health has become a major concern today with pollution and sedentary lifestyles taking center stage in our lives. Therefore monitoring our health has become paramount. This project is a step in that direction involving the current trend – IoT or Internet of Things.

In almost all health check-ups the most basic parameters that are measured are temperature, pulse rate, blood pressure and blood sugar (usually for diabetic people). Let’s say that there is a person who resides in place X but had a surgery done somewhere far away. The doctor would like to keep regular tabs of these parameters on this person. How does such a remote check-up happen? Another situation would be during disasters like floods or places where there is not really any medical facility or access to doctors. How to check the basic health parameters in such cases? The project is targeted at these issues.

20160226_201918

The system shown in the picture uses a STM32 Nucleo which is an ARM microcontroller based development board. The STM32 is interfaced with a LM34 Fahrenheit Temperature Sensor to measure the body temperature. The analog output of the sensor is directly read using the ADC.

To measure the pulse, an electronic stethoscope is used. Although, it is unconventional to measure pulse this way, an electronic stethoscope is used since it opens the possibility of recording heart sounds. In most check ups, doctors also listen to the cardio-thoracic sounds. I made an electronic stethoscope by simply adding a microphone to a stethoscope. To finish things off, some hot melt glue to hold the wires properly in place.

The electronic stethoscope’s audio signal is amplified using a TLV2362 based Op-amp circuit. The output which is technically called a phono-cardiogram looked like this.

The sound is currently recorded indirectly by the system. The audio output from the amplifier is fed to a speaker and then recorded. The recorded sounds are uploaded to a cloud service like SoundCloud. For the pulse measurement, the audio output is sampled by the ADC of the microcontroller to detect peaks. The peaks correspond to the beats of the heart. The interval between these beats is measured 5 different times and the average interval is calculated. The reciprocal of this interval multiplied by 60 gives the number of beats per minute.

For measuring blood pressure, the usual sphygmomanometer apparatus is used. A pressure sensor, MPX5050, is fitted into the tube leading to the analog pressure dial. The sensor’s analog output is also read using the ADC and the pressure reading is calibrated carefully. The blood pressure measurement is made using oscillometric measurements of the pressure. The cuff is worn tightly around the person’s arm and the pressure is increased to more than 160mm of Hg by inflating the cuff using the bladder. Then the valve is slowly released to gradually relieve the pressure. At one point as pressure decreases, small oscillations will be seen in the pressure value during every systole (contraction) of the heart. The pressure at which this happens is read as the systolic pressure by the system. As pressure is decreased further, at another point these oscillations will disappear because the pressure is low enough that blood need not be ‘forced’ into the arm. This pressure is read by the system as the diastolic pressure.

These techniques allow the various values to be measured but they are still present within the ARM microcontroller’s memory. To push the data to a server through the internet, the ESP8266 WiFi module is used. The data of each health parameter – temperature, pulse rate, systolic and diastolic pressures are sent to different channels hosted on the free IoT platform – ThingSpeak.

RemoteHealth

The entire procedure can be put this way. The system is switched ON and the ESP8266 receives commands to connect to a predetermined hotspot. This takes time and meanwhile the user is required to hold the LM34 sensor. Once the connection is established, a green LED will turn ON to indicate that the user can proceed. Then the user presses the user button to make the microcontroller read the temperature. Once the button is pressed, the microcontroller will automatically read the temperature and push that value to the predetermined channel on ThingSpeak. Meanwhile, the user now places the electronic stethoscope on the chest and uses the earphone to make sure that the heart’s sounds are picked up. Then again when the microcontroller is done sending the value, it will turn the green LED ON to indicate the user can proceed. The user button is then pressed to initiate pulse measurement and to send it to the server. Then the user wears the blood pressure cuff, pressurizes it to more than 160 mm of Hg. Once the green LED turns ON again. the user presses the button and begins to slowly release the valve. The measurement of blood pressure is made as explained before and the data is sent to the corresponding channels. These processes are shown in the video below.

Unlike other works of mine, the major portion of this project’s ‘output’ is actually a website. The data collected, is rendered on a website with each page dedicated to a separate registered user. Such a website dedicated to this project is “The Health Check-up Site”

The system in its current state is manual in nature. Future work has to be done in automating the blood pressure measurement for this system. More suitable temperature sensors rather than LM34 have to be used. The use of MP3 encoders to directly record the audio output and its automatic upload to a cloud should be explored. Integration of other features like blood sugar measurement should also be done, for this system to become incredibly useful.

But as such it does, to some extent, solve the problems or situations that were discussed earlier. Such systems would also help health conscious people have their parameters  and sounds recorded everyday for long term analysis by a family doctor, for example, without going to hospital or clinics. It would also help to provide a way for people in rural areas or people isolated somewhere for some reason, to have their health checked-up. To put some form of medical monitoring closer to people irrespective of their location, is the prime idea and motive behind this project.

Production Recorder

Standard

This project is about a system that can help supervisors to monitor production in manufacturing stations. Currently, a supervisor relies heavily on the logs created by the personnel which leaves plenty of room for lethargy and inefficiency.  I came to know this through Niranjan, a mechanical engineering friend of mine, who noticed this ‘corruption’ during his implant training. This project is the solution that I came up with.

Most modern manufacturing machines, especially the CNCs, have a stack light or machine status lights to indicate the state of a machine. Typically a stack light will have 3 lights – Red indicating breakdown, Yellow indicating a job in progress and Green indicating that the machine doors can be opened for retrieving or setting the work piece. Therefore the transition from yellow to green indicates the end of a process and at the end of each such process there is a finished workpiece.

220px-StackLightInstall1

Machine Status lights or Stack lights

The Production Recorder system has multiple transmitters, each associated with a single machine, to communicate with a central receiver. Each transmitter module monitors the stack lights of its associated machine. This is done by using light sensors to detect the light or simple level translators to see the electrical signal supplied to each light. The microcontroller in these transmitter modules is programmed to read the light being ON or OFF as a digital input for processing. At every Yellow to Green transition, the transmitter module’s microcontroller, a MSP430, understands that a job is finished and expects the operator to tell the result of the job. It does so by waiting for one of three buttons to be pressed- the crossed button (bottom) for defective, the dashed button (middle) for minor faults and the clear button (top) for Quality Check Passed. The operator is required to check the workpiece and press one of the three switches on the transmitter module for good, minor fault or defective.

up3

Every job and its result is reported by the transmitter to a central receiver. The transmitters send specific codes detailing the particular machine number and the quality of the current job to the central receiver via the ‘NRF24L01+’ RF transceivers. If in case the operator does not press any switch and another process starts (when the microcontroller sees Yellow during its wait state) a warning code is sent. In the event of a breakdown and the microcontroller sees the Red light, a breakdown code is sent. These codes are obtained by the central receiver through the same transceiver. The central receiver also has a ‘HC 05’ Bluetooth module to transfer these codes to the supervisors mobile for processing. The central receiver functions as a link between the individual transmitters and the android app.

up2

The custom built app processes these codes and updates production values on the screen. The codes are used to determine which machine and its current job result to increment the appropriate value on screen.  In case of a breakdown, the machine title gets displayed in a red background to notify the supervisor that something is wrong with the machine.

2015-12-26-18-55-45

Screenshot before establishing Bluetooth Connection through ‘Source Select’

If the machine is repaired and resumes production after a breakdown, depending on the next job result an increment occurs and the title color of the appropriate machine goes back to its normal color. As a proof of concept prototype, the project’s transmitter module microcontroller simulates the stack lights by providing the signals to the LEDs appropriately and then reading that as an input. Practically, the concept and method remain the same.

Future work can be done to take an IoT based approach so that the data can be accessed by any authorized person anywhere anytime. Also, the app can be modified in order to automatically generate a variety of plots using the obtained data for performance evaluation and personnel management. This system and its concept is primarily aimed to help a supervisor keep better track of the production in real time. Subsequently, this creates a production optimized environment where lethargy and inefficiency can be greatly reduced by careful monitoring.

Repairing A Lamp – The Reverse Engineering Way

Standard

This article is about one occasion where I had to use the concept of reverse engineering which is the method of breaking things down to understanding its design and working. Although reverse engineering is a skill that an engineer should posses, I was always so focused on my own designs that reverse engineering never crossed my mind. That was until one day when my LED lamp suddenly blew. Naturally, I was curious to know why. So I removed the mounting screws and dismantled it to pieces. The main  circuit board actually had all the LEDs and the side on which the wires come from the power supply was intensely charred.

20151208_211424 20151208_202003

Most of the board except this was almost untouched. So, I wiped out the soot and examined the board’s PCB traces to understand how the LED’s and other components were connected.

20151208_211125

In the first glance I saw that the LEDs were in series. So, I knew that it had to be a constant current circuit. A quick search using the IC (on the left) number – CYT1000A which is a Linear Current Driver showed me that I was right. So the circuit was very simple – an array of LEDs connected in series to a constant current driver and then all that would be required is a DC supply. It is only logical that the charred IC on the right had to be a rectifier of sorts so as to convert the AC supply into the DC version required by the circuitry. When I desoldered and cleaned the IC to took a very close look at it, there was the number MB6S etched on it. MB6S is a 600V Reverse voltage tolerant bridge rectifier from Fairchild semiconductors. Thus, I had reverse engineered the circuit. It turned out that it was a circuit given as a typical application in the current driver IC’s datasheet.

circuit

But I still didn’t have the answer to what I was actually curious about – what went wrong? I used my multimeter in continuity mode to check the connections between the wires and the components. The AC (input) terminals of the MB6S were short-circuited. However, there was no electrical connection between the wires attached to the board and the MB6S input terminals. If the lamp was to work, there had to be a connection so that the power can be supplied. So patiently from the input terminals I kept check continuity to see where the break in connection was. And not surprisingly the break in connection was exactly above and below the circular hole (the hole is there to provide space for the mounting screws). Like a detective, I had enough evidence now to judge what went wrong. This is what I think happened – An abnormal transient in the AC supply made the voltage higher than what the diode is capable of blocking. Therefore the diode breaks down creating a short-circuit between the supply lines. This draws a lot of current through the wires to the IC input terminals through the PCB trace around the circular hole. The huge current produces most heat where the PCB trace is narrow (above and below the circular hole) since the resistivity is comparatively higher there.  The huge current burns the plastic solder mask resulting in the charring and the narrow metal film ‘melts or vaporizes out of contact’.

If my deduction was right, simply replacing the bridge rectifier would make the lamp work again. So, I used the commonly available W10 bridge rectifier which is more bulky but has far greater tolerance (1000V) than the MB6S (600V).

20151216_194513   20151216_200604

I soldered the supply wires to AC terminals of the W10 and then soldered the DC terminals of the W10 to the correct DC terminals on the lamp. After all the soldering, came the moment of truth. I connected the AC supply to the mains and switched it on.

20151216_201158

It worked and I was right! Then it was a matter of finishing things up with some hot melt glue to insulate all the metal terminals and prevent the wires from excessive movement (which will eventually cause any soldering to wear away and break contact). Then I tucked the wires and neatly assembled it back into the recognizable lamp.

20151216_202540   20151216_203048

Finally, the mounting screws went in place and the lamp was as functional as it used to be. As simple as the lamp might be, it was still interesting to reverse engineer it. Only when I understood the circuit, did I find what could have gone wrong and only when I understood what went wrong, did I find a way to undo it. The end result is that, I basically salvaged a lamp but this is one of those cases where the process is much more rewarding that the result itself.

20151216_204113

 

HP07 Digipot Interface Module

Standard

This is the first product design work that I have done and I did it for the auxiliary project (also called mini-project) required for my bachelor’s degree in my 7th semester. From the outset, I had one idea set firmly in my mind – “my mini-project should be a mini-product”. So, I wanted to create a module and spent 2 months designing an RF transceiver. In the very end, I realized I couldn’t fabricate it at home and had to scrap that idea. But, I was certainly not gonna back out and then this one came to me.

This idea is an interface module for digital potentiometers. Digital potentiometer ICs are those which enable you to control a potentiometer (simply a variable resistance) digitally. It is used in applications like digital control of an amplifier’s gain (especially for instrumentation, isolation amplifiers), voltage references etc. The snag is, most common digital potentiometer IC’s use an Up/Down counter interface that many hobbyists would need time to get around. So this module is designed to provide a selectable parallel/serial interface to the user. Also there is an on-board DIP switch that can be used to set a resistance directly. For example, if I had a mechanical potentiometer and wanted to set a particular resistance, it would be impossible to do so without measuring it. In this module, if you provide the correct binary code on the DIP switch, the resistance is set to that value automatically.

This article is about my experience of the ‘product development life cycle’ that was required to make a working prototype of the module. In the beginning, I spent a couple of days on finalizing what my module should have and should do. Once I settled that, I chose to use the ATTiny861 micrcontroller as the brain of the module. Then, I began writing the code for it and simulating it in Proteus. After several bouts with the USI (Universal Serial Interface), PCINT (Pin Change Interrupts) and WDT (Watch Dog Timer), I finally got a working version of the program in simulation.

simu

Then came the breadboard where I soon realized that the simulation wasn’t exactly accurate. I had to make subtle changes to perfect the design. Over the course of another day with repeated testing (using the NI myDAQ), I completed and finalized the complete working version of the embedded C code for the microcontroller. Subsequently, the schematic or circuit diagram was also finalized.

20151009_195234 20151008_213208

The next step in the design process, is the PCB design. Since, I was creating a module, I wanted the PCB to be very compact and dense. I ended up creating a 34mm by 42mm double layer board using EagleCAD and the layout looked like this:

Myboard

After this comes PCB fabrication and I did this in my own ‘facility’. I printed of the two layers of the PCB and transferred the routes to a copper board.

20151015_185832Since it is a double sided board, I transferred the top layer on one side of the copper board first. Used that as a reference and drilled necessary holes onto the board. Now I aligned the copper board holes with holes on the bottom layer paper and then transferred the back layer as well.  The  Toner transfers are not always perfect and so after some heavy correction work, this is what the bare board looked like:

20151016_143405   20151016_143415

Since I have already written an article about PCB Fabrication at home, I am gonna skip past that. But just for the sake of mentioning, the process continues with etching followed by mask removal, trace corrections, via connections, tinning of pads, component assembly and soldering (simultaneous trace and continuity corrections too). After a lengthy spell of hands-on work, the module was finally complete.

20151017_164636

Now, the last phase of design – final testing. I connected the P/S mode select, DIN and CLK pins to the myDAQ for providing the necessary signals. I also used the myDAQ for measuring the resistance similar to the way I tested the breadboard version.

20151018_181438 20151018_205214

And to my great joy and disbelief, it worked. Here is a demonstration video:

Thus, I finished my very first product. I went through all typical stages of a product design and now I am generating the gerber files to have it manufactured and eventually sell a few, if possible. Since no true design process is complete without documentation (ofcourse I wasn’t gonna leave that), I have attached my user manual for the HP07 Digipot Interface Module.