mikkeli
872997281f
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz
220 lines
16 KiB
Markdown
220 lines
16 KiB
Markdown
---
|
||
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 (listen-only by default; see [CAN bitrate plan](impl/plans/CAN-BITRATE.md)) |
|
||
| **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](impl/reports/DEVICE-NAMING.md)).
|
||
|
||
## Waveshare SIM7600G-H-M.2
|
||
|
||
[hat](https://www.waveshare.com/wiki/SIM7600G-H-M2_4G_HAT) [module](https://www.waveshare.com/wiki/SIM7600G-H-M.2)
|
||
|
||
| 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](impl/reports/SIM7600-SETUP.md).
|
||
- 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](https://www.waveshare.com/wiki/UPS_Power_Module_(C))
|
||
|
||
| 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](impl/plans/POWER.md).
|
||
- 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](impl/reports/USB-CAMERA.md) |
|
||
|
||
### 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** | Planned 115200 baud / 100 Hz (factory default) |
|
||
| **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 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 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](impl/reports/TIME-SYNC.md).
|
||
- Forum sources: [RTC battery on Orin Nano DevKit](https://forums.developer.nvidia.com/t/rtc-battery-on-jetson-orin-nano-developer-kit/296732), [How to add RTC battery](https://forums.developer.nvidia.com/t/how-to-add-rtc-battery-in-jetson-orin-nano/255792).
|
||
- 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](impl/reports/TIME-SYNC.md)).
|