Re: adalm-pluto gr-iio/iio-examples
You're right - great - thanks! But it's misses the PlutoSDR sinks and sources - they show up as missing blocks. -- Cinaed On 8/22/20 9:20 AM, Derek Kozel wrote: In most cases the examples should update automatically when opened in GNU Radio 3.8. On 8/21/2020 10:52 PM, Cinaed Simson wrote: Has anyone converted or ported the GRC example files in gr-iio/iio-examples for gnuradio-3.8? I checkout the version of gr-iio for gnuradio-3.8 but example GRC files in gr-iio/iio-examples are XML files - or for 3.7. -- Cinaed
BPSK tutorial
For those of you who have been asking questions about BPSK, I have created https://wiki.gnuradio.org/index.php/Simulation_example:_BPSK_Demodulation, which is a follow-on to the QPSK tutorial. Questions and comments are welcome! --- Barry Duggan KV4FV https://github.com/duggabe
Re: linux distro with GNU Radio preinstalled?
I am biased (my livecd) but Pentoo Linux has gnuradio and a few other sdr programs pre-installed. I'm in the middle of prepping for a release, so I can confirm that the daily isos are both very up to date and reasonably bug free. The download page itself is a bit outdated (it references an older release) but the dailies are from...today. https://pentoo.ch/downloads Feel free to email me off list or join my discord (linked on the above site) if you are interested and care to discuss. Thanks, Zero On Wed, Aug 26, 2020 at 6:22 PM Kristoff wrote: > > Hi all, > > > I am giving an (online) presentation / demo of GNU Radio next week. > > > As I do not know if there will be a lot of linux-users, I would like to > provide an easy-to-use option for windows users. > > The GNU Radio Live mentioned on the GNU Radio website (*) is based on > Ubuntu 2016.04, which is ... euh ... not very recent :-) > Are there any new linux distro / liveCDs that have GNU Radio > preinstalled and ready to use, either to boot from USB dongle or in a VM? > > > (*) > https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment > > > Kristoff (ON1ARF) > > > > >
linux distro with GNU Radio preinstalled?
Hi all, I am giving an (online) presentation / demo of GNU Radio next week. As I do not know if there will be a lot of linux-users, I would like to provide an easy-to-use option for windows users. The GNU Radio Live mentioned on the GNU Radio website (*) is based on Ubuntu 2016.04, which is ... euh ... not very recent :-) Are there any new linux distro / liveCDs that have GNU Radio preinstalled and ready to use, either to boot from USB dongle or in a VM? (*) https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment Kristoff (ON1ARF)
Re: How to toggle between two different file paths in File Source
Try calling src.open(filename, repeat) after the delay. On Wed, Aug 26, 2020 at 5:41 PM Jonathan Morales < jonathan.morales...@gmail.com> wrote: > > Hello! > > I've been struggling to figure out how to send one file, delay, then > switch to sending a second different file. I've been using > gnuradio-companion to generate a Python script which I manipulate. I've > tried resetting the filepath call after a delay but, when I run the script > it continues to only send the first file. > > Regards, > J >
How to toggle between two different file paths in File Source
Hello! I've been struggling to figure out how to send one file, delay, then switch to sending a second different file. I've been using gnuradio-companion to generate a Python script which I manipulate. I've tried resetting the filepath call after a delay but, when I run the script it continues to only send the first file. Regards, J
Re: [USRP-users] [UHD] Announcing 4.0.0.0 Release Candidate 1
Thanks for the UHD 4.0rc1 update, Michael. This UHD version will be the most robust and compatible version yet! For macOS users of UHD and GNU Radio, a brief update: UHD 3.15 and UHD 4.0rc1 build and run on many macOS versions -- at least 10.11 " El Capitan" through 10.15 "Catalina", and probably further back with a modern enough compiler. I've built UHD 3.15 back to 10.8 "Mountain Lion", but unfortunately UHD applications do not execute ... maybe others know what the issue is here? I have yet to try UHD 4.0rc1 on these older macOS systems. GNU Radio 3.7.14.0 and 3.8.2.0 -- with a patch to cover the commits since this release was tagged on the "maint-3.8" branch -- also work with these same macOS versions. All of these projects / versions are available in MacPorts right now, via the ports "uhd" (3.15), "uhd-devel" (4.0rc1), "gnuradio37" (3.7.14.0), and "gnuradio" (3.8.2.0 + patches). I have tested out GR 3.8.2.0 + UHD 4.0rc1 and they play nicely (enough) together; I'm confident that the combinations GR 3.8.2.0 + UHD 3.15 and GR 3.7.14.0 + UHD 3.15 also work. MP allows GR 3.7.14.0 + UHD 4.0rc1, though I don't know if this will even build. I value any feedback on macOS building and/or use of UHD and GR (and Volk, but that's pretty separate by now); MacPorts or some other install means; any macOS version: 10.4-5 PPC 32/64, 10.4-16 Intel 32/64; even 10.16 ARM64 ... if that's where you are (you're ahead of me then, though I'm catching up ;) !!! Cheers! - MLD --- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/ On Tue, Aug 25, 2020 at 8:46 PM Michael West via USRP-users < usrp-us...@lists.ettus.com> wrote: > The release candidate of the long awaited UHD version 4.0.0.0 has been > tagged and is available for testing. This major release introduces a new > RFNoC framework, a new streaming infrastructure, a power calibration > utility and API, and many other features and bug fixes. The new > infrastructure provides improved performance, more flexibility, and the > foundation for future demands of higher throughput and lower latencies. > > The tag for this release candidate: > https://github.com/EttusResearch/uhd/releases/tag/v4.0.0.0-rc1 > > There have been 831 commits since the last release (3.15.0.0) which can > be viewed here: > https://github.com/EttusResearch/uhd/compare/v3.15.0.0...v4.0.0.0-rc1 > > Please report any bugs found on the UHD issue tracker: > http://github.com/EttusResearch/uhd/issues > * Please do not use the issue tracker for help or support. > > Pull requests for direct code changes may be submitted to the UHD or FPGA > repositories: > http://github.com/EttusResearch/uhd/pulls > http://github.com/EttusResearch/fpga/pulls > > CHANGELOG: > ## 004.000.000.000 > * b200: > - Enable power calibration API > - Add a prop tree node usb_version > * cal: > - Add utility to update all .fbs files, or check the generated ones > - Add pwr_cal container > * cmake: > - Add ability to pass CXXFLAGS to CMake environment > * docs: > - Update PCIe xport instructions for NI Repos > - n3xx: Include WX in table of N320 images > - Add stream and transport args documentation > - Update Basic/LF dboard references to use new operating mode > - e3xx/n3xx: Add sections on FP-GPIOs and how to drive them > - n3xx: Document eeprom flags > - Add note about DPDK needing to be built as shared libraries > - Change DPDK version to 18.11 and make args use underscores > - Clarifying which devices support DPDK > * dpdk: > - Add new DPDK stack to integrate with I/O services > * e31x: > - Change RFNoC Ctrl clock to 40 MHz > - Fix timeout for timekeeper registers > - Fix filter bank and antenna switching for channel 0 > - Swap out liberio for internal Ethernet > * e320: > - Fix timeout for timekeeper registers > - Swap out liberio for internal Ethernet > * examples: > - Add usrp_power_meter example > - Update test_messages example > - Update gpio example > - Add options to benchmark_rate > - Add example out-of-tree module for RFNoC modules > - Remove thread priority elevation > * fpga: > - Replaced RFNoC architecture with new 4.0 version > - Added modelsim make simulation target > - Upgrade to Vivade 2019.1 > - Removed unused coregen files and modules > - Removed fpga submodule and merged into uhd repo > - lib: Change max FFT size to 1024 > - lib: add Intel MAX10 architecture for 2clk FIFO > - rfnoc: Port RFNoC Keep One in N block to new RFNoC architecture > - rfnoc: Port RFNoC Replay block to new RFNoC architecture > - rfnoc: Port Signal Generator RFNoC block to new RFNoC architecture > - Add Switchboard RFNoC block > - Remove liberio > - rfnoc: Port RFNoC Moving Average block to new RFNoC architecture > - rfnoc: Port Log-Power block to new RFNoC architecture > - rfnoc: Port RFNoC Window block to new RFNoC architecture > - lib: Add synthesizable AXI4-Stream SV components > - lib: Add
Re: Messages into two blocks: Message order & timing guaranteed?
Hi Lukas, I'd suggest you use timed transmissions with your USRP. I assume you want to build a TDD system. In that case, it would be advisable to avoid transmitting `0`s. One more reason to use timed transmissions. I assume your align block is some kind of synchronization. I suggest to sync your RX stream first and then use your messages to align your stream. Your 2 Msg2Tag blocks will probably deviate sometimes since they run in separate threads. Cheers Johannes On 25.08.20 18:35, Lukas Haase wrote: Hi, I have a block that generates messages (may be very fast, in the ms range or below). At some point I need to convert these into precise, repeatable timing, so I have a "Msg2Tag" block. It takes messages at the input and outputs a sample stream of zeros with the messages as tags. However, since I need repeatable and precice timing, that block has a parameter "period" and it would insert a tag only every period-th sample. +-+ Msg+-+ | Message +>+ Msg2Tag |-> Stream with 0s, tag every period-th sample +-+ +-+ Now I want to copy this "Message to Tag" block and feed it with the same message source. +-+ Msg+-+ | Message +---+>+ Msg2Tag |-> Stream with tags #1 +-+ | +-+ | | +-+ `>+ Msg2Tag |-> Stream with tags #2 +-+ *** Will both output sequences (and tags) be guaranteed to be identical? *** Why am I doing this? I have a system with a query and response (think of an RFID reader for example) based on USRP. The query/response time is short (>1ms). I need to perfectly time-align the USRP response with the USRP query. Right now I only have one "Message to Tag" block which I use as global timing control: I feed this signal not only into the USRP Sink but also in a block that properly aligns the response from USRP Source: +-+ Msg+-+ +---+ | Message +>+ Msg2Tag |-+--->+ USRP Sink | +-+ +-+ |+---+ | |+-+ `--->+ | | Align |-> Further ,-->+ | processing /+-+ | +-+| + USRP Source |' +-+ (Note that I am omitting blocks and details for the sake of clarity). However, a configuration in which the USRP is "in the loop" seems to be extremely unreliable [*]. Since I can perfectly reproduce the signal that goes into the USRP Sink, I could just clone the block; I would not need to use the same output stream of the Msg2Tag block. However, for reproducible results, the clone must be guaranteed to be an identical copy. I am afraid that with two Msg2Tag blocks, the result will not be guaranteed the same. Which options do I have for my setup? I do want to use messages initially because it makes high-level protocol stuff much easier. Thanks, Lukas PS: I heard about gr-eventstream but want to avoid it if possible. [*] While this setup seems to be working for some parameters (such as inserting huge delay blocks and changing min output buffer of Msg2Tag block, this generally seems to be unreliable and at some point the USRP reports a late packets. I think this is because now the "Align" block dictates the sample flow. It might let Msg2Tag buffer lots of samples at the output while reading in samples from USRP Source. During this time, the USRP clock proceeds. Once the samples in the buffer are sent to the USRP, they are late and the system breaks.
