[Samsung Epic 4G Touch] numus:
That is great if you understand the difference between radio performance reporting in the kernel and actual signal integrity as reported by the modem chip and then relayed via the RIL to the kernel.

The kernel doesn't do much except interpret what the RIL is telling it. The RIL is the interface layer between the radio (modem) chip and the kernel and all commands pass thru it thru a 2 part daemon and vendor_ril.

So just because you change the kernel has no effect on the actual signal performance (strength is only part of it) another part is the S:N ratio (signal to noise)... You can have the strongest signal possible but if the S:N is way to low then you get frequency interference. In analog devices this was heard as static or white noise and possibly a bleedthru from an adjacent frequency, but in the digital age this just causes a decrease in signal integrity. Digital devices employ a buffer with a certain threshold. After you drop below that threshold you suffer serious degradation in the data stream to the point that it drops to almost 0 and you lose the stream all together.

To put it mildy: What your phone THINKS the signal is may be WAY WAY different then what the actual signal is. The kernel only is reporting what it thinks it is being told the signal is by the RIL and uses an equation to calculate the displayed strength. It is very easy to alter this in the kernel and make it appear to have better signal when it doesnt (see iphone 4 http://www.gizmag.com/iphone-signal-strength-error/15607/)

See above...

P.S. I can give you a perfect example of how to alter reported values in the kernel..

http://forum.sdx-developers.com/?action=downloads;sa=view;down=4

That is how you modify the battery reporting code in the kernel... It doesnt actually change what the battery usage is or magically make the battery have a higher capacity but it reconfigured the values the kernel used inorder to better approximate remaining capacity of the battery dependent upon a new voltage curve that I calculated... It ended up being much more accurate then the curve Samsung used... People thought it was giving better battery life, but all it did was make sure 100% = 100%, 50% = 50%, ect....

To display that.. Utilizing this line

#ifndef convert_adc2voltage
#ifdef __9BITS_RESOLUTION__
#define convert_adc2voltage(x)	(x * 10000 / 848)
#else /* __9BITS_RESOLUTION__ */
#define convert_adc2voltage(x)	((x - 2170 ) * 10 / 7 + 3200)
#endif /* __9BITS_RESOLUTION__ */
#endif /* convert_adc2voltage */

You can see all the kernel is doing is taking the ADC (analog to digital converter) value outputted by the power system and attempting to convert it to a reportable value.

If you look in the header file.

#define BATT_CAL	296	/* 3.49V */

#define BATT_MAXIMUM	59	/* 4.19V */
#define BATT_SAFE_RECHARGE	51	/* 4.10V */
#define BATT_FULL	40	/* 3.98V 90*/
#define BATT_ALMOST_FULL	29	/* 3.85V 70*/
#define BATT_HIGH	21	/* 3.75V 50*/
#define BATT_MED	17	/* 3.71V 30*/
#define BATT_LOW	12	/* 3.65V 15*/
#define BATT_CRITICAL	3	/* 3.55V 5*/
#define BATT_MINIMUM	(-2)	/* 3.49V 3*/
#define BATT_OFF	(-8)	/* 3.40V 1*/

#define BATT_EIGHT	35	/* 80%*/
#define BATT_SIX	25	/* 60%*/
#define BATT_FOUR	19	/* 40%*/
#define BATT_TWO	15	/* 20%*/

So you take the CAL file and add to it another defined value.. Says Bat high at 296 + 21 = 317.. that means when the ADC = 152 (based upon the non-9bits converter formula) that the battery is currently at 50%.. If you changed that simple value to 22.. that means ADC = 153 is = 50%... you can see how that can start to influence how the kernel reports the battery percent..... It isn't actually doing anything with the battery or power system, but is just trying to interpret what the hardware is outputting...

This is actually backwards cause it takes the ADC value and puts that thru the equation and outputs a number

It is how I started doing dev work for android.... Haven't done much lately because of real world obligations but still try to follow up on changes.