[Discuss-gnuradio] Changing external reference frequency with USRP2...
Hi I have read on the FAQ that is possible to change the external reference frequency for the USRP2 from 10 MHz to another value simply by changing one line in the firmware. However, I have as yet been unable to locate the actual source file in which I need to make this change, and what the name of this variable is. Could someone please let me know? Many Thanks Ian. This message is intended only for the use of the intended recipient(s) If you are not an intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error please destroy all copies of this message and its attachments and notify the sender immediately ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Inband firmware questions
Hi, It's entirely possible for that version to have a syntax error. There was a bad array declaration that an older Quartus would accept and a newer one rejected. The newer one was more correct. :-/ I managed to fix it (well, I think I did at least :) But the generated code, altough meeting fmax constraint, has some setup/hold violation. Looking at the path, it seems there are latches (and not register) and combinatorial signal being used as clocks ... which is frightening for FPGA code. I'm not going to have the time this week, but I'll see if I can get the most recent version (very few changes) available via git somewhere. That'd be great. Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux
On 13 August 2010 01:02, Elvis Dowson elvis.dow...@mac.com wrote: Hi, Another data point, if I set the audio sink sample rate to 16kHz, there are no under-runs, but that obviously will cause the sound to play back at a lower pitch, but atleast there are no crackles and distortions. In the console output window, there are no audio underruns. When you set the audio sink sample rate to any value higher than 16kHz, it starts to distort and crackle. What can be inferred from all this? Maybe it is a driver issue. I suppose your iMac is the latest generation (late 2009?) but the distributed alsa drivers are usually older. You can check how the hardware is detected in the hardware tab of the audio settings or lspci | grep Audio and see how it fits with what's actually in the computer. You can also try to install linux-backports-modules-alsa and see if that provides better driver. ALex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about GRC scope sink
Hi, I hve just a little question about GRC scope sink please the question is I just generate the signal about 1.5Mhz amd Amplitude 1v p-p directly trough the usrp So i know that when i connect the usrp source to the scope sink i will see the signal that it's frequency is the difference of the input frequency - nco frequency but what is the Y axis that call counts measured for but i know that my input is = 1vp-p but in the scope sink show about 3k(counts?) p-p what is that? thank you very much for yours advice wipat ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux
Hi Alex, On Aug 13, 2010, at 12:39 PM, Alexandru Csete wrote: Maybe it is a driver issue. I suppose your iMac is the latest generation (late 2009?) but the distributed alsa drivers are usually older. Yes, my iMac 27 is a late 2009 model. $ sudo dmidecode -s system-product-name iMac11,1 You can check how the hardware is detected in the hardware tab of the audio settings or lspci | grep Audio and see how it fits with what's actually in the computer. The following commands show the various hardware and codec installed on the iMac. I'm running it natively on the iMac 27 at the moment. Install required packages to enable audio. $ sudo apt-get install linux-backports-modules-alsa-lucid-generic gnome-alsamixer Find the Sound card model cat /proc/asound/card0/codec#0 | grep Codec Codec: Cirrus Logic CS4206 List all the audio PCI devices connected to the system $ sudo lspci | grep Audio 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06) 01:00.1 Audio device: ATI Technologies Inc HD48x0 audio Modify the alsa-base.conf file. $ sudo gedit /etc/modprobe.d/alsa-base.conf options snd-hda-intel power_save=10 power_save_controller=N model=imac27 For the Cirrus Logic CS4206/4207 chipset, the snd-hda-intel driver options parameter for the model is imac27 Do you think the two are matched? Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux
On Fri, Aug 13, 2010 at 03:47:12AM +0400, Elvis Dowson wrote: Hi Eric, I came across an old thread, http://www.ruby-forum.com/topic/107228 There is a general issue related to the fact that when using usrp_wfm_rcv and similar applications that there are in fact two clock domains, and that they are guaranteed not to match. There's an osc on the USRP and an osc associated with the sound card. We made an API change in the audio interfaces that can specify that it's NOT OK to block when accessing the audio interface. When used in a flow graph that contained both an audio sink or source and a USRP sink or source, this would result in the USRP being the master clock, and would dodge the two clocks problem. Although the parameter was added to all (most) audio interfaces, I believe that it currently only works on the portaudio interface. Please feel free to fix this for gr-audio-alsa, gr-audio-oss and gr-audio-osx. This could potentially explain the issue I have, with distorted and crackling audio. It might also explain the nearly un-reproduceable random behaviour when it sometimes works giving clear audio output (so far has happened only 4 times in 6 weeks, approx 16 hours a day). How would one go about fixing this for gr-audio-alsa? Perhaps if you can give me some high level tips and pointers, I could try to make the changes. Thanks for being willing to take a look at this! First off, you'd need to read the docs on ALSA and understand the interfaces that are available to work with. I think that fixing it in audio_alsa_sink should be enough. Once the sink is working you could go after the source if you like. Given the interfaces exported by ALSA, you'd need to figure out how to honor the condition ok_to_block == False. There are two cases. (1) audio clock is slower than usrp clock (2) audio clock is faster than usrp clock In (1) you'll want to avoid an ever growing queue of samples by somehow giving the driver samples when it wants them, but dropping the excess samples (hopefull in a way that nobody notices) every now and then. In (2) you'll need to insert an extra sample every now and then to keep the audio from underruning. It's been a long while since I looked at the ALSA docs, but there may be some kind of callback that you can arrange for the ALSA code to call when it needs (or provides) samples. Right now we just naively block when reading or writing. You may want to look at audio_portaudio_sink. It's got at least partial support for this feature, although the interface to the driver will be different than ALSA. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Inband firmware questions
I managed to fix it (well, I think I did at least :) But the generated code, altough meeting fmax constraint, has some setup/hold violation. Looking at the path, it seems there are latches (and not register) and combinatorial signal being used as clocks ... which is frightening for FPGA code. I'm not going to have the time this week, but I'll see if I can get the most recent version (very few changes) available via git somewhere. That'd be great. Hi Sylvain, Myself and another student were the main contributors of the inband code, with much help from Eric, Matt, and Brian. We did a lot of testing of the code, but the only main bug we had found was that the timestamp on the RX side would occasionally jump. This was something that I could never figure out (I'm not much of an FPGA coder), that Eric S. finally chimed in and seemed to have fixed. We used the code for various TDMA and CSMA MAC protocols and it seemed stable. The main thing, IMO, keeping it out of the main codebase was that the inband code relied on a bunch of GNU Radio primitives that were eventually deprecated. The FPGA code itself though, is independent of this. It would be great to get Eric S's code merged in to git somewhere which fixes the timestamp jump and then move the code in to a mainstream location. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux
Hi Eric, Before I dive into it, I just have a quick question. Why is it that others are not encountering the same issue? The same example code was run on a Mac Pro dual quad machine belonging to another member of this forum, and he didn't face the issue of crackling and distorted audio with the audio sink. Anyway, I guess from a logical stand-point if the wave file sink writes to the file correctly, then the data is coming in correctly, and its only the real-time rendering of the audio using the alsa audio sink that's not working correctly. Still, I wonder what the difference could be, it working consistently for others, but not for me. Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux
I guess, its perhaps an older version of GNU Radio, the one before the audio API changed. Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tunnel.py hanging after some time
Hi, I am having trouble with the tunnel.py in the digital foler appear to stop working after a while when using lower bitrates (around 0.5 MB/s) . When I first set up the newtork I am able to ping other nodes with no problem. After some time (sometimes less than half an hour) the pings are no longer sucessful. I checked and the gr interface remains up and correctly configured with the ip address. When I ping out any host I can see the transmission on a spectrum analyzer so I know the transmit path is still functioning. Higher bit rates seem to work for much longer periods of time. Has anyone else had similar issues with these bit rates? If so has anyone figured out the cause of the lost connectivity? I am using USRP2s with WBX cards and using 400 MHz carrier frequency. No other application traffic is being sent over the network. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ADC calibration
On Tue, 10 Aug 2010, Matt Ettus wrote: When using a BasicRX or LFRX with the PGA set at 0dB gain (USRP1 only), +10dBm is full scale on the ADC. On the USRP2 full scale on the ADC is full scale when it gets back into gnu radio. On the USRP1 full scale on the ADC is (1.67/2) times full scale due to the gain of the CORDIC. +10dBm = 2Vpp = 1 Vpeak = 0.7 Vrms With other daughterboards you will need to calibrate at the frequency of interest. Thanks, that's helpful. However, I can't quite make the math work: P = V^2/R ; 0.01 W = (1 V)^2/R ; R = 100 Ohms. But we're using SMA connectors which are 50 Ohms right? Or should I be putting 1 Vpeak I *and* 1 Vpeak Q and getting the 100 Ohms from the combination of the two 50 Ohm connectors? Thanks, Dan (forgot to reply all first, sorry for the double-msg Matt) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ADC calibration
On Fri, Aug 13, 2010 at 3:17 PM, Daniel Halperin dhalp...@cs.washington.edu wrote: On Tue, 10 Aug 2010, Matt Ettus wrote: When using a BasicRX or LFRX with the PGA set at 0dB gain (USRP1 only), +10dBm is full scale on the ADC. On the USRP2 full scale on the ADC is full scale when it gets back into gnu radio. On the USRP1 full scale on the ADC is (1.67/2) times full scale due to the gain of the CORDIC. +10dBm = 2Vpp = 1 Vpeak = 0.7 Vrms With other daughterboards you will need to calibrate at the frequency of interest. Thanks, that's helpful. However, I can't quite make the math work: P = V^2/R ; 0.01 W = (1 V)^2/R ; R = 100 Ohms. But we're using SMA connectors which are 50 Ohms right? Or should I be putting 1 Vpeak I *and* 1 Vpeak Q and getting the 100 Ohms from the combination of the two 50 Ohm connectors? This may be helpful: http://en.wikipedia.org/wiki/Alternating_current#Mathematics_of_AC_voltages Note the usage of Vrms for power calculations and not Vpeak. Thanks, Dan (forgot to reply all first, sorry for the double-msg Matt) Good luck. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Octave/MATLAB code for USRP2 DDC ?
Does anyone happen to have Octave or MATLAB code that models the USRP2's DDC (CIC and HBFs)? -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ADC calibration
On 08/13/2010 12:14 PM, Daniel Halperin wrote: On Tue, 10 Aug 2010, Matt Ettus wrote: When using a BasicRX or LFRX with the PGA set at 0dB gain (USRP1 only), +10dBm is full scale on the ADC. On the USRP2 full scale on the ADC is full scale when it gets back into gnu radio. On the USRP1 full scale on the ADC is (1.67/2) times full scale due to the gain of the CORDIC. +10dBm = 2Vpp = 1 Vpeak = 0.7 Vrms With other daughterboards you will need to calibrate at the frequency of interest. Thanks, that's helpful. However, I can't quite make the math work: P = V^2/R ; 0.01 W = 1^2 / R ; R = 100 Ohms. RMS power = Vpeak^2 / (2*R) RMS power = Vrms^2 / R Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py hanging after some time
Hi Dave, Not sure whether we had the same issue. We modified the original tunnel.py to a multichannel based tunnel. We were able to connect multiple nodes (USRP2+WBX) initially after running tunnel.py. We could ping every nodes. After a while, some nodes started to fail. If we restarted the failing nodes, ping went through again. We were operating with 3 channels and 100kbps each on 400MHz. Does anyone have a clue what is going on? An On Fri, Aug 13, 2010 at 3:00 PM, David Barton david.barto...@yahoo.comwrote: Hi, I am having trouble with the tunnel.py in the digital foler appear to stop working after a while when using lower bitrates (around 0.5 MB/s) . When I first set up the newtork I am able to ping other nodes with no problem. After some time (sometimes less than half an hour) the pings are no longer sucessful. I checked and the gr interface remains up and correctly configured with the ip address. When I ping out any host I can see the transmission on a spectrum analyzer so I know the transmit path is still functioning. Higher bit rates seem to work for much longer periods of time. Has anyone else had similar issues with these bit rates? If so has anyone figured out the cause of the lost connectivity? I am using USRP2s with WBX cards and using 400 MHz carrier frequency. No other application traffic is being sent over the network. Thanks, Dave ___ 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] ADC calibration
On Fri, 13 Aug 2010, Matt Ettus wrote: On 08/13/2010 12:14 PM, Daniel Halperin wrote: On Tue, 10 Aug 2010, Matt Ettus wrote: When using a BasicRX or LFRX with the PGA set at 0dB gain (USRP1 only), +10dBm is full scale on the ADC. On the USRP2 full scale on the ADC is full scale when it gets back into gnu radio. On the USRP1 full scale on the ADC is (1.67/2) times full scale due to the gain of the CORDIC. +10dBm = 2Vpp = 1 Vpeak = 0.7 Vrms With other daughterboards you will need to calibrate at the frequency of interest. Thanks, that's helpful. However, I can't quite make the math work: P = V^2/R ; 0.01 W = 1^2 / R ; R = 100 Ohms. RMS power = Vpeak^2 / (2*R) RMS power = Vrms^2 / R ... so as long as I don't send a pure DC signal (which presumably I can't b/c there will be filters so the device doesn't support it anyway) I should be using RMS power to account for the carrier wave variation? Makes sense. Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem on write fpga reg
Hi all, I'm working on a synchronization block to allow the transmitter and receiver to co-locate on the same motherboard and work alternatively, transmitter working for 0.5 second then receiver working for 0.5 second, and then repeat this process. I'm using USRP1 and LFTX/RX to develop my transmitter and receiver, which work well when transmitter and receiver are plugged on two USRP1 mother board. I'm trying to write fpga register FR_MASTER_CTRL to enable transmitter board or receiver board every 0.5 second, in order to implement tx and rx working alternatively. The functions defined for enabling tx and rx is shown as followed. def write_mode(self): self._u._write_fpga_reg(FR_MASTER_CTRL, self.mode) def enable_tx(self, value): if value: if self.verbose: print Enabling transmitter. self.mode |=bmFR_MC_ENABLE_TX self.transmitting = True else: if self.verbose: print Disabling transmitter. self.mode =~bmFR_MC_ENABLE_TX self.write_mode() def enalbe_rx(self, value): if value: self.mode |=bmFR_MC_ENABLE_RX self.write_mode() self.rcvr.start() self.receiving = True else: self.rcvr.stop() self.mode =~bmFR_MC_ENABLE_RX self.write_mode() self.receiving = False def start(self): if self.tx: self.enable_tx(True) if self.rx: self.enable_rx(True) However, i got an AttributeError File /home/john/gnuradio/gr-iono/usrp_ionsonde_control.py, line 197, in set_reset self.write_mode() File /home/john/gnuradio/gr-iono/usrp_ionsonde_control.py, line 166, in write_mode self._u._write_fpga_reg(FR_MASTER_CTRL, self.mode) File /usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py, line 50, in __getattr__ return getattr(self._hb, name) AttributeError: 'gr_hier_block2_sptr' object has no attribute '_write_fpga_reg' What's the problem may be? Could this fpga reg be written every half second or even 20 microseconds? Thank you so much for help. Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Continual output of 'S'
When I run the FFT routine (usrp2_fft.grc) there are two apparent anomalies that I do not understand. TIA to anyone who can help a poor soul out with what are most likely simple things: 1) When I execute, there are error messages and no window appears. The routine works fine, per the caveat of #2 below, if I 'Build' and the just run with Python from the command line. 2) When I run usrp2_fft.py, the windows appear and the program runs fine, but it continually outputs an 'S' to the terminal. I looked for an output somewhere for stdio or stdout, but found nothing. Is this perhaps an old bug, or a Ubuntu thing? Is it something that needs to be edited in the Python file or with a switch? Harley Myler CONFIDENTIALITY: Any information contained in this e-mail (including attachments) is the property of The State of Texas and unauthorized disclosure or use is prohibited. Sending, receiving or forwarding of confidential, proprietary and privileged information is prohibited under Lamar Policy. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Continual output of 'S'
Hi Harley, On Aug 14, 2010, at 1:18 AM, HR Myler wrote: 2) When I run usrp2_fft.py, the windows appear and the program runs fine, but it continually outputs an 'S' to the terminal. I looked for an output somewhere for stdio or stdout, but found nothing. Is this perhaps an old bug, or a Ubuntu thing? Is it something that needs to be edited in the Python file or with a switch? Looks like a sample over-run. I got that the last time, due to network contention between Fedora 12 running inside a VM, and the host Mac OS. Switching to Ubuntu helped fix that. Try to re-check your network settings or allocate more CPUs for the VM. Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux
Hi Eric, On Aug 13, 2010, at 8:38 PM, Eric Blossom wrote: Given the interfaces exported by ALSA, you'd need to figure out how to honor the condition ok_to_block == False. Could you please tell me the intent behind the ok_to_block flag? By blocking, do you mean a synchronous call, which will block and render the subsystem un-responsive, until, it completes? In this scenario, should the two subsystems be running asynchronously, with a buffer in between, so that the two can run at different clock rates? e.g. USRP2 running at a particular clock rate, and the alsa_audio_sink running at a different clock rate? Or is the whole GNU Radio flow-graph a synchronous system, i.e. it completes execution and evaluation of the entire flow graph, every clock cycle, reading data from the environment, processing the inputs, and computing the output, for every clock cycle? Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
