ADALM-PLUTO as VHF/UHF Spectrum Analyzer and a Tracking Generator

[Kalvin]

Hi All,

I have been playing this evening with the Pluto and GNU Radio Companion, and I have been able to make Pluto to perform as a spectrum analyzer and a tracking generator. Pluto can TX a carrier wave as a tracking generator, and simultaneously RX the sent carrier wave for the power estimation.

Edit: Please find the latest software version in reply #6 which also solves the performance issues stated in this original message.

----

The GNU Radio Companion flowgraph can be found as an attachment below. A quick'n dirty proof-of-conecpt Python code is currently as follows:

Code: [Select]

def main(top_block_cls=analyzer, options=None):
    if options is None:
        options, _ = argument_parser().parse_args()
    tb = top_block_cls(freq_step=options.freq_step, plutoip=options.plutoip, rf_bw=options.rf_bw, start_freq=options.start_freq, stop_freq=options.stop_freq)
    # Analyzer code starts here:
    import time
    for f in range(int(options.start_freq), int(options.stop_freq), int(options.freq_step)):
        tb.set_curr_freq(f)
        tb.blocks_vector_sink_x_0.reset()
        tb.start()
        time.sleep(0.5)
        time.sleep(0.5)
        tb.stop()
        rms = tb.blocks_vector_sink_x_0.data()[-100:]
        rms_dB = sum(rms) / len(rms)
        print f, rms_dB
    tb.wait()

The biggest problem is that changing the carrier frequency requires a delay of one seconds or so in order to let the TX and RX signals stabilize. There is a discussion thread at Analog which should provide solution to this, but unfortunately I couldn't make it work after one hour of struggle: https://ez.analog.com/university-program/f/q-a/91477/adalm-pluto-how-to-change-settings-with-quick-settling

Anyway, if the problem with the frequency stepping could be solved, Pluto could be used as an handy and inexpensive spectrum analyzer with a tracking generator in the VHF and UHF frequencies. I guess Pluto could be turned into a simple VNA if the TX and RX signals could be phase locked.

[scatha]

Instead of altering the carrier frequency it'll be quicker performing the sweep at baseband by changing the frequency of your VCO within the 20 MHz instantaneous bandwidth of the Pluto, no need to retune the frontends. Of course you'll need to use a combination of the two techniques to sweep wider ranges.

[Kalvin]

Instead of altering the carrier frequency it'll be quicker performing the sweep at baseband by changing the frequency of your VCO within the 20 MHz instantaneous bandwidth of the Pluto, no need to retune the frontends. Of course you'll need to use a combination of the two techniques to sweep wider ranges.

I was experimenting with that and the results were good. The flowgraph has this block "Constant Soiurce" feeding the VCO (Complex) outputting a changing TX "carrier sweep", and the output spectrum looks really good and the VCO changes fast without any problems whatsoever. It is just annoying that one has to wait for one second or so if the actual TX center frequency "LO Frequency" needs to be changed.

Using Pluto as VNA: It seems that Pluto's TX and RX clocks cannot not be phaselocked as taken from https://ez.analog.com/university-program/f/q-a/102190/iio-rx-buffer-is-chopped-and-filled-with-zeros-rx-tx-synchronization/305999#305999 :

RX and TX have independent LOs, which makes their phases random and will change slightly when they move. When you go beyond 100MHz from an initial value, the VCO will recalibrate and have a completely new phase. There really is no pattern to the phase offsets. Since the VCO is within the part there is nothing we can really do in the FPGA to compensate for this. If you have a AD9361 you can use external LOs but AD9363s do not support this option.

However, one could use the on-chip RX & TX loopback feature for measuring the phase difference each time one changes the LO Frequencies ie. getting the reference phase. Not sure yet how easy or hard this may be, but it may provide a practical way for getting the reference phase values required by the VNA.

[RoGeorge]

If the Rx/Tx LO phase is a problem, maybe starting with a scalar network analyzer first will be the way to go.  Then, see what other tricks can be implemented.

[Kalvin]

If the Rx/Tx LO phase is a problem, maybe starting with a scalar network analyzer first will be the way to go.  Then, see what other tricks can be implemented.

Yes, that is the plan. Scalar analyzer is quite simple thing to do as it doesn't require phase coherency. The RX part still needs demodulation and "video filter" after which Pluto would then work as a simple scalar spectrum analyzer and a tracking generator. Hopefully generating the tracking signal using VCO instead of stepping the LO carrier frequency will provide better repeatability to measurements so that Pluto could be a useful $99 spectrum analyzer for the frequency range 70 MHz - 3.8 GHz.

