Got Earthmate USB GPS, now what?
Got Earthmate USB GPS, now what?
May 7 2004, 05:37 PM
Joined: 18-March 04
Member No.: 2,388
I took the plunge and got the Delorme Earthmate USB GPS.
The 6000 recognize it right away as "Delorme USB Earthmate". dmesg says something about
USB HID v1.00 Pointer [Delorme Publishing Delorme Earthmate] on usb 1.27.0
Now what do I do? I installed qpegps but the defualt path is
-p /dev/ttyS0 -s -4800
Is that for connection through serial cale? What should I change it to?
One good thing about the setup is that the Z can power the GPS all by itself. The bad is that if qpegps is run in 640x480 mode, it looks skewed.
Please help me set this up.
May 9 2005, 02:45 PM
Joined: 25-October 03
From: Bath, UK
Member No.: 464
I hadn't thought you'd need libusb, however after reading this (http://emul.berlios.de/about.php) I think you might (it might be worth trying to find some program which will test whether libusb is working - in fact I don't even know what it's supposed to do).
I'm working exclusively from http://emul.berlios.de/ as this is the one linked from http://geocities.com/i0xox0i/ with some kind of indication that it'll work on 2.4.x (the other site seems to me to be concerned with 2.6.x kernel modules which won't work for you until the 2.6.11 kernel is ported to the 6000).
Installing.. blah blah
ipkg_conf_write_status_files: Can't open status file: /mnt/card/packages//usr/lib/ipkg/status for writing: Read-only file system.
I saw someone saying this had happened to them - I asked whether their card was mounted ro or rw - I can't remember what the problem was though I'm afraid. Perhaps umount the card and try running fsck on it.
mknod /dev/ttyUSB0 c 188 0
mknod /dev/ttyUSB1 c 188 1
mknod /dev/ttyUSB2 c 188 2
mknod /dev/ttyUSB3 c 188 3
mknod /dev/ttyUSB15 c 188 15
appears to be correct.
Next question is whether the driver for the device is loaded, and whether/how it's bound to the dev entry. My (admittedly not very in-depth) understanding is that you'll get this binding if you use the kernel module (which acts as the usb-serial convertor).
I don;t think this is what you're going to be doing - the patched gpsd uses the emul lib which uses libusb which talks to the usb device directly (that's my guess anyway).
Try to install the libusb, stick the emul lib in (and create the symlinks to the major and .so files), the see if gpsd or the two test programs will work.
(a bit of an explanation: http://www.mp3car.com/vbulletin/showthread.php?t=24211)
Last user comment on this page might also be interesting to investigate:
(the one from David Tauriainen)
Explanation of what emul is: http://s2.selwerd.nl/~dirk-jan/gpsdrive/ar...e/msg04332.html
Plus the entire README from emul source code:
EarthMate Userland Library v1.0.2
emul's dependencies are as follows:
libusb >= 0.1.8
The library has moved away from automake and friends. For your target
install, please link the appropriate makefile. For example, someone doing
an install with Mac OS X or OpenDarwin should issue the command:
$ln -s Makefile.darwin Makefile
To install, please take a look at the Makefile and make sure the
PREFIX variable is set to your liking. The default is '/usr'. If this
is acceptable, it should be simple enough to enter the command below
and hit enter:
$ make install
To see if things are working, there are two programs which utilize
this library. Those are: emul_test and sirfmon. If all goes well,
simply running emul_test should start spewing NMEA (or binary garbage)
on the terminal. A quick way to get the unit to switch back into nmea
mode is to physically replug it. There is also the excellent utility
'sirfmon' written mostly by Eric S. Raymond which can be run with this
library via the command:
$ sirfmon emate (it also works with regular tty devices)
You can switch the unit between sirf and nmea with the sirfmon utility.
By default, the unit is switched into sirf mode when starting sirfmon. To
go back to nmea, simply enter 'n' at the command line.
Both sirfmon and emul_test are installed by default. emul_test can be
passed the argument 'd1' - 'd8' to activate emul library debugging.
For information regarding the gpsd patch in directory patches,
please view the readme file in that directory.
Documentation for the library can be found in html/ courtesy of doxygen.
man keywords are 'emul.h' and 'serconfig'.
If you want to help out, with porting/patches/bug reports/success
stories/etc, please do. Visit the project page at:
My tests and trials:
Machines tested with library:
amd athlon 1500/256MB ddr266/ehci-ohci-uhci
abit bh6 p3 667/256MB PC133/ali ehci-ohci, uhci bus onboard
2.4 linux kernel notice:
Host controllers that are usb 2.0 compatible bundled with ohci bridges for
usb 1.1 gave me some trouble. For instance, trying to read from the interrupt
in pipe will return -22 (or EINVAL) for whichever reason. This problem does not
seem to exist on the 2.5/2.6 kernels. A quick and dirty solution is to connect
a usb 1.1 hub on one of the controllers port hubs and then plug the earthmate
into that. I'm not sure if this is the same for ehci/uhci controllers as
well... I surely hope not. For people with plain jane usb 1.1 busses there
should be no problem.
RedHat Linux 9.0 (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) kernel
Before compiling, I had to change MANDIR to 'MANDIR=$(PREFIX)/share/man'.
Otherwise it compiled cleanly. The version of libusb that comes default with
rh9 is 0.1.6, which does not contain the necessary functions for interrupt
transactions. I had to first package a new rpm of libusb-0.1.10a and then force
it to install using the --force flag. I also grabbed the latest usbutils and
repacked that as well (for lsusb tool). On the first run, the system completely
locked up. Apparently when connected to the uhci usb bus the system would oops.
I then tried upgrading the kernel to something a little more recent from
kernel.org. With 2.4.22/2.4.24/2.4.30 no lockups occured. sirfmon, both the
version packaged with the library and the one accompanying gpsd, worked well.
The library utilites, such as emul_test, did not however. This problem should
be fixed at this point. I also ran gpsd-2.21 with success.
Gentoo Linux 2005.0 (gcc 3.4.3 / kernel 2.6.11):
Compiled without trouble. It just works, but then again I'm developing emul
on this platform.
Slackware 10.1 (gcc 3.3.4 / kernel 2.4.29):
Compiled without trouble. The sirfmon utility works fairly well at rates
below or at 9600bps. Anything higher will start
choking the emul applications, including gpsd.
OpenDarwin 7.2.1 (gcc 3.3):
Compiled without trouble. The only usb controller which seemed to work was
an Ali based ehci/ohci controller, and even then only one of the two ports
worked. I'm sure someone with ppc hardware could easily have this working.
When running the test applications, they work quite well now. Before a certain
bug was fixed, they would fail on the read process. gpsd should work fine with
Mac OS X:
I'm guessing this library will work based on what happened with OpenDarwin.
BSD support is coming along slowly.
NetBSD 2.0 (gcc 3.3.3):
Compiled without trouble. In order to avoid using userconf manually on every
boot to disable uhid/uhidev, the uhid interface needs to be disabled in the
kernel by recompiling it. This is of course very inconvenient for someone with
usb mice, etc. With userconf, at boot I had to issue the command 'boot -c' in
order to get into the userconf dialog. Then, to disable the hid interface,
issue the commands: disable 349 and disable 350. The emul_test program works
fine, however the lines never drop... that is something that should be fixed.
The em_select() function seems to be at blame for why sirfmon and emul_test2
fail to work properly.
Avoid this library... use the ucycom module instead. Someone, namely
'brick', has reported the module working fine with the earthmate on FreeBSD
6.0-CURRENT. The node created by ucycom should be used with gpsd. If you
however would want to still use this library... who am I to stop you! Something
to look into for disabling ucycom/uhid without obtaining a migraine would be
|Lo-Fi Version||Time is now: 23rd May 2017 - 12:57 AM|