Dear All,
Can anyone also address the first part of my question aslo, I mean how to
improve the quality of received data. I mean is it normal with GNU
Radio/USRP that we receive so currupt data or I am doing something wrong.
Any suggestion please...
Thanks
Matt Ettus wrote:
Hi
I'm trying to write USRP data to a FIFO and read it out using a C++
app. I can't get it to work. What I did was to type 'mkfifo myfifo'
in the shell. This is the output to ls -l myfifo.
prw-r--r-- 1 sebastiaan sebastiaan 0 2008-07-23 14:20 myfifo
I then tried to run my application, passing
Quoting kaleem ahmad <[EMAIL PROTECTED]>:
>
> Dear All,
>
> Can anyone also address the first part of my question aslo, I mean how to
> improve the quality of received data. I mean is it normal with GNU
> Radio/USRP that we receive so currupt data or I am doing something wrong.
> Any suggestion pl
I have nfs mounted the gnuradio build directory on the Beagle, (and
synced the clocks with ntp). When "make check" gets to
gnnuradio-core/src/tests, it looks like the test tries to run some
command from the build system.
If I run the individual test on the host I get this:
[EMAIL PROTECTED] tests
Hi,
You can find attached the code for transmit and receive sides, and the file
which I am sending (send.txt) and one which I am receiving (rcv.txt). You
can see that nearly 80%-90% received data is corrupt. I am receiving around
50dBm at receiver antenna, and I have tried with both stations at l
kaleem ahmad wrote am 2008-07-23 11:38:
Dear All,
Can anyone also address the first part of my question aslo, I mean how to
improve the quality of received data. I mean is it normal with GNU
Radio/USRP that we receive so currupt data or I am doing something wrong.
Any suggestion please
Before
I have just provided the information which can be helpful for you, and the
code is also attached with it and a sample received file is also there along
with actual sent file.
Please just scroll up and you will find my message with all this
information. Additionally OS is 'openSUSI' a favour of Li
Is there any documentation on what the gain does for the USRP receive and
transmit functions. Sometimes it seems like these values are meaningless.
Also, I am noticing that when I begin to Rx data, there is often a huge
amplitude spike within the first 2k samples I Rx. Is this normal?
--
Vie
Hello Kaleem!
kaleem ahmad wrote am 2008-07-23 15:58:
If you have two USRP boards and two RFX2400 daughter cards then you can try
these codes (fsk_tx.py and fsk_rx.py) using:
Which version of GNU Radio are you using?
Which cable/antenna setup do you use?
You are hard coding your frequency. Y
Hi all,
I want to ask how much is a USRP board(1 motherboard and 4
daughterboards)?Where can I buy them in China?
Thanks!
DONG Chao___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
kaleem ahmad wrote am 2008-07-23 16:23:
I have just provided the information which can be helpful for you
Seen it, just after I pressed the send button.
Race condition ;-)
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser
Student of Telematik, Techn. University G
On Wed, Jul 23, 2008 at 07:45:57AM -0700, isaacgerg wrote:
>
> Is there any documentation on what the gain does for the USRP receive and
> transmit functions. Sometimes it seems like these values are meaningless.
Sometimes they are fixed. Have you queried the valid ranges for the
daughterboards
On Wed, Jul 23, 2008 at 02:32:06PM +0200, Sebastiaan Heunis wrote:
> Hi
>
> I'm trying to write USRP data to a FIFO and read it out using a C++
> app. I can't get it to work. What I did was to type 'mkfifo myfifo'
> in the shell. This is the output to ls -l myfifo.
>
> prw-r--r-- 1 sebastiaan
Hi Kaleem,
Each USRP has its on reference crystal oscillator. This oscillator may have
maximum +/- 50 PPM ( Matt said the new USRPs has maximum 20 PPM) frequency
error. Lets assume the error is 10 PPM in each USRP. This means, that at 2500
MHz (2.5 GHz) the error = 2500 * 10 = 25000 Hz = 25KHz.
Hi,
See:
http://www.ettus.com/custom.html
Firas
--
View this message in context:
http://www.nabble.com/how-much-is-USRP-board--tp18612549p18613720.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing li
I am sending a known sequence of samples from one USRP to another using the
Basix RX/TX d'boards setting the frequency to 24e6.
When I rx the sequence, the correlation of it keeps flipping, but not in a
way that suggests residual carrier. It seems as if I am experiencing an
instantaneous flip.
As I see from the simple manual and some source code, most of the blocks are
designed for PHY layer or hard ware. Should all the MAC layer functions
implemented by python application, or are there any existing MAC layer
blocks we can use directly? Thanks for help.
Y
yyzhuang wrote:
>
> Thanks
There is currently no MAC layer support. There has been some work in
supporting it through the new m-blocks, but I still believe there are
pieces missing for tightly timed CSMA MACs. The timestamps are great
for TDMA, but CSMA is still kind of left in the dark.
I'm working on it as research
On Wed, Jul 23, 2008 at 09:06:57AM -0700, yyzhuang wrote:
>
> As I see from the simple manual and some source code, most of the blocks are
> designed for PHY layer or hard ware. Should all the MAC layer functions
> implemented by python application, or are there any existing MAC layer
> blocks we
Eric Blossom wrote:
In the relatively near term, I'll be gluing the message blocks
(m-blocks) and the GR flow graphs together. When that is complete, I
expect that what you'll find is that the natural place to write MAC
layer stuff is in m-blocks while using the flow graph to implement the
P
On Wed, Jul 23, 2008 at 12:37:03PM -0400, George Nychis wrote:
>
> Eric Blossom wrote:
>
>>
>> In the relatively near term, I'll be gluing the message blocks
>> (m-blocks) and the GR flow graphs together. When that is complete, I
>> expect that what you'll find is that the natural place to write M
Hi Eric,
I haven't seen tutorials about how to use m-blocks yet. I'm curious and want
to see how it works, although I'm not sure what I can get from it. Are there
any examples about how to use the m-blocks in gnuradio-examples? Thanks
Y
Eric Blossom wrote:
>
> On Wed, Jul 23, 2008 at 09:06:5
Thanks George. I'm still exploring Gnu Radio. Since I'm a student in Computer
Science, I know very little about PHY and hardware, but our group will work
with Electrical Engineering people as well.
Hope to see the new mac blocks.
Y
George Nychis wrote:
>
> There is currently no MAC layer suppo
yyzhuang wrote:
Thanks George. I'm still exploring Gnu Radio. Since I'm a student in Computer
Science, I know very little about PHY and hardware, but our group will work
with Electrical Engineering people as well.
I'm of a CS background, so I know exactly what you mean. Hang in there,
what
Really thanks for the efforts. Surely more stuff will be added in the future.
Maybe some day we can build up the entire protocol stack.
George Nychis wrote:
>
>
>
> yyzhuang wrote:
>> Thanks George. I'm still exploring Gnu Radio. Since I'm a student in
>> Computer
>> Science, I know very litt
yyzhuang wrote:
Really thanks for the efforts. Surely more stuff will be added in the future.
Maybe some day we can build up the entire protocol stack.
I think that GR has been great for PHY development and testing. If you
follow academic research at all in the CS network realm, you'll fin
Hi George,
Thanks for the quick and thought-out response. I actually tried with
the new rbf yesterday. It produces no noticeable differences in the
output I'm interested in at this point.
Second, we are not seeing any underrun. I have verified this in two
ways. First, I check pkt->underrun()
Steve Peters wrote:
Hi George,
Thanks for the quick and thought-out response. I actually tried with
the new rbf yesterday. It produces no noticeable differences in the
output I'm interested in at this point.
Not getting an underrun is good. There may very well be an issue with
the FPGA.
George,
I am sure that Steve will check the single rx-chain and get back to
you with the results of that test.
Although, I have a hypothesis about what might be happening. Is it
possible that there are some control signals being sent to the USRP
over the command channel that disable the rx_buffer
George Nychis wrote:
I spend all of my time working with the single chain, and if I find bugs
I can fix them. But I think you're the only ones using the dual
chain... so your feedback is useful and I'd appreciate any help solving
the problems. I don't really know Verilog, and our Verilog c
Ketan Mandke wrote:
George,
I am sure that Steve will check the single rx-chain and get back to
you with the results of that test.
Although, I have a hypothesis about what might be happening. Is it
possible that there are some control signals being sent to the USRP
over the command channel th
> Ketan Mandke wrote:
>>
>> George,
>>
>> I am sure that Steve will check the single rx-chain and get back to
>> you with the results of that test.
>>
>> Although, I have a hypothesis about what might be happening. Is it
>> possible that there are some control signals being sent to the USRP
>> over
Hi
I managed to get the previous issue sorted. You guys were right,
FIFOs are blocking, so you first need to open a read before you can
start writing to it. Now I just have a question. How do I read this
data in C++? At the moment I am using
double *buf = new double;
FILE* fifo = fopen("myf
Hi everyone,
What is the input impedance for the TVRX and DBSRX daughterboards?
The
tuners used on the boards have 75Ω inputs according to the tuners'
datasheets. Are the board inputs also 75Ω, or has something been done
to convert them to 50Ω inputs?
Thanks!
Thomas
Thomas wrote:
Hi everyone,
What is the input impedance for the TVRX and DBSRX daughterboards?
The tuners used on the boards have 75Ω inputs according to the tuners'
datasheets. Are the board inputs also 75Ω, or has something been done
to convert them to 50Ω inputs?
The TVRX is really 75 o
Hi All,
I am having lots of issues with the USRP 64MHz (20ppm) on board oscillator
which does not allow me to get exact and constant RF frequencies out of the
RFX900 board. I can not really fix that in SW so I was thinking about
replacing the 64MHz crystal with a more precise one. Has anybody a
s
Wireless Monster wrote:
Hi All,
I am having lots of issues with the USRP 64MHz (20ppm) on board
oscillator which does not allow me to get exact and constant RF
frequencies out of the RFX900 board. I can not really fix that in SW so
I was thinking about replacing the 64MHz crystal with a more
On Wed, Jul 23, 2008 at 5:30 PM, Wireless Monster
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I am having lots of issues with the USRP 64MHz (20ppm) on board oscillator
> which does not allow me to get exact and constant RF frequencies out of the
> RFX900 board. I can not really fix that in SW so I w
On Wed, Jul 23, 2008 at 3:57 PM, Chris Stankevitz <[EMAIL PROTECTED]> wrote:
>> I am having lots of issues with the USRP 64MHz (20ppm) on board
>> oscillator which does not allow me to get exact and constant RF frequencies
>> out of the RFX900 board. I can not really fix that in SW so I was think
Steve Peters wrote:
Just a quick follow-up to this. Last night I printed out diffs in the
std::clock() function along with the timestamp diffs right after the
packets are read. There are no jumps in the std::clock(), which tells
me the timestamp jump is caused by something strange like the c
Hey all,
What is the best way to measure the channel for use in space-time
coding schemes using an RFX2400 board?
As far as I know you can only get the I and Q streams out of the USRP,
and I'm not sure how you would get a set of channel coefficients.
I am planning on using the conjugate of the m
On Wed, Jul 23, 2008 at 10:43 PM, Jason Uher <[EMAIL PROTECTED]> wrote:
> Hey all,
>
> What is the best way to measure the channel for use in space-time
> coding schemes using an RFX2400 board?
>
> As far as I know you can only get the I and Q streams out of the USRP,
> and I'm not sure how you wou
Hi,
I am reading two data streams from two files using the
command
Src1 = gr.file_source(gr.sizeof_short, "file1.dat")
Src2 = gr.file_source(gr.sizeof_short, "file2.dat")
I want to multiply the two data streams using
multiply = gr.mul
43 matches
Mail list logo
