The Navigatrix has been updated. The new website can be found at navigatrix.net.




Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Hello Navigatrix gurus! Linux noob here... I have a MiniPlex-2Wi mux. I want to use it with OpenCpn and the other apps on Navigatrix 0.5 (August 2014) which I installed yesterday. This device has a USB connection as well as WiFi. I am focused on the USB connection at present. No luck yet. May I ask for your help, please?

I have tried following the other ShipModul thread in this forum, but either did not understand it all, did not do it right, or it did not work. I have also tried other Ubuntu-based threads. I could either not find, or did not understand, a concise statement of what all to do and where to do it all.

I wrote to ShipModul and Martin Poenot replied promptly, saying, "We use an FTDI chip and use a custom PID of 0xFD4A for the MiniPlex-2Wi. The FTDI driver is already compiled into the kernel. The only thing yo need to do is add the following line to /etc/modules:
ftdi_sio vendor=0x0403 product=0xfd4a


The FTDI chip in the MiniPlex talks to our processor at 115200 baud so in your application you need to set the baud rate to 115200 as well." (I was using Mint 17.1 when I asked, so he may be referring to that kernel...)

I added the line to /etc/modules and rebooted. Nothing changed.

IF I could get it to show up as a serial device like /dev/ttyUSB1 then I feel like I could get the connection going in OpenCpn. But I'm still at the shallow end of the pool with regard to 'drivers', modules, and devices in Linux.

Once it is working, I promise to come back and post a step-by-step, 'idiot's guide' to what should be done after a clean install of the present version of Navigatrix.

Looking forward to your assistance. Thanks in advance! ;)

Ben (diver864)


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
diver864 wrote:
I wrote to ShipModul and Martin Poenot replied promptly, saying, "We use an FTDI chip and use a custom PID of 0xFD4A for the MiniPlex-2Wi.

I don't know. You would want to trust someone who designs, build and sells the product, after all they already have your money, over anyone else who probably had to look up what a ShipModul MiniPlex-2Wi is, what it does, let alone how it functions.

...and with that I ask;

Did it work under Mint?

What is it you want to do with it? (There's a well know phenomena in problem solving that can be avoided, if you're clear.)

What have you tried? In some cases this is a "show your work" (or some specificity that provides some assurance) as someone might have edited a file, but failed to notice the error message indicating that nothing was done.

This is also important to know so the left hand knows what the right is doing, sort of thing.

Additionally, it is not uncommon to change two variables in an equation and one defeats the other, or at minimum you don't understand what causes what?

Or finally, there are also the times changing a variable is ineffectual, counterproductive, or grinds everything to a halt because of not understanding th It's the ones who are don't have your money you should be leery about.e problem.

So, in the interim, go to the terminal and enter:
Code:
lsmod | grep ftdi_sio
This lists the modules that are loaded. It will return the name of the module, if it's loaded. When I execute the command
Code:
moe@io:~$ lsmod | grep ftdi_sio
moe@io:~$
...this is what I get because I don't have the thing to test. But, I am speculating it loads for you. It possibly even hotplugs, and loads the module when the device is inserted.

You can test that out by trying it.

You can see if the system recognises it when it's inserted, by looking at the output of
Code:
dmesg | tail
You can also check
Code:
dmesg | grep ftdi_sio
Depending on the outcome of those commands, and information you provide it can be made to work. I'm guessing the module loads without the modification to /etc/modules.

So it might hinge on if you want the hardware to do the work, or the software. Because it just might be a case of one, or the other, but not both unless someone puts a lot of time into it.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Hi Moe, thanks for your reply and coaching.

What I want to do: I have a ShipModul NMEA 0183 multiplexer (mux) which has (among other i/o) a USB port designed specifically to provide USB-to-serial type communications with a PC. I need to be able to plug it in to my Navigatrix-based laptop via USB and have it appear as /dev/ttyUSB0 or 1.

Why I want to do it: When that works, I understand that various apps on my laptop will receive the various NMEA sentences the mux is receiving.

Other info that may be useful:
- The mux' model is MiniPlex-2Wi. Its USB controller chip is an FTDI chip. It has PCI ID of 0403:FD4A. It communicates on USB at 115,200.
- I am running Navigatrix 0.5 (August 2014).

What I've done so far:
- Based on what was a clean install of Navigatrix, I added the following line to /etc/modules:
ftdi_sio vendor=0x0403 product=0xfd4a. No visible result.
- Based on what I read in the Navigatrix forum's other thread about getting a similar ShipModul mux to work, I also tried the following:
.
Code:
insmod ftdi_sio vendor=0x0403 product=0xfd4a

