I want to make a software defined radio, based on the hardware device shown in the schematic diagram below.

This device is CALLISTO. It can graph solar radio wave activity.

I don't have a strong background in telecommunication engineering (I'm an electrical engineering student); but right now I have to solve this problem as a part of a project in my internship program.

I have a USRP B200 and I want to use a GNU Radio Companion to process the signal. At first, I just tried to recreate each block into GRC. But apparently, that's not the way it works. So, I hope someone can give me a reference on how to manipulate this schematic diagram using a software defined radio to produce exactly the same result. I know it's a lot to ask, but please help me. I'm willing to learn this.

  • 1
    $\begingroup$ so, what exactly is it that you need to build? The B200 is a software-defined radio hardware, but it has a different architecture than your picture. I'm confused about what you want to achieve. What does this do? $\endgroup$ – Marcus Müller Jun 6 '17 at 7:10
  • $\begingroup$ im trying to recreate a device called CALLISTO using USRP and GRC, you can look it up in here e-callisto.org , basically its solar radio spectrometers $\endgroup$ – gilang Jun 7 '17 at 2:07
  • $\begingroup$ Then you should describe the math it's supposed to be implementing rather than the hardware device. The hardware is different, but you can possibly implement the same purpose! For example, if you go to someone who builds custom cars with a drawing of an ox carriage, he'll have a hard time building something similar. If you go there and tell them "I need something to carry grain from home to the mill", then they can help you. You're showing us the ox carriage, but we'd need to know what you need to get done! $\endgroup$ – Marcus Müller Jun 7 '17 at 5:38
  • $\begingroup$ you're right I just realized that's what I supposed to do but apparently the math behind it that lay on the code of that hardware is so hard for me to understand $\endgroup$ – gilang Jun 7 '17 at 6:21

In general, a software-defined radio and one implemented in hardware will have much the same signal paths, but how they are broken down into individual “blocks” will vary. In your case, following the main signal path from left to right:

  • It looks like everything on the main path to the left of “Log Detect” is a conventional superheterodyne receiver. These are mostly parts that your USRP SDR hardware will replace. Everything after it would be be implemented in software. The I²C bus is presumably used for tuning and instead you will just use the methods of the USRP source block to change frequency. (Internally, this corresponds to communicating with the USRP over USB, but that is not something your code interacts with directly.)

  • The next step will be to apply the appropriate frequency shift and low-pass filter (corresponding to the BPF in the diagram) to extract the actual desired signal. The USRP has its own filtering but it will not be optimized for your particular signal. You can read about these steps in any tutorial for building receivers in GNU Radio.

  • At this point you will also want to downsample (a.k.a. decimate) the signal down to the lowest sample rate that still preserves the signal features you care about without consuming too much CPU power. Again, this should be covered in any good SDR tutorial. You should look at how the existing microcontroller code referenced in that diagram operates — in particular, how often the ADC is sampled.

  • Now we get to things specific to your application. The GNU Radio software analogue of a log detector is the Complex to Mag^2 (gnuradio.blocks.complex_to_mag_squared) block followed by the Log10 (gnuradio.blocks.nlog10_ff) block.

  • The next block in your diagram is an ADC (which function has already been handled by the USRP, of course) inside a microcontroller. The diagram doesn't tell us what the program does, so you'll have to look into that yourself. If it's standard straightforward DSP operations, then you can likely use existing GNU Radio blocks, but you may have to write a custom block. Or, you can have the signal exit GNU Radio (via some sink block) to another program or non-GR code that implements the same algorithm the microcontroller does to produce the output to the "Focal Plane Unit".

  • Everything else on the diagram — the “Clock Buffer”, the low pass filters, and voltage regulators — is just supporting hardware that is entirely irrelevant to the actual signal processing task.

So, that's everything that we can conclude just from the diagram you provided.

I strongly recommend that you find a couple tutorials on building basic software-defined receivers with GNU Radio. Even though they won't be dealing with your particular radio protocol, they will introduce the fundamental concepts of A/D conversion, quadrature, filtering, and downsampling. They're not very complex at all and once you understand those things, your problem and solution will make much more sense to you.

| improve this answer | |

To add to Kevin's excellent answer above, look at https://wiki.gnuradio.org/index.php/Tutorials (GNU Radio tutorials for every user level) and in particular https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations (which includes building a working Software Radio Broadcast FM Receiver with GNU Radio).

| improve this answer | |
  • 1
    $\begingroup$ Hi Barry, and thanks for posting! Would you please consider summarizing content from the linked web pages in your answer? I realize that the linked tutorials are pretty comprehensive. I ask because links often tend to rot, and if the answer contains the gist of the linked pages, then the answer can still be useful even if the link does rot. 73! $\endgroup$ – rclocher3 Apr 29 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.