When you look at a wireless handheld consumer device there are 3 main factors that define the product besides the functionality/usecase ofcourse. The factors are the cost, the range/bandwidth and the battery life. For the end consumer they would like a lot of functionality with the cost being as low as possible. While they would love the range and battery life to be large.
Ok back to reality.... The 3 factors are related and you could consider them as the 3 points of the golden triangle that surrounds the basic use case. You have to tweak the various factors depending on the usecase. If you want more range and bandwidth, battery life will go down, cost will rise. The thumb rule... tweaking one affects another.
So there we were, trying to tweak the current consumption of the device we were building. The aim was to reduce the current consumption of a particular component from about 1.5 milli amps (1500 micro amps) to less than 10 micro amps under certain conditions. We studied the h/w schematics, the external/internal pullups/pulldowns for various paths, the chip datasheet. Discussed it with the h/w folks. I ran the various signals thru my head, keeping in mind not to break any existing functionality while trying to accomodate the new ones. We had to multiplex just a single line to communicate stuff between the main processor and the component under scrutiny. We had to think of timing issues and signal settling times due to spurious capacitances, signals. In this tiny little world of chips, super-highways and interconnects we were playing God. And as God we had to think more about the rogue signals and components that misbehave and try to get them back to the right path. Come to think of it we were just being human. hmmm...... When consuming less than 10 micro amps the component would switch off its sequential logic (logic using some clock). To get out of that low power mode we had to use the combinational logic functions of the chip. Finally we came to the conclusion that it was feasible. The feasibility analysis had to be done before writing a single line of code and the implementation itself would provide its own set of challenges. We finally ended up bringing down the current consumption to about 1 microamp but thats another story.
Ok back to reality.... The 3 factors are related and you could consider them as the 3 points of the golden triangle that surrounds the basic use case. You have to tweak the various factors depending on the usecase. If you want more range and bandwidth, battery life will go down, cost will rise. The thumb rule... tweaking one affects another.
So there we were, trying to tweak the current consumption of the device we were building. The aim was to reduce the current consumption of a particular component from about 1.5 milli amps (1500 micro amps) to less than 10 micro amps under certain conditions. We studied the h/w schematics, the external/internal pullups/pulldowns for various paths, the chip datasheet. Discussed it with the h/w folks. I ran the various signals thru my head, keeping in mind not to break any existing functionality while trying to accomodate the new ones. We had to multiplex just a single line to communicate stuff between the main processor and the component under scrutiny. We had to think of timing issues and signal settling times due to spurious capacitances, signals. In this tiny little world of chips, super-highways and interconnects we were playing God. And as God we had to think more about the rogue signals and components that misbehave and try to get them back to the right path. Come to think of it we were just being human. hmmm...... When consuming less than 10 micro amps the component would switch off its sequential logic (logic using some clock). To get out of that low power mode we had to use the combinational logic functions of the chip. Finally we came to the conclusion that it was feasible. The feasibility analysis had to be done before writing a single line of code and the implementation itself would provide its own set of challenges. We finally ended up bringing down the current consumption to about 1 microamp but thats another story.
Anyways after the feasibility analysis, we were wondering what we should charge the customer for this feature. It was a small feature but everyone would love to be paid a lot for anything and everything they do. While the person who you are doing it for would love to get it done for free or as part of some previous payment.
Ok back to reality.... So my manager decides to call a meeting of the team and the program manager to discuss the technical details of the feature, and the pricing for it related to the man hours to be allocated. We spoke of the technical feasibility and came to the conclusion that it would take a couple of days to complete, which included full regression testing. Regarding the pricing he and the program manager could have come to a decision on it. They didn't need us in the discussion as we were engineers and that was not part of our job profile. We then went into some philosophical discussions about doing the right thing and decided that it was something we had missed and so we should not charge the customer for it.
Looking back I feel my manager came into the meeting already decided. He didn't want to just force his decision upon us. I had a feeling that this was on his mind from the beginning of the meeting. Trust me I did :-) He could have just told us what his decision was and we would have left it at that. No questions asked. However he didn't want to just tell us the time as per his clock. He wanted us engineers to build the clock so that we can tell the time in the future.
1 comment:
As here I can see that you are telling me about your time management. And yes we should manage our time effectively. Again it is not so hard to track our time and every single because group calendar is here. I'm also using this scheduler for a long period and the result that I got is just amazing to say.
Post a Comment