ALDL in Linux with TunerPro RT - How to guide

160 And 8192 Baud Aldl
User avatar
vlad01
Posts: 8548
Joined: Mon Oct 08, 2012 8:41 am
cars: VP I S
VP I executive
VP II executive
VP II executive #2
Location: Kyneton, Vic

ALDL in Linux with TunerPro RT - How to guide

Post by vlad01 »

Hi all.

I thought this might interest a few people, I attempted to try figure a way around getting the ALDL working within TunerPro RT under Linux (I run Mint which is a distro of Ubuntu) without resorting a clunky and resource hungry VMs just like my main solution was for a while. I used VirtualBox, which I got working but it was no walk in the park with the UBS side of things and additional packages needing to be mounted and installed within the VM, and requires all other stuff to be closed on the Linux host, or otherwise the windows machine became so slow that you couldn't even move the mouse without a 5 min delay (not actually joking :comp: )

So I present you with this how to guide :thumbup:


I figured out a way to do it with the use of the AI chat and help from Ant, who provided me with a unreleased version of OSE, 3.0 that is still more or less experimental and has not been verified on the later models and all scenarios. But for this it was a key part of making this all work, and as far as I could test, it all worked perfectly so far!

With the permission from Ant, I provide a copy of the OSE 3.0 in the form of the plugin dll only. DISCLAIMER! as mentioned, this is not fully tested and may break shit!
Download for the dll is at the end of this post.

To use it, replace the current OSE 1.8 dll in the TP plugin folder, just make sure you save the old one first, just in case you need to revert.

Some of the issues that prevented ALDL from working properly was the hard coded timing routines within the 1.8 and older versions of OSE. 3.0 is rebuilt with a different approach that to my understanding has a much more dynamic and adaptive set of timing routines. This allows additions layers to be able to sit between software and hardware that add their own latency penalties, without causing a breakdown in the timing that OSE 1.8 and older suffered.

Since the newer OSE is much more flexible, it can compensate for these sort of things, such as those exact layers I was dealing with, emulation of a windows program within linux and different layers of driver handling since linux and windows do it their own way very differently. This would trip up the plugin's timing and it would immediately error for anything that was two way like uploading/downloading, real time editing and verifying cals. However, simple data logging worked ok as it was just a downstream thing.

The OSE 3.0 plugin was actually the last problem I needed to solve the issues, the first one was getting linux to run the ALDL adapter at the correct 8192 baud in the first place, the other issue was figuring out how to get TP to see the ALDL as a com port, when com ports aren't really a thing in linux, at least not through a USB adapter since it is a virtual port under windows from my gist of it, but linux is just a as it is, a serial adapter.


The actual guide now:

I won't go into every step in detail, since A. I can't be bothered, B. linux people know what to do and I am dumber than most of them, C. you can google it, or AI it, that's what I did. D. I don't remember half the shit I do after 5 sec.

Usually the ALDL FTDI chip comes up at /dev/ttyUSB0, sometimes it maybe a 1 instead of 0. Google the terminal command to sus out what your adapter comes up as in linux.

Also a good idea to look at the other parameter too while you're at it, the base number or clock will be important, but it's almost always 24,000 for our adapters.


Mine was /dev/ttyUSB0

This needed to be mapped within wine where TP was being emulated in. I actually use Crossover which is wine but in self contained bottles as they call them, so this step may differ.

I mapped the com port and number within the windows environment to tell windows where/what who? the com port is in relation to the external device as linux sees it.

This two screen shots have all the details.

You basically add a string value named COM3 in the registry that tells all software within the wine bottle, that com3 is actually /dev/ttyUSB0 in linux. Set the value as such.

I used com3 as TP started with that number as the default, and for some reason com1 spazes out and changes to com11 every time the settings in TP preferences are closed. You can chose any other arbitrary number, I had com all the way to 20 something. All worked except com1, so it's probably a bug in TP.



Screenshot from 2026-09-02 12-45-14.png
Screenshot from 2026-09-02 12-46-09.png


Ok, next I am going to paste a bunch of commands and AI's comments on each of them, that you run in the terminal, curated by the AI chat which then I compiled into a sort of sequence that worked for me, and leaving out all the junk that wasn't needed.

I actually know some of the order doesn't matter. The last two commands might be able to be tossed together, but I ran them one by one since I wasn't sure if that works going by how AI had them together. Someone can comment on that.

There were a few mistakes, the divisor to force the 8192 baud was wrong, so I fixed it to the correct 2930, it gave me 14 for some reason.


