- A Voyager's Companion

Shipmodul MiniPlex USB
Page 1 of 2

Author:  belle-isle [ 04 Feb 2014, 21:46 ]
Post subject:  Shipmodul MiniPlex USB

En français ci-dessous / French version below

I managed to install Navigatrix on both a dedicated partition on my onboard mini-PC and on a Parallels virtual machine on my Mac. Works OK, especially with my "mouse" USB GPS which I have as a backup.

However, I can't get either setup to work with my onboard instruments. They are all multiplexed using a Shipmodul MiniPlex USB, which works great with OpenCPN under Windows and/or Mac (it feeds my position, heading, and ground speed from the fixed GPS, as well as AIS data from other ships, and depth, water speed, temperature, and magnetic heading via the Raymarine Seatalk input : all this can be displayed on the dashboard, and makes for a great nav platform). I would naturally prefer this setup in Navigatrix as well, rather than being limited to a lone clumsy USB GPS.

BUT, despite reading a few tips on other forums (especially, I have not managed to make the connection to the MiniPlex work. I have tried the following :
insmod ftdi_sio vendor=0x0403 product=0xfd49

sudo modprobe usbserial vendor=0x0403 product=0xfd49

putting in /etc/modprobe.d/usbserial :
options usbserial vendor=0x0403 product=0xfd49

This manages to create /dev/ttyUSB0 (previously absent), however, it looks all garbled, and gpsd doesn't seem to receive anything. Could have to do with baud rate ? How can I change this ? Any other suggestions ? And how can I automate the creation of /dev/ttyUSB0 so that I don't have to launch these commands each time ?

Thanks for any help !


J'ai réussi à installer Navigatrix à la fois sur une partition dédiée sur mon mini-PC de bord et sur une machine virtuelle Parallels sur mon Mac. Ca marche bien, notamment avec mon GPS "souris USB" que j'ai comme secours.

En revanche, je ne parviens pas faire fonctionner aucune des deux installations avec mes instruments de bord. Ils sont tous multiplexés grâce à un Shipmodul MiniPlex USB, qui fonctionne très bien avec OpenCPN sous Windows et/ou Mac (il me fournit la position, le cap, la vitesse fond du GPS fixe, ainsi que les données AIS des autres bateaux, et la profondeur, vitesse surface, température et cap magnétique via l'entrée Raymarine Seatalk : tout cela peut être affiché sur le "dashboard", faisant d'OpenCPN une formidable plateforme de nav). Evidemment, je préférerais cela dans Navigatrix aussi, plutôt que d'être limité à un GPS USB bancal et solitaire.

MAIS, même en ayant suivi des suggestions trouvées sur des forums (en particulier, je n'ai pas réussi à faire marcher la connexion avec le MiniPlex. J'ai essayé :
insmod ftdi_sio vendor=0x0403 product=0xfd49

sudo modprobe usbserial vendor=0x0403 product=0xfd49

Mettre dans /etc/modprobe.d/usbserial :
options usbserial vendor=0x0403 product=0xfd49

Cela crée /dev/ttyUSB0 (inexistant auparavant), mais le contenu est illisible, et gpsd ne semble pas recevoir quoi que ce soit. Le problème est-il dans la vitesse baud ? Comment la modifier ? D'autres suggestions ? Et comment automatiser la création de /dev/ttyUSB0 pour ne pas à avoir à relancer ces commandes à chaque fois ?

Merci pour votre aide !

Author:  Moe [ 04 Feb 2014, 23:08 ]
Post subject:  Re: Shipmodul MiniPlex USB

This is what I think is happening:

Shipmodul MiniPlex returns NMEA entences prefixed with $PSMD...

gpsd parses the following NMEA sentences: RMC, GGA, GLL, GSA, GSV, VTG, ZDA, GBS, HDT, DBT. It recognizes these with either the normal GP
talker-ID prefix, or with the GN prefix used by GLONASS, or with the II prefix emitted by Seahawk Autohelm marine navigation systems, or with
the IN prefix emitted by some Garmin units, or with the EC prefix emitted by ECDIS units, or with the SD prefix emitted by depth sounders. It
recognizes some vendor extensions: the PGRME emitted by some Garmin GPS models, the OHPR emitted by Oceanserver digital compasses, the PTNTHTM
emitted by True North digital compasses, and the PASHR sentences emitted by some Ashtech GPSes.

I've heard that it is possible to teach the gpsd to parse sentences prefixed uniquely. I have never had reason to learn if it is possible and I don't know how that would be done. It might involve a rewritten driver, or it might be just a switch.

At this point it might be best to disable the gpsd to get it out of the way.
sudo dpkg-reconfigure gpsd
Select No for the first option regarding automatic start, and defaults for the rest.
sudo /etc/init.d/gpsd stop
to stop the current process...and then try to configure your Shipmodul MiniPlex.

You will loose all gpsd function and integration into the system, but we moght find out what isgoing on. It might be possible later to send the demuxed gps data to a reconfigured gpsd to regain what would be lost. However, at this point I don't know.

Automatic 'hotplug' recognition of the MiniPlex might require a new "udev" rule. But try it first with the gpsd disabled.

Good luck.

Author:  belle-isle [ 05 Feb 2014, 07:29 ]
Post subject:  Re: Shipmodul MiniPlex USB

Hi again and thank you for your fast reply.

I have tried disabling and stopping gpsd. Sadly, this does not help much.
However, I have made a bit of progress.

First, I have noticed that
~$ sudo modprobe ftdi_sio vendor=0x0403 product=0xfd49

works better than with usbserial : the "rhythm" of garbled text looked more like that of an NMEA stream. So I figure this driver should be be preferred.

Then I started noticing that at times (very seldom), I did get a legible NMEA stream. And then it would switch over to being totally garbled, at very random times. Learning from the aforementioned forum thread, I understood the problem lay with the baud rate.

With the following code, I managed to restore the baud rate to the wanted value :
~$ sudo stty -F /dev/ttyUSB0 57600

The stream then becomes legible again. And after a random time (a few seconds), it becomes scrambled again, and surprisingly I learn that the baud rate has changed again !
~$ sudo stty -F /dev/ttyUSB0
speed 115200 baud; line = 18;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = ^A;
start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
werase = <undef>; lnext = <undef>; flush = <undef>; min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Here is an example of output :
~$ sudo cat /dev/ttyUSB0
$GPRMB,A,0.00,L,START ,076   ,2216.386,S,16625.784,E,0.0,317.0,0.0,A*4F
$GPRMB,A,0.00,L,START ,076   ,2216.386,S,16625.784,E,0.0,317.0,0.0,A*4F

Needless to say, on both Mac and Windows, the stream is perfectly legible all the way. I have checked. And by the way, this looks like a standard NMEA stream, no problematic prefixes, or am I mistaken ?

With gpsd being shutdown, my first question is : can it be that some other process and/or driver is conflicting and also trying to manage /dev/ttyUSB0 ? I have loaded ftdi_sio instead of usbserial because it seems to work much better, but how can I make sure that usbserial is really kept out of the way ?

The second problem I'm trying to understand is that while the flow of NMEA data is legible, MMG GPS Panel shows the data just fine once configured to read out of /dev/ttyUSB0. OpenCPN on the other hand, will not read the data, even when correctly pointed to /dev/ttyUSB0. How can this be ?

As for the last issue I'm facing, each time I reboot I have to reload the driver, so I placed
options ftdi_sio vendor=0x0403 product=0xfd49
in /etc/modprobe.d/ftdi_sio.conf (which I had to create). Now I only need to do the following in order to launch the driver :
~$ sudo modprobe ftdi_sio
However, I would like this to happen automatically upon startup. How can this be done ?

Once I find answers to these questions, we'll just need to get it all working with gpsd. Sounds like I'm still a long way off, so any help would be appreciated.

Author:  Moe [ 05 Feb 2014, 10:08 ]
Post subject:  Re: Shipmodul MiniPlex USB

When you look at something like one post says "got it; this is how" and the next post says "I have not had any luck...I have done all of the above..." I just wonder what is going on.

Another site referencing the one above recommends
sudo medit /etc/modprobe.d/usbserial
having the line
options usbserial vendor=0x0403 product=0xfd49
as a means to inform the system the usbserial device is the following.The author then repeats the information in the cited page.

This is, as everyone seems to agree, that the ftdi_so module works it should, because that is the chip you're dealing with. He recommends editing the same file
sudo medit /etc/modprobe.d/usbserial
and replacing the entire contents with
insmod ftdi_sio vendor=0x0403 product=0xfd49
which will alias the 'proper' module when it call for a usbserial driver, loading it in place of the other.

However, he continues with the same thing I'm going to say.

I don't have this device so I can test it.

However, the subsequent poster "thanked" the Penguin...but I don't know if that's because it worked or he at least tried.

It may be the case that it is only the USB/Serial converter that connects is misbehaving by calling the wrong module.

The standard way to have a module loaded with ever boot if it doesn't automagically load is to add it to /etc/modules.
sudo medit /etc/modules

Double check
lsmod | grep usb
to see what is being called to help out usbserial; ftdi_sio....or some I'm guessing ftdi_so 'helps' usbserial like pl2303, e.g., does.

Regarding MMG/OpenCPN differences; MMG spends a lot of time parsing sentences and tossing out junk. I don't know if OpenCPN can handle garbage data/errors as well....possibly not.

Author:  belle-isle [ 05 Feb 2014, 21:18 ]
Post subject:  Re: Shipmodul MiniPlex USB

Hi again,

Thanks for the pointers. I've made some more progress.

First, I managed to have the driver loaded automatically on boot. This I did, as directed, by adding the following to the end of the /etc/modules file :

Just for the record, in case others need help on this : my /etc/modprobe.d/usbserial file reads
insmod ftdi_sio vendor=0x0403 product=0xfd49

and my /etc/modprobe.d/ftdi_sio.conf file reads
options ftdi_sio vendor=0x0403 product=0xfd49

From what I understand this redirects the usbserial driver to use the ftdi_sio driver instead.

With this done, /dev/ttyUSB0 gets created systematically when pluging the MiniPlex in the USB port. Good !

Problem is, it looked randomly scrambled, which I could clear up by setting the baud rate with
~$ sudo stty -F /dev/ttyUSB0 57600

However, it would initially randomly become scrambled again. Now with usbserial out of the way, I noticed that this happened in the first minute or so, and then if I once more restored the correct baud rate, it would remain legible. Using
~$ tail -f /var/log/syslog
I noticed that this matched exactly with the timing of the following calls being made by modem-manager to /dev/ttyUSB0
Feb  6 10:19:26 nx modem-manager[834]: <info>  (ttyUSB0) opening serial port...
Feb  6 10:19:38 nx modem-manager[834]: <info>  (ttyUSB0) closing serial port...
Feb  6 10:19:38 nx modem-manager[834]: <info>  (ttyUSB0) serial port closed
Feb  6 10:19:38 nx modem-manager[834]: <info>  (ttyUSB0) opening serial port...
Feb  6 10:19:38 nx modem-manager[834]: <info>  (ttyUSB0) closing serial port...
Feb  6 10:19:38 nx modem-manager[834]: <info>  (ttyUSB0) serial port closed
Feb  6 10:19:38 nx modem-manager[834]: <info>  (ttyUSB0) opening serial port...
Feb  6 10:19:50 nx modem-manager[834]: <info>  (ttyUSB0) closing serial port...
Feb  6 10:19:50 nx modem-manager[834]: <info>  (ttyUSB0) serial port closed
Feb  6 10:19:50 nx modem-manager[834]: <info>  (ttyUSB0) opening serial port...
Feb  6 10:19:50 nx modem-manager[834]: <info>  (ttyUSB0) closing serial port...
Feb  6 10:19:50 nx modem-manager[834]: <info>  (ttyUSB0) serial port closed

Four calls in all, after which setting the baud rate would not be altered anymore.

First question : How can I disable these interferences ? What is modem-manager used for ? Can it be removed or will other peripherals such as a phone not work anymore ? Can I stop these calls from accessing the device ?

Second question : Can I somehow automate setting the baud rate for the device ? It looks as though gpsd won't recognize it automatically, and I always need to do it manually. I believe even in solving the above issue with modem-manager, I will still have to do so.

With the device working correctly, I then started working with gpsd, and after a few tries, it does work OK. OpenCPN correctly recognises the NMEA stream and positions the boat and AIS targets ! So that's good news, It proves the multiplexer is correctly set up, it sends a valid stream, and provided I can set the baud rate right and it won't be overriden, it will work.

Here's what I did to enable gpsd to work with the MiniPlex. In the file /lib/udev/rules.d/40-gpsd.rules I added the following lines just before the list of other hardware.
# FTDI Shipmodul [linux module: ftdi_sio]
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="fd49", SYMLINK+="gps%n", RUN+="/lib/udev/gpsd.hotplug"

There's still an interesting line in the system logfile. I don't really know how to deal with that one.
Feb  6 13:11:30 nx gpsd[1235]: gpsd:SHOUT: vendor/product match with 091e:0003 not found

Thank you Moe for your help.

Author:  Moe [ 05 Feb 2014, 22:32 ]
Post subject:  Re: Shipmodul MiniPlex USB

I'm running out the door so I'll just hit a few points.

modem-manager helps with mobile broadband (3G and such). A few folk in the Debian/Ubuntu world have reported problems like you have in that it keeps probing devices it should leave alone.

You can remove it with
sudo apt-get purge modemmanager
it won't effect wireless/ethernet connections, but makes 3G bloody hard.

The "vendor/product match with 091e:0003 not found" is for a Garmin International GPSmap which might be rectified by
sudo medit /etc/udev/rules.d/51-garmin.rules
ATTRS{idVendor}=="091e", ATTRS{idProduct}=="0003", MODE="666"
save and execute
sudo udevadm control --reload-rules

Thanks for letting me muddle through this with you. I'll look at speed and the gpsd when I return.

Author:  Moe [ 06 Feb 2014, 08:14 ]
Post subject:  Re: Shipmodul MiniPlex USB

If I understand you, the magic expression to keep things running smoothly is stty -F /dev/ttyUSB0 57600?

You figured it out, but how to tell the machine to to it every time without you typing it in....right?

This simplest method is to include it in /etc/rc.local

sudo medit /etc/rc.local
so that it looks like
#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

stty -F /dev/ttyUSB0 57600

exit 0
sudo chmod +x /etc/rc.local
Reboot. Test.

It should do the trick. There are other ways to do this (which would be cool) such as a hotplug script to set the baud rate whenever the 'right' device is plugged in, but there is another level of complexity that needn't be addressed.

Also the probability that a global setting of the port at 57600 is a non-issue...that is you're not going to unplug the multiplexer so you can plug in your printer, chances you don't have to consider 'weird states'. So, set it and forget it. But remember it it the first USB device to plug in.

Author:  belle-isle [ 06 Feb 2014, 15:38 ]
Post subject:  Re: Shipmodul MiniPlex USB

Thanks a lot for your latest two messages.

I removed modem-manager and have noticed less interference. So that's a good thing despite the fact I got a warning on boot that some packages are missing. I still have to check this, but I would say it's OK for now.

No luck with the "gpsd:SHOUT: vendor/product match with 091e:0003 not found" error, though. I still see it appearing at times in the logfile, and it seems that this is causing interference as well, changing the baud rate.

stty -F /dev/ttyUSB0 57600
is indeed a working command to change the baud rate to a working setting. I found this on some forums, and have also found that suggests the following although I haven't tried it and don't really know what the difference would be.
stty speed 57600 </dev/ttyUSB0

Thank you for your suggestion of calling stty via the /etc/rc.local file. I haven't had time to try this yet. When does this script get executed ? I had tried to call stty in "/lib/udev/rules.d/40-gpsd.rules", just before the call to gpsd hotplug, but no luck at my first shot, so I gave up for now.

I understand the issue with the multiplexer having to be the first plugged in, so as to have the address /dev/ttyUSB0. For this reason I had also tried looking into giving it a "permanent" name, such as /dev/miniplex, but I thought I'd get it to work consistently first before breaking everything ! If this can be done, then including
stty -F /dev/miniplex 57600
in the script insteand could solve the issue and not be a problem to other devices, right ?

Author:  Moe [ 06 Feb 2014, 22:35 ]
Post subject:  Re: Shipmodul MiniPlex USB

Easy ones first: The difference between stty -F /dev/ttyUSB0 57600 and stty speed 57600 </dev/ttyUSB0 is the same as saying 'set tty device xxx to 57600 speed' and 'set speed 57600 for tty applies to device xxx'. Six for you; or you will have six.

/etc/rc.local runs toward the end of all the multi-user boot levels:
  • 2 Multi-user Mode without network interfaces
  • 3 Multi-user Mode with networking
  • 5 Same as runlevel 3 plus a display manager. (X11, GUI)
so, unless your operating in a recovery mode, it runs just before you log in.

Regarding 'gpsd:SHOUT' two years ago this May a bug report was filed about the same trouble, "GPSD is not working..." a developer responded, "gpsd works fine, the problem seems to be in gpsctl. I'm not sure why gpsctl gives different results than gpsd." After that the trail gets cold. I'll put a bloodhound on it to see if we can shack something loose.

And you are right. The elegant solution would be a udev rule to set the speed of /dev/miniplex, e.g., wherever and whenever it's connected.

Author:  belle-isle [ 08 Feb 2014, 00:34 ]
Post subject:  Re: Shipmodul MiniPlex USB

Hi again,

Thanks for explaining the subtlety of language between the two stty calls.

I have made the modification to /etc/rc.local and it works as is to be expected.

That is : if the device is plugged in before booting, then it seems it works fine from start ! The signal is picked up in /dev/ttyUSB0, and fed through gpsd all the way to OpenCPN. So that's a victory !

However, if the multiplexer is NOT plugged in on boot, and it is connected to the USB port later on, then it does not work. Logically enough, the call to
stty -F /dev/ttyUSB0 57600
is made when /dev/ttyUSB0 does not yet exist... I would need the script to run on device plugin and not on login.

For information, in both cases, the output to log is identical :
bibou@nx:~$ sudo cat /var/log/syslog | grep gps
Feb  8 16:08:09 nx gpsd.hotplug: add /dev/ttyUSB0
Feb  8 16:08:09 nx gpsdctl: gpsd_control(action=add, arg=/dev/ttyUSB0)
Feb  8 16:08:09 nx gpsdctl: reached a running gpsd
Feb  8 16:08:09 nx gpsd[1247]: gpsd:SHOUT: vendor/product match with 091e:0003 not found

In addition, if on startup the device is plugged, and it is later unplugged and replugged. It doesn't work because strangely enough it takes the name /dev/ttyUSB1 ! Unplugging it again and back it gives it the name /dev/ttyUSB0 anew... I really would have to look into this persistent device naming.

In this case, with the device working anew on /dev/ttyUSB0, the log gets cluttered about every two seconds with the following :
Feb  8 16:28:05 nx gpsd[1229]: gpsd:ERROR: device open failed: No such file or directory - retrying read-only
Feb  8 16:28:05 nx gpsd[1229]: gpsd:ERROR: read-only device open failed: No such file or directory
Feb  8 16:28:05 nx gpsd[1229]: gpsd:ERROR: /dev/ttyUSB1: device activation failed.
Feb  8 16:28:07 nx gpsd[1229]: gpsd:ERROR: device open failed: No such file or directory - retrying read-only
Feb  8 16:28:07 nx gpsd[1229]: gpsd:ERROR: read-only device open failed: No such file or directory
Feb  8 16:28:07 nx gpsd[1229]: gpsd:ERROR: /dev/ttyUSB1: device activation failed.

Author:  Moe [ 08 Feb 2014, 01:36 ]
Post subject:  Re: Shipmodul MiniPlex USB

Un/Plugging 'quickly' results in 'port hopping'. Subsequent ports are incremented /ttyUSB0, /ttyUSB1, 2, 3, etc. The 'new' device is assigned a new identity. The machine doesn't consider a device removed, or might just be sleeping, for X seconds.

Unused ports are then recycled. I don't recall the exact time, but I use at least 10 seconds as rule of thumb.

It's particularly frustration if you have a worn or dodgy connector that makes/break contact multiple times in a 'short' period. "/dev/ttyUSB9?...what's it doing on 9?"

For what you say, it seems a hotplug script (udev rule) is a more suitable solution.

Author:  Moe [ 08 Feb 2014, 02:43 ]
Post subject:  Re: Shipmodul MiniPlex USB

It might look something like:

SUBSYSTEMS=="usb", ATTRS{idProduct}=="0xfd49", ATTRS{idVendor}=="0x0403", SYMLINK+="miniplex", RUN+="/bin/stty -F /dev/miniplex 57600"
...but I'm guessing.

I don't recall where you were in setting the ftdi_so module, setting the gpsd to find the 'new' device at /dev/miniplex, other configuration changes....and so on. I also don't know if you can create the symbolic link and set it in the same motion or if you need to add ACTION to give the system time to create the link.

You should be able to stick the in /etc/udev/rules.d and hammer away at it.
sudo /etc/init.d/udev restart
for a quicker turnaround on testing.

Good luck.

Author:  belle-isle [ 09 Feb 2014, 07:08 ]
Post subject:  Re: Shipmodul MiniPlex USB


It took me quite some time, but at last it looks like things are more or less working as they should.

A udev rule was indeed the way to go, and as a bonus it allowed persistent naming.

My rule reads :
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="fd49", ACTION=="add", SYMLINK+="miniplex", RUN+="/bin/stty -F /dev/miniplex 57600", RUN+="/lib/udev/gpsd.hotplug"
and I placed it in /etc/udev/rules.d/98-miniplex.rules. Interestingly enough, when called 10-miniplex.rules it would not work, whereas I thought the earlier it would be called the better. But it proved me wrong. Also note that the vendor and product codes had to be written without the hex-code prefix, contrary to your suggestion and to recommendations I also found on forums. I don't know why but it wouldn't work with a leading "0x".

In any case, just for the record, and in case someone tries to use the same multiplexer, I include here the full device data.

~$ udevinfo /dev/miniplex

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0':

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/ttyUSB0':

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0':
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{interface}=="ShipModul MiniPlex-2USB"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1':
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{version}==" 2.00"
    ATTRS{product}=="ShipModul MiniPlex-2USB"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2':
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{version}==" 1.10"
    ATTRS{manufacturer}=="Linux 3.8.11-dsp-nopae uhci_hcd"
    ATTRS{product}=="UHCI Host Controller"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0':

  looking at parent device '/devices/pci0000:00':

Also for the record, I naturallt removed the rule from /lib/udev/rules.d/40-gpsd.rules (as mentioned in near the end of my 3rd post), since it was now elsewhere.

I also added an additional rule for my USB "mouse" GPS, and now I have persistent names for one or the other device. gpsd locates both of them thanks to the hotplug feature, and OpenCPN gets their signal from gpsd. Perfect.

The only remaining glitches are in the /var/log/syslog
file :

1. The ever-present SHOUT, but at least it does not look like it changed the baud rate anymore (don't know why...)
Feb  9 22:40:18 nx gpsd[8039]: gpsd:SHOUT: vendor/product match with 091e:0003 not found

2. When I plug either device, it works fine. When I unplug it, it disconnects fine. When it is plugged back in, it works again, but for a reason I can't determine, I get these log entries every 1 or 2 seconds, without any sort of timeout. This lasts until I disconnect the device again, so it will be filling the logs fairly quickly ! Why it seems to poll the connected device both on the right port and on a wrong port is quite a mystery to me.
Feb  9 22:40:18 nx gpsd[8039]: gpsd:ERROR: device open failed: No such file or directory - retrying read-only
Feb  9 22:40:18 nx gpsd[8039]: gpsd:ERROR: read-only device open failed: No such file or directory
Feb  9 22:40:18 nx gpsd[8039]: gpsd:ERROR: /dev/ttyUSB1: device activation failed.

Author:  Moe [ 09 Feb 2014, 07:35 ]
Post subject:  Re: Shipmodul MiniPlex USB

Well done creating the rule.
gpsd:SHOUT: vendor/product match with 091e:0003 not found
is indeed a mystery.

Do you have a Garmin International GPSmap (various models) as "091e:0003" indicates?

A quick search yields no answer to the problem, a few people aren't even using a Garmin. As this problem has been popping up for a few years, I think I'll kick this over to the gpsd people to see what they say.

Author:  belle-isle [ 09 Feb 2014, 07:43 ]
Post subject:  Re: Shipmodul MiniPlex USB

As such, there is no Garmin component in the system. The GPS connected to the Shipmodul MiniPlex is a Furuno GP-32. I do have a Garmin portable GPS, but I haven't connected it to the computer since installing Navigatrix, so that can't be the issue. Please also note that this issue pops up whether using the ShipModul MiniPlex or my USB "mouse" GPS (a BU-353), so it has to come from gpsd indeed. Or maybe I have a problem in my udev rules, but apart from what I mentioned I haven't changed anything...

Author:  Moe [ 09 Feb 2014, 07:48 ]
Post subject:  Re: Shipmodul MiniPlex USB

I just checked and I get the same error with no Garmin anything.
wadda@mini:~/Downloads/komodo/trunk/mozilla$ cat /var/log/syslog | grep SHOUT
Feb  9 22:44:31 mini gpsd[710]: gpsd:SHOUT: vendor/product match with 091e:0003 not found
...funny old world.

But now I'm curious. It's a gpsd thing because it's the same on two other Linux systems, virgin or modified..

I'll let you know what I find.

Author:  belle-isle [ 09 Feb 2014, 07:53 ]
Post subject:  Re: Shipmodul MiniPlex USB

OK, great.
I'll keep watching this post anyway.

Thanks a lot for the great help.
Your pointers got me going in the good direction several times.

Author:  Moe [ 09 Feb 2014, 08:09 ]
Post subject:  Re: Shipmodul MiniPlex USB

I beginning to think it is not an error at all...just an 'advisory' as opposed to an 'error'.

gpsctl can switch a dual-mode GPS between NMEA and vendor-binary modes...gpsctl does its work through gpsd, which will locate it for you.'s just telling us it can't find the Garmin device to switch to the vendor-binary mode.

But I still ask the big cheese.

Author:  Moe [ 09 Feb 2014, 08:27 ]
Post subject:  Re: Shipmodul MiniPlex USB

No need...opensource project file gpsd-tail.h

    /* logging levels */
    #define LOG_ERROR -1 /* errors, display always */
    #define LOG_SHOUT 0 /* not an error but we should always see it */
    #define LOG_WARN 1 /* not errors but may indicate a problem */
    #define LOG_CLIENT 2 /* log JSON reports to clients */
    #define LOG_INF 3 /* key informative messages */
    #define LOG_PROG 4 /* progress messages */
    #define LOG_IO 5 /* IO to and from devices */
    #define LOG_DATA 6 /* log data management messages */
    #define LOG_SPIN 7 /* logging for catching spin bugs */
    #define LOG_RAW 8 /* raw low-level I/O */

It doesn't explain what it is, or why we should always see it; but there you go.

Author:  Moe [ 09 Feb 2014, 08:51 ]
Post subject:  Re: Shipmodul MiniPlex USB

Thanks, by the way.

I have a wind/depth/gps node on the boat. I a few years ago had a choice: gps; or other instrumentation connected to the computer.

I chose gps and cobbled a splitter from the gps to the cockpit repeater, which apparently meant I had to hand enter data...or maybe it was gross operator error...doesn't matter.

Now, I think I can figure how to fix it.

This has been educational. Thanks for bringing it up.

Page 1 of 2 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group