Actions
Forum Thread Details
  • Replies 28 replies
  • Subscribers 2561 subscribers
  • Views 6305 views
  • Users 0 members are here
Related

RoadTest POLL: Would You Be Interested in Roadtesting an SDR Active Learning Module

rscasny

ADALM-PLUTOI am getting to launch a roadtest on an active learning module used to learn the fundamentals of software-defined radio (SDR), radio frequency (RF), and wireless communications.

I wanted to gauge your interest in this roadtest.

Here's a some info on the product:

ADALM-PLUTO is a software-defined radio active learning module. The easy to use ADALM-PLUTO active learning module (PlutoSDR) helps introduce the fundamentals of software-defined radio (SDR), radio frequency (RF) and wireless communications.

Here are some features:

  • Portable self-contained RF learning module
  • Cost-effective experimentation platform
  • Based on Analog Devices AD9363--Highly Integrated RF Agile Transceiver and Xilinx® Zynq Z-7010 FPGA
  • RF coverage from 325MHz to 3.8GHz, up to 20MHz of instantaneous bandwidth
  • Flexible rate, 12bit ADC and DAC, GNU Radio sink and source blocks
  • MATLAB®, Simulink® support, libiio, a C, C++, C# and Python API
  • One transmitter and one receiver, half or full duplex
  • USB 2.0 powered Interface with Micro-USB 2.0 connector
  • High quality plastic enclosure

Here are some docs:

datasheet 
product overview
user guides 

For more information

Here's the poll questions:

Parents

  • Yes, for sure I will be interested. This and Analog devices ADALM2000 are both interesting. The issue might be that element14 launches both roadtest at same time frames.

    This device in particular has interesting features. The device can capture RF signals in the range of 325MHz to 3.8GHz which means it can capture signals from most well known wireless communication protocols such as Bluetooth/WiFi (2.3GhZ). Also signals from LoRa and cellular protocols.

    One feature that I did not get quite well is how it works is that device can not only capture the these signals but it can abstract meaningful data out of it means it can understand the WiFi data. There should be WiFi stack running on the device itself. Same could be true for other protocols such as BLE, LoRa etc.

    Regarding the time frame, normally it takes more than 80 hours of time because sometimes the software setup is complex and takes time. Also if there is low-level API's it takes time for the program. Fortunately, there is MATLAB/SIMULINK libraries for this device. The writing also may take some time. That's why I voted for more than 80 hours.!!

  • in reply to embeddedguy

    Hi Ujjval,

    Regarding:

    One feature that I did not get quite well is how it works is that device can not only capture the these signals but it can abstract meaningful data out of it means it can understand the WiFi data. There should be WiFi stack running on the device itself. Same could be true for other protocols such as BLE, LoRa etc.

    The SDR device normally just passes through the captured spectrum directly to the attached PC, and then it is up to the PC software to do any demodulation and any protocol decode. You're right that theoretically the SDR device could do it on its own (for instance code running on Linux on the Zync chip inside the device) but that's an advanced topic, that would require coding to do it, as far as I'm aware. I don't know if there is already any existing software examples to do that for some protocols, there may be.

    Usually the SDR is run tethered to the PC, and the PC handles demodulation and the protocol stack where relevant.

  • in reply to shabaz

    Hi,

    Aha. That way..Relieved.

    Yes I got it. So that software running on PC will handle the tasks. Because doing it on Linux running on FPGA could be difficult in terms of dependencies/availability of packages etc. But cool, at least signal is passed to PC.

Reply Children
No Data