GPS on the Neo 1973
m (Manually using GPS moved to GPS on the Neo 1973: THe page name did not make any sense and info is only for the Neo 1973)
m (Category: Application Developer)
|Line 92:||Line 92:|
Revision as of 22:58, 15 September 2008
The Neo1973 device contains an integrated GPS. The particular device is marketed as an AGPS, and there is some discussion available as to what significance that "A" might have.
There is an ongoing effort to write a Free Software program that could be used instead of this binary-only program. See Hammerhead/Protocol for details and the latest status.
Quick test (driver output to console) on Neo1973 Phase 1
Main article: Getting GPS console output with gllin
To get the output of this driver, read the file /tmp/nmeaNP (it is actually a pipe, not a file). The simplest way is to open another ssh connection to the phone and use cat:
This way it is possible to see the first results very easily.
The "GPS Sight" program with graphic interface
Main article: GPS Sight
There is also a working open source GPS preview program to get the gllin output to the graphical environment. It can immediately show the location, altitude, speed and curved distance from selected point. This program can also draw the covered path (no background map).
The old program in /home/root/DM2/gps
Main article - Phase 1 GPS driver
In the very early shipment to 50 Phase 1 developers, a binary-only program for talking to the the GPS was accidentally included in /home/root/DM2/gps, (and presumably, the same binary would function on a P0 device). It was compiled to OABI format which now is obsolete as OM2007.2 builds are in EABI format, but developers suggested tricks to run it with chroot. These approaches seem now obsolete and the old binary seems even no longer easily available.
He also succeeded at getting the Neo1973 to act like a bluetooth GPS with the following script: (Note that this script has bad problems if you run it more than once. You can get a "time traveling GPS" effect, with the GPS showing you your past position).
#!/bin/sh killall rfcomm tail mknod /dev/rfcomm0 c 216 0 echo 1 > /sys/devices/platform/s3c2410-i2c/i2c-0/0-0008/gta01-pm-bt.0/power_on sleep 1 hciconfig hci0 up name linuxgps sleep 1 sdpd sleep 1 sdptool add SP ( while true; do rfcomm listen /dev/rfcomm0 1 sleep 1 done ) & ( while true; do tail -f /tmp/gps.nmea > /dev/rfcomm0 echo 1 > /sys/class/leds/gta01\:vibrator/brightness sleep 1 echo 0 > /sys/class/leds/gta01\:vibrator/brightness done ) &
gllin sends a udp packet per nmea sentence on port 6000. this is a much cleaner aproach because using files will fill up memory or rootfs (the latter will result in the need for reflashing).
i switch off writing to /tmp/nmeaNP and logging to log/... with
the help says that -nmea is the default, fact is that gllin logs nmea sentences into ./log/<date> wich will fill up mem or rootfs for long running tests. the following python script reads the nmea sentences (you need to have python-io installed to get the socket module):
#!/usr/bin/python import sys import socket s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind(('127.0.0.1', 6000)) while True: line = s.recv(1024) sys.stdout.write(line) sys.stdout.flush()
the program just prints those to stdout but other methods are possible (i feed them into a NMEA parser).
benefits are that both programs can be started and stopped at will. none needs the other. gllin will not terminate if /tmp/nmeaNP is not there or not read from. the `cat /tmp/nmeaNP | gzip > gps.gz` is a useless idea anyway because the files in log/ (current directory) contains the NMEA data already.
The ouput from the binary driver seems to follow the NMEA standard.