Any idea how many ALDL cables could be connected to the data port (spliced in) and function? I'm working on a project that would require 3 devices to be connected at once? Seem like it might work without killing the signal?
Thanks
Printable View
Any idea how many ALDL cables could be connected to the data port (spliced in) and function? I'm working on a project that would require 3 devices to be connected at once? Seem like it might work without killing the signal?
Thanks
depends on the application.
with certain setups, adding a single ALDL cable can prevent another module that communicates on the line to quit working until it is unplugged from the car. the 88-93 grand prix with a driver information center is the only one i've run across so far, but there may be more.
Well, I'm thinking about starting a custom digital dash to replace the stock dashboard in my Burb. I'd like to use 2 or 3 separate Android devices to be able to fill all the room where the stock dash was. I figure if I hard wire 2 'dash devices' and occasionally plug in a 3rd for tuning.....
Whatcha think?
getting them to play well with each other would be interesting.... could have a seperate ADX setup for one compared to the rest. one sends commands to the PCM, the others listen for that command to be sent and then listen for response data at the same time as the "commanding" one.
i'm fairly certain that could be done with some defined headers in the ADX.
You will only be able to get one ALDL cable connected. Anymore than that and the packets get corrupted (or so it seems).
You would need to daisy chain devices, re-sending the datastream to the next device.
The way I would do it is with an Arduino Mega probably. This would allow for 3 devices (three UART ports on the Mega). If you just do one firmware hardcoded for your setup, its pretty easy (and cheap).
I have no coding experience, and wouldn't have the slightest idea where to start. I understand what you mean though.Quote:
Originally Posted by 3400tZ
just an idea, but are these three devices making exactly the same request and expecting the same data?
because if this is the case, i would imagine you could just connect one device's TX line and all three RX lines in parallel.
in theory, one device sends the request, the other devices THINK they're sending the request, but magically get an echo and a response anyway. obviously the timing would be really staggered, so it'd be dependant on how the particular devices are coded, what kind of delays they'll tolerate between requests and responses, but could work?...
Your question is odd. How many devices can be connected to the ALDL? Many. First the ECM/PCM sends out a $F0 poll every 2 or 3 seconds. Well maybe faster or slower. The $F0 is a "Hello, is any one out there (On the 8192 Baud line)? If you have One device that responds to this and request a Mode 1 message sent, the ECM/PCM will respond. If you have 10 devices on the ALDL Line that "LISTEN" and do NOT transmit any messages, you can have many.Quote:
Originally Posted by Scrufdog
This is how the Old Tech-1 was set up in the GM Training Centers across the country. The instructor had the Master Tech-1 and the students had the Slaves. This was set up with special cartridges the Training Center received. There was ONE car in class that was used as a Demo to the students. The instructors T-1 answered the $F0 poll and told the ECM/PCM the T-1 will Drive the Bus and run things. Then the Instructors T-1 requested Mode 1 messages from the controller. After the ECM/PCM doesn't see the Off-Board device for 3 to 5 seconds the ECM/PCM will return to "Normal Mode Messages". (No Off-Board device on line.) The Instructor had a standard ECM or Powertrain Cartridge and the students had the "Special Training Center Cartridges" which only would listen for the selected vehicle message and display the data.
To answer your question? It is dependent on what each device does or how it is programmed. You could get fancy and have number 1 ask for a mode 1 message and then release the command of the ALDL. Then the next one, #2, ask for a Mode 2 dump. ect ect. Only one device can talk at one time.
If this Bus has broadcast messages such as a Corvette, Toronado, Caddy, ect, this will not work. The ALDL Line was used to send and receive different messages to keep all the controllers alive like the IP with coolant and speed and the HVAC to have the A/C on Hi and blowing out the vents. ABS and Traction control and BCM to name a few on the line.
Doesn't work. The timing would have to be EXACT, down to the millisecond, of all three devices for both send request and receive.Quote:
Originally Posted by steveo
It doesn't work, I've tried. ;)
The "many devices" that are on some of the ALDL in the oem vehicles are specifically set up to communicate with each other and a single diagnostic device. Attempting to connect more than one diagnostic device at a time causes the ALDL datastream to shut down.
i don't see why having receive headers wouldn't work for all but one of them.... one to send the request, all 3 to receive, the receive only just watches for a F0/F4, 85, 01, xx, xx, xx, xx, cs header and then act upon the data.
i'm certain i've done this to watch in on data the ECM sends to a DIC/DIS before.
If the TX/RX set works like a standard CanBUS, wouldn't additional devices with unique IDs work all together? Say an AutoProm and an Android device with adapter. I'm going off of how CanBus acts with my job, but you can attach as many diagnostic devices to the CanBUS as long as they have different IDs. I may just have to pickup a cable and see what happens.
I just ordered one of those DIY ALDL chips. I'll get it working on it's own then see how it goes with another device connected, and with or without the TX pin connected.
ALDL is very different than CAN bus. There's no device ID used in the ALDL datastream, just send and receive packets along with actual data.
Like Chris said, CAN is very different. CAN is actually made to have multiple devices on the same network.
What billy is talking about seems to be all devices that knows about each other so that's why it could work but in the case that you're using ALDLdroid with TunerPro on the same ECU for example, I don't see how it could work. Either both Mark and I would need to implements some sort of communication protocol within both apps or you have to come up with a device in the middle like I was talking earlier.
Without a TX pin, I'm not sure how it could work as you would receive the response at random times. You will probably have to increase the timeout of the listen packet for the devices that won't have the TX pins connected. To be honest, I really don't think that will work too well but it might be worth a try.