Adding ALDL to ELM protocol - What have I done!
Posted: Fri Sep 17, 2021 8:05 pm
With the development of the latest OBDX tool and a new manufacture bringing it to light, I have been motivated to finish the development of the ELM side for all protocols.
In saying that, I cannot explain the absolute hate I have for ELM cables and its protocol. The literally tears and blood them f*ing things have caused from day dot. They have single handedly shortened my life spam, I know it. Then topping them off with only supporting string commands which was the absolute most inefficient way for transferring data from app to tool. But as much shit as I give them, they were a simple starting point back when I barely understood the difference between a string and bytes, and are great for beginners.
So this now leads us to a first with ELM protocol standards, implementing ALDL. It both hurts and pleases me to show the below image of an OBDX setting up ALDL and sending a simple ALDL frame (01 00) to request diagnostic data from an VY BCM.
For those wondering what the commands are.. we have:
AT I (Request ELM name)
AT @1 (Request OBDX name)
AT SP F (Set protocol to F = ALDL)
01 00 (send ALDL frame request of F1 57 01 00 B6)
01 00 11 FB ... (BCMs response frame)
AT H1 (enable headers so we see full frame)
01 00 (Send same frame again)
F1 75 01 00 11 FB (BCM response with headers on)
ATMA (monitor all live data)
..all bus data after this.
For those technically inclined, the length byte and checksums are automatically calculated and put into the frame. And the response also has its header, length and checksum bytes removed as its all validated by the tool before sending to the user. Oh and the echo is also ignored too.
The single downfall with the basic setup is if someone was to filter for a frame such as the VT-VZ heartbeat (08 55 A3), this frame would not be displayed because that is a no data payload frame (08= header, 55=length, A3=checksum). This is the equivalent of a VPW frame with no payload (6C 10 F1 XX) where XX is the checksum and first three bytes are the header, technically the ELM does not show this to the user with default settings.
This can be over-ridden by enabling headers to get the full frame sent, but regardless I now understand why the ELM developers did what they did for all other protocols in the attempt to try make it as easy as possible for the end user.
In saying that, I cannot explain the absolute hate I have for ELM cables and its protocol. The literally tears and blood them f*ing things have caused from day dot. They have single handedly shortened my life spam, I know it. Then topping them off with only supporting string commands which was the absolute most inefficient way for transferring data from app to tool. But as much shit as I give them, they were a simple starting point back when I barely understood the difference between a string and bytes, and are great for beginners.
So this now leads us to a first with ELM protocol standards, implementing ALDL. It both hurts and pleases me to show the below image of an OBDX setting up ALDL and sending a simple ALDL frame (01 00) to request diagnostic data from an VY BCM.
- ELM_ALDL_Demo.PNG (17.46 KiB) Viewed 3707 times
AT I (Request ELM name)
AT @1 (Request OBDX name)
AT SP F (Set protocol to F = ALDL)
01 00 (send ALDL frame request of F1 57 01 00 B6)
01 00 11 FB ... (BCMs response frame)
AT H1 (enable headers so we see full frame)
01 00 (Send same frame again)
F1 75 01 00 11 FB (BCM response with headers on)
ATMA (monitor all live data)
..all bus data after this.
For those technically inclined, the length byte and checksums are automatically calculated and put into the frame. And the response also has its header, length and checksum bytes removed as its all validated by the tool before sending to the user. Oh and the echo is also ignored too.
The single downfall with the basic setup is if someone was to filter for a frame such as the VT-VZ heartbeat (08 55 A3), this frame would not be displayed because that is a no data payload frame (08= header, 55=length, A3=checksum). This is the equivalent of a VPW frame with no payload (6C 10 F1 XX) where XX is the checksum and first three bytes are the header, technically the ELM does not show this to the user with default settings.
This can be over-ridden by enabling headers to get the full frame sent, but regardless I now understand why the ELM developers did what they did for all other protocols in the attempt to try make it as easy as possible for the end user.
