The Anti-Latchup Circuit


In electronics, a power supply (for example, battery) usually has a positive line and a negative line. One is not supposed to connect these two with each other because a lot of current flows through and it damages everything. It was in my third semester that I got my very own power supply and it wasn’t long before I accidentally blew it in the above way. So at that time, I started to design a circuit that will provide some protection in such scenarios. But I just lost touch of it as I moved on to other things.

Then the same requirement arose for my second project during my internship at TIMA labs, which specializes in radiation effects on electronics. When electronic components are bombarded with neutrons, it creates faults that is similar to connecting the positive wire to the negative which draws a lot of current damaging the device. This effect is called latchup. To protect both the power supply and the circuit under radiation test, an anti-latchup circuit is needed.

schemeit-project (1)

My Anti-Latchup Circuit

Technically, it is a mix of current sensing and switching techniques with a resistor programmable current limit. For sake of simplicity, let’s skip past that and its working. The power supply, say a battery, is connected to the loose ends on the left and the circuit to be tested is connected to the loose ends on the right. In the absence of this circuit i.e., connecting the battery directly, if a fault happens a large current will be drawn and it can damage the circuit and the battery as well. But with this circuit, the current is never off limits and thus both the circuit and the battery are well protected.

In the video, the black and read wires are the leads that power-up the circuit under radiation test. A fault is artificially created by connecting the two wires and instead of damaging the power supply, the current is moderated at 1 ampere. The rattling sound is due to the relay that is doing the moderation.

I wish I had done this before I blew my power supply, but as the saying goes: it is better late than never.


Using Raspberry Pi as a Validation Tool in Radiation Experiments


This was one of my projects during my internship at TIMA labs, Grenoble. TIMA labs specializes in analysing the errors created in memories and other semiconductor devices when exposed to radiation in the form of neutron beams. The lab, in collaboration with Universidad Complutense de Madrid (UCM), had developed a Fault Injection Tool that can simulate the errors that a neutron beam creates without the neutrons at all. So, the question at hand was, how well does the tool simulate the errors and that can’t be known until both errors created in both ways are recorded and compared. Enter Rapsberry Pi (henceforth referred as RPi). The RPi is used as the remote computer that will detect and store the errors for later processing. Therefore my job was to basically write a python script (because RPi’s run Python scripts not C) for the requirement above. The primary platform, on which the experimentation will be done, was a FPGA board. The idea was to load a circuit onto the FPGA, make the RPi feed it inputs and store the corresponding outputs. The correct outputs for each given input will be stored as a GOLDEN file while subsequent trials will involve errors by either radiation or simulation (by the Fault Injection Tool). The RPi will feed it inputs, get the outputs and check if the output is correct with respect to the GOLDEN file. If not, it assumes an error and stores it along with the position and time of the error in an ERROR file.


On the left is the FPGA board to be tested whereas on the right is the RPi.

The correlation between the error files from the simulation and the actual test under radiation will be evidence of how well the Fault Injection Tool works and hence its performance can be validated. A sample of how it looks like is seen the photo below. The black window is the actual console where the input and output sequence is seen in real time. To the right we see, the error.txt file with the log of all errors that were detected.


The console and error file windows with the program text in the background.

Unfortunately there is no video of this process because it is too long. So I have attached the python code: io

Wireless MPPT through Xbee


MPPT stands for Maximum Power Point Tracking and it is a highly efficient technique used in the solar energy domain. Intuitively, what MPPT does is to literally draw as much power as possible from the solar panel. Power is, by definition in the electrical domain, the product of voltage and current. So, what MPPT or at least the tracking part of MPPT does is to vary the voltage using a converter (usually a buck converter) and look at the corresponding values of current. Then it (it being a microcontroller) calculates their product or power and decides the combination of voltage and current where the power obtained is maximum. Then it operates the circuit at that maximum power point for efficient functioning. MPPT, fundamentally, is an algorithm that runs as a program in a controller to achieve this maximum power state.


This is my implementation of a MPPT system. Even in MPPT, there are many algorithms like incremental conductance etc. However, I used the Perturb & Observe method. Quite simply put, the controller keeps slightly changing the voltage (perturb) and checks if the power increases or decreases (observe). If, power increases it continues to change the voltage in that way until it reaches a peak point which is the maximum power point. In theory, I haven’t changed anything with regard to MPPT, however I added an Xbee module to allow wireless data transfer.

