Cruisers Forum
 


Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
Old 22-03-2010, 09:41   #1
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
Garmin 60CSx and Ubuntu with Kernel 2.6.31-20-Generic - Solution ?

I have until now used my Garmin 60CSx with Ubuntu and OpenCPN. I used these commands in a script to make it work:
gksudo modprobe garmin_gps
sudo mount -t usbfs none /proc/bus/usb/
sudo gpsd /dev/ttyUSB0

This works with ubuntu 9.10 and kernel 2.6.31-19-generic. Now with the latest kernel update I can't make this command work. sudo mount -t usbfs none /proc/bus/usb/ . Error: "mount: mount point /proc/bus/usb/ does not exist"

Since this is the old workaround I have tried for weeks to get My GPS to work another way with the new kernel. But with no luck.

Does anybody else had any luck using Ubuntu and Garmin (preferably 60CSx) with the 2.6.31-20-generic kernel?
amadeus is offline   Reply With Quote
Old 22-03-2010, 10:20   #2
Registered User

Join Date: Dec 2005
Location: Helsingborg
Boat: Dufour 35
Posts: 3,891
Have you tried using gpsd?
Check these instructions: Setting Up GPS | Official OpenCPN Homepage

Thomas
cagney is offline   Reply With Quote
Old 24-03-2010, 14:46   #3
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
New development. :)

Finally some results. I installed the new gpsd_2.92-2 that came a few days ago into my karmic. And when i use the command: "sudo modprobe garmin_gps" and then "sudo gpsd /dev/ttyUSB0" or "gpsd -N -D 6 /dev/ttyUSB0" I can read my position with xgps.

But it seems that OpenCPN is not compatible yet with the new gpsd version.

Anyone got any new ideas?
amadeus is offline   Reply With Quote
Old 24-03-2010, 15:08   #4
Registered User

Join Date: Dec 2005
Location: Helsingborg
Boat: Dufour 35
Posts: 3,891
Have you set NMEA Data source to Network GPSD in the ToolBox GPS tab? First set this value and then plug in your gps.
cagney is offline   Reply With Quote
Old 24-03-2010, 17:00   #5
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
Log

NMEA Data source to Network GPSD is set correct.

A little ouput with what happening when I start OpenCPN:

gpsd -N -D 6 /dev/ttyUSB0
gpsd: launching (Version 2.92)
gpsd: listening on port gpsd
gpsd: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd: successfully connected to the DBUS system bus
gpsd: running with effective group ID 1000
gpsd: running with effective user ID 1000
gpsd: stashing device /dev/ttyUSB0 at slot 0
gpsd: client 127.0.0.1 (0) connect on fd 6
gpsd: => client(0): {"class":"VERSION","release":"2.92","rev":"svn","p roto_major":3,"proto_minor":1}
gpsd: checking client(0)
gpsd: <= client(0): l
gpsd: => client(0): =
gpsd: checking client(0)
gpsd: <= client(0): O
gpsd: => client(0): =
gpsd: checking client(0)
gpsd: <= client(0): lO
gpsd: => client(0): =
gpsd: checking client(0)
gpsd: detaching 127.0.0.1 (sub 0, fd 6) in detach_client


And now a output with xgps with the same start command:

gpsd: => GPS: 100600fa1003
gpsd: SendPacket(), wrote 6 bytes
gpsd: DOPS computed/reported: X=0.623644/0.000000, Y=0.577145/0.000000, H=0.849723/1.045293, V=1.205760/1.476186, P=1.475089/1.808802, T=0.663859/0.881724, G=1.617589/2.012262
gpsd: /dev/ttyUSB0 is known to be Garmin USB binary
gpsd: garmin_ser_parse()
gpsd: garmin_ser_parse() Type: 0x72, Len: 0x54, chksum: 00
gpsd: PrintSERPacket(, 0x72, 0x54, )
gpsd: SAT Data Sz: 84
gpsd: Sat 2, snr: -100, elev: 37, Azmth: 74, Stat: 4
gpsd: Sat 4, snr: -100, elev: 14, Azmth: 30, Stat: 4
gpsd: Sat 12, snr: -100, elev: 38, Azmth: 103, Stat: 4
gpsd: Sat 14, snr: -100, elev: 14, Azmth: 227, Stat: 4
gpsd: Sat 20, snr: -100, elev: 1, Azmth: 328, Stat: 4
gpsd: Sat 23, snr: -100, elev: 6, Azmth: 352, Stat: 4
gpsd: Sat 29, snr: -100, elev: 57, Azmth: 195, Stat: 4
gpsd: Sat 30, snr: -100, elev: 70, Azmth: 123, Stat: 4
gpsd: Sat 31, snr: -100, elev: 53, Azmth: 285, Stat: 4
gpsd: Sat 255, snr: 0, elev: 0, Azmth: 0, Stat: 0
gpsd: Sat 255, snr: 0, elev: 0, Azmth: 0, Stat: 0
gpsd: Sat 255, snr: 0, elev: 0, Azmth: 0, Stat: 0
gpsd: SAT_DATA: visible=9 used=9 mask={SATELLITE|USED}
gpsd: PrintSERPacket(, 0x72, 0x54, ) = 0x50000
gpsd: SendPacket(), writing 6 bytes: 100600fa1003
gpsd: PrintSERPacket(, 0x6, 00, )
gpsd: ACK
gpsd: PrintSERPacket(, 0x6, 00, ) = 00


It looks for me that OpenCPN is incompatible with gpsd 2.92. Hope Dave see this.
amadeus is offline   Reply With Quote
Old 26-03-2010, 04:20   #6
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Quote:
Originally Posted by amadeus View Post
It looks for me that OpenCPN is incompatible with gpsd 2.92. Hope Dave see this.
yes, they completely changed the API with 2.90. Your best bet is to "upgrade" to a slightly older copy of gpsd. Among other abstraction-taken-way-too-far improvements, it is no longer possible to know if your DGPS signal is locked on, you just have to rely on the DOP error numbers.


