To put it in simple words, I am wondering why the GMSK-Mod blocks always
outputs 8192 bits - no matter when I input 50 bits or 255 bits.
Is there a GMSK-burst-like modulation happening?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https:
I trying to run a GMSK mod/demod test under GRC. My objective is to
create a single GSM-like burst and to store it in a file. The waveform
should have defined bits (by now I assume them to be random).
Thus I created a flowgraph that looks like this
Random Source (fixed # of samples, no repeat)
Perhaps it would work better to treat the input as one variable. Use a
tuple of numbers instead. You can make a text entry widget w/ converter
type "Evaluate".
The callback would probably look more like this:
set_user_register(*\$user_reg_args)
-josh
Thanks, thats already a good solution. How
Perhaps it would work better to treat the input as one variable. Use a
tuple of numbers instead. You can make a text entry widget w/ converter
type "Evaluate".
The callback would probably look more like this:
set_user_register(*\$user_reg_args)
-josh
Thanks, thats already a good solution. How
I am trying to build a flow graph in GNU Radio Companion consisting of a
USRP source block and a FFT sink. During runtime, I would like to send a
user settings register to the USRP.
Fortunately, everything is already employed so I only need to build some
sort of variable control. By now, that al
There is a coarse and a fine frequency offset correction. The fine
correct makes sure that the subcarrier is centered in the bin; the
coarse adjusts for an integer number of subcarriers off from the center
frequency. By default, the OFDM receiver will correct for some number of
subcarrier bins (it
Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it
just with the OFDM transmitter?
What is this tool doing? Transmitting a sine and checking the offset.
Sorry, for the moment I have no possibilitie to check that.
> It's because with the larger bandwidth, the subcarriers,
I highly suspect it's user error :) but I'm truly at a loss right now as to the
error.
Michael,
we encountered a very similar issue and spent already a lot of time on
that. Configuration is the same except we are using an USRP2 though.
We also did not receive anything at the RX side although
I found something on the mailinglist that there might also be
SEND_MODE_ONE_PACKET function beside the SEND_MODE_FULL_BUFF but
actually it affects nothing as I replace it in the gr_uhd_usrp_sink.cc
(after recompling etc.).
In another thread it was mentioned that the transmitting buffer is not
t
> Please don't e-mail the same question to the list in multiple threads -
> it actually makes it more difficult for people to help you in a coherent
> manner.
Sorry, I thought about to specify that a little bit more to make it
findable more easily afterwards.
> It is possible that tunnel.py is
Trying out the tunnel.py example, we are transmitting a ping request
between two USRP2s. The receiving USRP should respond immediately with a
ping reply what the outpout is also saying.
At all, this ping reply is not send. We can bypass this by deploying a
time.sleep(0.05) at the RX-USRP before
The XCVR2450 hardware is incapable of full-duplex operation. It *cannot*
transmit and receive at the same time.
Yes, you are right but consider we are transmitting ping requests just
for a very short moment (since they are also containing only 84 bytes)
with a frequency of 1 Hz. Hence, we are
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel correct as some packets are
received and transmitted after having configured the IP
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel correct as some packets are
received and transmitted after having configured the IP
Ok, that definitely makes sense if there is no error correction is
implemented.
We are now trying to establish an TCP/IP connection between both USRP2s
with the tunnel.py script.
Unfortunately, it says "Destination Host unreachable" when pinging the
other USRP. We should have set up the tunnel
> But fiddling with gain values is often useful; even if you've already
> done that I recommend trying again, by reducing tx-amplitude and the
> actual gain values, shifting the terminals around (perhaps they're too
> close?).
We have now found out that we need a sampling rate of at least 2Msps
wh
Hey guys,
we are trying to get run the tunnel.py / benchmark_rx.py (OFDM) in order to
measure the datarate between two USRP2 (located with distance of 1 m) with
daughterboards XCVR2450.
We are running the benchmark_tx/rx.py as follows:
benchmark_tx.py -f 2.4G --tx-gain=10 --tx-amplitude=0.8 -v
be
17 matches
Mail list logo
