Because X440 images now can also contain DDC/DUC we cannot direct
connect the radio with the replay block anymore. Instead we have
to rely on the uhd.rfnoc util connect_through_blocks function
which will find a route through the statically connected DDC/DUC
if they are present or connect the SEPs directly if they are not.
rfnoc_rx_replay_samples_to_file.py could hang and then abort with
"Timeout while loading replay buffer!" whenever the requested sample
rate was not an integer divisor of the master clock rate. For example,
requesting 200 Msps at an MCR of 368.64 MHz would leave the record
buffer stuck at exactly 50% fullness.
Two problems combined to cause this:
First, the rate was read back from the DDC before the graph was
committed. At that point the DDC's input sample rate property is not
yet valid, so set_output_rate() falls back to setting the output edge
property and returns the uncoerced, requested rate. The example then
reported a rate that the DDC never actually applied.
Second, run_capture() derived the number of samples to request from the
radio with int(radio_rate / rate), truncating instead of rounding. With
a radio rate of 368.64 Msps and a nominal rate of 200 Msps this yielded
a ratio of 1 rather than the decimation the DDC had actually settled on,
so the radio was told to produce only half the samples needed to fill
the record buffer.
The rate is now read back with get_output_rate() after graph.commit(),
when property propagation has completed, and the user is warned when
the requested rate had to be coerced. The rate ratio is computed with
rounding, so the radio is asked for the full number of samples the
record buffer needs.
While here, fix two related issues in the readback path. The DDC port
is now taken from the destination port of the discovered edge rather
than assuming it matches the radio channel index, and the rate is read
per channel (from the DDC where one is present, otherwise from the
radio) so that chains without a DDC are not ignored. Rates are compared
against a tolerance rather than for exact float equality.
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
Without this change, kernel 6.12 generates the following warning:
nixge 40000000.ethernet (unnamed net_device) (uninitialized): fixed link full duplex 1000Mbps not recognised
With the change, the link is correctly detected as 1G:
nixge 40000000.ethernet sfp0: configuring for fixed/gmii link mode
Fixed an issue when multiple timed DDS commands were present, where
the first one was popped and then the second command immediately
got popped as well to the stale a lookahead signal.
The fix is to clear the lookahead signal and threshold signal on
every fifo pop command.
- Fix target link libraries (UHD::uhd instead of uhd)
- Updated README
- Better describe the different ways to build the FPGA bitfiles
- Mention pybind11 requirement
- Add x410 image core to CMakeList to enable using make for this image
We see this warning about lingering references during UHD operations
like image load even if they are not. We did some testing to verify.
It seems the garbage collector could take some time to remove these
reference. But the warning here could be misleading. Hence, removed.
UHD hosts <4.10 speak mprpc and unconditionally connect to the RPC port
(49601) of any device they discover. When they reach a gRPC-based MPM
device, the protocol mismatch crashes uhd_find_device.
UHd host 4.10, prevents this by using rpc_version key from discovery
response and skips RPC attempt if mprpc device found during
uhd_find_devices.
This change moves the RPC port to 49602. Now, old UHD <4.10 hosts can
still discover both mprpc and grpc devices. But their mprpc connection
attempt on 49601 during uhd_find_devices is refused by grpc device
(running on new rpc port 49602) and is marked as not reachable instead
of crashing.
Since with the availability of discoverable features in Python it is
possible to use the front panel SPI of the X4xx series from there, this
example shows how to do this. It is pretty much on par with the C++
version.
