Reply
Thread Tools
Posts: 124 | Thanked: 213 times | Joined on Dec 2009
#1
Hopefully this is a quick question & answer :


Which /dev device is the internal GPS?

I assumed it would be /dev/ttyS0 (as they often are, if they're not USB) ....not so.
 
Posts: 46 | Thanked: 16 times | Joined on Jan 2008 @ Edmonton, AB, Canada
#2
I think that the idea in Fremantle is to use liblocation for GPS access, and not accessing the GPS directly. I haven't looked at it in detail, yet, but there is information online.

I know it is a kind of no-answer, but I hope that helps a bit!
 

The Following User Says Thank You to pablob For This Useful Post:
Posts: 124 | Thanked: 213 times | Joined on Dec 2009
#3
I appreciate the response

I know about liblocation, but I do have a need to get at the device directly. I'm not merely using the provided APIs, I'm doing something new.

There must be a device at some point for liblocation to access....so which one is it?
 
Posts: 119 | Thanked: 110 times | Joined on Sep 2009 @ Prague
#4
i'm not sure that information alone would be of any use, even if we knew it (I tried to discover for a hour or so, but failed... ) - first you have to power up the device anyway (how?), and after that you have to know the used protocol (which may be quite different from NMEA/sirf...).
 

The Following User Says Thank You to andree For This Useful Post:
Posts: 124 | Thanked: 213 times | Joined on Dec 2009
#5
Protocol discovery is not an issue - reading raw data from the device will enable me to discover the protocol of the gps hardware....heck, if we know the actual chipset we can go straight to the hardware tech specs

Waiting for the device to be enabled is not an issue either - if it's not there, it's not there

If I can use:

stty -F /dev/gpsdevice

...I can get to work on my project
 
Posts: 1,224 | Thanked: 1,763 times | Joined on Jul 2007
#6
The actual access to the GPS hardware is probably done by /usr/libexec/location-daemon. Unfortunately this file does not open any files in /dev.

My guess is that communication with GPS hardware is done over phonet0 network. I do see a lot more action there (use tcpdump -i phonet0) when GPS is in use, but it possible that this data is used merely for GSM cell based location.

As for the data format - it seems that location-daemon is using liblas.
 

The Following 2 Users Say Thank You to Matan For This Useful Post:
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#7
Even if you find device. If you open and read information from it,you would block other applications using it. Would it be desirable behavour for users?
 
Posts: 124 | Thanked: 213 times | Joined on Dec 2009
#8
I have no SIM card in my N900, therefore no cellular activity can be taking place. I assume that the activity we see on phonet0 is GPS data
 
Posts: 124 | Thanked: 213 times | Joined on Dec 2009
#9
Further digging reveals that the driver for the GPS hardware has been written so that it presents itself as a network interface (phonet0) rather than a block device.

Given that all GPS hardware I have ever seen is accessed via a serial or usb device, does anyone know why this architectural decision was made?

Can any Nokia techs tell me if it is possible for me to write a block device driver for the GPS hardware? I'd like to present it as /dev/gps for ease of use....
 
Posts: 119 | Thanked: 110 times | Joined on Sep 2009 @ Prague
#10
and further digging shows usage of SSI McSAAB (ssi_mcsaab_imp, http://en.wikipedia.org/wiki/Simple_...rface_protocol ), which I'd guess is where you can find gps sitting.... and there's also a phonet pipe protocol end point socket (pn_pep) used with phonet interface...
 

The Following User Says Thank You to andree For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 10:41.