Could someone be kind enough to make a DVD for me with the raw samples of
the FM Broadcast band?
The reason I'm asking for this is I currently do not have access to any of
the USRP devices, and would like to test an idea I have.
Thank you in Advance,
Justin N2TOH
I observed today with a controlled test using valve blocks that the
scrambler block continues to output data even when no input data should
be coming in. I then looked at the source:
int
gr_scrambler_bb::work(int noutput_items,
gr_vector_const_void_star &input_items,
On Wed, Dec 8, 2010 at 5:12 PM, Ed Criscuolo
wrote:
> I just tried to use a new RFX2200 daughterboard in a USRP1 with
> the latest stable release GnuRadio 3.3.0, and it didn't recognize it.
> Usrp_probe reported a Name of "Unknown (0x002C)".
>
> What's the deal here? Do I need to go to the latest
Check out this link. You will find everything you want.
http://www.ansr.org/kd7lmo/www.kd7lmo.net/ground_gnuradio_ota.html
On Wed, Dec 8, 2010 at 8:58 PM, Justin Kelly wrote:
> Could someone be kind enough to make a DVD for me with the raw samples of
> the FM Broadcast band?
>
> The reason I'm
Hi list,
I'm writing a program to use QAM using a combination of Matlab and gnuradio
(QAM demod hasn't been implemented in gnuradio). My Matlab code does all of
the baseband signal processing, produces a complex vector of samples at the
transmitter. It also takes a complex vector of samples to dec
On 12/9/10 4:07 PM, Jason Abele wrote:
Looks like the rfx2200 code for usrp1 is incomplete. I have attached
a patch that should apply rfx2200 support to any gnuradio tree>=
3.3.0
Thanks Jason! You're a lifesaver! I've got a pending delivery
in the next week or so that depends on this. I'll
Thanks Ben. I'll look into that.
On Thu, Dec 9, 2010 at 5:32 PM, Ben Reynwar wrote:
> I'm working on getting QAM working in gnuradio at the moment. It's my
> first foray into signal processing so it's not at all robust or
> efficient. Hopefully it will improve.
> You can find the code at githu
Hi,
i have just compiled gnuradio from git, as i have an usrp with a 52mhz
clock i was trying to apply the modifications documented. Unfortunately
the files usrp/lib/legacy/* do not exist anymore.
i can find the files in usrp/lib directly but the lines somehow differ.
I find d_fpga_master_cl
On Thu, Dec 9, 2010 at 5:11 AM, Patrik Eliardsson
wrote:
> Dear list,
>
> What is the expected behavior when we get underruns with the UHD and the flow
> control using the USRP2?
>
> 1) When we get underruns, does the usrp2 send some random samples until the
> host computer manage to feed the us
I'm working on getting QAM working in gnuradio at the moment. It's my
first foray into signal processing so it's not at all robust or
efficient. Hopefully it will improve.
You can find the code at github.com/benreynwar/gnuradio.
There's an example file in my repo at
gnuradio-examples/python/digit
> thanks for the help. I think my configuration is correct, but I am using the
> mimo cable.
OK, I polished the multi-device addressing scheme. Previously you gave
it a list of IP addresses. Well there wasnt any sanity checking
implemented and it was missing all of the device identification
gran
On Wed, Dec 8, 2010 at 7:55 PM, Brett L. Trotter wrote:
> The current git tree doesn't seem to have the USRP1 or USRP2 firmware
> for a non UHD setup. The Wiki seems to indicate it should be in
> gnuradio/usrp/fpga, but the only directory I see there is 'rbf'.
>
> Has it moved to a separate tree,
On 12/09/2010 02:11 AM, Patrik Eliardsson wrote:
> Dear list,
>
> What is the expected behavior when we get underruns with the UHD and the flow
> control using the USRP2?
>
The host will get an async packet marked underflow and print a U. You
can get the timestamp of this packet through the r
On Wed, Dec 8, 2010 at 1:55 PM, Brett L. Trotter wrote:
> I observed today with a controlled test using valve blocks that the
> scrambler block continues to output data even when no input data should
> be coming in. I then looked at the source:
>
>
> int
> gr_scrambler_bb::work(int noutput_items,
On Wed, Dec 08, 2010 at 12:55:20PM -0600, Brett L. Trotter wrote:
> I observed today with a controlled test using valve blocks that the
> scrambler block continues to output data even when no input data should
> be coming in. I then looked at the source:
>
> int
> gr_scrambler_bb::work(int noutput
-
Hello Josh,
thanks for the help. I think my configuration is correct, but I am using the
mimo cable.
And as I just read, MIMO cable doesn't work with UHD at the moment.
I read some mails in the list form the 18th of november, in which you wrote,
that you're realizing the routing of the FPGA at
Didn't look hard enough. I found the matlab utils in
/gnuradio-core/src/utils
Since there's no write_complex_binary.m I guess I'll need to output my
complex samples in 2 files, one for I and one for Q.
On Thu, Dec 9, 2010 at 10:31 AM, Tuan (Johnny) Ta wrote:
> Hi list,
>
> I'm writing a program t
Since the RFX2200 does not seem to be supported by GR 3.3.0, I switched
over to the latest git source and tried it. It seems to be broken
with respect to the RFX2200. Probing the USRP now detects the card's
name correctly (Flex 2200 Rx MIMO B), but still complains that it
has "... invalid EEPROM
I just tried to use a new RFX2200 daughterboard in a USRP1 with
the latest stable release GnuRadio 3.3.0, and it didn't recognize it.
Usrp_probe reported a Name of "Unknown (0x002C)".
What's the deal here? Do I need to go to the latest development
version to get it to recognize this card? If so,
Dear list,
What is the expected behavior when we get underruns with the UHD and the flow
control using the USRP2?
1) When we get underruns, does the usrp2 send some random samples until the
host computer manage to feed the usrp2 and then starts to consume the 'old'
samples from the host comput
Alright, i was able to replicate the problem. If i tried to create a
multi usrp with one or more addresses that did not correspond to an
actual usrp it would throw "lexical cast error".
It wanted to throw "no control response error" but the exception threw
an exception. Anyway, I pushed a fix for
> looking for an implementation that's entirely USRP based.
> I am only looking to be able to get the demodulated symbols
> on the USRP rather than doing it on the PC. Would I need to
> implement all of the blocks you mentioned -
Correct. ISTR Stevie's receiver has a squelch block as well...
Al
The current git tree doesn't seem to have the USRP1 or USRP2 firmware
for a non UHD setup. The Wiki seems to indicate it should be in
gnuradio/usrp/fpga, but the only directory I see there is 'rbf'.
Has it moved to a separate tree, and where might I find it?
Thanks in advance!
-Brett
__
Max,
Thanks so much for your quick response. As it turns out, I'm already
part of the op25 yahoo group, and I've seen the good work the op25 group
has done. However, like you said, I am looking for an implementation
that's entirely USRP based. I am only looking to be able to get the
demodulat
In case anyone else happens to be interested, it appears that you need
a lower value of freq_alpha for the frequency lock loop
(fll_band_edge_cc) if the number of samples per symbol is higher.
I'm pretty sure that an unstable fll was causing the errors I was seeing.
python benchmark_qt_loopback2.p
Following up to my last- it seems I've generally misunderstood the valve
block. (also, my code example was off the top of my head and incorrect).
Please disregard the other post on this thread. Thanks.
-Brett
On 12/08/2010 12:55 PM, Brett L. Trotter wrote:
> I observed today with a controlled te
26 matches
Mail list logo