• 0
fusionimage

Analog Discovery 2 as Software Defined Radio?

Question

Hi!

Since I've been doing a lot of stuff with SDR for the past 2 years, I was wondering, if it is possible to use the AD2 with any SDR software. The Waveforms SDK only allows to record float values to a file, if I understood correctly, so I would have to save them and convert them before usage. It would be nice though, to make a FIFO pipe to some other software like gnuradio, gqrx or SDR#. Thanks to the 14 bit ADC/DAC it would be a very useful SDR device.

Does anybody of you have an idea, of how to implement this? Since we can use the AD2 to play audio, the easiest way would be to create a virtual sound card, piping the whole spectrum (Waveforms does it in spectrum view, but without demodulation possibilities), because those can be used in any SDR software.

Thanks in advance!

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

@D@n, you were correct when you previously stated that we'll need a "sync" block.  Both source and sink blocks are implemented in code by inheriting from the "gr::sync_block" class.  From [1]:

"Sources and sinks are derived from gr::sync_block."

Building on my previous post, we'll want to start by implementing:

  • an "Analog Discovery 2 Analog Source" class that inherits from GnuRadio's gr::sync_block class, configures its gr::sync_block with an I/O signature of one 16-bit integer output, and sources its stream from one of the AD2's analog input channels
  • an "Analog Discovery 2 Analog Output" class that inherits from GnuRadio's gr::sync_block class, configures its gr::sync_block with an I/O signature of one 16-bit integer input, and sinks its stream into one of the AD2's analog output channels

@fusionimage, I looked at the project wiki for "gr-osmosdr" at [2].  It states it is "primarily being developed for the OsmoSDR hardware", but supports some other devices as well.  From this, I have the impression that those other devices are supported in gr-osmosdr as a result of scope creep rather than of design or necessity.  I'm thinking the AD2 support should be implemented as its own module.  Can you explain the specific features that you were seeking to gain by integrating with gr-osmosdr?  What software beyond GnuRadio are you seeking compatibility with?

In case anybody is curious why I specified 16-bit integer interfaces for the source and sink, take a look at GnuRadio's data types in [3].  ADC outputs and DAC inputs are discretely valued and of fixed finite precision by virtue of being digital; they map naturally to integers, which are also discretely valued and of fixed finite precision.  I specified 16 bits because that's the smallest / least expensive integer precision supported by GnuRadio that can preserve the precision of the AD2's 14-bit ADC and 14-bit DAC.  I did not specify a complex integer type because we will only be able to interface real-valued sequences with a given AD2 channel.  I did not specify a float type because they are more expensive than integers and, in this situation, don't provide any additional value over integers.

Chris

[1] https://wiki.gnuradio.org/index.php/OutOfTreeModules#Sources_and_sinks

[2] https://osmocom.org/projects/sdr/wiki/GrOsmoSDR

[3] https://wiki.gnuradio.org/index.php/Guided_Tutorial_GRC#2.2.5._Examining_the_Output

Share this post


Link to post
Share on other sites
  • 0
4 hours ago, D@n said:

Having worked with SDR's that have a single ADC as a receiver, as well as SDR's that have a synchronous pair of ADC's, I'd have to disagree with your use of the word only above.  Both can be built.  Both are used.  Each has its advantages and disadvantages.

ok, i didn't know that. what would be the pros and cons of either implementation?

@clf yes, gr-osmosdr was primarily designed for osmocom hardware, but since a lot of software uses its API, it would be great to have the ad2 running beyond gr-osmosdr or UHD (ettus universal hardware driver, devices like the LimeSDR can be used with this driver too).

1 hour ago, clf said:

Can you explain the specific features that you were seeking to gain by integrating with gr-osmosdr?  What software beyond GnuRadio are you seeking compatibility with?

the advantage would be compatibility to not only gnuradio, but also to other software like gqrx, etc.

but, you're right, if you only want to use the ad2 in gnuradio, a new block would be the best.

Share this post


Link to post
Share on other sites
  • 0
7 minutes ago, fusionimage said:

ok, i didn't know that. what would be the pros and cons of either implementation?

@fusionimage,

If the communications engineer wants I&Q, then either the hardware engineer (i.e. chip or board designer) or the DSP engineer (i.e. FPGA, embedded programmer, or other front end logic designer) is going to try to solve it.  Both solutions can work.

The biggest con's to deal with are 1) it's very difficult to get Q after the fact.  The Hilbert transform approach tends to "filter" the incoming data between f=0 and fs/2, to remove the negative frequency components (fs is your sample rate).  It doesn't add any components back in.  Hence, if you want to generate a signal centered around zero frequency with both I&Q components, you really need a different approach.  2) It can be very difficult in the analog world to match two high frequency oscillators (I&Q, cosine and sine, etc) to keep them lined up.  It's easier to match oscillators at lower frequencies--even easier in digital logic, but ... I tend to be biased.  3) When working with complex analog signals, you can easily end up with signals that have a DC component (i.e. they are centered about zero, right where you want them).  Lots of other stuff tends to wander around on a board at DC (self-interference).  Keeping that junk out of your I&Q digitizer can be a challenge. 

My favorite solution is to digitize a signal at an intermediate frequency, particularly one centered about fs/4 but with a nice guard band between the signal of interest and the two edges, f=0 and fs/2.  From here, you can downconvert digitally with no multiplies to get your I&Q samples.  Once you have the two I&Q sample streams, you can filter them both and downsample some more.  This turns the whole Hilbert transform challenge into little more than a lowpass filter design problem, where the same lowpass filter is applied (independently) to each of the I and Q channels.

One problem I had when doing this was that several different rounding methods will give you a component at DC.  Watch out for that.  ;)

Dan

Share this post


Link to post
Share on other sites
  • 0

@fusionimage,

From Gqrx's design documentation at [1]:

Gqrx is heavily based on GNU Radio using both DSP blocks as well as its famous runtime engine.

[...]

At lowest level we have various DSP and I/O blocks. These can be blocks from GNU Radio, gr-osmosdr or even implemented in gqrx.

You've mentioned GnuRadio and Gqrx by name as desired applications.  It's looking like we can satisfy these use cases by implementing a plain ol' GnuRadio module for the AD2.

Chris

[1] http://gqrx.dk/doc/gqrx-design#more-136

Share this post


Link to post
Share on other sites
  • 0

I am interested in this project, but unfortunately not likely to be able to help with programming.Some python ( too slow for this  )but no C.

May be able to help test /debug and hardware test.

I bought an AD2 hoping to see SDR developed for it , it would make the instrument so nicely functional as both a SDR and analysis tool for associated hardware.

What usable frequency range is anticipated ?

As far as hardware to implement SDR

  1. What are the thought processes for interface? AWG/Scope I/O ports ( BNC adapter boards look OK for basic connection, with 0 or 50 Ohm jumpers )
  2. With the AD2  output limits would a wideband LNA be needed right at the output for Tx?
    1.   New BNC board with amp?
    2.  "Piggy back " a  daughter board with  amp onto the standard adapter?
    3. Inexpensive Ebay wide band amp after the BNC board ( or hardwire per  #2)

Share this post


Link to post
Share on other sites
  • 0

Hi @Gregg Daugherty

The FPGA of Analog/Digital Discovery and Electronics Explorer devices cannot be reprogrammed with custom image, but custom application can be created using the WaveForms SDK or LabVIEW driver for Analog Discovery.

The OpenScope is PIC32 based open source instrumentation device which can be reprogrammed with custom firmware. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now