Saturday, January 21, 2017

The Solar Misconception

Let’s just breeze over the fact that I am terrible at maintaining my blog. I know that. In my defense tho, I can say that my Linux work laptop is still broken.

Somehow the display driver of the board went kaput. OEM replacement was costing me too much so I went for a local repair. BIG MISTAKE. Although the laptop boots up, something is messing up the thermals. The temperatures reach up to 105 C and the fan never even attains full speed for max cooling. I even tried running water over the CPU block and northbridge in thin copper vapor pipes.

Yes, I am liquid cooling my laptop.

But even that did not work very well as for some reason, the pump seems to fail ever so often. I have more or less given up on it unless I can find a better pump. Any better ideas for this?


But again, that is not the only thing I have been busy doing. I was curious with all the fuss around the ESP8266 and Lua(?) and NodeMCU and things like that, so I wanted to check them out.
Just recently I got NodeMCU v0.9 and I started experimenting with it. It turned out to be great little wifi Arduino kinda thing and if used with Blynk, practically anyone can make their own IoT controlled appliances. It's good fun!

But again, that was not even close to the main thing I was doing, which of course is, the Desk Project.

Please concentrate on the lighting effect. Also, this is an old photo, so you see the old speakers.


I was cleaning up my desk space, which as you can see from my previous posts, was a bit too much of a mess of wires and solder blobs popping out everywhere. Even the wire colors were mismatched. So I decided to clean it up, and maybe make some small upgrades in the entire system, make it more foolproof.

Side note:- Talking of foolproof, I blew up my 300w ATX PSU. It had something to do with PWM whines/signals traveling back to the ground pin of PSU and damaging the capacitors over time. I cannot confirm because I don't have an oscilloscope. But the speakers attached with the system also made the whining noise, so that is how I guess it is what it is. Since the whole system is juiced up now, I don't really need a PSU, but I'm still using it as the wires are a very useful distribution system.

Anyhow, time for the final reveal, My desk space v2.0, (I think)

Notice the Sub hidden behind the pen stand. Some more tiding up of wires is required, But its much better now.

Let’s go over the changes slowly

Firstly, there is a (kinda) new battery. A Rocket 12V 26Ah SMF pack provides all the juice for anything I may ever need.

I hot glued a wood peice to the battery, and screwed on the charge controller. Now that I think about it, there is something called double tape as well.


Then there is the new charge controller I got, a 10A PWM charge controller. It turns out that the way I was using the previous charge controller with the battery and the load connected was actually very bad for the battery and has considerably damaged them. Plus my second mistake was using 2 diff batteries in parallel. Don’t do that. This controller, on the other hand, has independent PV Battery and Load lines, all PWM controlled. It also has a 1 amp USB port, which I am using to power the next thing on the list.

A big battery also requires a bigger power source, so I replaced my old 5 Watt panel with a decent 20-watt one. However, there is a catch and I will discuss that later.



3 current sensors, with 3 voltage dividers attached with them. MOSFET to control the LCD Backlight. All controlled by an Arduino Pro Mini

This is a masterpiece. Really. It’s an Arduino pro mini, which has 3 ACS-712 current sensors and 3 voltage dividers which measure the current and voltages on each of the solar charge controller lines and give the net power in Watts for each channel. That is, how much the PV is generating, How much the battery is charging, how much power my load is consuming. Not only that, I was bored with having to adjust the LCD backlight intensity myself from time to time, so I also added an LDR which is then used to control the backlight intensity as per the ambient lighting. That means that I am using nearly all of the Arduino pins to get this to work, and after some initial difficulty of coding with arrays, the whole system is now nearly perfect!

Notice the small LDR just above the Chinese text on the LCD.
-ve Current is because the battery is charging up, so reversed direction of current.
Also causes the "W" to get displaced.


I am storing all the ADC values in individual arrays and then taking a running average of those values. Kind of like the Arduino smoothening example, but applied to all 7 ADC pins of Arduino. That allows for consistent reading and stable values on the display.



The Left side PCB is the LED Driver and Distribution board.
There is another Pro Mini and an HC-05 Bluetooth module now.



Next change is the LED Driver board, the one with the 6 MOSFETs and central wire tappings. This is now modified as a common power distribution board as well as allows the 2nd Arduino Pro mini to control the RGB Strips as well. They were Pi exclusive previously.

The last change in the addition of a 2nd Arduino in the system. This is now a standalone Bluetooth connected device which I use to change the intensity of desk lamp, RGB strip or turning the speakers on or off.

Oh yes, the speakers! Gone are the Creative sbs380 and now I am using a 2.1 channel Harman Kardon speaker set. Notice the Sub woofer hidden behind the books. Audiophiles would say that I am blocking the sound, but in reality, the sound isn't affected that much. The only downside is that the tweeter units are quite directional and the wires are fixed in the speakers and the sub, so it is a bit of a mess, as you can see...

I want to clean up the right side a bit better. Maybe use wire casings?


Another side note on the foolproofing, I added directional diodes in my circuits so that back powering is avoided. Previously, if I powered on the RGB Strip, the sound organ Arduino automatically got powered on, because it is linked to the same RGB strip. Adding a simple 1n4007 fixed that. Evolving circuits, you see.

MSGEQ7 circuit, hidden behind the monitor on the second desk. Notice the Diode and the cut in PCB.



Now that I have thoroughly shown off and bragged about a mildly not-so-boring system, I want to talk about the Power source of everything here. The Sun.

No really. Since all of this is powered by a giant open fusion reactor, I want to talk about how I, and in general, many small scale SPV users are being “cheated” just a teeny bit.

Since I got a big battery (relatively), I knew that my old panel and my charge controller won't be able to charge it properly. I had anyways thought of getting a new, or I should say a proper charge controller, so I sneakily ordered a 20-watt solar panel as well.

For Indian readers, both SPV and controller are from a company called Sparkel. No sponsorship but I wish I had it.

:P


I was really excited when my parcel came, in some amazing huge bubble wrap. Anyhow. When I hooked up the panel, I had in mind the thought that my existing battery set would take only 1/4 the time, since the panel was now 4 times more powerful. I was wrong. I checked the open circuit voltage and the short circuit current of the panel, and it was more or less matched the spec sheet.

The Datasheet of my SPV module. Quite useful!
If you know what you are looking for.


I thought that maybe the old charge controller is at fault, and can regulate only so much... So I proceeded and replaced that with the 10A controller as well.

After some observational period, I realized that the time to charge the batteries has improved, but not by a factor of 4, as I expected it to, but only by around 1.5 or 2. Something was definitely off.
So I got to work.

Having initially checked the open circuit voltage and short circuit current, I wrote an email to the company. The folks replied with a very detailed answer and a proper data sheet from the OEM. Great! They also suggested that I take measurements when the load is connected since the panel will then operate at max efficiency, A fact I already knew, but was too lazy to test.



However, after the first email, I did actually measure voltage and current values with just the solar panel and the battery hooked up. Prepare for numbers!

Since I am using a 20W panel, I was expecting around 16-18 watts of power that would be supplied to charge up the batteries. When I hooked up my multimeters, I was getting a peak power output of around 11W only.

WHAT?

All the conspiracy theories started popping up, that maybe I have a defective piece and so on and so forth.
However, once I checked the voltage and current that was being drawn from the solar panel, I realized that the panel is not reaching its rated peak power output. So maybe again the panel is defective...

The basic thing that I was forgetting at that time was that the charge controller was a PWM based controller. The way these works are as follows:-

The SPV module in ideal conditions is rated for 17.5V and 1.12 A, under maximum load. That gives a power output of roughly 20W, the actual rating of the panel. However, when a Lead acid battery needs to be charged, it is usually done using CV or constant voltage charging. That charging voltage, although dependent on diff manufacturers, is usually in the range of 13.6 to 14.5V

What the charge controller does, is that it takes the raw input from the PV, a plain DC line, and then chops it up into small pieces of PWM signal, using a MOSFET. It's the same way we use to vary the intensity of LED Lights, by PWMing the voltage.

For example, a 50% duty cycle of PWM for a 12V source will effectively give a 6V signal. So the 12V LED connected in such a way will be approximately set at half brightness level. Not exactly half, because that depends on the characteristic curves of the LED, but you get the point.

In the same way, the charge controller, which receives a 17.5V signal, will chop it using PWM and will automatically set the duty cycle so that the output from the MOSFET, which is used to charge the battery, is maintained at around 13.5V or so.

Should be self-explanatory



Nice little simple trick. But this means that if 17.5V is reduced to 13.5V which implies a 33% drop of voltage using PWM, then 33% of the total current that was previously passing is also cut short because effectively the panel is not charging the battery for 33% of 1 complete charge “duty cycle”. For 33% of the time, the panel is practically dead.

This implies that if for my particular setup, 20W of power is PWM'ed and reduced as per the voltages required mentioned above, 33% of the 1.12A, that is around 350mA of the current that can be generated is available but actually never used to charge up the battery. It may not sound like much, but 350mA is actually quite a lot, and incidentally current required by a 3W high power LED, which as we all know, are pretty darn bright.

It's not that the panels are bad or the controller is bad, its just how it works. A solar panel can give max power at a certain voltage level, and due to design constraints and FoS principles, the max power range of a panel is designed to be at around 17V for 12V panels. Since there is no actual power conversion method actually inside the PWM controller, it effectively disconnects the supply after the set duty cycle, or at the set apparent voltage. Thus it prevents the panel from actually working at its peak efficiency so that the battery can be charged safely.

So if 350mA of current is never used and it is or can be generated by the panel at 17.5V, the apparent loss of power due to PWM is around 6W. Damn, that is more loss than my previous panel was actually producing! And taking this fact into account, my measured power reading of 12W of charging power made sense, since 12+6 =18W which is roughly what I was expecting out of a 20W panel anyways.
MPP - Maximum Power Point, so by default, maximum efficiency

I must state that the company from which I got the solar panels and the charge controller was very prompt and helpful and they made me realize the fallacy of my thinking process about the power output and things like that.

So I think that effectively all the small scale solar users, who are using PWM based controllers, are not actually getting the power output that they are expecting.


I say small scale because, for large scale uses, the losses of PWM would be too much. If the system is 12V, the loss of power is around 3W for every 10W the panel can produce. So for a 10kW SPV system, there would be 3kW of untapped solar energy, Which just does not make any sense. So, large scale SPV plants use MPPT charging methods. Fancy name. It stands for Maximum power point tracking. Fancy full-form as well.



What MPPT is actually doing is using a simple DC-DC Buck converter. This allows the panel to be operated at its maximum power output level at all times, in my case, 17.5V and 1.12A, but “bucks” the output voltage to around 13.5V Now you may say, that even PWM is doing that. Correct, but PWM controllers actually decrease the power by reducing the time the current can flow, MPPT is converting power, and by reducing the voltage, it actually increases the current at the output.


Remember transformers? AC transformers? 1A at 220VAC is the same amount of power at 2A 110VAC? That is what the buck converter is doing for the panel and the battery.

When I hooked up a buck converter directly to the panel, I got the following results

Direct Panel connection
Voc = 21.2V Open circuit voltage
Asc = 0.93A Short circuit current
W = 19.5W Not exact as panel is not under load, but good enough for general comparison

