Graphics not working in L702X Dell XPS 17 while installing Linux Mint 12

January 30th, 2012 No comments

Looks like the faulty nouveau driver is creating the fault during boot up. Without nomodeset and/or acpi=off, booting leads to segmentation fault by the nouveau module. When I disable the nouveau module by blacklisting it under modprobe.d, I am able to boot up cleanly using the Intel Sandybridge Mobile graphics driver.  After updating the blacklist configuration, remember to run update-initramfs -u.

Code:
filename: /etc/modprobe.d/nvidia-nouveau

# disable nouveau driver
blacklist nouveau
options nouveau modeset=0
Tags:

Temperature Monitoring Device

January 1st, 2012 No comments

LM35 Temperature Sensor

The System.

The monitor.

The mixed water line:

The hot water line:

The cold water line:

monitor opened up:

the atmega8 microcontroller

the lcd unit:

theboard:

inside the monitor:

The AVR code.

const int COLD = 0, HOT = 1, MIXED = 2, CALIBRATE = 3;
const int PWMPORT = 5;

float SCALE = 5000.0/1024.0; // 10 bit resolution for ADC
const float LM35SCALE = 10; // 10mV per Centigrade

#include <LiquidCrystal.h>

LiquidCrystal lcd(13, 12, 11, 10, 9, 8 );

byte smiley[8] = {
  B00010,
  B00101,
  B00010,
  B00000,
  B00000,
  B00000,
  B00000,
};

float Calibrate( void )
{
  // write 5v to PWM port
  analogWrite(PWMPORT, 255);

  // read the 5v analog value in the calibrate port
  delay(500);
  int val = analogRead(CALIBRATE);

  // read again the 5v analog value in the calibrate port
  delay(100);
  val = analogRead(CALIBRATE);

  // whatever digital value we read is the range of output that we would get for 5v input.
  // so, set the scale appropriately.
  SCALE = 5000.0/(float)val;
  
  return SCALE;
}

void setup()
{
  pinMode(PWMPORT, OUTPUT);
  
  lcd.createChar(0, smiley);
  lcd.begin(16,2);
  
  lcd.setCursor(0,0);
  lcd.print(“Calibrating..”);
  float scale = Calibrate();
  lcd.setCursor(0,1);
  lcd.print(“Scale=”);
  lcd.print(scale);
  delay(1000);
}

int Temp( int inADC )
{
  float lm35volts = (float)inADC * SCALE;
  float temp = lm35volts/LM35SCALE;
  
  return (int)temp;
}

int ReadData( int port )
{
  int data = -1;
  for ( int i = 0; i < 3; ++i )
  {
    data = analogRead( port );
    delay(100);
  }
  
  return data;
}

void loop()
{
  int cold = ReadData( COLD );
  int hot = ReadData( HOT );
  int mixed= ReadData( MIXED );
  
  int cold_temp = Temp(cold);
  int hot_temp = Temp(hot);
  int mixed_temp = Temp(mixed);
  
  lcd.clear();

  lcd.print( “C=” );
  lcd.print( cold_temp );
  lcd.write(0);
  lcd.print(“C”);
  lcd.print( ” H=” );
  lcd.print( hot_temp );
  lcd.write(0);
  lcd.print(“C”);
  
  lcd.setCursor(0,1);
  lcd.print( “Mixed=” );
  lcd.print( mixed_temp );
  lcd.write(0);
  lcd.print(“C”);
  
  delay(1000);
}

Fixing a Hand Remote Control that doesn’t work!

