User Tools

Site Tools


swift_nav_duro


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
swift_nav_duro [2026/03/20 20:13] – [Connectivity] adminswift_nav_duro [2026/11/08 16:49] (current) – [Photos] millerjs
Line 1: Line 1:
 ====== Swift Navigation / Carnegie Robotics Duro ====== ====== Swift Navigation / Carnegie Robotics Duro ======
 +<note important>My findings regarding SSH and TTY access may not apply to all models! 
 +See [[swift_nav_duro#limited_access|Limited Access]]</note>
 [{{:swiftnav:duro:swiftnav_duro.png?400 |Photo credit Carnegie Robotics}}] [{{:swiftnav:duro:swiftnav_duro.png?400 |Photo credit Carnegie Robotics}}]
  
Line 57: Line 58:
 There is a MicroUSB port behind the service door on the rear of the unit, and this actually gives us pretty much everything needed to get started and use the device. Officially, we are not allowed to use it. There is a MicroUSB port behind the service door on the rear of the unit, and this actually gives us pretty much everything needed to get started and use the device. Officially, we are not allowed to use it.
  
-{{:swiftnav:piksi_tty_motd.png?250 |}}+[{{:swiftnav:piksi_tty_motd.png?250 |Piksi Multi TTY Access}}]
  
 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 ====
Line 197: Line 200:
  
 If we ever want that stuff to run again, all we have to do is comment out the ''CUSTOM_SCRIPT'' line in the config file, reboot again, and all those intit scripts will run again - but make sure the config file is backed up (or duplicated under another name in /persistent/) because of course it will be deleted. If we ever want that stuff to run again, all we have to do is comment out the ''CUSTOM_SCRIPT'' line in the config file, reboot again, and all those intit scripts will run again - but make sure the config file is backed up (or duplicated under another name in /persistent/) because of course it will be deleted.
 +
 +==== Limited Access ====
 +In November 2026, I picked up a few more Duro's that had been listed as "defect". In the ones that work, I found generic firmware - no Unicontroll stuff - and also, no shell access anywhere. No SSH, no third TTY going to agetty, nothing. I'm doing some digging to see if I can figure out how to get into it and get it back. 
 ===== Photos ===== ===== Photos =====
 +Note: these are all photos of my first Duro. If my others have different features, or anything worth showing, I will add them. 
 +
 My Duro is a late model, with Carnegie Robotics branding. It is not clear to me when it was manufactured, but the [[https://www.marvell.com/content/dam/marvell/en/public-collateral/phys-transceivers/marvell-phys-transceivers-alaska-88e1512-product-brief.pdf|Marvell PHY]] on the carrier board has a late 2021 date code. The Piksi Multi seems to be an 00108-09 revision, but I haven't confirmed its date of manufacture yet. My Duro is a late model, with Carnegie Robotics branding. It is not clear to me when it was manufactured, but the [[https://www.marvell.com/content/dam/marvell/en/public-collateral/phys-transceivers/marvell-phys-transceivers-alaska-88e1512-product-brief.pdf|Marvell PHY]] on the carrier board has a late 2021 date code. The Piksi Multi seems to be an 00108-09 revision, but I haven't confirmed its date of manufacture yet.
  
swift_nav_duro.1774037612.txt.gz · Last modified: by admin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki