1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
/*! \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
The RJ45 port (eth0) comes up with a default configuration of DHCP,
that will request a network address from your DHCP server.
The SFP+ (eth1, eth2) ports are configured with static addresses 192.168.10.2/24
and 192.168.20.2/24 respectively.
The configuration for the ethX port is stored in /etc/systemd/networkd/ethX.network.
For configuration please refer to the manual pages
<a href=https://www.freedesktop.org/software/systemd/man/systemd.network.html> systemd-networkd manual pages</a>
The factory settings are as follows:
eth0 (DHCP):
[Match]
Name=eth0
[Network]
DHCP=v4
[DHCPv4]
UseHostname=false
eth1 (static):
[Match]
Name=eth1
[Network]
Address=192.168.10.2/24
[Link]
MTUBytes=9000
eth2 (static):
[Match]
Name=eth2
[Network]
Address=192.168.20.2/24
[Link]
MTUBytes=9000
Note: Care needs to be taken when editing these files on the device, since vi / vim sometimes generates
undo files (e.g. /etc/systemd/networkd/eth1.network~), that systemd-networkd might pick up.
Note: Temporarily setting the IP addresses via ifconfig etc will only change the value till the next reboot / reload of the FPGA image.
\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 or hostname which to connect the RPC client. Defaults to `addr'.| All N3xx | mgmt_addr=ni-sulfur-311FE00 (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
discovery_port | Override default value for MPM discovery port. | All N3xx | discovery_port=49700
rpc_port | Override default value for MPM RPC port. | All N3xx | rpc_port=49701
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:
|
