orin-nano-env-setup/docs/BOM.md

type

type
reference

Bill of Materials

USB port allocation (2026-10-12)

All ports are taken.

Port	Device	Speed	Typical load
USB-A	PCAN-USB	full speed (12 Mbit/s)	≪ 1 Mbit/s
USB-A	USB camera	USB 2.0	up to ~60 Mbit/s (1080p30 MJPEG)
USB-A	SIM7600 (Waveshare HAT)	USB 2.0	up to 150 Mbit/s down (LTE Cat 4)
USB-A	IMU (WT61 on a USB-UART adapter; later NEO-M8U)	full speed	≪ 1 Mbit/s
USB-C	Tablet (Orin in device mode: NCM gadget)	USB 2.0	~5 MB/s paced down, ~22 MB/s up

• The four USB-A ports sit behind one Realtek 4-port hub (0bda:5489 USB 2.0 side, 0bda:0489 USB 3 side). Every device above is USB 2.0, so they all share one 480 Mbit/s upstream. Worst case ~210 Mbit/s: fits, but a second camera would not leave much room.
• The carrier spec (SP-11324-001 Table 5-3) gives 0.5 A for the USB-A VBUS. The modem's transmit peaks are the largest load; if the LTE link drops under heavy upload, check its supply first.
• Name devices by USB ID or serial in udev, not by port: any device can go in any port.
• Anything more (a USB stick to offload data, a debug serial adapter) needs an external hub. Non-USB expansion is still free: Ethernet, the header UART and I²C, and the M.2 Key M slots.

Field	Value
Manufacturer	PEAK-System Technik GmbH
Model	PCAN-USB
USB ID	0c72:000c
Purpose	USB-to-CAN adapter for reading car CAN bus traffic
Interface	SocketCAN netdev
Bitrate	500 kbps, measured on the Z27AG OBD port (not listen-only since 2026-10-12, though nothing transmits on CAN now: OBD-II goes over the K-line via the ELM327; see CAN bitrate plan)
Driver	PEAK proprietary driver 9.2.0 (netdev build) — out-of-tree module, must be rebuilt after kernel updates

Notes

• The mainline kernel driver peak_usb is not compiled into the NVIDIA Tegra kernel (JetPack r36.4), so PEAK's proprietary driver is required.
• Must be built with NET=NETDEV_SUPPORT for standard SocketCAN tools (candump, ip link, etc.).
• The module lives at /lib/modules/$(uname -r)/misc/pcan.ko and is loaded via modprobe pcan.
• Staying on USB (2026-10-12) rather than moving to the onboard controller (optional header J17 + a 3.3 V transceiver): the USB cable makes the car connection easy to detach and reattach, which a header-mounted transceiver would need a bulky connector (e.g. 4-pin DTM) to match.
• Jetson Orin Nano has a built-in CAN controller (exposed by GPIO pins). Kernel canN order is not stable, so both are pinned by udev: onboard → can_onboard, PCAN-USB → can_pcan (device naming).

Waveshare SIM7600G-H-M.2

hat module

Field	Value
Manufacturer	Waveshare (SIMCom SIM7600G-H-M.2 module)
Form factor	M.2 B KEY
Purpose	LTE Cat 4 cellular + multi-constellation GNSS (GPS, Beidou, GLONASS, GALILEO, QZSS)
Interface	USB (ttyUSB* for AT commands/NMEA, QMI cdc-wdm0 + wwan0 for data)
Power	3V – 4.2V (board rail)
Antennas	3× IPEX (LTE main + LTE diversity + GNSS)
Max data rate	150 Mbps DL / 50 Mbps UL (LTE Cat 4)

Required software

Package	Purpose
gpsd	Decode NMEA from the GNSS ttyUSB port
ModemManager + NetworkManager	Manage the modem and the LTE data connection (QMI)
qmi_wwan + cdc-wdm kernel modules	Not in the Tegra kernel; built out of tree in ~/infra/qmi_wwan/
minicom (or picocom)	AT command terminal for module configuration

Notes

• The module presents multiple USB serial ports (/dev/ttyUSB0–/dev/ttyUSB4) — ttyUSB2/3 for AT commands, ttyUSB1 for NMEA GPS data (symlinked as /dev/sim7600-gps).
• Default USB composition (PID 9001) is used with QMI; no PID switch needed. PPP dial-up does not work with the povo SIM (network detaches).
• Setup details: SIM7600 setup report.
• M.2 B KEY is not mechanically compatible with Mini-PCIe.
• Supply voltage should be ~4.0 V for reliable operation.
• DO NOT hot-plug while powered.

