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).

---