[USRP-users] Tuning resolution of TwinRX + DDC?
Hi everyone, We recently did VLBI observations centered at 1332.49 MHz, using a X310 with TwinRX. The USRP was locked to external references for 10MHz and PPS for this. To get the best phase noise, I used 'integer-N' tuning. We noticed that overall, our receiver frequency was off by 0.118 Hz. This causes the phase of the recorded signal to rotate in about 9 seconds, compared to the other stations participating. As far as I understand, when using integer-N tuning, the DDC simply takes care of the remaining offset. What would be the tuning resolution of the TwinRX itself (using int-N), and what is the resolution of the DDC which corrects for this? Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Recording the full X3x0 bandwidth
Hi, I'm trying to record the full X310 bandwidth, for a few hours, without any missed samples. Which of course is a bit of a challenge - does anyone here already achieve this? We're using a TwinRX, so initially I wanted to record 2x 100MS/s (from both channels), which amounts to 800MB/s, 6.4Gb/s. At first I tried uhd_rx_cfile, but have been unable to get it to a good state without showing an 'O' every few seconds at these speeds. As a recorder I have a SuperMicro 847 chassis with 36 disks (Seagate Ironwolf 8TB T8000VN0022, 7200rpm). In this particular server, the disks are connected through an 'expander' backplane, from a single HBA (LSI 3008). CPU is dual Xeon 4110, 2.1 GHz, 64 GB of ram. At first I tried a 6 disk pool (raidz1), and eventually ended up creating a huge 36 disk ZFS stripe, which in theory should have no trouble with the throughput, but certainly kept dropping packets. Note that recording to /dev/shm/file works perfectly without dropping packets, until the point that the memory is full. Given that ZFS has quite a bit of (good) overhead to safeguard your data, I then switched to creating a mdadm raid-0 with 18 of the disks (Why not 36? I was really running out of time!) At that point I also found 'specrec' from gr-analyze, which seems more suitable. But, even after enlarging its circular buffer to the largest supported values, it would only average a write speed of about 300MB/s. In the end I had to settle for recording at only 50MS/s (200MB/s) from only a single channel, a far cry from the 2x 6.4Gb/s I'm ultimately looking to record. Although I did get more than an hour of perfect data out of it, over time the circular buffer did get fuller in bursts, and within 2 hours it exited due to exhausting the buffers. Restarting the application made it work like fresh again, with the same gradual decline in performance. Specrec, even when tweaking its settings, doesn't really take advantage of the large amount of memory in the server. As a next step, I'm thinking of adapting specrec to use much larger buffers, so that writes are at least in the range of MB to tens of MB. From earlier experiences, it is also important to flush your data to disk often, so the interruptions due to this are more frequent, but short enough to not cause receive buffers to overflow. In terms of network tuning, all recording was done with MTU 9000, with wmem and rmem at the recommended values. All recordings were done as interleaved shorts. Does anyone have hints or experiences to share? Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Passing arguments to an RFNOC block
Hi again, After way too much time spent trying to debug my issues, and renaming all the variables, I wasn't getting anywhere. Then I discovered xmllint which pointed out a few (!) more xml errors in a completely different section of the rfnocblock XML file. After fixing this, I've got the resampler part working. Regards, Paul Boven. On 28/02/2019 10:30, Paul Boven via USRP-users wrote: Hi Jonathon, Thanks for looking at the block, and spotting the mistake. Unfortunately that doesn't stop the swig part from failing, so I'll keep digging further. Regards, Paul Boven. On 28/02/2019 04:19, Jonathon Pendlum wrote: Hi Paul, Your Nocscript has an error on line 47, you are a missing a comma: LE($config 1) should be LE($config, 1). That may not be the source of your issue, but try fixing that first. Jonathon On Thu, Feb 28, 2019 at 1:14 AM Paul Boven via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hi everyone, As part of the VLBI[1] backend that I'm making in RFNOC, my first step is to make a rational resampler. It takes the 100MS/s signal from a TwinRX, and reduces it to 80MS/s. This can be done with a 5:4 resampler. In order to make this work, I'm using the axi_rate_change block. Although the block works in simulation, I keep running into problems with the GRC integration, in particular SWIG throwing run-time errors. The problem seems to be in the way that the arguments (N, M, config) are passed around, but studying other blocks like the DDC block hasn't provided the clues for me to get past this hurdle. The resampler itself does work, which I tested by having it emit zeroes instead of the 'deleted' samples, and using a 'keen 1 in N' in GRC itself. At the moment, the block exits in VLBI_swig.py in set_arg: return _VLBI_swig_resamplerd5x4_sptr_set_arg(self, *args) RuntimeError: SyntaxError: Parsing Stopped at: $N, 5) If you're familiar with RFNOC, can you please have a look at: http://www.jive.nl/~boven/rfnoc-VLBI It contains the source, and also a compiled bitfile for the X310 for your convenience (but use at your own risk, of course). Regards, Paul Boven. [1] Very Long Baseline Interferometry ___ USRP-users mailing list USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Passing arguments to an RFNOC block
Hi Jonathon, Thanks for looking at the block, and spotting the mistake. Unfortunately that doesn't stop the swig part from failing, so I'll keep digging further. Regards, Paul Boven. On 28/02/2019 04:19, Jonathon Pendlum wrote: Hi Paul, Your Nocscript has an error on line 47, you are a missing a comma: LE($config 1) should be LE($config, 1). That may not be the source of your issue, but try fixing that first. Jonathon On Thu, Feb 28, 2019 at 1:14 AM Paul Boven via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hi everyone, As part of the VLBI[1] backend that I'm making in RFNOC, my first step is to make a rational resampler. It takes the 100MS/s signal from a TwinRX, and reduces it to 80MS/s. This can be done with a 5:4 resampler. In order to make this work, I'm using the axi_rate_change block. Although the block works in simulation, I keep running into problems with the GRC integration, in particular SWIG throwing run-time errors. The problem seems to be in the way that the arguments (N, M, config) are passed around, but studying other blocks like the DDC block hasn't provided the clues for me to get past this hurdle. The resampler itself does work, which I tested by having it emit zeroes instead of the 'deleted' samples, and using a 'keen 1 in N' in GRC itself. At the moment, the block exits in VLBI_swig.py in set_arg: return _VLBI_swig_resamplerd5x4_sptr_set_arg(self, *args) RuntimeError: SyntaxError: Parsing Stopped at: $N, 5) If you're familiar with RFNOC, can you please have a look at: http://www.jive.nl/~boven/rfnoc-VLBI It contains the source, and also a compiled bitfile for the X310 for your convenience (but use at your own risk, of course). Regards, Paul Boven. [1] Very Long Baseline Interferometry ___ USRP-users mailing list USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Passing arguments to an RFNOC block
Hi everyone, As part of the VLBI[1] backend that I'm making in RFNOC, my first step is to make a rational resampler. It takes the 100MS/s signal from a TwinRX, and reduces it to 80MS/s. This can be done with a 5:4 resampler. In order to make this work, I'm using the axi_rate_change block. Although the block works in simulation, I keep running into problems with the GRC integration, in particular SWIG throwing run-time errors. The problem seems to be in the way that the arguments (N, M, config) are passed around, but studying other blocks like the DDC block hasn't provided the clues for me to get past this hurdle. The resampler itself does work, which I tested by having it emit zeroes instead of the 'deleted' samples, and using a 'keen 1 in N' in GRC itself. At the moment, the block exits in VLBI_swig.py in set_arg: return _VLBI_swig_resamplerd5x4_sptr_set_arg(self, *args) RuntimeError: SyntaxError: Parsing Stopped at: $N, 5) If you're familiar with RFNOC, can you please have a look at: http://www.jive.nl/~boven/rfnoc-VLBI It contains the source, and also a compiled bitfile for the X310 for your convenience (but use at your own risk, of course). Regards, Paul Boven. [1] Very Long Baseline Interferometry ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Can I use chained DDCs?
Hi Jason, I'm currently on the rfnoc-devel branch of uhd/host as well. And having the same problem: Changing frequency on the DDC or radio causes hangs. However, on 'master', the data format out of the rfnoc blocks didn't even get accepted by the flowchart. Could you please provide the details on how you configured and compiled your uhd to support rfnoc on 'master' ? Which versions of uhd, gr and gr-ettus are you using? Regards, Paul Boven. On 03/12/2018 21:12, Jason Matusiak via USRP-users wrote: Brian, It looks like switching from rfnoc-devel to the head of master cleaned up my issues (Once I realized a clock rate of 120MHz was no longer supported). Not sure what was the problem, but I won't worry about it at this point. I think you are right on the DDC, I will need to look into that more next. - Original Message - Subject: RE: Re: Re: [USRP-users] Can I use chained DDCs? From: "Jason Matusiak" Date: 12/3/18 12:08 pm To: "Brian Padalino" Cc: "USRP-users@lists.ettus.com" Brian, No. I am leaving it alone on startup. I was running off of the rfnoc_devel branch. I just changed to master and am attempting to rebuild with RFNOC enabled to see if something else has been introduced to it. I should try to roll back a version or two and see what that does for me as well. Thanks! - Original Message - Subject: Re: Re: [USRP-users] Can I use chained DDCs? From: "Brian Padalino" Date: 12/3/18 12:03 pm To: "Jason Matusiak" Cc: "USRP-users@lists.ettus.com" Hey Jason, On Mon, Dec 3, 2018 at 11:50 AM Jason Matusiak mailto:ja...@gardettoengineering.com>> wrote: Brian, I am not sure what the issue is here. I don't think it is the chained DDC anymore as I can see the issue with the single DDC using multiple different bitfiles. I wasn't re-tuning the Fc anywhere, I was just dropping the sample rate from 120MHz down to something I could handle. Right now I am not touching the CORDIC modifications at all. Are you trying to change the samplerate at runtime after starting the stream? In my experience, ever since around the time the the DDC moved from a CORDIC to using a DDS, dynamically changing the samplerate at runtime after starting a stream is broken and causes strange behavior. In my experiences, it's been timeouts. What version of UHD are you running for your applications? I think I settled on 3.13.0.1 release as my stable base, and I have a few patches applied. Brian ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
Hi Marcus, everyone, On 25/11/2018 19:47, Marcus D. Leech via USRP-users wrote: OK, just tried the attached flow-graph in the lab, using: [mleech@lab ~]$ uhd_usrp_probe --args addr=192.168.10.2 [INFO] [UHD] linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; UHD_4.0.0.rfnoc-devel-702-geec24d7b The above text suggested to try the rfnoc-devel branch instead of the master branch for uhd/host. With that, I've gotten RFNOC to work, thanks! Below some further details on what I managed to piece together for now, in case anyone wants to comment. I'm using the default FPGA image for the X310, which has only the radio and the DDC/DUC blocks for RFNOC, as the images with more blocks are currently unavailable. RFNOC receiving (with TwinRX) works, but often the frequency doesn't get set correctly on startup. Changing the frequency (e.g. via a QT range slider) regularly causes the command link from PC to USRP to die. Samples from USRP to PC keep flowing, that part is quite stable. For the TwinRX, the data rate seems to be 100MS/s complex, so the RFNOC Radio block already takes care of converting the samples (real samples, second Nyquist zone on either I or Q ADC input) into complex values. As a first test, I used the RFNOC Radio Block and DDC to make a tunable WBFM radio, using the 'CORDIC' input to the DDC block to select the station. This works very well now (apart from the issues noted above). Build process: Host: Ubuntu 18.04 LTS 1) UHD: git clone http://github.com/EttusResearch/uhd cd uhd/host git checkout rfnoc-devel mkdir build; cd build cmake -DENABLE_RFNOC=ON -DCMAKE_INSTALL_PREFIX=/usr .. make package sudo dpkg -i uhd_4.0.0.rfnoc-devel-702-geec24d7b_Ubuntu-18.04-x86_64.deb 2) GNU Radio: git clone --recursive http://github.com/gnuradio/gnuradio cd gnuradio git checkout maint-3.7 mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr -DCPACK_DEBIAN_ARCHIVE_TYPE=gnutar .. make package sudo dpkg -i gnuradio_3.7.13.4_Ubuntu-18.04-x86_64.deb 3) GR-Ettus: git clone http://github.com/EttusResearch/gr-ettus cd gr-ettus mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr .. make gr-ettus doesn't have a 'make package' target in the Makefile, so I created a package by hand using "fakeroot DESTDIR=`pwd`/fakeroot make install" and then building a Debian package out of that. Next steps: build an FPGA image with a few more interesting RFNOC blocks. Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
Hi again, On 11/22/18 6:45 PM, Marcus D. Leech via USRP-users wrote: Your radio block is set to a sample rate of 100e6, whereas the X310 uses a sample clock of 200e6. This may be why things are getting stuffed up. I've now tried 200 MHz for the radio block. Still getting the same error messages, and nothing in the FFT plot. Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Firmware images for X310-RFNOC?
Hi, On 22/11/2018 16:20, Marcus D. Leech via USRP-users wrote: On 11/22/2018 09:26 AM, Paul Boven via USRP-users wrote: A simple flowgraph (see attached image) using RFNOC:Radio, RFNOC:DDC and a QT GUI frequency, together with Device3, starts and runs but no data is produced. Instead, it generates a lot of error messages, "timeout on chan 0" and "ValueError: Bad CHDR or packet fragment". Check your ethernet MTUs and the packet sizes setup in your device3 block. I had this issue the other day, and the MTU on my ethernet interface had been set larger than it could actually support, resulting in truncated-by-the-interface packets. Thanks for the quick reply. The MTU of the network doesn't seem to be the issue. I've tried on two different network cards on my PC (both Intel 1G cards). The MTU of the Ethernet card is set to 9000, and this is known to work. uhd_usrp_probe chooses a packet size of 8000 bytes. When running tcpdump at the same time, I can see that packets of 8000 bytes are being received. It looks like it sends about 1 second of data in 8000 bytes packets from UDP port 49153 to port 33894, and then the remaining traffic is just 16 byte packets being exchanged between PC and USRP. Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Firmware images for X310-RFNOC?
Hi everyone, After quite a bit of trial and error, I've managed to build a GNU Radio environment that includes RFNOC. My environment consists of: uhd-3.14, gnuradio-3.7.13.4, gr-ettus (master). uhd_usrp_probe shows that the X310 is detected, and has the expected RFNOC blocks on board (DmaFIFO_0, Radio_0, Radio_1, DDC_0/1, DUC_0/1). The USRP in question is an X310 with a TwinRX board. A simple flowgraph (see attached image) using RFNOC:Radio, RFNOC:DDC and a QT GUI frequency, together with Device3, starts and runs but no data is produced. Instead, it generates a lot of error messages, "timeout on chan 0" and "ValueError: Bad CHDR or packet fragment". Is my expectation correct that such a simple flowgraph should work? Is the fact that the TwinRX has two radios (one on I, one on Q) perhaps a problem here? Am I missing something obvious still? The way I built and installed the software is documented below, comments very much appreciated. 1) Remove anything gnuradio/uhd related. 2) Build UHD: git clone https://github.com/EttusResearch/uhd cd uhd/host mkdir build; cd build cmake -DENABLE_RFNOC=ON -DCMAKE_PREFIX=/usr .. make package sudo dpkg -i uhd_3.14.0.0-220-g97933b15_Ubuntu-18.04-x86_64.deb 3) Build GNU Radio: git clone --recursive https://github.com/gnuradio/gnuradio cd gnuradio checkout maint-3.7 mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr -DCPACK_DEBIAN_ARCHIVE_TYPE=gnutar .. make package sudo dpkg -i gnuradio_3.7.14.4_Ubuntu-18.04-x86_64.deb 4) Build gr-ettus: git clone https://github.com/EttusResearch/gr-ettus cd gr-ettus mkdir build; cd build cmake -DCMAKE_INSTALL_PREFIX=/usr .. make (manually created a package using PREFIX and fakeroot) dpkg -i gr-ettus*.deb The above results in a seemingly working gnuradio-companion which includes RFNOC blocks Regards, Paul Boven. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
