| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| swift_nav_duro [2026/03/20 20:08] – [Swift Navigation / Carnegie Robotics Duro] admin | swift_nav_duro [2026/11/08 16:49] (current) – [Photos] millerjs |
|---|
| ====== 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}}] |
| |
| All of this is laid out in the [[https://www.swiftnav.com/resource-files/Piksi%20Multi/v2.2/Specification/Piksi%20Multi%20HW%20Specification%20v2.2%20%5B000-534-02-02%5D.pdf|HW Spec PDF]], but at a high level: | All of this is laid out in the [[https://www.swiftnav.com/resource-files/Piksi%20Multi/v2.2/Specification/Piksi%20Multi%20HW%20Specification%20v2.2%20%5B000-534-02-02%5D.pdf|HW Spec PDF]], but at a high level: |
| |
| {{ :swiftnav:piksi_multi.png?direct&400|https://support.swiftnav.com/support/solutions/articles/44001850753-piksi-multi-specification}} | [{{ :swiftnav:piksi_multi.png?direct&400|Photo credit Swift Navigation}}] |
| |
| * Based on the Zync 7020 running custom cores and linux | * Based on the Zync 7020 running custom cores and linux |
| |
| Piksi Multi is capable of simultaneous tracking of L1 and L2 signals from up to 22 satellites. | Piksi Multi is capable of simultaneous tracking of L1 and L2 signals from up to 22 satellites. |
| <cite>Piksi Multi HW Specification v2.2 [000-534-02-02], p.2</cite> | <cite>Piksi Multi HW Specification v2.2, p.2</cite> |
| </blockquote> | </blockquote> |
| |
| {{ :swiftnav:piksi_multi_block_diagram.png?direct&900 |}} | [{{ :swiftnav:piksi_multi_block_diagram.png?direct&900 |Piksi Multi HW Specification v2.2, p.3}}] |
| |
| ===== Connectivity ===== | ===== Connectivity ===== |
| Like just about every other commercial GNSS receiver, especially rugged ones, the Duro uses unique connectors for power, serial, ethernet, etc. Unfortunately un-casing the unit does not readily provide access to these signals internally, so using the connectors as intended is the best course of action for working with the Duro. | Like just about every other commercial GNSS receiver, especially rugged ones, the Duro uses unique connectors for power, serial, ethernet, etc. Unfortunately un-casing the unit does not readily provide access to these signals internally, so using the connectors as intended is the best course of action for working with the Duro. |
| |
| At the time of this writing, Carnegie Robotics still sells the interface cables for the Duro, and they are relatively affordable. | The connectors used are standard M12, which are slightly more available than LEMO or Fischer, and the user manual documents them well, if you choose to make your own cables. Behind an access panel there is a microSD slot and MicroUSB port. Using these is not sanctioned by Swift Navigation or Carnegie Robotics and will ruin the device's IP rating. |
| | |
| https://shop.carnegierobotics.com/collections/duro-accessories | |
| | |
| The connectors used are standard M12, which are slightly more available than LEMO or Fischer, and the user manual documents them well, if you choose to make your own cables. | |
| |
| | <note>At the time of this writing, Carnegie Robotics [[https://shop.carnegierobotics.com/collections/duro-accessories|still sells the interface cables]] for the Duro, and they are relatively affordable.</note> |
| |
| ==== MicroUSB ==== | ==== MicroUSB ==== |
| 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 ==== |
| * An [[https://web.archive.org/web/20200811154010/https://support.swiftnav.com/support/solutions/articles/44001850760-duro-specification-and-user-manual|August 2020 capture]] of the Duro specification page states "Duro contains 32 GB on-board storage for data logging which is not yet supported but planned to be released with a future firmware release." but it's not clear if this ever happened. The latest revision of the Duro User Manual (4.4) which has Carnegie Robotics branding, clearly states "Warranty is voided if Duro back access panel is opened." | * An [[https://web.archive.org/web/20200811154010/https://support.swiftnav.com/support/solutions/articles/44001850760-duro-specification-and-user-manual|August 2020 capture]] of the Duro specification page states "Duro contains 32 GB on-board storage for data logging which is not yet supported but planned to be released with a future firmware release." but it's not clear if this ever happened. The latest revision of the Duro User Manual (4.4) which has Carnegie Robotics branding, clearly states "Warranty is voided if Duro back access panel is opened." |
| |
| * A number of "typical" GNSS features were on the road map, but never implemented - hot starts, warm starts, and RTC backup with an external battery or supercap. Essentially, every boot is a cold-start, though I suspect it saves almanacs and ephmerides and will use them if they are valid, after a restart. {{ :swiftnav:duro:cell_duro.png?direct&200|}} | * A number of "typical" GNSS features were on the road map, but never implemented - hot starts, warm starts, and RTC backup with an external battery or supercap. Essentially, every boot is a cold-start, though I suspect it saves almanacs and ephmerides and will use them if they are valid, after a restart. [{{ :swiftnav:duro:cell_duro.png?direct&200|Photo credit Swift Navigation}}] |
| |
| * The Duro carrier board has two 10 pin headers arranged in what appears to be the appropriate footprint for an XBee module, and there is space inside the enclosure for one. The microSD slot is also shared with a SIM slot. In early documentation there are photos of the Duro with an SMA connector next to the TNC connector - presumably there were plans to give the Duro its own connectivity, but they were abandoned. The product summary document from March 2018 describes the cellular modem as a beta feature. | * The Duro carrier board has two 10 pin headers arranged in what appears to be the appropriate footprint for an XBee module, and there is space inside the enclosure for one. The microSD slot is also shared with a SIM slot. In early documentation there are photos of the Duro with an SMA connector next to the TNC connector - presumably there were plans to give the Duro its own connectivity, but they were abandoned. The product summary document from March 2018 describes the cellular modem as a beta feature. |
| |
| 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. |
| |