December 4th, 2011 No comments
    It is hard to imagine a television or a multimedia system without remote control now a days. Broken remote control units is an eternal problem. Thanks to China for dumping remote control units, which makes the cost of them affordable between 60-75Rs for television units. But, finding a replacement for multimedia systems is still a problem as no vendor is holding such stocks for its lower sales.
     I have been hit for the same problem when my Altec Lansing 5.1 multimedia system’s remote control broke. In the sense, the remote was functional intermittently. And some time, the key pad mapping got goofed up with + working as – and so on. When I visited my local electronics stores guy, he said the general problem for intermittent remote operation is a conked up crystal that is found inside the remote control unit. 

    Remote control units work with Infrared light communication between the hand-unit and the multimedia system’s base unit.  Commands from the keypad are converted to IR signals, which are received and decoded by the base unit to perform appropriate function.  Since IR light is not visible to human eye, one should use a Camera eye to see the IR light.  The easiest way is to observe the LED mounted in the front of the hand unit through a mobile camera or any camera that’s in working condition.  The cameras bandwidth covers IR and UV apart from the visible spectrum.  You will find that the IR led blinks (carrier frequency is 22khz), when you press any button on the remote control unit.  If you observe that for some keys the IR led is not flashing or intermittently flashing, you may associate the problem to a faulty crystal in the remote control PCB.

    When the remote is opened, you will see a PCB like the one in the picture.  The PCB could be plucked out from the casing by hand.  You will also see a rubber like buttons which are the actual buttons that you press.  The rubber button is placed on the PCB, where the button presses are converted to switching action.  Remember, the buttons will have a conducting coating under it, which indeed closes the circuit when the button touches the PCB. 

    The crystal that comes as a part of the circuitry is shown in the picture.  It is otherwise called a ceramic resonator, which is the crucial component of an oscillator circuitry.  Crystals are typically used against LC, RC tank circuits for its very high stability feature against temperature and humidity. My remote uses a 455Khz crystal named CRB455E (http://dalincom.ru/datasheet/CRB455E.pdf). The cost of this crystal as on today is Rs 2 in Chennai/India.  After replacing the crystal, my remote is working perfectly so far.

kDevelop 4.2 Debugging

November 7th, 2011 No comments
    When I was using KDevelop 4.2 for debugging a process, I got perplexed having the inferior application closing down whenever I was setting a breakpoint on the fly.  On the contrary, the breakpoints there were setup before the start of the inferior application, things behave as expected.  With little bit of digging, it is found that whenever a new breakpoint is setup or removed (Toggle Breakpoint), kDevelop inherently issues a SIGINT to the inferior application, which in turn stops the application from debugging.  To handle this problem, setup a signal handler for SIGINT, to consume the Interrupt signal (Ctrl+C, Ctrl+Break).  But once the debugging is over, don’t forget to reset the SIGINT handler.

Hash Overflow due to 64 bit upcasting

October 28th, 2011 No comments
    Lately, I had to debug the following piece of code, where it caused overflow on the hash bucket design.  The code worked perfectly on a Windows machine while compiled for Win32, but failed to work on a Linux Mint x64 machine.  The code is listed below, which basically calculates hash value of an input 32 bit unsigned number, limiting the hash value to 2^10 (1Meg).

hash = ( fpArray*2654404609 )>>12; // Calculate the hash and limit the value to 2^20 (1 Meg)

   When the input value for fpArray was 1724463449 (0x66C93959), the hash value generated was 1779068547 (0x6A0A6E83), which is more than (0x000FFFFF) to cause the hash bucket overflow.

unsigned hash = fpArray * 2654404609;
hash = hash >> 12;

    When I rewrote the code like the above, the value of hash was 2800236889 (0xA6E83959).  Upon shifting right by 12 yields 638651 (0x0009BEBB), which is the correct and expected hash value.

    Overall, the first snippet of code appears to be correct.  Do you see a problem there?  I couldn’t find the issue, until I recalled the 32bit vs 64bit difference.  If you carefully look at the multiplier 2654404609 (0x9E370001), although appears to be a valid 32 bit number, what is the default assignment of type to this number by the compiler?  If it was assigned 64bits, what would happen to the results?  To validate this, I changed the 2nd snippet as the following.

unsigned long hash = (unsigned long)fpArray * 2654404609;
hash = hash >> 12;
unsigned h2 = (unsigned)hash;

    Now, when the input is the same 1724463449 (0x66C93959), the value of hash becomes 4577423727077636441 (0x3F8646A0A6E83959) and upon right shifting by 12 bits yields 1117535089618563 (0x0003F8646A0A6E83). Followed by downcasting to unsigned yield 1779068547 (0x6A0A6E83). Bingo!

    So, what is happening here? While performing (fpArray * 2654404609), the computation is upcasted to 64bit computation by the 64 bit compiler.  So, what is the solution? Just put a “U” at the end of the constant.

hash = ( fpArray*2654404609U )>>12; // Calculate the hash and limit the value to 2^20 (1 Meg)
(or)
const unsigned multipler = 2654404609; // here U suffix is not needed as the constant is explicitly made unsigned
hash = ( fpArray * multiplier ) >> 12;

    Now, the computation will happen with 32 bit numbers to get the expected outputs.

Lessons Learned here:

  1. While using constants, beware of the upcasting and downcasting. So use proper suffixes like U, L, F etc.
  2. Instead of using constants directly in expressions, use them as constant variables.
  3. Be conscious about the compiler type and the assumptions made by the compiler in different build modes.

Three Worlds

October 7th, 2011 No comments
We have been always told by our elders that there are three worlds, the one that we live (earth), the one above us (heaven) and the one below us (hell).  After becoming an elder ourselves, do we still believe that there are three different type of worlds? We have been also instructed that all the gods live in the heaven and all the devils live in hell and likewise all the humans live in earth.  Depending on our deeds, after our death, we could either go to heaven or hell.  Do we still believe in all these statements?  If one could do a little thought work over those statements, it could become apparent that all those are baseless myths.  But, why was such a myth conceived in the first place? 

Let’s first analyze the concept of three worlds.  The key lies in “above us” and “below us” ideology. It was believed that the place we live is a “flat” and unlimited space.  Now, we know that we are living in a spherical space suspended in vacuum space called universe (or multi-verse maybe!).  When we all believed that our living space is flat, the ideology of “above us” and “below us” is a natural thought. Even now, if one thought about the boundaries of the universe, there is no absolute answer, but there are lots of theories.  When humans climbed mountains, they realized that the temperature dropped over increasing altitude.  Likewise, when humans dug deep on earth, they found the temperature to be increasing rapidly.  So, now we know why hell (the world below) is always portrayed as “fire”/”hot” place.  Humans found the celestial activities as depicted on the sky to be very intriguing and scary sometimes.  So, they thought something uncontrollable is up there, which was deemed as a god, to whom every human should submit and fear.
Tags:

How to Remove The headlamp – Getz Prime

September 24th, 2011 No comments

Removing the headlamp from Getz Prime is pretty trivial and requires just only one tool and probably 5 minutes of time.  Let’s see how to go about that.

1. The Headlamp Assembly: It appears very dull ey? Yes, I was going to remove it and replace the frontal glass.

2. The Tool: All the bolts that attach the assembly to the chassis are 10mm and you would need a bit rod for disassembling the headlamp unit.

3. Remove Bolts: Use the 10mm bit rod to remove the bolts.  Remove the first bolt visible from the top.

4. Remove the other 3 bolts visible from the front side.

5. Remove the hidden bolt.  Now that you have removed the front side 3 bolts, you will be able to pull that plastic to expose the hidden lamp assembly bolt fastened to the chassis.

6. Shake and pull the the headlamp assembly.  Remember to remove three wiring harnesses connected to the headlamp assembly; a) The Bulb supply b) Motor, Parking lamp, Main Bulb supply c)  Indicator supply.

