USB-to-CAN adapter for reading car CAN bus traffic
Interface
SocketCAN netdev
Bitrate
500 kbps, measured on the Z27AG OBD port (listen-only by default; 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.
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).
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).
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.
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)
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: being fitted (2026-10-12) on Dupont wires, moved from the smart-serow motorcycle unit, where an Arduino read it. Final mounting and connector to follow.
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
Planned 115200 baud / 100 Hz (factory default)
Power
3.3 V from header pin 1. Datasheet: 3.3–5 V input through an onboard regulator, < 10 mA
Range
±16 g, ±2000 °/s; roll and yaw ±180°, pitch ±90°. No magnetometer
Datasheet
~/infra/kb/inbox/engineer/raw/WT61_Datasheet.pdf (raw, not yet in the KB)
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; 10 kΩ from 7 to 3.3 V (pin 1). Pin to confirm
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.
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 module stores its baud rate and output rate in flash. Leaving smart-serow it is set to 9600 baud / 20 Hz. The reader opens at 9600,
sends FF AA 63 (115200 / 100 Hz), and reopens at 115200. Commands at the wrong baud are ignored, so configuring on every start is safe.
Mounting mode: FF AA 65 flat, FF AA 66 upright. Set it once the car mounting is known.
Do not zero the accelerometer at startup the way smart-serow's imu_calibrate() does: that removes gravity, which tilt and grade need.
The user needs the dialout group to open /dev/ttyTHS1.
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 10 kΩ resistor. The resistor pulls
pin 7 up to 3.3 V, so the pin reads 1, and a press grounds it to 0. 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.
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
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.
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).
mikkeli
4ac775a13d