I haven't really been using Pluto or GNU Radio before, so it will take some time to get things done in a proper way, but at least Pluto is generating stimulus and receiving the response although the current quick'n dirty solution is not the most elegant way.

[Kalvin]

Some background here: I built a multiielement, dual-band Moxon antenna for 2m and 70cm but I do not have an antenna analyzer, so I cannot tell how well the antenna performs and what is the SWR. But I do have Pluto, RF Bridge 0.1 - 3000 MHz and a BG7TBL noise generator at hand. Using the noise generator is plan b, if getting Pluto to work as a tracking generator goes bust. The first experiments with Pluto and GNU Radio looks very promising though, so I will continue exploring that path. Of course using Pluto as spectrum analyzer and tracking generator would be a useful tool for other amateur radio work as well, like building and measuring filters etc. As Pluto is lacking band filters it will receive the harmonics as well as the actual signal, using Pluto for example measuring the harmonics of the transmitter needs some thinking.

[Kalvin]

For those interested in playing and experimenting with Pluto, here is the source code for this quick'n dirty, experimental and very rudimentary spectrum analyzer and tracking generator.

Addition: I have two attenuators connected to Pluto: TX = - 10 dB and RX = -20 dB.

From the source file plutosa.py:

Code: [Select]

# Pluto SDR Based Spectrum analyzer and Tracking
# Generator using GNU Radio Python Flow Graph.
#
# This is a quick and experimental hack for using
# ADALM-PLUTO as a rudimentary spectrum analyzer and
# a tracking generator.
#
# Usage example for scanning the 2m amateur band:
#
# $ python plutosa.py --start-freq=144e6 --stop-freq=146e6 --freq-step=10e3
#
# The software will output the frequency and the measured
# signal level:
#
# > IIO context created:network
# > Backend version: 0.15 (git tag: v0.15  )
# > Backend description string: 192.168.2.1 Linux (none) 4.9.0-10475-g2398d50 #269 SMP PREEMPT Mon Oct 15 20:18:34 CEST 2018 armv7l
# > Step time = 0.105
# > 144000000 -17.0538330078
# > 144010000 -16.5327987671
# > 144020000 -16.1735343933
# > 144030000 -16.1947441101
# etc.
#
# The system was developed and tested on 64-bit
# Linux Mint version 18.3.
#
# The ADALM-PLUTO was patched for frequency extension
# providing frequency range of 70 MHz - 6 GHz, and
# for dual-core support.

Latest updates as Mar 15, 2019:

- Added command line option for the step time
- Added support for logarithmic sweep
- Added command line option for the RX gain
- Added filtering modes (running average and running median)
- Faster sweep time as the GNU radio graphs is kept running constantly
- Greatly improved measurement noise performance

Code: [Select]

$ python plutosa.py -h
Usage: plutosa.py: [options]

Options:
  -h, --help            show this help message and exit
  --plutoip=PLUTOIP     Set Pluto Device [default=ip:192.168.2.1]
  --start-freq=START_FREQ
                        Set Start Freq [default=142M]
  --stop-freq=STOP_FREQ
                        Set Stop Freq [default=146M]
  --freq-step=FREQ_STEP
                        Set Frequency Step [default=100k]
  --logsweep=LOGSWEEP   Perform logratihmic sweep with given step count
                        [default=none]
  --vbw=VIDEO_BW        Set Video BW [default=1000]
  --ifbw=IF_BW          Set IF BW [default=20000]
  --rmsa=RMS_ALPHA      Set Video RMS alpha [default=1m]
  --rxgain=RX_GAIN      RX gain in dB [default=64.0]
  --txlevel=TX_LEVEL    Set TX output level [default=100m]
  --steptime=STEP_TIME  Set minimum step time [default=none]
  --filtermode=FILTER_MODE
                        Select filter mode (0=None, 1=average, 2=median)
                        [default=0]
  --filterwidth=FILTER_WIDTH
                        Select filter sample window width [default=5]

Hopefully someone finds this simple application useful when getting started with programming Pluto, or when an owner of a Pluto needs a simple RF analyzer from 70 MHz - 6 GHz.

Br,
Kalvin

[Kalvin]

Hi!

Please find the updated plutosa.py main file in the message above. It implements some missing features.

