[Discuss-gnuradio] Question about UHD output data type.
Hi, I met a strange problem about UHD output data. I write the sampler program according to rx_timed_samples.cpp and use int 16 bits as io type as in command: size_t num_rx_samps = dev-recv( buff, sizeof(buff), md, uhd::io_type_t::COMPLEX_INT16, uhd::device::RECV_MODE_ONE_PACKET ); Then I checked the output data and found that samples seems to be the int 8 bit data since the minimum step is 0.0078125, which is equal to 2 power of -7. What could be the reason for this? Thank you for your help! Liang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD help
I have UHD built, burned a UHD firmware to SD, the USRP2 pings, uhd_find_devices is happy- how do I use usrp2_fft.py for instance with UHD- or do I need to edit the .py files to change the flowgraph for UHD? Sorry if this has been answered somewhere already. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dynamic range of USRP2-XCVR2450
Hi, I am trying to find out the dynamic range of the system USRP2-XCVR2450. Looking at the schematics it seems there isn't automatic gain control in the whole RF chain, Isn't it? Thus the dynamic range of the system would be the ADC dynamic range, which is 2 volts Am I right? Cheers, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD help
On 10/19/2010 06:44 AM, Brett L. Trotter wrote: I have UHD built, burned a UHD firmware to SD, the USRP2 pings, uhd_find_devices is happy- how do I use usrp2_fft.py for instance with UHD- or do I need to edit the .py files to change the flowgraph for UHD? There are grc blocks, drag and drop a UHD USRP source and an FFT plotter block. Didnt get around to modifying any examples as of yet. -Josh Sorry if this has been answered somewhere already. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about UHD output data type.
I met a strange problem about UHD output data. I write the sampler program according to rx_timed_samples.cpp and use int 16 bits as io type as in command: size_t num_rx_samps = dev-recv( buff, sizeof(buff), md, uhd::io_type_t::COMPLEX_INT16, uhd::device::RECV_MODE_ONE_PACKET ); Then I checked the output data and found that samples seems to be the int 8 bit data since the minimum step is 0.0078125, which is equal to 2 power of -7. What could be the reason for this? The range of an int16 is +/-2^15, the minimum step is 1 because its an integer. Did you by any change change the io type to int16, but interpret the buffer as a complex float? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dynamic range of USRP2-XCVR2450
On 10/19/2010 12:21 PM, Jorge Miguel wrote: Hi Marcus! How do you get the 85 dB value? Is the Intermodulation distorsion of the page 3 ADC datasheet? In the features list for the LTC2284: 72.4dB SNR, 88dB SFDR SFDR is spur-free dynamic range. I am not an expecienced engineer (I am recent graduated) but I was thinking about the maximun and minimum input powers to be linearly detected in the USRP receiver. I thought the ADC as a good point to start with and then see what is going on in the XCVR2450 transceiver At the ADC point, it is said that is has 2volts p-p dynamic range. This value can give us the maximun power input at the ADC provided the input impedance.(Good question. What is the input impedance? I cannot see it in the ADC datasheet) P=(V^2)/R Is it right? In other post I can read:/ADC's datasheet, we need 2Vp-p to fully utilise its dynamic range. The input impedance of the ADC is around 220ohms so this is equal to an input signal level of about 6dBm. If you go above this you will get saturation./ I do the calculations and it doesn't match!!! The LTC2284 can be configured for either 1VP-P or 2VP-P. I believe the USRP2 uses 1VP-P configuration. Generally, with ADCs, you ascribe roughly 6dB of dynamic range per bit, this is a 14-bit A/D. Before the ADC is the XCVR2450, with all RF components. Each one of then has its Noise figure and some of them gain such us the power amplifier or the Maxim. You said that /The XCVR2450 does have gain control, but it is solely under control of the host software/. Besides the ones I mentioned, is there any other place with gain? The MAX2829 has roughly 93dB of RX gain-control range--that's right on the data sheet, and is exposed to the API inside Gnu Radio. When you create a source, you can specify the gain (actually, you can change it dynamically as well). Is it the correct way of calculating the dynamic range? I really need help. Thanks, Jorge. The LTC2284 A/D is a 14-bit A/D. The maximum input voltage the way it's configured is 0.707Vrms. Divide that by the 2^14, and that's roughly your minimum input voltage. In general, though you take a little bit off the top and add a little bit onto the bottom of the range. Google is your friend. I'd suggest looking up ADC noise floor dynamic range. Plenty of articles out there. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: UHD:SingleUSRP and buffer allocation, policy
Marcus, Would you post your flow graph? Also, did you use TUN/TAP? Andrew On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote: I've noticed latency issues with one of the applications I'm working on. Latencies of up to tens of seconds have been observed, which I tried to combat by specifying recv_buff_size in the parameter list. Right now, I'm running with 4096 bytes, which at 400Ksps, gives me a roughly 1 second latency between input and output (where output is both an audio sink, and a couple of different file sinks as well as a scopesink2, and an FFT sink). But increasing it beyond 4096 bytes causes the latency to go up very quickly, and if I drop it to 1024 bytes, I start seeing over-runs. If you do the math, however, 4096 bytes is nowhere near 1 second worth of buffer. One second is 1.6Mbytes (400Ksps x 4bytes per sample). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] noise figure of XCVR2450
Hi List, I have previously claimed on this list that I have measured a noise figure of some 4dB on the XCVR2450. However, I probably made the following mistake: I used a CW of 2.4GHz as signal. However,there is spurious at 2.4GHz which I mistook for being my desired signal. The signal generator and the USRP2 was locked so there was just a single peak. When I measured today I got a noise figure around 25dB. I wonder if it can be noise from the transmitter chain which is leaking into the receiver.. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP alternatives for CR / DSA application
Hello all, Currently I am in the opening stages of a senior design project for my EE degree. My end of the project will be to implement a CR / DSA radio using the GNU platform but not necessarily using the USRP as the platform of choice. Looking for alternatives to the USRP, I was wondering if there was some sort of consolidated list of single board computers / processors known to be compatible with GNU. If such a list does not exist, any suggestions would be much appreciated. The only parameters that are necessary to follow for the design is that the single board computer must have GB 10 Ethernet and the price is capped to $500. Thank you well in advance, -Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas parameter in DPSK2 grc block not in .py?
There's an argument to be made for this. It'll go into the thinking about the refactoring of the code. blks2impl must be burned I think the structure in the gr-noaa directory is a good example of how to organize a set of related blocks and applications. There is also the concept of using SWIG's XML output for the GRC files. I've only played around a bit with them, but it's something to look into if you haven't already. It looks like it captures _most_ of the information about the blocks that is exposed in the GRC xml files. It's fairly expressive output, so we'd have to see if it actually covers everything necessary for GRC to use with updated parsing. Have you already looked at, and dismissed, this, Josh? I have not looked at nor have I dismissed the possibility. There are certain visually appealing things you can do like hiding parameters that dont matter when another parameter is set, or grouping two similar blocks that have different outputs. I believe that there is no general abstraction on how to do this and that generated xml files will be somewhat lacking. That said, maybe generating the xml files might be useful for enough of the blocks that its worth figuring out. Maybe we can have a middle ground and find a way to generate the xml and leave a place to get extra block specific information into the generator. Basically, I will take a look at the SWIG XML when I get the chance. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas parameter in DPSK2 grc block not in .py?
On 10/19/2010 05:45 PM, Josh Blum wrote: There's an argument to be made for this. It'll go into the thinking about the refactoring of the code. blks2impl must be burned I think the structure in the gr-noaa directory is a good example of how to organize a set of related blocks and applications. There is also the concept of using SWIG's XML output for the GRC files. I've only played around a bit with them, but it's something to look into if you haven't already. It looks like it captures _most_ of the information about the blocks that is exposed in the GRC xml files. It's fairly expressive output, so we'd have to see if it actually covers everything necessary for GRC to use with updated parsing. Have you already looked at, and dismissed, this, Josh? I have not looked at nor have I dismissed the possibility. There are certain visually appealing things you can do like hiding parameters that dont matter when another parameter is set, or grouping two similar blocks that have different outputs. I believe that there is no general abstraction on how to do this and that generated xml files will be somewhat lacking. That said, maybe generating the xml files might be useful for enough of the blocks that its worth figuring out. Maybe we can have a middle ground and find a way to generate the xml and leave a place to get extra block specific information into the generator. Basically, I will take a look at the SWIG XML when I get the chance. -Josh I think having the XML generated automatically (mostly) from the underlying SWIG/C++ is a very nifty idea. But I think I agree with Josh that some of the semantics are going to need to be grafted in post-facto. Unless we can come up with some clever way of deriving those semantics from the underlying C++ code. But moving towards a single, de facto location for all of this, and having the rest be derived by an automated build-time process would be sweet. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] shmat issue
I'm seeing this issue on my omap3 install with the dialtone flowgraph: # python /usr/share/gnuradio/examples/audio/dial_tone.py gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument l# python /usr/share/gnuradio/examples/audio/dial_tone.py In both cases I can hear the dial tone fine. I'm curious why I get the shmat error the first time only. It looks like gnuradio falls back to another method of creating the shared segment. I'd like to resolve the shmat issue though, because I am also trying to run the kalibrate program and have the same shmat issue there, but it does not have a fall back method. Thanks, Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 UART use
We're exploring the possibility of monitoring the overrun/underrun status via the USRP2 UART. I'm curious to learn what approaches people have taken to do this (e.g., connect the UART to a logic analyzer, use a level shifter - RS232 - host serial/USB port, etc.). I'd also like to know what other information is available via this port and any other information people can share about there experience using the UART port. I've found some level shifter cables that seem ideal and aren't too expensive ($30), but I'd like to hear what (if anything) other folks are doing. Thanks, --Bob P.S. I attempted to send this out several hours ago, but for some reason it didn't make it. If the original does resurface, I apologize in advance for the duplicate posting. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 UART use
On Tue, Oct 19, 2010 at 8:14 PM, b...@sigmatix.com wrote: We're exploring the possibility of monitoring the overrun/underrun status via the USRP2 UART. I'm curious to learn what approaches people have taken to do this (e.g., connect the UART to a logic analyzer, use a level shifter - RS232 - host serial/USB port, etc.). I'd also like to know what other information is available via this port and any other information people can share about there experience using the UART port. I've found some level shifter cables that seem ideal and aren't too expensive ($30), but I'd like to hear what (if anything) other folks are doing. We use a UART-to-USB converter board from Sparkfun for accessing the UART on the USRP2, typically plugged into minicom: http://www.sparkfun.com/commerce/product_info.php?products_id=10009 Cheap, simple, and the FTDI Linux drivers work fine at 230.4 Kbps (the rate of the UART on the USRP2). We've instrumented the USRP2 firmware at different times with debug messages to understand what is going on, but that is about it. It can be very helpful for the right situation. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 UART use
On 10/19/2010 06:14 PM, b...@sigmatix.com wrote: We're exploring the possibility of monitoring the overrun/underrun status via the USRP2 UART. FYI, the USRP2 under UHD reports underflows as async messages to the host that can be accessed through the API. There are no true overflows since the implementation drops packets on the ground when the host buffers fill. But you can observe packet loss by inspecting the timestamps on a packet. This is done in the benchmark rx example application. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
On Tue, Oct 19, 2010 at 08:34:40PM -0400, Philip Balister wrote: I'm seeing this issue on my omap3 install with the dialtone flowgraph: # python /usr/share/gnuradio/examples/audio/dial_tone.py gr_vmcircbuf_createfilemapping: createfilemapping is not available gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument l# python /usr/share/gnuradio/examples/audio/dial_tone.py From $ man shmat EINVAL Invalid shmid value, unaligned (i.e., not page-aligned and SHM_RND was not speci- fied) or invalid shmaddr value, or can’t attach segment at shmaddr, or SHM_REMAP was specified and shmaddr was NULL. In both cases I can hear the dial tone fine. I'm curious why I get the shmat error the first time only. You should see it only once ever, if the program can write to ~/.gnuradio/prefs. Generally this gets written during make check. Does make check work? Why are you running as root? It looks like gnuradio falls back to another method of creating the shared segment. Yes it does. I'd like to resolve the shmat issue though, Set a breakpoint with gdb, or add printfs. because I am also trying to run the kalibrate program and have the same shmat issue there, but it does not have a fall back method. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
