pothosware / pothossoapy

Pothos framework support for software defined radio hardware.

Pothos SDR blocks

SDR source and sink blocks for interfacing SDR hardware with Pothos.

Documentation

• https://github.com/pothosware/PothosSoapy/wiki

Dependencies

• Pothos library
• SoapySDR library

Licensing information

Use, modification and distribution is subject to the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

pothossoapy's Issues

GPIO access support

Blocking on pothosware/SoapySDR#22

• register a probe to query GPIO state
  • (optional bank name parameter)
• registered calls to set mask, ddr, value
  • calls work with an without a named GPIO bank
• GPIO setter parameter
  • dictionary specifies mask, value, ddr -- operates on all banks
  • or dictionary of dictionaries (where each key is a bank)

error using sync block

Hi I'm new on pothos and I'm having a problem for using the sync block. I need to transmit a chirp signal using a usrp. Does anyone now how to fix it?

additional readbacks

• has HW time?
• various ranges
• device and driver key

Log level selection parameter

Support setting the soapy sdr log level. This is a drop down that by default, does not modify the default level. Users will set the log level to allow debug prints.

• related issue: pothosware/SoapySDR#40

multi-channel time alignment block

A block with N input and N output streams that uses time labels and selective dropping to ensure that the output stream is time aligned.

• This is a zero-copy block. Passively forward buffers.
• This is a zero-conf block, because the sdr source provides the sample rate through labels
• Provide probes for drop counts (per channel)

build check for new logger level: SOAPY_SDR_SSI

• maintain compatibility with soapy release on current master

LimeSDR TX bandwidth setting incorrect

For an application that I am currently working on I need to transmit chirp signals with a bandwidth of 15MHz.
The setup consists of a transmitting LimeSDR and a receiving LimeSDR that both operate at a sample rate of 32Msps.

I always set the RX bandwidth to 16MHz. Now, the waveforms and the spectrum that I expect look like this:

To achieve this, I usually set the TX bandwidth to 100e6.

However, if I assign TX bandwidth the values 16e6 or 32e6, I will get the following:

Can you please help me investigate that issue. It probably occurs at the interface of Pothos and the LMS7 module.
Thank you very much.

Normalize Labels for Compatibility

I propose that the label names be changed so as to match tag names found in gnuradio, so that someday some compatible behavior or even standard may evolve.

The following tag names are used in gr-uhd and gr-osmosdr/bladerf:

txTime -> tx_time
txEnd -> tx_eob
rxTime -> rx_time
rxEnd -> rx_eob
rxFreq -> rx_freq
rxRate -> rx_rate

use available antennas signal for dropdown/radio widget

Can the gui widgets handle the vector of strings for available options? If not, we should fix this.

Support for Pothos::Packet in source/sink blocks

• SDRSink checks for Pothos::Packet based messages and treats them as stream + labels.
• SDRSource uses the SOAPY_SDR_ONE_PACKET flag to produce the buffer as a packet message and not into the stream.

Doesn't build with earliest supported SoapySDR version

CMake looks for SoapySDR 0.6+, but the converter block doesn't compile because the first stable version with the converters was 0.7.

buffer integration - zero copy support

One of the strengths of the Pothos Framework is the advanced buffer integration. Naturally, we would like the source and sink blocks to provide scheduler access to underlying buffers provided by the hardware driver.

Currently blocked by a need for a demonstration driver to motivate the SoapySDR API: pothosware/SoapySDR#8

Apply cahced setting calls ASAP

The SDR block will cache any settings calls while the future is busy setting up the device handle. Currently, these cached calls are forcibly applied when the block is activated. However, they should really be applied ASAP when the device handle is setup.

Meaning that the std::future task should run through all settings calls after its finished getting a device handle. Some extra synchronization will be needed to protect the cached settings while the future is processing them because additional settings could potentially be made. Possibly, we can just make a dedicated execution thread in the place of using std::future.

Fixing this issue means that the block will continue to set itself up while the topology activates, but without blocking calls. This is because talking out to hardware can be a costly or long operation, such as calibration and waiting on time-outs. A block, its stream, and configuration will be fully setup by the time activate() is called.

Updates for latest SoapySDR 0.5 series

• parameterize setHardwareTime(), deprecate setCommandTime() In SoapySDR, we have a parameterized setHardwareTime() call for setting arbitrary timestamps. Recently, setCommandTime() has been deprecated in favor of using the parameterized setHardwareTime(). Do the matching work in SDR blocks by given setHardwareTime a "what" parameter as well.
• mark setCommandTime() deprecated
• switch to bandwidth range over bandwidth list of doubles. See getBandwidths() call in SDRBlock.cpp

add overlay options for clock and time references

demo control block

A demo control block ships with the sdr package. It has hooks to read the hw time periodically through the signals and slots, print info from a receive channel, and send TX bursts. Timed tuning.

random sample dropper - for testing

The random dropper has a chance (configurable) of dropping a random chunk of samples. After a drop, a new time stamp will be output. This block will be used for internal tests, however, users may find it helpful to test their systems in the presence of overflows.