Br,
Kalvin

[Bicurico]

Hi Kalvin,

I am interested in interfacing your script with my VMA Simple Spectrum Software (which runs on Windows). More info on my blog: https://vma-satellite.blogspot.com/

As soon as free time allows, I will see if i can get your code to run on my Windows based GNU Radio Setup and hopefully I can hack a special version of my software. This is what I tried to do with the HackRF unit using hackrf_sweep.exe, but the firmware has a nasty bug which makes the HackRF crash after each sweep: https://vma-satellite.blogspot.com/2017/12/teaser-vma-simple-spectrum-analyzer-for.html

I want to see what kind of performance is to be expected... Luckily I own two PlutoSDR units, which have been sitting in their boxes for some while now.

Regards,
Vitor

[Kalvin]

UPDATE: These measurements are now obsolete as those were made using the old version of the software. The updated results can be found in the later replies.

I will leave these measurement results here for historical reasons.

----

Here are three measurements that I have run for testing purposes:

1. An FM filter (RTL-SDR.com), sweep from 70 MHz to 125 MHz.

2. Test sweep 144 MHz - 146 MHz using no attenuator, -10 dB attenuator, -20 dB attenuator, -30 dB attenuator and measurement noise floor (50 ohm termination).

3. Cheap RF Bridge from eBay, sweep 100 MHz - 3GHz with a direct cable measurement along with the RF bridge return loss with cheap 50 ohm terminations.

Note: I had additional attenuators connected to Pluto during these tests for the best spectral purity: TX = -10 dB and RX= -20 dB.

The graphs are shown below. Pluto's performance close to 70 MHz is somewhat limited and the measurements will contain some noise below 100 MHz which can be filtered out by the software. The dynamic range is around 45 dB, but it can probably be extended by dropping the extra attenuators after checking that the RX nor TX won't be overloaded.

Edit: It was found that Pluto's TX signal leaks somewhat into RX, limiting the maximum achievable dynamic range. Disabling the TX or setting the TX level to 0 will gain 20 dB - 30 dB more dynamic range.

Br,
Kalvin

Edit: Added the RF Bridge sweep image.

[Kalvin]

Hi Kalvin,

I am interested in interfacing your script with my VMA Simple Spectrum Software (which runs on Windows). More info on my blog: https://vma-satellite.blogspot.com/

As soon as free time allows, I will see if i can get your code to run on my Windows based GNU Radio Setup and hopefully I can hack a special version of my software. This is what I tried to do with the HackRF unit using hackrf_sweep.exe, but the firmware has a nasty bug which makes the HackRF crash after each sweep: https://vma-satellite.blogspot.com/2017/12/teaser-vma-simple-spectrum-analyzer-for.html

I want to see what kind of performance is to be expected... Luckily I own two PlutoSDR units, which have been sitting in their boxes for some while now.

Regards,
Vitor

Hopefully you can get the software running in the Windows machine. I do not have Windows machine for development purposes, so I cannot test Pluto and the code in Windows environment.  With some luck you might get the setup up and running without too much of difficulty,

[Bicurico]

Hello Kalvin,

I got it running on Windows.

Here my feedback:

1) The pluto-ip parameter does not seem to work. I had to change the Pluto's IP address back to 192.168.2.1 to run your scripts.
2) The spectrum sweep is slow. Very slow. Like 2 samples per seconds! That is samples, not sweeps!

Your script is cool and useful - don't get me wrong! I just imagined it would be as fast as hackrf_sweep (a sweep is almost instantaeous).

If this could be speeded up, i.e. by using C++ instead of Python, perhaps a link to my software would be possible. As it is, I won't bother, as it is not usable for me.

But again - your script is great and does have interesting applications.

Kind regards,
Vitor

[Bicurico]

Here is a picture of my CATV (contains analogue channels and a few DVB-T transponder). The signal comes on fibre into my home and the router converts the TV part into RF and outputs it on the F-connector for CATV distribution in the house.



The performance of the Pluto SDR is not too bad - the signal should be at around -20dBm, so it is almost 10dB off. This could easily be compensated.

The main issue is that this sweep takes like 20-30 seconds.

Meanwhile I found out that there is the option to set the steptime, but even with the lowest setting, the sweep takes too long.

But hey - still very interesting and cool!

 

Regards,
Vitor

[Kalvin]

I got it running on Windows.

Hi Vitor,

Excellent news. Did you have to struggle a lot, or was it effortless?