Waveshare UPS Power Module (C)

wiki

Field	Value
Purpose	Keep the Orin running through cranking and short power losses, and give time for a clean shutdown at ignition off
Input	15–19 V DC (Waveshare recommends a 19 V / 2.37 A adapter). ⚠ A PD trigger at the standard 20 V level is above the rated maximum
Output	Input voltage when powered (pass-through); battery voltage (9–12.6 V) when not
Battery	3 × 21700 Li-ion in series (not included); charging stops when full and resumes below 12 V
Monitoring	INA219 on I²C. On the car unit it is bus 7 (40-pin header), address 0x41
Holdover (bench, 2026-10-09)	≥ 20 s across a supply swap, enough to ride through cranking

Notes

• First read-only check (2026-10-09, on input power, charged): bus 12.34 V, shunt ≈ 0 mV (idle). Chip at power-on defaults (config 0x399f, calibration unprogrammed), so read current from the shunt-voltage register (0x01, 10 µV/LSB) rather than the current register.
• Fed from the ignition-switched cigarette socket via a 15 V PD trigger (15 V / 3 A, inside the 15–19 V rating). Plan: car power.
• Ignition-off shutdown (not built yet): on input loss the battery current turns clearly negative (discharging). A small service watches the INA219, waits out a grace period longer than a crank (30–60 s), then runs systemctl poweroff, with low battery voltage as a hard backstop. The shunt value is unconfirmed; check the schematic before converting shunt mV to amps.
• Read every second by svc-core's orin-status (read-only: register pointers only, chip left at defaults), published as yukart/host/ups_*: pack voltage, current (+ charging), state, and a charge estimate. Waveshare's demo code (UPS_Power_Module_C.zip, ina219.py) assumes a 0.01 Ω shunt and gives the sign, and maps 9.0–12.6 V linearly to 0–100 %.
• No GPIO or shutdown signal on the module; the BOOT button may be needed to wake a battery that stopped outputting (FAQ).

USB camera (IMX662, Sunplus UVC bridge)

