The Navigatrix has been updated. The new website can be found at navigatrix.net.
| Author |
Message |
|
belle-isle
|
Post subject: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
En français ci-dessous / French version belowHi, 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 http://ubuntuforums.org/showthread.php?p=9774735#post9774735), I have not managed to make the connection to the MiniPlex work. I have tried the following : Code: insmod ftdi_sio vendor=0x0403 product=0xfd49 Code: sudo modprobe usbserial vendor=0x0403 product=0xfd49 putting in /etc/modprobe.d/usbserial : Code: 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 ! ---------------------------------------------------- Bonjour, 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 http://ubuntuforums.org/showthread.php?p=9774735#post9774735), je n'ai pas réussi à faire marcher la connexion avec le MiniPlex. J'ai essayé : Code: insmod ftdi_sio vendor=0x0403 product=0xfd49 Code: sudo modprobe usbserial vendor=0x0403 product=0xfd49 Mettre dans /etc/modprobe.d/usbserial : Code: 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 !
|
|
| Top |
|
 |
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
This is what I think is happening: Shipmodul MiniPlex returns NMEA entences prefixed with $PSMD... Quote: 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. Code: sudo dpkg-reconfigure gpsd Select No for the first option regarding automatic start, and defaults for the rest. Code: 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.
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
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 Code: ~$ 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 : Code: ~$ 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 ! Code: ~$ 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 : Code: ~$ sudo cat /dev/ttyUSB0
$GPZDA,111946,05,02,2014,0,0*42
$GPRMC,111946,A,2216.3908,S,16625.7886,E,0.1,244.2,050214,12,E*4D
$GPRMB,A,0.00,L,START ,076 ,2216.386,S,16625.784,E,0.0,317.0,0.0,A*4F
$GPGLL,2216.3908,S,16625.7886,E,111947,A*3E
$GPGGA,111947,2216.3908,S,16625.7886,E,1,9,1.7,1,M,59,M,,*64
$GPVTG,243.5,T,231.5,M,0.1,N,0.1,K*4B
$GPZDA,111947,05,02,2014,0,0*43
$GPRMC,111947,A,2216.3908,S,16625.7886,E,0.1,243.5,050214,12,E*4C
$GPRMB,A,0.00,L,START ,076 ,2216.386,S,16625.784,E,0.0,317.0,0.0,A*4F
$GPGLL,2216.3908,S,16625.7886,E,111948,A*31
`~0�~0~00�����<���?�x����<��������?� ?~
�f0�����<��?� �������f�<� 3<<3�3 03�`�~0�x`3~0��``����`3�� ��������������������������`x0怘�`~0��f0�������<���<��<�����<�<�3̘�f
�`~0�3�� 0�����<�������?�x����<��������?� ?~ 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 Code: 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 : Code: ~$ 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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
When you look at something like http://ubuntuforums.org/showthread.php?t=1562418...and 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 Code: sudo medit /etc/modprobe.d/usbserial having the line Code: 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 better....as it should, because that is the chip you're dealing with. He recommends editing the same file Code: sudo medit /etc/modprobe.d/usbserial and replacing the entire contents with Code: 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. Code: sudo medit /etc/modules Double check Code: lsmod | grep usb to see what is being called to help out usbserial; ftdi_sio....or some other...as 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. http://ftdi-usb-sio.sourceforge.net/http://www.sealevel.com/support/article/AA-00524
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
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 : Code: ftdi_sio Just for the record, in case others need help on this : my /etc/modprobe.d/usbserial file reads Code: insmod ftdi_sio vendor=0x0403 product=0xfd49 and my /etc/modprobe.d/ftdi_sio.conf file reads Code: 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 Code: ~$ 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 Code: ~$ 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/ttyUSB0Code: 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. Code: # 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. Code: Feb 6 13:11:30 nx gpsd[1235]: gpsd:SHOUT: vendor/product match with 091e:0003 not found Thank you Moe for your help.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
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 Code: 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 Code: sudo medit /etc/udev/rules.d/51-garmin.rules inserting Code: ATTRS{idVendor}=="091e", ATTRS{idProduct}=="0003", MODE="666" save and execute Code: 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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
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 Code: sudo medit /etc/rc.local so that it looks like Code: #!/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 Save. Code: 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 are....so 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.
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
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. Code: 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 http://www.catb.org/gpsd/faq.html#baud suggests the following although I haven't tried it and don't really know what the difference would be. Code: 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 Code: stty -F /dev/miniplex 57600 in the script insteand could solve the issue and not be a problem to other devices, right ?
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
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. http://www.reactivated.net/writing_udev_rules.html
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
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 Code: 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 : Code: 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 : Code: 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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
|
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 dead...it 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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
It might look something like: Code: 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. Code: sudo /etc/init.d/udev restart for a quicker turnaround on testing. Good luck.
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
Hi, 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 : Code: 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. Code: ~$ 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':
KERNEL=="ttyUSB0"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/ttyUSB0':
KERNELS=="ttyUSB0"
SUBSYSTEMS=="usb-serial"
DRIVERS=="ftdi_sio"
ATTRS{port_number}=="0"
ATTRS{latency_timer}=="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0':
KERNELS=="2-1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="ftdi_sio"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{bNumEndpoints}=="02"
ATTRS{supports_autosuspend}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
ATTRS{interface}=="ShipModul MiniPlex-2USB"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1':
KERNELS=="2-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="1"
ATTRS{idVendor}=="0403"
ATTRS{speed}=="12"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{busnum}=="2"
ATTRS{devnum}=="46"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="90mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="0"
ATTRS{bcdDevice}=="0600"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="21000900"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="251786"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="CustomWare"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="fd49"
ATTRS{bDeviceClass}=="00"
ATTRS{product}=="ShipModul MiniPlex-2USB"
looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="0"
ATTRS{idVendor}=="1d6b"
ATTRS{speed}=="12"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{authorized_default}=="1"
ATTRS{busnum}=="2"
ATTRS{devnum}=="1"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="0mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="2"
ATTRS{bcdDevice}=="0308"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="0000:00:1d.0"
ATTRS{version}==" 1.10"
ATTRS{urbnum}=="757"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Linux 3.8.11-dsp-nopae uhci_hcd"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="0001"
ATTRS{bDeviceClass}=="09"
ATTRS{product}=="UHCI Host Controller"
looking at parent device '/devices/pci0000:00/0000:00:1d.0':
KERNELS=="0000:00:1d.0"
SUBSYSTEMS=="pci"
DRIVERS=="uhci_hcd"
ATTRS{irq}=="18"
ATTRS{subsystem_vendor}=="0x1ab8"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x0c0300"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="f"
ATTRS{device}=="0x2658"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-3"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x0400"
ATTRS{d3cold_allowed}=="0"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
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...) Code: 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. Code: 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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
Well done creating the rule. Quote: 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.
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
|
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...
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
I just checked and I get the same error with no Garmin anything. Code: 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.
|
|
| Top |
|
|
|
belle-isle
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 01 Oct 2012, 03:44
Posts: 19
|
|
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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
I beginning to think it is not an error at all...just an 'advisory' as opposed to an 'error'. Quote: 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. ...it'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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
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.
|
|
| Top |
|
|
|
Moe
|
Post subject: Re: Shipmodul MiniPlex USB
|
|
Joined: 04 Nov 2010, 20:51
Posts: 1062
|
|
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.
|
|
| Top |
|
|
|