.
Code:
sudo modprobe usbserial vendor=0x0403 product=0xfd4a

. created /etc/modprobe.d/usbserial (as root) and put the following in it:
Code:
options usbserial vendor=0x0403 product=0xfd4a


You asked me to check some things. Results:
Code:
ben@acer-linux:~$ lsmod | grep ftdi_sio
[color=#FF0000]ftdi_sio[/color]               39986  0
usbserial              38902  2 pl2303,[color=#FF0000]ftdi_sio[/color]

That is a surprise, because before I started hacking around (for good or ill) that returned nul, as yours does.

Code:
ben@acer-linux:~$ dmesg | tail
[15975.569192] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[16173.309880] type=1400 audit(1429192952.012:32): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=18403 comm="apparmor_parser"
[16173.310662] type=1400 audit(1429192952.012:33): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=18403 comm="apparmor_parser"
[17983.072391] usb 2-1.2: USB disconnect, device number 5
[17983.269629] usb 2-1.2: new full-speed USB device number 7 using ehci-pci
[17983.370249] usb 2-1.2: New USB device found, idVendor=0403, idProduct=fd4a
[17983.370256] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17983.370262] usb 2-1.2: Product: ShipModul MiniPlex-2Wi
[17983.370266] usb 2-1.2: Manufacturer: CustomWare
[17983.370270] usb 2-1.2: SerialNumber: 25001350


Code:
ben@acer-linux:~$ dmesg | grep ftdi_sio
[    4.620868] [color=#FF0000]ftdi_sio[/color]: unknown parameter 'vendor' ignored
[    4.620874] [color=#FF0000]ftdi_sio[/color]: unknown parameter 'product' ignored
[    4.621102] usbcore: registered new interface driver [color=#FF0000]ftdi_sio[/color]
[10770.244755] Modules linked in: pps_ldisc(F) pps_core(F) pl2303(F) acer_wmi(F) sparse_keymap(F) rfcomm(F) bnep(F) dm_multipath(F) scsi_dh(F) intel_powerclamp(F) coretemp(F) kvm_intel(F) kvm(F) serio_raw(F) intel_ips(F) uvcvideo(F) wl(POF) videobuf2_vmalloc(F) videobuf2_memops(F) joydev(F) videobuf2_core(F) videodev(F) snd_hda_codec_hdmi(F) snd_hda_codec_realtek(F) cfg80211(F) lpc_ich(F) btusb(F) bluetooth(F) snd_hda_intel(F) snd_hda_codec(F) shpchp(F) snd_hwdep(F) binfmt_misc(F) nfsd(F) auth_rpcgss(F) nfs_acl(F) nfs(F) lockd(F) mac_hid(F) sunrpc(F) mei_me(F) fscache(F) mei(F) parport_pc(F) ppdev(F)[color=#FF0000] ftdi_sio[/color](F) usbserial(F) batman_adv(F) lp(F) parport(F) btrfs(F) libcrc32c(F) raid10(F) raid456(F) async_raid6_recov(F) async_memcpy(F) async_pq(F) async_xor(F) async_tx(F) xor(F) raid6_pq(F) raid1(F) raid0(F) multipath(F) linear(F) dm_mirror(F) dm_region_hash(F) dm_log(F) hid_logitech_dj(F) usbhid(F) hid(F) psmouse(F) i915(F) ahci(F) i2c_algo_bit(F) libahci(F) atl1c(F) drm_kms_helper(F) drm(F) wmi(F) video(F)


What do you suggest I do next?


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
Quote:
What I want to do: <snip>

Why I want to do it: When that works, I understand that various apps on my laptop will receive the various NMEA sentences the mux is receiving.
Yes, I understand you want it to work, and I have a rough understand of the device. Aside from that....

While you're racing ahead looking for the MiniPlex-2Wi on /dev/ttyUSB0, I'm back at the starting blocks with more basic questions, wondering what is the situation that calls for a hardware multiplexer? What problem is this multiplexer suppose to solve? What are you trying to mux? What are the instruments? What is their interface? What is the data? What do you expect to see, or not see?


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Mate, your photos on your blog are stunning! Thanks for sharing. Spent 5 years in Oz myself.

Your question about broader objective is a good one, probably for another thread. I inherited a Garmin 4208 chartplotter, GPS 17 and GMR24 radar when I bought the boat, along with Tack Tick (pre Raymarine ownership) wireless wind instrument and brain, Raymarine Autohelm S3G autopilot with ST8001 controller, fluxgate compass etc, VHF with DSC, Icom 801 SSB, and more. Replaced old Datamarine sounder with Garmin. (hope appreciate what a pain it was to type all that on phone and overcome autocorrect! ;-P )

Garmin plotter talks proprietary to radar, nmea 0183 to gps, n2k to sounder. wind is nmea 0183. Pilot is all ST to itself. Can also do nmea 0183. Radios are nmea 0183. I have a Hawking like master plan for point to point interconnection of it all, developed with great careful study over past 3 years. I am deliberate despite how things may appear.

However this does not allow for:
- simply added redundancy of cheap USB GPS
- simply added comfort of using Navigatrix facilities for below decks instrument repeaters, openCpn based route planning, etc etc. Crew self-serve awareness of key info on long voyages via own devices. Plotting of other parties DSCs, AIS targets, and ship's position on cabin repeater tablet display again for crew and pax awareness. Also doesn't allow for buffering and filtering of redundant nmea sentences. Etc. again.

Thus a WiFi enabled mux.

Having justified that, and eventually purchased it, I'd really like to stick with the objective of getting it working. What's next?

Thanks,
Ben


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Bump - can anyone help me get OpenCpn listening to the mux please?


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
There are no bumps here. Just like at sea, when the wind doesn't blow, you wait or fire up the engine and make your own way.

In the list of the things you’ve got attached to that multiplexer I had forgotten the question before I got to the end. That's a long list. Good luck with that.

This is how I think it might get the MiniPlex to work.

Navigatrix already has a gps/ais multiplexer called gpsd.

gpsd is the premier software tool that gathers, parses, and distributes gps time/data so well it is capable of creating a microsecond accurate Strata 1 Time Server using the same computer that will play a Sponge Bob video, even if that computer is a $35 Raspberry Pi.

I’ve also read somewhere it can multiplex data from a few other non-gps sensors (compass, etc.). I don’t recall any specifics, but this is the internet and I’ll leave it at that.

gpsd integrates a number of core geolocation/time services for Navigatrix, suffice to say a small keystone in the system.

...and because of the MiniPlex you will need to kill it and disable it from starting. It can make problem solving the MiniPlex more difficult, unless the guy who sold it to you knows any better. gpsd might eat some non-gps/ais data. It has that reputation that it may or may not deserve. It is efficient, humourless, and terrorize the children, a reputation it does deserve. All I'm saying is, it may not be fit for purpose. But that's the way it is.
Code:
sudo /etc/init.d/gpsd stop
to turn it off.
Code:
sudo dpkg-reconfigure gpsd
to reconfigure the default settings to keep it from starting up behind your back and squirreling any work you’re about to do. Less tail chasing.

You will answer <No> to the question “Start gpsd automatically?"
You will answer <No> to the question “ Should gpsd handle attached USB GPS receivers automatically? ”

<tab> and <OK>(<enter>) your way out of anything else.

This is the typo-free way of editing /etc/defaults/gpsd changing both “true” to “false”
Quote:
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="false"
GPSD_OPTIONS="-n -G -b"
DEVICES=""
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"
For a cheap thrill, you can hand-hack the file
Code:
sudo medit /etc/default/gpsd
or go full-commando with
Code:
sudo nano /etc/default/gpsd
...because nano can be less drama if you count keystrokes and clutter (sometimes).

I’m stalling now because I have no idea what comes next.

The test you did,

lsmod | grep <module name or part>

indicated the ftdi_sio module was loaded, as the guy who sold you the gizmo suggested was required.

I’m guessing there is some certainty missing. Where did it go?

Ascertain if the hotplug mechanism (udev, I believe) is picking this up and assigning the gizmo as a device on the filesystem, /dev/ttyUSB0, or whatever.

Unplug the gizmo. Wait 10 seconds. (This might be a myth, but 10 seconds, I'm told, is the outside limit for recycling device name increments, ttyUSB0, ttyUSB1, ttyUSB2, and so on. This use to be a problem if there was an intermittent short in the USB connector, and a wiggle of a loose connector would then move the device to ttyUSB6, and none of the application settings followed. But this is the internet, and I’ll leave it at that.)

Re-insert the gizmo. Go to the log and read the last 10 entries.
Code:
dmesg | tail
It looks like this:
Quote:
moe@io:~$ dmesg | tail
[71155.055839] usb 1-1.4: SerialNumber: 70F39547DEFA
[71164.952911] usb 2-1.1: new full-speed USB device number 6 using ehci-pci
[71165.046058] usb 2-1.1: New USB device found, idVendor=067b, idProduct=2303
[71165.046066] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[71165.046070] usb 2-1.1: Product: USB-Serial Controller
[71165.046074] usb 2-1.1: Manufacturer: Prolific Technology Inc.
[71166.081780] usbcore: registered new interface driver pl2303
[71166.081822] usbserial: USB Serial support registered for pl2303
[71166.081873] pl2303 2-1.1:1.0: pl2303 converter detected
[71166.085483] usb 2-1.1: pl2303 converter now attached to ttyUSB1

There it is, ttyUSB1, the device is /dev/ttyUSB1

With this information, you can add the connection to OpenCPN, however they (MiniPlex and OpenCPN) say to do it.

Other than that, I don’t know anything about plotters, overlay, or the black arts of radio.

If there is no pick up from udev, we can deal with that.

If there is success, then you could possible use OpenCPN data repeater function to pump gps data to a special configuration of gpsd, and restore some of those lost functions....or just live with a crippled system.

The more elegant solution would be to remember what you've done and reconfigure the gpsd to listen to the virtual device, or the hockey-puck gps you occasionally insert into the system as ancillary (not likely), or a simple backup if the complexity fails (more likely).


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Hi Moe,

thanks again for your help to date. I appreciate your patience and contribution. Today I spent several hours reading man pages and Ubuntu wiki, trying to understand the context of what we're trying to do. That helped (me.) Also carefully read again through the other thread by another guy with a similar model MiniPlex mux, that was trying to do the same thing as I. You helped him reach success, and that model is very close to mine, feature wise.

In one of the last posts of that thread, though, the OP said he'd later updated to Navigatrix (August 2014), which is based on Ubuntu 14.04 with a different kernel, and that broke it. So he had to work out a different solution. I followed the later solution he offered, but unfortunately it did not work for me.

You also gave me some instructions. Here is what I did:
$ sudo /etc/init.d/gpsd stop (no response, meaning all good.)
$ sudo dpkg-reconfigure gpsd (done per your instruction. All off.)

I spent some time looking around in /etc/modprobe.d, /lib/modprobe.d, udev, etc., and it's clear that by default there IS (supposed to be) an ftdi_sio module loaded automatically. Just not with this particular PCI ID as an alias.

When I $ lsmod | grep ftdi, the result agrees; it seems to be there:
$ lsmod | grep ftdi
ftdi_sio 39986 1
usbserial 38902 4 pl2303,ftdi_sio

Likewise, when I
$ find /lib/modules/`uname -r` -type f -name "*.ko" | grep ftdi
the result also seems to confirm the module should be there. Result:
/lib/modules/3.13.9-dsp/kernel/drivers/usb/serial/ftdi_sio.ko
/lib/modules/3.13.9-dsp/kernel/drivers/usb/misc/ftdi-elan.ko

However, the particular PCI version of that module/driver does NOT appear to be set up:
$ modinfo ftdi_sio | grep usb:v0403pFD4A returns nothing.

I started trying things on my on. I report what I did here, in hopes you may spot something indicative of the problem area.

First, following part of the other thread, I tried
$ insmod ftdi_sio
insmod: ERROR: could not load module ftdi_sio: No such file or directory

Then I tried
$ modprobe ftdi_sio vendor=0x0403 product=0xFD4A
libkmod: ERROR ../libkmod/libkmod-config.c:686 kmod_config_parse: /etc/modprobe.d/usbserial.conf line 1: ignoring bad line starting with 'insmod'

I guess that the bad line it refers to is insmod ftdi_sio, in the usbserial.conf file that the other thread instructed to create. So I deleted that file which I had made.

Try again:
$ modprobe ftdi_sio vendor=0x0403 product=0xFD4A
This time, no error.

But
$ modinfo ftdi_sio | grep usb:v0403pFD4A
still returns nothing.

I unplug the USB and wait 10+ seconds.
$ dmesg | tail
[18232.421669] ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected
[18232.421728] usb 2-1.1: Detected FT232RL
[18232.421733] usb 2-1.1: Number of endpoints 2
[18232.421736] usb 2-1.1: Endpoint 1 MaxPacketSize 64
[18232.421740] usb 2-1.1: Endpoint 2 MaxPacketSize 64
[18232.421744] usb 2-1.1: Setting MaxPacketSize 64
[18232.422182] usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB1
[18292.539472] usb 2-1.1: USB disconnect, device number 14
[18292.539801] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[18292.539842] ftdi_sio 2-1.1:1.0: device disconnected

Plug it back in and wait again.
$ dmesg | tail
[18412.765192] usb 2-1.2: Product: ShipModul MiniPlex-2Wi
[18412.765195] usb 2-1.2: Manufacturer: CustomWare
[18412.765199] usb 2-1.2: SerialNumber: 25001350
[18412.768771] ftdi_sio 2-1.2:1.0: FTDI USB Serial Device converter detected
[18412.768824] usb 2-1.2: Detected FT232RL
[18412.768828] usb 2-1.2: Number of endpoints 2
[18412.768832] usb 2-1.2: Endpoint 1 MaxPacketSize 64
[18412.768835] usb 2-1.2: Endpoint 2 MaxPacketSize 64
[18412.768838] usb 2-1.2: Setting MaxPacketSize 64
[18412.769591] usb 2-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

Woohoo! that looks like it might be progress. I start up OpenCpn (3.2.2), click on Tools / Connections, create a new serial connection with /dev/ttyUSB0, 115200 baud, and wait to see the new sentences scrolling by in the NMEA debug window, the way they did in the Windows system when I did it last night. Nix, nada, nothing. (At this point I ask myself, why am I doing this, vs just running it on Windows? Answer: because of all the other great SW bundled in with NX, which I assume is not available as free/open source in Windows.)

$ modinfo ftdi_sio | grep usb:v0403pFD4A
still returns nothing.

What are your next recommendations?

Any chance we could get together real time, maybe via vnc or teamviewer, and work it through?

Thanks -


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
Quote:
When I $ lsmod | grep ftdi, the result agrees; it seems to be there:
It is there. Reboot your machine without the Miniplex.

It's not there.

Well, it's not there on an 'out of the box' system. Although the file is sleeping at /lib/modules/<kerenel_ID>/kernel/drivers/usb/serial/ftdi_sio.ko, it is not loaded until needed. But you said, upon the recommendation of the device vendor, you modified your system to load the ftdi_sio module everytime.

So regardless of how successful that modification was, the module is loaded when the MiniPlex is inserted into the system if not for the entire time the system is running.

We know the device hotplugs.

udev says, "Hello, gizmo. There is various minutia known about you. You're assigned to /dev/whatever_I_thinkitshouldbe0....Next!"

I think the next step is to contact the vendor and say, "Ok. I did that. The vanilla module loads into a vanilla filesystem. The device is recognized...Now what?"

It's private and you don't have to associating with or take advice from riffraff, drunks, or dummies on the internet for something 1) they haven't tested, 2) don't own, and 3)provide no guarantee the advice is any good. The vendor, on the other hand, aside from having your money, should have an idea how the damn thing works, and works in a stock Linux setup.

When chasing troubles through the web of possibilities I find it bit odd reading anything I have written in the past, 1) that while it might sound good, I don't remember how I got there, or 2) if I do remember, I'm shocked by my lack of imagination, but pleased, while limited, I'm at least consistent.

I don't think the system cares if it's an external drive with a cure for cancer, or one of those USB missile launchers that shoot foam missiles off your desk. If the system knows what to expect, it will ship data in most any form until the cows come home. The proper setting might even make the data usable.

Aside from the feed back from udev, and our pal at ShipModul, the MiniPlex is a black box.

Is the speed 115.2K, or 57.6K? Is it fix or negotiable? Does it deviate from a traditional 8, 1, None protocol? Anything else missing? Is there any intelligence, or is it just hardware? Have I made a typ0? How is the MiniPlex delivering the data?

To exclude configuring OpenCPN wrong I would want to see what is coming out the pipes.

Remember, it is vanilla on vanilla. For simplicity, check that none of the previous 'experiments' as squireling your efforts. At the moment, we are only looking for gps data, and gpsd has been killed. We should see a smudge of something.
Code:
dmesg | tail
to make sure you're hitting the right device.

Adjust the following to suit
Code:
stty raw -echo < /dev/ttyUSB1; cat -vte /dev/ttyUSB1
If you get permission errors
Code:
sudo -s
and then
Code:
stty raw -echo < /dev/ttyUSB1; cat -vte /dev/ttyUSB1
^C kills it.

Any output?

Something like:
Quote:
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
or
Quote:
^f^X^X^^M-`M-^XM-^XM-`M-^XM-^X^^^F^XM-^X^XM-^F^^^XM-xM-^X^XM
still means data, just some settings are wrong.

Kill it. Try
Code:
sudo gpsd /dev/ttyUSB1 -F /var/run/gpsd.sock
take a quick look at
Code:
xgps
Anything interesting?

Kill it (^C). Kill the gpsd.
Code:
sudo killall gpsd 
Code:
sudo rm /var/run/gpsd.sock
return to
Code:
stty raw -echo < /dev/ttyUSB1; cat -vte /dev/ttyUSB1
Any change?

The accepted convention is, user terminals are indicated with $, super user are indicated with #
Quote:
moe@io:~$
as opposed to
Quote:
root@io:~#
Portraying a command that takes super powers but without sudo behind a $ only leads to confusion.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
per vendor and manual this model's host port (usb to serial) is 115.2k not 57.6k. 8,N,1, no xon/xoff. Previous post's model was not a -2 version, but mine is. We both have usb host ports but maybe my mux is a newer version (it is the latest variant, and also differs in that it has the WiFi output.)

Followed your instructions (substituting /dev/ttyusb0 for 1)
nothing on the raw view of its output.

when I did the gpsd and xgps commands, the class that xgps showed (with the mux UNplugged) was something like {class:...blah blah.../dev/ttyusb0}.

when I did the same routine with mux plugged in, it said :
{"class":"VERSION","release":"3.9","rev":"3.9","proto_major":3,"proto_minor":8}
no idea if that's significant, but it's different and doesn't relate to a /dev/ttyusbanything.

no response on any of the attempts to directly view raw output. i double checked the physical connections.

no response when i went into opencpn and tried it, either on serial or network (udp or tcp.)

The only other thing to report is, not immediately but after a few minutes, these messages appeared (mux plugged in.) Gibberish to me. Isn't cups something to do with printer?
$ dmesg | tail
[ 2142.239750] type=1400 audit(1429518754.284:49): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=4103 comm="apparmor_parser"
[ 2142.241354] type=1400 audit(1429518754.284:50): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=4103 comm="apparmor_parser"
[ 2440.720443] perf samples too long (5022 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 2593.446595] ttyS0: LSR safety check engaged!
[ 2658.359004] ttyS0: LSR safety check engaged!
[ 2704.176224] ttyS0: LSR safety check engaged!
[ 2718.996946] ttyS0: LSR safety check engaged!


I have seen the highlighted messages here before. No idea whether any of the above messages are related to the mux; if i unplug-wait-replug and dmesg again, they didn't reappear within 10-15 mins of checking.

I know the device is working, receiving from talkers, and outputting on its talker port, because it works in the windows version of opencpn. i am dual-booting so i know it's not defective usb port on the laptop.

you made a good point about checking if any of the earlier twiddling I did broke something - may have. I am going to go back and try to (find and) undo everything I can. unfort i did not start taking good notes about what i changed until later... face-palm.

Wait... it (nmea output) is NOT working on the windows side of things any longer. sign. Yesterday, when I got it working, i pulled apart my test rig (temporary wires running here and there across the boat, between installed systems), and pulled stp cabling for a permanent installation. Hooked the mux back up last night, and made a couple of quick connections. I must have botched an instrument connection. Let me make some permanent connections, then I will test again and report back, probably in about 24 hours. In the meantime, anything in the post above may be invalid.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
Once you get it back on line, give previous a go, because there's less involvement.

But...have you tried the solution in the URL you gave?

Also carefully read again through the other thread by another guy with a similar model MiniPlex mux.

Belle-Isle showed a way to assign parameters to a device. For example, you plug in a gizmo, if it matches a vendor/product, don't use default values, use these, X,Y,Z, and this is it's unique name.../dev/rocket_launcher.

Now, it just so happens, anytime, anything you plug in with X vendor/product id will have a pre-set interfce , and be called /dev/rocket_launcher rather than ttyUSB1...or whatever.

I know, it gets pretty exciting when something that awesome is available. This ability alone keeps many drunk with power up at night. The thought can be frightening.

Did you try that?, using the code as a template for your situation...and what happens when look at it via,
Code:
stty raw -echo < /dev/awesome_gizmo; cat -vte /dev/awesome_gizmo

...and gpsd is still dead and buried.

Although to automate the whole show, rather than create that file 98gps, or whatever, create the following to /etc/udev/rules.d/99-ftdi.rules:

Code:
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="fd4a", ACTION=="add", SYMLINK+="miniplex", RUN+="/bin/stty -F /dev/miniplex 115200",  RUN+=”/sbin/modprobe ftdi_sio”, RUN+=”/bin/sh -c ‘echo 0403 fd4a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id’”
This removes the gpsd hotplug thingy, and adds the vendor/product ID insert, and runs the modprobe insertion...and I hope order isn't important, or the "RUN" commands are in the right order of execution, and you can name it what you will.

Someone at Navigatrix's international office in Panama would be willing to test or review any ShipModul units they would give to a crew member. I'm not interested, but there might be a few others who would. Just think of the integration, the wifi is also an access point, a communication centre for data sources.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Moe (et. al.),

I pulled cable (fun in a 35 year old sailboat) and installed the mux properly. Soldered and heat-shrinked the couple of splices where connections were not terminal to terminal. et voila! All the instruments are talking to each other. That thing is like the Dr. Doolittle of the electronics world.

Under Windows (I hate to keep saying that, because I'd set out to get entirely off of it), the vendor's utility app and OpenCpn can both also see the NMEA traffic from it just fine, over both the USB and WiFi host ports. So, it works.

Under Lubuntu/Navigatrix, I have not had the chance to go back and try to get it going yet - no time left this week. I had to leave the boat, but will be back over the weekend. I would like to get it figured out, for no other great reason than stubbornness. I will clean up my install and start fresh - maybe just do a clean re-install of Navigatrix to be sure. I will come back to the thread once its ready and I have access to the gizmo again.

Cheers for now.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Hi Moe,

I would still like to get the ShipModul MiniPlex working via USB with Navigatrix. (It is working fine via WiFi in Navigatrix, but that can't be used to configure it directly, just listen to it.) And of course as said before, it works in Windows.

Today I got an email from the ShipModul maker, saying another customer told them that a Linux user should issue the following command (linux kernel 3.12 and higher):
Code:
echo 0403 fd4a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id


I was unable to do that successfully, either as standard user or with sudo. "Permission denied." I then tried su to get root, but could not. My password would not authenticate, and it has me wondering if I have even created an admin user, but that's a different topic...

thoughts?


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
The sudo is working for the echo, but the redirect (>) also needs superpowers, but can't be shirt-tailed in for security reasons. Sometimes, as with compound commands, it's easier to "step into the role" of root with
Code:
sudo -s
and then the command, rather than just issuing sudo commands, as in the following
Quote:
wadda@glenda:~$ echo 0403 fd4a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
-bash: /sys/bus/usb-serial/drivers/ftdi_sio/new_id: Permission denied
wadda@glenda:~$ sudo echo 0403 fd4a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
-bash: /sys/bus/usb-serial/drivers/ftdi_sio/new_id: Permission denied
wadda@glenda:~$ sudo -s
[sudo] password for wadda:
root@glenda:~# echo 0403 fd4a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
root@glenda:~#
root@glenda:~# exit
exit
wadda@glenda:~$
Notice the change in user id and prompt termination (#). You can do significant damage to the system as root. This is a reason why it's advised to not stay as root. You can then exit when finished.

Password authentication failure is most likely from a typo.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Thanks. Really embarassing question, but is the su password in navigatrix preset? I don't recall creating an admin user.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
Umm, not really. Via the LiveCD the default user is nx. nx appears password free because of work through visudo and sudoers. Both fun and exciting I just don't have time to go over them right now.

When you install the system on a hard drive you select a password. The installed user has sudo access...if you know the password, and you're off to conquer and destroy

There isn't really anything like an "admin" user, even though if you execute sudo users-admin "Account Types" can be changed to Administrator. (Just to confuse people.)

There are really only various levels of permissions. X user is relegated Y set of permissions. Permissions can be assigned to groups and members of that group, etc... Every aspect is tailorable and customizable, generally not, but the possibility exists. It can be a very complex world of users, groups of users, and permissions for individual users and group.

The one user who rules them all is root. Root can even implement impediments, or safeguards, to it's own power (e.g., sticky bits, ..:: home ::.. on the Desktop), but root can do or change anything. Other users, or groups of users are limited depending on the configuration.

99.44%, or more, of anything you want to do on a system can be done with escalated privileges, (sudo, gksudo, pkexec, etc.)

Using sudo you can assume the role of root. You can 'pretend' to be root. You can do everything that root can do, command prompt and everything, but you cannot log in as root, as the root password is not set by default. (It's a security thing apparently, again, just to confuse people.)

A root password can be set with
Code:
sudo passwd root
....but isn't necessary. sudo will do what you need to do.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Notes to self from research. I'm not at the boat and can't test yet...

Try 0:
Rationale: It's what the vendor said to do. (Admittedly they don't do Linux however.) The file /etc/modules configures which loadable modules are utomatically loaded. Apparently you can pass parms through the lines in this file. Put ftdi_sio explicitly in this file and pass the VID/PID info to it so that it's built this way into the kernel at load time:

edit /etc/modules to add a new line, "ftdi_sio vendor=0x0403 product=0xfd4a"
reboot

I've done this, and it works. The module is loaded with the correct VID and PID.
But the system doesn't appear to go on to recognize it as a USB serial host and create /dev/ttyUSBx

I read in linux 2.6.x kernel faq about USB that I might need to
$ mknod /dev/usb/ttyUSB0 c 188 0
so I will try that.


Try 1:
Moe explained that gpsd is a pretty comprehensive mux in the system, and that it might even be able to handle some of the non-GPS nmea sentences. So I should try to get the hw mux talking to gpsd, once I've got it talking usbserial.

I read on the gpsd site that the following should do it.
$ sudo gpsinit -s 115200 ftdi_sio /dev/ttyUSB0
I tried it (without access to the particular usb mux we're working on) and got an error saying "no such file" or something like that, about gpsinit. Maybe Moe can shed some light on the right way to do this?


Try 2:
Rationale: this is what another user told the vendor they do. I have no idea what it does.
echo 0403 fd4a > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Tried this before, and it appeared to 'work', i.e. there was no error, but I don't know what 'working' is. It didn't make anything like /dev/ttyusbx appear...


Try 3:
Rationale: change something in the device driver source file itself, that gets compiled into the kernel. Look in /lib/modules/`uname -r`/kernel for a relevant file *.o. Scrutinize that file and identify where the VID/PID are assigned, or where they could be. Assign them appropriately using VID 0403 and PID fd4a.

Tried to find the *.o file. There aren't any, that I could find.

For someone who hasn't been playing with linux during its evolution over the past 12+ years, googling to try to find a relevant approach is like playing Battleship. Instead of calling these 'Try 0', 'Try 1', etc., I should be saying 'E,4'! 'G,7'!


Try 9:
Rationale: This is what a developer for a company that makes a product using the FTDI chip whose usb interface acts as a virtual com port says (my paraphrase): the ftdi_sio driver is probably being loaded automatically. Since that's bound to a particular product id (not same as mine, but same vendor id), once it's bound, you can't access it. So let's unbind it. You can always just '$ sudo rmmod ftdi_sio', followed by
'$ sudo rmmod usbserial', but that's a blunt instrument. Instead, make the system differentiate between various FTDI devices using the product name defined in the USB descriptor. Once the product named "PRODUCT_NAME" is detected, the shell command below is run, which will effectively unbind the ftdi_sio and your USB device.

create new file /etc/udev/rules.d/ftdi_sio_ben
In that file put the following (all one line):
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="fd4a", ATTRS{product}=="PRODUCT_NAME", RUN+="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/ftdi_sio/unbind'"
(where "PRODUCT_NAME" is the product name defined in the USB descriptor - probably "ShipModul MiniPlex-2Wi".)

On reflection I can see where this might be a half-step, but since we're not trying to bind ftdi_sio to a particular driver (heck, I just want it to bind to *any* driver that will enable it to function as usb serial), this might not solve the problem.

Aside: To view information about a module, use modinfo:

$ modinfo st
filename: /lib/modules/2.4.20/kernel/drivers/scsi/st.o
description: "SCSI Tape Driver"
author: "Kai Makisara"
license: "GPL"
parm: buffer_kbs int, description "Default driver buffer size (KB; 32)"
parm: write_threshold_kbs int, description "Asynchronous write threshold (KB; 30)"
parm: max_buffers int, description "Maximum number of buffer allocated at initialisation (4)"
parm: max_sg_segs int, description "Maximum number of scatter/gather segments to use (32)"
parm: blocking_open int, description "Block in open if not ready an no O_NONBLOCK (0)"


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 04 Nov 2010, 20:51
Posts: 1062
I think you're working too hard.

When the system is running, open a terminal (<ctrl><alt><t>, all three keys at the same time) take a deep breath and plug in your USB converter.

USB converters should work out of the box. This is the first step to see what the system sees.

Into the terminal window, enter
Code:
dmesg | tail -n 20 > ~/Desktop/miniplex_message

This gives the last 20 entries of the log file into a text file (miniplex_message) on your Desktop.

Attach that exciting file to a reply post, so we can see what is going on.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
Thanks Moe. Just as soon as I get back to the boat (probably Saturday) I will respond.


Top
   
 
 Post subject: Re: ShipModul MiniPlex-2Wi

Joined: 30 Oct 2014, 17:01
Posts: 21
file with last 20 lines in tail of dmesg attached as requested.


Attachments:
miniplex_message.txt [1.39 KiB]
Downloaded 355 times
Top
   
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2  Next


Search for:

Credits © 2010 - 2024