Re: [Discuss-gnuradio] [USRP-users] Questions about benchmark_tx/benchmark_rx

2012-06-01 Thread Shen Wenbo
On Fri, Jun 1, 2012 at 1:01 PM, Weixian Zhou idea...@gmail.com wrote:

 I used the benchmark_tx and benchmark_rx to transmit data and I have some
 questions:
 1. I set the frequency of both benchmark_tx and benchmark_rx to 300M, the
 transmission succeed; but it failed when I set the frequency to 2.4G or
 other frequencies. Why is this?


What daughter board u are using, maybe your daughter board doesn't support
2.4GHz,
Target frequency: 300.00 MHz
Actual frequency: 4500.00 MHz
means u daughter board runs on 4.5GHz



 2. Both the benchmark_tx and benchmark_rx gives the warning as I marked
 red: the actual frequency is not same but the transmission succeed. Why is
 it?

Target frequency: 300.00 MHz
Actual frequency: 4500.00 MHz
means u daughter board runs on 4.5GHz, maybe it doesn't support 300MHz


 3. In the receiving end, the pktno is disordered some pktnos are much
 larger than averages. Why is it?


They are  disrupted, so maybe some random numbers

4. What does the n_right=0 means? Does it mean the packet is corrupted in
 the receiving end?

n_right means how many packets are correctly received, which means their
crc check should be true (ok=True)



 *The benchmark_tx messages as following:*
 belltestbed@belltestbed-OptiPlex-790
 :~/Desktop/gnuradio/gr-digital/les/narrowband$ ./benchmark_tx.py -f 300M
 --from-file=pic.jpg
 linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-128-g12f7a5c9

  gr_fir_ccf: using SSE
 -- Opening a USRP2/N-Series device...
 -- Current recv frame size: 1472 bytes
 -- Current send frame size: 1472 bytes

 UHD Warning:
 The recv buffer could not be resized sufficiently.
 Target sock buff size: 5000 bytes.
 Actual sock buff size: 100 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.rmem_max=5000

 UHD Warning:
 The recv buffer could not be resized sufficiently.
 Target sock buff size: 5000 bytes.
 Actual sock buff size: 100 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.rmem_max=5000

 UHD Warning:
 The send buffer could not be resized sufficiently.
 Target sock buff size: 1048576 bytes.
 Actual sock buff size: 100 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.wmem_max=1048576

 UHD Warning:
 Unable to set the thread priority. Performance may be negatively
 affected.
 Please see the general application notes in the manual for
 instructions.
 EnvironmentError: OSError: error in pthread_setschedparam

 No gain specified.
 Setting gain to 17.50 (from [0.00, 35.00])

 UHD Warning:
 The hardware does not support the requested TX frequency:
 Target frequency: 300.00 MHz
 Actual frequency: 4500.00 MHz

 UHD Warning:
 The hardware does not support the requested TX sample rate:
 Target sample rate: 0.05 MSps
 Actual sample rate: 0.195312 MSps

 Symbol Rate: 25000.00
 Requested sps:   2.00
 Given sample rate:   195312.50
 Actual sps for rate: 7.812500

 Requested sample rate: 5.00
 Actual sample rate: 195312.50
 Using Volk machine: avx_32
 Warning: failed to enable realtime scheduling
 .


 *And the benchmark_rx messages as follwing:*
 bell@bell-HP-Compaq-4000-Pro-SFF-PC
 :~/Desktop/USRP/gnuradio/gr-digital/examples/narrowband$./benchmark_rx.py -f 
 300M
 linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.001-129-g23344268

  gr_fir_ccf: using SSE
 -- Opening a USRP2/N-Series device...
 -- Current recv frame size: 1472 bytes
 -- Current send frame size: 1472 bytes

 UHD Warning:
 The recv buffer could not be resized sufficiently.
 Target sock buff size: 5000 bytes.
 Actual sock buff size: 100 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.rmem_max=5000

 UHD Warning:
 The recv buffer could not be resized sufficiently.
 Target sock buff size: 5000 bytes.
 Actual sock buff size: 100 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.rmem_max=5000

 UHD Warning:
 The send buffer could not be resized sufficiently.
 Target sock buff size: 1048576 bytes.
 Actual sock buff size: 100 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.wmem_max=1048576

 UHD Warning:
 Unable to set the thread priority. Performance may be negatively
 affected.
 Please see the general application notes in the manual for
 instructions.
 EnvironmentError: OSError: error in pthread_setschedparam

 No gain specified.
 Setting gain to 49.50 (from [0.00, 99.00])

 UHD Warning:
 The hardware does not 

[Discuss-gnuradio] Restore USRP2 images to support old USRP2 (Not UHD) code

2012-01-30 Thread Shen Wenbo
Hi All,

I have burned the USRP2 to support the UHD, but now I need to run some old
USRP2 code.
The new burned USRP2 images don't support the old code. So, is there any
ways I can restore
USRP2 images to old version to support the old code?

Any help is appreciated, thanks in advance.

-- 
Wenbo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Apply Trellis in benchmark_tx and rx

