best linux to run ts

[OrangeAlpine]

So, I've been able to get Tuner Studio installed in LinuxMint, (Ubuntu even) but no matter what linux disro I use, it can NEVER find my Megasquirt using the USB Controllers, any help or suggestions on how to get the 2 computers to talk to each other!?

[piledriver]

I have not had much luck using the "auto detect" button, but the pull down list of USB devices is usually quite short and predictable, and it remembers if you have made a good connection and shut down normally.

I use a Microconnectors dual USB (with a cable saver male<>female) at the end with pin 9 broken off as the 5v I wired out on the db connector to feed a BT adapter seems to blow up the microconnector adapters for some reason)

My Gobi4000 is always /dev/ttyUSB0-ttyUSB2, so the usb serial adapter is always /dev/ttyUSB3/4
(or 4/5 if i unplug/replug while TS is running)

[OrangeAlpine]

I've never been able to use autodetect either... But I'm not using it. I've imported a tune that I had saved from a different (windows) computer. I've tried all the different USB connecters in the communications menu, and it can never find a valid communications port. (not using autodetect.)

I'm not sure what this part of your reply is about "My Gobi4000 is always /dev/ttyUSB0-ttyUSB2, so the usb serial adapter is always /dev/ttyUSB3/4
(or 4/5 if i unplug/replug while TS is running)"

Could you enlighten me?

Long time linux user, just apparently not hard core..

[jsmcortina]

Detect works ok for me?

Did you follow the part of the manual where it tells you to ensure you username is added to the required "groups" to gain access to the serial ports?

James

[piledriver]

Detect works ok for me?

Did you follow the part of the manual where it tells you to ensure you username is added to the required "groups" to gain access to the serial ports?

James

I have seen autodetect work... but usually not.

I have had to fight with a bit when importing a tune from Windows IIRC. (have used TS Windows occasionally to check for comms software vs hardware issues, or perhaps just to justify the space it still takes up on my hard drives)

If the pull down doesn't show /dev/ttyUSBx at all,
then its a permissions issue.
On older distros (perhaps also most LTS) user needed to be member of dialout and uucp.
Modern distros (usually using systemd for init) user needs to be member of lock group, dialout and uucp also if exists.

The Gobi 4000 is a 4G WWAN card that creates 3 USB serial ports on module load//initialization. (1 data I/O, one control port, and one for GPS)
so it creates /dev/ttyUSB0/1 &2 prior to the external USB serial adapter. (internal mini-pcie card)

[OrangeAlpine]

Where do we find the permissions? Earlier in this thread, I have read that with the jssc (a 232 protocol) we do not need permissions. We plugged in an RS 232 adaptor. The computer sees it as a 232 usb using the lsusb command. Jump drives also work. We can see the jssc protocols but they are not accepted, do not see a /dev/ttyUSBx. (when I login as su and look at the /dev all I can find is a ttyUSB0, no more) I do not know how to get the permissions that have been mentioned.

Guidance is appreciated. When/if we get the permissions, which you recommend the USB direct, or the 232 with adaptor?

[piledriver]

Theoretically you don't need it with jssc, but I have not found TS to work right without the user being a member of lock, and I use the jssc driver. JSSC seems faster and much more reliable vs the std rs232 driver.

If you don't see the devices when logged in as root the adapter is a probable issue.
What device is /dev/ttyUSB0?

type dmesg |less to see the kernel boot log (and be able to scroll around/search using the less viewer)

There are several easy ways to set user/group permissions up, what distro are you running?

Under Debian/ubuntu/Mint flavored distros you have to install a gui program unless you want to manage it from the command line.
(I once knew all he commands for that, but its too easy to use the guis if its a local box)

If using kde on Mint you install kuser and it shows up in the KDE control panel.

I'm certain there are equivalents for the other available desktops.

which you recommend the USB direct, or the 232 with adaptor?

??? What are you trying to connect to, exactly?
MS3 has a built-in FTDI USB<>serial adapter that is excellent.
Otherwise you need an external USB adapter, FTDI units are common and highly recommended.
If you have to run an extension, use a serial cable for the long run, don't extend the USB cable, a lot of the USB extension cables are flake.

If you need a long USB cable to use an MS3s setup, buy the $5 cable rather than the $2 cable.

[OrangeAlpine]

I am using Cinnamon on Mint.

Trying to connect to MS3, both USB and Serial 232. Which do you suggest, the 232 or directly with USB?
when I type in find -name "ttyUSB0"
./pci0000:00000:00:ld.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0
./pci0000:00000:00:ld.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0

when I type in find -name "ttyUSB1"
./pci0000:00000:00:ld.0/usb1/1-1/1-1.1/1-1.1:1.0/ttyUSB1
./pci0000:00000:00:ld.0/usb1/1-1/1-1.1/1-1.1:1.0/ttyUSB1/tty/ttyUSB1

When I type in "lsusb" i get
Bus 001 Device 003: ID 0bda:57b5 Realtek Semiconductor Corp.
Bus 001 Device 013: ID 0403: 5001 Future Technology Devices International. Ltd, FT 232 USB-Serial (UART) IC
Bus 001 Device 014: ID 0403:6001 Future Technology Devices International. Ltd FT 232 usb-Serial (UART) IC
Bus 001 Device 002: ID 8087:07e6 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Is this of any help in determining what is on USB zero??

[piledriver]

/dev/ttyUSB0 is the MS3, and if you have a decent USB cable for it, use it.
(Most USB printers use the same cable)
Both the MS3 and your second adapter are FTDI: Good.

You can only connect one serial adapter at a time, both the onboard FTDI and the serial port access the same pins on the CPU, so it causes neither to work if both are physically connected.

Have you loaded the firmware yet?

[OrangeAlpine]

Thanks for the info, good to know the two computers see each other. Firmware was loaded into Megasquirt using XP, but that computer has become unreliable. The two port hookup was done only to query the system. I have never tried to communicate with MS using both adaptors.

How can I get Tuner Studio to register USB zero as a valid communication port?

I have never been able to find any Manual addressing Linux installations or any place to register in a lock group. I am thinking this is perhaps the heart of my problem. I am registered as a Tuner Studio and Megalog user. I do not use the Lite version.

Linux sees the MegaSquirt, but Tuner Studio does not see MegaSquirt. How do we bridge the gap?

Bill

[piledriver]

The permissions we are discussing are local--- settings on your tuning computer.
Exactly what version of Mint and what desktop environment are you running?

The command line utilities are relatively easy to use already installed, see http://www.cyberciti.biz/faq/howto-linu ... -to-group/

sudo grep lock /etc/group will for example list members of the group "lock"
sudo useradd -G username will add username to lock group.

The fact that you can even see the usb serial port (/dev/ttyUSB0) in TunerStudio indicates that the issue is possibly something else.

Turn on "debug log comm" in tuner studio (communications>debug log comm) and try again, it will create a file in your home dir that lists every step TS takes to communicate with any errors.

Have you created a new project yet?

[OrangeAlpine]

Running Linux Mint 17.1 'Rebecca' with 64-bit Cinnamon desktop.

There are no members in a "lock" group. I can find no evidence of a "lock" group, until I created a "lock" group... then added myself to it... I am now the only user in "lock"
Since I've added myself to the "lock" group, I've not been able to use the command find -name "ttyUSB0" or "ttyUSB1" it now says Permission denied.

I have never been able to see /dev/ttyUSB0 in tunerstudio...
Under Communications/settings I have
Driver: USB and wireless selected
Connection type: FTDI - D2XX driver
Connection Settings: Device Serial #: Auto
Baud Rate: 11520

I've not been able to create a new project, since it can not find any MegaSquirt computers. I can copy the last few attempts of the data comm log if you would like to see it:

7/5/15 6:31:09 PM :Debug: Port not valid: Unable to open device: D2XX error, ftStatus:DEVICE_NOT_FOUND, None
Jul 05, 2015 6:31:10 PM com.ftdi.FTDevice getDevices
INFO: Found devs: 1 (All:1)
7/5/15 6:31:10 PM :Debug: Opening Connection to FTDI Device: USB D2XX, Serial # @ 115200 Baud
Device: FTDevice{devDescription=, devSerialNumber=}
Device Type: DEVICE_UNKNOWN
Device ID: 0
Device Location ID: 0
Jul 05, 2015 6:31:10 PM z.c f
SEVERE: null
com.ftdi.FTD2XXException: D2XX error, ftStatus:DEVICE_NOT_FOUND
at com.ftdi.FTDevice.ensureFTStatus(FTDevice.java:146)
at com.ftdi.FTDevice.open(FTDevice.java:327)
at z.c.f(Unknown Source)
at f.o.h(Unknown Source)
at f.p.run(Unknown Source)


Thanks

[piledriver]

What happens running TS as root?

You can create a new project offline, no megasquirt required.

I'll reinstall Mint 17.1 (KDE) again to help work through this, but you may find Mageia 5 would be easier.
The hack job that is the Cinnamon desktop may be part of your issue.

I suggest upgrading to a recent kernel, the default 3.13 is ancient history in Linux time.
3.19.0 is installable which is only a few months old, has many bugfixes and newer drivers.

