On 31 January 2011 22:03, Al Johnson <[email protected]> wrote: > On Monday 31 January 2011, Neil Jerram wrote: >> Joachim Ott <[email protected]> writes: >> > That version is running so far, after starting bluetoothd and >> > simple-agent.py. >> >> I tried bt-gps (from the feeds) a while ago before writing my last email >> on this. But at that time I hadn't understood the point about needing >> to start bluetoothd by hand first. > > I'd forgotten that bug was outstanding. Bluez expects bluetoothd to be started > by udev, but SHR no longer has it. I guess we still don't have an alternative. > >> Now that I know that, bt-gps runs without error, and emits some >> reasonable looking traces, and the N800 successfully pairs. But there's >> still no GPS-level connection. >> >> Here's the FR transcript: >> >> ============= >> root@om-gta02 ~ # bluetoothd >> root@om-gta02 ~ # BtGPS.py >> Checking 0a12 0001 >> Found >> Bus 001 Device 001: ID 1d6b:0001 >> Bus 001 Device 003: ID 0a12:0001 >> 0 >> Props dbus.Dictionary({dbus.String(u'Name'): dbus.String(u'om-gta02-0', >> variant_level=1), dbus.String(u'Powered'): dbus.Boolean(True, >> variant_level=1), dbus.String(u'Devices'): >> dbus.Array([dbus.ObjectPath('/org/bluez/343/hci0/dev_00_19_4F_A4_B8_06')], >> signature=dbus.Signature('o'), variant_level=1), >> dbus.String(u'DiscoverableTimeout'): dbus.UInt32(0L, variant_level=1), >> dbus.String(u'PairableTimeout'): dbus.UInt32(0L, variant_level=1), >> dbus.String(u'Discoverable'): dbus.Boolean(True, variant_level=1), >> dbus.String(u'Address'): dbus.String(u'00:06:6E:17:45:7F', >> variant_level=1), dbus.String(u'Discovering'): dbus.Boolean(False, >> variant_level=1), dbus.String(u'Pairable'): dbus.Boolean(True, >> variant_level=1), dbus.String(u'Class'): dbus.UInt32(4849920L, >> variant_level=1)}, signature=dbus.Signature('sv')) Checking 0a12 0001 >> Found >> Bus 001 Device 001: ID 1d6b:0001 >> Bus 001 Device 003: ID 0a12:0001 >> 0 >> ^Z[1]+ Stopped BtGPS.py >> root@om-gta02 ~ # bg >> [1] BtGPS.py >> root@om-gta02 ~ # simple-agent >> Agent registered >> RequestPinCode (/org/bluez/343/hci0/dev_00_19_4F_A4_B8_06) >> Enter PIN Code: 6805 >> ============= >> >> >, I could connect from a SE C905. It claims to see just >> > >> > these services: >> > >> > Audio remote control >> > Audio remote control target >> >> Interesting. I guess that could be either FR not advertising the right >> service, or the SE C905 not seeing it. But BtGPS.py does include >> "sdptool add SP" - which I'm guessing is the GPS service advertisement. > > Yes - that should make it advertise a serial port, and you should be able to > see that from the client. > >> I'm wondering if the problem is the detail of the GPS protocol. I think >> I recall people saying that the protocol available from fso-gpsd is not >> quite the same as that from gpsd, and that the gpsd version is the right >> one. >> >> Am I correct in thinking that gpspipe takes its input from the >> (fso-)gpsd pipe? (Or does it read /dev/ttySAC1 directly?) > > gpspipe connects to gpsd and spits out either native gpsd or NMEA data, > depending on the arguments. > >> Also I see that gpspipe has several format options: >> >> ============= >> root@om-gta02 ~ # gpspipe -h >> Usage: gpspipe [OPTIONS] [server[:port[:device]]] >> >> -d Run as a daemon. >> -f [file] Write output to file. >> -h Show this help. >> -r Dump raw NMEA. >> -R Dump super-raw mode (GPS binary). >> -w Dump gpsd native data. >> -l Sleep for ten seconds before connecting to gpsd. >> -t Time stamp the data. >> -T [format] set the timestamp format (strftime(3)-like; implies '-t') >> -s [serial dev] emulate a 4800bps NMEA GPS on serial port (use with '-r'). >> -n [count] exit after count packets. >> -v Print a little spinner. >> -V Print version and exit. >> >> You must specify one, or both, of -r/-w. >> You must use -f if you use -d. >> ============= >> >> Is "-r" definitely the right one to use? "gpspipe -r" gives me: > > It ought to be - you want to output NMEA data on the bluetooth serial port so > I think it should be "-r -s [whatever the bluetooth serial port's called]" > >> ============= >> root@om-gta02 ~ # gpspipe -r >> netlib_connectsock() returns socket on fd 3 >> GPSD,W=1,A=42.875,T=169.7809,C=1.00,E=5.22 3.12 4.18,N=0,A=42.875,B=?,L=3 >> 0.8 abcdefgijklmnopqrstuvwxyz,E=5.22 3.12 >> 4.18,T=169.7809,R=1,U=0.000,E=5.22 3.12 4.18,N=0,M=3,E=5.22 3.12 >> 4.18,A=42.875,T=169.7809,R=0,U=0.000,E=5.22 3.12 4.18 GPSD,O=- >> 1296502099.000 ? 51.530356 -0.115981 42.89 3.12 4.18 169.7809 0.590 0.000 >> ? ? ? 3 GPSD,O=- 1296502099.000 ? 51.530356 -0.115981 42.89 3.12 4.18 >> 177.3715 0.550 0.000 ? ? ? 3 GPSD,O=- 1296502100.000 ? 51.530356 -0.115981 >> 42.89 3.12 4.18 177.3715 0.550 0.000 ? ? ? 3 GPSD,Y=- 1296502100.000 11:28 >> 45 121 0 0:15 29 287 0 0:26 71 299 24 1:5 54 194 27 1:7 22 59 29 1:8 56 60 >> 27 1:21 17 307 0 0:10 16 159 0 0:19 5 37 0 0:3 1 9 0 0:27 18 237 19 1: >> ============= > > Hmm...that's not NMEA, so if that's what's appearing on the bluetooth serial > port it's not surprising things don't work with it. I'm guessing it's native > gpsd but I'm not familiar with it so it might not be. If other apps (tangogps, > navit and so on) are working then it suggests there's a problem with gpspipe. > > Can you try connecting to this serial port from the client and see what data's > appearing on it? That would narrow the problem down to the data format rather > than the serial connection itself.
That format is called TPV stream (http://gpsd.berlios.de/protocol-evolution.html and http://esr.ibiblio.org/?p=801). When I had bt-gps running, the commandline looked like this: rfcomm -r watch 0 1 sh -c gpspipe -r >/dev/rfcomm0 Looks like the fso-gpsd doesn't output nmea records anymore. Can the N800 switch between different formats? _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