After Buck conversion to 13.5V
Voc = 13.5V
Asc = 1.3A
W = 17.5 W which is 6.5W more than the PWM charge method.

Which is only a 2W loss in power as compared to 6W. This means using a buck converter, I can charge my battery with 4W more power from essentially the same panel. Crunching some more numbers, I get to the fact that PWM charge controllers will get limited to about 70% of peak efficiency, whereas MPPT controllers can touch 95% or plus efficiency.

A simple Buck converter. I used this as a test bench for MPPT design.
Actual MPPT charge circuits are much more complex, and usually, have buck/boost working side by side.



Why isn't MPPT used then? It is, but the cost factor in small scale usage prevents a complete replacement of PWM based systems as they are cheaper and simpler to make and maintain. For large scale and commercial systems, MPPT controllers are the obvious choice. In these cases, the working voltages are also increased to 24V or sometimes 48V, for off-grid systems.

Do I want the extra 4W of power from my panel? Obviously.

Will I do something about it? Maybe make my own MPPT controller? I don't think so because I just don't have the time as of now.

Sunday, July 3, 2016

BONUS! Driving a High power RGB LED from Arduino only.

While I was working on the hardware side of the Sound Reactive LED lights tutorial, my friend decided to make one for his room as well. So hopefully I'll manage some better photos of the build process for that.

In the meantime, my Linux work laptop decided that I was being too productive in my vacations and decided that I should go on a break. Hence, I am struck with just one laptop now. I know, I sound crazy, but once you have used 2 computers simultaneously, having just one makes you feel restricted. Same goes for those insanely cool multi-monitor rigs.

Anyhow.

Along with all those components needed for the sound reactive lights, I had also ordered one small little thing. A 10 Watt RGB LED Module. These are classified as high power LEDs and it is required to use a proper heat sink with them as they get very hot. I used to wonder how hot can a 90% efficient device can be, so I tried to power it without a heat sink.
At 300mA for 3-4 seconds, the back plate of the LED got so hot that it burned my finger when I touched it. WOW!
Not to mention that these things are INSANELY BRIGHT! You cannot really directly look at them without hurting your eyes and going blind for a second afterward. And that is for a 10 watt LED. 100 watt LED's are also available and I can only imagine how bright those are.

Why did I buy one? I was curious.

The main issue with these high power LED's is that they require special methods to receive power, And are very sensitive to the power input. That is why you cannot simply attach them to a battery to make them work. Nope, you need a Constant current power supply to get the most from them.

Theory Time!

LED stands for Light Emitting Diode. It's a DIODE.
Remember Ohm's law? Stating that "For a given voltage, the current flowing in the circuit is dependent on the resistance" or mathematically V=I*R. Basic electrical law.

Also, remember that Diodes and other semiconductor devices do not obey the Ohm's law. What that means is that for a material obeying ohm's law, the V-I graph is linear. For something like a semiconductor, it's non-linear.

Values are not important. The nature of the curve is, which is linear here. This is for  normal resistance, following Ohm's Law


See the graphs on the right. Non-linear, and different for different colors.
The Dashed line represents the max efficiency current. Hence, constant current power supplies are required.



So what's the big deal? Well, for diodes, a small voltage change can cause a huge increase in the current. And as that current increases a certain limit, The diode junction is bound to get damaged.

That is the reason there always is a resistance in series with the LED, usually of a value of around 150 ohms, whenever an LED is to be used with Arduino or a Raspberry Pi. It limits the current flowing via the LED and protects both the LED and the board, by protecting from over-current.

Simple resistor, used to limit current to the LED


Neat solution. But this works only for low power LED's, typically those 3-5mm LED bulbs. What if we use a resistor to regulate current for a high power, say 3 watt LED? You need a big resistor. And I don't mean a big value resistor... I mean a resistor that can dissipate quite a lot of heat, without getting destroyed. Normal electronics resistance are 1/4 of a watt. For a 3 Watt LED, you need roughly a 5 Watt resistor. So to drive 3 watt LED, you end up wasting another 5 watts as heat. That's not very efficient, is it?

RGB LED strips have small resistance in the strips itself. hence we can simply connect it to a battery and it will work fine. That is not the case for high-power LED modules. They just have the diodes in them and no resistance is included, which makes it necessary to have a high power constant current source to power them. And you cannot simply connect them to a battery. They will burn out within a couple of seconds. Even more importantly, for RGB LED's, there are different forward voltages for different colors. For example, the LED I got had 4V for Red, 7V for blue and 9V for green. Those are the forward voltages. The forward currents were 350mA for each color. At such high current, there is no way that I can simply put a resistance in there.

Another solution is to use something like an LM317 as a constant current power source. That's a neat idea, but again it gets limited to about 100mA of constant current. Anything over that, and you will need a heatsink on the LM317 and again a high watt resistance. So that's also not a viable solution.

Yet another solution, one that is used commercially in LED light bulbs on mains is to use a DC Buck converter with an Op-Amp to get a constant current source. Such breakout boards are easily available on Amazon and EBay and have a precision potentiometer to tune the voltage and the current output of the buck. They can also supply around 3 amperes of current without the need of a heat sink. All this makes them ideal for constant lighting application, where there is just one color LED and that too is maintained at a constant brightness, just like a normal light bulb. For RGB LEDs, you need 3 of them, and there is no way to control the brightness other than manually changing the resistance values, and even then, most of the RGB LEDs won't work because they are the common anode type, that is single +ve and 3 -ve lines per color.

Commercial solution for Driving LEDs
Notice that Voltage is variable, but the current is fixed at 300mA. That means this supply can work with 3-5 watt LEDs


