http://maemo.org/community/brainstorm/view/share_gps
I put up an idea to export or share the GPS device or its data stream. AFAIK some gps enabled phones are capable of serving as a BT-GPS-Mouse, wouldnt it be nice to have it USB and BT ready. Adding an option to the ACK screen when plugging into USB to serve as GPS-Mouse and adding GPS-Mouse as BT service would be my choice. Some kind of WiFi-share (GPSoIP or simple output to a stream like port-based thing) would be an idea to look at too.

Should not be too difficult. What you do is export the GPS over Bluetooth SPP, which the GPSD supports.

What you do is reverse of: http://gpsd.berlios.de/bt.html

Which is explained here for N810: http://talk.maemo.org/showthread.php?p=311896

Sharing on WiFi is easy as well. That could work via SSH port forwarding, or by letting GPSd listen on 0.0.0.0, or something like that.

I think I could figure out how to do that but avarage joe should not have to think about that only once, if there would be a button to "share via BT" or something alike it would be useful for average joe. for example its a thing of 2 min to get a BT device into pan with my computer on linux to share its internet connection: install dhcpd configure it and make it start automagical with a BT-PAN as it isnt needed else, do some iptables editing and you are done.
average joe using a gui networkmanager which I dont, he knows how to interact with his gui tool..(I dont) needs 30 sec to change all his connection details which I do in about the same time on the shell (I love TAB completion) and now think of average microsoft joe... he doesnt even know what modprobe or lsmod is! from my own exp. with starting working on in and with linux I know that some howtos are missing basics you need to know. (dont read through what your link reads) average joe needs a helping hand or a button and most of the time he doesnt want a helping hand but a button

Why BT PAN. Why not BT SPP. Or WiFi. Or GPRS. Or TCP over USB. Here lies a problem. That, and BT PAN is not enabled by default.

I find BT PAN a rather strange solution btw. BT SPP is much easier to set up, and more widely supported. See, if it speaks TCP/IP, its easy to set up with GPSD, but GPSD can also talk to a device like rfcomm0.

On S60 I've used a Java ME program called ExtGPS for this purpose. Very simple. I can't imagine its too complex. But one should put it off after using to save battery juice.

oh I am sorry! this was just an example to show the problem of average joe in case of BT by hand on linux. (as I said: for example)

how it will be done depends on how the recipients manage an external BT GPS device (its serial port afaik), but as you see in the n810 post its a problem to keep the gps active without a program running up front.

maybe it should show up at a scan as GPS device with applied service name too.

dont know how that would work for windows if you stream via tcp or udp ports with a gpsserver, as I dont know any freeware to connect to a gps server for windows (I still think of average joe who has no idea of other streams than webradio)

By default, GPSD listens on 127.0.0.1:2947

If it shows up at a scan that means 1) N900 Bluetooth is on 2) N900 GPS is on 3) N900 GPS is using Bluetooth SPP. Well, at least, I assume so, because exporting over Bluetooth SPP is just the most common way, you know.

But your (I assume its yours?) Brainstorm entry is very basic. Look, what you want can be done by command line already (although I cannot write a howto right now because not have device yet). Your idea doesn't mention GUI.

So I think you should make more clear the problem (that it is not easy to share the GPS) and that you want to provide this in an easy manner and decide which protocol to export it over.

Because right now this is not clear.

So what could be done is:

1) simply let GPSD listen on 0.0.0.0 this means it will work on all ppp0 (GPRS), wlan0 (WiFi), pan0 (Bluetooth PAN), usb0 (IP over USB) while user may only use one of these or not like to share data with 'everyone'. Now, A) everyone is a relative term though given GPRS is usually NATed and WiFi may have authentication or not possible for clients to communicate w/each other and PAN also has authentication and well USB requires physical cable. B) we could allow user to specify which devices GPSD should listen to C) we could use IPT to forward connections to 127.0.0.1:2947
2) provide only over Bluetooth hence means some authentication takes place. So, only Bluetooth over SPP. I don't see any use-case where Bluetooth PAN would be preferred over Bluetooth SPP maybe you can convince me *wink*.
3) We decide what is the best solution of these and implement it in a GUI, or we let users vote for the best solution. The question is where this GUI is located or activated, and if this part of Maemo is open source. But I also question if its really up to a vote on Brainstorm at all. Its a cool feature, but not a 'commonly used one', like timsamoff states. The possibilities are endless though, but rather for 'power users', so one could say its not very important a good GUI exists.
4) In that sense maybe we could outline some use-cases from several angles (very_useful_ones, cool_ones_making_jaw_drop). Here some I can think of:

• Run together with OBD-2 analyzer on laptop or Carputer.
• Run navigation software on iPod touch (with gpsserial or RoqyGPS, allowing more navigation software than available for Maemo.
• Run navigation software on S60 phone without GPS, allowing more navigation software than available for Maemo.
• Be kind and provide GPS for third parties in the train or restaurant (LOL).

sorry again I changed the question in brainstorm and my solution

I also think there is no need for a whole setup GUI, just two functional buttons, one at the USB ack screen and one in the GPS settings or BT settings to share via BT... well and a button to stop sharing

Thanks. A checkbox would do it, I guess.

Here suggestion for implementation:

# On GPS device running Linux. 2 examples using BlueZ. Configation file /etc/bluetooth/rfcomm.conf examples use rfcomm4, channel 4 to avoid interference with existing rfcomm configuration.

# Example 1. Requires client with GPS daemon.

rfcomm4 {
listen rfcomm4 4 screen /dev/gps 112500
channel 4;
comment "External GPS";
}

# Example 2. Does not require GPS daemon; raw GPS data.

rfcomm4 {
listen rfcomm4 4 gpsd -n /dev/gps
channel 4;
comment "External GPS";
}

The client either:

1) runs GPSD with source rfcomm4 channel 4. Example: http://www.justuber.com/blog/2007/10...-ubuntu-gutsy/
2) configure rfcomm4 channel 4, tell GPS client to use /dev/rfcomm4 as GPS input data instead of default (probably /dev/gps or 127.0.0.1:2947)

Please people please make this if you can.. if it takes too long if possible please please provide atleast "noob-friendly" directions INSTEAD of a gui please but work on it

Isn't the GPS device locked down and only available through the Location API? Thus rendering it useless for anything that expects NMEA.