Can I burn the USRP2 non-UHD firmware on an N210?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
It seems my old patch that zeroed out the output of the USRP didn't make
it into UHD- we're seeing a constant sine output between packets- and in
our case this messes with the receiver unless we use some custom TX
cards that have an amp we can shut down with ATR.
Is there any way to fix this?
We have a flowgraph that does a full stop, some disconnects and a
restart during its execution. Before the latest UHD version bump, this
worked fine, but now it goes silent after the upgrade without any
apparent failures. Is dynamic reconfiguration now broken- either on
purpose or accidentally?
We have a number of old flowgraphs that take advantage of quadrature
sampling and work fine in USRP1 non-uhd, but once converted to UHD (for
USRP1 and 2), we've been wholly unable to come up with subdev specs that
work- the I and Q are not synchronized in any way and any change in
frequency
I have a loop block that I wanted to run very slow (1Hz), and put a
throttle block set to rate 1. Unfortunately, it seems to tear through
the first 8-9k samples in a blink before it slows down. Is there an
alternative implementation of the throttle block that would work at very
slow speeds?
Lets say you have a GUI app that has a fixed runtime determined by a
head block set to (sample_rate * n_seconds). Currently, the gui keeps
running. Is there an OnShutdown or some function I can override to catch
the flowgraph completion? Worst case, can I set up a loop thread to
check
I have a UHD app I'd like to work with USRP1 and 2- but when I give USRP2:
self.dut_out.set_subdev_spec(A:A A:B, 0)
it complains about the A's and I have to specify :A :B instead, but
for USRP1 it needs the A.
It would be a nice simplification if the USRP2 allowed A:whatever since
it
With UHD, what's the proper way to use the A and B connectors on an LFRX
to get quadrature sampling? I've tried setting subdev spec as A:AB but
it doesn't seem to work with the UHD source at anything other than 0 for
the frequency for both USRP1 and USRP2 via UHD.
I just discovered the not well published --with-fusb-tech=libusb1 option
to configure, hoping to resolve the USRP1 non-uhd crashing issues myself
and one other person are seeing when the flowgraphs do a lock or stop.
Unfortunately, I still see the same lockup, which rules out any
libusb-0.1
On 05/26/2011 09:14 PM, Brett L. Trotter wrote:
On 05/26/2011 08:06 PM, Nick Foster wrote:
On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying
So after discovering that while I had libusb-devel-0.1 and
libusb1-devel-1.0.3 installed on my RHEL-6 machine here (and ubuntu),
gnuradio compiled against 0.1 despite 0.1 being ancient and
unsupported. I then removed libusb-devel and gnuradio fails to configure.
[root@aurora gnuradio]# ls -lad
This is precisely the problem I'm seeing that kills my USB. I have to
ctrl+c to keep that from happening.
On 05/27/2011 12:05 PM, Johannes Schmitz wrote:
I made a simple example to show how it happens.
It is a problem of lock/unlock in combination with usrp.
Like this the lock unlock
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes the USB on the host system to
freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
this
will
yield a very delayed signal on the scope sink. The same problem does not
happen on USRP1 when the sinks are swapped out and the sample rates
adjusted appropriately.
On 05/26/2011 07:29 PM, Brett L. Trotter wrote:
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected
On 05/26/2011 08:06 PM, Nick Foster wrote:
On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes
I discovered today that almost no big retailer (newegg, bestbuy, etc)
except amazon appears to sell 1 GB SD cards any more and 2GB cards are
probably going to be headed that way sooner or later. 2GB cards, while
also overkill on the USRPs, are riskier to buy since some may be SDHC.
What's the
I'm looking for a way to create a block that can find the USRP source
and/or sync in the flowgraph and be able to get to the dboard iface for
doing write_aux_dac and write_io. Bottom line I'd like to write an AGC
block that can manipulate a custom card. Is there a facility for finding
other block
in terms of moving data, but just
provide an instance of some sort of control?
Thanks!
On 05/22/2011 04:09 PM, Brett L. Trotter wrote:
I'm looking for a way to create a block that can find the USRP source
and/or sync in the flowgraph and be able to get to the dboard iface for
doing write_aux_dac
Why/when was variable sink removed? It seems to have been in the last
few weeks.
It's still used in gnuradio-examples/grc/simple/var_sink_taps.grc among
a bunch of places in our own code.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
I did a bench experiment here and observed that set_gpio_ddr is required
on a tx card but not an rx card. Is this intended?
Here is iotest.py (Python 2.5 required for ternary I used)
#!/usr/bin/env python
I2C_DEV_EEPROM = 0x50# 24LC02[45]: 7-bits 1010xxx
I2C_ADDR_BOOT =
I have an application I've been compiling fine against gnuradio for
several years, including recent ubuntu and RHEL-6, until I tried it on
FC14. For some reason, on FC14, it seems like gri_glfsr is
improperly/inadequately defined or not linked properly. Long story
short, after the #include
:: part needed to go. It now compiles fine.
On 05/03/2011 04:49 AM, Brett L. Trotter wrote:
I have an application I've been compiling fine against gnuradio for
several years, including recent ubuntu and RHEL-6, until I tried it on
FC14. For some reason, on FC14, it seems like gri_glfsr is
improperly
Has anyone written a motorola trunk decoder for gnuradio? I'd like to be
able to dump all active audio in a trunk to separate streams by
talkgroup. I'd love to know about any trunk decoders in general.
Thanks!
-Brett
___
Discuss-gnuradio mailing list
Who do we petition to get PyQwt5 included in RHEL-6? It compiles
straightforwardly from Fedora 15 SRPM, so it shouldn't be a problem.
This new build requirement means one can't build GnuRadio with stock
RPMs even on RHEL 6 now otherwise.
___
swig/python detected a memory leak of type 'uhd::usrp::multi_usrp::sptr
*', no destructor found.
Anyone seen this before?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I desperately need to know how to get from a usrp.source_c python object
down to what would be the result of going through
usrp_prims.usrp_open_cmd_interface? Can anyone help?
Thanks!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
I'm sure this has been asked many times, but if you would be so kind as
to offer any hints where to look for solutions or what to test, it would
be much appreciated.
I've got several different flowgraphs here that upon shutting down some
portion of the time, they emit a series of errors and then
Is there one or two books that give a pretty comprehensive, yet low base
communications/DSP knowledge requirement that would be a guided
walkthrough of waves and fields, various forms of modulation, carriers,
filters, sidebands, etc? I'm really looking for something that's either
not a textbook,
I see that http://code.ettus.com/redmine/ettus/projects/public/documents
has the PDFs, but are the PCB/PADS files still around for any of these
boards? If the answer is no, then is open source hardware becoming
open, but we don't want to make it too easy since we make money on
these. If yes, then
The card I'm looking at (an LFRX variant) has the proper checksum in
0x1F (0x17), but then byte 0x20 has 0x04 with the remaining data 0xFF
I previously thought I understood 0x20 began the region where we could
do what we wanted, but I'm now not so sure. If I was going to store some
custom data,
I'd like to record raw broadcast (rx_cfile) with either a USRP1 or USRP2
(have both) but with all samples known to as accurate as the system
clock, preferably millisecond to sub-millisecond accuracy. I considered
writing a block that outputs the number of milliseconds since midnight
as shorts that
Sorry for the delay- I sent this 02/02/11 from an email that's not
subscribed.
On 02/02/2011 04:48 PM, Josh Blum wrote:
On 02/02/2011 12:48 PM, Brett L. Trotter wrote:
gr-usrp has set_tx_freq and tx_freq
uhd has set_center_freq but no get_center_freq or center_freq- I'm
trying to port
gr-usrp has set_tx_freq and tx_freq
uhd has set_center_freq but no get_center_freq or center_freq- I'm
trying to port some USRP1 python code to UHD and there doesn't seem to
be a clear analog.
Have I overlooked something?
Thanks for any input/help!
-Brett
`include ../../firmware/include/fpga_regs_common.v
`include ../../firmware/include/fpga_regs_standard.v
these seem to be absent from the repo obtained here: git clone
git://git.ettus.com/ettus/fpga.git
Where can I find those files?
___
Looks like these files were not moved from gnuradio/usrp.
A symlink in fpga/usrp1 to ../../gnuradio/usrp/firmware seems to do the
trick, but it would be nice if one of the repos had everything necessary.
On 12/13/2010 12:49 PM, Brett L. Trotter wrote:
`include ../../firmware/include
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
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 an up to date fedora 13 x86_64
I just did this:
624 git clone http://gnuradio.org/git/gnuradio.git
625 cd gnuradio
626 git branch --track next origin/next
627 git checkout next
628 ./bootstrap
629 ./configure --enable-docs --enable-grc --enable-gnuradio-examples
On 11/27/2010 11:55 PM, Eric Blossom wrote:
On Sat, Nov 27, 2010 at 11:16:24PM -0600, Brett L. Trotter wrote:
On an up to date fedora 13 x86_64
I just did this:
624 git clone http://gnuradio.org/git/gnuradio.git
625 cd gnuradio
626 git branch --track next origin/next
627
I seem to be having trouble with
gnuradio-examples/python/digital/tunnel.py on a fedora 13 box
complaining with an eng_notation error about any value I put in (eg 10M,
10e6, 1000) for --rx-freq or --tx-freq where the same exact script
(md5 matches) on an ubuntu box works fine. This is the
I've got a laptop here (Acer Aspire 7552G) with 1GB ethernet with the
latest git development copy of gnuradio and UHD, with a USRP2.
On this particular laptop, when I try to transmit anything substantial,
the USRP2 stops transmitting and quits responding, meanwhile the host
keeps sending udp
On 11/09/2010 11:44 PM, Brett L. Trotter wrote:
Does any alteration to code or firmware need to be made in order to get
a USRP2 to lock to an external 10MHz reference?
I'm still looking for more information on this subject, and have some
additional information to add.
We're still in the non
Does any alteration to code or firmware need to be made in order to get
a USRP2 to lock to an external 10MHz reference?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Clarification to last- I see it can be done in Python with UHD, but
without, do I need to put
clocks_mimo_config(*MC_WE_LOCK_TO_SMA*); in clocks.c- perhaps in place
of WC_WE_DONT_LOCK on like 52
or is there a way to do it in python for non UHD?
On 11/09/2010 11:44 PM, Brett L. Trotter wrote
I have UHD built, burned a UHD firmware to SD, the USRP2 pings,
uhd_find_devices is happy- how do I use usrp2_fft.py for instance with
UHD- or do I need to edit the .py files to change the flowgraph for UHD?
Sorry if this has been answered somewhere already.
-Brett
With the -s option on, what is the byte ordering of the output? eg is a
sample 0xABCD being written as 0xCD, 0xAB, or 0xAB, 0xCD?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I'm just now getting to a gnuradio project and hadn't had much of a
chance to dogfood my gnuradio RPM from my repo. Now that I'm getting to
it, all of the examples scripts have #!/usr/bin/env python hardcoded at
the top. I was thinking the build process (which already knows the
appropriate python)
[r...@aurora rng2]# usrp_rx_cfile.py -R A:0 -d 4 -g 18 -f 8M -N 1.5M -s
/tmp/brx_8m_d4_g18_1.5msamples-06-26-10_13-22-37
Using RX d'board A: Basic Rx
USB sample rate 16M
gr_vmcircbuf_createfilemapping: createfilemapping is not available
[r...@aurora rng2]# ls -lh
a while since I've seen that message.
-Brett
On 06/26/2010 05:10 PM, Eric Blossom wrote:
On Sat, Jun 26, 2010 at 12:32:38PM -0500, Brett L. Trotter wrote:
I'm just now getting to a gnuradio project and hadn't had much of a
chance to dogfood my gnuradio RPM from my repo. Now that I'm getting
I know there aren't too many folks toying with RHEL 6 yet, but I've
uploaded gnuradio 3.2.2 RPMS (i386 + x86_64) for RHEL 6 on the new repo.
For info: http://blackopsoft.com/RHEL_6
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
First please let me note that I will not and do not email this list
about the repo except when I have an update pertaining to gnuradio.
When I first started the repo, I was only building packages for x86_64,
but soon after adopted mock and built most of them for i386 as well, but
the sdcc source
I hate to be partly off topic, but I wanted to give an update on the
repository I shared a few days ago.
I created the repository because I've been using RHEL/CentOS for
GNURadio and Octave a long time and wanted to help others do so since it
can be a chore on the slower distributions. Although
checking for xdg-mime... true
checking for Python = 2.5... yes
checking for Python Cheetah templates = 2.0.0... yes
checking for Python lxml wrappers = 2.0.0... yes
checking for Python gtk wrappers = 2.10.0...
^C^C^C^C^C^C^C^C^C^C^C
can't control C either..
this has happened on an ubuntu
]# python -c import gtk
same freeze
Brett L. Trotter wrote:
checking for xdg-mime... true
checking for Python = 2.5... yes
checking for Python Cheetah templates = 2.0.0... yes
checking for Python lxml wrappers = 2.0.0... yes
checking for Python gtk wrappers = 2.10.0...
^C^C^C^C^C^C^C^C^C^C^C
the same.
top doesn't show anything eating up CPU, at all.
Josh Blum wrote:
Thats really bad!
howabout
python -c import pygtk; pygtk.require('2.0'); import gtk
Brett L. Trotter wrote:
Josh Blum wrote:
what does python --version give you?
what happens when you run python -c import gtk
Usually for stuff like compiling and it has worked in the past (even a
few days ago).
You're correct, when I come on with VNC or console, it works fine.
Any idea what broke?
Johnathan Corgan wrote:
On Tue, Mar 17, 2009 at 4:16 PM, Brett L. Trotter br...@webtrotter.com
wrote:
top doesn't
Subversion and www seem to be misbehaving. Is it just me/my connection?
Is there an ETA on revival?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I've got a block that I needed to make a gr_io_signature4 for- unless
I've misunderstood something:
gr_io_signature_sptr
gr_make_io_signature4(int min_streams, int max_streams,
int sizeof_stream_item1,
int sizeof_stream_item2,
int
I'm doing some logging of what time signal events happen and in the
destructor of a custom signal block, I'm printing a log line to a file,
followed by an fflush, but i'm not always getting my line. Is the
destructor not happening, or is something else transpiring?
Is there a way to ensure a
The purpose of this email is to ask if anyone (out of the relatively few
USRP2 users) had happened to bump into this card and had similar
difficulty as well as to determine if this is repeatable on other
systems and thus warn others away from the headache I've encountered.
I've been successful
two interrelated questions here:
1) in a block with minimum output streams = 1 and maximum = 1, do I need
to know if the output stream is not connected and not try to fill the
output buffer at all (or will outputitems be 0?)
and 2) if yes, how do I get a count of the number of connected streams?
Brett L. Trotter wrote:
two interrelated questions here:
1) in a block with minimum output streams = 1 and maximum = 1, do I need
to know if the output stream is not connected and not try to fill the
output buffer at all (or will outputitems be 0?)
and 2) if yes, how do I get a count
Are there any examples of how to use this?
Since the current C++ (until C++0x is out) doesn't support vector
initialization, how does one format the inheritance constructor?
for example:
myblock::myblock(...) : gr_block(myblock, gr_make_io_signaturev(4,4,
std::vectorint somevec)) { ...}
in what
I've got a couple proprietary transmitter and receiver blocks here with
some other custom blocks in the flowgraph, and the problem I'm seeing is
that I seem to be building up a really large buffer of data that hasn't
been transmitted out of the USRP yet. I'm guessing I've missed something
with
I've got a relatively large array of maximal length LFSR masks I'd like
to be able to use, there are of course a different number for each
degree, increasing with the degree.
I forgot that C++ doesn't support jagged arrays like C# so I created
this great little jagged array with the 2nd dimension
I now am encountering a situation where my work function is consuming
all of the inputs trying to search for a match for a particular
condition and does so successfully when the parameters are correct for
the data it is receiving, but if it gets busy looking with the wrong
settings, the callbacks
I have figured it out- the actual callback was occurring, but then the
d_updated wasn't being evaluated in the work function at due to the
aforementioned improper conditions :)
Thanks Eric!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Just FYI:
on the page:
http://gnuradio.org/trac/wiki/Development
the link to the form (http://www.gnu.org/prep/maintain_6.html) appears
to have moved.
http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
is about as close as I could find, though it is not a form in and of itself.
Looking at the gr_file_source code, it doesn't appear that there is a
callback to close the current file and open a new one instead. I have an
application where I'd like to be able to do that. If it's not
implemented in some other way I haven't found, I'd like to implement
this and have done so
I've been having some trouble after upgrading my mail server- I
apologize for any bounces or inconvenience over the last few days and
think the problem is currently resolved.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
I have a rev 2, rev 3 and a rev 4 usrp here. When I plug in either
the 2 or 3 (no serial #) and a 4 and do a lsusrp, both usrp's show
up as one or the other (daughter cards and everything) until I do a
second lsusrp.
Is this a bug? It's no big deal, but I was curious what's causing it.
This is
We're getting tuple out of range when specifying port 1 on either side
for an LFTX board. Specifying -T A:0 or -T B:0 on does seem to work on
several of the transmitter apps we've tried.
[EMAIL PROTECTED] ~]# usrp_siggen.py -T A:0 -f 5M -i 128 --sine -a 16000 -g 0
Using TX d'board A: LF Tx
I may be mistaken, but when I last svn updated off the trunk, boost
1.35+ was required. This is not yet in the Fedora repositories (1.36
beta is in development however) and means building gnuradio with a
standard system is not possible. While one can find the 1.36 src rpm and
build it, it's a bit
this is a worthwhile endeavor.
Thank you for the time.
Eric Blossom wrote:
On Thu, Aug 21, 2008 at 08:50:26PM -0500, Brett L. Trotter wrote:
I may be mistaken, but when I last svn updated off the trunk, boost
1.35+ was required. This is not yet in the Fedora repositories (1.36
beta
Is there a simple way to print out a list of what was connected into a
flow graph?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Eric Blossom wrote:
On Tue, May 20, 2008 at 11:14:18AM -0700, Johnathan Corgan wrote:
On Tue, May 20, 2008 at 11:07 AM, Eric Blossom [EMAIL PROTECTED] wrote:
On Tue, May 20, 2008 at 12:09:27PM -0500, Brett L. Trotter wrote:
Is there a simple way to print out a list of what
I realize that this is not gnuradio traffic specifically, hopfully it
won't put anybody off- I apologize if it does, but I'm desperate!
I'm working with an Altera/Terasic DE2 board trying to get ethernet up
and running with the onboard DM9000a. I've read the manuals backwards
and forwards and I
I think this has been answered in the past, but I couldn't find the
answer- is there a pre-done script to transmit a raw data file directly
as samples?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
I had originally asked Johnathan Corgan about expanding the list called
sbs_to_mm that has the mm mu gain for given samples/symbol to include
higher samples per symbol so that we can use it at very low bitrates. I
don't know who wrote the script in the first place, but Johnathan had
indicated he'd
In 3.03 and before, as opposed to CVS, one could add higher samples per
symbol values to pick_bitrate.py and operate at lower bitrates than 35k.
Currently, gmsk seems to be the only one that works via that method,
dqpsk and dbpsk complain about sbs_to_mm not having an array key for the
particular
I'm working on a self-educational project to replace the simple CRC in
the tunnel apparatus with a very heavy reed-solomon encoding for very
lossy and low-bandwidth links. One thought just occurred to me.
Originally, I was going to group up all of my data in 127 byte blocks,
r/s encode it with a
Brett L. Trotter wrote:
I'm working on a self-educational project to replace the simple CRC in
the tunnel apparatus with a very heavy reed-solomon encoding for very
lossy and low-bandwidth links. One thought just occurred to me.
Originally, I was going to group up all of my data in 127 byte
Got a few good replies on my question about lost bytes. I appreciate the
input, that sounds like it'll work great in conjunction with the error
correction then. I'm hoping to have that in place within the next couple
of hours and start testing.
___
I've made a swig wrapper for some code that needs a char pointer passed
in, how do I do such a thing?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Brett L. Trotter wrote:
I've made a swig wrapper for some code that needs a char pointer passed
in, how do I do such a thing?
Thinking about this more, maybe I need to give more information.
I've wrapped Phil Karn's FEC library and I'm trying to call encode_rs_char:
void encode_rs_char
I've been learning about software defined radio from the ground up and
my maths are a bit shaky and I'm mainly a software guy, so concepts of
signals and whatnot are rather foreign to me. So as I've been reading,
I've taken lots of tangents to review what must seem like completely
elementary
I'd really like to work on the reed-solomon encoding over the weekend
here and unfortunately I can't do so without more information. If anyone
can tell me whether the padding mechanism proposed in my recent email
might work- or how to make it take into account the bits/sample and
samples/symbol,
I'm involved with very lossy links and low signal strengths using gmsk
and dqpsk and would like to add a layer of reed-solomon encoding in
place of the current CRC check.
My plan was to use reed solomon in a standard (255,223) configuration
and use PKSC#7 padding in 223 byte blocks where the last
The gnuradio build guide for fedora should be updated since the latest
trunk requires guile-devel to be installed as well.
Is there a way for average joes to update the trac wiki?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Is there a way to know or log (in the verbose logging) the maximum
received strength of a packet- or running max perhaps over a period of a
few seconds? I'm trying to measure it with a scope and coming up short-
I think I have some faulty hardware in the loop here, but that's what
I'm trying to
Eric Blossom wrote:
On Thu, May 03, 2007 at 07:27:33AM +1000, stevie.glass wrote:
Hi
I've a rev 3 USRP which has the Flex2400 and TVRX daughtercards installed.
At one time the setup worked well - altho I've let it lie a while. This
week I've swapped out a TVRX and replaced it with the
In looking for particular frequencies which can successfully transmit across a
particular medium or antenna, I've spent days running benchmark_tx on one side
and benchmark_rx on the other (two separate machines). I've got an ethernet
connection between the two machines, so it is a matter of
What is the current status of the OFDM project? Is it such that I could
give it a try using a tunnel.py type setup over a shared wireline - or
at least over two separate RX/TX wires?
Last I heard the receiver and transmitter were working but not over the air.
Trond Danielsen wrote:
I read in an earlier thread that you want to do the (I)FFT processing
in the FPGA. This is not how it is intended to be used. GNU Radio is a
software radio framework, and the goal is to move as much of the
signal processing as possible onto the host computer. Moving the
Johnathan Corgan wrote:
Johnathan Corgan wrote:
There is an alternative that Eric and I have conceived that would be
a temporary workaround. It would not solve the original problem but
would at least allow upper level protocols that do re-transmission to
recover from the failure. I'll
Daniel O'Connor wrote:
On Thursday 18 January 2007 21:31, Brett Trotter wrote:
I realize ssh probably isn't the best thing to test with, but it happens to
be a quick and easy way to test file sending. The question is, is our
tunnel acknowledging corrupted packets instead of asking for
I've got two machines with one usrp each using basic tx/rx board pairs.
As soon as I start tunnel.py on each and set the ip's, one machine
(usually the one started second) starts showing B.
If i disconnect wires, both sides go silent, reconnect and one or both
start showing
Eric Blossom wrote:
On Thu, Jun 22, 2006 at 03:32:10PM -0500, Brett L Trotter wrote:
I've got two machines with one usrp each using basic tx/rx board pairs.
As soon as I start tunnel.py on each and set the ip's, one machine
(usually the one started second) starts showing B
Paying more attention to your message this time, our intent is to use
the LFTX/RX boards.. Is there any way to make it work with those as that
is our target frequency range?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
I've got a properly encoded wav file (48khz, 16bit) that I need to
transmit over the USRP- does anyone have a file sink type python script
that should work for Digital Radio Mondial given the wav file?
___
Discuss-gnuradio mailing list
1 - 100 of 113 matches
Mail list logo
