[Discuss-gnuradio] code for configuring usrp with 2 transmitting and 2 receiving antennas?
Dear All, I was wondering if someone could point me to code for configuring a usrp with 2 transmitting and 2 receiving antennas. I tried to make some code by copying certain parts in multi_file.py, and it seems to be working to some degree, but I am not sure, because multi_file.py seems to be for receiving from 4 antennas. Thanks! Best regards, Zenny ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help on gr_top_block and gr_hier_block2 when trying to receive after transmitting
Dear All, I was trying to make a channel estimation procedure to work, and I am in desperate need for some help. I had a preliminary version that works only part of the time, and I decided to start from scratch. I followed Eric's advice and used tunnel.py as an example. I have two USRPs, one called S and the other called R. The procedure is: (1). S sends channel estimation sequence. R receives, and estimate the channel. (2). R sends the channel estimation report back to S. (3). S sends data to R according to the channel estimation Everything works perfectly until step (2), that is, S can get the channel estimation report and can send data to R. The problem is that R cannot receive. The signal received by R is almost always near 0. My guess is that something is preventing R from receiving after it started the transmit path. Here is the skeleton of the code: tb.start() print --- started listening! --- while not tb.rxpath.receiver.finished_phase_diff_est(): time.sleep(0.001) #orig: 0.001 # here I do carrier sense, until the sender finishes while tb.rxpath.receiver.est_snr() 0.001: time.sleep(0.001) print --- sender stopped, preparing to send report! --- # here I call some functions to estimate the chanel tb.lock() tb.disconnect_all() # the transmting path was not connected originally, because my laptops are slow. I am getting some new ones. # add then cannot receive begin tb.connect(tb.txpath) tb.unlock() tb.txpath.set_tx_amplitude(_def_rv_tx_power) print --- sending rpt --- time.sleep(0.01) #orig: 0.01 tb.txpath.set_tx_amplitude(0) time.sleep(0.1) #try to make sure that 0 is written into the data buffer. tb.lock() print --- done sending! --- # add then cannot receive end tb.disconnect_all() tb.connect(tb.rxpath) tb.unlock() time.sleep(1) print --- done receving --- I noticed that if I delete the code between # add then cannot receive begin # add then cannot receive end , then the receiver can receive some signals. txpath and rxpath are both gr.hier_block2, and tb is gr_top_block, same as in tunnel.py. Can someone give me some hint to this? Thanks so much! Please let me know if more information is needed. Best regards, Zenny ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get wireless carrier signal in GNU Radio
Sachin, Sure, here is the related code I use: # get a probe alpha = 0.001 thresh = 30 self.probe = gr.probe_avg_mag_sqrd_c(thresh,alpha) # connect usrp to the probe self._fg.connect(self.u, self.probe) # wait until the medium is free while objDemod1.probe.level() threshold: time.sleep(0.0001) Zhenghao On Thu, Oct 23, 2008 at 4:59 PM, Shirve [EMAIL PROTECTED] wrote: Hi Zhenghao, Thank you for your valuable reply. I appreciate it. As per your supplied information, I will start looking for CSMA code in tunnel.py, though if you can send me your code, it will be quite helpful too. I hope that using tunnel.py code and help from you I will be able to get the carrier sense capability for my application. Thanks -Sachin Zenny Zhang wrote: Sachin, I don't know if this is helpful, just sharing my experience. 1. You may want to check tunnel.py, in which there is a CSMA scheme -- Eric told me this a couple of weeks ago. 2. It is possible to do some carrier sensing by ourself. You can just read the signal from the USRP and compare the signal strength level with a threshold. Of course a filter is needed. I tried this last week and it is working, although the threshold may need some tuning. If you need I can send you the code written in python. Zhenghao On Wed, Oct 22, 2008 at 6:19 PM, Shirve [EMAIL PROTECTED] wrote: Hi, As per the current status of GNU Radio, I got to know that there is no MAC (CSMA) implementation. Therefore I am not sure if I can get the signal from signal processing blocks of GNU Radio about the carrier sensed by USRP receiver. Please help me in this regard. Till now I am able to locate the message queue mechanism to get the received packets from the other USRP transmitter, which is in gr_msg_que.cc in runtime library of GNUradio-core. But this mechanism just indicates the received packets (correct or corrupted), while the signal sensing (packet start) starts much earlier than the complete packet reception. Is it possible to get the information about the wireless carrier signal in the vicinity of USRP receiver from the current GNU Radio framework? I am using GNU Radio 3.1.1 version. Your help will greatly help me in my goal. Thanks in advance and expecting your kind reply. - Sachin -- View this message in context: http://www.nabble.com/how-to-get-wireless-carrier-signal-in-GNU-Radio-tp20120856p20120856.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/how-to-get-wireless-carrier-signal-in-GNU-Radio-tp20120856p20139200.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get wireless carrier signal in GNU Radio
Sachin, I don't know if this is helpful, just sharing my experience. 1. You may want to check tunnel.py, in which there is a CSMA scheme -- Eric told me this a couple of weeks ago. 2. It is possible to do some carrier sensing by ourself. You can just read the signal from the USRP and compare the signal strength level with a threshold. Of course a filter is needed. I tried this last week and it is working, although the threshold may need some tuning. If you need I can send you the code written in python. Zhenghao On Wed, Oct 22, 2008 at 6:19 PM, Shirve [EMAIL PROTECTED] wrote: Hi, As per the current status of GNU Radio, I got to know that there is no MAC (CSMA) implementation. Therefore I am not sure if I can get the signal from signal processing blocks of GNU Radio about the carrier sensed by USRP receiver. Please help me in this regard. Till now I am able to locate the message queue mechanism to get the received packets from the other USRP transmitter, which is in gr_msg_que.cc in runtime library of GNUradio-core. But this mechanism just indicates the received packets (correct or corrupted), while the signal sensing (packet start) starts much earlier than the complete packet reception. Is it possible to get the information about the wireless carrier signal in the vicinity of USRP receiver from the current GNU Radio framework? I am using GNU Radio 3.1.1 version. Your help will greatly help me in my goal. Thanks in advance and expecting your kind reply. - Sachin -- View this message in context: http://www.nabble.com/how-to-get-wireless-carrier-signal-in-GNU-Radio-tp20120856p20120856.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cannot receive after one run of the code?
Dear All, I am writing because I am really in need for some advice. I wrote a program that (1) receives from the sender and estimates the channel (2) switch to the transmitting mode and sends the channel estimation back to the sender (3) switch back to the receiving mode to receive data A while ago, I asked about how to switch between these modes without having to stop the flow graph, and Eric gave me excellent advice on looking at tunnel.py. Recently, after did some optimizations, I found that the code is having a weird problem, and I have struggled on it about a week on it but still don't know what to do. Basically, after power-on the USRP, the code runs perfectly once. But most often, it runs well exactly once -- the next time I run it, the receiver at step 1 cannot receive any signal. To run it again, I have to unplug the USRP. Here, by not receiving any signal, I mean that the signals read from USRP have an average square value of around 0.8. When things are working fine, the value is around 200 when the sender is not sending, and is around 100 when the sender is sending. At first I thought it was because I did not set mux right. But it does not seem to be so. I also noticed that after I screw it up, I cannot even run the benchmark_rx.py, because it will also not receive anything. But I can run usrp_oscope.py and I can see the waveform when I have a transmitter sending. I really appreciate if someone could give me a hint on this. Thanks so much! Best regards, Zhenghao --- I have simplified my code and I am posting it here. This code has exactly the same problem as I described. If other information is needed, please let me know. Thanks! from gnuradio import gr, gru, modulation_utils from gnuradio.blksimpl import psk import cmath import Numeric from pprint import pprint from gnuradio import usrp from pick_bitrate import pick_rx_bitrate import time import sys from arrayimport array from pick_bitrate import pick_tx_bitrate # default values (used in __init__ and add_options) _def_samples_per_symbol = 2 _def_excess_bw = 0.35 _def_gray_code = True _def_verbose = True _def_log = True _def_costas_alpha = 0.05 # the original setting _def_gain_mu = 0.03 _def_mu = 0.05 _def_omega_relative_limit = 0.005 _def_rv_tx_freq = 247000 _def_rv_rx_freq = 242000 _def_found_delta_f = 0.025 _def_bitrate = 50 _def_PI = 3.141592653 _def_rv_tx_power = 2000 #org: 12000 # / # DBPSK demodulator # # Differentially coherent detection of differentially encoded BPSK # / class dbpsk_demod(gr.hier_block): def __init__(self, fg, samples_per_symbol=_def_samples_per_symbol, excess_bw=_def_excess_bw, costas_alpha=_def_costas_alpha, gain_mu=_def_gain_mu, mu=_def_mu, omega_relative_limit=_def_omega_relative_limit, gray_code=_def_gray_code, verbose=_def_verbose, log=_def_log): Hierarchical block for RRC-filtered differential BPSK demodulation The input is the complex modulated signal at baseband. The output is a stream of bits packed 1 bit per byte (LSB) @param fg: flow graph @type fg: flow graph @param samples_per_symbol: samples per symbol = 2 @type samples_per_symbol: float @param excess_bw: Root-raised cosine filter excess bandwidth @type excess_bw: float @param costas_alpha: loop filter gain @type costas_alphas: float @param gain_mu: for MM block @type gain_mu: float @param mu: for MM block @type mu: float @param omega_relative_limit: for MM block @type omega_relative_limit: float @param gray_code: Tell modulator to Gray code the bits @type gray_code: bool @param verbose: Print information about modulator? @type verbose: bool @param debug: Print modualtion data to files? @type debug: bool self._fg = fg self._samples_per_symbol = samples_per_symbol self._excess_bw = excess_bw self._costas_alpha = costas_alpha self._gain_mu = gain_mu self._mu = mu self._omega_relative_limit = omega_relative_limit self._gray_code = gray_code self._rx_freq= _def_rv_rx_freq self._rx_gain= 45 # receiver's gain self._rx_subdev_spec = None self._bitrate= _def_bitrate self._decim = 64 # Decimating rate for the USRP (prelim) self._fusb_block_size= 0 self._fusb_nblocks = 0 if self._rx_freq is None:
[Discuss-gnuradio] Switching from the receiving mode to the transmitting mode?
Dear All, I am working on an application where I have a sender S and a receiver R. The procesure runs as follows: (1) S transmits the channel estimation sequence. R estimates channel. (2) S switches to receiving mode. R switches to the transmiting mode. R sends the channel estimation back to S. (3) S switches back to transmiting mode. R switches back to the receiving mode. S sends data to R. For both S and R, I created two flow graphs, one for transmiting and the other for receiving. When switching modes, I was basically starting and stopping flow graphs. I found that I have to stay in step (1) and (2) for at least 0.1 sec. Are you aware of any faster method to do this? Thanks so much for any hint! Best regards, Zhenghao ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Switching from the receiving mode to the transmitting mode?
Dear Eric, On Thu, Oct 9, 2008 at 2:19 PM, Eric Blossom [EMAIL PROTECTED] wrote: Use Auto Transmit/Receive switching (ATR) and see tunnel.py for an example that uses it. (It's a terrible example of a MAC, but does show how to set up something similar to what you want.) No need to stop the flow graphs. Thank you so much. I will look at tunnel.py. Best, Zhenghao ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A question about using two daughter boards on usrp for simultaneous transmitting and receiving
Hi, I have a question about using two daughter boards on usrp for simultaneous transmitting and receiving. Basically, in my application, the sender has two antennas and transmit a stream of training symbols to the receiver who has one antenna. The receiver estimates the channel and send the estimate back to the sender. For simplicity allow me to call the sender S and the receiver R. So for S I created two flow graphs, fg and fg1, one for transmitting the training symbols and the other for receiving the channel estimate report. The trouble is that each flow graph works perfectly fine individually, that is, if I only run fg, S can estimate the channel, and if I only run fg1 and ask R to send some constant back, S can get the correct report. But when I run fg first, then stop it, then run fg1 (by doing so I am trying to achieve the automatic channel feedback function), S will not get the report for most of the time. More over, after I run my application, if I run benchmark_tx.py on R and benchmark_rx.py on S, S cannot get the packets from R. This lead me to guess that I really messed up something in USRP. I can return things to normal by unplugging the power of USRP and plug it back after some time. Based on my limited experience, I guess it is because of S has two antennas and maybe I didn't do the right thing for setting up the usrp sink. I am guessing this because R is also running two flow graphs, one for receiving from S and the other for sending to S, and R seems to be fine. I tried several means to fix this: 1. I made sure that S and R are transmitting on different frequencies 2. I made sure that when I stop fg, the transmitting power at S is 0 3. I checked the received signal strength at S and it should be fine. It looks like S cannot get the correct carrier phase/sampling time. Any hint wil be greatly appreciated. Thanks. Also, please let me know if you need any more information for this. Below is the code I used to set up the usrp sink, I basically just copied from the usrp multi-antenna code and modified a little def _setup_usrp_sink(self): Creates a USRP sink, determines the settings for best bitrate, and attaches to the transmitter's subdevice. self.u = usrp.sink_c(nchan=2) # say we want two channels self.dac_rate = self.u.dac_rate()# 128 MS/s # derive values of bitrate, samples_per_symbol, and interp from desired info (self._bitrate, self._samples_per_symbol, self._interp) = \ pick_tx_bitrate(self._bitrate, 1, self._samples_per_symbol, None, self.dac_rate) self.u.set_interp_rate(self._interp) self.usrp_rate = self.dac_rate / self._interp # we're using both daughterboard slots, thus subdev is a 2-tuple self.subdev = (self.u.db[0][0], self.u.db[1][0]) print Using TX d'board %s % (self.subdev[0].side_and_name(),) print Using TX d'board %s % (self.subdev[1].side_and_name(),) # set up the Tx mux so that # channel 0 goes to Slot A IQ and channel 1 to Slot B IQ self.u.set_mux(0xba98) self.subdev[0].set_gain(self.subdev[0].gain_range()[1])# set max Tx gain self.subdev[1].set_gain(self.subdev[1].gain_range()[1])# set max Tx gain self.set_freq(0, _def_sd_tx_freq) self.set_freq(1, _def_sd_tx_freq) self.subdev[0].set_enable(True) # enable transmitter self.subdev[1].set_enable(True) Thanks, Zenny ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] two possible bugs in qpsk receiving with GNU radio
I was working on qpsk receiving with GNU radio and I was wondering if
these are something we should change.
1. The qpsk constellation in the current code seems to be (1,0),
(0,1j), (-1,0), (0,-1j). Should it be rotated by 45 degrees?
2. I understand that in the current mpsk_receiver_cc block, qpsk
decisions are obtained by calling the generic decision function.I just
want to mention, in case anyone wants to use the decision_qpsk
function, that it has bug in it and will never return decision 0.
unsigned int
gr_mpsk_receiver_cc::decision_qpsk(gr_complex sample) const
{
unsigned int index = 0;
// Implements a simple slicer function
if((sample.real() 0) (sample.imag() 0))
index = 1;
else if((sample.real() 0) (sample.imag() 0))
index = 2;
//bug here begin
else
index = 3;
//bug here end
// fixed begin
else if((sample.real() 0) (sample.imag() 0))
index = 3;
// fixed end
return index;
}
Also, this qpsk decision function is using the rotated constellation.
I actually copied the original mpsk_receiver_cc code and modified it
to rotate the constellation and it works fine.
Zenny
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] two possible bugs in qpsk receiving with GNU radio
On Thu, Jun 19, 2008 at 1:35 PM, Brian Padalino [EMAIL PROTECTED] wrote: It appears that is the case. Looking at the changeset located here: http://gnuradio.org/trac/changeset/7389#file6 It appears as if around 5 months ago this was changed. Thanks! Looks like I am using some old code... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gr_mpsk_ receiver_cc’s costas loop issue
Hi, I have been working on the mpsk receiver code also recently. Hope I can be of some help. terminal_display result files prove NCO's frequency isn't adapted to frequency_offset correction (even for small values of frequency deviation). I am not sure what you printed as f. The mpsk_receiver_cc block can return both the frequency and phase. The frequency is more or less stable and seems to be the frequency offset, the NCO value is just the phase difference as far as I remember, and will change wildly. The mpsk_receiver_cc tracks phase change with phase tracking code, and I don't think there is an NCO involved... - Zenny ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to enable synchronous transmission from two antennas? Thanks!
Hi All, I understand that I am asking a question that has been asked several times --- how to enable synchronous transmission from two antennas? Basically, I want see if I could send two streams through two antennas simultaneously while the symbols of the two streams are synchronized. I found this recent thread http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg12571.html about the same problem, and I was just wondering how things have developed, like the m-block code and in-band code. If they are ready, where could I get them? Thanks a lot in advance for any hint. I also checked this link http://www.gnuradio.org/trac/wiki/MultiUsrp and found that it seems to be about allowing synchronous reception, and I am not sure whether the same hardware connection works for synchronous transmission. Again, thanks in advance for any hint. In fact I equipped one USRP board with two daughter boards (RFX2400, rev30), and I initially hoped that one USRP board could drive two transmitting antennas synchronously. Is this possible? Thanks. Zenny ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
