Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
Hi, Thank you. Tx/Rx on the old Flex2400 using the usrp2 is now working. On 01/09/2010 21:41, Jason Abele wrote: On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote: On 09/01/2010 12:51 PM, Jason Abele wrote: I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: prefix/share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason So, Jason, is this because the older FLEX-series boards used an on-board clock that is *different* than the one supplied by the USRP2, and the driver code (either Classic or UHD) assumes a different clock rate than the one that was previously on-board, and thus is mis-programming the PLL? If the two clocks are the same frequency, then I don't understand why changing from clock supplied on-board to clock supplied by USRP2 would fix the problem. Inquiring minds want to know... There are two problems: 1. When daughterboards were built with onboard oscillators, they were all 64MHz (presumably to play nicely with the USRP1 64MHz oscillator), but the USRP2 uses a 100MHz reference. Thus, when the daughterboard driver tunes the synthesizer, it is presuming a 100MHz reference on the USRP2 (actually, the UHD daughterboard drivers ask the motherboard what clock reference frequencies it can provide, and then chooses the best option), thus it would misconfigure the RFX synthesizer because it would not know that the reference frequency was 64MHz. 2. Actually, it never gets to mistuning the synthesizer because we used the daughterboard id to separate the MIMO B version of the RFX (ie. uses refclock from USRP motherboard) from the non-MIMO versions (with oscillator on board). However, the USRP2 (using either raw ethernet or UHD drivers) does not implement the daughterboard control for the non-MIMO versions. Hence why the burn_db_eeprom command is needed to change the daughterboard id. I put an issue in our issue tracker to add a warning to the UHD code and some notes in the daughterboard documentation to let users know about converting non-MIMO versions of the RFX to MIMO versions, I expect the fix will roll into one of the next few releases. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] use of pulseaudio -- some parameters to call?
Hi Alex, Can you actually get usable audio in and out when you use pulse for device? Yes (OpenSuSe) -- this is the only way to get some audio operation with GnuRadio on top of pulseaudio here. I use Ubuntu 9.10 and 10.04 and none of my computers are able to work with that setting. I have Ubuntu 09.04 and 09.10 (some as Linux-Mint, some in a Virtualbox on top of SuSe) all with pulse audio. All of them have the expected audio function (in and out). For the VBox you can set withIn gnuradio als samplerates whcih seems to be converted in VBox environment. On LinuxMint installation (no VBox, direct) there are some limits for the samplerate to 44,1, kHz or to 48 kHz. So, for the operation in GnuRadio, I prefer the use of Alsa on top of Pulseaudio. But there are still some questions how to get influence to the parameters? Even when I looked into the sources I found some methods for changing parameters, but I did not understand how to call them from GRC environment supplied with GnuRadio 3.3.1git(20100805) Using the default alsa devices, i.e. leaving it empty, works quite all right. According to the pulseaudio docs, alsa applications will automatically be routed through pulseaudio via the alsa-plugin. for my environment on SuSe I had to use the device_name parameter pulse to use the alsa_plugin of pulseaudio. Are you sure your hardware actually supports all those sample rates? I suspect the reported sample rates are software rates from the mixer and not native rates of the hardware. I have hardware that only supports 44.1 and 48 kHz yet I get the same list as you get. Using other LINUX software e.g. LabView as I understand, it is possible to change the hardware samplerate of the soundcards. But for the signal processing in GnuRadio there may no effect if the hardware samplerate is changed since the software solution in gnuradio depends on a specfied samplerate inside gnuradio(GRC) -- the hardware samplerate may be tranparently changed in low level routines as the hardware needs. Thanks for the answer M. Hartje -- Prof. Dr.-Ing. Michael Hartje Labor Hochspannungstechnik / Labor elektrische Messtechnik Neustadtswall 30; D-28199 Bremen Tel +49 421 5905-3444 FAX +49 421 5905-3476 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] More test bench stuff with usrp_std
Hi all,
I'm trying to modify the test bench provided with the standard USRP verilog
code
to work with the latest version of the usrp_std module. I'm using the 2rx 0tx
config.
My problem is that I don't think I'm initializing the usrp_std module properly;
I'm not sure of the order of events that should happen to start getting data
out
of the module. I can never get it to assert the usbrdy[1] signal, and thus it
never has data ready . Here are the highlights of what I do:
I create a usb, adc, and master clock: (default time unit is ns)
always #16 clk_120mhz = ~clk_120mhz; //1/16ns = 62.5MHz (?)
always #60 usbclk = ~usbclk; //1/60ns = 16.67MHz (what does FX2 give us?)
always #16 adclk = ~adclk; // 1/16ns = 62.5MHz
I start generating adc data
always @(posedge adclk) adc1_data = #1 adc1_data + 1;
always @(posedge adclk) adc2_data = #1 adc2_data + 1;
I (think) I reset the rx and (presumably non-existent) tx chains:
#1000
send_config_word(`FR_MASTER_CTRL,32'hc); //TX, RX reset
I then set up what I think are the pertinent registers to get the rx chains
going:
#1000
send_config_word(`FR_MASTER_CTRL, 32'h2); //RX enable
send_config_word(`FR_RX_SAMPLE_RATE_DIV, 32'h2);// 128e6/64e6 = 2 divisor
(closest!)
send_config_word(`FR_DECIM_RATE, 32'h1); //decimation rate = 1
send_config_word(`FR_RX_FREQ_0, 32'h0); //ddc center freq, rx0 = 0
send_config_word(`FR_RX_FREQ_1, 32'h0); //ddc center freq, rx1 = 0
send_config_word(`FR_RX_PHASE_0, 32'h0); //ddc phase acc word
send_config_word(`FR_RX_PHASE_1, 32'h0); //ddc phase acc word
send_config_word(`FR_RX_MUX, {12'h0, 2'h3, 2'h3, 2'h2, 2'h2, 2'h1, 2'h1, 2'h0,
2'h0, 1'b1, 3'h0});
//rx mux set so that DDCn gets ADCn, complex samples ignored
send_config_word(`FR_RX_FORMAT, {21'h0, 1'b0, 1'b1, 5'hf, 4'h0}); //set rx
data
format control register: 16 bits, want Q
I can see in ModelSim that the serial data is banged in properly. However, I
get no joy. The usrp_std module simply never spits anything out. The
burst_usb_read() task included with the test bench code waits for usbrdy[1] to
be asserted, but it never does. I've already tried to set the OE and RD inputs
to see what happens, but nothing does.
Any input would be greatly appreciated.
Nelson.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp2::rx_samples() failed when switching rx_path using the latest git_trunk
Hi, What could be the reason for this error? usrp2: channel 0 not receiving usrp2::rx_samples() failed From some previously post, Johnathan said that this should be fixed in releases after 3.2.2 I'm using the latest git trunk version, I've change the firmware (to txrx_raw_eth_20100608.bin) and the fpga image (to u2_rev3-20100603.bin) (I am using USRP2 + RFX2400). And the error still occur! Why? My top_block basically contains a usrp2_sink and a usrp2_source block and a rx_path and a tx_path. The rx_path and the tx_path are changed during runtime with the following sequence: top_block.lock() top_block.disconnect() top_block.connect() top_block.unlock() The error occurs after a random number of switches of the different paths (sometimes it works for 30 switches and sometimes just for 3) and the program requires a restart to get rid of the problem. Br, Patrik Eliardsson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
The strange thing is that when the fft's sample rate is at 25Msps which equals the USRP's bandwidth at a decimation of 4 everything works fine with the regular fft sink yet not with the OpenGL one. However when I increase the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both sinks work fine. What does this mean? I'm really convinced all this is because graphics are rendered strictly through software. Does GRC even support graphics hardware acceleration? how do I configure it? -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29604761.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 10:09 AM, Jack Ott wrote: The strange thing is that when the fft's sample rate is at 25Msps which equals the USRP's bandwidth at a decimation of 4 everything works fine with the regular fft sink yet not with the OpenGL one. However when I increase the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both sinks work fine. What does this mean? I'm really convinced all this is because graphics are rendered strictly through software. Does GRC even support graphics hardware acceleration? how do I configure it? The application has very little control over such things. The X server implementation is responsible for dealing with hardware acceleration, I think via something called the Direct Rendering Manager. OpenGL will take advantage of that, if it's an available option in your X server. I'd try changing the update rate in your FFT window--change the Refresh Rate parameter in your FFT window from the default of 30 to 5 and see if that makes a difference. I'm betting that it will. -- 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
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 07:09 AM, Jack Ott wrote: The strange thing is that when the fft's sample rate is at 25Msps which equals the USRP's bandwidth at a decimation of 4 everything works fine with the regular fft sink yet not with the OpenGL one. However when I increase the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both sinks work fine. What does this mean? I'm really convinced all this is because graphics are rendered strictly through software. Does GRC even support graphics hardware acceleration? how do I configure it? Jack, I think you are missing the point here. There is no need to lie to the program. If you are sending the FFT sink 25 MS/s, then tell it you are sending it 25 MS/s. If you give it a different rate you will have all sorts of other issues, like incorrect frequency scales on the display. If you want to decrease the processor load then reduce the display update rate. If you have unaccelerated OpenGL, then the OpenGL version will be unacceptably slow. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 11:39 AM, Matt Ettus wrote: If you have unaccelerated OpenGL, then the OpenGL version will be unacceptably slow. Matt Any idea how you *tell* if your OpenGL is accelerated or not? How does this relate to the Direct Rendering Manager in the X server? -- 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
Re: [Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP
Sam, Coming from a Windows user, I have to say that switching to Ubuntu was 1) extremely easy and 2) greatly accelerated my understand and ability to use GNURadio/USRP - mainly because I could use the GRC, which is a Labview-like graphical interface to GNURadio and USRP. I'd *highly* recommend giving it a shot first, at least to learn with, before trying Windows development. That's my 0.02. YMMV. Also check out the Simulink libraries - I think they're linked from Ettus.com -William On Wed, Sep 1, 2010 at 5:36 PM, Sam Evans sam_evans1...@yahoo.com wrote: Hi everybody, I would like to ask some questions regarding USRP. I really need some help. I got my USRP with a WBX and LP0410. I work on a computer running Windows XP. After I read many thing about how to install the GNU Radio in Windows environment I could install it using MingW. I used the gnuinstall.py python script like many others but when I tried to run my first script in python I got an error message ImportError: No module named gnuradio. I don't know what is the problem, the gnuradio is installed, the latest one GNU Radio 3.3.0. Could anybody help me with some ideas, how to make it work, and what I'm missing. The second question would be. I would like to use the GNU Radio for a real application. I want to make a .NET application with Delphi Prism and to be able to get data from USRP an set data. There are many informations out there to emulate python (there are even DLL files) to be able to run python scripts from a .NET application. What I want is to exchange data with some devices running on 2 ISM bands (433 and 868). I will make an application with Visual Studio 2010 and I would like to be abel to read data through python script, interprete data and display in the form as some value or a therometer showing the value sent by a device. Wireless devices will have ASK, OOK modulation, some simple stuff. Anybody have made something like this and could help me to start it, I'll make all the work but I need some help from those who already made something like this. Do you have any other idea how could I implement this, what other solution do exists? A alternative would be to use LabView but there are problems, too. No documentation or some help. It would be very good to have some DLL files that would implement functions and interface to the USB data, but even if I was searching for a long time, I couldn't find anything. I'm opened to any suggestion, because right now I'm stuck, I don't have any idea. Thank you very much for any idea. I wish everybody a nice day. Best regards, Sam Evans. ___ 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
[Discuss-gnuradio] Dimension of the y axis using usrp_oscope.py
Hello! I am doing some experiments using usrp_oscope.py. I am especially interested in comparing the values obtained from the usrp devices and those measured from a traditional oscope. Unfortunately one can't find any hint which dimension (volts, etc.) is used for displaying the graph. Thanks a lot for your help! Cheers, Fabian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On Thu, Sep 2, 2010 at 5:53 PM, Marcus D. Leech mle...@ripnet.com wrote: On 09/02/2010 11:39 AM, Matt Ettus wrote: If you have unaccelerated OpenGL, then the OpenGL version will be unacceptably slow. Matt Any idea how you *tell* if your OpenGL is accelerated or not? I know several ways that work for me: Try executing glxinfo or glxgears. I can only execute them if I have 3D acceleration enabled. If you are using Gnome desktop or something similar, you can try to enable Desktop effects - they wont work either without 3d acceleration. With ATI and Nvidia based cards it is rather easy to tell because 3D acceleration is only available with the proprietary drivers and you can not (or should not be able to) install them by accident. They also provide some configuration and diagnostic tools that should be accessible from the menus. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Detecting transmit underruns on UHD
With UHD, how can I programmatically detect when transmit underruns have occurred? I see Us in the output both on the host and from the USRP2 serial port, but I haven't spotted an API to test for this condition. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On Thu, Sep 2, 2010 at 08:39, Matt Ettus m...@ettus.com wrote: I think you are missing the point here. There is no need to lie to the program. If you are sending the FFT sink 25 MS/s, then tell it you are sending it 25 MS/s. If you give it a different rate you will have all sorts of other issues, like incorrect frequency scales on the display. If you want to decrease the processor load then reduce the display update rate. Just to elaborate a bit on this. The FFT sink in GNU Radio incorporates time domain frame decimation via the keep one in n block. The sample stream input to the sink is divided into frames at the configured FFT size (1024 samples by default in GRC). Then, only one frame per n is forwarded out to the FFT block, with n being calculated as the sample rate divided by the display update rate, then divided by the FFT size. In this way, we only burden the CPU with the windowing/FFT/log power calculation and graphics rendering as many times as is needed to refresh the display at the requested rate (which are still all using fast C++ code, not Python.) The sample rate parameter to the FFT sink is *not* a control input. You are simply telling the flowgraph the correct numerical time base of the input sample stream, to be used in the above calculation. The sample rate itself is usually established elsewhere; in this case, by the upstream USRP2 source block's decimation parameter. The sample rate parameter is also used to correctly display the units on the x-axis of the FFT window. Thus, the proper way to control the CPU usage of the FFT sink is to vary the update rate, as was mentioned by Matt and others. If in fact you are CPU-bound, then lying to the FFT sink by giving it an artificially high, incorrect sample rate will have the side effect of increasing the time frame decimation, thus lowering the CPU load, and appearing to cure the problem. But the x-axis units/scale will be incorrect and the update rate won't match the requested rate. (None of this speaks to whether your system's OpenGL/video card combination is properly functioning or whether it results in a performance improvement over the non-GL version of the sink.) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dimension of the y axis using usrp_oscope.py
It will be completely dependent on your receiver chain. My understanding is that the values you are seeing are the output of the ADC, so you'll need to figure out what the voltages at that point are. Perhaps someone else can be more helpful, but you'll need to do the legwork. What receiver are you using? -William On Thu, Sep 2, 2010 at 12:20 PM, Fabian Steiner r...@fabis-site.net wrote: Hello! I am doing some experiments using usrp_oscope.py. I am especially interested in comparing the values obtained from the usrp devices and those measured from a traditional oscope. Unfortunately one can't find any hint which dimension (volts, etc.) is used for displaying the graph. Thanks a lot for your help! Cheers, Fabian ___ 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] Detecting transmit underruns on UHD
See recv async message: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 And the async metadata: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html -Josh On 09/02/2010 12:58 PM, Marc Epard wrote: With UHD, how can I programmatically detect when transmit underruns have occurred? I see Us in the output both on the host and from the USRP2 serial port, but I haven't spotted an API to test for this condition. -Marc ___ 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] GRC's graphical sinks performance issues
Marcus D. Leech wrote: On 09/02/2010 11:39 AM, Matt Ettus wrote: If you have unaccelerated OpenGL, then the OpenGL version will be unacceptably slow. Matt Any idea how you *tell* if your OpenGL is accelerated or not? How does this relate to the Direct Rendering Manager in the X server? Yes, the simplest way to tell is if I disable 3D acceleration through the driconf utility, after which glxgears becomes noticeably slower, it goes from displaying 60 vertically synched frames to 16. I also marked DRI in xorg.conf as false, yet in either case I get the exact same performance from GRC. On another note I forgot to mention that I already had the fft's refresh rate at 10Hz instead of the default 30. I just don't understand why GRC is the only program not leveraging the graphics card. I also stumbled upon this http://gnuradio.org/redmine/wiki/gnuradio/CompGrWxgui#Enable-the-GL-Sinks It talks in the bottom of the page about the Intel G965 chipset, since I have the mobile version GM965 I thought it might have something to do with this, but so far no luck. -- 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 -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29607093.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD recv timestamp differs from stream command time spec
I'm using a USRP2 with UHD and starting a receive a short time in the future. I have an external reference and PPS. Below is the pertinent code, slightly simplified. The timestamp returned in the metadata by recv is always off a little from the time I requested in the stream command. The amount it is off seems to be consistent and related to the sampling rate. For 25 Msps, it's always off by 230 nanoseconds, for 12.5 Msps, it's off by 270 nanoseconds, for 6.25 Msps, it's off by 350 nanoseconds. If I receive one packet at a time using RECV_MODE_ONE_PACKET, the first packet's metadata is off by the same amount. I'm using the latest gnuradio and uhd (the one with USRP1 support). Should I expect the timestamp in the received metadata to match the requested time in the stream command? -Marc // set_clock_config elided. uhd::stream_cmd_t streamCommand(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); streamCommand.num_samps = _buffer.size(); streamCommand.stream_now = false; streamCommand.time_spec = startingTime; _usrp-issue_stream_cmd(streamCommand); size_t numReceived = _device-recv(_buffer[0], _buffer.size(), metadata, uhd::io_type_t::COMPLEX_INT16, uhd::device::RECV_MODE_FULL_BUFF); // Error checking elided. fprintf (stdout, Off by %g nanoseconds.\n, (metadata.time_spec - startingTime).get_real_secs()*1e9); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting transmit underruns on UHD
Oh cool! When was that implemented? I missed it... I assume there is no problem with timeout = 0? Is the interface thread safe? read/write/recv_async? --Eric On Thu, 2010-09-02 at 13:23 -0400, Josh Blum wrote: See recv async message: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 And the async metadata: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html -Josh On 09/02/2010 12:58 PM, Marc Epard wrote: With UHD, how can I programmatically detect when transmit underruns have occurred? I see Us in the output both on the host and from the USRP2 serial port, but I haven't spotted an API to test for this condition. -Marc ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] use of a bulletin board system in lieu of a mailing-list discussion
Hello, all. OK, I know I'm just the new guy here, and it may be poor form to suggest that a well established forum should change its ways But I find the email-based discussion list VERY inefficient. - any sense of threading of a conversation is lost (at least for me: I receive the digest version.) - if there is a way for me to search for my issue in prior threads, I haven't found it yet. (Maybe I'm missing it or maybe it doesn't exist) - email arrives even on days when I'm not focusing on my GNU radio projects. I'm part of other organizations that use a web bulletin board very effectively. It addresses all the above issues: threading, searching prior discussions, and simply being there when one needs it. One such system is vBulletin (http://www.vbulletin.com/). This system is a bit different from a wiki (which has static pages that anyone can update). Rather, someone posts a post in a forum. Follow up posts are seen distinctly (you can't edit someone else's post), and all such follow ups to an original post are called a thread. Is there any interest in considering a shift to it or something similar? Yes, it would need: a physical host, effort to set it up, an admin (for membership issues), and a panel moderators (to edit / move threads when necessary). And maybe the cost of the software. I understand that if there is a lack of interest (to participate), or if no one is available to set it up, it won't happen. If so: /c'est la vie/... However, I just wanted to float the idea in case there is general interest and the right set of volunteers. -- Dan Harasty attachment: dharasty.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting transmit underruns on UHD
On Sep 2, 2010, at 12:23 PM, Josh Blum wrote: See recv async message: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 And the async metadata: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html Thanks, Josh. Now that you mention it, I remember your announcement where that was added. It looks like I'll need another thread to watch for those messages, right? -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD recv timestamp differs from stream command time spec
On 09/02/2010 10:39 AM, Marc Epard wrote: I'm using a USRP2 with UHD and starting a receive a short time in the future. I have an external reference and PPS. Below is the pertinent code, slightly simplified. The timestamp returned in the metadata by recv is always off a little from the time I requested in the stream command. The amount it is off seems to be consistent and related to the sampling rate. For 25 Msps, it's always off by 230 nanoseconds, for 12.5 Msps, it's off by 270 nanoseconds, for 6.25 Msps, it's off by 350 nanoseconds. If I receive one packet at a time using RECV_MODE_ONE_PACKET, the first packet's metadata is off by the same amount. I'm using the latest gnuradio and uhd (the one with USRP1 support). Should I expect the timestamp in the received metadata to match the requested time in the stream command? The timestamp that you request is used as the time to turn on the receiver. The timestamp returned with the data is the time of those samples at the output of the receive DSP chain. Since there is decimation in the receive chain, there will be some delay between when you enable the receiver and when the DSP spits out its first sample. When using our standard DSP units that we provide in the code, this delay is a function of the decimation rate. If you really need your first sample to be at time X, you will need to send a command which starts the receive chain a little early. There are two related issues. First, if you are using the standard ATR settings, the receiver is turned off when you are not receiving. Nothing powers up instantly, so if you want to have useful reception at a particular time, you will also need to turn it on early. The second issue is group delay through the RF, ADC, and DSP. We demarcate time at the output (decimated) side of the DSP. That data came in over the air some time earlier, but that time delta is a function of the daughterboard design and settings (particularly the filters), the ADC design, and the DSP design and settings. The DSP delays can be calculated. In any application where you need to know to the nanosecond the time a particular sample represents at the antenna port you will need to calibrate the delays. All of this applies to the TX side as well, in reverse. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] use of a bulletin board system in lieu of a mailing-list discussion
Dan, Other than the difficulty of setting up and maintaining the site, I think it's a fabulous idea! Then again, I'm just as new as you are, but in general I think it would be *way* better. Especially for new folks jumping in and learning all the past body of knowledge. -William On Thu, Sep 2, 2010 at 1:47 PM, Dan Harasty dhara...@telcordia.com wrote: Hello, all. OK, I know I'm just the new guy here, and it may be poor form to suggest that a well established forum should change its ways But I find the email-based discussion list VERY inefficient. - any sense of threading of a conversation is lost (at least for me: I receive the digest version.) - if there is a way for me to search for my issue in prior threads, I haven't found it yet. (Maybe I'm missing it or maybe it doesn't exist) - email arrives even on days when I'm not focusing on my GNU radio projects. I'm part of other organizations that use a web bulletin board very effectively. It addresses all the above issues: threading, searching prior discussions, and simply being there when one needs it. One such system is vBulletin (http://www.vbulletin.com/). This system is a bit different from a wiki (which has static pages that anyone can update). Rather, someone posts a post in a forum. Follow up posts are seen distinctly (you can't edit someone else's post), and all such follow ups to an original post are called a thread. Is there any interest in considering a shift to it or something similar? Yes, it would need: a physical host, effort to set it up, an admin (for membership issues), and a panel moderators (to edit / move threads when necessary). And maybe the cost of the software. I understand that if there is a lack of interest (to participate), or if no one is available to set it up, it won't happen. If so: *c'est la vie*... However, I just wanted to float the idea in case there is general interest and the right set of volunteers. -- Dan Harasty ___ 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] use of a bulletin board system in lieu of a mailing-list discussion
On Thu, Sep 02, 2010 at 01:47:34PM -0400, Dan Harasty wrote: Hello, all. OK, I know I'm just the new guy here, and it may be poor form to suggest that a well established forum should change its ways :-) But I find the email-based discussion list VERY inefficient. - any sense of threading of a conversation is lost (at least for me: I receive the digest version.) - if there is a way for me to search for my issue in prior threads, I haven't found it yet. (Maybe I'm missing it or maybe it doesn't exist) Google works for me: gnuradio + whatever I care about gets me one of the N mailing list archives, where the messages are threaded. - email arrives even on days when I'm not focusing on my GNU radio projects. Gee, that sounds like your mail handling tools suck. I'd suggest the non-digest format, and have your MUA automatically put the messages into a folder that you only look at when you care about GNU Radio. I'm assuming that your MUA can sort out the threading. I'm part of other organizations that use a web bulletin board very effectively. It addresses all the above issues: threading, searching prior discussions, and simply being there when one needs it. One such system is vBulletin (http://www.vbulletin.com/). This system is a bit different from a wiki (which has static pages that anyone can update). Rather, someone posts a post in a forum. Follow up posts are seen distinctly (you can't edit someone else's post), and all such follow ups to an original post are called a thread. Is there any interest in considering a shift to it or something similar? Who knows? You can of course subscribe an address that gets gateway'd to where ever you like. Yes, it would need: a physical host, effort to set it up, an admin (for membership issues), and a panel moderators (to edit / move threads when necessary). And maybe the cost of the software. I understand that if there is a lack of interest (to participate), or if no one is available to set it up, it won't happen. If so: /c'est la vie/... However, I just wanted to float the idea in case there is general interest and the right set of volunteers. -- Dan Harasty Thanks for the suggestion and the links. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 UHD consecutive tx timestamps
I would like to be able to send a continuous stream of tx packets, each with a timestamp, such that if one is dropped, the next will be transmitted at the correct time. My use case involves CDMA test signal generation, and currently a dropped packet causes a total loss of sync on the test devices (as opposed to a temporary signal interruption). I realize that this capability is highly dependent on how the time logic and packet queuing is implemented. Is this a feature request that you might consider? --Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] use of a bulletin board system in lieu of a mailing-list discussion
On 09/02/2010 10:47 AM, Dan Harasty wrote: Hello, all. OK, I know I'm just the new guy here, and it may be poor form to suggest that a well established forum should change its ways But I find the email-based discussion list VERY inefficient. A lot of people on here seem to use Nabble which provides the bulletin board interface. The mailing list already has search and archive features, as do Nabble and Google. On a more philosophical note, I think a mailing list better encourages participation and community. For example, if everyone only looked at the forum when they had a question that they were hoping to have answered, then there would never be anybody there to answer them. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting transmit underruns on UHD
On 09/02/2010 01:54 PM, Marc Epard wrote: On Sep 2, 2010, at 12:23 PM, Josh Blum wrote: See recv async message: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 And the async metadata: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html Thanks, Josh. Now that you mention it, I remember your announcement where that was added. It looks like I'll need another thread to watch for those messages, right? That is one possibility. You can also poll for the messages by using a timeout of zero. Depends on your application and what is most convenient. -josh -Marc ___ 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] Detecting transmit underruns on UHD
On 09/02/2010 01:46 PM, Eric Schneider wrote: Oh cool! When was that implemented? I missed it... http://old.nabble.com/UHD-Announcement---August-16th-2010-td29457066.html I assume there is no problem with timeout = 0? should be fine Is the interface thread safe? read/write/recv_async? You can have a separate thread for send, recv, async recv, control (sets/gets). So thats fine, but dont (for example) use multiple threads to call send, or multiple threads to set properties. -josh --Eric On Thu, 2010-09-02 at 13:23 -0400, Josh Blum wrote: See recv async message: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 And the async metadata: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html -Josh On 09/02/2010 12:58 PM, Marc Epard wrote: With UHD, how can I programmatically detect when transmit underruns have occurred? I see Us in the output both on the host and from the USRP2 serial port, but I haven't spotted an API to test for this condition. -Marc ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Eric, thanks for the insightful reply. I will be using these pins for my design. what else is provided to the board through Ethernet? If I understand correct, the configuration data for DAC (such as the IF frequency, etc) is provided through Ethernet, but we don't really want to change those, so I'd like to program those registers one and won't touch them again. For that do I need to just change the firmware? Is there any other important point I need to care about if I remove the Ethernet modules in FPGA? Thanks, Malihe Eric Blossom wrote: On Wed, Sep 01, 2010 at 07:07:26PM -0600, Malihe Ahmadi wrote: Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. The MICTOR debug connector, J301, has 32 uncommitted pins and 2 clks. It's currently configured as an output, but you can use it for whatever you like. Look in u2_rev3.v and/or u2_core.v. output [31:0] debug, output [1:0] debug_clk, That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD recv timestamp differs from stream command time spec
On Sep 2, 2010, at 1:02 PM, Matt Ettus wrote: [An excellent answer.] Thanks! -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
On 09/02/2010 02:48 PM, Malihe Ahmadi wrote: I need 5 mega bit per sec of bandwidth and if I understand correct the rate of CMII_TX_CLK is 100 mega bit per second which is higher than what I want. The first reason I don't like GiGe is that it chunks the data and it can cause delay in its stream (I rather have my own protocol to transmit data to the FPGA) but I think I can bear with that! The second reason is that I don't know what is the relation between the stream of data generated at the source (for example by sig_source_i()) and the GMII_TXD input signal to the FPGA and eventually sample_tx input of dsp_core_tx. Can somebody explain that relation for me? Also, does anybody have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe The rate that data is actually sent over the GiGe depends on your decimation/interpolation settings. The FPGA sees a continuous stream of numbers that represent a signal, generally sinusoidal in nature. That stream is a complex-baseband representation of your signal, which the FPGA will interpolate, possibly digitally upconvert, and present to the RF transmitter hardware. Similarly on receive the FPGA gathers the complex baseband data from the A/D, decimates and filters it, and presents it to the GiGe interface for transmission to the host as complex baseband samples. I think you may be confusing the data rate of whatever modulation scheme you want to use in your application, with the rate that the *waveform data* is presented into/out-of your Gnu Radio flow-graph. The packetization is generally not an issue, unless you are running at the edge where the host computer can't keep up, which produces overruns on receive, and under-runs on transmit. But for modest-bandwidth signals, with a decent CPU, this doesn't happen very often. The GiGe interface is simply a convenient and relatively-cheap way of getting complex-baseband data into/out-of the FPGA (along with the occasional programming instructions for the PLL synthesizers, gain controls, etc, on the daughter-cards). -- 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
Re: [Discuss-gnuradio] USRP2 FPGA Compiling
I downloaded the ise12 branch of the fpga code. Compiled it using the makefile, and ISE12.2 gui tool. Both did not work in the usrp2, giving the same results...what a shame. SteveChrepta wrote: I am preparing to make small changes to the fpga code. First I wanted to compile the latest fpga code and verify its operation. I downloaded (git) the latest fpga code. I have ISE 12.2 running on a WINXP_Pro SP2 PC. I modified the makefiles to work with the latest cygwin. Actually I invoke make proj to create the ISE project, and then use the ISE tool in Windows to perform the compile. I set the Design Goal to Timng Performance and the fpga build completes successfully with no errors and all timing constraints met! I generate the programming file, u2_rev3.bin, and put it on the SD card. The problem is that the LEDs on the USRP2 do not behave correctly. After power-on, the F-LED lights, and that's all. This says that the fpga is configured, but the follow-on all-LED blink and D-LED did not happen. The ISE 12.2 that I am using is a full version that I downloaded, and I have a 30-day free trial license. All indications of the ISE tool seem to be ok for a successful fpga build. The .bin file size is the same as the original. As I stated before, there were no build errors, but many Warnings, related to port size mismatch, registers with IOB=TRUE, that are not associated with IOBs, unused module inputs, RAM_Dn inputs never assigned. Actually, in the USRP2 schematic, PIN V15 is reset_fpga and in the u2_rev3.ucf file, PIN V15 is PHY_CLK. So there is a discrepency. I will check the other pins. Any help is appreciated. Also if anyone can email to me their successful build warning report(s), this can help. I'm sorry for the long posting. Thank you, Steve. -- View this message in context: http://old.nabble.com/USRP2-FPGA-Compiling-tp29586343p29608036.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, do you have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe Nick Foster wrote: Malihe, The USRP2 drivers are designed to abstract the user from the device transport, and in normal use you shouldn't have to concern yourself with the transport layer at all. You provide a stream of data in gnuradio, and the USRP2 provides a stream of data out the device (or vice versa). All the magic that happens between should be transparent. To the user, there is no packetization at all on transmitted data -- discrete Ethernet data packets are buffered in the USRP2 and transmitted seamlessly by the device. If you are seeing gaps in signal when viewed on a scope, you are probably experiencing buffer underruns caused by running at a data rate too fast for your CPU to handle. Can you explain the problem you are seeing with your device? Nick Date: Wed, 1 Sep 2010 19:07:26 -0600 From: ahmad...@ualberta.ca To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ 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
[Discuss-gnuradio] Fwd: problem with address book upload and mailing lists [Ticket: 100829-000092]
FYI, I guess the linkedIn spam mail issue is solved. Best regards, Aaron. Begin forwarded message: LinkedIn Customer Support Message Subject: problem with address book upload and mailing lists Hi Aaron, No, only the discuss-gnuradio@gnu.org was used on the member's account. I've now removed that address and put it on our Do not contact list, along with your other requested e-mail addresses. If you have further questions, please feel free to reply to this message. Zach LinkedIn Customer Support PGP.sig Description: This is a digitally signed message part ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, do you have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe Nick Foster wrote: Malihe, The USRP2 drivers are designed to abstract the user from the device transport, and in normal use you shouldn't have to concern yourself with the transport layer at all. You provide a stream of data in gnuradio, and the USRP2 provides a stream of data out the device (or vice versa). All the magic that happens between should be transparent. To the user, there is no packetization at all on transmitted data -- discrete Ethernet data packets are buffered in the USRP2 and transmitted seamlessly by the device. If you are seeing gaps in signal when viewed on a scope, you are probably experiencing buffer underruns caused by running at a data rate too fast for your CPU to handle. Can you explain the problem you are seeing with your device? Nick Date: Wed, 1 Sep 2010 19:07:26 -0600 From: ahmad...@ualberta.ca To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ 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] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi MArcus, Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, can I get those occasional programming instructions you mentioned to be hard-coded (for example changing the firmware so that it uses some default values instead of passing those values through GiGe) if I am interested in removing Ethernet and using debug bus to pass stream of data to the FPGA? Thanks, Malihe Marcus D. Leech wrote: On 09/02/2010 02:48 PM, Malihe Ahmadi wrote: I need 5 mega bit per sec of bandwidth and if I understand correct the rate of CMII_TX_CLK is 100 mega bit per second which is higher than what I want. The first reason I don't like GiGe is that it chunks the data and it can cause delay in its stream (I rather have my own protocol to transmit data to the FPGA) but I think I can bear with that! The second reason is that I don't know what is the relation between the stream of data generated at the source (for example by sig_source_i()) and the GMII_TXD input signal to the FPGA and eventually sample_tx input of dsp_core_tx. Can somebody explain that relation for me? Also, does anybody have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe The rate that data is actually sent over the GiGe depends on your decimation/interpolation settings. The FPGA sees a continuous stream of numbers that represent a signal, generally sinusoidal in nature. That stream is a complex-baseband representation of your signal, which the FPGA will interpolate, possibly digitally upconvert, and present to the RF transmitter hardware. Similarly on receive the FPGA gathers the complex baseband data from the A/D, decimates and filters it, and presents it to the GiGe interface for transmission to the host as complex baseband samples. I think you may be confusing the data rate of whatever modulation scheme you want to use in your application, with the rate that the *waveform data* is presented into/out-of your Gnu Radio flow-graph. The packetization is generally not an issue, unless you are running at the edge where the host computer can't keep up, which produces overruns on receive, and under-runs on transmit. But for modest-bandwidth signals, with a decent CPU, this doesn't happen very often. The GiGe interface is simply a convenient and relatively-cheap way of getting complex-baseband data into/out-of the FPGA (along with the occasional programming instructions for the PLL synthesizers, gain controls, etc, on the daughter-cards). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 and external RF tuner
The BasicRX has no amplification. Its full scale amplitude is +10dBm. The ADC in the USRP2 has a rated SFDR of 88dBFS. That means you may see spurs at levels high as -78dBm equivalent when using a BasicRX. In the plots you sent me, your signal is -50 dBm and the spur is more than 40 dB lower, putting it at better than -90dBm, or more than 12dB better than the spec. That is what you need to expect from a real-world ADC. Normally, if you want to look at a -60dBm signal, you will amplify it a lot before you put it into the ADC. That will make it much stronger than the spurs. This is why boards like the RFX, DBSRX, and WBX all have amplifiers. I suggest amplifying your signal by at least 30dB. Matt On 09/01/2010 06:10 AM, Luca Pascale wrote: Hi all, I am working with a usrp2+BasicRx and an external tuner with a 21.4 MHz IF output and a bandwidth of about 20 MHz. The same setup but with usrp1 (instead of usrp2) it's working well. Now I am injecting a tone at 21.45 MHz (-60 dBm) at the input of the BasicRX and set the usrp2 freq at 21.4MHz (with set_rx_freq() UHD API). The problem is that: a) with sample rate of about 3.125M I have 2 strong spuriouses. The first in the middle of the FFT (FFTDIM/2) and the second one at about the middle of the second half of the FFT b) with a sample rate =3.125 the second spurious disappear but the first at FFTDIM/2 is still present. In both case I can also see the tone at 21.45MHz. To compute the spectrum I use matlab [10*log10(|fftshift(fft(signal*window))|^2)]. Am I doing mistakes or someone have the same problem ? Suggestions ? Thanks in advance Luca ___ 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] Dimension of the y axis using usrp_oscope.py
Hello - It will be completely dependent on your receiver chain. My understanding is that the values you are seeing are the output of the ADC, so you'll need to figure out what the voltages at that point are. Perhaps someone else can be more helpful, but you'll need to do the legwork. What receiver are you using? -William I am using a LFRX board. I know that the usrp's ADC has a resolution of 12bit, but what is the maximum value it can deal with? Unfortunately, I haven't found any information on this issue yet. Looking forward to further pieces of advice. Cheers, Fabian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 FPGA Compiling
Works fine for everyone else, but we are using ISE 12.1. It shouldn't be different, though. The most likely problem is programming the SD card incorrectly. Matt On 09/02/2010 11:59 AM, SteveChrepta wrote: I downloaded the ise12 branch of the fpga code. Compiled it using the makefile, and ISE12.2 gui tool. Both did not work in the usrp2, giving the same results...what a shame. SteveChrepta wrote: I am preparing to make small changes to the fpga code. First I wanted to compile the latest fpga code and verify its operation. I downloaded (git) the latest fpga code. I have ISE 12.2 running on a WINXP_Pro SP2 PC. I modified the makefiles to work with the latest cygwin. Actually I invoke make proj to create the ISE project, and then use the ISE tool in Windows to perform the compile. I set the Design Goal to Timng Performance and the fpga build completes successfully with no errors and all timing constraints met! I generate the programming file, u2_rev3.bin, and put it on the SD card. The problem is that the LEDs on the USRP2 do not behave correctly. After power-on, the F-LED lights, and that's all. This says that the fpga is configured, but the follow-on all-LED blink and D-LED did not happen. The ISE 12.2 that I am using is a full version that I downloaded, and I have a 30-day free trial license. All indications of the ISE tool seem to be ok for a successful fpga build. The .bin file size is the same as the original. As I stated before, there were no build errors, but many Warnings, related to port size mismatch, registers with IOB=TRUE, that are not associated with IOBs, unused module inputs, RAM_Dn inputs never assigned. Actually, in the USRP2 schematic, PIN V15 is reset_fpga and in the u2_rev3.ucf file, PIN V15 is PHY_CLK. So there is a discrepency. I will check the other pins. Any help is appreciated. Also if anyone can email to me their successful build warning report(s), this can help. I'm sorry for the long posting. Thank you, Steve. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, I think I should explain my project better. We are developing a physical layer protocol for an asynchronous packet based transceiver all in Verilog. The design has been simulated so far using ModelSim. The target of the project is the VLSI fabrication of this design. Thus all the signal processing (digital modulation (for now we are interested in BPSK digital modulation), packetization, spreading, filtering ) has to be done in FPGA, and it should be as stand alone as possible. The reason we picked USRP2 was that it was a compact board with RF specification quite close to our requirements. Our understanding was that we can get one computer (host) to transmit stream of bits to the USRP2, do the processing in FPGA and send the data over air, and the second USRP2 would capture the signal and again FPGA would do the processing and eventually pass the data (through Ethernet) to the second host (computer). I thought, if I generate a stream of bits in the first host (TX) and do BPSK modulation and pass them to the USRP2 using Gnuradio, the two 16 bit I and Q port that I get at the DSP core of the FPGA are two bytes of that stream of bits and now I can continue with packetization and the rest of my processing inside FPGA (basically replacing the interpolation module with my spreading module) and redo that process at the receiver to retrieve the generated bit stream. I have already read through the DSP codes inside the FPGA. What I understand from your email below was that I can't retrieve the bit stream (generated at the host) in the FPGA and the 16 bits I and Q are modulated, shaped sample representation of the bit stream. This is a bit confusing for me because I thought (assuming the host just generates the bits and does the BPSK modulation) the Ethernet decoder (DP83865) of the USRP2 is basically compensating (undo-ing) the processing that was performed on the bits (by Ethernet encoder) right before they leave the host (computer) so that the Ethernet becomes transparent. If that is not the case, my only solution is to pass the bit stream to the FPGA using the debug port! Would you please let me know which part of my assumption is wrong? Thanks, Malihe Nick Foster wrote: Malihe, Date: Thu, 2 Sep 2010 14:19:54 -0600 From: ahmad...@ualberta.ca Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. Assuming your spreading doesn't bring your bandwidth over around 25MHz, you should be able to do the spreading operation on the host and transmit the spread baseband data to the USRP2 via Gnuradio. The host typically does not send unmodulated data to the USRP2; the host side, usually using Gnuradio, performs the desired DSP operations on your raw information such as spreading, shaping, and modulating, and sends the resulting complex waveform to the USRP2 as raw 16-bit samples. The USRP2 itself knows nothing about your original unmodulated data. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . The data you are receiving at the FPGA is whatever you send to it -- the interpolation rate you pick determines the sample rate the USRP2 will run at. The interpolator will handle upsampling the raw samples to match the data rate the DACs run at. It's up to you (using Gnuradio) to encode your data into an appropriate waveform for your application. Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Whatever raw samples you send into gnuradio get sent to the FPGA (I'm simplifying here: see the link below for details). The USRP2 itself does not know or care that you are using DBPSK or that you are sending '011'. It sounds like you might have a misconception of exactly what the USRP2 is doing. This FAQ is for the USRP1, but the overall description applies also to the USRP2: http://gnuradio.org/redmine/wiki/gnuradio/UsrpFAQ Also, do you have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? A simple GRC flowgraph would perform this function for you. You can use a signal source to feed a USRP2 sink, and then a USRP2 source to feed an FFT sink (or whatever sink you like). The parameters for these blocks depend on what daughterboards you are using for TX and RX and whether you are using the UHD driver or
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
On 09/02/2010 05:11 PM, Malihe Ahmadi wrote: Hi MArcus, Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, can I get those occasional programming instructions you mentioned to be hard-coded (for example changing the firmware so that it uses some default values instead of passing those values through GiGe) if I am interested in removing Ethernet and using debug bus to pass stream of data to the FPGA? Thanks, Malihe Marcus D. Leech wrote: Well, I'm not an expert in the way the FPGA works internally, nor on the signals going into or out of if, but the GMII_RXD pin is likely the RXD pin from the 1GiG Ethernet Phy. Your DBPSK modulated bits stream is represented as a discrete-sampled time-series, those (complex) samples are presented to the Ethernet interface, sent over the Ethernet to the FPGA, where those samples are possibly interpolated by the FPGA up to the sample rate of the A/D (200MHz), from the output side of the A/D the signal is a complex analog baseband representation of the signal, which is then typically upconverted to the final target frequency. The normal way that discrete-sampled time series gets to appear at the FPGA is that the resulting waveform is created by a Gnu Radio flow graph that includes the proper modulation stuff to take a series of bits (like your 011) and turn it into a complex baseband waveform. Now, you want to avoid the SDR aspects altogether, and do everything inside the FPGA. So you want to use the USRP2 essentially as your wireless PHY, and totally ignore the SDR aspects of the USRP2 design. You want to know if there are pins available on the FPGA to allow it to take your bits (and related clocks), and have the FPGA do the necessary modulation and spreading, in a standalone manner. I think Eric Blossom already mentioned the MICTOR interface, which may do what you want. Assuming that the MICTOR or some other interface on the FPGA will do what you want, and there's enough room inside the FPGA, then I don't see that you'll have a problem. You can certainly hard-code whatever daughter-card setup you need inside the firmware. You'll find that if you want detailed help making this work, you'll have a hard time finding anyone who'll give you that help for free. The FPGA and aeMB firmware is freely available, and you'll likely get some hints and tips from time to time. But what you're contemplating is a fairly major project that is, to a first approximation, outside of the strict confines of Gnu Radio. -- 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
RE: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Malihe, Your understanding is basically correct. I misunderstood your request -- I didn't realize you had an existing FPGA design you were integrating with the USRP2, and figured you were going about things the hard way. Nothing happens to Ethernet packets between the host transmission and GMII_TX -- the USRP2 MAC receives the same data that goes out the host MAC. I was trying to say that modulation is typically done in Gnuradio, not in the FPGA, and so data on the wire is typically baseband modulated and not a data bitstream. If you are implementing the modulation in FPGA you are of course free to define the data on the wire however you like. For your purposes you should be able to take your data straight from the MAC and buffer and encode it in whatever way you see fit. Nick Date: Thu, 2 Sep 2010 18:30:22 -0600 From: ahmad...@ualberta.ca To: bistro...@hotmail.com CC: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi Nick, I think I should explain my project better. We are developing a physical layer protocol for an asynchronous packet based transceiver all in Verilog. The design has been simulated so far using ModelSim. The target of the project is the VLSI fabrication of this design. Thus all the signal processing (digital modulation (for now we are interested in BPSK digital modulation), packetization, spreading, filtering ) has to be done in FPGA, and it should be as stand alone as possible. The reason we picked USRP2 was that it was a compact board with RF specification quite close to our requirements. Our understanding was that we can get one computer (host) to transmit stream of bits to the USRP2, do the processing in FPGA and send the data over air, and the second USRP2 would capture the signal and again FPGA would do the processing and eventually pass the data (through Ethernet) to the second host (computer). I thought, if I generate a stream of bits in the first host (TX) and do BPSK modulation and pass them to the USRP2 using Gnuradio, the two 16 bit I and Q port that I get at the DSP core of the FPGA are two bytes of that stream of bits and now I can continue with packetization and the rest of my processing inside FPGA (basically replacing the interpolation module with my spreading module) and redo that process at the receiver to retrieve the generated bit stream. I have already read through the DSP codes inside the FPGA. What I understand from your email below was that I can't retrieve the bit stream (generated at the host) in the FPGA and the 16 bits I and Q are modulated, shaped sample representation of the bit stream. This is a bit confusing for me because I thought (assuming the host just generates the bits and does the BPSK modulation) the Ethernet decoder (DP83865) of the USRP2 is basically compensating (undo-ing) the processing that was performed on the bits (by Ethernet encoder) right before they leave the host (computer) so that the Ethernet becomes transparent. If that is not the case, my only solution is to pass the bit stream to the FPGA using the debug port! Would you please let me know which part of my assumption is wrong? Thanks, Malihe Nick Foster wrote: Malihe, Date: Thu, 2 Sep 2010 14:19:54 -0600 From: ahmad...@ualberta.ca Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. Assuming your spreading doesn't bring your bandwidth over around 25MHz, you should be able to do the spreading operation on the host and transmit the spread baseband data to the USRP2 via Gnuradio. The host typically does not send unmodulated data to the USRP2; the host side, usually using Gnuradio, performs the desired DSP operations on your raw information such as spreading, shaping, and modulating, and sends the resulting complex waveform to the USRP2 as raw 16-bit samples. The USRP2 itself knows nothing about your original unmodulated data. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . The data you are receiving at the FPGA is whatever you send to it -- the interpolation rate you pick determines the sample rate the USRP2 will run at. The interpolator will handle upsampling the raw samples to match the data rate the DACs run at. It's up to you (using Gnuradio) to encode your data into an appropriate waveform for your application. Assuming I want to use Ethernet, let's say I want to send the stream '011', and I
Re: [Discuss-gnuradio] More test bench stuff with usrp_std
First mistake: the 2rx 0tx doesn't actually work (or I'm too stupid to make it
work :) I'm using the default 2rx 2tx config, and the usrp_std module is now
responding to input, although it's not showing me what I want yet.
Has anyone else had experience writing test benches for the full chip?
Nelson.
- Original Message
From: Nelson Costa ncosta1...@yahoo.ca
To: gnu radio discussion discuss-gnuradio@gnu.org
Sent: Thu, September 2, 2010 8:14:16 AM
Subject: [Discuss-gnuradio] More test bench stuff with usrp_std
Hi all,
I'm trying to modify the test bench provided with the standard USRP verilog
code
to work with the latest version of the usrp_std module. I'm using the 2rx
0tx
config.
My problem is that I don't think I'm initializing the usrp_std module
properly;
I'm not sure of the order of events that should happen to start getting data
out
of the module. I can never get it to assert the usbrdy[1] signal, and thus
it
never has data ready . Here are the highlights of what I do:
I create a usb, adc, and master clock: (default time unit is ns)
always #16 clk_120mhz = ~clk_120mhz; //1/16ns = 62.5MHz (?)
always #60 usbclk = ~usbclk; //1/60ns = 16.67MHz (what does FX2 give us?)
always #16 adclk = ~adclk; // 1/16ns = 62.5MHz
I start generating adc data
always @(posedge adclk) adc1_data = #1 adc1_data + 1;
always @(posedge adclk) adc2_data = #1 adc2_data + 1;
I (think) I reset the rx and (presumably non-existent) tx chains:
#1000
send_config_word(`FR_MASTER_CTRL,32'hc); //TX, RX reset
I then set up what I think are the pertinent registers to get the rx chains
going:
#1000
send_config_word(`FR_MASTER_CTRL, 32'h2); //RX enable
send_config_word(`FR_RX_SAMPLE_RATE_DIV, 32'h2);// 128e6/64e6 = 2
divisor
(closest!)
send_config_word(`FR_DECIM_RATE, 32'h1); //decimation rate = 1
send_config_word(`FR_RX_FREQ_0, 32'h0); //ddc center freq, rx0 = 0
send_config_word(`FR_RX_FREQ_1, 32'h0); //ddc center freq, rx1 = 0
send_config_word(`FR_RX_PHASE_0, 32'h0); //ddc phase acc word
send_config_word(`FR_RX_PHASE_1, 32'h0); //ddc phase acc word
send_config_word(`FR_RX_MUX, {12'h0, 2'h3, 2'h3, 2'h2, 2'h2, 2'h1, 2'h1,
2'h0,
2'h0, 1'b1, 3'h0});
//rx mux set so that DDCn gets ADCn, complex samples
ignored
send_config_word(`FR_RX_FORMAT, {21'h0, 1'b0, 1'b1, 5'hf, 4'h0}); //set rx
data
format control register: 16 bits, want Q
I can see in ModelSim that the serial data is banged in properly. However, I
get no joy. The usrp_std module simply never spits anything out. The
burst_usb_read() task included with the test bench code waits for usbrdy[1]
to
be asserted, but it never does. I've already tried to set the OE and RD
inputs
to see what happens, but nothing does.
Any input would be greatly appreciated.
Nelson.
___
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
