a mARTIAN dIARY

My First CHIP!

Filed under: RaNTs@eARTH — cafm @ 1:52 pm August 31, 2007

It’s a really proud moment for me to see the first press releases of my first ever chip!

PNX5100

…..is the world’s first video postprocessor with proprietary Motion Accurate Picture Processing technology, enabling TV manufacturers to drastically improve high-definition (HD) motion picture on LCD TVs. This technology on NXP’s new PNX5100 video postprocessor combines movie judder cancellation (MJC), motion sharpness and vivid color management to successfully remove the visible halo and blur in fast moving scenes delivering an enhanced viewing experience for enjoying sports and action movies.

Datasheet(PDF)

Well now…”my” does seem to be a bit strong word…but still it is mine as much as it is of anybody else of the team that worked on it :P

Missed Call Problem – A TRIZ Approach

Filed under: RaNTs@eARTH, the 'I' factor — cafm @ 2:56 pm August 30, 2007

Recently my friends (Vishwa and Vijay)  and I ( I know “I” seems odd but MS Word wont let me have it otherwise and yeah I know its PROPER English :P )  were discussing a problem that that’s having a detrimental effect on the sleep patterns of a lot of engineers and managers in the mobile phone industry.

The Problem can be stated as “The Missed call facility along with the Caller line identification feature is being misused by the customers by using the same to avoid making revenue generating calling.”
The main challenges accompanied with the problem is that

  1. The problem in itself is not explicitly illegal/ unethical from the customer view point to solve by any legislation.
  2. Any penalty/cost to be imposed on the missed will also be inadvertly penalizing the people making “genuine” missed calls.
  3. A lot of customers with intent to make revenue generating services are not getting access to the system which in turn is costing the company invisible revenue loss.
  4. The solution for the 3rd problem requires investment for a larger infrastructure than what is not financially justified by the actual “active” customers in the network based on the current revenue model

Now to apply the TRIZ contradiction matrix to this problem, it needs to be stated as a contradiction.
There may be multiple ways of stating the problem as a contradiction but I take up this specific way -:

Say you improve reliability of the network by limiting the total number of users as stated in the 4th challenge then the worsening quality is that the quantity of connections that can be offered with the same infrastructure is reduced and consequently revenue is affected.

Or in TRIZ terms it can be stated as

Improving Feature: Reliability Vs Worsening Feature: Quantity of the substance

This is a very abstract way of representing the contradiction but TRIZ is after all an abstraction
The solutions can be looked up at  http://www.triz40.com/
Solutions are
21. Skipping

  • Conduct a process, or certain stages (e.g. destructible, harmful or hazardous operations) at high speed.

28 Mechanics substitution

  • Replace a mechanical means with a sensory (optical, acoustic, taste or smell) means.
  • Use electric, magnetic and electromagnetic fields to interact with the object.
  • Change from static to movable fields, from unstructured fields to those having structure.
  • Use fields in conjunction with field-activated (e.g. ferromagnetic) particles.

40. Composite materials

  • Change from uniform to composite (multiple) materials.

3. Local quality

  • Change an object’s structure from uniform to non-uniform, change an external environment (or external influence) from uniform to non-uniform.
  • Make each part of an object function in conditions most suitable for its operation.
  • Make each part of an object fulfill a different and useful function.

Now the theme among most of them is the break up the service especially looking at the  rule “Change from uniform to composite (multiple) materials.” (The quantity here being the number of connections as defined by us earlier) or from all 3 rules in “Local Quality”.

Now translating this into terms specific to our problem we can come with with- :
Provide different services with different QoS but at corresponding costs. As in, provide two or more separate networks, one that has a poor QoS but also has a much lesser “infrastructural cost” to be levied from the customers and provide another high quality network where the cost of service is higher but QoS is better.

This may at first glance seem to penalize the people who would be responsible for generating revenue even in the first case. But only by going into the actual financial details can we ascertain whether these new networks would exist at a higher cost segment or in the similar band as to now. (The lower QoS network might even get cheaper)

In one way I had always this solution in mind and probably that why I was able to see thru the esoteric solutions given by TRIZ, but then again innovations ultimately has to come from the Innovator: P

 Now the funny part -:  This already exists! :P In a way that is…

Take the case of Bangalore

There are three prominent GSM providers -:
Spice Hutch and Airtel.

For people who have experience with the networks they can see the semblance between spice with the first network (extremely low cost but not that great QoS), Hutch ( Low Cost and decent enough QoS) and Airtel ( the costliest of the lot with probably the best QoS)

The Traffic Problem – Redefined

Filed under: RaNTs@eARTH, the 'I' factor — cafm @ 4:09 pm August 22, 2007

One of the biggest takeaways you can have from the number “42” is that its not always the answer that difficult.(even though it did take millions and millions years of a computing time of the (edit) 2nd most advanced computer to answer it…still) . But after being exposed to TRIZ and Edward De Bono and his crazy hats, what Douglas Adams said makes a lot “more” sense.

When one works in a company that’s situated in the “other” part of the IT heaven that is Bangalore, it’s much harder for one to understand certain problems that run in the blood of every other bangalorean especially the much maligned traffic problem. Till I started making my now-routine weekly trips to Koramangala, traffic to me was like the demon that existed in my house but in the “that” unused room which I never had to visit. And in some crazy way it more like a kind economic stimulant to keep all those RJ’s and others in the radio industry employed than an issue.

But after coming face to face with the demon I have had to change my opinions. And with Murphy’s help, on the day I am late, it would take me 40 min to reach my destination and on others when I try to factor in the 40 min, I reach 20 min early with nothing to do except swat flies for the time I “saved”. Soon enough “traffic” slowly took a prominent place in my list of lunch break and ice break(er) topics.