So what this system does, is to get the electrical data about voltage & current and transmit them to any remote computer. This is exceptionally important for day long analysis that can be carried out efficiently only by a computer when it would be impractical to leave a computer under the sun for an entire day. In my implementation, I chose to do the analysis in Matlab but the applications can be diverse. Anyway, the main purpose is the same – transmit data wirelessly to any processor (in a more sheltered place) for analysis and by extension detailed calculations.

ARM & CAN Bus based Automotive Data Monitoring System


This system uses two ARM microcontrollers, specifically the TM4C123GH6PM. One of the microcontrollers performs the function of data acquisition, while the other focusses on data rendering. This system is designed for automotive purposes, where data is collected from several sources. This data is then sent to another controller that uses it to make decisions and run an user display. This transfer of data happens through a CAN bus. CAN stands for Controller Area Network and it is essentially a 2-wire communication protocol.

In the data acquisition end 4 sensors are used – ultrasonic, temperature, pressure and a photocell (LDR). The ultrasonic sensor is to be fitted to the rear of the vehicle. It is similar to a Rear Parking Assist, except that if the distance is too less, not only does the buzzer go on but also the motor (assuming an electric vehicle) will stop.
Temperature sensor measures the cabin temperature and the pressure sensor measures tyre pressure. These data are not used in any particular decision making. They are simply shown on the display.
A photo cell acts as light sensor and if the external ambiance is low it automatically switches on the headlight. This is the basic purpose of the system. The decisions regarding rear distance and light are all taken by the data rendering controller. For example, depending on the brightness of the environment (sensed by the LDR and transmitted by the data acquisition controller) the data rendering controller switches ON/OFF a white LED that represents the headlights.
Conceptually, the data acquisition controller gets the data from the sensors and transmits it to the data rendering controller. The data rendering side then makes both decisions about the motor and the white LED. All these parameters are displayed in a 16×2 LCD display by the data rendering controller, where D- stands for distance, L- stands for light, T- stands for temperature and P- stands for pressure.
This is the ARM and CAN bus based system for Automotive data monitoring. Several enhancements can be made with more sophisticated sensors to monitor several other data. However, this is the fundamental setup.

Speed Logger


This “device” is a combination of a speedometer, an odometer and a logging system. A typical speedometer displays the instantaneous speed. This device is a bit different. It measures the speed at defined intervals of time and displays it. But more importantly it takes the speed and selects the range it belongs to. For example 0-10, 10-20 kmph etc. are speed ranges represented as 1, 2 and so on. That particular range is then incremented. The values in each such ranges are displayed as a histogram. Thus this system provides a spectral view of the time spend in each speed range. This system has been visualized using an Arduino to communicate with the Matlab software on the computer. The PIC microcontroller runs the LCD display to show the user what speed is being simulated. That speed is transmitted to the computer through the Arduino. Matlab then gets that speed, selects the range, increments it and produces the updated histogram.

E.g.: The potentiometer (in the video) simulates the speed of the vehicle and it is shown in the LCD display. The speed falls in a particular range and thus that value is incremented. If the checking and updation is done every second, then the values in each range represents the number of seconds the vehicle spends in each of those speed ranges. Thus we get a speed logging system. Why is this system an improvisation? The current system tells only the distance travelled (odometer). However there is no measurable way to determine how that distance is travelled – at what speeds? Travelling 2 hours at 50 kmph will show the same result as 1 hour at 100 kmph, but travelling at 100 kmph is definitely more rash. This system, since it logs the speed, is a definite way to determine how the vehicle has been driven. Its implementation in bikes can help parents monitor rash driving. It can also help governmental  transport agencies monitor how their public transport vehicles likes buses are driven. The major use is to foster safety through data monitoring and logging. Obviously, speed isn’t the only factor in safety and so it’s a natural conclusion that logging speed might not have a huge impact.

The real safety provider is human psychology. For example, writing an exam with or without an invigilator, the students tend to follow the rules or cheat respectively. Therefore, its a psychological factor that when drivers know that their speeds are being logged, they will be less prone to rash driving. However, the system itself presents a way to integrate both a speedometer and an odometer, providing the functionality of both and a little more as well (logging).

C for Beginners


This is my second book but my first practical ‘reader oriented’ book. The first book was a short thesis that barely nobody has read, but this book is one of the special things I have done.

