[Neo1973] AGPS - globallocal cuckoo's egg? Re: AGPS server questions
Salve Harald, Sean! I fear AGPS from globallocal is a coockoo's egg - they anounced that their AGPS chips cost only 5 US$ - I fear they will make money with their AGPS server services http://www.globallocate.com/NETWORK/NET_AGPS_SERVER_Frameset.htm Like selling cheap pringer or mobiles and make the money with ink or the phone tariff. There are sources like http://igs.ifag.de/index_ntrip_cast.htm to get the GNSS data streams over the internet - for free. I'm registrated an can use their casts. The globallocal answers on my questions are diffuse and the information that AGPS is not usable without globallocate server Would be a RTCM 2.3 Typ 17 stream enough for AGPS? If it has a TCP/IP portal on the network side to reach LTO or AGPS servers, and would need a NAL on the handset side to connect to the GPS control stack. NAL= The AGPS features currently only expect a NAL (network abstraction layer) to reach the AGPS servers. Routing to a server Would the binary from gobal locate allows to define an own routings to a server? Right now the NAL is built in and assumes TCP/IP. If you configured the AGPS NAL for a local proxy, then rerouted to whatever you choose, you're all set. free routing possible, but what is the protocoll of the AGPS data that the globallocal chip expect? Would it be possible to run an own server (runnning open software)? You would need to: - develop a SUPL protocol stack SUPL = a protocol from OMA, Open Mobil Alliance - where is it documented? - get an assistance data feed. Network operators pay big $$$ for this from commercial providers. Developing your own is a major task. Just some stations - ntrip_cast for the beginning - get authority from cell providers and network operators for AGPS to go through them GPRS/SSL (Note the own position fix for MS-A above: you could get between an operator and $$, a dangerous place to be!) - develop a database of {cell-tower == lat,long,alt} So it is a pretty big job with some major hurdles. O2 in Germany serves lat,long for free. There is also a chip from atmel ublox with Assist-Now(TM) and AFAIK is their documentation linkt to a Assist-Now(TM)-AGPS server. Maybe I don't know enough, but for me it smells like that globallocal AGPS is only used with AGPS servers - and with the risk that this server knows the location of every globallocal user after connection. I will go on this topic - but I fear that AGPS from globallocal is not open enough to feed my mobil with own data - independend of globallocal server. If this would be true, it would be disapointing. I would like to pay more for a device when AGPS would be independend of third party servers. Without asking globallocal again, do you have some more documentations about SUPL and NAL? Greetings, rob Sean Moss-Pultz schrieb am Sonntag, den 03. Dezember 2006 um 23:13h: Robert- Sorry for the time it took me to get back to you on this one. Hopefully you still remember your original question: Sean I just want you to ask your AGPS experts - when you have to ask externaly e.g. open local - you could wait a day for me doing a bit more research: Would be a RTCM 2.3 Typ 17 stream enough for AGPS? Would the binary from gobal locate allows to define an own routings to a server? Would it be possible to run an own server (runnnig open software)? Here is your answer from a senior engineer at Global Locate: --- There is an open GPS hw/fw solution out there, but it is open only because the fw side of it went belly-up and the hw side decided to keep the silicon in their catalog. But there's few PhDs in signal processing or navigation to support it. PhDs have less time on their hands than GUI developers, evidently. About the questions: What is the context? AGPS protocol stack support on a handheld, or The AGPS server on the network side? I'll assume he's discussing the handset side. First some background. MS-A AGPS server sends minimum ephemeris to handset (age is about 2 hours or less) handset replies with measurements; server computes (and owns) the position Data rates are moderate, but the same for each position MS-B AGPS server sends ephemeris for local conditions (age is about 2 hours) handset computes (and owns) the position data rates are about the same, but can be smaller for subsequent fixes. LTO LTO gets to handset via: - GPRS - WiFi - Bluetooth - USB Only about 40KB needed every 2 days, although we prefer every 6 hours for safety if it is cheap enough. The AGPS features currently only expect a NAL (network abstraction layer) to reach the AGPS servers. For the LTO, same thing. Right now, our only NAL is for TCP/IP, as User-plane (SUPL) for OMA support is easiest. In future, C-Plane may be offered by some GSM BBs and we can use that if the network supports it.
Re: [Neo1973] AGPS - globallocal cuckoo's egg? Re: AGPS server questions
Salve Sean, Oleg, *! Sorry, it was not my intention to then my mail to the list, and probably it has not the right style/sound - I didn't want to write bad about globallocal, I just feared that assisted data for the globallocal AGPS is based on a non open protocoll. Oleg Gusev schrieb am Mittwoch, den 13. Dezember 2006 um 14:54h: Am Mittwoch, 13. Dezember 2006 13:57 schrieb Robert Michel: Maybe I don't know enough, but for me it smells like that globallocal AGPS is only used with AGPS servers - and with the risk that this server knows the location of every globallocal user after connection. It's obvious ;) That I don't know enough, or that globallocal AGPS chips are only talking with globallocal AGPS servers or just proxies, which are talking with globallocal servers? Or both? :) I will go on this topic - but I fear that AGPS from globallocal is not open enough to feed my mobil with own data - independend of globallocal server. The globallocate receiver works without any AGPS. HP ipaq hw6515 and 6915 have it connected over SPI, you can find the details here http://wiki.xda-developers.com/index.php?pagename=SableGPS This is fine, but i would like to run an own AGPS server, connect via SSL to him and use the AGPS power of the chips as well - without running fees beside the GPRS traffic and without leaving information of my localisation on any third party server. Even more, when the assisted data protocoll is open and our test with the Neo1973 shows that it worth to use AGPS, I like to lobby that a MediumWave Digital Radio Mondial station would broadcast LEO or AGPS data. But Sean answered us and I will be polite and patient. I'm conviced that the globallocal chip will be great, but because of this great feature inside the Neo1973, I'm a bit afraid that AGPS has no free protocoll to serve AGPS data ourself. rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Neo1973] AGPS - globallocal cuckoo's egg? Re: AGPS server questions
Salve Gabriel! Gabriel Ambuehl schrieb am Mittwoch, den 13. Dezember 2006 um 14:24h: On Wednesday 13 December 2006 13:57, Robert Michel wrote: I fear AGPS from globallocal is a coockoo's egg - they anounced that their AGPS chips cost only 5 US$ - I fear they will make money with their AGPS server services If the GPS can do indoor GPS without assistance (which is what the site seems to suggest, to me anyway) were are still better off than with a similar GPS only chip that has neither indoor nor AGPS features, right? yes. If it won't do that, the chip is rather useless to me. when it would be not so much data that is transmitted via GPRS, because we select only the needed satellites and use a good compression... I can image enough situation that this GPRS traffic would worth it. There's no way in hell I'm gonna *pay* someone to constantly know where I am ;) - get authority from cell providers and network operators for AGPS to go through them GPRS/SSL Agreed, if you pay for the traffic, they better do not interfere with it. The telcos being common carriers could even get into major trouble for doing that, let's just hope network neutrality is being upheld... Network neutrality is no question for GPRS/SSL. A dream would be, when the network poeretor wouldn't be just neutral, when they serve assited GPS data for free or a fixed price (1-2 Euro/month) When there is an open protocoll for serve assited data http://www.heise.de/newsticker/meldung/59560 It seems that SUPL (Secure User Plane Location) is for this, HP has an own protcoll and did compared both here: http://h71019.www7.hp.com/enterprise/downloads/Article_Dueling_Architectures_UserPlane-ControlPlane.pdf And an idea for an WAP extension: Because some network operators have interesting tariffs with wap flat, it could be work to serve LTO or AGPS data via wap to have fixed costs. rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FCC status for FIC Neo1973?
not to mention completely outside the terms of service of any major carrier...? a while ago, I spoke to both Cingular and T-Mob, I told them I was doing some work with a gm-862, both said there was nothing in their service restrictions about connecting with weird equipment like that --Jeff On 12/13/06, David Schlesinger [EMAIL PROTECTED] wrote: Do you mean legal challenges beyond its use being, strictly speaking, a violation of Federal law, not to mention completely outside the terms of service of any major carrier...? -Original Message- From: [EMAIL PROTECTED] on behalf of La Monte Henry Piggy Yarroll Sent: Wed 12/13/2006 7:37 AM To: community@lists.openmoko.org Subject: FCC status for FIC Neo1973? Would anyone care to comment on the FCC status of the FIC Neo1973? In particular, are there any legal challenges associated with using prototypes on a live GSM network? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko as a slimserver client or remote control
Salve Stefanie! On Wed, 29 Nov 2006, Stefanie Tellex wrote: This requires wireless internet, but it wouldn't be hard to get a slimserver client running on the phone, so you could stream your mp3s to the phone and listen to them. Push a button, and your phone starts streaming music from your server. Slimp3slave is a command line client using the old udp protocol: http://www.ex-parrot.com/~pdw/slimp3slave/. Slimserver has a newer TCP based protocol as well, but there isn't a C client yet. (Slimserver itself is a GPL'd perl program, so a C client for the new protocol isn't hard, it just hasn't been done yet.) Of course it would be possible to run Slimp3slave, but consider that this would only for slimdevice owner http://www.slimdevices.com/ So IMHO it would be more interesting (for more people) to have a free server like icecast and use this to a GUI frontend player And to have the total freedom - the songs could be on PC A, the soundcard on PC B and the Neo1973 would controll to play this songs. Even cooler would be adding a remote control interface to slimserver that runs on the phone. You pull out the phone and start controlling the music coming out of your speakers. We have two slimserver clients in our apartment: it could use GPS to figure out which one is closest, and connect to that one to change the volume, switch songs, or whatever. Yes this would be cool, but until I haven't saw it with my own eyes, I would not expect GPS accuracy 10m indoor. Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Global Locate Ephemeris Data
Would we be violating the license by redistributing this data, or additional data based entirely upon that data source to other Neo1973 units? I'm wondering about the possibility of leveraging off the fact that all Neo1973 units should have a very unified idea of the current time to increase the fix accuracy. For example, if you have three Neo1973s in a rough geographic triangle, such that: Neo 1 - has LOS to satellites a,b,c,d Neo 2 - has LOS to satellites c,d,e,f Neo 3 - has LOS to satellites a,c,d,f Each unit computes a positional fix with 5m accuracy as normal, but all at the same coordinated time. Scaling this up to a downtown city environment, where you could have 100 Neo1973's with a 5 mile radius... if they all took positional fixes at the same time, would it be possible to use all of this coordinated data, plus the ephemeris info, to increase the fix accuracy? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Global Locate Ephemeris Data
Salve Richard! Ahh, it seems that the idea of distributed lightning detection has inspired you for something (maybe) more usefull *g* On Wed, 13 Dec 2006, Richard Franks wrote: Would we be violating the license by redistributing this data, or additional data based entirely upon that data source to other Neo1973 units? AFAIK no. Otherwise NTRIP casts would illegal as well. I'm wondering about the possibility of leveraging off the fact that all Neo1973 units should have a very unified idea of the current time to increase the fix accuracy. For example, if you have three Neo1973s in a rough geographic triangle, such that: Neo 1 - has LOS to satellites a,b,c,d Neo 2 - has LOS to satellites c,d,e,f Neo 3 - has LOS to satellites a,c,d,f Each unit computes a positional fix with 5m accuracy as normal, but all at the same coordinated time. GPS normaly needs the signal from 4 satellites - what about instead of making the accuracy higher, helping neo4 that could receive data from ony 3 satellites? Scaling this up to a downtown city environment, where you could have 100 Neo1973's with a 5 mile radius... if they all took positional fixes at the same time, would it be possible to use all of this coordinated data, plus the ephemeris info, to increase the fix accuracy? - Nice idea, but how to feed the GPS chip whith this? (Close Chip, close binary in user mode) - How to avoid that other users could track you? - and with 100 receivers there would be a need for a smart distributed calculating... - traffic? 4x100x50 bit/s? 20kbit/s realy so few? To have exact time stamps and sender id there must be a big overhead? I'm not so conviced that such a brute force with 100 receivers would help with errores due e.g. Ionosphere because non of this recievers is a fixed/stationary one and a fixed public receiver in the city with receiving a,b,c,d,e,f would help more. But shure, there should be a way that a local receiver network would be usefull. At last to have one Neo in the car and getting the needed assited data inside a building from this directly (Wi-Fi, PMR). So a little more information about AGPS but also about the globallocal chip, which data could be acessed would help... Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Admin tools like screen
ke, 2006-12-13 kello 16:59 +0100, Robert Michel kirjoitti: When you use screen on your mobile you need to have multiple SSH connections to your server - everytime you open a new terminal you need a new login - key based login would help, but would not be so secure SSH has the ability to multiplex several terminal connections (among others) over a single TCP link. Thus you only have to authenticate once. See OpenSSH's -S option. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: yet another fantasy idea: nextel-like walkie talkie feature?
ke, 2006-12-13 kello 10:26 -0800, [EMAIL PROTECTED] kirjoitti: I suppose everyone is familiar with the Nextel feature that behaves a bit like a walkie-talkie. In summary, you can contact anyone within certian groups in a half-duplex (meaning only one talks at a time) push-to-talk like environment. There's an S60 program and associated service that's in relatively wide use; see eg. http://www.symbianone.com/content/view/1094/108/ But given the data network, and our own community of brilliant and motivated developers, would it be possible to implement something like this? But of course. The real question is, can we interoperate with Nokia's offering, which would be nice. They apparently license the technology to operators and they might be rather jealous of it. You know Nokia's love-hate-relationship with openness... Of course, even without interoperability with an installed base this is a good idea. May often be cheaper and more practical than calling. Off the top of my head, one way to do this might be: Implement a server to keep track of phones using this service and their IP address. Phones check in with the server when their IP address changes. Then when someone wants to talk to someone else, they select the recipient and press talk. Code on the phone connects to the server, gets the IP address of the recipient, opens a data connection to the recipient (either directly or through some proxy if necesary), and establishes the appropriate half-duplex voip connection. That's pretty much it, except voip may be overstating it a bit; I associate voip with real-time voice communications; as said, this is more a voice message, and as such should be treated as a file. (Perhaps one could transfer the files using HTTP, though the signaling might be a bit kludgish; ah well.) Also, one should facilitate the transfer of arbitrary other files in this way as well (including, ta-dah, text messages, since SMS are generally ridiculously priced). Also, a client should be able to set a size limit on incoming data thinking of non-flat GPRS fees. Perchance even have the option to store the bigger files/messages on the server to be downloaded on demand. And then there's the option of encrypting the files with gnupg while in transit... Oh, and we reprogram the cool audio chip to reduce sound quality and thus bitrate to save bandwidth and decrease delays. Rather use a generic low-bandwidth codec on the host CPU; Speex is free and can go down to a mere 2kbps while giving the option of higher bandwidths for higher quality when that is called for. (Or, if interoperability with Nokia's thingy is an option, whatever they use...) For latency, start transmitting the codec's output as soon as any is available. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: yet another fantasy idea: nextel-like walkie talkie feature?
ke, 2006-12-13 kello 20:16 +, Ole Tange kirjoitti: I am wondering why you want push-to-talk when you can have VoIP using SIP or just a normal GSM conversation? Can you elaborate on why? Full-fledged VOIP over GPRS is iffy due to quality of service issues that don't hamper the playback of simple voice messages but merely affect the time to get the message through. Also, the unobtrusive nature of such a message (think a voice SMS) may be desirable sometimes (yes, there are answering services; still better to have a separate class of voice messages for not-so-instant communication). And then there's the pricing, which would often (though not always) favor well-compressed voice messages via GPRS over a regular phone call (even more so with text messages which could be sent over the same infrastructure). I get that flat-rate GPRS is a rare beast, but here where we have reasonably priced deals, this kind of thing would be especially useful. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FCC status for FIC Neo1973?
Jeremy wrote: I'm no expert at all, but I do know that when we were designing a device with a Kyocera m200 CDMA data module (http://www.kyocera-wireless.com/m2m-business/index.htm), the module itself was carrier (Sprint in our case) approved and FCC approved, but once we incorporated it into our device, we then had to get it re-approved by the carrier and the FCC (though it is typically an easier process when using an approved module already). I think the deciding factor may be whether the module is stand-alone or not... But I say that with the disclaimer that I could be completely wrong. :) My experience so far putting modules for both GSM and CDMA into another product has been similar - even though the module itself is 'approved' the actual application to which it is put must also be run through an evaluation process. As far as carriers in the US, I know Cingular is good for GSM. Not sure who else? Are approval issues going to be a problem for the Neo1973 in the States? (Am looking forward to getting one, and not being able to use it as a phone would be a serious damper.. ;-) -P ~Jeremy - Original Message From: Graham Auld [EMAIL PROTECTED] To: community@lists.openmoko.org Sent: Wednesday, December 13, 2006 2:06:45 PM Subject: FCC status for FIC Neo1973? I wouldn't expect such an issue as i expect the GSM module will be correctly certified and as access is via AT command set you /shouldn't/ be able to make it do things it's not allowed to... someone please correct me if i'm incorrect in my assumptions Graham *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Jeff Andros *Sent:* 13 December 2006 16:17 *To:* David Schlesinger *Cc:* community@lists.openmoko.org; La Monte Henry Piggy Yarroll *Subject:* Re: FCC status for FIC Neo1973? not to mention completely outside the terms of service of any major carrier...? a while ago, I spoke to both Cingular and T-Mob, I told them I was doing some work with a gm-862, both said there was nothing in their service restrictions about connecting with weird equipment like that --Jeff On 12/13/06, *David Schlesinger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Do you mean legal challenges beyond its use being, strictly speaking, a violation of Federal law, not to mention completely outside the terms of service of any major carrier...? -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] on behalf of La Monte Henry Piggy Yarroll Sent: Wed 12/13/2006 7:37 AM To: community@lists.openmoko.org mailto:community@lists.openmoko.org Subject: FCC status for FIC Neo1973? Would anyone care to comment on the FCC status of the FIC Neo1973? In particular, are there any legal challenges associated with using prototypes on a live GSM network? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FCC status for FIC Neo1973?
Tim Newsom wrote: Once its FCC certified, why would it matter? It should be just like getting any phone from any vendor and putting your SIM in to get service. Heh, I can dream it would be that easy.. ;-) For the devices I've been working with the last couple of years (stationary, constant GPRS connection) the FCC approval is necessary to _start_ the other approvals the vendors want before allowing a device on their network. Am personally not sure if it's real 'certification' or an excuse to extract $$$ out of companies. Don't know if it's the same for 'consumer' devices or not. -P You may have a hard time getting support for configurations because the vendor won't know how to do things with the neo1973, but they can push the configuration to the phone with an sms message and most modules I have seen support using that for configuration. I would be surprised if the one in the neo1973 does not... Sean or anyone who knows... Is configuration by sms possible with this phone? Can we override it with a gui? Or ony by the gui maybe? --Tim On Wed, 13 Dec 2006 17:19, Paul Bohme wrote: Jeremy wrote: I'm no expert at all, but I do know that when we were designing a device with a Kyocera m200 CDMA data module (http://www.kyocera-wireless.com/m2m-business/index.htm), the module itself was carrier (Sprint in our case) approved and FCC approved, but once we incorporated it into our device, we then had to get it re-approved by the carrier and the FCC (though it is typically an easier process when using an approved module already). I think the deciding factor may be whether the module is stand-alone or not... But I say that with the disclaimer that I could be completely wrong. :) My experience so far putting modules for both GSM and CDMA into another product has been similar - even though the module itself is 'approved' the actual application to which it is put must also be run through an evaluation process. As far as carriers in the US, I know Cingular is good for GSM. Not sure who else? Are approval issues going to be a problem for the Neo1973 in the States? (Am looking forward to getting one, and not being able to use it as a phone would be a serious damper.. ;-) -P ~Jeremy - Original Message From: Graham Auld [EMAIL PROTECTED] To: community@lists.openmoko.org Sent: Wednesday, December 13, 2006 2:06:45 PM Subject: FCC status for FIC Neo1973? I wouldn't expect such an issue as i expect the GSM module will be correctly certified and as access is via AT command set you /shouldn't/ be able to make it do things it's not allowed to... someone please correct me if i'm incorrect in my assumptions Graham From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Andros Sent: 13 December 2006 16:17 To: David Schlesinger Cc: community@lists.openmoko.org; La Monte Henry Piggy Yarroll Subject: Re: FCC status for FIC Neo1973? not to mention completely outside the terms of service of any major carrier...? a while ago, I spoke to both Cingular and T-Mob, I told them I was doing some work with a gm-862, both said there was nothing in their service restrictions about connecting with weird equipment like that --Jeff On 12/13/06, David Schlesinger [EMAIL PROTECTED] wrote: Do you mean legal challenges beyond its use being, strictly speaking, a violation of Federal law, not to mention completely outside the terms of service of any major carrier...? -Original Message- From: [EMAIL PROTECTED] on behalf of La Monte Henry Piggy Yarroll Sent: Wed 12/13/2006 7:37 AM To: community@lists.openmoko.org Subject: FCC status for FIC Neo1973? Would anyone care to comment on the FCC status of the FIC Neo1973? In particular, are there any legal challenges associated with using prototypes on a live GSM network? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community