Re: proposal for wakeup interface
On Sat, 2009-01-24 at 13:19 +0100, Sander van Grieken wrote: Hi, I'm new to this list, and maybe it has been discussed before, but I have a proposal for the wakeup interface of the RealtimeClock module of odeviced. The problem with the current interface is that it only allows you to set or reset the wakeup time, thereby overwriting the previous setting, which might have been something some other app depended on. In other words, this service doesn't allow for multiple applications to co-exist. My proposal is to change the wakeup service to a 'stateful' service, where different clients can request a wakeup time, and the service manages the list of requested wakeup times, selects the earliest wakeup time (in the future of course) and programs the device wakeup timer. Once the timer fires (or when the device enters suspend), the service selects the (chronologically) next wakeup time and stores it in the wakeup timer. the API would look something like this; - RegisterWakeupTime ( time, appId ) # register a wakeup time from an application (maybe dbus sees the ID of the caller, which would mae the appId obsolete but I'm not so experienced with dbus) - UnregisterWakeupTime ( time, appId ) # clears a specific wakeup time - UnregisterWakeupTime ( appId ) # clears all wakeup requests from app appId - GetWakeupTime () # would return the first-to-occur wakeup time - ListWakeupTimes () # would return all requested wakeup times, in chronological order Something like this is available in org.freesmartphone.Time.Alarm interface of otimed. Each app can only register one timestamp. When the Alarm time is reached the service will call org.freesmartphone.Application.Alarm() on the sender. This is not yet documented, please look at subsystems/otimed/alarm.py for more details. :( -- Jan Lübbe jlue...@lasnet.dehttp://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Three different databases for gsm celltower locations
Please excuse the late reply... On Mon, 2009-04-06 at 21:53 +0200, Onen wrote: Hallo Jan, I have seen the last commits from you about adding GSM based localisation. First this is great, that it reaches the framework! This brings me some questions: 1. This has been especially a surprise to us, as we at openBmap have currently been thinking how to bring this to the users. We already did some work on exporting the database under SQLite files for every country. And on top of this, a small DBus service to bring the localisation to everyone... I hacked this together in some spare hours while i was in Bern for OpenExpo, so this is in no way the final code or interface. I just wanted to try out the data i've been collecting with Cellhunter (BS conenction). The cell db is currently exposed via ogsmd. The location interface should be distinct from that. I've been talking with Daniel about this for some time: * each client should request an accuacy and an update frequency, the location daemon will then choose the an approach to find the location (cells/wifi, GPS) * maybe also some notifications for locations I am no hacker, but still would have hoped to bring some help on this... If you are interested, how would you like to proceed? 2. I had a look at the code, and suppose you are building your database out of the data from CellHunter. Am I correct? Yes. The algorithm i use is extremly simple: I just calculate the boundingbox of all measurements for a given cell and then store the center and radius in a binary file. When calculating the position, i just average all found positons, or if none a found, take the center of the LA's bounding box. I think CellHunter is a great project but we still think that we should log HPV-Dops, speed, in order to be able to filter low quality measures. This is currently discussed on another thread on this list [1]. If you combine a high speed with low Dops, you end up with very unprecise positions for building the cells coverage, don't you think? For now even the signal strength is not used in my code. Still, it gives an accuracy that should be useful for AGPS. I would like to know what is your opinion about all of this. Are you interested in our approach, and are you interested in taking in consideration in your code the extra fields our data contains (Dops, speed, software id, software version, etc.) to possibly filter measures to keep only higher quality? I would propose to include even more data: * some GPS receivers can give an inaccuracy in cm in addition to DOP, this even includes position errors from reflections, fading and not just the satellite position geometry * speed and *direction*, the handover algorithm used by operators take these into account, so we should collect them * if we are in a call or have a GPRS * if available, log the timing advance * don't log each neighbour seprately, but upload a measurement report with time, position and *all* current cells (serving + neighbours). also log what the max amount of tracked neighbours is. then we can deduce which cells are *not* visisible at that position. this should give us better accuracy by using signal shadowing. * also allow logging of different radio technologies (GSM, UMTS, Bluetooth, Nearfield/RFID, WiFi b/g, ...) with the same measurement report. Also please take a look at: http://lwn.net/Articles/304218/ and http://lwn.net/Articles/325016/ -- Jan Lübbe jlue...@lasnet.dehttp://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Three different databases for gsm celltower locations
On Tue, 2009-04-07 at 23:49 +0100, Joerg Reisenweber wrote: Am Sa 4. April 2009 schrieb Stefan Schmidt: OpenBmap likes to have more fields for quality informations about GPS and GSM. I strongly suggest to include fields for TimeAdvance values for each BTS. TA is a much better and more reliable value for distance to Base Transmitter Sation than dB signal strength. See: http://lists.openmoko.org/pipermail/openmoko-kernel/2008-April/002434.html and http://lists.openmoko.org/pipermail/openmoko-kernel/2008-June/002987.html As Jörg said, the timing advance is only valid while a channel to the BTS is open. An active GPRS connection is enough, but the TA for that is sent in the EM command for GPRS. When it is invalid 255 is sent, otherwise the actual value. You may need to create traffic to see a vaild TA here. The TA field for voice calls uses '0' for invaild, so it's not as nice for getting proper readings. -- Jan Lübbe jlue...@lasnet.dehttp://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
FSO Milestone 5.5 Preview Image
Hello! To prepare for the upcoming release of FSO Milestone 5.5, i've built an image which contains the latest versions of our software. We want to give you a preview of the changes and get some final testing before the release. Some notable changes since MS5.1 (a complete list will be published with the final release): * ogsmd: + Revamped timeout handling and parser, better unsolisticated message handling + Support for more optional SMS features, submit/delivery reports + Handle corrupt SMS PDU better + Updated network database + Improve support for the Freescale Neptune and Qualcomm MSM modems + Implement a demo cell location service (using the cellhunter DB) + API: Change network code from int to string see: http://git.freesmartphone.org/?p=specs.git;a=commit;h=7547d409977666eebb5117e4fc837ec6f19a4553 * ogpsd: + Fix and reenabled ephemeris upload (~ 16 sec TTFF is possible) * ophoned: + Support Bluetooth headsets * otimed: + Use the network supplied offset in countries with more than one time zone + The NTP servers ip can be configured in frameworkd.conf Also, there have been a lot of bugfixes all over the framework. For people who flash their device very often, we now try to bind mount /media/card/bind-home to /home/root. Just create that directory on your SD-Card and it will be mounted on the next reboot. There are some known issues with the current build, please report any additional problems to: http://trac.freesmartphone.org/ * oeventsd has a race condition which sometimes causes failure to inhibit suspend or dimming * illume's shutdown menu is only one pixel wide * the org.freesmartphone.GSM.Monitor commands sometimes report invaild data * the aux button sometimes does not enable the display after dimming * there is currently no GUI for BT headset configuration, use opreferencesd for this You can get the image here: http://buildhost.freesmartphone.org/~jluebbe/ms5.5-preview/images/om-gta02/ Thanks to everyone who has submitted patches and bug reports! We can't do this without you :) Waiting for new bug reports, -- Jan Lübbe jlue...@lasnet.dehttp://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
