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.
> Regards, and many thanks for the help so far!
>
> Neil
_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user
