Easiest way to transmit CW frequency and measure received IQ?

Hi there! I’m an uber noob when it comes to SDR and especially LimeSDR. I have a LimeSDR-mini and wish to simply set a particular transmit power and frequency to then measure raw IQ from the receiver. Right now I have the TX directly connected to RX with a 10dB attenuator.

What is the easiest tool to use to accomplish this? GRC? LimeSuiteGUI? SoapySDR backend? I don’t need to do any processing of the data on the MCU or anything. If I can get raw IQ via python or something that would be ideal.

Ideally I would also like to do the following:

  • calibrate transmitted power? is this possible with onboard hardware? Obviously setting the gain is pretty easy but is there an easy way to know what the output power is at TX port with reasonable accuracy?
  • Quickly sweep a particular frequency range. I have tried to look up some discussion on this, and it seems like this might be pretty difficult.
  • Bonus points: has anyone performed TDR measurements using a LimeSDR? How doable is this?

I’m not really asking for anyone to figure this out for me obviously. BUT if you have any advice or know if any of this is doable PLEASE let me know!

Not sure if it’s easiest, but I currently just write C programs for anything I want to do, using the SoapySDR library (see C interface) with a driver/module for the LimeSDR provided by the Lime Suite.

Don’t forget to initialize the gain component “PAD” to 52.0 for maximum output power. The “IAMP” gain component should usually bet set to 0.0. It’s also important to set the antenna correctly, but I think “AUTO” is a valid setting.

If you want to transmit a single CW frequency, simply output (I, Q) = (1.0, 0.0) as samples. In that case, the device will emit a CW signal on whichever frequency it has been set to during initialization.

If you want to do a frequency sweep, you need to calculate the phase for each sample and then set the in-phase component I to cos(phase) and the quadrature component Q to sin(phase) for each sample. The cosine and sine describe a circle on the complex I/Q-plane. If you rotate with a frequency of 1 Hz counter-clockwise around the center point (0, 0), the resulting frequency will be the center frequency (that you set as frequency during initialization) plus 1 Hz. If you rotate with 2 Hz counter-clockwise, the resulting frequency will be the center frequency plus 2 Hz, and so on. Rotating clockwise (instead of counter-clockwise) results in frequencies emitted that are below the center frequency (instead of above).

That’s how I would do it, but I’m pretty sure there are some graphical tools that are easier in that regard. Maybe using GNU Radio?

Thanks for the suggestions!

So LimeSuiteGUI gives me anxiety. I’m pretty overwhelmed with all the options and parameters in there. I haven’t taken the time to get into the C or Python backends yet, but I did a simple GRC program.

So it’s easy enough to just put a constant source into the Lime Sink like so:

And receive like this:

Unfortunately that results is garbage:

However, when I do a simple Cosine source, it looks as expected:

The goal here is to get relative phase differences between the transmitted and received carrier signals. Are DC corrections enabled by default on the receiver? I can’t think of any reason why this wouldn’t work otherwise.

Me too :fearful:

Beautiful piece of art :grin:

I would suspect so. Can you try to set your RX frequency off by 10 kHz or so? I think the TX side should not have any issues with DC.

It’s really meant for advanced uses, where you might need to tune some obscure configuration parameter, and not for general usage.

Nothing wrong with a software that can tweak everything on board. I still would like to learn more about those “obscure configuration parameters” :smiley: (but not sure where to start). I guess documentation is still work in progress or is there any good starting point to get into it?

Until now, I’ve been doing all filtering in software (using a lightweight FFT implementation for C and a fast-convolution algorithm), but I think it would be awesome to actually use the GFIR on chip or other cool feature that I might not even know about yet.

The transceiver datasheet is a good start:


And then:

Have often thought that a reimplementation of LimeSuiteGUI, which was based on a hierarchical block diagram, where you could drill down and states were reflected in colours and textures etc., would be pretty nice. In any case, I just need to make very clear that this is not currently planned, before engineering colleagues with plenty to do already give me a stern look :smiley:

1 Like

I see that there is a function called “disable_DC_corrections()” in device_handler.cc

However, that is not implemented in the python wrapper for the “sink” object. I was going to try manually disabling the DC corrections in the GRC generated python file, but this function is not implemented (seen here).

Any chance that could be added?

One for @Garmus, but feel free also to add an issue to the tracker.