Hi,
I read a lot about different hardspls and radios together with different roms result in faster or slower battery drain... But nobody really knows which is the best hardspl or radio combination for any rom.
that's why I set up a little website which could help with this..
http://www.smartwebdesign.ch/ppcbatt/
It's only very simple by now.. I don't want to put real work in it until I know what you think about!
If it's beeing used I will add a search interface for sure.. but for now I just want to know what you think and if people are willing to enter data...
Suggestions are highly welcome!
Greets Chaelli
nice intention
i think you should have a required field for the location where the phone is usedand the provider(some combinations work good in some regions/orivuders)
and the first fields should be drop down ones, to be able to select previously created entries, or create a new one(to be able to sort and filter data )
le:
it would be a good ideea , for all users to use the same tool to measure battery drain in standby, and with the screen turned on at maximum brightness
this would be an emphiric way of measuring battery drainage.
if you want accurate data, then only certified people can enter data into the site.
as mentioned, there are many variables, network, age of phone, how warm it is even.
dont think its possible personally, but a good idea.
Is there any software that can do a battery of tests on WinMo? Perhaps all chefs can cook them into their Roms so that it would launch right after the initial setup before any cabs are installed and perform the tests and at the end a summary will be displayed.
thx for the feedback!
@ravest: I will add these fields but not groub by them yet (useless until there is more data) - but I will add a possibility to show the details for every device/rom/radio where you can see these things (including the comments)
@others: I also thought about measuring.. but I don't think people will take the time to measure this exactely - that's why I've chosen to use a subjective measurement - usually one has a pretty good idea how one configuration works compared to another one (with the same usage pattern - which is usally not depending on the configuration but on the person...
I know that this is not good science.. but IF we get a lot of data I think the results would be usefull...
The only way to confirm battery life is in a laboratory, with the handset linked directly to certified test equipment and kept at constant transmitter/receiver levels.
Any public database of random opinions will be much less useful than individuals trying out all the different radio/ROM's for themselves.
As others have mentioned before there are too many variables on the way people use their phones, and different networks etc etc.
@optimiser: of course you are right - but I never intended to get an exact value - but an average user-feeling. People can compare different configurations on their personal phones !usually with other variables (like usage pattern, location, provider) staying stable! - and this is what's important.. one can compare the different configurations against each other
chaelli said:
@optimiser: of course you are right - but I never intended to get an exact value - but an average user-feeling.
Click to expand...
Click to collapse
And therefore it is useless, as us humans, can't properly judge battery drain (which is measurable in mAmps) by "user feeling".
In order to measure battery drain you would need to set up a test procedure, which must include (beside the others) the following:
the same phone
the same period of time
same usage
and WORKING measurement tool. Not a software (because they tend to swtich of on standby mode) but plugged external measurement.
THEN you could approach some kind of fair measurement. Otherwise it's "how you feel", and as long as you are happy with your feelings, it's perfectly OK.
Cheers.
Related
Hi,
Have spent a great deal of time browsing through the site, and trying out some of the ROMs. Which has led me to the following...
The Company I work for has deployed a large number of XDA-II's (Himalaya), and we've encountered a number of reliability problems with them, not to mention users unable to keep the devices charged.
The consequences of these problems are: 1) Lost software installs and 2) Extra support time.
We've also found the O2 active UI to be a right royal pain in the ar5e!
So, having been playing around with ROMs, I have an idea of what is possible. But, to date, I've just not been able to find exactly the ROM I'm looking for. I'm quite happy to sit down and try and figure things out for myself, but it's quite difficult to try and find a good chunk of spare time.
So, here's the point of my message.
If I can identify the components I need to be installed within a "special edition" cooked ROM, would someone be able to help me build it? I'm basically looking for WM2003SE, so that the screen can be flipped into landscape - or a third-party progam to do that, a wireless email client that I will provide, backup software that I will provide, all the usual hardware stuff (BT, camera etc), no O2 UI (Hoorah!), and maybe one or two other packages, and as much storage/memory available as possible, and, of course, the ability to add a splashscreen. That's it - nothing too out of the ordinary. All of the additional software will be licensed.
So, that's my idea. What do you get in return? Well, I'm more than happy to donate to the site, and, come to some arrangement with anyone that is interested in helping - perhaps some hardware/software etc.
This would save me a lot of time, and be quite an interesting project - to see so many devices get a decent upgrade, and one that helps reduce support overheads.
Please PM me if you are interested.
Thanks.
Vince
well you can
select the win2003se rom you want and put the rest in a cooked extended rom that was what i did i put all cabs i needed in extended rom if the device gets hard reset it will install everything there
the config file must have the names of course
you can get some of the setting there too like operator settings
you can allways donate to xda-developes....lol
PS ...i m not part of xda-developers or in any way associated with them just a user who is glad they existed.
Hi, my name is Eric. I've been working with WinCE for a long time (since WinCE 2.0 haha) and I've regained interest in PPC programming. Working with few things here and there, mostly experimenting.
In anycase, I've got an idea to record g forces on a vehicle while it's being tested to its limits (AutoX, drag race).
Now, I know there's already a piece of software out there, gPC, but it isn't completely refined (indepth calibration, angle corrections) or completely free (by donation).
The goal of the project is to create something similar to a device called gTech which goes upwards of $300 for the basic model.
Key features will include:
- a reset function + algorithms to compensate for device orientation
- graphs of resulting logged data
- logging of calibrated data and raw data
- Driving aids
- Flashing screen to indicate reaching of new peak G (separate indicators for forward and lateral)
- a screen showing realtime overlapping graphed data for all axis
- a 2d grid with a cursor indicating current forward and lateral g
- on the same 2d graph, a drawn boundary indicating limits of g achieved (this will eventually look like an egg after working the car hard)
- and finally, real time telemetry transmission via edge/3g to a receiving computer
The ultimate goal of this project is to provide reliable data for motor enthusiasts whether they would like to see if their shifting is smooth, or if they're braking, or powering on in the right places or if their car mods have had any effect (this last one is pretty useful to quantify). In addition, provide some rudimentary tools to assist in competitions and spirited driving in the form of g limit warnings (flashing screen, large indicators of current g). In the case of spirited driving on a mountain road, the device can warn when approaching loss of traction (after collecting limit data) to prevent going off a cliff.
Venues of use:
Auto Cross
Track Days
Drag Strip
Skidpad
Of course, I have to insert here, that this device can't save your bacon if you do something idiotic and by no means do I condone dangerous driving.
With that said, all the above is what I hope to achieve and any of your comments is well appreciated.
Current Release:
v0.1
Alpha stage, rudimentary raw data output via numbers and a line (indicating X and Y recorded g) and a circle (indicating Z g). The numbers shown are the raw numbers recorded from the accelerometer and not converted to m/s^2. Although, you can probably do that math on your own if you're smart enough (simple scaling). What I've discovered is that each accelerometer is different, and even going from a negative axis (eg, device upside down) to positive axis (device right side up) will give different numbers. In addition, if you run the program, you'll notice a lot of jitteriness. I hope it doesn't affect the accuracy once I smooth them out with a segmented average.
Executable is packaged in a zip. It contains an EXE which can be straight run with Dot NET CF v2.0 (basically, all WM 6.1 devices)
Hi Canagan,
Great idea, I will certainly be testing this out.
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Thanks.
Whoooaaa sound a really good app ! Will test it this weekend ! Thanks
PooleyUK said:
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Click to expand...
Click to collapse
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Great idea.. I will test it also
It seemt to be working on my Touch HD. But are the meaning of all these numbers??
CanaganD said:
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Click to expand...
Click to collapse
Cool, looking forward to seeing this develop.
So far the accelerator test seems to be working fine.
would be need ive i could see how many hp mycar has
Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
Hello,
I just made a Public Google Doc sheet, where we can compare all the ROMs and battery drain to see wich one is working the best.
I hope that this form can be filled seriously and will show some interesting stuff.
The form is here: http://spreadsheets.google.com/viewform?hl=en&formkey=dDFfc0YtTGV5R0h1cnhOS1JfR3NKQmc6MQ#gid=0
and results here: http://spreadsheets.google.com/ccc?key=0AhpXApcdNdskdDFfc0YtTGV5R0h1cnhOS1JfR3NKQmc&hl=en#gid=0
Please tell me if you want an acces to the sheet to edit and add some informations.
Thank a lot and I hope you won't find that stupid.
You should make it more clear what exactly should be on/off durung the test.
Having anything enabled besides the phone radio will increase the drain.
My experience varies between 0.4%/hour and 2%/hour depending on whether I enable mobile data and autosync or not for example.
Nice idea, but seem that that would be so complicated to present all the datas.
I am thinking that having the average score would be representative. Do you want the right to access the file to modify the form and add some extra informations?
Send me your email in PM.
This was posted (not by me) on the old forums but I want to discuss it over here;
I’ve started to put together a simple widget for calendar events and bumped into the problem that #C0# might have a start date in the past (when that event is just happening). In this case, #C0S# might even be yesterday. I tried to base my script on “R” and “T” parsers, but had to face the fact that these give an absolute value.
As abs() function is available among maths features, while on the other hand generating the positive/negative sign for it with additional calculations is fairly complicated, I’ve been wondering if it would be possible to provide this data in a negative form for past dates.
If there’s a reason for the absolute value, it’d be also a great help to have a simple parser that gives -1 for past dates and 1 for future ones.
A UNIX date parser for #D…# might also come handy and could give a possible workaround, although I’d rather prefer the past-date-parser.
Click to expand...
Click to collapse
My suggestion is to get rid of the absolute value from the "R" and "T" parsers and replace it with negative & positive numbers. Feature request?