The next lot of commands I found allows you to make a custom rule for that adapter, so that every time it is plugged in, regardless of the port, the rules will automatically set a custom divisor to run the adapter at the 8192 baud, since TP is unable to do that through wine.



---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



"Even if you can see the device in Linux, CrossOver running under your user account might not have permission to read/write to the raw hardware serial port.Open your Linux terminal.Run this command to grant your user account access to the serial hardware group:"

bash

Code: Select all

sudo usermod -a -G dialout $USER
"(Note: If you are on Fedora, Arch, or openSUSE, the group might be called uucp instead of dialout, so run sudo usermod -a -G uucp $USER)Crucial: You must completely log out of your Linux desktop session and log back in (or restart your computer) for this change to take effect."



---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




"You need the vendor ID and product ID of your specific adapter so Linux doesn't accidentally apply this rule to other USB devices (like a USB mouse).Plug in your adapter.Run this command:"

bash

Code: Select all

lsusb
"Look for your FTDI device. It will look something like this:Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) ICNote the ID numbers. In this example, 0403 is the vendor ID and 6001 is the product ID."



---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




"Open a new configuration file in your system's rules directory using a text editor (like nano):"

bash

Code: Select all

sudo nano /etc/udev/rules.d/99-aldl-ftdi.rules


---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



"Paste the following single line into the file (replace 0403 and 6001 with your actual IDs if they are different):"


Code: Select all

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/usr/bin/setserial /dev/%k spd_cust divisor 2930"

"(Note: %k is a dynamic placeholder that automatically changes to ttyUSB0, ttyUSB1, etc., depending on which port the system assigns).Save and exit the editor (in nano, press Ctrl+O, Enter, then Ctrl+X)."



---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



"Tell Linux to load your new rule immediately without needing a system reboot:"

bash

Code: Select all

sudo udevadm control --reload-rules
bash

Code: Select all

sudo udevadm trigger


---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



And here is the OSE 3.0 plugin as the dll only, with the permission from Ant. It's experimental, read the notes at the top of the post.
OSEPlugin_3.0.zip
You do not have the required permissions to view the files attached to this post.
Last edited by vlad01 on Wed Sep 02, 2026 4:30 am, edited 1 time in total.
User avatar
antus
Site Admin
Posts: 10012
Joined: Sat Feb 28, 2009 10:34 am
cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007

Re: ALDL comms in Linux for TunerPro RT

Post by antus »

OSE Plugin is very old code, and has hard coded timeings. So it is sensitive to the kinds of delays emulation layers will add. These days with AI it could probably do with a re-write to make it more tolerant.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
vlad01
Posts: 8548
Joined: Mon Oct 08, 2012 8:41 am
cars: VP I S
VP I executive
VP II executive
VP II executive #2
Location: Kyneton, Vic

Re: ALDL comms in Linux for TunerPro RT

Post by vlad01 »

It did mention latency and timing was likely an issue and gave a few suggestions. One was to mod the delay timer for the device I think? From the default 16ms to 1ms. This did not do anything for the failed download, but I did notice a slight increase in the data logging rate to a max of 13-14Hz, with the average around 12Hz, certainly higher than any other setup or system I have used. Without this mod, it sat around the 11Hz with peaks of around 12Hz. I thought that was an interesting side effect and hinted at a latency issue.

Another suggestion was to reinstall or alter the way Crossover was installed, to take it out of the flatpack and have it installed more directly to reduce latency further.

But rather than taking the risk, I had a gut feeling it was more of a fundamental issue that couldn't be hacked around trying things at random.

Could I give it a crack at getting AI to code up a new plugin? Complete n00b question, will I need the original source for it to work from?
User avatar
antus
Site Admin
Posts: 10012
Joined: Sat Feb 28, 2009 10:34 am
cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007

Re: ALDL comms in Linux for TunerPro RT

Post by antus »

PM Sent
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
vlad01
Posts: 8548
Joined: Mon Oct 08, 2012 8:41 am
cars: VP I S
VP I executive
VP II executive
VP II executive #2
Location: Kyneton, Vic

Re: ALDL in Linux with TunerPro RT - How to guide

Post by vlad01 »

I've updated the OP, we have a fully functional ALDL and TunerPro RT running within Linux.

Thanks to Ant for letting me use and post up a sort of pre-release version of OSE 3 which fixes many of the limitations the current release versions of OSE have. These changes were the missing key to get ALDL to work on other than native windows.

This has been a goal of mine since I ditched modern windows last year. I'm stoked that a solution was eventually found. :punk: