Queen’s Dessert Icecream

February 5th, 2012 No comments

image

image

image

image

Queen’s Dessert Icecream with Chocolate Sauce and Chocochips.  It tasted very nice and creamy.  The ice cream had dark chocolate cookies, which added to the taste and experience.  Although Chocolate fudge would have been a better choice than chocolate sauce, it indeed tasted nice.

Simple Superstar Movie

February 5th, 2012 No comments
Wilbur is in the process of producing his first movie called Simple Superstar.  He is raising the funding for the movie from his fans.  More about the movie and himself at www.wilbur.asia.  Being a fan, I have donated a small contribution, which would make me one of the Associate Producers of the movie.  I am so excited to see the movie screened end of this year.  Keep up the good work Wilbur!

Butterscotch Icecream

February 4th, 2012 No comments

image

image

image

Butterscotch Icecream with butterscotch sauce, chocolate fudge, chocochips.  This is one of my favorite flavors.  Just seeing this makes me mouth watering!  Additional toppings could be almond nuts and cashew nuts sprinkled over the ice cream.  When I had this icecream, it was so soft and creamy, which makes me go to the parlor at Ambattur every week.

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.