Hi, I probably sound like a complete noob when I ask this (in all honesty i'm not technologically savvy), but after reading the safety instructions that came with the Touch Pro 2 I have a question. The user manual says the antenna area (towards the top on the back of the device) should not be touched as it will lead to further RF energy exposure and also affect performance/battery life. What I'd like to ask is, is RF energy transmitted only when making/taking a call? Or is it transmitted whenever the device is in use (e.g. when texting, browsing the net, etc. etc.)? It's quite uncomfortable to always avoid touching the top of the device, and I'd be happy to learn that I'd only need to do this while in a call.
thanks for any help!
It has to transmit whenever you send something to the tower. Sending a text message and browsing the internet (requests for things form servers) will make it transmit. Don't worry about it when you are browing or texting, but keep your hand off the antenna for maximum signal when talking.
thanks for the info. Also, the RF energy is too low-level to present a danger to a person's health even if the antenna area is touched right?
Haha, is this for real?
I don't think you need to worry about it.
hint: A phone may emit something like half a watt (=< 500mW) of RF energy, if you're lucky. A Cell Phone tower transmits over one hundred times that (=> 500 W plus). Your average television transmission tower emits maybe a MegaWatt or more (=> 1MW plus).
Which is more dangerous?
Which do folks carp on about?
It also has to "check in" with the tower on a regular basis. Just to let it know you're in coverage area and can receive a call/message/etc.
Still not really dangerous.
Hi guys i'm looking to buy my Defy but considering the SAR value Defy has 1.52..!
is it ok with this value? people say that lower the SAR value then less harmful to body..!
pls check this link
http://www.techfreakstuff.com/2011/06/mobile-phone-radiation-sar-values-best-worst-phones-use.html
Well Defy is listed in worst phone list with higher value though its accepted but some thoughts..
Nyways 'm looking forward to buy my defy..!
Whats u r opinion guys???
Just buy it... Your won't stick it on your ear 24 hours anyway...
Sent from my awesome Moto Defy: Stock Rooted Gingerbread 2.3.3 - XDA Premium
farsight73 said:
Just buy it... Your won't stick it on your ear 24 hours anyway...
Sent from my awesome Moto Defy: Stock Rooted Gingerbread 2.3.3 - XDA Premium
Click to expand...
Click to collapse
Thats ryt..!
I think i have apropriate "old sayin". It goes something like this...
If you are ment to be f****d, your pants will go down by itself.
You can use headsets if you still prefer your safety first.This phone is something awesome.just buy it.
Sent from my MB525 using XDA App
SAR value is test under the phone transmits max power. It's will lower than 1.52 in daily use
On the other hand my defy has better reception on poorly covered areas than my Samsung Galaxy had
please note that the SAR value is derived from the maximal transmit power (as mentioned above), which is for most of the current touch phones caused by the WiFi. Consider also that 3G also produces high radiation compared to the 2G. However, the lower signal strength, the higher radiation. Look up the position of the antenna of your Defy in the manual and make sure you do not cover that spot on the cell-phone when making a call (usually in the lower end, the other side of the of the ear-phone). also, try to hold the phone with that end as far from your head as possible, as the radiation decreases not arithmetically, but geometrically (every unit of distance decreases the radiation by more units - please refer to the http://img.tfd.com/mgh/Investopedia/Inverted_Yield_Curve.png) where "Yeld"=SAR value and "Maturity"=distance from body...
sorry for the academic stuff, but i could not find a better explanation...
I checked the link. I might take notice if there weren't so many exclamation marks! Yes, this is true!
tlsty said:
please note that the SAR value is derived from the maximal transmit power (as mentioned above), which is for most of the current touch phones caused by the WiFi. Consider also that 3G also produces high radiation compared to the 2G. However, the lower signal strength, the higher radiation. Look up the position of the antenna of your Defy in the manual and make sure you do not cover that spot on the cell-phone when making a call (usually in the lower end, the other side of the of the ear-phone). also, try to hold the phone with that end as far from your head as possible, as the radiation decreases not arithmetically, but geometrically (every unit of distance decreases the radiation by more units - please refer to the http://img.tfd.com/mgh/Investopedia/Inverted_Yield_Curve.png) where "Yeld"=SAR value and "Maturity"=distance from body...
sorry for the academic stuff, but i could not find a better explanation...
Click to expand...
Click to collapse
Thats a nice info.Thanks.
EDIT:
I was taking a look here, what about W/kg per 10g vs W/kg per 1g? So, Europe and USA have different SAR limit but the first is related to 10g of tissue, the second to 1g. Will this make any difference? In other words, which is the lowest SAR? Just a doubt..
This thread deals specifically with the 'Auto brightness backlight flicker'. Which only occurs when the phone is set to 'Auto brightness'.
This does not deal with the various other screen glitches, or the constant flicker at various brightness levels when looking at grey screens.
Please do not get the two issues confused.
_____________________________________________________________________________________________
I have observed a few patterns, on two seperate handsets with the same symptoms....
*Firstly, the flicker occurs while the CPU is under load, and particularly at lower battery levels.
*Secondly, The flicker occurs momentarily when you plug in a charger.
*Thirdly, The flicker doesn't occur while the device is charging.
*Fourthly (is that even a word), The flicker is often seen immediately after a screen settles, such as when the screen stops moving after scrolling.
All of these things are evidence of a power management issue. As if the backlight voltage is not being regulated correctly.
I did some more testing over the last few hours and have found something interesting. If you go to 'Settings' - 'Developer Options' - and enable 'Show Screen Updates', your phone will blink the screen different colours whenever the screen is updated. I found that when the screen settles, the screen is updated one final time, just a moment after it has settled. This is exactly when the flicker occurs. As i see it, this is further evidence that the flicker is power management related.
It seems to me that when the CPU goes from load to idle and changes its power draw, the backlight voltage regulation does not filter these fluctuations and the backlight flickers.
The question is, can this be altered either by the power management built in to the kernel, or by other power management software? Or is it a physical design flaw in the power regulation circuit?
The fact that the fluctuation only seems to occur when the brightness is set to auto leads me to believe that it indeed can be fixed with software.
If it was a physical supply voltage fluctuation when the CPU goes from load to idle, it would surely flicker all the time, not only on Auto Brightness.
I assume that the CPU voltage is altered by the kernel as the load level changes.
My question is, if the governor is changed to one which doesn't allow the CPU to scale or voltage step, does the issue go away?
Is there anyone out there who has rooted their device and can test my theory? I don't want to root my device as I may need to send it back DOA (it's only a day old).
If you can change the governor to a profile which doesn't allow stepping or voltage adjustment (100% Voltage and Frequency all the time), and the problem goes away, we have an answer and HTC can work on developing a new Kernel to fix the issue.
Thanks!!
Sentinel196 said:
Please do not get the two issues confused.
Click to expand...
Click to collapse
It is highly likely that all the graphics issues are related. This includes various types of flickering, notification bar corruption, and strange bands in the camera app. Similar issues occurred with the Teg3 Asus Prime when it launched and all were corrected with updates. There are also some performance variations that can be seen in benchmarks when the issues are at their peak that go away when the phone's rebooted.
Nvidia, not HTC (or the devs) controls the Teg3 low-level code, drivers, and kernel. All this has been discussed in the other two threads. As has a communication from HTC UK received yesterday that they've identified the issue and will be issuing an update (not 1.29) to address it.
64 pages of flickering and graphics issues discussion here:
http://forum.xda-developers.com/showthread.php?t=1617009
Thanks for the info. I'm well aware of the other thread and have been following it closely.
Not looking to start a debate about the cause and if the problems are related. Just looking for someone to help me test my theory.
Sentinel196 said:
This thread deals specifically with the 'Auto brightness backlight flicker'. Which only occurs when the phone is set to 'Auto brightness'.
This does not deal with the various other screen glitches, or the constant flicker at various brightness levels when looking at grey screens.
Please do not get the two issues confused.
_____________________________________________________________________________________________
I have observed a few patterns, on two seperate handsets with the same symptoms....
*Firstly, the flicker occurs while the CPU is under load, and particularly at lower battery levels.
*Secondly, The flicker occurs momentarily when you plug in a charger.
*Thirdly, The flicker doesn't occur while the device is charging.
*Fourthly (is that even a word), The flicker is often seen immediately after a screen settles, such as when the screen stops moving after scrolling.
All of these things are evidence of a power management issue. As if the backlight voltage is not being regulated correctly.
I did some more testing over the last few hours and have found something interesting. If you go to 'Settings' - 'Developer Options' - and enable 'Show Screen Updates', your phone will blink the screen different colours whenever the screen is updated. I found that when the screen settles, the screen is updated one final time, just a moment after it has settled. This is exactly when the flicker occurs. As i see it, this is further evidence that the flicker is power management related.
It seems to me that when the CPU goes from load to idle and changes its power draw, the backlight voltage regulation does not filter these fluctuations and the backlight flickers.
The question is, can this be altered either by the power management built in to the kernel, or by other power management software? Or is it a physical design flaw in the power regulation circuit?
The fact that the fluctuation only seems to occur when the brightness is set to auto leads me to believe that it indeed can be fixed with software.
If it was a physical supply voltage fluctuation when the CPU goes from load to idle, it would surely flicker all the time, not only on Auto Brightness.
I assume that the CPU voltage is altered by the kernel as the load level changes.
My question is, if the governor is changed to one which doesn't allow the CPU to scale or voltage step, does the issue go away?
Is there anyone out there who has rooted their device and can test my theory? I don't want to root my device as I may need to send it back DOA (it's only a day old).
If you can change the governor to a profile which doesn't allow stepping or voltage adjustment (100% Voltage and Frequency all the time), and the problem goes away, we have an answer and HTC can work on developing a new Kernel to fix the issue.
Thanks!!
Click to expand...
Click to collapse
i like the theory, but on the 4 out of 6 handsets i've had, the flicker started off only on auto brightness, then got worse over a day or two, and then would develop into a constant flicker, regardless of backlight settings.
Well i really hope thats not the case here as I only have 10 hours left of DOA return window. :S
Sentinel196 said:
This thread deals specifically with the 'Auto brightness backlight flicker'. Which only occurs when the phone is set to 'Auto brightness'.
This does not deal with the various other screen glitches, or the constant flicker at various brightness levels when looking at grey screens.
Please do not get the two issues confused.
_____________________________________________________________________________________________
I have observed a few patterns, on two seperate handsets with the same symptoms....
*Firstly, the flicker occurs while the CPU is under load, and particularly at lower battery levels.
*Secondly, The flicker occurs momentarily when you plug in a charger.
*Thirdly, The flicker doesn't occur while the device is charging.
*Fourthly (is that even a word), The flicker is often seen immediately after a screen settles, such as when the screen stops moving after scrolling.
All of these things are evidence of a power management issue. As if the backlight voltage is not being regulated correctly.
I did some more testing over the last few hours and have found something interesting. If you go to 'Settings' - 'Developer Options' - and enable 'Show Screen Updates', your phone will blink the screen different colours whenever the screen is updated. I found that when the screen settles, the screen is updated one final time, just a moment after it has settled. This is exactly when the flicker occurs. As i see it, this is further evidence that the flicker is power management related.
It seems to me that when the CPU goes from load to idle and changes its power draw, the backlight voltage regulation does not filter these fluctuations and the backlight flickers.
The question is, can this be altered either by the power management built in to the kernel, or by other power management software? Or is it a physical design flaw in the power regulation circuit?
The fact that the fluctuation only seems to occur when the brightness is set to auto leads me to believe that it indeed can be fixed with software.
If it was a physical supply voltage fluctuation when the CPU goes from load to idle, it would surely flicker all the time, not only on Auto Brightness.
I assume that the CPU voltage is altered by the kernel as the load level changes.
My question is, if the governor is changed to one which doesn't allow the CPU to scale or voltage step, does the issue go away?
Is there anyone out there who has rooted their device and can test my theory? I don't want to root my device as I may need to send it back DOA (it's only a day old).
If you can change the governor to a profile which doesn't allow stepping or voltage adjustment (100% Voltage and Frequency all the time), and the problem goes away, we have an answer and HTC can work on developing a new Kernel to fix the issue.
Thanks!!
Click to expand...
Click to collapse
As for your first issue regarding flickering at lower power levels, have you tried accessing the power-saving settings and turning off the setting which changes brightness at lower battery levels? The method of accessing power-saving settings is outlined here: http://forum.xda-developers.com/showthread.php?t=1627517
oh well again i guess
NVIDIA PRISM Display Technology - PRISM (or Pixel Rendering Intensity and Saturation Management) reduces a mobile device’s backlight power while simultaneously enhancing the pixel color to deliver the same visual quality with substantially extended battery life.
Click to expand...
Click to collapse
http://www.nvidia.com/object/tegra-3-processor.html
Thanks. I'll test that out to see if it makes a difference too.
Still hopeful someone with root can test changing the scaling setting for the CPU.
hamdir said:
oh well again i guess
Click to expand...
Click to collapse
It's a great guess. The sensitivity of this being wonky was one of the things causing problems on the Prime. It also affected individual devices differently, was worse in certain apps, and was most prominent when the display was showing a predominantly dark background.
So how did they fix it?
Sentinel196 said:
So how did they fix it?
Click to expand...
Click to collapse
Drivers and low-level code. And it took four updates to get everything stabilized (battery usage, CPU performance/stepping, graphics). This has little to do with HTC (the XL having no similar issues) and everything to do with Nvidia.
designgears said:
Pretty sure this has to do with the crappy gfx drivers. The same thing that cause the camera to have issues and the notification bar. While I had the international one x, the phone benched really well while those problems weren't happening, but as soon as I was able to reproduce them and ran the tests again, score was reduced by a lot.
I could reboot the phone and the problems would go away, only to come back after some use.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1619432
OK. So it looks like I'm on the right track and it's hopeful that this can be fixed in future updates
Thanks for the info.
Sentinel196 said:
OK. So it looks like I'm on the right track and it's hopeful that this can be fixed in future updates
Thanks for the info.
Click to expand...
Click to collapse
There were a bunch of really smart people and quite a few established devs on the Prime forum when it launched. When these problems started to occur, everyone was equally flummoxed. The one question that never was answered is why devices with identical h/w and s/w would perform differently and react to updates differently. Clearly they shouldn't. No one believed the issues could be corrected with s/w alone. Somehow they were. Neither Asus nor Nvidia ever answered the question as to the differences in individual device behavior. I don't blame anyone here for being skeptical. Something really funky is going on with Teg3 that no one will probably every truly understand. Truthfully, if the HSPA version of the One X was S4 too I’d have preferred it.
I guess it just comes down to variation in the tolerances of components.
I used to work in mil-spec electronics design and manufacturing and even with the tightest possible manufacturing tolerances, there was always variation.
BarryH_GEG said:
There were a bunch of really smart people and quite a few established devs on the Prime forum when it launched. When these problems started to occur, everyone was equally flummoxed. The one question that never was answered is why devices with identical h/w and s/w would perform differently and react to updates differently. Clearly they shouldn't. No one believed the issues could be corrected with s/w alone. Somehow they were. Neither Asus nor Nvidia ever answered the question as to the differences in individual device behavior. I don't blame anyone here for being skeptical. Something really funky is going on with Teg3 that no one will probably every truly understand. Truthfully, if the HSPA version of the One X was S4 too I’d have preferred it.
Click to expand...
Click to collapse
there is a lot to love about the Tegra mate, h264 video playback is amazing on it, also android is on steroids thanks to T3
but yes im with you on the issues, semi accurate reported crazy silicon issues, i don't find it hard to image that the Prism feature is just a cover up too
it was added later on the nvidia specs page
So, to sum this up guys - are you closer to say that flickering problem is actually only a matter of s/w?
I'm wondering how long it'll take HTC to admit that there are real issues and then how long we'll have to wait for the possible solution - replace, repair or just update the firmware :O
Anyways, this made me a bit more optimistic, since with unlocked bootloader it'd be hard to fight for the replacement
Sentinel196 said:
I guess it just comes down to variation in the tolerances of components.
I used to work in mil-spec electronics design and manufacturing and even with the tightest possible manufacturing tolerances, there was always variation.
Click to expand...
Click to collapse
Here's my theory. Nvidia's having yield issues with Teg3 and what's shippable is functional but varies in spec to a degree. The s/w is anticipating a range of responses from the h/w and what it's receiving is outside that range causing it to bork. Nvidia's "fix" is a combination of taming the h/w via low-level code and expanding what the s/w and drivers are capable of interpreting. And because of variations between chips, it's hard to test in a lab which is why it took four updates to resolve the Prime's issues. Again, just my theory.
I also believe both Asus and HTC were victims. There's no way both companies could be so ****ty at testing to have not caught this pre-production. My second theory is that Nvidia provided hand-picked chips early on that were right on spec and consistent so all the internal testing passed and units sent to professional reviewers all behaved optimally. It wasn't until production that inconsistencies between chips started to rear their ugly heads. Add to this that Nvidia's code, their drivers, and the kernel (still GB vs. ICS on the XL) are proprietary so both Asus and HTC are 100% dependent on them to resolve these issues.
Pretty ugly if I'm right.
BarryH_GEG said:
Here's my theory. Nvidia's having yield issues with Teg3 and what's shippable is functional but varies in spec to a degree. The s/w is anticipating a range of responses from the h/w and what it's receiving is outside that range causing it to bork. Nvidia's "fix" is a combination of taming the h/w via low-level code and expanding what the s/w and drivers are capable of interpreting. And because of variations between chips, it's hard to test in a lab which is why it took four updates to resolve the Prime's issues. Again, just my theory.
I also believe both Asus and HTC were victims. There's no way both companies could be so ****ty at testing to have not caught this pre-production. My second theory is that Nvidia provided hand-picked chips early on that were right on spec and consistent so all the internal testing passed and units sent to professional reviewers all behaved optimally. It wasn't until production that inconsistencies between chips started to rear their ugly heads. Add to this that Nvidia's code, their drivers, and the kernel (still GB vs. ICS on the XL) are proprietary so both Asus and HTC are 100% dependent on them to resolve these issues.
Pretty ugly if I'm right.
Click to expand...
Click to collapse
not hard to believe
one of the advertised features of Gerfoce 6 series was the pure video decoder, the entire 1st gen batch did not even work, it was broken in the silicon and Nvidia did not admit it until much later when the series was obsolete
hamdir said:
not hard to believe
one of the advertised features of Gerfoce 6 series was the pure video decoder, the entire 1st gen batch did not even work, it was broken in the silicon and Nvidia did not admit it until much later when the series was obsolete
Click to expand...
Click to collapse
Then you'll find this fascinating. Nvidia's PR exceeds their product’s capabilities by about 2:1.
http://semiaccurate.com/2012/05/01/why-cant-nvidia-supply-keplergk104gtx680/
BarryH_GEG said:
Then you'll find this fascinating. Nvidia's PR exceeds their product’s capabilities by about 2:1.
http://semiaccurate.com/2012/05/01/why-cant-nvidia-supply-keplergk104gtx680/
Click to expand...
Click to collapse
still you cant live without them bro, in our CG industry they are pioneers now thanks to their cuda cores and language
im sure they let marketing tint their transparency but semi accurate goes too far
Just got the GN for Sprint 2 days ago and have so far enjoyed my selection. I have run across an issue with the onboard barometer though. It seems to always read way lower that the pressure actually is. With every app I use it on it reads 1.2 mercuries low inHg and about 35 hPa low depending on which app I use. Is there any way to calibrate the sensor to compensate since not all apps have a calibration option?
Zero responses? There has to be some way to calibrate it since it uses a piezo system and not actual mercury.
Depends on where you are. It's not corrected for height, so if you are 1000ft above MSL, you'll read 1 inHg low because that's the actual pressure. Your local weather station/airport altimeter setting have corrected for altitude, so places like Denver, CO don't scare people by telling them the local pressure is lower than at the center of hurricanes.
Various apps have a built-in correction factor that you have to manually enter. Barometer HD and Barograph are two that I've found so far that have a correction setting. You have to play with it until it reads the same as the weather man says. Barograph seems cool because it periodically takes the reading, instead of telling you what it is every half a second. You only see the power of a barometer by observing the pressure changes over several hours. Another graph over time app I just found is Barometer Monitor. There's no correction factor, but it does allow you to specify how often it measures the pressure.
The idea is to create a very low cost app and sensor to monitor the cadence of a bicycle. Since most of app can find the speed through GPS, I need one that count how many RPM I'm doing.
1. I don't know how to program android app or even which language I should use
2. The idea consists on adapting one magnet on the crank and the other on the bike frame near to the crank course
3. When the magnet on the crank goes through the other one on the bike frame it should create a small current
4. This magnet would be wired to the android based cellphone (perhaps a Galaxy Nexus) on the audio port
5. The small current should generate a sound
6. This sound should be intepreted as one full cycle
7. The software must count and store how many cycles per minute I'm doing
How could one do this?
distance / circumference = rotations
It sounds like you already have distance traveled from the GPS record.
If you can measure your tires, πd (or 2πr) will give you the circumference, and distance/circumference will give you number of rotations, no additional hardware required.
marcoskp said:
The idea is to create a very low cost app and sensor to monitor the cadence of a bicycle. Since most of app can find the speed through GPS, I need one that count how many RPM I'm doing.
1. I don't know how to program android app or even which language I should use
2. The idea consists on adapting one magnet on the crank and the other on the bike frame near to the crank course
3. When the magnet on the crank goes through the other one on the bike frame it should create a small current
4. This magnet would be wired to the android based cellphone (perhaps a Galaxy Nexus) on the audio port
5. The small current should generate a sound
6. This sound should be intepreted as one full cycle
7. The software must count and store how many cycles per minute I'm doing
How could one do this?
Click to expand...
Click to collapse
As I understand marcoskp, he want to monitor cadence ( rate per minute of crank not wheel).
In this case you should have information of current transfer also if you want to use speed from GPS to calculate.
But you can have situation when crank is stable and you are still moving.
So external sensor is necessary.
Using audio port is very good and easy solution, but cause of wireing, have you consider BT sensor?
It should work same but instead connecting it to audio port you create switchable transistor and count full circles (simple counter) as a rising slope. And those information will be sent via Bluetooth (counter value).
It will be only little more expensive ( BT module here is only one with real cost, and it's quite cheap ) but much easier to mount.
Thanks saffron82. More than that, bikes works with differents gear ratio. Some are fixed, but today people uses 21 to 30 speeds (or 20 if you are using sram's 2x10). So cadence may change a lot if you are using a bigger or smaller ratio. The idea behind audio port is also to consume less energy. But I may be wrong. Perhaps bt consumes less energy.
saffron82 said:
As I understand marcoskp, he want to monitor cadence ( rate per minute of crank not wheel).
In this case you should have information of current transfer also if you want to use speed from GPS to calculate.
But you can have situation when crank is stable and you are still moving.
So external sensor is necessary.
Using audio port is very good and easy solution, but cause of wireing, have you consider BT sensor?
It should work same but instead connecting it to audio port you create switchable transistor and count full circles (simple counter) as a rising slope. And those information will be sent via Bluetooth (counter value).
It will be only little more expensive ( BT module here is only one with real cost, and it's quite cheap ) but much easier to mount.
Click to expand...
Click to collapse