Mint 17.1 is based on the latest "stable" LTS of ubuntu, which means its full of mostly 2 year old versions of everything.
It doe not have a lock group, user must be a member of "dialout" and "uucp" to even see the serial ports..

There will still be some issues as you have to "own" the /dev/ttyX lockfiles for TS, there is an osX script in the TS distribution that shows how.
A current distro that has a "lock" group eliminates all that unreliable futzing around.
(LTS anything is gnome user manager a "current" distro)
Install kuser or the gnome equivalent to do user mangement.
Gnome Control Center probably has something.


Mageia has decent well integrated GUI system management tools Ubuntu//mint sorely lack.
(Its all I use anymore, although I tried Mint 17.1 and several other recent releases, all had operational issues)
IIRC Cinnamon is an installable desktop in Mageia 5, but I am not inclined to use it.

Mageia also defaults to grub "legacy" so you can install its boot loader to the root partition, and just load it with a simple entry like Windows.
(Grub "legacy" has an easily human readable configuration file unlike grub2, which hides most of its logic in hidden scripts you dare not edit)

The main isue with Ubuntu-derivatives incl. Mint is they always reformat the swap partition on install (for no apparent reason, and without asking) which gives Mageia heartburn for some reason. Just don't select a swap partition on install if you decide to install Mageia.

If the machine is new enough you might sign up for and load the Win10 "insider" previews, the latest isos work well.
It works great on my 6 year old Thinkpads.

I have Mint 17.1 (KDE) installed again, and added my user to the uucp and dialout groups. and logged out/back in for it to take effect.
Next post will be from tuning laptop.

edited for spelling.

[piledriver]

On an "old" distro like Mint 17.1 (LTS ~=2 year old versions of all software-based) you still have to do one more permissions fix...
(I have personally never found an upside to running 2 year old version of any software, or that an LTS or "stable" release to be any more "stable" that bleeding edge distros except for very short lived hiccups---many things never get fixed in LTS releases)

You need:
sudo chgrp uucp /var/lock
sudo chmod 775 /var/lock

This changed the ownership of the /var/lock directory as needed so TS can use the serial lockfiles as it has to.
You may also put same in /etc/rc.local (but omit the sudo)

On a current distro (Mageia 4/5, fedora/SUSE/current non-LTS Ubuntu, basically anything using systemd) there is a lock group that owns /run/lock that you must be a member of. (/var/lock no longer exists, or is just a symlink for compatibility)

EDIT:
Mint17 must be transitional as /var/lock is just a symlink, so the above commands must be:
chgrp uucp /run/lock
chmod 775 /run/lock

add that to /etc/rc.local before the exit 0 line, save and reboot.

Then try tuner studio again.
JSSC works better for me, have yet to see the FTDI user space driver to work on Linux.

[piledriver]

I didn't copy any of the registration files over to the fresh Mint 17.1 install, or reuse my usual home dir in order not to "inherit" any possible configuration hints or such.(to be certain of a clean run at it as you have)

I had to use the std rs-232 drivers in Tuner Studio "lite" mode.
(which have been very iffy at times)

Connected right up, even used "search for device".
Using 3.19.0 kernel, and MicroConnectors dual serial USB adapter (with pin 9 broken off on a connector saver, as the 5v I added on pin9 to power BT seems to blow the adapter out randomly)

So
1)make certain your user is a member of "dialout" and "uucp"

2) add
chgrp uucp /run/lock
chmod 775 /run/lock

to /etc/rc.local

save
reboot
Run tunerstudio.
Strongly recommend using "usb and wireless>JSSC" driver in registered TS.

[LT401Vette]

Strongly recommend using "usb and wireless>JSSC" driver in registered TS.

Glad to hear that. In the next major release RXTX has been removed by default and JSSC is the default RS232 driver.

[piledriver]

Strongly recommend using "usb and wireless>JSSC" driver in registered TS.

Glad to hear that. In the next major release RXTX has been removed by default and JSSC is the default RS232 driver.

I get perfect reliability and ~30% boost in updates per second with JSSC vs. std RXTX serial.
RXTX once worked well, but hasn't had an upstream maintainer in ages.

Sadly the "no permissions required" aspects of both RXTX-nolock and (iirc) JSSC seem not to work out in practce, but on modern distros all you need is to be a member of "lock", "uucp" and "dialout", and I'm not sure you even need "uucp" and "dialout" anymore, haven't tried it that way. (having "lock" group member might be all thats required on "current" distros, will test this on Mageia 5)

Note all the "fixes" in this thread are essentially based on the TunderStudio documentation and included script for OS X, with only very minor adaption for the path and group changes in recent Linux distros.