2011-11-10 Thread Shen Wenbo
Hi,

I  applied trellis in benchmark_tx2 and rx2 using dbpsk2.

I have modified the dbpsk2.py file according to the test_tcm_bit.py.

On the TX side, I add:

# turn bytes into k-bit vectors
self.bytes2chunks = \
  gr.packed_to_unpacked_bb(self.bits_per_symbol(), gr.GR_MSB_FIRST)

#add the error correlation code
fsm =
trellis.fsm(/home/symbol/gnuradio/gr-trellis/src/examples/fsm_files/awgn1o2_128.fsm)
self.trellis_enc = trellis.encoder_bb(fsm, 0);

#gray code
self.symbol_mapper = gr.map_bb(psk.binary_to_gray[arity])

self.diffenc = gr.diff_encoder_bb(arity)
self.chunks2symbols =
gr.chunks_to_symbols_bc(psk.constellation[arity])

# pulse shaping filter
nfilts = 32
ntaps = nfilts * 11 * int(self._samples_per_symbol)# make
nfilts filters of ntaps each
self.rrc_taps = gr.firdes.root_raised_cosine(
nfilts,  # gain
nfilts,  # sampling rate based on 32 filters in
resampler
1.0, # symbol rate
self._excess_bw, # excess bandwidth (roll-off factor)
ntaps)
self.rrc_filter =
gr.pfb_arb_resampler_ccf(self._samples_per_symbol, self.rrc_taps)

# Connect
self.connect(self,
 self.bytes2chunks, self.symbol_mapper,
self.trellis_enc,
 self.diffenc, self.chunks2symbols, self.rrc_filter,
self)

On the RX side:
self.phase_recov = gr.costas_loop_cc(self._phase_alpha,
 self._phase_beta,
 fmax, fmin, arity)

# Do differential decoding based on phase change of symbols
self.diffdec = gr.diff_phasor_cc()

#the error correlation code
fsm =
trellis.fsm(/home/symbol/gnuradio/gr-trellis/src/examples/fsm_files/awgn1o2_128.fsm)
metrics = trellis.metrics_c(fsm.O(), arity,
psk.constellation[arity], trellis.TRELLIS_EUCLIDEAN)
va = trellis.viterbi_b(fsm, 1520, 0, -1)

self.symbol_mapper = gr.map_bb(psk.gray_to_binary[arity])

# unpack the k bit vector into a stream of bits
self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol())

# Connect
self.connect(self, self.agc, self.freq_recov, self.time_recov,
self.phase_recov,
 self.diffdec, metrics, va, self.symbol_mapper,
self.unpack, self)


I can not get any packets on the receiver side. If I remove the trellis
encode and decode block, everything works fine.
There must be some problems with the use of trellis blocks. Could some one
give me any clue?
Any help is appreciated!

Best,
-- 
Wenbo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] error correcting codes block

2011-06-11 Thread Shen Wenbo
OK, thanks Colby

On Sat, Jun 11, 2011 at 11:46 AM, Colby Boyer colby.bo...@gmail.com wrote:

 There is a Viterbi encoder/decoder block called 'trellis' and it handles
 hard and soft decoding. What you need to do is find the generating
 polynomial or convolutional code that matches your needs.

 --Colby

 On Fri, Jun 10, 2011 at 1:27 PM, Shen Wenbo shenwenbosm...@gmail.comwrote:

 Hi All,

 Does GNURadio the error correcting code (ecc) blocks ?
 I have googled, and found  some info
 about directory gr-error-correcting-codes, but this folder is not in
 GNURadio 3.3.
 So, can any block in GNURadio3.3 do error correcting?

 --
 Wenbo


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





-- 
Wenbo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] error correcting codes block

2011-06-10 Thread Shen Wenbo
Hi All,

Does GNURadio the error correcting code (ecc) blocks ?
I have googled, and found  some info
about directory gr-error-correcting-codes, but this folder is not in
GNURadio 3.3.
So, can any block in GNURadio3.3 do error correcting?

-- 
Wenbo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] how to use gr_clock_recovery_mm_cc

2011-06-07 Thread Shen Wenbo
Hi All,

In the gmsk.py, the gr.clock_recovery_mm_ff is used.

I want to use gr.clock_recovery_mm_cc (float omega, float gain_omega, float
mu, float gain_mu) (which implements Mueller and Müller (MM) based clock
recovery block with complex input, complex output) to replace the
gr.clock_recovery_mm_ff

I have done these in two steps:
1. use the same parameters (used to init gr.clock_recovery_mm_ff) to init
gr.clock_recovery_mm_cc.
omege=2.00, gain_omega=0.000625, mu=0.05, gain_mu=0.05,
omega_relative_limit=0.005000

2. move the clock recovery block forward before demod block
self.connect(self, self.clock_recovery,  self.fmdemod, self.slicer, self)

Before modification, if I run the benchmark program using gmsk, receive rate
is almost 100%, but after my modification, receive rate drops to 0%.

Does my method have problem, any help is appreciated!

-- 
Wenbo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio