Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 6 hrs ago - more...
| The Following User Says Thank You to kernelpanic For This Useful Post: | ||
 |
|
2008-06-04
, 20:09
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#42
|
There's an OS2008 cron kicking around somewhere, but I'm not sure it's in a repo. Besides, cron's not so hot here; we don't want only clock-based actions, but also event-based -- like on establishing an internet connection...
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
|
|
2008-06-04
, 20:54
|
|
Posts: 373 |
Thanked: 56 times |
Joined on Dec 2005
@ Ottawa, ON
|
#43
|
Have you considered the fact that the thief is not going to be able to charge the tablet unless you happen to have your charger chained to your tablet at all times. This has certain implications:
1) The window of opportunity for any recover attempt is rather small. A day or two maybe. It needs to be pretty aggressive in recognizing that the tablet is stolen and collecting the necessary data.
2) The thief is most likely stealing the tablet to pawn it off somewhere else or at least will do so as soon as it is dead. Also they likely have no clue as to how to operate it. It is fairly intuitive but not *that* intuitive. The likelihood of a thief to research how to operate it and which charger to buy and then go out and find one is unlikely.
3) Given 2), your most likely utility of this app is recovery of the tablet from some unsuspecting mark who it was sold to off the back of a truck and not in capturing of the thief.
Keep these things in mind when designing your triggering frequency and what data it collects.
The GPS data of the complete track from theft detection to recovery might give invaluable info to the police in finding the thief even if it was fenced to someone else.
Capturing a photo of the thief might require some social-engineering to get them to activate camera capture at the right time (have it ring like a phone or something and blink some acknowledgment message on the screen that says "Press here to answer/hang up" :]).
Use the ambient light sensor on the N810 (if you have one) to detect when it has good conditions to take some pictures or handling of the tablet. There is no point in transferring a bunch of black pictures of the inside of someones pocket.
Even if wifi is not available, taking pictures and GPS data in a "store and forward" mode when wifi is around will give more opportunities for good data capture.
Just a few thoughts that may have already been mentioned.
1) The window of opportunity for any recover attempt is rather small. A day or two maybe. It needs to be pretty aggressive in recognizing that the tablet is stolen and collecting the necessary data.
2) The thief is most likely stealing the tablet to pawn it off somewhere else or at least will do so as soon as it is dead. Also they likely have no clue as to how to operate it. It is fairly intuitive but not *that* intuitive. The likelihood of a thief to research how to operate it and which charger to buy and then go out and find one is unlikely.
3) Given 2), your most likely utility of this app is recovery of the tablet from some unsuspecting mark who it was sold to off the back of a truck and not in capturing of the thief.
Keep these things in mind when designing your triggering frequency and what data it collects.
The GPS data of the complete track from theft detection to recovery might give invaluable info to the police in finding the thief even if it was fenced to someone else.
Capturing a photo of the thief might require some social-engineering to get them to activate camera capture at the right time (have it ring like a phone or something and blink some acknowledgment message on the screen that says "Press here to answer/hang up" :]).
Use the ambient light sensor on the N810 (if you have one) to detect when it has good conditions to take some pictures or handling of the tablet. There is no point in transferring a bunch of black pictures of the inside of someones pocket.
Even if wifi is not available, taking pictures and GPS data in a "store and forward" mode when wifi is around will give more opportunities for good data capture.
Just a few thoughts that may have already been mentioned.
| The Following 3 Users Say Thank You to mwiktowy For This Useful Post: | ||
|
|
2008-06-04
, 21:14
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#44
|
Originally Posted by mwiktowy
Well, it is a standard Nokia charger; if the thief makes a habit of stealing phones, hocking most and keeping a really nice one for himself, he's got such a charger; if not, I'd say about 25% chance that he has or has access to one. And if this device (which some people can't tell isn't an iPhone, and everyone knows the iPhone is the greatest thing since bread of any sort) catches someone's interest, it's not unrealistic to suppose they'd notice the Nokia logo, conclude it's a Nokia iPhone, and go buy a charger. Still, can't assume that's the case...
Have you considered the fact that the thief is not going to be able to charge the tablet unless you happen to have your charger chained to your tablet at all times. This has certain implications:
1) The window of opportunity for any recover attempt is rather small. A day or two maybe. It needs to be pretty aggressive in recognizing that the tablet is stolen and collecting the necessary data.
2) The thief is most likely stealing the tablet to pawn it off somewhere else or at least will do so as soon as it is dead. Also they likely have no clue as to how to operate it. It is fairly intuitive but not *that* intuitive. The likelihood of a thief to research how to operate it and which charger to buy and then go out and find one is unlikely.
3) Given 2), your most likely utility of this app is recovery of the tablet from some unsuspecting mark who it was sold to off the back of a truck and not in capturing of the thief.
Keep these things in mind when designing your triggering frequency and what data it collects.
The GPS data of the complete track from theft detection to recovery might give invaluable info to the police in finding the thief even if it was fenced to someone else.
Capturing a photo of the thief might require some social-engineering to get them to activate camera capture at the right time (have it ring like a phone or something and blink some acknowledgment message on the screen that says "Press here to answer/hang up" :]).
Use the ambient light sensor on the N810 (if you have one) to detect when it has good conditions to take some pictures or handling of the tablet. There is no point in transferring a bunch of black pictures of the inside of someones pocket.[/quote]That's really good, too. On the N800, of course, you'll obviously limit it to taking pictures when the camera's out; but those can be pretty handy; obviously the guy's playing with it, pops the camera out, looks at it, swivels it, looks at it some more... mugshot material, no?[/quote]
Even if wifi is not available, taking pictures and GPS data in a "store and forward" mode when wifi is around will give more opportunities for good data capture.
Just a few thoughts that may have already been mentioned.
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
| The Following User Says Thank You to Benson For This Useful Post: | ||
 |
|
2008-06-04
, 21:22
|
|
Posts: 4,384 |
Thanked: 5,524 times |
Joined on Jul 2007
@ ˙ǝɹǝɥʍou
|
#45
|
It's great fun to watch an active committee at work designing a camel *g*
The iphone implementation sounds quite simple and appealing actually.. why not start with something simple so people can take advantage of it ASAP?
.. and then let it grow.
The iphone implementation sounds quite simple and appealing actually.. why not start with something simple so people can take advantage of it ASAP?
.. and then let it grow.
|
|
2008-06-04
, 21:37
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#46
|
The iPhone has an always-on connection; that connection is to a GSM tower, which gives you exact distance from a fixed location right off, and often triangulation allows an exact postion. We're not so lucky; that solution won't do much good. But feel free to implement something simple like that, if you feel it's useful.
You'll need to install cron, install gpsd-clients*, add one line to crontab, and make about a 5-line shell script. Dunno about twitter, but you can FTP or SSH the data somewhere, if nothing else.
*<plug shame="none" href="http://www.internettablettalk.com/forums/showthread.php?t=20652">gpsd-clients</plug>
But this simple solution can't be developed into the sort of thing you're discussing. If you read between the lines, we've pretty clearly established an architecture of a simple daemon with plugins to accomplish the more interesting & complex tasks. That's how you make something that can actually grow usefully...
Last edited by Benson; 2008-06-04 at 21:49.
You'll need to install cron, install gpsd-clients*, add one line to crontab, and make about a 5-line shell script. Dunno about twitter, but you can FTP or SSH the data somewhere, if nothing else.
*<plug shame="none" href="http://www.internettablettalk.com/forums/showthread.php?t=20652">gpsd-clients</plug>
But this simple solution can't be developed into the sort of thing you're discussing. If you read between the lines, we've pretty clearly established an architecture of a simple daemon with plugins to accomplish the more interesting & complex tasks. That's how you make something that can actually grow usefully...
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
Last edited by Benson; 2008-06-04 at 21:49.
| The Following 2 Users Say Thank You to Benson For This Useful Post: | ||
|
|
2008-06-05
, 00:03
|
|
Posts: 179 |
Thanked: 90 times |
Joined on Dec 2007
|
#47
|
Hello All,
This thread gets better all the time!
mwiktowy- Way ahead of you. Had already thought and discussed most of this. My plan was to-
1. use the ambient light sensor, the keyboard slide, and certain dbus signals to detect when to take pictures. If it's event driven it shouldn't use too much juice. Certainly a lot less than the backlight.
2. Attempt GPS connection ~every 30 minutes, but if it doesn't get at least 2 satellites within 3 minutes assume it's indoors and shut off. If it gets a connection, keep the track until it goes indoors. i.e. if it loses fix for 3 min. kill it and try later. My experience is that with the GPS on/screen off and a full battery it can still run for 6-8 hours. This'll be far less of an issue with aGPS. (Also do something similar with wireless IAPs and possibly bluetooth. It only takes a couple of seconds to get all available APs via libconic. This could give a rough fix for devices without GPS like the n800.
3. cache all pictures and data for when it has a connection (possibly targz'ed) and send it all in a batch.
4. Even if it goes dead, eventually someone (your unsuspecting buyer perhaps) will charge it and turn it on. At which point it'll report in again. (Until it's reflashed...) Recovery of the tablet is the primary goal. But catching the thief would be nice too.
5. As Benson pointed out- cron has it's limitations. It'll also likely kill the battery faster than what we're talking about. A lot of the functionality of this daemon is going to be in event-driven dbus callbacks.
To be honest, I can breeze through all of the above as I know libgpsbt, libconic, and the like fairly well. The libcurl stuff is halfway done already. But I've never used libgpgme, so that's where I'm on a learning curve. And for the app to be solid, that's what has to come first.
To phi and ysss- if y'all want to design an iPhone-like implementation go ahead. No one is stopping you. If it's so easy, you could have been done in the time it took me to post this
I'll continue to build my camel at a snail's pace of ~100-200 lines of code a day. My only deadline is to finish it before my tablet gets stolen...
cheers,
kernelpanic
This thread gets better all the time!
mwiktowy- Way ahead of you. Had already thought and discussed most of this. My plan was to-
1. use the ambient light sensor, the keyboard slide, and certain dbus signals to detect when to take pictures. If it's event driven it shouldn't use too much juice. Certainly a lot less than the backlight.
2. Attempt GPS connection ~every 30 minutes, but if it doesn't get at least 2 satellites within 3 minutes assume it's indoors and shut off. If it gets a connection, keep the track until it goes indoors. i.e. if it loses fix for 3 min. kill it and try later. My experience is that with the GPS on/screen off and a full battery it can still run for 6-8 hours. This'll be far less of an issue with aGPS. (Also do something similar with wireless IAPs and possibly bluetooth. It only takes a couple of seconds to get all available APs via libconic. This could give a rough fix for devices without GPS like the n800.
3. cache all pictures and data for when it has a connection (possibly targz'ed) and send it all in a batch.
4. Even if it goes dead, eventually someone (your unsuspecting buyer perhaps) will charge it and turn it on. At which point it'll report in again. (Until it's reflashed...) Recovery of the tablet is the primary goal. But catching the thief would be nice too.
5. As Benson pointed out- cron has it's limitations. It'll also likely kill the battery faster than what we're talking about. A lot of the functionality of this daemon is going to be in event-driven dbus callbacks.
To be honest, I can breeze through all of the above as I know libgpsbt, libconic, and the like fairly well. The libcurl stuff is halfway done already. But I've never used libgpgme, so that's where I'm on a learning curve. And for the app to be solid, that's what has to come first.
To phi and ysss- if y'all want to design an iPhone-like implementation go ahead. No one is stopping you. If it's so easy, you could have been done in the time it took me to post this
I'll continue to build my camel at a snail's pace of ~100-200 lines of code a day. My only deadline is to finish it before my tablet gets stolen...
cheers,
kernelpanic
 |
|
2008-06-05
, 00:26
|
|
Posts: 698 |
Thanked: 129 times |
Joined on Oct 2007
@ CA
|
#48
|
What if, instead of having the central server, the device would just email the info to the owner? Would make things simpler, no?
|
|
2008-06-05
, 01:51
|
|
Posts: 373 |
Thanked: 56 times |
Joined on Dec 2005
@ Ottawa, ON
|
#49
|
Originally Posted by kernelpanic
Figured as much :]
Hello All,
mwiktowy- Way ahead of you. Had already thought and discussed most of this.
...
2. Attempt GPS connection ~every 30 minutes, but if it doesn't get at least 2 satellites within 3 minutes assume it's indoors and shut off. If it gets a connection, keep the track until it goes indoors. i.e. if it loses fix for 3 min. kill it and try later. My experience is that with the GPS on/screen off and a full battery it can still run for 6-8 hours. This'll be far less of an issue with aGPS. (Also do something similar with wireless IAPs and possibly bluetooth. It only takes a couple of seconds to get all available APs via libconic. This could give a rough fix for devices without GPS like the n800.
I wonder what the difference in power draw is between keeping the GPS on vs. turning it off and on periodically (and forcing it to do more computing to update its position). I haven't done any investigations but from my limited use of the GPS, it isn't a huge power drain as it is a just passive (but really accurate) receiver of a time signal
I am having trouble with something draining my battery too quickly (clobbered metacrawler and fixed flash fs corruption but it didn't help) right now so any valid tests will have to wait until I have a clean Diablo slate.
 |
|
2008-06-05
, 03:03
|
|
Posts: 566 |
Thanked: 145 times |
Joined on Feb 2008
@ Tallahassee, FL
|
#50
|
Originally Posted by kernelpanic
dang! I thought you were going to try to haave it done before mine was stolen!
My only deadline is to finish it before my tablet gets stolen...
__________________
N800 / OS2008
Now running Canola-free (by invitation) since 2215 UTC 21 May 2008.
N800 / OS2008
Now running Canola-free (by invitation) since 2215 UTC 21 May 2008.
| The Following User Says Thank You to briand For This Useful Post: | ||
Besides, I'm well into coding my daemon at this point.
Speaking of that, Progress Report-
I've got all the libraries I need (I think). I'm using libcurl for downloads/uploads and gpgme for crypto. (Since osso-gnupg bites on os2008, I'm targeting the first *real* release of this for Diablo which looks to have a real version of gnupg...) I do have that newer SVN versions of gnupg and osso-gnupg (which is just a wrapper to keep dependencies from breaking.) compiled and running on os2008. Which is nice in and of itself. Also, since Diablo has aGPS support, fixes should be fast enough that the thief shouldn't notice any battery drain or other weirdness...
As far as the daemon goes, the framework is there, though a lot of the data-gathering functions are empty. I'm coding the check-in/gnupg stuff now and hope to have it working against a (test) webserver fairly soon. After that will be the put/upload code, then the data gathering.
Once I've got a basic daemon built, I'll release the source for review/comment/contribution. At that point I'll be starting work on the server end.
Cheers,
kernelpanic