So it seems that if you want to drive an RGB LED, on a budget (I AM ALWAYS ON A BUDGET), there is no easy way to do so....  or is there?

There is. A very simple way. So simple that I did not even think of it.
The answer yet again was PWM.

So I loaded up the Arduino, connected the MOSFETs and the potentiometers, wrote a simple code to change the duty cycle of the PWM pulse as per the value from the potentiometer, and hooked up everything to my 12V 300W ATX power supply.

I used the following:-

  • Arduino Nano
  • 3X IRFZ44N MOSFETs
  • 3X 10kOhm Variable Resistance
  • 10 Watt RGB LED Common Anode (+ve)
Here is the final circuit diagram. P.S. I'm new to Fritzing. Yellow Wire is +12VDC. Black is ground.


The LED module is at the top. I could not find something similar to what I have, but the connections are similar..


You might think that connecting a 7V LED to a 12V line capable of pushing nearly 20A of current will surely blow out the LED. You are correct, but what you are missing is that it's not connected directly. There is a MOSFET in between that will regulate the power delivered to the LED. Of course, make a direct connection if you wish to see smoke and stuff.

Since I had no idea that how much of the duty cycle will result in how much current, I added a serial monitor output that gave me the duty cycle of the PWM on the screen of my laptop. That way, I could see the duty cycle of the PWM.

Here is the sample code, with the fixed values for my case. Yours may vary. Check accordingly.

int redled = 9;     //red channel to D9 of arduino
int greenled = 10;    //green to D10
int blueled = 11;    //blue to D11

int redPin = 0;        //red pot to A0
int greenPin = 1;       //green pot to A1
int bluePin = 2;        //blue pot to A3
int pred,pgreen,pblue,lred,lgreen,lblue;         // variable to store the read value

void setup()
{

  Serial.begin(9600);
  
  pinMode(redled, OUTPUT);   // sets the pin as output
  pinMode(greenled, OUTPUT);
  pinMode(blueled, OUTPUT);
}
void loop()
{

  pred = analogRead(redPin);    //reads the ADC values coming via the pots
  pgreen = analogRead(greenPin);
  pblue = analogRead(bluePin);

  lred = map(pred,0,1023,0,90);     //maps the ADC to pwm duty cycle
  lgreen = map(pgreen,0,1023,0,190);   //0,1023 is the adc values
  lblue = map(pblue,0,1023,0,145);      //0,90/190/145 are the pwm values

  analogWrite(redled, lred);      //output to the Digital pins for PWM
  analogWrite(greenled, lgreen);
  analogWrite(blueled, lblue);

  Serial.println(lred);      //prints the PWM duty cycle in serial monitor
  //Serial.println(".");
  Serial.println(lgreen);
  //Serial.println(".");
  Serial.println(lblue);
  Serial.println("  ");

delay(100);
}



Next, I simply connected my Multimeter in series with every color channel one by one and started to increase the duty cycle by rotating the pots. As soon as the current reached 320mA, I recorded the PWM Duty cycle for that color, via the serial monitor of Arduino.

Completed circuit. A bit of mess, but minimalist.
Proper heatsink with thermal conduction paste in between is a MUST!

The net result

The front of the LED is perpendicular from me, Its daytime, and you can still see lens flares here.
And this is 1/3rd the brightness.


Repeating this for every color, I found the maximum duty cycles for red, green and blue. Next, I simply replaced the maximum duty cycle of 255 in the Arduino code to the values I found above.

Upload the updated code, and it's done! Since the PWM signal is now limiting the maximum current using the software, I can directly power the RGB LED without any complex circuit, and still, operate the LED at full intensity. There is no heat loss, and the whole system works on 12V, and I can even select what color I want, by rotating the pots. Simple!

Did you enjoy reading this? Thinking of trying it out? Some mistakes here and there? Do let me know! Feedback is much appreciated, as always.

Have fun!

Monday, June 6, 2016

Making the party room (Theory Post)

Remember when I said, "sooner than you expect?"

Well, this post here is a tutorial, like my RasPi lighting system. Actually, its more of an extension to that project really, since I am using the same LED Strips I got back then. Only now, they are properly mounted.

So what is different now? 

Have you ever been fascinated by those disco lights? Ones that change their color and intensity according to the song that is being played? I bet you have. I bet some of you even wanted those in your room. I know because I wanted one. But those system, don't come cheap. And I'm already on a shoestring budget, pretty much always. The cheaper solution is (pretty much) always to make your own. And hence, I turned to Arduino, the nifty little microprocessor.


The Arduino Nano. There are many versions available. The Uno being the most popular. You can use the Uno or the Nano. They have the same processors, but the Nano is easier on the breadboard.



Basically, What I needed to do was to split the audio into 2 signals, one going to my main stereo system, and one going to the analysis chip to break down the sound into diff parts, identifying the lows, mids, and highs of the sound. and somehow drive / light up the LED strips according to those processing values,

The first part is easy, splitting the audio signal. I just bought the 3.5 mm audio jack splitter. DUH! You can also use a microphone placed near the speaker, in-case you do not want to tamper much. But, that will also pick up the ambient noise, so will be good only in silent environment. Only thing that is required is getting a clean audio signal.


Simple Audio Splitter. You can use a microphone board as well, if you like.


Now for the second part, the signal analysis. It's a bit tricky. Especially if you plan to use an arduino only. That is because the Arduino itself is not meant for direct audio. We can however, turn it into a spectrum analyser using some pretty complex maths. Remember Fourier transforms? That's what the Arduino will have to do, hundreds of time per second, to separate the audio into different frequency bands.

Okay, a little bit about Fourier transforms...  

"The Fourier transform decomposes a function of time (a signal) into the frequencies that make it up, in a way similar to how a musical chord can be expressed as the amplitude (or loudness) of its constituent notes. The Fourier transform of a function of time itself is a complex-valued function of frequency, whose absolute value represents the amount of that frequency present in the original function, and whose complex argument is the phase offset of the basic sinusoid in that frequency."

Didn't got any of that? Me neither. In simplest terms, any sound you hear, in music, is a mashed mixture of sounds of various frequencies and amplitudes together hitting your ear. What this transform does is that it takes this sound, and breaks it into individual components of the sounds that make the original sound. For example, a drum kit will have bass, mid and treble, all together. Fourier will separate out these different frequencies so that they become a simple sinusoidal function, which can be easily processed by a computer.


Here, the Red line is the sound pattern you hear. 

The blue lines in the background are what the fourier transform does.
Breaking the main sound  into its components, so that computers can process it.




The problem however is that these transformation equations are complex. Humans, like me take forever to solve them, and even small microprocessors like the arduino may not be fast enough to calculate them for a proper song. The obvious solution is to use a faster CPU, which is done in providing visualisations of music in music players on PC and mobiles. But, we are on a budget, right?

Thankfully, there is a simpler solution. Enter the MSGEQ7 IC.


It's TINY!


What this IC (integrated circuit) does, is that it takes away all the maths that's needed and stuffs it into a tiny space, one that we do not even need to go into. 

"The seven band graphic equalizer IC divides the incoming audio signal into seven bands of 63Hz, 160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz and 16kHz. The seven frequencies are peak detected and multiplexed to the output to provide a DC representation of the amplitude of each band."



The frequency splitting graph of the MSGEQ7 IC


So, this chip solves 2 major problems for us. It splits the audio signal into 7 bands of the mentioned frequencies, and also gives a voltage output for these frequencies according to their respective amplitude. That is great, since we can use that output as a signal to drive the LED lights. And since every frequency will have a different voltage level, We can make the LEDs light up in different colours as per the frequency. Example, Red glows for bass or the low end, green for the mids, and blue for the high end.






The green chip on the breadboard is the MSGEQ7 IC
The 3 black parts on the left are the MOSFET's which are driving a simple single RGB LED. 
Here is a basic circuit diagram, if you want to start right away. Obviously, there is Google as well, so you might as well just search for this thing. There are plenty of guides on how to make one. Ofc, I'll be posting a proper hardware guide later..


Here it is in working. (What I made)







I think this might have piqued your interest,after the boring part of theory. But that was a bit necessary. Without knowing how all this is actually working, there is no point in making it. You might as well buy something off the shelf. The advantage here is that once you know why you are doing what you are doing, you can customize it however you want.

So ultimately, what we are going to do, is to feed the audio signal into the MSGEQ7 IC, let it do it's thing, Take the Voltage output of the analysed signal from the IC, and feed it into one of the Analog pins of the Arduino. Once the signal is in the Arduino, we simply take the signal values for the different frequencies and map them to the PWM output, which with the help of some MOSFET's light up the LEDs according to the beats of the song. SIMPLE!

That's probably it for the theory part. I'll be updating this with the parctical guide in the coming time as well. Stay tuned!

And as always, Feedback and suggestions are very much appreciated. Thanks for reading!

Wednesday, June 1, 2016

The 10-Month Hiatus

Yeah, I know.
10 months.

I cannot stick to a schedule. I know that as well. But, I keep on working. I may not document what all I've been doing, even though I want to, but I just don't end up having that much time to do it.

You might ask then, What have I been doing since the last post here.

It's been a roller coaster, frankly. If you guys follow me on Google+, you would have some idea as to what all has happened.

First, let's talk about the update to my RasPi Lights. (Previous post)



The Main "Brain"
This took more than a year, from start to finish, and back then, I knew nothing about anything in this pic.


As you can see, It's now more or less in its final form. Here are the basics.


  • RasPi connected to
  • BMP180 for ambient temperature and pressure
  • DHT11 for ambient temperature and humidity
  • DHT11 for room temperature and humidity



IP address at top
Readings from BMP180 (outside room)
Readings from DHT11 (Blue sensor just below the screen)
Readings frm DHT11 Outside the room, alomgside the BMP180


All the sensor reading are now recorded and stored in a web server database at intervals of 10 minutes.
Graphs of all the readings plotted in real time on the web page hosted by the Pi itself.


BMP180 readings graphs, Opened on Chrome.
Blue is Temperature, Red is Pressure
I can actually predict the weather with these!


And obviously a much neater RGB LED Driver system.
Prepare to be dazzled!



My favourite setting. There's a red Laptop missing from the table here tho.

I saw somewhere speakers from LG that had LED Lights in them. That right then was a "Challenge Accepted" moment.
Turned out to be pretty good, I think

Obviously, It's an RGB LED Strip

Not sure if this is gaming mode, or the red one is...


Usually in this setting. The LED's are very bright and I do not end up needing any additional lighting in this config.
Photos look dark because they are underexposed to -2EV



Next, There's now an Arduino Nano controlling the power to my Pi, Speakers, Desk-Lamp, which is controlled by Bluetooth.
And it also monitors the Battery Charge, current drawn and the voltage of the Solar power system.


From left to right:- Buck converter, ACS712 Current sensor, Nano, Relay board (hidden), Screen.


Yeah, Everything I've mentioned above is running off solar energy. 12 Watts panel connected to a total of 14Ah of Lead Acid battery.


Salvaged PWM Solar charge controller I had lying around. Gives a total of 150W of backup.

And no more breadboards here. Its all Permanent, Although I think I could have made it a little better with more planning. But it works fine ATM.

That's what I have done for my room. But that's not the only thing. Me and my pals were also working on a project for college.
Here it is.





