<br><br><div><span class="gmail_quote">On 11/28/06, <b class="gmail_sendername">Sean Moss-Pultz</b> <<a href="mailto:sean_mosko@fic.com.tw">sean_mosko@fic.com.tw</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 11/28/06 2:24 AM, "Tomasz Zielinski" <<a href="mailto:tomasz.zielinski@gmail.com">tomasz.zielinski@gmail.com</a>> wrote:<br><br>> Questions to hardware developers:<br>> 1. How long does the battery live with only GSM unit active?
<br>> 2. How long with GSM and GPS?<br>> 3. How long with GSM, GPS and Bluetooth?<br><br>We really don't have these answers at this point. I will keep you all<br>posted.<br><br>> 4. Is the user-mode software allowed to turn on and off various
<br>> modules? In example: crontab task turns the GPS on, read coordinates,<br>> process them, turns GPS off and sleep for 15 minutes.<br><br>This is an open device...even down to the kernel. Whether we allow this or
<br>not, if somebody wants to do it, it can happen ;-)<br><br>-Sean</blockquote><div><br>Um, the only thing I see as a problem, since you said in a previous email ( or later, I'm not sure, this is the order I read them) that all the hardware requires an non-disclosure, either you're going to need to provide access to the power up/sleep commands thru the drivers, or reverse engineering this is going to suck, assuming there's even a software sleep command(I'd assume so, but normally that begets bad things) even a nice constant for the commands, and a passthrough character driver would be really nice.
<br><br>I'm not asking you to go farther than your agreement, but if you could map the system commands for the major components into the driver, that would be a wonderful help<br><br>Thank you so much, Sean, for making this all possible, it's really a wonderful thing
<br><br>--Jeff<br></div><br></div><br>