| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| swift_nav_duro [2026/03/20 20:14] – [MicroUSB] admin | swift_nav_duro [2026/03/23 15:34] (current) – [MicroUSB] millerjs |
|---|
| If this MicroUSB port is plugged into another machine, it will enumerate as three virtual TTYs using the common device class abstract control module. On linux this will be ''ttyACM0'', ''ttyACM1'', and ''ttyACM2'', if no other cdc_acms are present. ''ttyACM1'' is mapped to ''ttyGS1'' on the device and has a vt100 getty terminal running on it. You can connect to it with minicom or putty and log in as root (no password) and be greeted with some wonderful ASCII art. | If this MicroUSB port is plugged into another machine, it will enumerate as three virtual TTYs using the common device class abstract control module. On linux this will be ''ttyACM0'', ''ttyACM1'', and ''ttyACM2'', if no other cdc_acms are present. ''ttyACM1'' is mapped to ''ttyGS1'' on the device and has a vt100 getty terminal running on it. You can connect to it with minicom or putty and log in as root (no password) and be greeted with some wonderful ASCII art. |
| |
| In Linux on the device, ''ttyGS0'' and ''ttyGS2'' are symlinked to ''tty.usb0'' and ''tty.usb2''. ''tty.usb0'' is available as I/O for the GNSS firmware, and can be used the same as the two UARTs which are physically defined as the serial ports accessible through the M12 connectors on the front of the unit. By default, the GNSS firmware uses ''usb0'' as SBP in/out, but it can be used for NMEA out, RTCM in, or RTCM out as well. I haven't found any references made to what, if anything, uses ''ttyGS2''/''tty.usb2'', so ''ttyACM2'' is just blank. It's possible to manually run the tools that route GNSS data I/O internally, so you could use it for anything ''usb0'' can do if you configure it manually or with your own init script, or as another vtty. | In Linux on the device, ''ttyGS0'' and ''ttyGS2'' are symlinked to ''tty.usb0'' and ''tty.usb2'', respectively. ''tty.usb0'' is available as I/O for the GNSS software, and can be used the same as the two UARTs which are physically available as the serial ports accessible through the M12 connectors on the front of the unit. By default, the GNSS firmware uses ''usb0'' as SBP in/out, but it can be used for NMEA out, RTCM in, or RTCM out as well. ''ttyGS2''/''tty.usb2'' is in use, but I don't believe its use is configurable from the Swift Console. |
| |
| Note about this port: it does deliver power to the Piksi Multi, but I'm not sure if the rest of the Duro board is powered or if that configuration is even kosher. Usually in cases like this the Vcc line of the USB port is left disconnected, requiring the user to operate the device from a separate and more powerful supply. I don't know if this was intentional or a mistake made when designing the Duro board. | \\ |
| | |
| | Note about this port: it does deliver power to the Piksi Multi, but I'm not sure if the rest of the Duro will work correctly. Usually in cases like this the Vcc line of the USB port is left disconnected, requiring the user to operate the device from a dedicated supply. I don't know if this was intentional or a mistake made when designing the Duro board. In my own testing, the Duro does work when powered from MicroUSB alone, pulling just shy of 5w in normal use. Ethernet and microSD work, I have not tested the RS-232 interfaces. I don't see any warnings or complaints in the logs, and performance appears unchanged. |
| |
| ==== microSD ==== | ==== microSD ==== |