To begin with, this book is aimed at people who are about to learn C and for those who have “learnt” and passed their exams but still don’t quite have an idea of what the deal is with C. Therefore I wanted this book to be as engaging as possible. The purpose of this book is to give the reader a seamless way to learn C. The fact that the content is only broken down into chapters for namesake, is to exuberate continuity. The same can be said for the order in which the book approaches its end. But, there is a table of contents available for anybody to search for something particular instead of reading the whole work again.

As a student, I was not particularly fond of loads of examples right after each and every syntax that was discussed. Programs are included in between texts but the number of programs is greatly reduced to not scare away a less persistent reader. I would like any  reader to approach the book in two parts – the first being the text which is to tell and explain what they have to know about C and the second being the additional information in the appendices and the stack of programs at the end for the more interested reader. It is often student mentality to feel insecure after pages of programs that illustrate a one line definition. I wanted to avoid that and for that reason limited programs are explained in great detail in between texts. In a crisp way, the main text contains what one “needs” to know and the appendices & programs contain what one “should have” known about C.

A lot about C is said in countless books and though I know this is not by any means an extensive work. I hope that any reader after picking though this book (at least the textual part) is left with a fulfilling experience of learning the fundamentals of C and thereby set themselves up for any advanced course in programming.


One's face might not last forever, but one's name should! //hp07

One’s face might not last forever, but one’s name should! //hp07

Working with the 16-bit PIC24F


I started my microcontroller (uC) journey with the ‘AVR’ and then made it a point to diversify into other awesome uCs. Naturally, the next stop is the famed Microchip’s PIC – Peripheral Interface Controller. Now, when I say PIC it is almost always assumed (in India especially) to be the PIC18F series mostly the PIC18F4570 etc. It so happens that these chips are 8-bit architectures like the AVR (they are classic competitors).

A lot and I mean a lot has been done with this PIC series (18F) to the point that virtually any circuit that can be done has been done and posted on the internet. So, to spice things up a bit I chose to work with the relatively unknown PIC24F series. This series features a 16-bit architecture with superior features (PPS – Peripheral Pin Select is the most remarkable in my opinion) and performance than the 18F. Specifically, I chose the PIC24FJ64GA002 and the best thing for me was, there is not much ready reference circuits or programs available for this microcontroller.

What have I done? I repeated the exact same experiments that I did with AVR. The output is the same but to achieve it was a task, my word, far more difficult to accomplish. And since the output is the same it might be a little boring to see the videos of the hardware implementation, so instead I have posted screen recordings of the simulations (using Proteus).

Since descriptions of the experiments were already written in my AVR article, I would not like to repeat them here. So onto the experiments then.

Simple I/O:

The simulation shows an LED blinking (output) and when the switch is pressed (input) the LED is held on which is truly a simple case of input and output.


As a part of only output programming, here is an LED matrix display that is programmed to display ‘hp07’. The hardware part for this is too straight forward that I stopped with the simulation. 


Curiously, Proteus is capable of simulating LCD displays too. As the potentiometer is moved from the minimum to maximum resistance position, the voltage varies from 0-5V and that is read by the microcontroller using the ADC and it is displayed.

DSC03992   DSC03991


Proteus can also simulate oscilloscopes that show waveforms. Therefore instead of showing a variation in LED brightness and motor speed (that can barely be seen), the simulation shows it better. You can notice how when ON time (in the waveform) is longer, the motor rotates faster and slow during shorter ON times.


I recently got an instrument called logic analyser that can be used to practically visualize the waveform too. I have a computer interface based one and therefore the screenshot of the waveform:



Ofcourse, I have to end with the same button presses counting game. When the count button is pressed, a counting interrupt routine is executed with the red LED glowing that counts the number of times the button has been pressed.

And when the transmit button is pressed the data is transmitted through the Universal Asynchronous Receiver Transmitter (the green led glows during this routine). The other microcontroller receives the data and displays it with the help of IC 7447 and a common anode 7 segment display.


The count is re-initialized to zero after every transmission.

And therefore I finished my experiments with PIC. Yea, I did the same experiments as with the AVR microcontrollers. It is easy for me to use a thermistor instead of a potentiometer and post it as a digital thermometer in the ADC experiment. But all that is technically trivial manifestations of the base which is the ADC module. What matters is the program and the base circuit to get it to work and I have done that – therefore mission accomplished!

The videos of the hardware implementation using PIC is on my youtube channel: