GetServingCellInformation, index starts at 0 or 1?

Hi, please help me with a stupid doubt: for org.freesmartphone.GSM.Monitor, GetServingCellInformation() the spec states: ( ctype, int ): Cell Type Indicator NA/GSM/GPRS This means 0:NA / 1:GSM / 2:GPRS right? Not 1:NA / 2:GSM / 3:GPRS? Thanks, Onen

GetNeighbourCellInformation, MCC and MNC

GetStatus()? Thanks, Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards

Re: FSO/SHR Meeting, a.k.a FSOSHRUDCON (c) mrmoku

Hi, would it be open to people out of SHR and FSO teams? Because I would be interested, in meeting the people to talk about all you have mentioned. I have a preference for Paris, but am open. Onen Julien Cassignol wrote: Hi everyone, It's been quite some time we've been working together

No DBus signal when call ongoing, but signal strength changes

? Thanks, Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards

Re: 'GSM' sometime means GPRS, sometime not

Don't you think the framework could unify all of this, for better consistency? Onen Michael 'Mickey' Lauer wrote: Am Samstag, den 07.03.2009, 12:22 +0100 schrieb Onen: I was wondering if it was not misleading to have GSM and GPRS distinct in one method, and GSM meaning GPRS in another

When in a call, GetNeighbourCellInformation returns garbage data

on? Is this supposed to be this way with the current modem? Should we add a note in the specs to let future user of the API know? Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman

Re: GetNeighbourCellInformation, MCC and MNC

Michael 'Mickey' Lauer wrote: Am Montag, den 09.03.2009, 21:24 +0100 schrieb Onen: the GetNeighbourCellInformation() method in org.freesmartphone.GSM.Monitor interface does not provide MCC and MNC fields. MCC and MNC is a higher level functionality connected to the notion

Re: Future of an Open Phone - Diner at FSOSHRUDCON

Hi, this is a great idea. I am very much interested in such a talk. Count me in for sure. Onen Stefan Schmidt wrote: Hello. I changed the normal dine on saturday to the catchy name Future of an Open Phone - Diner. Question we like to discuss there are less in the area of middleware

Re: Three different databases for gsm celltower locations

Hi, Thomas Landspurg wrote: The good news is that we are communicating and discussing while progressing slowly. With Sebastian of CellHunter, we basically agree that Cell Hunter would upload is cells to OpenCellID while maintaining their own database for the purpose of the game. With Onen

Re: Three different databases for gsm celltower locations

/USB etc... Onen ___ 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

answering here. Step back and think about it. I don't want flames but constructive work here. :) As said before, I will keep trying to find other ways which would bring everybody to an agreement... Onen ___ smartphones-standards mailing list smartphones

Re: Three different databases for gsm celltower locations

Hi, Stefan Schmidt wrote: On Sat, 2009-04-04 at 15:03, Onen wrote: Another point is the other signals than GSM. Our initial vision was to build a database of communicating objects, WiFi, Bluetooth, etc... Can anybody give me some ideas how BT should be useful here? From what I

Re: Three different databases for gsm celltower locations

Timo Juhani Lindfors wrote: Onen onen...@free.fr writes: A reason why BT may still last over WiFi may be the power needed to have BT on in comparison of WiFi, don't you think? What about digital radio broadcasting stations or RDS information from regular radios? These are very interesting

GSM location in FSO

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? Thanks, Onen [1] http://git.freesmartphone.org/?p=framework.git;a=commit;h

Re: Three different databases for gsm celltower locations

the final position. Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards

Re: [FSOSHRUDCON] Call for talks!

feedback. If interested... Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards

Re: [olocationd] Please comment on openBmap format for raw data download (GSM/GPS data)

identifier instead of a real name? I don't know in fact. But so far, in order to protect privacy of people, we are going in direction of a file containing the list of contributors, and all the raw XML files without being linked to its contributor. Thanks for your input! Onen

[FSOSHRUDCON] Added Travel section (car pooling, etc.)

, or car pooling, etc. Hope this helps, Onen ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards

Re: OT: LinuxTag '09 in Berlin, Germany

I can be there and help about FSO, gnufiish (I mean I have for them a general knowledge), and present openBmap. I am not sure what days exactly, I can make it. Is this info mandatory right now? Onen Michael Lauer wrote: Fso for sure, openezx, gnufiish, openbmap (onen?), htclinux. Cheers

Re: OT: LinuxTag '09 in Berlin, Germany

://www.freesmartphone.org OpenEZX http://www.openezx.org GnuFiishhttp://www.gnufiish.org Which else? openBmaphttp://www.openBmap.org Onen ___ smartphones-standards mailing list smartphones-standards