Field	Value
Sensor	Sony IMX662 per the seller (1/2.8", STARVIS 2, low-light); the USB bridge does not report it
USB ID	1bcf:2d4f (Sunplus Innovation Technology, "USB Camera 1080P"), USB 2.0 high-speed
Purpose	Camera for the Orin: recording, live view on the tablet, later inference (roles open; see project-yukart roadmap, Phase 5)
Interface	UVC (uvcvideo, /dev/video0) + UAC microphone (ALSA card U1080P, 48 kHz stereo). In-tree drivers, no setup
Formats	MJPEG up to 1920×1080 at 60 fps nominal; YUYV only at low rates (5 fps at 1080p). No H.264
Documentation	None beyond the seller's listing; facts from the device: USB camera report

Notes

• Delivered frame rate follows the light: 17–20 fps indoors with auto exposure, full rate with a short fixed exposure.
• MJPEG is ~245 KB per 1080p frame, ~7.3 MB/s at 30 fps; too much for the tablet link (~5 MB/s) or for recording. The Orin Nano has no hardware video encoder; software H.264 (x264enc ultrafast) costs ~1.3 cores at 19 fps, ~2 at 30.
• Shares the carrier board's internal USB 2.0 hub with the SIM7600; headroom is ample.
• UVC controls (exposure, white balance, power-line frequency) reset on re-enumeration; set them when opening the device.

WitMotion WT61 IMU

Status: shorted on first power-up (2026-10-12), on Dupont wires, after the move from smart-serow; cut off quickly. Cause unknown; whether the module still works is untested.

Field	Value
Manufacturer	WitMotion
Model	WT61: 6-axis accelerometer + gyroscope, with onboard angle fusion (roll, pitch, yaw)
Purpose	Motion data for the recordings: longitudinal and lateral g, yaw rate, road grade
Interface	TTL UART on the 40-pin header: UART1, /dev/ttyTHS1 (free: no console or getty on it). The header I²C stays free for other sensors
Protocol	11-byte packets, 0x55 header: accel 0x51, gyro 0x52, angle 0x53, each three int16 values + temperature + checksum. Reference: smart-serow arduino/IMU.md
Rate	115200 baud / 100 Hz, set 2026-10-14 on the second module (it came at 9600 / 10 Hz); 100 packets/s of each type, no checksum errors
Power	3.3 V from header pin 1. Datasheet v24-0429: 3.3–5.5 V, 5 mA working (5 V), 39 µA asleep; data valid ~1 s after power-up
Range	±16 g, ±2000 °/s; roll and yaw ±180°, pitch ±90°. No magnetometer
Datasheet	v24-0429: /mnt/wdelem/dropzone/WT61-datasheet-240429.pdf. Older: ~/infra/kb/inbox/engineer/raw/WT61_Datasheet.pdf (raw, not yet in the KB)
Module pins (bare module, 12 pads)	2, 11 VCC · 5, 8 GND · 3 RX · 4 TX · 6 SWIM (programming) · 1, 7, 9, 10, 12 not connected. A breakout board's labels take precedence

Wiring (40-pin header)

WT61	Header pin
VCC	1 (3.3 V)
GND	6
TX	10 (UART1 RX)
RX	8 (UART1 TX), needed only to send config commands
Realign button (optional)	7 (GPIO09, PAC.06) through the button to ground on 9; 100 kΩ from 7 to 3.3 V (pin 1 or 17)

Everything sits in header pins 1–10, so one 2×5 connector can carry it. Pins 3/5 (I²C bus 7) carry the UPS monitor.

Header facts (carrier board spec SP-11324-001 v1.3, Table 3-3 and 5-3; raw copy in /mnt/wdelem/dropzone/):

• All signals are 3.3 V. Pins 7, 8 and 10 pass through TXB0108 level translators: their outputs are very weak (±20 µA) and can be overdriven, and any pull-up or pull-down on them must be weaker than 50 kΩ (I²C excepted). Hence 100 kΩ for the button, not 10 kΩ.
• 3.3 V on the header: 1 A per pin, but 0.1 A in total for the header from VDD_3V3_SYS. 5 V: 0.5 A in total.
• Pin 8 (UART1 TX) is also a boot strap (BOOT2_STRAP): nothing should drive it while the board powers up. The WT61's RX is an input, so it does not.
• Pin 7 is PAC.06 (gpiochip0 line 144), pulled down on the module at power-on.
• UART1 verified after the WT61 short (2026-10-12): loopback with pin 8 jumpered to pin 10, 1024 bytes intact at 9600 and 115200 baud.

Notes

• The header is 3.3 V logic and not 5 V tolerant. Powering the module at 3.3 V keeps every signal at 3.3 V. The datasheet only says "TTL level", so if it is ever fed 5 V, first check that its idle TX reads ~3.3 V.
• Power comes from the header's 3.3 V supply pin (1 or 17), a regulated rail on the carrier board. Not from a GPIO: a GPIO pin is a signal and is not meant to power anything.
• The second module (2026-10-14) speaks WitMotion's newer register protocol, not the 3-byte commands in smart-serow's IMU.md: it ignored FF AA 63. It came at 9600 baud / 10 Hz (a rate the datasheet does not list). Commands are 5 bytes, FF AA <register> <low> <high>, each run as unlock FF AA 69 88 B5, the write, save FF AA 00 00 00, all at the module's current baud. Done on the car Orin, checking after each step:
  1. at 9600: unlock, FF AA 04 06 00 (BAUD = 6, 115200), save → it answered at 115200 at once, still 10 Hz;
  2. at 115200: unlock, FF AA 03 09 00 (RRATE = 9, 100 Hz), save → 100 packets/s of each type. Stored in the module's flash. Back to 9600: BAUD = 2. The register map is WitMotion's general one (its "WT61 Protocol" document, linked from the datasheet, is not in the KB); confirmed here only by the module's behaviour.
• Mounting mode (FF AA 65 / 66 on the old protocol): not needed; the reader rotates into the car's frame itself.
• Do not zero the accelerometer at startup the way smart-serow's imu_calibrate() does: that removes gravity, which tilt and grade need.
• The serial device belongs to dialout (the header's /dev/ttyTHS1 and USB adapters alike); a service gets it with SupplementaryGroups=dialout, not by adding users to the group.
• USB-UART adapter: JetPack's kernel has drivers for CP210x and FTDI only (no PL2303, no CH341). In use: a CP2102 (10c4:ea60, generic serial 0001, so it can only be told apart by port). A PL2303GC (067b:23a3) enumerates but gets no driver.
• The temperature field is the chip's own temperature, not the air's: raw / 340 + 36.53 °C per the datasheet (smart-serow's IMU.md says 36.25).
• The gyro zeroes itself at power-up, and yaw resets to 0. The module must be still while it powers up; it is, if it powers with the Orin at ignition and the car is parked.
• Yaw drifts. With no magnetometer, yaw is integrated gyro and holds only over short spans; use yaw rate, not absolute yaw. Roll and pitch are referenced to gravity and do not drift.
• Output is low-pass filtered at 10 Hz by default, even at 100 Hz output. Fine for vehicle motion, but it smooths out bumps and vibration. A gyro rate under 0.122 °/s reads as 0 (static threshold). Both are set only from WitMotion's PC software; there is no serial command for them.
• Realign button parts (optional, not fitted): one momentary push button (normally open) and one 100 kΩ resistor. The resistor pulls pin 7 up to 3.3 V, so the pin reads 1, and a press grounds it to 0. Weak on purpose: the pin sits behind a TXB0108 (see header facts); check both states with gpioget once wired. Realigning starts from the tablet app first; the button adds a way that works without the tablet, triggering the same command.
• Realign: a press levels the frame to gravity (the mounting rotation, from averaged accelerometer readings) and sends FF AA 52 to zero yaw. The result is stored on disk, not redone every drive. Refuse while moving (gyro or GPS speed); record raw data plus a realign event, so a bad alignment can be corrected afterwards. Align on level ground: a slope becomes part of the mount.
• I²C mode (FF AA 62) exposes the raw MPU6050 only (no angles) and needs 4.7 kΩ pull-ups. Not used; v24-0429 lists SDA/SCL as not connected.
• Mounting matters more than the sensor. An IMU needs a rigid path to the body; a box on carpet, Velcro or isolators smooths the motion and drifts. Decided (2026-10-12): the IMU lives outside the enclosure on one USB-A port (WT61 behind a 3.3 V USB-UART adapter now; a NEO-M8U over USB-C as the GNSS+IMU upgrade), mounted on the roll cage, clamped close to a foot or a joint rather than mid-span. The header wiring above stays valid but is no longer the plan. A fault in the sensor now lands on a USB port (0.5 A limit) rather than the header's 3.3 V rail.
• No reverse-polarity protection is documented. A 4-way Dupont housing put on the wrong way round swaps VCC and GND. Check VCC and GND with a meter before first power-up.

RTC backup battery

Status: optional, low priority. Battery choice settled (CR2032); footprint/R560 still to verify against NVIDIA's schematic.

Field	Value
Purpose	Keep the RTC (rtc0, nvvrs-pseq-rtc) running while the board is unpowered, so the clock is correct at boot without network or GPS
Carrier board	P3768 (Orin Nano Developer Kit): pads present, connector not populated (needs soldering)
Connector (per NVIDIA docs, as quoted on the forum)	Wieson AC2651-0011-003-HH, 2-pin, 1.25 mm pitch. A community-used substitute is Molex 53398-0271 header + 51021-0200 housing
Battery	CR2032 (primary 3 V lithium) in a holder with leads. Not ML2032 or other rechargeables: the module datasheet says the backup pin (PMIC_BBAT) does not support charging, so a rechargeable just drains, and it has ~⅓ of the capacity
Expected life	RTC draws 12–50 µA while unpowered (~15 µA measured on the forum) → CR2032 (~220 mAh) lasts ~1.5–2 years typical, ~6 months worst case. Drains only while the board has no power
Extra parts	Forum reports also populating R560 (0.56 Ω, e.g. Panasonic ERJ2BQFR56X); confirm in the P3768 schematic

Notes

• Without it the clock boots at a stale date (seen 2026-10-08: June 4) until NTP syncs. See the time sync report.
• Forum sources: RTC battery on Orin Nano DevKit, How to add RTC battery.
• A reported side effect: the battery lead and socket make the case cover sit unevenly.
• Polarity: one forum post says the positive pad is marked with a white triangle. Confirm with a meter before connecting.
• Test after fitting: power off fully, wait a few minutes, boot with no network, and check cat /sys/class/rtc/rtc0/date (should be today, not a reset date).
• Low priority: online almost always means NTP within a minute; the gap only matters for offline drives (see the time sync report).