wiki.millerjs.org

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:10] – [Notes and Curiosities] adminswift_nav_duro [2026/03/23 15:34] (current) – [MicroUSB] millerjs
Line 50: Line 50:
 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 ====
swift_nav_duro.1774037438.txt.gz · Last modified: by admin
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki