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? Has
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 changes
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? Perhaps
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 tb.is_running
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 techn
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 possibi
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.
_
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 disco
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
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
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
>> d
unt decimation 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 USR
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 pr
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 long
for blocks that
aren't really part of the flowgraph 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 flo
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 i
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
http
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 = (I2C_DEV_EE
glfsr:: 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 seem
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 , I can
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
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
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.
___
Discuss-gnur
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
http://lis
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 t
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, th
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, or
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, wh
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_ce
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
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 "../../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?
___
Discuss-gnu
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,
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
__
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 co
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
>
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
--enable-gr-ut
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 lates
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 datag
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.
W
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
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
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
f message- thanks
for clearing that up, its been 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
[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 /tmp/brx_8m_d4_g18_1.5msamples-06-
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)
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
http://lists.
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 r
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 I'
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
> wrote:
>
>
>> to
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
ython --version
Python 2.5.2
[r...@evo2 gnuradio]# 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 f
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 i
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 s
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 destr
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 wit
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
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?
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::vector somevec)) { ...}
in what c
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 rega
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 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
htt
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 f
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 suc
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
http://lists.gnu.or
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 th
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
[EM
obviously 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 t
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 o
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 o
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
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 don
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
http://lists.gnu.org/mailman/listinfo/dis
I had originally asked Johnathan Corgan about expanding the list called
sbs_to_mm that has the m&m 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 v
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.
___
Disc
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
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 25
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 t
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
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'
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 concep
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 N
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
http://lists
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 dia
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
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 sshi
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
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.
Johnathan Corgan wrote:
> Brett L. Trotter wrote:
>
>
>> Yay- congratulations- transferred 100MB successfully and all of my
>> 'stumbler' packets- even with UDP.
>>
>
> You're using FSP (which goes over UDP), correct? FSP has a retry
>
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.
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 f
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
http://lists.gnu.o
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 t
1 - 100 of 118 matches
Mail list logo
