Hardware Verification

This page outlines the internal testing process for the hardware and software tools we use before each ATDM shipment and deployment.

ATDM - Internal Hardware Verification Procedure

1. Prerequisites & Initial Login

  1. Power On: Connect the appropriate power supply to the ATDM unit and power it on.

  2. Connect Ethernet: Ensure the ATDM is connected via Ethernet to a network accessible by your host computer.

  3. Access Console/SSH: Access the device's command line. This can typically be done via:

    • Serial Console: (Details if applicable, e.g., Baud rate, port)

    • SSH: Once the device boots and gets an IP address (check DHCP server or use device discovery), connect via SSH from your host computer:

      ssh torizon@<ATDM_IP_ADDRESS>

  4. Login: Use the standard internal testing credentials:

    • Username: torizon

    • Password: Andromeda

    Expected Outcome: You should see a login prompt similar to this after entering the password:

    Last login: Fri Mar 28 00:49:53 2025
torizon@verdin-imx8mp-15230135:~$

    (Verification: Successful login)

2. Hardware Component Tests

Execute the following commands for each component and verify the expected outcome.

2.1 Ethernet Connectivity

  • Command:

    ifconfig eth0
# Or alternatively: ip addr show eth0

  • Expected Outcome: The command should display details for the eth0 (or similarly named Ethernet) interface. Look for:

    • UP, RUNNING flags.

    • An inet address (IP address assigned via DHCP or static config).

    • RX/TX packet counts (should ideally increase if network activity occurs).

    • Example Snippet:

      eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
      inet 192.168.68.110 netmask 255.255.252.0 broadcast 192.168.71.255
      ether 00:14:2d:e8:64:b7 txqueuelen 1000 (Ethernet)
      RX packets 120 bytes 9297 (9.0 KiB)
      TX packets 40 bytes 5282 (5.1 KiB)

    (Verification: Interface is UP, RUNNING, and has an IP address).

2.2 CAN Bus Interface

  • Commands:

    # Configure CAN0 interface speed (e.g., 500kbit/s)
ip link set can0 type can bitrate 500000

# Bring the CAN0 interface up
ip link set can0 up

# Monitor CAN traffic (Requires external CAN tool/device sending messages for full test)
candump any -t z -Ddex

  • Expected Outcome:

    • The ip link set commands execute without error.

    • candump any starts listening without error. If CAN messages are being sent on the bus connected to can0, they should be displayed on the console.

    • (Minimal Verification: Commands execute, candump starts listening).

    • (Full Verification: candump displays expected CAN traffic).

    • TODO: Integrate pythonCanoe project to verify CANbus traffic on the fly.

2.3 Cellular Modem

  • Command:

    mmcli -m 0

  • Expected Outcome: The command should output detailed status information about the cellular modem (Quectel module). Key fields to check:

    • Hardware | manufacturer: QUALCOMM INCORPORATED

    • Hardware | model: QUECTEL Mobile Broadband Module

    • Status | state: registered (Indicates connection to the cellular network - may require active SIM)

    • Status | signal quality: XX% (A percentage value should be present)

    • 3GPP | operator name: <Network Name> (e.g., T-Mobile, AT&T - requires active SIM)

    • SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 (Indicates SIM is detected)

    • Example Snippet (Focus on key status lines):

      -----------------------------------
Hardware | model: QUECTEL Mobile Broadband Module
-----------------------------------
Status | state: registered
| signal quality: 88% (cached)
-----------------------------------
3GPP | operator name: T-Mobile
-----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0

    (Verification: Modem detected, reports status, ideally shows registered state and signal quality).

2.4 GPS Functionality

  • Commands:

    # Ensure GPS NMEA stream is enabled
mmcli -m 0 --location-enable-gps-nmea

# Optional: Set refresh rate (e.g., 1 second)
mmcli -m 0 --location-set-gps-refresh-rate=1

# Get current location data
mmcli -m 0 --location-get

  • Expected Outcome:

    • The enable/set commands execute without error.

    • The location-get command outputs location information. Look for:

      • GPS | nmea: lines containing standard NMEA sentences (like $GPGSV, $GPGSA, $GPRMC, $GPGGA). Even without a satellite fix, these lines should appear. A fix requires a clear view of the sky.

    • Example Snippet (Showing NMEA data presence):

      --------------------------
GPS | nmea: $GPGSV,2,1,07,10,,,30,18,,,25,26,,,29,27,45,295,32,1*58
| $GPGSV,2,2,07,29,04,156,34,32,,,30,48,,,36,1*52
| $GPGSA,A,1,,,,,,,,,,,,,,,,*32
| $GPRMC,,V,,,,,,,,,,N,V*29
| $GPVTG,,T,,M,,N,,K,N*2C
| $GPGGA,,,,,,0,,,,,,,,*66

    (Verification: NMEA sentences are being output by the modem).

2.5 WiFi Interface

  • Commands:

    # Check WiFi device status
nmcli device wifi

# List available WiFi networks
nmcli device wifi list

  • Expected Outcome:

    • The commands execute without error.

    • nmcli device wifi should show the state of the wlan0 (or similar) interface (e.g., connected, disconnected).

    • nmcli device wifi list should show nearby WiFi SSIDs if WiFi is enabled and networks are in range.

    • (Minimal Verification: Commands run, show wlan0 interface status).

    • (Full Verification: Nearby networks are listed).

2.6 Bluetooth Interface

  • Commands:

    # Check Bluetooth adapter status
hciconfig

# Ensure the adapter is UP (may require sudo)
sudo hciconfig hci0 up

# Enter bluetooth command utility
bluetoothctl

# Inside bluetoothctl, start scanning
scan on

  • Expected Outcome:

    • hciconfig shows the hci0 interface, preferably with UP RUNNING flags.

    • sudo hciconfig hci0 up executes without error (if needed).

    • Entering bluetoothctl works.

    • scan on starts the scanning process, and nearby discoverable Bluetooth devices should be listed with their MAC addresses and names.

    • Example hciconfig Output:

      hci0: Type: Primary Bus: UART
      BD Address: 10:68:38:50:44:0C ACL MTU: 1021:5 SCO MTU: 60:12
      UP RUNNING
      RX bytes:1824 acl:0 sco:0 events:133 errors:0
      TX bytes:1571 acl:0 sco:0 commands:129 errors:0

    (Verification: hci0 is UP RUNNING, scan on discovers devices).

    • (Type exit in bluetoothctl to leave the utility).

2.7 Touchscreen Input

  • Commands:

    # Identify input devices (look for touchscreen device name/path)
cat /proc/bus/input/devices

# Test the specific event device (replace /dev/input/eventX if needed)
# You might need sudo depending on permissions
sudo evtest /dev/input/event1

  • Expected Outcome:

    • The cat command lists input devices. Identify the one corresponding to the touchscreen.

    • Running evtest on the correct device path (/dev/input/eventX) should print event data to the console when you touch the screen. Press Ctrl+C to stop evtest.(Verification: Touching the screen generates output lines from evtest).

PreviousGetting StartedNextSoftware Development

Last updated