That’s it.  It takes just 5 minutes and 1 tool to remove the head lamp assembly from Getz Prime.

AWG Vs Current Flow Capacity

September 13th, 2011 No comments

This write up is taken from http://www.engineeringtoolbox.com/wire-gauges-d_419.html

The AWG – American Wire Gauge – is used as a standard method of denoting wire diameter, measuring the diameter of the conductor (the bare wire) with the insulation removed. AWG is sometimes also known as Brown and Sharpe (B&S) Wire Gauge.

The AWG table below is for a single, solid, round conductor. Because of the small gaps between the strands in a stranded wire, a stranded wire with the same current-carrying capacity and electrical resistance as a solid wire, always have a slightly larger overall diameter. The higher the number – the thinner the wire. Typical household wiring is AWG number 12 or 14. For telephone wires there are common with AWG 22, 24, or 26.

AWG Diameter
(mm)
Diameter
(in)
Square
(mm2)
Resistance
(ohm/1000m)
40 0.08 . 0.0050 3420
39 0.09 . 0.0064 2700
38 0.10 0.0040 0.0078 2190
37 0.11 0.0045 0.0095 1810
36 0.13 0.005 0.013 1300
35 0.14 0.0056 0.015 1120
34 0.16 0.0063 0.020 844
33 0.18 0.0071 0.026 676
32 0.20 0.008 0.031 547
30 0.25 0.01 0.049 351
28 0.33 0.013 0.08 232.0
27 0.36 0.018 0.096 178
26 0.41 0.016 0.13 137
25 0.45 0.018 0.16 108
24 0.51 0.02 0.20 87.5
22 0.64 0.025 0.33 51.7
20 0.81 0.032 0.50 34.1
18 1.02 0.04 0.82 21.9
16 1.29 0.051 1.3 13.0
14 1.63 0.064 2.0 8.54
13 1.80 0.072 2.6 6.76
12 2.05 0.081 3.3 5.4
10 2.59 0.10 5.26 3.4
8 3.25 0.13 8.30 2.2
6 4.115 0.17 13.30 1.5
4 5.189 0.20 21.15 0.8
2 6.543 0.26 33.62 0.5
1 7.348 0.29 42.41 0.4
0 8.252 0.33 53.49 0.31
00 (2/0) 9.266 0.37 67.43 0.25
000 (3/0) 10.40 0.41 85.01 0.2
0000 (4/0) 11.684 0.46 107.22 0.16

