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:

  • 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:

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

2.2 CAN Bus Interface

  • Commands:

  • 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:

  • 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):

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

2.4 GPS Functionality

  • Commands:

  • 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):

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

2.5 WiFi Interface

  • Commands:

  • 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:

  • 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:

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

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

2.7 Touchscreen Input

  • Commands:

  • 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