X20P UART1/UART2 interfaces (0x050c/0x050d) not supported - use main interface (0x01ab)

[hortovanyi]

Problem

X20P devices present multiple USB interfaces:

• 0x01ab - Main interface (working)
• 0x050c - UART1 interface (not working)
• 0x050d - UART2 interface (not working)

Users may attempt to connect to UART1/UART2 interfaces expecting them to work like the main interface,
but these require different USB-to-UART bridge protocols that are not currently implemented.

Investigation Summary

We attempted several approaches to support UART1/UART2:

1. USB packet analysis: Discovered that these interfaces use 2-byte status headers per 64-byte USB
   packet
2. Status header stripping: Successfully removed headers but received all zeros (no UART data)
3. Vendor-specific USB control transfers: Tried various initialization sequences (baud rate, line
   format, bridge enable)
4. CDC control transfers: Failed with LIBUSB_ERROR_PIPE as expected for vendor-specific interfaces

Root Cause

Despite UBX being enabled by default on UART1, the USB-to-UART bridge initialization is incomplete. The
specific vendor control sequence required for this chip is unknown.

Current Solution

• Added explicit error message when attempting to connect to UART1/UART2 interfaces
• Users are directed to use the main interface (0x01ab) which works reliably
• Error message: "X20P UART1/UART2 interface (0x050c/0x050d) is not currently supported. Please use the main X20P interface (0x01ab) instead."

Code Changes

• usb.cpp:418-431 - Added error check and exception for UART interfaces
• ublox_dgnss_node.cpp:1282-1310 - Commented out header stripping code (preserved for future reference)

Future Work

To support these interfaces, we would need:

1. Reverse engineering of the USB-to-UART bridge chip's control protocol
2. Proper vendor-specific initialization sequence
3. Understanding of the exact status header format and UART data extraction

Workaround

Use the main X20P interface (0x01ab) which provides full functionality for all GNSS operations.

[flipflip8952]

I think the 1546:050c and 1546:050d are just custom IDs for a standard FTDI chip (that is in the EVK). It's just that https://github.com/torvalds/linux/blob/master/drivers/usb/serial/ftdi_sio.c#L1074 doesn't know that.

We can (temporarily) teach it about those IDs:

modprobe ftdi_sio

# EVK-F9P
# Bus 001 Device 046: ID 1546:0507 U-Blox AG F9P; ZED_UART1
# Bus 001 Device 047: ID 1546:0508 U-Blox AG F9P; ZED_UART2
echo 1546 0507 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
echo 1546 0508 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

# EVK-X20P
# Bus 001 Device 050: ID 1546:050c U-Blox AG X20P UART1
# Bus 001 Device 051: ID 1546:050d U-Blox AG X20P UART2
echo 1546 050c > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
echo 1546 050d > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Now it should recognise them and create /dev/ttyUSBx devices, which one can use like any USB-to-UART serial port thingy.

To make this permanent you can use https://github.com/phkehl/ubloxcfg/blob/main/tools/99-ftdi-ublox.rules

Works for me.. :-)

(There's a USB hub in the EVK. The ttyACMx device is the USB directly connected to the F9P/X20P. The ttyUSBx devices are the FTDI chip USB side, and this is connected to the UART1 and 2 of the F9P/X20P.)