Hamish
(who does not appreciate software messing with instrument's raw data because it thinks it knows better)
HamishB is offline   Reply With Quote
Old 26-03-2010, 04:59   #7
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
Thanks for confirming HamishB.

I guess I have three short term options. 1. to use the old GPSD and the old kernel (which I do now) and hope Dave come up with a newer opencpn soon. 2. Change my Linux distribution with another where I have more control over my kernel options. A friend of mine is using Arch linux. Here I can use a new kernel but old gpsd. 3. Urgh. My wife has a laptop with the ugly OS that begins with W.

Hopefully this situation is solved relatively rapidly.

I see all of the Programs I have tested using gpsd have the same problem. So the situation is not unique.

I absolutely agree on :

Quote:
Originally Posted by HamishB View Post
Hamish
(who does not appreciate software messing with instrument's raw data because it thinks it knows better)
amadeus is offline   Reply With Quote
Old 26-03-2010, 12:04   #8
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 7,384
GPSD Woes...

Folks....

The sad story on gpsd:

1.gpsd Version 2.92 leading to 3.0 in June has completely changed the API. Opencpn does not currently support the new API.

2. New API does not support direct client-side query-response mode through TCP sockets. A streaming data model is used, abstracted by a library function which opencpn must link against. This library is/will be available for modern linux distros.

3. I quote from gpsd website:
Code:
"No, we don't support Windows — get a better operating system."
And one more...

Code:
If your code issues old-protocol commands A, D, E, M, P, T, U, or V, it is a wretched hive of scum and villainy that probably hasn’t changed since before the introduction of W.  You are using the oldest single-shot commands and will have to rewrite your interface significantly, as the new protocol does not support equivalents.  Use libgps.


So, there it is. If we move to the new gpsd API model, we abandon support for opencpn Windows client-side gpsd access.

IMHO, this sucks. The hubris of the quoted comment above is absolutely antithetical to the notions and spirit of open source development.
Never mind that if we make this change, we may pull the rug out from under who-knows-how-many Windows users currently depending on gpsd.

But I'll try to let that go.....

So, what to do?
Comments/ideas?

Dave

(p.s There. I feel better now)
bdbcat is offline   Reply With Quote
Old 26-03-2010, 14:56   #9
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
Thanks for taking the time to answer Dave. The reason I care so much is that OpenCPN is the first user friendly navigation software I have ever used. I have used software with more features, but never a program which is so user friendly at sea.

It looks that Linux is going through a major change in how USB is working, and then all software has to change with it. Including gpsd and OpenCPN. This seems to be not very popular. They say it has been warned about for years. But I don't think it justify that they remove important features and programs for a while. Maybe they speed up the process that way, I don't know.

Over to your concern Dave. I have a couple of win computers at home (like my wifes, virtualbox etc). I have tried OpenCPN on Windows too, but to my knowledge never gpsd in win. Just the driver to different GPS's and OpenCPN. My brother use franson gpsgate, but thats beside the point.

What I mean is that if gpsd don't want to support windows anymore it is a dead project anyway. So if I understand correctly you have to choose from backward compatibility and forward compatibility.

In my opinion it is not a question. Let the old code be available for old gpsd win users and go on with the new. If not, the Linux version will die. I think more users will suffer there. I know I will.

Fair winds to all.


I don't want windows to die. I just want the choice.
amadeus is offline   Reply With Quote
Old 26-03-2010, 17:54   #10
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Quote:
Originally Posted by amadeus View Post
I guess I have three short term options. 1. to use the old GPSD and the old kernel (which I do now) and hope Dave come up with a newer opencpn soon.
I don't understand why you have to mess with the kernel. Is the garmin kernel driver broken in the stock Ubuntu 9.10?

If you are using Ubuntu 9.10 stick with the gpsd version which comes with it (2.39), unless again there is something broken in the garmin driver. Even if the garmin kernel driver is broken, does it support NMEA mode? if so any gpsd version should work.

As a general rule- stick to what shipped with the distro unless you really know what you are doing.

Quote:
2. Change my Linux distribution with another where I have more control over my kernel options.
again, I don't understand what the kernel has to do with it.

Quote:
I see all of the Programs I have tested using gpsd have the same problem. So the situation is not unique.
stick with the gpsd 2.39 that shipped with 9.10 karmic. All software built for karmic will be expecting to see that version and nothing else.

For the OSGeo LiveDVD we are using Ubuntu 9.10 + OpenCPN 1.3.6 + gpsd 2.39 and it all works for me. (but no idea about the garmin 60CSx)
OSGeo Live GIS Virtual Machine and ISO-Image Downloads

regards,
Hamish
HamishB is offline   Reply With Quote
Old 26-03-2010, 18:19   #11
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
Hi HamishB

The problem with the Kernel is that after the newest kernel update on ubuntu 9.10, they stopped the support for usbfs. (Check: sudo mount -t usbfs none /proc/bus/usb/). Without being able to mount usbfs I can't use gpsd 2.39.

Gpsd 2.92 don't use usbfs and mount at /dev/USB0/ instead of /proc/bus/usb/

So there is nothing wrong with garmin driver or gpsd but Ubuntu and other distro's don't want to support USBFS anymore and force programmers to use the new method. They claim usbfs create bugs in the new system, which support more plug and play.

I can add the usbfs kernel module in a different distro like arch. But this is messy in Ubuntu. I therefor can't use what is shipped. Ubuntu obviously has advantages over other distros too.

Another thing is that within a month or so Ubuntu lucid lynx will arrive and with that the gpsd 2.92. Arch and other distro's are already using the gpsd 2.92. Within a month OpenCPN will not be able to connect to any gps when lucid lynx arrive. So this is not only a problem with my 60CSx.
amadeus is offline   Reply With Quote
Old 26-03-2010, 19:13   #12
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Quote:
Originally Posted by bdbcat View Post
Folks....

The sad story on gpsd:

1.gpsd Version 2.92 leading to 3.0 in June has completely changed the API. Opencpn does not currently support the new API.

2. New API does not support direct client-side query-response mode through TCP sockets. A streaming data model is used, abstracted by a library function which opencpn must link against. This library is/will be available for modern linux distros.
*BSD (Mac) too, for what it's worth.

n.b. the DBUS stuff wasn't really used much anyway. (AFAIK)

Quote:
3. I quote from gpsd website:
Code:
"No, we don't support Windows — get a better operating system."
And one more...

Code:
If your code issues old-protocol commands A, D, E, M, P, T, U, or V, it is a wretched hive of scum and villainy that probably hasn’t changed since before the introduction of W.  You are using the oldest single-shot commands and will have to rewrite your interface significantly, as the new protocol does not support equivalents.  Use libgps.


So, there it is. If we move to the new gpsd API model, we abandon support for opencpn Windows client-side gpsd access.
I don't understand that. gpsd has *never* supported MS Windows. So nothing lost. I'd ask if OpenCPN has its own MS Windows port of it, and be very surprised if the answer was yes, but from what I know of gpsd makes me think that the chance of that is very low.

AFAIK it just locks on to COM1 or whatever and parses the NMEA manually.


Quote:
IMHO, this sucks.
you are not alone

Quote:
The hubris of the quoted comment above is absolutely antithetical to the notions and spirit of open source development.
heh. understand that statement was written by Eric Raymond (ESR) and it is probably very much intended to be provocative. With respect the the "get a better OS" statement, in this case there's a bit of truth to it actually. If you are trying to implement something like multi-client gpsd with sockets etc. on ms windows it would be 1,000% harder and more annoying to get right. if possible at all for a 3rd party to write.


Agree with it or not, the logic goes along the lines of *in the long run* you're not really helping the addict by playing the role of the enabler, or if you prefer, that it's better to put your finite energy into building a viable promised land than it is to put your energy into making slaves' existing lives more comfortable, or fighting the massive powers that be as an abolitionist. Or maybe you just want to make a better world for yourself and your friends, and don't really care what everyone else does in their messy world (e.g. Dr. Perelman refusing the $1M prize for proving the Poincaré conjecture).


Quote:
Never mind that if we make this change, we may pull the rug out from under who-knows-how-many Windows users currently depending on gpsd.

But I'll try to let that go.....
As far as I know there are exactly zero MS Windows users who depend on gpsd, as it does not and has never existed on Windows. I would be very surprised to learn differently.

Quote:
So, what to do?

Comments/ideas?
for GpsDrive (which I work on) what we ("we" as in other members of the team) did was to add cmake configure switch to choose the old/new API. This only really needs to be chosen at build time for packaged distros,
and folks building from source can expect to rebuild if they change their
backend support tools.


Quote:
(p.s There. I feel better now)

if, **after** porting to the new API and getting to know it, you still feel as grumpy I'd encourage you to put on your thickest skin and let your feelings known about the technical merits of it on the gpsd-users mailing list.
All client programs/users are dealing with the same thing.


regards,
Hamish

(many years ago I wrote the code for a couple of those apparently vile old-protocol letter commands (it was COG & SOG IIRC), so I know a little about it I haven't been involved much with gpsd since Eric took over but still try to follow along with developments)
HamishB is offline   Reply With Quote
Old 26-03-2010, 19:17   #13
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Quote:
Originally Posted by amadeus View Post
What I mean is that if gpsd don't want to support windows anymore it is a dead project anyway. So if I understand correctly you have to choose from backward compatibility and forward compatibility.

In my opinion it is not a question. Let the old code be available for old gpsd win users and go on with the new. If not, the Linux version will die. I think more users will suffer there. I know I will.
AFAIK gpsd has never supported MS Windows.

If there is enough demand, the old gpsd2.39 could be packaged in parallel by distros, as is done with the last-good autoconf (2.13) before that project went off on a tangent which broke everything for their users.

If there is one thing that Linux/FOSS is good at, it's quickly making supply available to anywhere there is even the smallest demand.


Hamish
HamishB is offline   Reply With Quote
Old 26-03-2010, 19:28   #14
Registered User

Join Date: Oct 2009
Location: Bergen, Norway
Boat: Gib'Sea 472
Posts: 47
gpsd windows

check this out Hamish

SourceForge.net: Howto/gpsd on windows - travelingsales
amadeus is offline   Reply With Quote
Old 26-03-2010, 19:38   #15
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Quote:
Originally Posted by amadeus View Post
Hi HamishB

The problem with the Kernel is that after the newest kernel update on ubuntu 9.10, they stopped the support for usbfs. (Check: sudo mount -t usbfs none /proc/bus/usb/). Without being able to mount usbfs I can't use gpsd 2.39.
methinks that you are not using the latest Ubuntu Karmic packages at all, those should just be minimal security fixes which do not change any features. I suspect that you are unknowingly tracking Lucid on-the-fly.

There is a subtle tick box somewhere in the ubuntu package updater which asks if you want to track the latest changes or just the security updates.

i.e. OpenCPN 1.3.6 works fine on Karmic, but you aren't using a true Karmic anymore.

Quote:
Gpsd 2.92 don't use usbfs and mount at /dev/USB0/ instead of /proc/bus/usb/
gpsd doesn't create the device, the Serial->USB kernel module (pl2303?) or GarminUSB kernel module does that.

for me on Debian and MacOSX, it has always been /dev/ttyUSB0 or similar. You can specify which device gpsd should talk to as a command line parameter.

see "/usr/sbin/gpsd --help"


Quote:
So there is nothing wrong with garmin driver or gpsd but Ubuntu and other distro's don't want to support USBFS anymore and force programmers to use the new method. They claim usbfs create bugs in the new system, which support more plug and play.
In my experience the kernel developers know a lot more about it that I ever will, and so in most cases I'd trust their judgement.

Quote:
I can add the usbfs kernel module in a different distro like arch. But this is messy in Ubuntu. I therefor can't use what is shipped. Ubuntu obviously has advantages over other distros too.

Another thing is that within a month or so Ubuntu lucid lynx will arrive and with that the gpsd 2.92. Arch and other distro's are already using the gpsd 2.92. Within a month OpenCPN will not be able to connect to any gps when lucid lynx arrive. So this is not only a problem with my 60CSx.
just because new bleeding-edge software is released doesn't mean you have to use it. I use Debian/stable for exactly this reason- it may be a bit out of date but all the incompatibilities and growing pains have already been sorted out. So it just works.

If the gpsd 2.39 package from Karmic won't install directly on Lucid, there's a good chance that I'll backport (foreport?) it and make new .debs for that at some point in the next 6 months. (ie August, if there is still demand)


no need to panic,
Hamish
HamishB is offline   Reply With Quote
Reply

Tags
garmin

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN Linux / Ubuntu Issues and Questions yachtmanforfun OpenCPN 65 24-01-2018 08:06
Ubuntu 10.4 and OpenCPN cagney OpenCPN 24 07-01-2011 12:16
Problems with GPS and AIS Data in Ubuntu tebsin OpenCPN 29 04-07-2010 12:07
Generic Injectors for Westerbeke 7.6 BTD Genset H/V Vega Electrical: Batteries, Generators & Solar 9 17-02-2010 17:26

Advertise Here


All times are GMT -7. The time now is 21:21.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.