Basically, what we tried is to make a robot that mimics the movements of the human arm and replicates it in a servo driven arm with at least 1 degree precision.
Its close, but calibration is quite hard, considering all the parts we are using are cheap ripoffs and no original stuff can be found here. Tough luck.








For the curious, we are again using a Nano, with 6 Potentiometers as the angle sensors, and then feeding the angles measured to servos via a PCA9685 PWM driver board.
Servos are Tower Pro MG996R (Again, not originals)

The electronics on this were easy. The manufacturing and assembly of the parts were not even close to easy. It took a lot of time (about 3-4 months), and a little blood, to get to this point here.
And the best part was, when I got to present my project, the teacher just scoffed and said that we got it made from the market.

And then people ask why India is not doing so well in R&D. Short answer, because of people like him, no one actually bothers to work.



But that's not the worst.
Along with all this, I also got involved in what has to be one of the most challenging and amazing projects I have ever heard about. The CanSat competition organized by the American Astronomical Society and NASA.

We had to design a can shaped payload, which would be  launched and ejected into the atmosphere at approximate 10km from the surface. The payload then would descent, using parachute, and at a height of 400m, a fixed wing glider should be deployed, which is recording the temperature, pressure, humidity, air velocity, GPS data every second and transmitting it back to the ground station using XBee radios, whose graphs were to plotted using MATLAB in real time. Not to mention, there was also a TTL Camera to be there in the Glider.

That sounds AMAZING, right? That's because it is. We had to make everything from scratch, test everything, pack everything in a space of nothing more than 300mm by 120mm diameter, having a weight of less than 500gm.

And I'm pretty sure we would have managed to make the satellite, possibly even be in the top 10, if it were not for some really, REALLY big IDIOTS in the team. And sadly, those idiots were my seniors, and I couldn't really do much. It was out of my control.

The work got delayed, the parts were late, there were only discussions, and no actual work had started until April, and were were scheduled to go to Texas, USA for the launch in June.

Now fortunately / Unfortunately, we were kicked out of the competition in the final round of presenting the Critical Design Review to the judges, Mostly because the guy making the presentation had english grammar skills worse than that of a 10 year old. Also, we had not actually made a single thing, and we were presenting a CRITICAL DESIGN REVIEW of that.

I say fortunately, because thankfully I do not have to deal with such level of insane and imbecility anymore, let alone stay with them as a team for 2 weeks in US during the competition.
Unfortunately, because this was once in a lifetime kind of opportunity for me, and because of them, we lost it. Not to mention the visa fees and other stuff. Those guys were just looking for a visa and I don't think that they were really interested in making cool stuff.

I should have been packing my bags for the trip, but I'm just typing away at my keyboard. Feels bad, but what are my options anyways?

One option is, to make Sound Reactive LED lights, the ones that respond and change color and brightness according to the beats of the song. It looks good!  I've already started working on it, and as of now, after spending about 5-6 hours on that, at least the basic circuit is working. 

I also got a 10 watt RGB LED module, just because I was curious, and I am working on that as well. 



It's a MONSTER! At full power, you cannot even look at it, and heats up the Intel 775 Heatsink fairly quickly.
Just  pure insane, but very fun!

And that is what I'm gonna be doing in my Vacations now. Apart from maybe a few other small things. I'll try to write some small guides here... some sort of documentation, but I can only hope.

If you guys like what you see here, Follow me on Google+! There's my Photography Collection and a basic IoT Collection as well. And obviously, its not updated once in 10 months. :P


Questions, requests and feedbacks is much appreciated.  Until next time, and it will be sooner than you think. :)

Sunday, July 26, 2015

The RasPi Lights Tutorial

This blog post is a bit special. Not only am I writing this at a time I had hoped it would be over, this one is also a bit of a tutorial or How-To. I recently posted about a small little project I was working on here, and then just a few days back, when it was nearly finished, I posted a short video about it on google+. Surprisingly there was a bit of interest shown in that. xD

Here is that video

RGB mode to RED, on top of my bigger workspace.

Same thing as above, Now in blue.

This is just a temporary arrangement. I will mount the LED strip properly later.


So, here is a Not-So-Detailed tutorial on how I did it.

Disclaimer: - I did very little coding to get the work done. Most of what I did was simply copying over and merging codes into one single file. I take no credit, apart from assembling the hardware. Also, if you are looking for an absolute beginner guide sort of this, I recommend that you check out Adafruit's guides. They are simply amazing and very easy to follow.



So my basic aims with this little project were:-
·        Web interface controlled, PWM based RGB LED accent lighting
·        Temperature and humidity data logging of my room
·        Character LCD displaying the IP address, temperature and humidity in real-time.

The character LCD was an important add-on later since I was running the pi in headless mode, i.e. without a display, and knowing the IP address is very useful, since IP addresses are assigned dynamically at every reboot by the router.

Now onto the materials. The complete list of the materials I used are


·        Raspberry Pi B+ v1.2            [Not the latest Rpi2, but it should work]
·        Edimax Ew-7811un Wi-Fi adapter
·        Any character LCD display based on the Hitachi HD 44780 chip. [It should have 16 pins]
·        Analog RGB LED strip
·        Logic Level N-channel MOSFETs. I am using the IRLZ34N.                                                                 [Any mosfet with greater than 5 amp drain current at 2.5 volts of gate voltage should do here.]
·        Appropriate power supply for the Pi and the RGB strip.
·        Wires. Lots of wires. Jumper wires, MM/MF/FF type.
·        Breadboard. You aren’t going to solder everything in the first place.


The RGB strip I am using pulls around 1.2 amperes at white colour, i.e. all red green blue LED's turned on. At 5 meters. Some strips can pull up to 4 amperes for 1 meter only.  It’s best to check with a Multimeter. I played safe and slapped a 350 watt ATX power supply to it. I used the +5VSB line (the purple wire in the 22 pin ATX connector) to power the pi via GPIO. Although I recommend that standard USB port is used to power the pi since using the GPIO bypasses all the fuse and over voltage protection built into the pi. Wired incorrectly, you will kill the pi instantly.

Again, Adafruit's tutorials are much better explained and even if you are not planning to execute a certain guide, it will be helpful in other aspects. They are just so well written.

Coming to the execution side of this little project, let’s set up everything first.
Make sure you have a working RPi, and the raspbian is updated to the latest version.

If you have a smaller SD card and on a tight budget, read the Q&A at the end of this post.

First go to Adafruit's Character LCD guide, and follow that. Make sure that you have the libraries mentioned installed and the default example is working as intended. This will work for all common character matrix displays based on the Hitachi HD 44780. Usually all the 16x2, 16x4 and 20x4 character displays. Remember the 16 pin configuration.

Next, go to Adafruit's DHT sensor guide. I have used a DHT-11 but you can use the DHT-22 or AM2320 as well. Again, make sure that the libraries are installed and the demo program works fine.

Ok, with the screen and the DHT sensor handled and working, let’s move onto the RGB LED lighting setup. This one is a bit tricky.

The best guide I have found for this is over at GitHub. But we only need the hardware part of that guide. I used a different software for the LED strip, but the connections required are wonderfully explained by the author.

Once all the wiring is done, we need to install certain software that enables PWM or pulse width modulation on all of the GPIO pins of the raspberry. By default, only 1 pin is capable of that.
What is PWM? Get over here to check out. This is just for info. Not related to the stuff here.

I used a software called pi-blaster. The original pi-blaster was made sarfata. (GitHub) but at the time of writing this blog, his version of pi-blaster supports the older Raspberry B, not the B+ with 40 GPIO pins. So I am using a fork of the same software. It is exactly the same code, apart from a few lines which enable PWM on all the pins of RPi B+ and the RPi 2.

Instructions on how to install pi-blaster are posted along with the source code, which is compiled on the raspberry itself. Once installed, wire up the LED strip and test it using the echo commands. Again, they are mentioned in the Readme file of pi-blaster.
That is all the hardware part done. And actually nearly all of the software done as well.



Now comes the tricky part. The part where I struggled for nearly 3 weeks. That is, how do I get everything to work together? Well, the short answer is, I had to hack and create my own programs.
First, let us set up the Web Interface that controls the RGB LED strip using a web page.

Obviously, the first step is to install apache web server with PHP support onto the raspberry pi.

Next, comes the most important part. Here is the link to a zip file which has all the necessary files and a small ReadMe included in it. Basically, all you have to do is to copy over the files in the exact same directory structure as it is in the zip. These will be:-

"/usr/lib/cgi-bin/" - For the python scripts
and
"/var/www/" - For the hosted Web Page

You can use the sudo cp commands to copy stuff. I simply copied all the stuff from a different computer into the directories mentioned.

Once you have copied all of the files in the respective locations, you have to make the python scripts executable, which are in the /usr/lib/cgi-bin directory.

Use “chmod +x *.py” to make all the python files in the directory executable.

I found this zip file on a YouTube Video. All credits to original author.


VERY IMPORTANT.
After a lot of trial and error, I've observed that the PWM outputs are fine only on the GPIO_GENx pins. I'm not sure why that is, but this happens. Now if you wired your display as per the Adafruit guide, you have already used up all the GPIO_GENx pins. So we have a problem...

Or do we? Nope! In the python file used for running the display, change any 3 GPIO_GENx pins to simple GPIO pins, because the LCD works fine for any GPIO, as long as it is configured correctly. For example, I changed GPIO 23, 24, 25 to GPIO 13, 19, 26, hence freeing up the GPIO_GEN pins, which I then used for PWM. See the Rpi B+ pinout diagram to know which pins are GPIO_GENx pins. X here is a number.

Notice the GPIO_GEN pins? That's where correct PWM is.


You will need to edit the python scripts in the zip file, according to the pinouts you are using for the LED strip. In LED.py and stop.py, make sure you change the corresponding GPIO pins for the Red, Green and blue channel. Remember that the number is the GPIO number, and not the actual number. IE if you want to use GPIO 23 for Red channel, change the value of red channel to 23, which is the GPIO number, and NOT 16, which is the actual pin count. There are 2 places in the LED.py and one place in stop.py where the changes are required.

So now, all is done and the simple task of running it all together remains. It is a good idea to check that every component works individually. Make sure the demo programs by Adafruit of the Character LCD and the DHT sensor work. Also, issue the echo commands when the pi-blaster service is running to re-confirm that PWM is also working for the RGB LED strip.


Assuming everything is done up to this point, let’s start hacking code.
Now the base of the code is the same script as the character LCD example, because that is the most complex and we need the LCD script base.

The base code of Adafruit_CharLCD.py


After editing the char_lcd.py to barebones, add the DHT sensor.py into the same file.Remember to change the python code so that you don’t have to enter the GPIO pins in the input, as required by the original code of Adafruit, and works on the defined pin only.

Adafruit_DHT with predefined pins, inside an infinite While loop


Also add the code which pulls the IP address of the pi and stores it as a variable.

This part is actually above DHT and out from the infinite loop, as IP once assigned does not changes, until reboot. This saves additional processing if the IP code was also included in the loop.
I know I'm smart.


Then use the lcd.print() function to print the variables on the LCD screen. Put all of this inside an infinite loop so that the temperature and humidity keep on getting refreshed on the screen.
Lost track on how to do so? Let me help. :)

