Jump to content
  • 0

Analog Discovery 2 as Software Defined Radio?

fusionimage

Asked by fusionimage,

Question

fusionimage Member

fusionimage

Posted
Posted

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!

Link to comment
Share on other sites

41 answers to this question

Recommended Posts

D@n Prolific Poster

D@n

Posted
Posted

@clf,

I like your IQ for dummies link!  It has good pictures and does a decent job trying to explain what's going on.  And to think ... I needed to learn all of that through hand-waving and experimentation.  The pictures are better.

The hackaday one ... not so much.  The premesis that I and Q are a nemesis wasn't well supported by the article.  Still ... the picture is well worth understanding.

I also like the descriptions because they don't try to create any Hilbert transforms.  A Hilbert transform is a theoretical mathematical device designed to give you I and Q from a real-valued receiver.  I say theoretical, because it depends upon a filter that cannot be realized (it's non-causal, and non-finite).  The approach described and pictured in the hackaday article, that of using a balanced downconverter to regenerate both, is better (in my humble opinion) because 1) I can understand all the operators within, and 2) the lowpass filter design required maps to a readily solvable problem.

Dan

Link to comment
Share on other sites
fusionimage Member

fusionimage

Posted
  • Author
Posted

@clf: actually any software defined radio only uses one ADC as a receiver. you get the Q-signal by DSP. since you're dealing with quite some latency via usb, the additional time it takes to calculate the Q-stream is negligible.

 

the best thing would be to make the ad2 compatible with gr-osmosdr, since this is furthermore compatible with a lot of software

Link to comment
Share on other sites
D@n Prolific Poster

D@n

Posted
Posted

@fusionimage,

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.

I'm not personally familiar with gr-osmosdr, but I would imagine that any Gnu-Radio "source" block would work.  (Did I say "synch" block before? ... I looked it up, you need a "source" block.)  To what extent that block is configurable is ... up to you.

Dan

Link to comment
Share on other sites
clf Frequent Visitor

clf

Posted
Posted

@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

Link to comment
Share on other sites
fusionimage Member

fusionimage

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
D@n Prolific Poster

D@n

Posted
Posted
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

Link to comment
Share on other sites
clf Frequent Visitor

clf

Posted
Posted

@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

Link to comment
Share on other sites
clf Frequent Visitor

clf

Posted
Posted

@attila and the Digilent crowd,

1) What license is the Waveforms API and example code licensed under?

2) Are you OK with third-parties creating & releasing under an MIT-style license (a) a C++ language port of the Waveforms API and/or (b) a GnuRadio adapter for the Waveforms hardware, with the understanding that these might incorporate Digilent's published source code?

Thanks in advance,

Chris

Link to comment
Share on other sites
Jon Frey Frequent Visitor

Jon Frey

Posted
Posted

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)
Link to comment
Share on other sites
attila Prolific Poster

attila

Posted
Posted

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. 

Link to comment
Share on other sites
7M4MON Newbie

7M4MON

Posted
Posted

How to install (I'm using Ubuntsu and GRC 3.7.11 with WX GUI.)

at "gr-AD2_AnalogXx_Xxxxxx" directory

$ mkdir build ↵
$ cd build ↵
$ cmake ../ ↵
$ make ↵
$ sudo make install ↵

wxgui_.... blocks are not mine, installed with GRC 3.7.11.

Before using my blocks, you should be install Waveforms and dwf (from pip)

Link to comment
Share on other sites
xc6lx45 Prolific Poster

xc6lx45

Posted
Posted

A quick one-liner for those getting into the topic:

IQ data aka "complex baseband equivalent signal" is generally defined as the positive frequency component of the RF signal, shifted down in frequency.
Keep re-reading until it starts to make sense :-) When I have this internalized, much becomes obvious.

 

 

Link to comment
Share on other sites
Andras Frequent Visitor

Andras

Posted
Posted
5 hours ago, 7M4MON said:

How to install (I'm using Ubuntsu and GRC 3.7.11 with WX GUI.)

at "gr-AD2_AnalogXx_Xxxxxx" directory

$ mkdir build ↵
$ cd build ↵
$ cmake ../ ↵
$ make ↵
$ sudo make install ↵

wxgui_.... blocks are not mine, installed with GRC 3.7.11.

Before using my blocks, you should be install Waveforms and dwf (from pip)

Thanks to you @7M4MON and @fusionimage I could compile and install everything both on Ubuntu and Raspbian.

My joy isn't complete just yet, but I'll update my progress on GitHub as I try to make it work on Windows 10 too: https://github.com/7m4mon/gr-ad2/issues/1

Link to comment
Share on other sites
fusionimage Member

fusionimage

Posted
  • Author
Posted

ok, so how would you pipe a datastream to gnuradio? if you know gnuradio, you also should know, that it is used for DSP. i don't want the ad2 to stream 64bits per sample, this is just what gnuradio uses to save and read data to or from files by default. it doesn't mean that you must have a 32bit adc/dac for that

i didn't even talk about transmission and neither about commercial FM broadcast frequencies. as a licenced ham radio operator i am allowed to transmit on many different bands, but i just would like to receive shortwave with the ad2 because of the 12bit adc. the simpliest way for me would be a fifo pipe that can be read by gnuradio, but i have no idea how to do that. since i am not really familiar with python, i can't even include the ad2 sdk directly to gnuradio, what would make the usage even easier, since it uses python scripts too

 

edit:

"A floating point data stream is saved as 32 bits in the file, one after the other. A complex signal has 32 bits for the real part and 32 bits for the imaginary part."

so there are 64 bits per sample, just written/read one after each other

sure you are right, that i don't need 64 bits of data, but i don't even know how to get the 12 bits into gnuradio ;)

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink

Link to comment
Share on other sites
attila Prolific Poster

attila

Posted
Posted

Hello,

The recording to file is just an example script.

The WaveForms SDK provides functions to control, send and receive samples... You can do whatever you need with received samples, you can process it as you need for your task. The functions allow to generate custom periodic arbitrary waveforms or stream/play samples too.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to question listing
×
×
  • Create New...