Here my feedback:

1) The pluto-ip parameter does not seem to work. I had to change the Pluto's IP address back to 192.168.2.1 to run your scripts.

At one point I had to add the "ip:"-prefix into the Pluto address in order to be able to connect to Pluto, so I left it there. I didn't try without the prefix after that. Good observation!

2) The spectrum sweep is slow. Very slow. Like 2 samples per seconds! That is samples, not sweeps!

Yes, that is so true, unfortunately. There are two main reasons for that:

1. I am still learning GNU radio, so I had to "single step" the graph using start() and stop() between the frequency steps in order to be able to read the RMS-value of the received signal without memory corruption.  When I figure out how to keep the GNU radio graph running constantly and how to read the values from the graph blocks without memory corruption the sweep time can be increased significantly.

2. The main cause of the slonwess comes from this: The design does not use FFT for the spectrum processing, but uses more conventional approach used in traditional spectrum analyzers. Since I wanted to use Pluto as a tracking generator, using FFT didn't quite make much of a sense in that regard. However, it is quite easy to modify the GRC-graph to contain an FFT block, too, and step the RF LO frequency quickly after each FFT computation.

By implementing this FFT approach, one could sweep the frequency ranges like 2 MHz - 3 MHz at a time, compute the FFT, and change the RX LO frequency fast. The 2 MHz l- 3 MHz imitation comes from the fact that the USB-connection will start losing samples at higher bandwidths. I have tried the maximum 56 MHz with GRQX, but the audio is very choppy. If losing samples during sweeps is not a problem, one could try to use this maximum 56 MHz sweep intervals.

I do not know yet at this point how to read the output of the GNU radio FFT block in a correct way without corrupting the memory, though. There are some GNU radio blocks that are used for interprocess communication, but I haven't had time to study then more closely yet. Of course, one can always try to step the graph by start() and stop(), and then read the FFT data from the graph.

I will update the project source code as soon as I am able to run the system without start()/stop() stepping.

Your script is cool and useful - don't get me wrong! I just imagined it would be as fast as hackrf_sweep (a sweep is almost instantaeous).
If this could be speeded up, i.e. by using C++ instead of Python, perhaps a link to my software would be possible. As it is, I won't bother, as it is not usable for me.

The apparent slowness comes from the facts stated above and the current implementation. It should not be too difficult to modify the GNC-graph to contain needed FFT block, and then read the data in the main script after each LO step.

The main achievement of my approach was to be able to set the TX and RX LO parameters on the fly - fast - using the IIO. Unfortunately I had to single step the graph because my lack of knowledge on how to do process GNU radio data properly "on the fly". So, its is not Python which slows down the process, and changing to C++ would not help as the problem is in the interprocess communication which I need to study next so that I can control the GNU radio graph from my process when the graph is running.

But again - your script is great and does have interesting applications.

Kind regards,
Vitor

Thanks, Vitor! The program works quite nicely, although it has some shortcomings. At least Pluto can be used as a spectrum analyzer and a tracking generator, which was my initial intention after all. I was able to measure my Moxon antenna, and I found out that it was bit off on both 2m and 70cm bands. Luckily the antenna was resonant at too low frequencies, so cutting a few millimeters from the elements should fix the tuning.

Br,
Kalvin

[Kalvin]

The performance of the Pluto SDR is not too bad - the signal should be at around -20dBm, so it is almost 10dB off. This could easily be compensated.

The main issue is that this sweep takes like 20-30 seconds.

Meanwhile I found out that there is the option to set the steptime, but even with the lowest setting, the sweep takes too long.

But hey - still very interesting and cool!

 

Regards,
Vitor

Hi Vitor,

You can improve the performance as follows:

- Set the TX level off during sweeps with this command line parameter: --txlevel=0
- Add some filtering with these command line parameters: --filtermode=1 --filterwidth=10

Pluto's TX will leak into RX, so setting the TX level to 0 will increase the RX's dynamic range 20 dB - 30 dB from 45 dB to 70 dB or so. The output values are not calibrated to an absolute dBm levels, so one has to add a correction constant to the measured values. Filtering parameters will add filtered measurement values after raw measurement values, which will smooth out the otherwise noisy raw measurement data.

Br,
Kalvin

[Bicurico]

Hello Kalvin,

Thanks for elaborating the principle of how your script works.

I am considering making a special version of my software for interfacing your script. It will be really slow, but perhaps still usable.

