Without the low pass filter, I was getting a sequence of D's. The low pass filter uses a Volk machine, and downsamples the 50M to 30M with a 5M transition size. I am using the GUI companion on Linux, but I vaguely recall that I may have had better luck recording when I just created a Python script on a PC. I will try the script (on Linux) this afternoon, and I will also try running at 25M downsampled to 10M.
In the meantime, any additional comments/suggestions would be appreciated. Thanks. Paul B. Huter On Dec 4, 2013 6:29 AM, "Marcus Müller" <mar...@hostalia.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > With most hardware interfaces, you get notifications when your > driver/interface starts dropping samples -- with UHD you'd see loads > of 'O' indicating overflows. > If you don't see that, there is something really wrong. How does your > data acquisition take place? 50Msps is really a lot for an average PC > if you do filtering; I don't know how your low pass filter looks, but > I think it's probably causing to much computational load for your > computer to process the incoming samples in real time. > > Greetings, > Marcus > > On 04.12.2013 12:39, Paul B. Huter wrote: > > There must be something with my record, because my 20 seconds of > > running only produces about a 180MB file. I am not seeing any > > indications of dropped data, though. I am recording to a RAMDisk, > > but I get the same results recording to my HDD. > > > > Does anyone have recommendations for how to ensure I get my data > > recorded? I really think that if I cam record the data, playback > > will be more what I am looking for. > > > > Paul B. Huter On Dec 4, 2013 1:20 AM, "Marcus Müller" > > <mar...@hostalia.de> wrote: > > > > Hi Paul! > > > > I'm gonna go ahead and rearrange parts of your message for the ease > > of reply: > >>>> My datafile was recorded for about 20 seconds at a sample > >>>> rate of 50Msps through a low-pass filter to only capture > >>>> 0-30MHz. > > 50Msps * 20s = 1Gs (you're sure your file is 8GB in size?) should > > be plenty enough, so my guess was totally astray. > > > >>>> Looking at the configuration for my FFT, and changing > >>>> 'Refresh Rate' from the default '15' to '1M' gives me some > >>>> extra playback. > > what gui toolkit are you using? wx or qt? However, a refresh rate > > of one million frames per second... doesn't even remotely make > > sense. Since there is no way that your file source can supply > > 1024Msps for the GUI sink, even without throttling, I don't know > > what the (wx or qt or whatever) FFT sink does in that case. I'd > > have to read the source code... > > > >>>> I like the way the waterfall looks, but I'm having the same > >>>> issue as the FFT. > > > > Ok, this is confusing. The waterfall sink should basically be able > > to have one pixel of display per sample going in. And with 1 > > billion samples going in, there shouldn't really be repitions > > visible, unless your data is repetitive. > > > >>>> Is there some correlation between data rate on the record and > >>>> FFT refresh rate? > > No. Refresh rate is just the display refresh rate, i.e. the speed > > at which the GUI updates its visualization. > > > >>>> How is 'FFT Size' used (right now I have that at '1024')? > > Um this is kinda awkward - it's the size of the FFT; how the > > samples are internally processed prior to being transformed depends > > on the actual FFT sink implementation. > > > >>>> On a related note - is there a way to get the FFT to start > >>>> out in 'Autoscale', or do I need to hit the button every > >>>> time? > > > > No. "Autoscale" is (as far as I know and can remember right now) > > not a /mode/ for the qt nor the wx gui fft sink, but scales the > > display to fit the data that is display /the moment the button is > > clicked/. So, since data can only be available at run time, you > > can't do that before running the flow graph. However, at least for > > the qt implementation, you can set y max/y min, if you know it > > beforehand. > > > > So: Verify your data is really about 1 billion samples long and > > not only a few thousand; if your waterfall looks periodic, your > > recorded signal is periodic. > > > > Greetings, Marcus > > > > On 03.12.2013 22:45, Paul B. Huter wrote: > >>>> > >>>> Is there some correlation between data rate on the record and > >>>> FFT refresh rate? How is 'FFT Size' used (right now I have > >>>> that at '1024')? On a related note - is there a way to get > >>>> the FFT to start out in 'Autoscale', or do I need to hit the > >>>> button every time? > >>>> > >>>> Thanks! > >>>> > >>>> > >>>> On Tue, Dec 3, 2013 at 3:01 PM, Marcus Müller > >>>> <mar...@hostalia.de> wrote: > >>>> > >>>> Most probably your data is simply to short in relation to the > >>>> fft length and the amount of samples your specific graphical > >>>> FFT amplitude sink drops for display. Please review you fft > >>>> length, update rate, and try out different fft GUIs (qt/wx). > >>>> > >>>> You could zeropad your data generously to notice the > >>>> repitition. However, I think with what you're describing you > >>>> might be better off with a waterfall graph; try them, they're > >>>> fun :) > >>>> > >>>> Greetings, Marcus > >>>> > >>>> On 03.12.2013 21:45, Paul B. Huter wrote: > >>>>>>> When I play my data file back through a throttle and > >>>>>>> frequency translating FIR filter to an FFT sink with > >>>>>>> repeat OFF, it seems to just show a static plot. > >>>>>>> However, with repeat ON, I get playback, but I can't > >>>>>>> tell when data ends and starts back over. Is there a > >>>>>>> way for me to know when it repeats? Or, is there a way > >>>>>>> to get playback with repeat turned off? > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> Paul B. Huter > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org > >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>>>>>> > >>>>> > >>>>> > >>>>>>> > _______________________________________________ Discuss-gnuradio > >>>>> mailing list Discuss-gnuradio@gnu.org > >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>>>> > >>>> > >> > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJSnyATAAoJEAFxB7BbsDrLer0H/ikK1c3mNHcWj5NtsWk7e9rD > GXPW5aR9KFSp8O6UVu01K9vjXNbksuHVOPdJqT24ysSditqcjaxlBU+WlfjtEKtB > 8kWEGINs1RNsG0lgsFdkVNi+83wGjUm5z+Vgo5eiMwbInVUoxRzhVBEjZzZicBQn > x0TmcRH3zDpynINZCicqimvk4uZ/eYL4IowS375zLeGhIyn+SOtSI4qemAwJ6lpl > 8U1EyJWBMZ1VjPMy68uYSnwSWg37Sv2BrKpOECY2mtCYU8lwD4QhVlbyg12jVB4I > JpBNXbxgOU4rowek+y3qmRob79NVnuohHR6yo5eP0T4WYCiKRKTcpX4xW1hEScQ= > =wN1n > -----END PGP SIGNATURE----- >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
