wiki:v2x

V2X - Vehicle to Anything

V2X is a technology to allow a vehicle to communicate with other items. This uses a special RF Radio.

More V2X generics are provided in the Gateworks V2X Guide

VeniceFLEX GW82xx & FSA V2X

The VeniceFLEX features FSA adapters.

The Mini-PCIe FSA adapter can be ordered in a special configuration to support the V2X radio.

To enable 5V access on the FSA Mini-PCIe slot, the following resistors need to be loaded at the Gateworks factory before ordering. Note that a 100 piece minimum order is required for special configurations.

GW16FP0:

  • R21, R22, R25, R26 for 5V
    • This enables 5V on pins 3, 5, 45, 47
  • R19 & R20 for UART
    • Pins 17 (TX) & 19 (RX)

Venice GW71xx & GW72xx & GW73xx V2X

The Gateworks Venice GW72xx & GW73xx Single Board Computer (SBC) can be used to host the Unex V2X Radio. The SOM-301x radio requires 5V, 3.3V and USB 2.0. The 3.3V and USB 2.0 are provided by default but the 5V is not. A UART is also required for development.

To enable 5V access on the J10 Mini-PCIe slot, the following resistors need to be loaded at the Gateworks factory before ordering. Note that a 100 piece minimum order is required for special configurations.

GW71xx: (revision E and newer)

  • Load R70, R71, R72, R73 for 5V on J6 (use 02240128 which is a 0402 0-Ohm resistor)
    • This enables 5V on pins 3, 5, 45, 47
  • Load R74 and R75 for UART2 on pins 17 & 19

GW72xx:

  • Load R152, R153, R144, R145 for 5V (use 02240128 which is a 0402 0-Ohm resistor)
    • This enables 5V on pins 3, 5, 45, 47

The below resistors are for the UART and are by default unloaded on the GW72xx to avoid any conflicts:

  • R164, R165 for UART3 (use 02240128) (Pins 17 & 19)

GW73xx:

  • Load R5, R6, R102, R101 for 5V (use 02240128 which is a 0402 0-Ohm resistor)
    • This enables 5V on pins 3, 5, 45, 47

The below resistors are for the UART and are by default unloaded on the GW73xx to avoid any conflicts:

  • R104, R103 for UART3 (use 02240128) *Note UART3 is also used for the onboard WiFi/BLE and will conflict

An example schematic snippet is shown below.

GPS PPS Signal

The GPS PPS Signal uses pin 49.

UART Information for GW73xx

The UART3 (/dev/ttymxc2) on J10 on a GW73xx board is shared with the onboard Bluetooth module. (GW7301 has onboard BLE, GW7300 does not)

This is defined in the device tree here: https://github.com/Gateworks/linux-venice/blob/v5.15.15-venice/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi#L218

/* bluetooth HCI */
&uart3 {
     pinctrl-names = "default";
     pinctrl-0 = <&pinctrl_uart3>, <&pinctrl_bten>;
     cts-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
     rts-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
     status = "okay";

     bluetooth {
            compatible = "brcm,bcm4330-bt";
            shutdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
     };
};

To understand this better, think of how it works: UART devices don't have any sort of magic device 'auto-detection' like enumerated busses such as PCI and USB do (which have a bus infrastructure to provide things like a class, manufacturer, and device ID). Therefore device-tree must be used to explain to the OS what is there and map it to a driver. This is what the 'compatible = "brcm,bcm4330-bt"' string does; there is a driver that matches that compatible string.

It is possible to not see a /dev/ttymxc2 corresponding to schematic UART3 (NXP references hardware blocks as 1 based, Linux references them as 0 based) is indeed because the bluetooth HCI driver (hci_bcm) claims the UART such that Linux removes access from it to not conflict with it. The 'hci_bcm' driver won't fail to recognize the UART (ie if on a GW7300 which doesn't load that part) and remove it's claim on the device. Gateworks will not typically try to do things like removing that dynamically in the boot firmware via a dt fixup based on the model (because mapping model strings to what parts are loaded is a really bad idea).

To remedy this, one can either comment out the 'bluetooth' node in the device-tree if using a custom kernel/dt or use a 'fix_fdt' script.

  • In Linux find the device path
    # find /proc/device-tree/ -name "bluetooth"
    /proc/device-tree/soc@0/bus@30800000/spba-bus@30800000/serial@30880000/bluetooth
    

If the V2X support requires a kernel driver then it will need a device-tree binding of its own in which case one can use a dt overlay or customize the device tree.

Unex SOM-352 V2X Radio

Unex has released a newer V2X Radio, SOM-352. Link: https://unex.com.tw/en/product/som/

Here is the Unex SOM352 Quick Start Guide: https://unex.com.tw/en/document/som-352_quick-start-guide/

NOTE: This requires at minimum a 5V modification to the Gateworks SBC to power the card. Please see details above on this page.

Instructions for use:

  1. Connect all hardware. Be sure to use the Gateworks JTAG adapter to gain serial console access to the Gateworks SBC from your laptop/PC. Do not SSH into the Gateworks SBC.
  2. This device appears as a USB RNDS network device to the Linux OS running on the Gateworks SBC. It seems that the Ubuntu OS struggles with network naming related to enumerating this device. Therefore, in the Gateworks SBC u-boot, remove the following:
    print bootargs
    bootargs net.ifnames=0
    setenv bootargs #CLEAR THE VARIABLE
    saveenv
    boot
    
  3. Boot the Gateworks SBC and check to see if the radio is detected with the lsusb command and the following 3 devices:
    Bus 001 Device 014: ID 0424:3803 Microchip Technology, Inc. (formerly SMSC) 
    Bus 001 Device 015: ID 04d8:00dd Microchip Technology, Inc. MCP2221(a) UART/I2C Bridge
    Bus 001 Device 016: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
    
    
  4. Verify the radio interface was created with the ifconfig -a command: (something like enx162408f5cc4c below)
    root@noble-venice:~# ifconfig -a
    end0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
            ether 00:d0:12:8a:f8:35  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    enx162408f5cc4c: flags=4098<BROADCAST,MULTICAST>  mtu 1500
            ether 16:24:08:f5:cc:4c  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 28504  bytes 2050016 (2.0 MB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 28504  bytes 2050016 (2.0 MB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    
    
  5. Bring up the interface and assign an IP:
    ifconfig enx162408f5cc4c up
    ifconfig enx162408f5cc4c 192.168.1.1
    
  6. The radio itself has an IP of 192.168.1.3 (even though the interface is 192.168.1.1). Try to ping 192.168.1.3. NOTE: If an ethernet cable is connected to the Gateworks SBC, disconnect it for this test to avoid any network confusion.
    root@noble-venice:~# ping 192.168.1.3
    PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
    64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=1.05 ms
    64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.552 ms
    ^C
    --- 192.168.1.3 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1002ms
    rtt min/avg/max/mdev = 0.552/0.801/1.050/0.249 ms
    root@noble-venice:~# 
    
  7. SSH into the V2X radio from the Gateworks SBC (root is username, no password)
    root@noble-venice:~# ssh root@192.168.1.3
    root@autotalks:~# 
    
  8. Run the V2X example command while SSH'd into the radio, signified by the autotalks command prompt:
    root@autotalks:~# v2x-example
    Found file /usr/bin/sw_config_internal.txt
    Platform without TEE support
    Found file /usr/bin/sw_config.txt
    Using default value log_level_host=3
    ivn_service_broadcast_disable and v2x_service_broadcast_disable will affect only server application
    Device on M3 
    Shared memory ll_init done, memory size is 4096[bytes], rx size 2048[bytes], tx size 2048[bytes]
    ll_interface_init done - app_role 2
    GNSS device source config: internal poti disable = 1 internal baud rate = 0 internal 1Hz cycle ender = 0 internal poti type = 1 internal poti message format 1
               external baud rate = 0 external device=1 external port = 0 external 1Hz cycle ender = 0 external poti type = 1 external poti message format 1
    GNSS device source config: offset seconds = 0
    Device and services are registered and initialized
    Device is alive
    Using default value lmac_rf_config_file_location=1
    Using default value force_csk_generate=0
    Using default value log_level_device=3
    Using default value log_burst_size=10
    Using default value lmac_loopback_enable=0
    Using default value lmac_phy_loopback_enable=0
    Using default value lmac_trace_verbose=0
    Using default value swc_version=1
    Using default value lmac_ranging_enable=0
    Using default value lmac_dcc_indication_enable=1
    Using default value physical_interfaces_in_use=0
    Using default value lmac_diversity_enable=0
    Using default value lmac_tx_q_descriptors_count=8
    Using default value lmac_rx_q_descriptors_count=8
    Time sync is disabled for application role CLIENT Or not main process
    WDM frequency for channel A: 5880 MHz
    Could not attach interface 0
    
    ________________
    Going to send: 'Hello No. 1'
    
    ---TX Socket Statistics---
    Successfully sent: 1
    Failed to be sent : 0
    Total sent: 1
    Successfully received: 0
    Dropped: 0
    Total received: 0
    Previous packet tsf usec : 0
    ________________
    
    
    root@autotalks:~# 
    
    

Troubleshooting SOM-352

  1. Verify the 5V resistors have been loaded on the Gateworks Single Board Computer, for use when plugging the SOM-352 into the Mini-PCIe interface
  2. Verify the device is seen on lsusb:
    Bus 001 Device 014: ID 0424:3803 Microchip Technology, Inc. (formerly SMSC) 
    Bus 001 Device 015: ID 04d8:00dd Microchip Technology, Inc. MCP2221(a) UART/I2C Bridge
    Bus 001 Device 016: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
    
    
  3. Verify the RNDIS driver found the radio and created a network interface:
    root@noble-venice:~# dmesg | grep rndis
    [   18.009833] rndis_host 1-1.1.1.1:1.0 eth0: register 'rndis_host' at usb-ci_hdrc.0-1.1.1.1, RNDIS device, 22:ee:ea:b0:1c:91
    [   18.009989] usbcore: registered new interface driver rndis_host
    [   18.030099] rndis_host 1-1.1.1.1:1.0 enx22eeeab01c91: renamed from eth0
    root@noble-venice:~# dmesg | grep -i -C4 unex
    [   17.846327] usb 1-1.1.1.1: new high-speed USB device number 6 using ci_hdrc
    [   17.944213] usb 1-1.1.1.1: New USB device found, idVendor=1d6b, idProduct=0104, bcdDevice= 1.00
    [   17.944237] usb 1-1.1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [   17.944246] usb 1-1.1.1.1: Product: V2X-35X
    [   17.944253] usb 1-1.1.1.1: Manufacturer: Unex
    [   17.944260] usb 1-1.1.1.1: SerialNumber: 48400000.usb
    [   17.996172] usbcore: registered new interface driver cdc_ether
    [   18.009833] rndis_host 1-1.1.1.1:1.0 eth0: register 'rndis_host' at usb-ci_hdrc.0-1.1.1.1, RNDIS device, 22:ee:ea:b0:1c:91
    [   18.009989] usbcore: registered new interface driver rndis_host
    
    
    
  4. Verify the RNDIS module is seen:
    root@noble-venice:~# lsmod | grep rndis
    rndis_host             24576  0
    cdc_ether              20480  1 rndis_host
    usbnet                 57344  2 rndis_host,cdc_ether
    
  5. Cannot ssh into 192.168.1.3? Be sure all other network interfaces are removed (unplug ethernet cables, unplug WiFi cards, etc)
  6. Here is the Unex SOM352 Quick Start Guide: https://unex.com.tw/en/document/som-352_quick-start-guide/
Last modified 44 hours ago Last modified on 10/22/2025 10:33:12 PM

Attachments (3)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.