I am aware of the possibility of speeding things up using FFT, but that is actually more complicated a thing to do than what meets the eye.

Stiching together the different FFT results is one issue, as my software needs to know before hand how many samples the sweep is going to have.

The other issue is that FFT is complex math (at least for me) and most solutions use existing FFT libraries. But those libraries rely on other libraries and so on. At the end, if you want to hack an easy to install software (especially when using Visual Studio .Net), it quickly becomes a real feat.

I do like your approach a lot and actually it gives me some motivation to look at GNU Radio again. This is a fantastic software package, but again the learning curve is not linear. Doing some fairly easy things  is quickly achieved but as soon as you want to do something more complex it becomes really complicated (suddenly you need to know Python or even worse C++).

Let's see if I manage to implement a link to your script as I imagine it.

Installation was fairly easy: I had to uninstall PothosSDR and Python, because I was using v3. Then I installed PothonSDR again (last version, of course) and then installed Python v2. The biggest trouble was to get my device recognized by your script, because I used my second unit where I had changed the default Ip to 192.168.2.2. I did not remember how to change it back (eject and WAIT).

Regards,
Vitor

[Kalvin]

Hi All,

Here is the latest version of the Pluto spectrum analyzer and a tracking generator. I did manage to get rid of the start/stop of the GNU radio graph, and the graph is now running constantly during the measurement sweep. This improved the frequency sweep rate considerably, and the measurement values contain far less noise. Please find the latest source code in the original message in reply #6.

Here are the latest measurement results which shows improved performance.

1. An FM filter (RTL-SDR.com), sweep from 70 MHz to 125 MHz.

2. Linearity test sweep 144 MHz - 146 MHz using no attenuator, -10 dB attenuator, -20 dB attenuator, -30 dB attenuator and the measurement noise floor with 50 ohm termination and TX level 0.

3. Cheap RF Bridge from eBay, sweep 100 MHz - 3GHz with a direct cable measurement along with the RF bridge return loss with cheap 50 ohm terminations.

Note: I had additional attenuators connected to Pluto during these tests for the best spectral purity: TX = -10 dB and RX= -20 dB.

Br,
Kalvin

[Kalvin]

Hi All,

Since this project got started with the need for measuring the dual-band 2m and 70cm Moxon antenna I had built, I think it would be interesting/fair to show the actual measurement results of the untuned antenna.  The RF-bridge used is a cheap 10 EUR RF-bridge 0.1 MHz - 3 GHZ from eBay. Yes, the antenna needs some tuning, but fortunately I now have the needed tool for measuring its performance. Not too bad for 99 EUR Pluto and 10 EUR RF-bridge.

Br,
Kalvin

[Bicurico]

Hi.

I made a special version of my software for the ADALM PLUTO.

It always captures 560 samples, just like the R&S CMU200/CRTU does (I based this version on the CMU200/CRTU version).

While it does work, it takes so long to capture a sweep that I had to break the continuous sweep into a discrete one time sweep whenever the START button is clicked.

But this then breaks the screen refresh routine...

The sweep has to take less than 1 second for the software to be usable.

In regards to the Chinese SMA/NWT4000 devices, the trace of the Pluto looks much better, especially because it does not have the "notch" on transponders with reduced bandwidth.

Other than that, as it is, the SMA with ADF4350/ADF4351 is a much better option for spectrum measurements at just 50-60 Euro. The NWT4000, which costs 3 times as much, features a propper TG and can be used for antenna tuning, filter measurement, etc.

Unless someone hacks a nice firmware for Pluto that makes it work as a spectrum analyzer, I have my doubts on this (nice) device. The same goes for the HackRF and pretty much every other SDR of this kind. On paper they all have amazing specs. In reality, if you are not familiar with software development at firmware level, there is not that much one can do...

Regards,
Vitor

PS: The attachments show the DVB-T transponder capture with my antenna on the roof. In the right corner the mobile phone transponders are visible. Each sweep took around 20 seconds...

[OwO]

The PlutoSDR has a Zynq so it would be ideal to skip gnuradio and just implement everything directly on the FPGA. There is already an existing VNA with open source DSP logic in VHDL, maybe it can be hacked to work on the Pluto. I think you do need a reference path though.

[Bicurico]

I know that it is POSSIBLE to do, but I am illiterate to do it myself...

My guess is that once SOMEONE implements a firmware for Pluto with the following features:

