Some months ago I bought a PDA, it was an special offer and also got a
Bluetooth GPS reciever (Royaltek RBT-1000). It works fine with my PDA. This
weekend I decided to try to make it work with my laptop (Ubuntu Breezy).
Read some stuff on internet and it looked very easy to config. Been trying
different things for 3 hours and can't make it work properly. Lets go:
root@pluto:~# uname -a
Linux pluto 2.6.12-9-386 #1 Sat Oct 15 13:14:36 BST 2005 i686 GNU/Linux
root@pluto:~# hciconfig
hci0: Type: USB
BD Address: 00:10:60:A3:72:8E ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING
RX bytes:126 acl:0 sco:0 events:17 errors:0
TX bytes:318 acl:0 sco:0 commands:15 errors:0
root@pluto:~# hcitool scan
Scanning ...
00:02:C7:29:23:4F BlueGPS 29234F
root@pluto:~# sdptool browse
Inquiring ...
Browsing 00:02:C7:29:23:4F ...
root@pluto:~# sdptool search SP
Inquiring ...
Searching for SP on 00:02:C7:29:23:4F ...
Service Name: Serial Port
Service RecHandle: 0x10000
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
root@pluto:~# rfcomm bind /dev/rfcomm0 00:02:C7:29:23:4F 1
root@pluto:~# rfcomm
rfcomm0: 00:02:C7:29:23:4F channel 1 clean
root@pluto:~#cat < /dev/rfcomm0
Qú°³ ¢ŒAEê
Æ°³ ¢4°³ ¢
2D°³ ¢
Qú°³ ¢ŒAFN
Æ°³ ¢4°³ ¢
2D°³ ¢
QúV°³ ¢ŒAF²
Æ°³ ¢4°³ ¢
2D°³ ¢
Qú°³ ¢ŒAG
root@pluto:~# rfcomm
rfcomm0: 00:02:C7:29:23:4F channel 1 closed
As you see everything is OK, but I got "weird data" from the GPS reciever.
While testing I made it work properly form some minutes .... As I've been
trying with my PDA, I think that some times that it worked in the right way
it had been before linked to the PDA without switching off the GPS. But I'm
not sure about it.
Any idea where is the problem?
Thanks in advance,
acidbits
Finally I got everything clear, know how to make it work in the proper
way. Sure someone else will be stucked on this, I've spend some hours
on it.
Royaltek RBT-1000 has two operational modes, SiRF and NMEA. By default
it starts in SiRF mode. I read some documentation and I know how to
switch from SiRF to NMEA mode. There are 2 issues with this Bluetooth
GPS reciever and gpsd:
1. First time gpsd starts to request data to RBT-1000, gpsd forces it
to SiRF mode.
2. In SiRF mode there's some kind of issue between gpsd and RBT-1000,
that leads to have a lot of timeouts reading the data. This produces
timeouts in the applications that make requests to gpsd, and they
don't work properly.
I've been doing lots of tests and finally I found a trick to force
gpsd to get data from RBT-1000 in NMEA mode. Here we go:
Set up rfcomm & gpsd:
acid@pluto:~# hcitool scan
Scanning ...
00:02:C7:29:23:4F BlueGPS 29234F
acid@pluto:~# sudo rfcomm bind /dev/rfcomm0 00:02:C7:29:23:4F 1
acid@pluto:~# gpsd /dev/rfcomm0
Right now we have SiRF mode. Switching now to NMEA is useless,
although gpsd is running it won't connect with the GPS device (and
force SiRF mode) till some client request data to gpsd. There are
several ways to make it: "telnet localhost 2947" and type DATA, or=20
launching a simple app like xgps:
acid@pluto:~# xgps
Once gpsd has established the first connection with RBT-1000 and
forced it to be in SiRF mode comes the magic. First we have to close
the client app that we used to request data to gpsd thus making it to
establish the connection with RBT-1000. And now we send the magic
string to switch RBT-1000 to NMEA mode:
acid@pluto:~# echo -e -n
"\240\242\000\030\201\002\001\001\000\001\005\001\005\001\000\001\000\001\0=
00\001\000\001\000\001\000\001\022\300\001\152\260\263"
> /dev/rfcomm0
If you "cat < /dev/rfcomm0" you'll get those nice NMEA strings, no
binary chars anymore. Gpsd recognizes the new mode but doesn't switch
back to SiRF, it reads data in NMEA mode from RBT-1000. Now you can
launch any gpsd based app again (xgps, gpsdrive, kismet, ...) and no
more timeouts!! That's it!
It looks like in SiRF mode RBT-1000 can't answer the requests from
gpsd as fast as they are performed and this produces those timeouts.
Switching to NMEA mode using this trick is a workaround, it would be
better if gpsd had some option to force the GPS reciever to operate in
NMEA mode if availible.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
How many types of bluetooth doggles are out there? is there a way to
actually automaticaly probe what type each one is? I suppose doing that
would mean USB/HAL hacking other than Bluetooth hacking?
-- charles
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On 10/15/05, Michael Mauch <[email protected]> wrote:
>
> I wrote:
>
> > (or google for NMEA-0182).
>
> Oops, that should have been NMEA-0183 or NMEA0183 or "NMEA 0183".
>
> http://faq.royaltek.com/phpBB2/viewtopic.php?p=25 suggests that you
> should send "$PSRF 100".
>
Finally I made it work ... well it was already working ... :-) Thanks to
your SiRF clue!
I wanted GPSD (gpsd.berlios.de <http://gpsd.berlios.de>) to read data from
my GPS reciever, and I found that it also process SiRF data. No need to
switch the GPS to NMEA mode. I was stuck in the point that I couldn't read
NMEA data from /dev/rfcomm0, and thought that gpsd would have the same
problem.
Anyway, it is possible to switch back to NMEA sending a SiRF command, it is
a binary string. If someone is interested google says there was a pdf manual
in royaltek , not availible by now, but you can look at Google PDF->HTML
cache:
http://64.233.161.104/search?q=cache:W2SCQz2NLwkJ:www.royaltek.com/Manuals/software%2520interface%25201.1(SIRF).pdf+sirf+command+nmea+mode+switch&hl=en&client=firefox
I wasn't able to switch it to NMEA sending this binary string through "cat
go2NMEAmode.dat > /dev/rfcomm0"
go2NMEAmode.dat 64 bytes long (Hex value):
A0 A2 00 18 81 02 01 01 00 01 05 01 05 01 00 01 00 01 00 01 00 01 00 01 00
01 1 2 C0 01 6A B0 B3
Thanks!
I wrote:
> (or google for NMEA-0182).
Oops, that should have been NMEA-0183 or NMEA0183 or "NMEA 0183".
http://faq.royaltek.com/phpBB2/viewtopic.php?p=25 suggests that you
should send "$PSRF 100".
Regards...
Michael
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
aCiDBiTS wrote:
> root@pluto:~#cat < /dev/rfcomm0
> Q=FA=06=AD=B0=B3 =A2=BCAE=EA
[...]
> As you see everything is OK, but I got "weird data" from the GPS reciever.
> While testing I made it work properly form some minutes .... As I've been
> trying with my PDA, I think that some times that it worked in the right w=
ay
> it had been before linked to the PDA without switching off the GPS. But I=
'm
> not sure about it.
>=20
> Any idea where is the problem?
<http://www.worldofppc.com/HWTests/rbt1000.htm> indicates that this GPS
has two modes: NMEA and SIRF. If you have this BlueGPS1000 software or
something similar, try setting it to NMEA. Apparently there is a SIRF
binary mode, so that seems to be the data that you get by default.
I have no idea how you can enable the NMEA mode "manually" - perhaps
it's enough to send a standard NMEA string. You can echo the strings
into your /dev/rfcomm0 (while you have cat running in another console),
e.g.
echo -e '$PSRF103,04,00,01,01*21\r\n' >/dev/rfcomm0
That's the "Recommended Minimum Navigation Data", see e.g.
http://www.martin-dehler.de/gps/navigate.htm (or google for NMEA-0182).
Regards...
Michael
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users