/*! \page page_usrp_n3xx USRP N3xx Series
\tableofcontents
\section n3xx_feature_list Comparative features list
- Hardware Capabilities:
- Dual SFP+ Transceivers (can be used with 1 GigE, 10 GigE)
- External PPS input & output
- External 10 MHz input & output
- Internal 25 MHz reference clock
- Internal GPSDO for timing, location, and 20 MHz reference clock + PPS
- External GPIO Connector with UHD API control
- External USB Connection for built-in JTAG debugger and serial console
- Xilinx Zynq SoC with dual-core ARM Cortex A9 and Virtex-7 FPGA
- Software Capabilities:
- Full Linux system running on the ARM core
- Runs MPM (see also \ref page_mpm)
- FPGA Capabilities:
- Timed commands in FPGA
- Timed sampling in FPGA
- RFNoC capability
The N3XX series of USRPs is designed as a platform. The following USRPs are
variants of the N3XX series:
\section n3xx_feature_list_mg N310 (4-channel transceiver)
- Supported master clock rates: 200 MHz and 184.32 MHz
- 4 RX DDC chains in FPGA
- 4 TX DUC chain in FPGA
\section n3xx_getting_started Getting started
This will run you through the first steps relevant to get your USRP N300/N310
up and running.
\subsection n3xx_getting_started_assembling Assembling the N300/N310 kit
tbw
\subsubsection n3xx_serial Serial connection
It is possible to gain root access to the device using a serial terminal
emulator. Most Linuxes, OSX, or other Unix flavours have a tool called 'screen'
which can be used for this purpose, by running the following command:
$ sudo screen /dev/ttyUSB2 115200
The exact device node depends on your operating system's driver and other USB
devices that might be already connected.
(TODO: Expand upon how to figure this out, include /dev/serial/by-id)
You should be presented with a shell similar to the following
root@ni-sulfur-<serial>:~#
\subsubsection n3xx_ssh SSH connection
The USRP N-Series devices have two network connnections: The dual SFP ports,
and a RJ-45 connector. The latter is by default configured by DHCP; by plugging
it into into 1 Gigabit switch on a DHCP-capable network, it will get assigned
an IP address and thus be accessible via ssh.
In case your network setup does not include a DHCP server, refer to the section
\ref n3xx_serial. A serial login can be used to assign an IP address manually.
After the device obtained an IP address you can log in from a Linux or OSX
machine by typing:
$ ssh root@192.168.10.42
where the IP address depends on your local network setup.
(TODO: Add the hostname thing here)
On Microsoft Windows, the connection can be established using a tool such as
Putty, by selecting a username of root without password.
You should be presented with a shell similar to the following (FIXME):
root@ni-sulfur:~#
\subsection n3xx_getting_started_connectivity Network Connectivity
tbw (Using ifconfig, using systemd to set static IPs)
\subsection n3xx_getting_started_security Security-related settings
The N3XX ships without a root password set. It is possible to ssh into the
device by simply connecting as root, and thus gaining access to all subsystems.
To set a password, run the command
$ passwd
on the device.
\subsection n3xx_getting_started_fpga_update Updating the FPGA
tbw (using uhd_image_loader)
\section n3xx_usage Using an N3XX USRP from UHD
Like any other USRP, all N3XX USRPs are controlled by the UHD software. To
integrate a USRP N3XX into your C++ application, you would generate a UHD
device in the same way you would for any other USRP:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto usrp = uhd::usrp::multi_usrp::make("type=n3xx");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For a list of which arguments can be passed into make(), see Section
\ref n3xx_usage_device_args.
\subsection n3xx_usage_device_args Device arguments
Key | Description | Supported Devices | Example Value
---------------------|------------------------------------------------------------------------------|-------------------|---------------------
addr | IPv4 address of primary SFP+ port to connect to. | All N3xx | addr=192.168.30.2
second_addr | IPv4 address of secondary SFP+ port to connect to. | All N3xx | second_addr=192.168.40.2
mgmt_addr | IPv4 address which to connect the RPC client. Defaults to `addr. | All N3xx | mgmt_addr=10.1.2.3 (can also go to RJ45)
master_clock_rate | Master Clock Rate in Hz | N310 | master_clock_rate=125e6
identify | Causes front-panel LEDs to blink. The duration is variable. | N310 | identify=5 (will blink for about 5 seconds)
serialize_init | Force serial initialization of daughterboards. | All N3xx | serialize_init=1
skip_dram | Ignore DRAM FIFO block. Connect TX streamers straight into DUC or radio. | All N3xx | skip_dram=1
skip_ddc | Ignore DDC block. Connect Rx streamers straight into radio. | All N3xx | skip_ddc=1
skip_duc | Ignore DUC block. Connect Rx streamers or DRAM straight into radio. | All N3xx | skip_duc=1
ref_clk_freq | Specify the external reference clock frequency, default is 10 MHz. | N310 | ref_clk_freq=20e6
init_cals | Specify the bitmask for initial calibrations of the RFIC. | N310 | init_cals=0x4DFF
init_cals_timeout | Timeout for initial calibrations in milliseconds. | N310 | init_cals_timeout=45000
tracking_cals | Specify the bitmask for tracking calibrations of the RFIC. | N310 | tracking_cals=0xC3
rx_lo_source | Initialize the source for the RX LO. | N310 | rx_lo_source=external
tx_lo_source | Initialize the source for the TX LO. | N310 | tx_lo_source=external
\subsection n3xx_usage_sensors The sensor API
\section n3xx_rasm Remote Management
- Mender
- Salt
tbw
\section n3xx_theory_of_ops Theory of Operation
The N3xx-series are devices based on the MPM architecture (see
also: \ref page_mpm). Inside the Linux operating system running on the ARM
cores, there is hardware daemon which needs to be active in order for the
device to function as a USRP (it is enabled to run by default).
A large portion of hardware-specific setup is handled by the daemon.
tbw
\section n3xx_mg N310-specific Features
\subsection n3xx_mg_eeprom Storing user data in the EEPROM
The N310 daughterboard has an EEPROM which is primarily used for storing the
serial number, product ID, and other product-specific information. However, it
can also be used to store user data, such as calibration information.
Note that EEPROMs have a limited number of write cycles, and storing user data
should happen only when necessary. Writes should be kept at a minimum.
Storing data on the EEPROM is done by loading a uhd::eeprom_map_t object into
the property tree. On writing this property, the driver code will serialize
the map into a binary representation that can be stored on the EEPROM.
*/
// vim:ft=doxygen: