Actions
Forum Thread Details
  • Replies 28 replies
  • Subscribers 2561 subscribers
  • Views 6281 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:

  • Yes, I would definitely be interested with this!
    I mean, I'm already using a RTL SDR Blog receiver to "spy" on the devices emitting in the neighborhood, along with the rtl_433 project that I have even ported to ESP32 as part of experiments I do on the RFLinK32 project.

    Using such a device as the Pluto would allow to go even further to maybe finally let me figure out what the signal is from my "intelligent" water counter and the relays that have pop up in various lamp posts in the streets.

    I'll be sure to apply for this one if it becomes a roadtest.

  • This is much better than RLT-SDR I have - not only broader bandwidth, but with TX option as well. In my opinion software support (or better - good bundled software) is critical  for beginners - when a beginner has to choose between dozen different applications, some usable, other of worse quality it is easy to get lost and lose interest.

  • I voted No, Not because there is anything wrong with the product and suitability for a Roadtest but becausse SDR is a BIG subject and to do anything other than run other peoples scripts would take serious study and effort. 

    And since it would be down at below 20 in priority on my TODO list it doesn't appeal.

    In passing, I would suggest that unless you are already expert in SDR there is a lot of work needed to get up to speed. If you might need MATLAB and other Mathworks products to complete your project then the home license is your only hope without parting with serious amounts of money.

    My smallish MATLAB suite costs about £1700 per year in maintenance.

    MK

  • The ADALM-PLUTO has been on my wish list for some time. I voted maybe because this year I want to work on electronic / IT projects with no time constraints, just for the joy of learning. So maybe I'll buy a PLUTO when I have time to learn at my own pace. But I am very interested in reading reviews about the ADALM-Pluto.

  • in reply to kmikemoo

    Sometimes we got so excited about a device that we read a lot about it, datasheet, manual, app notes, and we ended dreaming about it. I'm sure I'm not the only one.

  • SDR tech is a complex area for any electrical engineer, however, SDR project is one of the most interested domains in electrical engineering. SDR related projects are always on my to-do-list in my hobby projects.

  • A very interesting product, I am just not sure if I could do it justice.

  • I am an Amateur Radio Operator, so being able to test an SDR system, would be awesome. So yes, I'm very interested.

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