Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
SAE J2534-2:2020 – A Guide to Optional Pass-Thru Features for Vehicle Diagnostics
The SAE J2534-2:2020 standard defines optional features that extend the core pass-thru interface specified in J2534-1. This revision adds support for Ethernet NDIS protocol and the ability to read voltage on an SAE J1962 pin, alongside enhancements for pin selection, multiple channels, mixed format CAN frames, single wire CAN, analog inputs, and more. For engineers developing diagnostic applications and pass-thru devices, understanding these optional features is crucial for building robust, high-performance vehicle communication solutions. 🔍
Key Optional Features and API Extensions
| Feature | Description | Key API / IOCTL |
|---|---|---|
| Ethernet NDIS | Enables Ethernet communication using the NDIS protocol for high-speed diagnostic data transfer. | New IOCTL codes, API version 04.04 |
| Read Voltage on J1962 Pin | Reads voltage level on a specified pin of the diagnostic connector (e.g., pins 2, 10, 14). | IOCTL_PASSTHRU_READ_VOLTAGE |
| Pin Selection | Allows dynamic selection of multiple pins for communication, enabling flexible routing. | IOCTL_PASSTHRU_SELECT_PIN |
| Access to Additional Channels | Supports multiple simultaneous communication channels beyond the base standard. | Extended PassThruOpen and PassThruConnect parameters |
| Mixed Format Frames on CAN | Enables use of both 11-bit (standard) and 29-bit (extended) CAN identifiers on the same network. | Message flags CAN_FLAG_MIXED_FORMAT and CAN_FLAG_29BIT_ID |
| Single Wire CAN | Implements the GMW3110 single-wire CAN protocol for low-cost networks. | Dedicated protocol type SW_CAN and associated IOCTLs |
| Analog Inputs | Reads analog voltage values from up to four dedicated inputs on the pass-thru device. | IOCTL_PASSTHRU_GET_ANALOG_INPUTS |
Each feature comes with specific Win32 API functions, IOCTL control codes, and message structures that must be followed exactly to ensure compatibility and reliability. The standard also mandates a discovery mechanism so that applications can query the device for supported optional features at runtime. 🛠️
Engineering Design Insights and Best Practices
Implementing the optional features defined in J2534-2 requires careful attention to both hardware design and software API conformance. Below are key insights gathered from the standard and industry practice.
🔍 Discovery First: Always use the discovery mechanism (via IOCTL_PASSTHRU_READ_OPTIONAL_FEATURES) to check which features are available on the target pass-thru device. This avoids runtime errors and ensures your application gracefully handles devices with different capabilities.
When designing a pass-thru device, ensure that the pin matrix is properly configured to handle the selected signals. For instance, enabling Single Wire CAN may require special bias resistors, while analog inputs need voltage dividers to stay within safe measurement ranges. The pin selection IOCTL should be used before connecting to a channel to avoid signal conflicts.
For software developers, follow the API specifications precisely for each optional feature. Use the correct IOCTL codes (e.g., IOCTL_PASSTHRU_READ_VOLTAGE for voltage reading) and message structures as documented. When adding new protocols like Ethernet NDIS, pay attention to buffer management and network framing to ensure reliable data transfer. The standard lists specific IOCTL codes under sections 6 through 13 of J2534-2:2020.
⚠️ Common Pitfalls: Assuming all pass-thru devices support every optional feature. Always verify with the discovery API. Misconfiguring the pin matrix can lead to short circuits or communication failures. When using mixed format frames, ensure your application correctly interprets the ID type from the received messages.
Backward compatibility is a core consideration. The J2534-2 specification is designed to work with existing J2534-1 implementations. New IOCTL codes are selected to avoid conflicts, and API version numbers must be updated when adding support for optional features. Devices should continue to support all mandatory J2534-1 functionality while adding these optional capabilities. ✅
Frequently Asked Questions
1. What does the Ethernet NDIS optional feature allow?
Ethernet NDIS enables high-speed diagnostic communication over Ethernet networks, such as those used in modern vehicles for DoIP (Diagnostics over IP). It defines how the pass-thru device interacts with the vehicle’s Ethernet interface using the NDIS (Network Driver Interface Specification) protocol.
2. How can I read the voltage on a J1962 pin?
Use the IOCTL_PASSTHRU_READ_VOLTAGE IOCTL code. You specify the target pin number (e.g., 2, 10, 14) and the device returns the measured voltage in millivolts. Ensure the device and driver support this optional feature before attempting to use it.
3. Can I use mixed format CAN frames with any J2534-2 compatible device?
Only if the device explicitly supports the Mixed Format Frames on a CAN Network optional feature. Use the discovery mechanism to check for the MIXED_FORMAT_CAN feature flag. When supported, you can send and receive both 11-bit and 29-bit identifier frames on the same CAN channel by setting the appropriate message flags.
4. What are the main risks when implementing Single Wire CAN?
Single Wire CAN (SW CAN) uses a single wire for both data and power, making it susceptible to ground offsets and noise. Ensure the pass-thru device’s pin matrix is correctly set to the dedicated SW CAN pin, and follow the J2534-2 electrical specifications for termination and voltage levels. Also, verify that the device supports the SW_CAN protocol type via discovery.
By leveraging these optional features, automotive engineers can extend the capabilities of pass-thru devices to meet the growing demands of modern vehicle diagnostics. The key is to implement with care, test thoroughly, and always use the standard’s discovery tools to ensure robust operation. 🛠️
