Thanks Josh. I've tried some different combinations of uhd_usrp_probe --args="serial=123456, recv_frame_size=16384,num_recv_frames=16" and varied recv_frame_size up to something really high like 1,000,000 and num_recv_frames up to 400 and didn't get the segementation fault error.
When I run my 4 channel RX script after trying some different configurations I am still getting overruns. If I change the USRP sampling rate to 500kS/s but leave the file rate at 500kS/s the overruns go away however I want to sample the USRP at 1MS/s to have a flatter frequency response. This leads me to think the Overruns are not caused by the file writing part. The fusb_block and fusb_nblocks setting were both set to 512*32 in the older GNURadio version and custom USRP 4 channel source block. The same script in the older GNURadio version still runs with no Overruns even at 1Ms/s for each of the 4 USRP channels. Is there anything else I can try? Do I need to also alter the send_frame_size and num_send_frames in the uhd_usrp_probe calls? Thank you, Tom ________________________________ From: Josh Blum <[email protected]> To: Tom Hendrick <[email protected]>; "[email protected]" <[email protected]> Sent: Wednesday, February 20, 2013 4:34 PM Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue On 02/20/2013 02:22 PM, Tom Hendrick wrote: > Thanks for the suggestion Marcus. > > I tried adjusting those settings by using the following command: > > uhd_usrp_probe --args="serial=123456, > recv_frame_size=4096,num_recv_frames=4096" > The 123456 is replaced with the actual serial number of the usrp1 when I run > the command. > > > When I run that command it shows the USRP1 configuration settings and the > daughtercard and then at the bottom it says "Segmentation fault (core > dumped)". This happens with other values of recv_frame_size and > num_recv_frames. Does anyone know what I'm doing wrong or is this even the > right way to change those settings? > > What are the default values in case I need to set them back to what they > were? I couldn't find this anywhere in the UHD documentation. > The values arent sticky, so you dont need to worry about that. The default libusb xfer size if 16384 bytes. I think the segfault comes from the number of frames. The default is 16, and you can change this, but 4k is probably way more pending LUTs than libusb can handle. -josh > Thank you, - Tom > > > > > ________________________________ > From: Marcus D. Leech <[email protected]> > To: Tom Hendrick <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Wednesday, February 20, 2013 9:53 AM > Subject: Re: [Discuss-gnuradio] USRP1 4 Channel Subdev Issue > > > I tried the suggestion from Marcus and was able to get the USRP1 to work with > 4 real channels. I have a simple GRC script which samples the USRP at 1MS/s > and then resamples the signal to 500kS/s and then writes to a file. I am > getting continuous Overruns with this GRC script on my laptop. >> >> I have the same GRC script with the older GNURadio and when I > ran it again on the same laptop (I booted up a prior version of > ubuntu with an older gnuradio version that uses the USRP class > not UHD) it writes to file with no Overruns at all. I saw that > the custom quad channel USRP block has an fusb_block and > fusb_nblocks setting. These are both set to 512*32 but if I > lower them to something like 64*32 I start to see the Overruns. >> >> Are there similar type settings I can adjust on the 3.6.2 > version of GRC or GNURadio python scripts to get rid of the > overruns? I'm not sure if this is possible but I would like to > not have to boot into an older ubuntu version when I need 4 real > channels. The only thing that comes to mind is to adjust > noutput_items and I tried this but it didn't eliminate the > overruns. >> >> Thank you, -Tom >> >> >> >> > http://files.ettus.com/uhd_docs/manual/html/transport.html#usb-transport-libusb > > The USB parameters shown there can be passed as device args > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