- all communication over TCP/IP using SCPI commands
- supported commands:
1) set start_freq
2) set stop_freq
3) set center_freq
4) set span
5) set TG_on/TG_off
6) set attenuator/amplifier
- output: sweep with fixed set of samples (configurable through SCPI: 500, 1000, 1500)

All the rest can then be done on an external software, just like I am doing on my "VMA Simple Spectrum Analyzer" application.

Main thing is that the sweep should be fast. Fast meaning 1000 samples in much less than 1 second.

Pluto would be the ultimate amateur spectrum analyzer at 100 Euro...

Regards,
Vitor

[Kalvin]

Hi Vitor,

Here is a simple frequency "scanner"** prototype implemented using GNU Radio Companion blocks. I have Pluto patched with the frequency extension patch, so it can tune to 70 MHz - 6 GHz with 56 MHz RF bandwidth.  The GNU radio graph uses 20 MHz baseband bandwidth, and it seems to be running just fine on my PC. At least Pluto can provide 20 MHz of data over USB cable, and the PC is able to compute spectrum using the FFT, and display the spectrum along with the waterfall on the screen. The update rate is probably a few times per second, so it should be sufficfient for your purposes. Thus it is possible to capture 20 MHz at a time with high update rate even using Python with GNU Radio. Using the IIO method from my spectrum analyzer code, one can sweep a frequency range in 20 MHz steps quite fast. Using appropriate blocks from the GNU radio Frequency Analysis Blocks, and performing some experimentation, one should be able to create a fast spectrum scanner quite easily without understanding the mathematics behind FFT.

** The scanning is performed manually in this example by the frequency slider. The frequency change is a bit choppy in this example, but using the direct IIO method the frequency change will be much faster.

Br,
Kalvin

[Kalvin]

The PlutoSDR has a Zynq so it would be ideal to skip gnuradio and just implement everything directly on the FPGA. There is already an existing VNA with open source DSP logic in VHDL, maybe it can be hacked to work on the Pluto. I think you do need a reference path though.

Implementing the VNA using VHDL would require quite a huge effort compared to GNU radio approach. The easier way would be implementing the GNU radio blocks using the Zynq ARM processor(s) running in Pluto (given that the ARM(s) inside the Zynq have the  muscle to do so at sufficient sampling rate), and push the processed data through USB-port.

Actually, using Pluto as VNA may not be that simple as the Pluto's TX and RX oscillators are not locked to each other, so getting the phase reference will require some hacking: From the Discussion at Analog Devices :

RX and TX have independent LOs, which makes their phases random and will change slightly when they move. When you go beyond 100MHz from an initial value, the VCO will recalibrate and have a completely new phase. There really is no pattern to the phase offsets. Since the VCO is within the part there is nothing we can really do in the FPGA to compensate for this. If you have a AD9361 you can use external LOs but AD9363s do not support this option.

Probably one could use the on-chip RF-loopback feature to determine the present RX and TX phases at some points during the measurement.

Br,
Kalvin

[Bicurico]

Hi Kalvin,

Thanks for the feedback.

I know how to build a block sheet in Gnu Radio Companion. What I never learned is how to go from here to a Python script and especially how to change the frequencies and so on.

Imagine I take your block diagram and want to output the samples of the 20MHz sweep. Then I want to increment start frequency by 20MHz and do one sweep again. This repeated until I get the end frequency...

Is that something you can program in Python in a way that my software can get access to the samples?

Regards,
Vitor

[Kalvin]

Hi Vitor,

Here is a very simple Python program using Pluto and GNU Radio which will compute the FFT of the received signal. The FFT values are printed on the console as the program is running with 0.1 steps up to 100 times ie. 10 seconds.

Check the file top_level.py for the methods of setting and getting the graph parameters. The computed FFT data is obtained from the graph using signal probe provided by GNU Radio.

Running the program:

Code: [Select]

python plutoscanner.py

You may want to use the IIO method from my spectrum scanner when changing the RX LO frequency which will allow faster frequency stepping.

The spectrum is computed now using the Log Power FFT block which outputs only the half of the frequency band. Just use complex FFT if you want to get full bandwidth, but you may need to implement the filtering by yourself. You may want to experiment with these nice blocks, and see how you can control the FFT processing and Pluto's frequency.

If the spectrum is inverted, please add Complex Conjugate into the graph between the Pluto Source and FFT Block, and re-generate the top_level.py the flow graph.

Br,
Kalvin