Here is the complete python file, for LCD displaying temp, humidity and IP


Character LCD with IP Address

Yeah, its quite hot here. I should say humid though.


Now, we want that this script starts up automatically at boot. Obviously, if I don’t know the IP address, how can I SSH into the pi to run the script that tells me the IP? So for that, I’m using the CRON task scheduler, which, I’ve been told, is built into every Linux system. Neat!
I programmed CRON to run the python script at every reboot, i.e., whenever the pi is turned on. This is by far the easiest method I have seen to run scripts at boot.
Remember that while setting up the pi-blaster, if you ran "sudo make install", pi-blaster will automatically start at every boot. No need to cron that.

Small guide to CRON Task Scheduler


With everything set up, fire up your laptop, PC, mobile or tablet, connect it with your Home wifi, open a browser, type in the IP Address that is shown on the LCD, and you should see something like this.

For some reason, the buttons work only when the text is clicked.


Press any option here, according to your taste. Except for the All colors, you will be able to select the color you want the lights for.

The All colors option cycles through every possible color, hence no color selector.

Press the activate button and hopefully, you will see something like this.



#SWAG



Now, someone asked me for a basic introduction to pi, as well as some general questions. The good thing about the pi is that there is a lot of information which is available on the internet. The BAD thing is that you really have to make an effort to get that information. All those small bits and pieces are scrambled throughout the net. Let me try to answer some of them in a Q&A form.

Q1. I’m a beginner and I don’t have the anything lying around, should I buy the kit or should I get individual parts?

A1. That depends upon you and your needs. I got only the RPi at first and I had no idea what I was going to do with it. As I progressed, I got the stuff I needed. If you are just getting started, I don’t think a full kit is needed, since most of the accessories are already there. Things like USB keyboard, mouse, HDMI monitor etc., are common now. Also, if you are using Wi-Fi, don’t forget to get a Wi-Fi dongle as well. The Edimax Ew-7811un is excellent.


Q2 .How cool would it be to attach an Arduino with it?

A2 .Very cool! But I don’t really know, since I haven’t tried that yet. If you are planning something with a lot of sensors, then it’s a great idea. I've tried something called GrovePi. It's basically a HAT board for Raspberry with Arduino on top. Also, the sensor connectors are standardized for the GrovePi, hence allowing for easy connections. The code is also available on their GitHub. Except for the wiring limitations and cost in India, it is an excellent starting point for IoT.


Q3. I’ve got some old SD cards, but of very small size. Is there any way I can use them?

A3. I had the same problem, and since I was on a shoestring budget, I found a way to work around that. Assuming you have a lot of pen drives, you can use one for storing the OS on the pen drive. The catch is that RPi still needs an SD card to boot from. The way to get around that is very simple.

Get an .img file of the OS of your choice. Usually Raspbian. No NOOBS, only the .img file. Next, install that .img onto your pen drive just as you would install the img on your sdcard. This will partition your pen drive into 2 parts. One will be a FAT partition of around 60 MB named boot. Other will be ext4, which stores the actual OS. There may be some unallocated space left.

Then, insert your sdcard, format it to FAT, name it as boot, and copy over all the stuff from the boot partition of the pen drive into the boot partition of the sdcard.
Open your sdcard, there will be a file named cmdline.txt
Change the line in cmdline.txt on sdcard from” root=/dev/mmcblk0p2” to “root=/dev/sda2”
This reassigns the root of the OS from the sdcard to the pen drive.

Lastly, you may like to merge the unallocated space of the pen drive the root partition of the pen drive. This can be easily done using Gparted on Linux. I don’t think it’s possible on widows.

The end result of the bootable Pendrive for RPi, as seen from Ubuntu.



Q4. is it necessary to have Linux installed on a main PC/Laptop? Can’t I use Rpi with a windows machine?
A4. Well, you can. But I’ve found out that tools like Putty and VNC are much more stable on Ubuntu as compared to windows. I’m not saying that they don’t work, I’m saying is that there is a bit of lag on while using windows to run commands on rpi using SSH or VNC. It’s not that bad, but it’s noticeable. If you are planning to run your RPI as a full-fledged computer then you don’t have to worry about all this, since you will be running Linux anyways. Exception to Windows 10 IoT.


Q5. What about the power source to the Pi?

A5. This is a fairly important part. Technically you can use any Mobile phone charger with a MicroUSB wire. But the Amps the charger is capable of supplying is very important. I tried a Moto charger, limited to 500mA only and it causes random freezes on the pi. 

500mA. Seriously Motorola?


Anyways. The power consumption/draw varies on what all is connected on the pi. To be on the safe side, I recommend a 10W or 2Amp charger. The voltage should not exceed 5 volts on the USB.
If someone is a bit crazier like me, you can also power the Rpi from the GPIO pins. But as I said, that bypasses all the power protection circuits and puts pi on a great risk. I’m myself using a 350w power supply. Overkill. But that also powers the speakers, the LED strips, a DIY 4 port USB charger and the 5V sensors.

The PSU I have mounted under my desks, that powers everything. I'll be adding a UPS here so that PSU continues to work even if there is a power outage. White LED's for added effects.


Here are some other Photos of my apparatus.

The brains behind all, The RPi B+
The 3 wires going to the left are for the LED PWM

The LCD display, DHT-22, 3 MOSFET's and a guest appearance by Ultrasonic sensor
This is the minimalist wiring possible.

A slightly better look at the MOSFET's. These were the hardest to get components for me. Logic Level MOSFET's.
Logic level is important.


So I guess that's it. Please feel free to comment, ask questions and suggest improvements. As usual, all feedback is welcome. Drop by on G+ and say Hi!

:)