But then one day it struck me. What is the most annoying part about traffic?
Is it the amount of time it takes or extra time it takes? Hmm…not really cuz if I were properly equipped (cue an ipod or a sony walkman) it doesn’t matter much.
Is it the time you waste just getting out of a signal to be caught again at the next one?
Yes this is annoying, but it’s probably not the most annoying or in a larger senses just a side effect of the main problem.
Then it dawned upon me that it’s the unpredictability that most annoying about the whole problem. It’s the fact that one day it takes 40 min and one day 20 min for the same distance, even without a major disruption like a accident or a fire(?). Plainly cuz the random traffic was more that day or I was unlucky to get caught in all the signals one by one. This brought about a paradigm shift in the way I viewed the traffic. It was no longer about “How to reduce the traffic?” but more about “How can I make traffic delays predictable?” and soon other solutions that I had not thought about till now or did not give too much utility points started emerging.  The important thing is for the frist question its hard to find a scalable solution where as the second problem has very scalable solutions.

I do not say that I have found a permanent solution or albeit even a temporary since most my ideas where invalidated by my friend during our discussion. Also I understand that what annoyed me, the un-predictability, might not even be of minute concern to others, but I feel that by redefining the question I was able inject a fresh life to the hackneyed approach existing to the problem.

For all the H2G2/Marvin fans…

Filed under: RaNTs@eARTH — cafm @ 1:27 pm August 21, 2007

FILE NOT FOUND!

mind-numbingly-depressively-hilarious :P

And come to think of it the life of a web server is really depressing especially when you put it that way….

Before you start Scripting………

Filed under: RaNTs@eARTH, TECHbabble — cafm @ 3:31 pm August 1, 2007

If you can get your job done with tr don’t use SED
If you can do it with SED don’t use AWK
If you can do it with AWK don’t use perl

One of the basic powers of UNIX based systems comes from the fact that there are a gazillion ways of doing even the simplest of tasks. With the combined philosophies of KISS and “Small is beautiful” implemented beautifully along with the pipelining and I/O redirection, the power can actually be overwhelming at times. This is exactly a stumbling point for a person new to this world, especially if he’s coming from the “click-click-click” philosophy of windows. Agreed, the latter philosophy is best suited for a general user who uses computer sparingly or for tasks such as browsing and chatting. The typical “Non-IT” portfolio.  But for an EDA engineer (like me) or a power user to think of a world without these tools is blasphemy. Still with so many choices available, a lot of people who would love to have the power dither away from the “right” path due to a sense of vastness.

I have held the view that languages are just means to end. Writing a program is not the hard part, its just the unavoidable detail.Any person with reasonable intelligence can use the IT industry mantra of {“CTRL+C-CTRL+V”} and write reasonable code. This is particularly true in the case scripting as the “hard” part such as memory management etc is removed. Hence we see that in the scripting mindset the focus is to get the job done and ask questions about efficiency etc later (unless it’s a heavily executed script and the current implantation is VERY bad). So the most important part of scripting boils down to the language/tool selection which can be a daunting task, taking the amount of choices available. Even though there can never be hard and fast rules , I thought I would pen down some thumb rules that can be applied to make this daunting task easy.

Never start with NO!
First thing to understand is that -: always be open to change…..but with intelligence. Don’t choose a language just because you’re comfortable with it. Even though there are exceptions to this rule like when time is playing a very important parameter in determining the value of the current solution or the complexity reduction offered to your with the new language does not justify the extra effort to be spent to get the thing implemented(Remember that the product of this first effort can be later used if the code is modularised) . I know this sounds vague but the idea I want to convey is that always consider other languages before committing to a particular language.A general flow for choosing a language is given at the end.

Visualize the Solution
Get a grip of the capabilities of the language rather than spend too much time learning the each and every syntax. More often than not, the time difference between when you learn the language and when you have to solve a practical problem would be too much that the intricacies that you spend hours learning would seen as distant to you as the basic syntax. Instead if you get the capabilities they it will help you visualize the solution in a particular language and the dirty stuff can be dealt with later. Chances are that most of the “challenges” that you have to face while implementation would have been faced by hundreds before and would be well documented so just GOOGLE!

Modularize it!
This is something I try to implement all the time. Once you visualize your solution, split it into independently implemental chunks. Not only does this help you write code that’s easily understandable/maintainable/modifiable but it also helps reduce your work when you are writing another script if you can reuse some of the modules.

Hybrids/ Genetic engineering is good.
Ever read about the plants that have insecticide genes engineered into them? Similarly , it might make sense to implement a part of the solution in one language and the other in another. As long as you can easily understand the way the data is to be transferred between the two parts, Go for it!

The following rules/questions can be used as a guideline while choosing the language.

It’s a simple solution involving a lot of individual UNIX commands / executables
Can I see the solution in Shell?

It involves rudimentary text processions, like single character substitution and some character removal
Can I see the solution with Shell along with cut and tr commands?

It involves more complex text manipulations
Can I see the solution in Shell and SED?
(AWK can do a log of things SED can do, but complex stream editing is something SED is better at (faster, the code is terser, etc.) but SED has no function and no arthemetic)

I also want some multilevel text manipulations and with support for variables during these complex text manipulation steps.
Can I see the solution in Shell and AWK?

It involves large scale text manipulation and reports parsing.
Can I visualize the solution in PERL? (or Python?)

It involves automation of interactive software like ftp, ssh etc
Can I see the solution with Expect along with a host language like TCL?

Please do leave a comment if you feel that there is anything else that you have come across that can make this more helpful. 



Disclaimer
The thoughts expressed in this blog are mine and should in no manner be linked to the organization(s) with which I am (or have been) associated.