The higher the gauge number, the smaller the diameter, and the thinner the wire.  Because of less electrical resistance a thick wire will carry more current with less voltage drop than a thin wire. For a long distance it may be necessary to increase the wire diameter – reducing the gauge – to limit the voltage drop.

American Wire Gauge (AWG)
Length
(feet)
Current (amps)
5 10 15 20 25 30 40 50 60 70
15 16 12 10 10 8 8 6 6 4 4
20 14 12 10 8 8 6 6 4 4 4
25 14 10 8 8 6 6 4 4 2 2
30 12 10 8 6 6 4 4 2 2 2
40 12 8 6 6 4 4 2 2 1 1/0
50 10 8 6 4 4 2 2 1 1/0 1/0
60 10 6 6 4 2 2 1 1/0 2/0 2/0
70 10 6 4 2 2 2 1/0 2/0 2/0 3/0
80 8 6 4 2 2 1 1/0 2/0 3/0 3/0
90 8 4 4 2 1 1/0 2/0 3/0 3/0 4/0
Standard Wire Gauge (SWG)

SWG inches mm
7/0 0.500 12.700
6/0 0.464 11.786
5/0 0.432 10.973
4/0 0.400 10.160
3/0 0.372 9.449
2/0 0.348 8.839
1/0 0.324 8.236
1 0.300 7.620
2 0.276 7.010
3 0.252 6.401
4 0.232 5.893
5 0.212 5.385
6 0.192 4.877
7 0.176 4.470
8 0.160 4.064
9 0.144 3.658
10 0.128 3.251
11 0.116 2.946
12 0.104 2.642
13 0.092 2.337
14 0.080 2.032
15 0.072 1.829
16 0.064 1.626
17 0.056 1.422
18 0.048 1.219
19 0.040 1.016
20 0.036 0.914
21 0.032 0.813
22 0.028 0.711
23 0.024 0.610
24 0.022 0.559
25 0.020 0.508
26 0.018 0.457
27 0.0164 0.417
28 0.0148 0.376
29 0.0136 0.345
30 0.0124 0.315
31 0.0116 0.295
32 0.0108 0.274
33 0.0100 0.254
34 0.0092 0.234
35 0.0084 0.213
36 0.0076 0.193
37 0.0068 0.173
38 0.006 0.152
39 0.0052 0.132
40 0.0048 0.122
41 0.0044 0.112
42 0.004 0.102
43 0.0036 0.091
44 0.0032 0.081
45 0.0028 0.071
46 0.0024 0.061
47 0.002 0.051
48 0.0016 0.041
49 0.0012 0.030
50 0.001 0.025

kDevelop Editing Freezes Problem

August 20th, 2011 No comments
While working with KDevelop 4.2, I was quite disturbed by suddenly freezing of editing window. In the sense, the opening file is uneditable, “find” strings does not work and literally kDevelop becomes unusable. I had to restart kDevelop 4.2 to resume editing the code. I believed that kDevelop is going into Vi mode and was trying to undo that. But that’s not the problem.

When kDevelop loses focus, somehow the editing capability is disabled temporarily. When you switch context a couple of time by Alt-Tab and land is kDevelop again, the editing capability is resumed. I don’t know whether this is a bug, but context-switching has been my breather for now.

Protected: பிந்தியாவின் மற்ற நாமங்கள்

August 9th, 2011 Enter your password to view comments.

This post is password protected. To view it please enter your password below: