[Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
Hi list, I have been trying to send and receive higher order constellations than bpsk (qpsk, qam16, ...). The way I'm currently implementing this (in c++) is that I have a custom pack_k_bits_bb(int bits_per_symbol)- block and then feed the result into a gr_chunks_to_symbols_bc- block, and then onward in the transmitting chain. On the receiving side, I use a constellation_decoder_cb- block followed by a gr_unpack_k_bits_bb- block to get the bits back. This approach assumes that there are less than 8 bits per symbol, and that the input to the transmitting chain is unpacked bytes, which is also produced by the receiver. The question is now, how do you produce constellations with more than 1 bit per symbol? Is there a better way to do this? Sure if one want to, for instance, read from a file/device the input should be packed bytes, but if the input to the transmitting chain is a gr_scrambler_bb- block... This is one way of doing it. Comments and suggestions on how to do this in other ways are most appreciated. BR //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The sinusiodal waveform is drifting from input to output.
Hi, I am transmitting the sinusoidal wave form (IQ samples), in the following methods, and found that when i stem plot in the MATLAB both the input wave form data on one USRP2 and the received data on another USRP2, initially the waveform is exactly fitting (i mean overlapping), and after certain samples, it starts ie., in the input wave form and the output data waveform drifting slightly and at the end samples both the waveforms overlaps perfectly. Why this slight drifting is happening when transmitting the I Q samples from one USRP2 to another USRP2. 1st method: I used, tx_samples.cc and receive_streaming_samples.cc. 2nd method: Using the GRC, created a signal source, and file sink and usrp2 sink on One PC and another PC usrp2 source and file source. So plotting both the input stored samples and output received samples, observed the above mentioned drift of mismatch of samples of the waveform and again at the end and start it perfectly matches or overlaps. Kindly help me in understanding this phenomena, why this is happening on raw data (IQ) samples sending. But this never happens, when i checked with the benchmark_rx.py and benchmark_tx.py used (as internally these two are using GMSK modulation, sync work and packets framing method). best regards, srinivas. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The sinusiodal waveform is drifting from input to output.
srinivas naga vutukuri wrote: Hi, I am transmitting the sinusoidal wave form (IQ samples), in the following methods, and found that when i stem plot in the MATLAB both the input wave form data on one USRP2 and the received data on another USRP2, initially the waveform is exactly fitting (i mean overlapping), and after certain samples, it starts ie., in the input wave form and the output data waveform drifting slightly and at the end samples both the waveforms overlaps perfectly. Why this slight drifting is happening when transmitting the I Q samples from one USRP2 to another USRP2. 1st method: I used, tx_samples.cc and receive_streaming_samples.cc. 2nd method: Using the GRC, created a signal source, and file sink and usrp2 sink on One PC and another PC usrp2 source and file source. So plotting both the input stored samples and output received samples, observed the above mentioned drift of mismatch of samples of the waveform and again at the end and start it perfectly matches or overlaps. Kindly help me in understanding this phenomena, why this is happening on raw data (IQ) samples sending. But this never happens, when i checked with the benchmark_rx.py and benchmark_tx.py used (as internally these two are using GMSK modulation, sync work and packets framing method). Is it possible that this is due to a phase/frequency- drift between the two units? I think benchmark_rx implements a PLL (Costas- loop) for frequency/phase- offsets, and might (don't remember) as well implement a form of early- late- gate loop (Optimized Müller Müller algorithm) for time- synchronizing the samples. I don't know if the phenomena you see is due to this, but it might... BR //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BPSK to QPSK
hi everyone, I am using the programs of DIGITAL-BERT folder to see the bit error rate pattern versus the SNR. The given programs are for BPSK scheme. I tried to change it for QPSK Scheme. But seems that I did not do it right. I am giving the modified code in the programs . Please help me out..Thanking in advance *1) transmit_path.py in /digital-bert/ folder.* self._bits = gr.vector_source_b([1,], True) # Infinite stream of ones self._scrambler = gr.scrambler_bb(0x8A, 0x7F, 7) # CCSDS 7-bit scrambler # Map to constellation self._constellation = [-1-1j,1-1j,-1+1j,1+1j] self._mapper = gr.chunks_to_symbols_bc(self._constellation,2) # Create RRC with specified excess bandwidth taps = gr.firdes.root_raised_cosine(sps*amplitude, # Gain sps,# Sampling rate 1.0,# Symbol rate excess_bw,# Roll-off factor 11*sps) # Number of taps self._rrc = gr.interp_fir_filter_ccf(sps,# Interpolation rate taps)# FIR taps # Wire block inputs and outputs self.connect(self._bits, self._scrambler, self._mapper, self._rrc, self) *2)receive_path. py in /digital-bert/ folder* self._agc = gr.agc_cc(1e-5, 1.0, 1.0, 1.0) # Create RRC with specified excess bandwidth taps = gr.firdes.root_raised_cosine(1.0, # Gain self._sps,# Sampling rate 1.0, # Symbol rate excess_bw,# Roll-off factor 11*self._sps) # Number of taps self._rrc = gr.fir_filter_ccf(1, taps) # Create a Costas loop frequency/phase recovery block print Costas alpha:, costas_alpha print Costas beta:, costas_beta print Costas max:, costas_max self._costas = gr.costas_loop_cc(costas_alpha, # PLL first order gain costas_beta, # PLL second order gain costas_max,# Max frequency offset rad/sample -costas_max, # Min frequency offset rad/sample 4) # QPSK # Create a MM bit synchronization retiming block mm_mu = 0.5 mm_omega = self._sps print MM gain mu:, mm_gain_mu print MM gain omega:, mm_gain_omega print MM omega limit:, mm_omega_limit self._mm = gr.clock_recovery_mm_cc(mm_omega, # Initial samples/symbol mm_gain_omega, # Second order gain mm_mu, # Initial symbol phase mm_gain_mu, # First order gain mm_omega_limit) # Maximum timing offset # Add an SNR probe on the demodulated constellation self._snr_probe = gr.probe_mpsk_snr_c(10.0/symbol_rate) self.connect(self._mm, self._snr_probe) self._c2r = gr.complex_to_real() self._slicer = gr.binary_slicer_fb() self._c2i = gr.complex_to_imag() self._inter = gr.interleave(gr.sizeof_float*1) # Descramble BERT sequence. A channel error will create 3 incorrect bits self._descrambler = gr.descrambler_bb(0x8A, 0x7F, 7) # CCSDS 7-bit descrambler # Measure BER by the density of 0s in the stream self._ber = gr.probe_density_b(1.0/symbol_rate) self.connect(self, self._agc, self._rrc, self._costas, self._mm) self.connect(self._mm,self._c2r) self.connect(self._mm,self._c2i) self.connect(self._c2r,(self._inter,0)) self.connect(self._c2i,(self._inter,1)) self.connect(self._inter,self._slicer,self._descrambler,self._ber) Please help me out. Amarnath ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: The sinusiodal waveform is drifting from input to output.
I mean drift, slight shift in the both the input and output receive waveforms. best regards, srinivas. srinivas naga vutukuri wrote: Hi, I am transmitting the sinusoidal wave form (IQ samples), in the following methods, and found that when i stem plot in the MATLAB both the input wave form data on one USRP2 and the received data on another USRP2, initially the waveform is exactly fitting (i mean overlapping), and after certain samples, it starts ie., in the input wave form and the output data waveform drifting slightly and at the end samples both the waveforms overlaps perfectly. Why this slight drifting is happening when transmitting the I Q samples from one USRP2 to another USRP2. 1st method: I used, tx_samples.cc and receive_streaming_samples.cc. 2nd method: Using the GRC, created a signal source, and file sink and usrp2 sink on One PC and another PC usrp2 source and file source. So plotting both the input stored samples and output received samples, observed the above mentioned drift of mismatch of samples of the waveform and again at the end and start it perfectly matches or overlaps. Kindly help me in understanding this phenomena, why this is happening on raw data (IQ) samples sending. But this never happens, when i checked with the benchmark_rx.py and benchmark_tx.py used (as internally these two are using GMSK modulation, sync work and packets framing method). best regards, srinivas. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem using GRC when executing the grc examples
Hello, I can run some examples like dial_tone.py, audio_fft.py, and others. But when using GRC to open grc examples, I can not execute the grc examples like dial_tone.grc. Then I try to add the following to .bashrc export BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib But I can not do that because .bashrc is read only. Therefore how to solve the problem? Thank you for your help. Makmur This is the error: Loading: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Done Showing: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Generating: /usr/share/gnuradio/examples/grc/simple/ber_sim.py Generate Error: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 313, in handle_states generator.write() File /usr/lib/python2.6/dist-packages/gnuradio/grc/python/Generator.py, line 61, in write open(self.get_file_path(), 'w').write(str(self)) IOError: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Executing: /usr/share/gnuradio/examples/grc/simple/ber_sim.py python: can't open file '/usr/share/gnuradio/examples/grc/simple/ber_sim.py': [Errno 2] No such file or directory Done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK to QPSK
amarnath alapati wrote: hi everyone, I am using the programs of DIGITAL-BERT folder to see the bit error rate pattern versus the SNR. The given programs are for BPSK scheme. I tried to change it for QPSK Scheme. But seems that I did not do it right. I am giving the modified code in the programs . Please help me out..Thanking in advance I think that the Costas- and MM- blocks only work for differential encoding... If anyone knows differently, speak now of forever hold your peace ;p //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
Makmur Hidayat wrote: Then I try to add the following to .bashrc export BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib But I can not do that because .bashrc is read only. Therefore how to solve the problem? $chmod +w .bashrc would make the above file writable. But .bashrc shouldn't really be r/o, should it? This file should be readable by everyone, and read/writable for the owner. At least in my experience. Cheers, //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
2010/3/3 Mattias Kjellsson m...@kth.se $chmod +w .bashrc would make the above file writable. But .bashrc shouldn't really be r/o, should it? This file should be readable by everyone, and read/writable for the owner. At least in my experience. Thanks Mattias, After I did-- $chmod +w .bashrc Then there is an error -- chmod: cannot access '.bashrc': No such file or directory Any way, is it correct what I did changing .bashrc for solving the error when executing the grc examples? Thank you Makmur ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
Makmur Hidayat wrote: 2010/3/3 Mattias Kjellsson m...@kth.se mailto:m...@kth.se $chmod +w .bashrc would make the above file writable. But .bashrc shouldn't really be r/o, should it? This file should be readable by everyone, and read/writable for the owner. At least in my experience. Thanks Mattias, After I did-- $chmod +w .bashrc Then there is an error -- chmod: cannot access '.bashrc': No such file or directory Have you actually checked that you have a file named '.bashrc'? If you do not, its just to create one. Something like: $echo 'export BOOST_PREFIX=/opt/boost_1_37_0' .bashrc $echo 'export LD_LIBRARY_PATH=$BOOST_PREFIX/lib' .bashrc would do the trick i think... Any way, is it correct what I did changing .bashrc for solving the error when executing the grc examples? I don't really know, since I'm not familiar with GRC... Cheers! //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK to QPSK
On 3/3/2010 7:12 AM, Mattias Kjellsson wrote: amarnath alapati wrote: hi everyone, I am using the programs of DIGITAL-BERT folder to see the bit error rate pattern versus the SNR. The given programs are for BPSK scheme. I tried to change it for QPSK Scheme. But seems that I did not do it right. I am giving the modified code in the programs . Please help me out..Thanking in advance I think that the Costas- and MM- blocks only work for differential encoding... If anyone knows differently, speak now of forever hold your peace ;p //Mattias No, the synchronization schemes are not dependent on the type of encoding. They will work for either differential or non-differential. In fact, they are really overkill for differentially encoded modulations Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK to QPSK
Tom Rondeau wrote: On 3/3/2010 7:12 AM, Mattias Kjellsson wrote: amarnath alapati wrote: hi everyone, I am using the programs of DIGITAL-BERT folder to see the bit error rate pattern versus the SNR. The given programs are for BPSK scheme. I tried to change it for QPSK Scheme. But seems that I did not do it right. I am giving the modified code in the programs . Please help me out..Thanking in advance I think that the Costas- and MM- blocks only work for differential encoding... If anyone knows differently, speak now of forever hold your peace ;p //Mattias No, the synchronization schemes are not dependent on the type of encoding. They will work for either differential or non-differential. In fact, they are really overkill for differentially encoded modulations Tom Hum... I'm glad to hear that, although I thought that the pi- phase ambiguity of Costas- loops made them unsuitable for QPSK- constellations... But I guess there is something I'm missing in the code then? Come to think of it. As stated in Practical Costas loop design, J Feigin, one can track the carrier, but there is a chance that the carrier will come out of the loop upside down. Are there blocks that check for this? BR //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK to QPSK
Hum... I'm glad to hear that, although I thought that the pi- phase ambiguity of Costas- loops made them unsuitable for QPSK- constellations... But I guess there is something I'm missing in the code then? You aren't missing anything, you just need to account for the possible rotation. The easy way to do this is with differential decoding, because the instantaneous phase is irrelevant. The harder-but-still-easy was is to transmit some know sequence at the beginning to determine the phase offset and adjust your decoding accordingly. Jason Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
Johnathan, Thank you for your advice.
I have run this command successful. But the usrp2 is still not working
properly. The problem is that only one LED light (F) is on after inserting
the 2Gb SD card (normal SD card produced by sandisk).
There are two previous advices for the same problem given Eric is:
{1} http://old.nabble.com/Write-bin-to-SD-card-td21680697.html#a21720767
((Yabo Li wrote:
Hi Eric,
Thanks very much for answering my questions. I tried a different SD card
(SanDisk), and now only one LED is on (LED F). Do you know what does
this mean?
One LED means that the FPGA was programmed, but not the firmware.
Either you didn't put the firmware on the card, or the card is bad.
Why don't you just use the SD card which came with the USRP? It is
known to work.
Matt)))
Because the SD card sent with USRP2 was bad that this method is not suitable
to me. I also used another SD card by getting the same results and did not
see the error information when I wrote the firmware.
Another solution is that
{2}http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg15300.html
(Remove all daughterboards and cables except the power supply. Does
it do the same thing, or do you get two leds?
I still only get one LED.
Also, if the SD card slot is stiff and/or
sticking, make sure that when you push the card in that it clicks and
slides
back a bit.
Yep, the SD card slot makes the clicking sound when I push the card in and
the card seems to be in there properly.
If that still doesn't work, please call the office so we can
discuss it further.
Will do. Thanks!
I have followed this steps, but still one f LED is on. However, another
USRP2 shows the same results that I think the platform should be ok.
The code I used to write the firmware and FPGA was listed as below. After
each step, I used u2_flash_tool + v to check if it works fine. There is no
any error shown on the terminal.
s...@shi-laptop:~$ cd /home/shi/Desktop/
s...@shi-laptop:~/Desktop$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda5 14318528 3388676 10202512 25% /
tmpfs 995828 0995828 0% /lib/init/rw
varrun 99582892995736 1% /var/run
varlock 995828 0995828 0% /var/lock
udev995828 192995636 1% /dev
tmpfs 995828 460995368 1% /dev/shm
lrm 995828 2392993436 1%
/lib/modules/2.6.28-11-generic/volatile
/dev/mmcblk0p1 1925464 4 1925460 1% /media/disk-1
s...@shi-laptop:~/Desktop$ sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w
txrx.bin -w
[sudo] password for shi:
s...@shi-laptop:~/Desktop$ sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w
txrx.bin -v
s...@shi-laptop:~/Desktop$ sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t fpga
u2_rev3.bin -w
s...@shi-laptop:~/Desktop$ sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t fpga
u2_rev3.bin -v
s...@shi-laptop:~/Desktop$ find_usrps
No USRP2 found.
s...@shi-laptop:~/Desktop$
Another strange thing is that after inserting the SD card into the USRP2, it
can not recognized by Ubuntu 9.04 anymore. Thus every time I have to format
it in windows before I am using u2_flash_tool to rewrite the firmware and
FPGA again. (I have tried to format it as FAT,FAT32,NFTS which makes no
difference. Because I guess the u2_flash_tool will remove the file system
created by windows).
I am wandering if I did anything wrong when I am using the u2_flash_tool to
burn the firmware? Or maybe I have to try to use another brand SD card
rather than Sandisk? Or Do I need to do something more with SD card before
using u2_flash_tool?
Thank you.
Andy
--
View this message in context:
http://old.nabble.com/u2_flash_tool-%3A---Can-not-find-the-command-tp27760919p27770237.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] BPSK to QPSK
On Wed, Mar 3, 2010 at 10:51 AM, Jason Uher jasonu...@gmail.com wrote: Hum... I'm glad to hear that, although I thought that the pi- phase ambiguity of Costas- loops made them unsuitable for QPSK- constellations... But I guess there is something I'm missing in the code then? You aren't missing anything, you just need to account for the possible rotation. The easy way to do this is with differential decoding, because the instantaneous phase is irrelevant. The harder-but-still-easy was is to transmit some know sequence at the beginning to determine the phase offset and adjust your decoding accordingly. Jason Yes, what Jason said. I think of synchronization as making sure the constellation is aligned. The actual bit representations are the next step. Since we put a 64-bit access code on the front of every packet, it should be easy to add logic in the sink to determine what the rotation is, but we haven't done anything about that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
You need to access .bashrc with super user rights. Open a terminal, and type the following commands: cd ~ sudo gedit .bashrc This will prompt for your password, then open .bashrc in an editable mode. A less recommended method of getting around this, would to change the access rights to .basrc with the following commands: cd ~ sudo chmod +w .bashrc -Michael Berman On Wed, Mar 3, 2010 at 4:05 AM, Makmur Hidayat makm...@gmail.com wrote: Hello, I can run some examples like dial_tone.py, audio_fft.py, and others. But when using GRC to open grc examples, I can not execute the grc examples like dial_tone.grc. Then I try to add the following to .bashrc export BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib But I can not do that because .bashrc is read only. Therefore how to solve the problem? Thank you for your help. Makmur This is the error: Loading: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Done Showing: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Generating: /usr/share/gnuradio/examples/grc/simple/ber_sim.py Generate Error: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 313, in handle_states generator.write() File /usr/lib/python2.6/dist-packages/gnuradio/grc/python/Generator.py, line 61, in write open(self.get_file_path(), 'w').write(str(self)) IOError: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Executing: /usr/share/gnuradio/examples/grc/simple/ber_sim.py python: can't open file '/usr/share/gnuradio/examples/grc/simple/ber_sim.py': [Errno 2] No such file or directory Done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- -Michael Berman ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] White space sensing efforts
Hi everyone! I've set up my USRP1 with 2 WBX, a dipole antenna - originally for FM radio - connected to one WBX, and a 450 MHz omni antenna to the other WBX. The connected PC is running Ubuntu 9.10 x86_64, build dependencies for GNU Radio are installed, GNU Radio builds and runs fine. Now what I'd like to do is implement sensing for white space devices[1], entirely in free software, with hardware available from Ettus Research. To my knowledge, this is what has happened so far: * Microsoft presented a prototype to the FCC that was implemented using 802.11 cards in combination with 2.4 GHz - UHF downconversion, and yes, they're using the USRP and GNU Radio. [2] * Philips Research prestented a prototype to the FCC as well. Monisha Ghosh is going to present their most recent results regarding DVB-T sensing at DySpan 2010. Is anybody else already working in this area? The challenges are: * different TV/DTV standards in different regions (NTSC/ATSC in North America, PAL/SECAM/DVB-T in Europe, ...) * wirless microphones also need to be detected (but that can be implemented later...) * sensing has to be reliable even below the noise floor (FCC requires -114 dBm, ETSI WG SE 43 is currently discussing the hidden node margin for Europe...) * we might have to circumvent or challenge patents or patent applications in this area What I can offer: * time for coding bits and pieces needed for detection of incumbent users * samples taken with my hardware * Eventually: remote access to my hardware, but that requires that we've physically met before. I need to trust you not to do something illegal with the WBX... Some constraints I think are necessary for fairness: * all the results are shared, of course with proper credits given * all the results will be published under GPLv3 and copyright assigned to the FSF (or whatever is necessary to include it in GNU Radio trunk) I'd like to collaborate with others instead of re-inventing the wheel ;). So far, we are already some folks over here in Europe who are working on this ... anybody else? Please speak up! 73 Alex HB9/OE9LAJ [1] http://en.wikipedia.org/wiki/White_spaces_%28radio%29 [2] http://research.microsoft.com/apps/pubs/default.aspx?id=80952 (ACM SIGCOMM Best Paper Award) signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
The error says: Generating: /usr/share/gnuradio/examples/grc/simple/ber_sim.py Generate Error: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' GRC generates the python files in the directory that the .grc file is found. Since the examples are installed in a root owned part of the file system /usr/share, you do not have permission to create files there as a regular user. Just open the file in grc and do a save-as in into your user home directory. Then try to run the flow graph. -Josh On 03/03/2010 04:05 AM, Makmur Hidayat wrote: Hello, I can run some examples like dial_tone.py, audio_fft.py, and others. But when using GRC to open grc examples, I can not execute the grc examples like dial_tone.grc. Then I try to add the following to .bashrc export BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib But I can not do that because .bashrc is read only. Therefore how to solve the problem? Thank you for your help. Makmur This is the error: Loading: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Done Showing: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Generating: /usr/share/gnuradio/examples/grc/simple/ber_sim.py Generate Error: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 313, in handle_states generator.write() File /usr/lib/python2.6/dist-packages/gnuradio/grc/python/Generator.py, line 61, in write open(self.get_file_path(), 'w').write(str(self)) IOError: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Executing: /usr/share/gnuradio/examples/grc/simple/ber_sim.py python: can't open file '/usr/share/gnuradio/examples/grc/simple/ber_sim.py': [Errno 2] No such file or directory Done ___ 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] Problem using GRC when executing the grc examples
Makmur, .bashrc is just a convenient way to set environment variables and aliases when you open a terminal. if setting theose environment variables (BOOST_PREFIX and LD_LIBRARY_PATH) before you run grc from the command line fixes your problem, then you would want to add them to your .bashrc file. Your .bashrc should be in your home directory. It should be writable by you. -Tom On Wed, Mar 3, 2010 at 7:05 AM, Makmur Hidayat makm...@gmail.com wrote: Hello, I can run some examples like dial_tone.py, audio_fft.py, and others. But when using GRC to open grc examples, I can not execute the grc examples like dial_tone.grc. Then I try to add the following to .bashrc export BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib But I can not do that because .bashrc is read only. Therefore how to solve the problem? Thank you for your help. Makmur This is the error: Loading: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Done Showing: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Generating: /usr/share/gnuradio/examples/grc/simple/ber_sim.py Generate Error: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 313, in handle_states generator.write() File /usr/lib/python2.6/dist-packages/gnuradio/grc/python/Generator.py, line 61, in write open(self.get_file_path(), 'w').write(str(self)) IOError: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Executing: /usr/share/gnuradio/examples/grc/simple/ber_sim.py python: can't open file '/usr/share/gnuradio/examples/grc/simple/ber_sim.py': [Errno 2] No such file or directory Done ___ 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] rx_timed_samples.cc doesn't stop streaming of samples
Hi All, 1) I've just installed the usrp2_vrt branch and tried running rx_timed_samples.cc. No matter what number of samples i specify in the options, the program just keeps running and printing out the timestamps... Even after i press Ctrl+C the computer still continues to receive data through the ethernet port implying that the u2-stop_rx_streaming doesn't get called. Does anyone know what the problem could be? 2) Could anyone please clarify what nitems means in the following line of the handler in rx_timed_samples.cc: operator()(const uint32_t *items, size_t nitems, const vrt::expanded_header *vrt_header) As far as I can see from the code, d_num_samples gets incremented by nitems every time rx_samples is called and then is comparared whith d_max_samples implying that nitems is the number of samples received. But nitems is always 365,hence d_num_samples gets incremented in step of 365, therefore is it correct that one can receive only a number of samples which is a multiple of 365? Hence what's the point in specifying 1000 as a number of samples to receive? Thanks Valentin -- View this message in context: http://old.nabble.com/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27771324.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] Problem using GRC when executing the grc examples
You need to access .bashrc with super user rights. Shouldn't ~/.bashrc be a user- override of the global /etc/bashrc (in ubuntu /etc/bash.bashrc) ? For instance if I want to change the promt to something like [hh.mm.ss]:usern...@host $ instead of the default one, I'd put those changes in my ~/.bashrc. That was always my assumption, but I might be wrong. Sorry for the off- topic, off- list, off- everything remark/question. //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK to QPSK
Hum... I'm glad to hear that, although I thought that the pi- phase ambiguity of Costas- loops made them unsuitable for QPSK- constellations... But I guess there is something I'm missing in the code then? You aren't missing anything, you just need to account for the possible rotation. The easy way to do this is with differential decoding, because the instantaneous phase is irrelevant. The harder-but-still-easy was is to transmit some know sequence at the beginning to determine the phase offset and adjust your decoding accordingly. Jason Yes, what Jason said. I think of synchronization as making sure the constellation is aligned. The actual bit representations are the next step. Since we put a 64-bit access code on the front of every packet, it should be easy to add logic in the sink to determine what the rotation is, but we haven't done anything about that. Tom Maybe I should have taken a few minutes to think about what was really going on, before I started to write interleaved pilot- symbols in the data- stream, and correcting the data on them at the rx- side then... Anyway I got some more experience thinking in gnuradio c++, and now a new view upon things ;] //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest USRP2 firmware binaries updated
On Tue, Mar 2, 2010 at 23:28, Firas Abbas firasmail2...@yahoo.com wrote: I think USRP2 has a big (1 MByte) external static RAM. Yes, it does. But that's not where the embedded microprocessor instruction store is located. The aeMB reads instructions out of a 32K block ram inside the FPGA itself. It may be possible to use the SRAM as the code store and the block RAM as an I-cache, but that's a fairly significant amount of FPGA design work/modification, and cache-miss performance might be too slow. In any case, about 25% of code in the firmware (txrx.bin) is combined daughterboard management, like tuning control parameter calculation, etc. By breaking these out into individual images, most of that space is freed up for other things. Another option would have been to implement overlays, where the required daughterboard code is loaded into a common place in memory from the SD card after the unit detects which daughterboard is installed. There are other opportunities for improving the code size of the other 75%. It seems the Microblaze gcc port, at least the version we're using, is not that efficient at code generation. Patches always welcome :-) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SBCs with GiGE
Not sure about cheap-ish, but have a look at the Toradex Robin NanoCOM SBC Daisy daughterboard. I have one, very compact, cheapish at under 300 Euros?, and a quick test today with my USRP2, running the usrp rx samples program (the one in host/apps!), I was able to capture complex samples with a decimation of 7 with no overruns (captured into RAM, as I don't have a hard disk and boot from flash). I tried an EeeBox (Z270) initially, and when it did work (very unreliable detection of the USRP2), could only manage the occasional reliable capture with a decimation of 128. Just some thoughts, but I am also very interested in others experiences with USRP2 and compact SBCs. Cheers, Dave Marcus D. Leech wrote: Are there any SBCs (Single Board 'Pooters) out there that are: o compact o cheap-ish o Have 1 GiGE on them for real? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
Just to clarify, this problem with the examples has nothing to do with .bashrc. Nevertheless, it is good to understand the .bashrc when working on a unix system (specifically one with bash). For your installation, just save the .grc file to a writable directory. For the future: I just pushed a branch that will generate the python file in your system's temp directory should the default directory be read-only. -Josh On 03/03/2010 09:39 AM, Tom Gross wrote: Makmur, .bashrc is just a convenient way to set environment variables and aliases when you open a terminal. if setting theose environment variables (BOOST_PREFIX and LD_LIBRARY_PATH) before you run grc from the command line fixes your problem, then you would want to add them to your .bashrc file. Your .bashrc should be in your home directory. It should be writable by you. -Tom On Wed, Mar 3, 2010 at 7:05 AM, Makmur Hidayatmakm...@gmail.com wrote: Hello, I can run some examples like dial_tone.py, audio_fft.py, and others. But when using GRC to open grc examples, I can not execute the grc examples like dial_tone.grc. Then I try to add the following to .bashrc export BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib But I can not do that because .bashrc is read only. Therefore how to solve the problem? Thank you for your help. Makmur This is the error: Loading: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Done Showing: /usr/share/gnuradio/examples/grc/simple/ber_simulation.grc Generating: /usr/share/gnuradio/examples/grc/simple/ber_sim.py Generate Error: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 313, in handle_states generator.write() File /usr/lib/python2.6/dist-packages/gnuradio/grc/python/Generator.py, line 61, in write open(self.get_file_path(), 'w').write(str(self)) IOError: [Errno 13] Permission denied: '/usr/share/gnuradio/examples/grc/simple/ber_sim.py' Executing: /usr/share/gnuradio/examples/grc/simple/ber_sim.py python: can't open file '/usr/share/gnuradio/examples/grc/simple/ber_sim.py': [Errno 2] No such file or directory Done ___ 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] The sinusiodal waveform is drifting from input to output.
On Wed, Mar 3, 2010 at 03:26, srinivas naga vutukuri srinivas.vutuk...@gmail.com wrote: I am transmitting the sinusoidal wave form (IQ samples), in the following methods, and found that when i stem plot in the MATLAB both the input wave form data on one USRP2 and the received data on another USRP2, initially the waveform is exactly fitting (i mean overlapping), and after certain samples, it starts ie., in the input wave form and the output data waveform drifting slightly and at the end samples both the waveforms overlaps perfectly. Why this slight drifting is happening when transmitting the I Q samples from one USRP2 to another USRP2. This is almost certainly due to receiver frequency and timing drift between transmitter and receiver USRPs. It's a fact of life in real-world radio systems, requiring significant design effort to compensate for; you're seeing exactly what you should expect to see. The digital demodulators in GNU Radio typically use DSP blocks like Costas loops for frequency/phase synchronization and MuellerMueller timing recovery blocks to track timing drift. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
On Wed, Mar 3, 2010 at 08:14, Andy_Long luckshiw...@yahoo.com.cn wrote: I have run this command successful. But the usrp2 is still not working properly. The problem is that only one LED light (F) is on after inserting the 2Gb SD card (normal SD card produced by sandisk). This usually means the firmware was not loaded correctly, as Eric mentioned. Another strange thing is that after inserting the SD card into the USRP2, it can not recognized by Ubuntu 9.04 anymore. Thus every time I have to format it in windows before I am using u2_flash_tool to rewrite the firmware and FPGA again. (I have tried to format it as FAT,FAT32,NFTS which makes no difference. Because I guess the u2_flash_tool will remove the file system created by windows). The SD card does not use a filesystem; there is no need to format it. In fact, when you write it with u2_flash_tool, you are overwriting any pre-existing filesystem metadata like partition tables, etc. That is why Ubuntu doesn't recognize it afterwards. When you insert the SD card into a reader, the OS will see a new block device come online, like /dev/sdb or /dev/sdf or some other device name depending on what other block devices you have in the machine. A properly programmed SD card (for the USRP2) will not have a recognized partition table, so your kernel will not try to mount it into the VFS. Also, after programming the card, you must insert it into the USRP2 and power cycle the USRP2 before trying 'find_usrps'. I am wandering if I did anything wrong when I am using the u2_flash_tool to burn the firmware? Or maybe I have to try to use another brand SD card rather than Sandisk? Or Do I need to do something more with SD card before using u2_flash_tool? It's possible you need to use another brand card, as these seem to be notoriously flaky. But your u2_flash_tool commands appeared correct. One thing to try would be to remove the SD card from the reader after the write command, then insert it back in before the verify command. This will ensure you are not simply verifying the firmare/FPGA images against the disk cache. I know you seem to be having a lot of difficulty, but I can assure you that I've programmed SD cards for the USRP2 dozens or hundreds of times with stock and custom images, and what exists does work fine if properly done. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
1) I've just installed the usrp2_vrt branch and tried running rx_timed_samples.cc. No matter what number of samples i specify in the options, the program just keeps running and printing out the timestamps... Even after i press Ctrl+C the computer still continues to receive data through the ethernet port implying that the u2-stop_rx_streaming doesn't get called. Does anyone know what the problem could be? Its possible that your machine is slow enough such that it always has samples in the packet ring and no lag time for the CPU. In this case, the rx_samples call does not get a chance to return and therefore the while loop cannot get a chance to check the done condition. A remedy could be to change line 54: return true; with the following return not done(); This will cause the callback to return false when done, so that rx_samples with exit and the loop condition will be checked. This is due to a false assumption on my part, let me know if that change fixes it for you. 2) Could anyone please clarify what nitems means in the following line of the handler in rx_timed_samples.cc: operator()(const uint32_t *items, size_t nitems, const vrt::expanded_header *vrt_header) Its a callable object. An instance of it gets created and passed into u2-rx_samples(my_handler); As far as I can see from the code, d_num_samples gets incremented by nitems every time rx_samples is called and then is comparared whith d_max_samples implying that nitems is the number of samples received. But nitems is always 365,hence d_num_samples gets incremented in step of 365, therefore is it correct that one can receive only a number of samples which is a multiple of 365? Hence what's the point in specifying 1000 as a number of samples to receive? 1000 is an arbitrary number. If the actual number of items per packet is 365, then it should take 3 receives to have more than 1000 samples, and the program should be done. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK to QPSK
On Wed, Mar 3, 2010 at 03:36, amarnath alapati amarnath.alap...@gmail.com wrote: I am using the programs of DIGITAL-BERT folder to see the bit error rate pattern versus the SNR. The given programs are for BPSK scheme. I tried to change it for QPSK Scheme. But seems that I did not do it right. I am giving the modified code in the programs . Please help me out..Thanking in advance Two major issues: 1) On the receiver, you are not demapping your received constellation into QPSK dibit symbols. The current script simply discards the Q channel and slices the I channel about zero to recover BPSK symbols; you never changed any of that. 2) Even were you to do this, the phase ambiguity of QPSK demodulation means you can end up in one of four states on the receiver, so I and Q can be swapped or inverted. In real communication systems this is either handled with differential coding or known synchronization words that allow the receiver to detect the rotated phase lock. BPSK has this problem as well, though limited to correct or inverted demodulation. The original BPSK-based BERT scripts use a self-synchronizing differential bit scrambler and descrambler that is okay with inverted demodulation. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using GRC when executing the grc examples
On Wed, Mar 3, 2010 at 10:06, Josh Blum j...@joshknows.com wrote: For the future: I just pushed a branch that will generate the python file in your system's temp directory should the default directory be read-only. This has been merged into master. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
On Wed, Mar 03, 2010 at 11:25:56AM +0100, Mattias Kjellsson wrote: Hi list, I have been trying to send and receive higher order constellations than bpsk (qpsk, qam16, ...). The way I'm currently implementing this (in c++) is that I have a custom pack_k_bits_bb(int bits_per_symbol)- block and then feed the result into a gr_chunks_to_symbols_bc- block, and then onward in the transmitting chain. On the receiving side, I use a constellation_decoder_cb- block followed by a gr_unpack_k_bits_bb- block to get the bits back. This approach assumes that there are less than 8 bits per symbol, and that the input to the transmitting chain is unpacked bytes, which is also produced by the receiver. The question is now, how do you produce constellations with more than 1 bit per symbol? Is there a better way to do this? Sure if one want to, for instance, read from a file/device the input should be packed bytes, but if the input to the transmitting chain is a gr_scrambler_bb- block... This is one way of doing it. I assume that you mean 1 byte per symbol. I suggest that you create *_ci and *_ii versions that handle 32-bits. Eric Comments and suggestions on how to do this in other ways are most appreciated. BR //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE : [Discuss-gnuradio] PSK demodulation : g et exact point before deciding what is the closest constel lation point
Thanks Eric ! I have a few questions more. 1- I've successfully retrieved the intermediate values by enabling logging to files. Though, I've no idea about how I could just wire in your own logging stuff wired in by reaching into the hier_block and connecting away, as an alternative way to reach the same results. 2- I am using USRP2 with an RFX2400 daughterboard. Datasheets indicate 17dBm for Transmit power, but I cannot find any information about Receive power. Does anyone know Input power for RFX2400 ? 3- I have only one USRP2 and would like to use a loop-back cable to connect the output to the input of the same USRP. So I would, for example, run benchmark_tx and benchmark_rx in two different shells. Can I do it without any worry ? I am asking the question because it seems that many people always ran a such test with two USRP (one for Tx and the second for Rx) 4- My last question refers to the error message usrp2::tx_raw: FIXME: short packet: 1 items (32 bytes) received when I run benchmark_tx with a modulation other than gmsk. This problem has been the subject of a couple of posts such as this one : http://osdir.com/ml/discuss-gnuradio-gnu/2009-06/msg00284.html . But it seems not to have been solved. Thanks in advance for your help. Chris De: Eric Blossom [mailto:e...@comsec.com] Date: lun. 22/02/2010 13:20 À: Paring, Christophe Cc: discuss-gnuradio@gnu.org Objet : Re: [Discuss-gnuradio] PSK demodulation : get exact point before deciding what is the closest constellation point On Mon, Feb 22, 2010 at 12:03:28PM -0500, christophe.par...@etsmtl.ca wrote: Hi all ! I am dealing with PSK (BPSK, QPSK, 8PSK) modulation/demodulation ; in demodulation, I would want to retrieve the exact point (vector) before finding the closest constellation point. K Is there any way to get it with d?psk.py codes or whatever else ? Thanks in advance for your help. Chris Chris, If you look at the code (gnuradio-core/src/python/gnuradio/blks2impl/dbpsk.py et al.), you'll see that you can enable logging (and get all the intermediate values logged to files) or you could just wire in your own logging stuff wired in by reaching into the hier_block and connecting away. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: SanDisk cards flakey?
Or maybe I have to try to use another brand SD card rather than Sandisk? It's possible you need to use another brand card, as these seem to be notoriously flaky. SanDisk SD cards are not notoriously flaky. They invented the SD Card format and are, I believe, the largest maker of Flash devices in the world. They're the gold standard for SD cards (and their Extreme line is the gold standard for endurance, surviving in cameras destroyed by flying debris, dropped from balloons at tens of thousands of feet, etc). If the USRP2 is notoriously flaky with SanDisk SD cards, there's almost certainly something wrong with the USRP2's implementation of the SD card interface -- not with SanDisk cards. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: SanDisk cards flakey?
On Wed, Mar 3, 2010 at 18:00, John Gilmore g...@toad.com wrote: Or maybe I have to try to use another brand SD card rather than Sandisk? It's possible you need to use another brand card, as these seem to be notoriously flaky. SanDisk SD cards are not notoriously flaky. They invented the SD Card format and are, I believe, the largest maker of Flash devices in the world. They're the gold standard for SD cards (and their Extreme line is the gold standard for endurance, surviving in cameras destroyed by flying debris, dropped from balloons at tens of thousands of feet, etc). You're of course correct--I had missed the SanDisk brand name and my these was referring to SD cards in general I've used with the USRP2. No intent to malign SanDisk. It's possible there is a design issue with the SD interface on the USRP2. I'd consider it pretty unlikely, but not out of the question. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: SanDisk cards flakey?
If the USRP2 is notoriously flaky with SanDisk SD cards, there's almost certainly something wrong with the USRP2's implementation of the SD card interface -- not with SanDisk cards. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I will make an observation that this isn't the only forum where inconsistency in compatibility and performance with SD and SDHC cards has become an issue. The Plug Computer folks (Sheeva Plug, etc) are also running into problems with this card worked, that one didn't type problems. Food for thought. -- 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] Re: SanDisk cards flakey?
On Mar 3, 2010, at 9:10 PM, Marcus D. Leech wrote: If the USRP2 is notoriously flaky with SanDisk SD cards, there's almost certainly something wrong with the USRP2's implementation of the SD card interface -- not with SanDisk cards. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I will make an observation that this isn't the only forum where inconsistency in compatibility and performance with SD and SDHC cards has become an issue. The Plug Computer folks (Sheeva Plug, etc) are also running into problems with this card worked, that one didn't type problems. An interesting view on this issue: http://www.bunniestudios.com/blog/?p=918 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
