I just sent an email regarding the first meetup planning to those that
had expressed interest. If I missed you, please send me a email and
I'll add you to the email discussion.
--Eric
On 04/10/2014 11:26 AM, Eric Schneider wrote:
Is anyone doing a GnuRadio / SDR meetup in the Denver
I'm not sure how the GSOC thing works, but if there is anything I can do
to help make this project happen, let me know!
This very idea has been on my "some day" shelf for far to long...
--Eric
On 03/13/2014 11:41 AM, MITUL VEKARIYA wrote:
Hi
Here's the link for my proposal for the project "Ve
Is anyone doing a GnuRadio / SDR meetup in the Denver Area?
If not, is anyone in the area interested? First beer is on me. :-)
--Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I hope this isn't bad form for the lists, but this skill set is proving
difficult to find through other channels.
Is there a good place to find people with GnuRadio / UHD / Ettus
hardware experience?
And if you are available for consulting, please contact me!
I'm looking for multiple persons
I would like to be able to send a continuous stream of tx packets, each
with a timestamp, such that if one is dropped, the next will be
transmitted at the correct time. My use case involves CDMA test signal
generation, and currently a dropped packet causes a total loss of sync
on the test devices (
Oh cool! When was that implemented? I missed it...
I assume there is no problem with timeout = 0?
Is the interface thread safe? read/write/recv_async?
--Eric
On Thu, 2010-09-02 at 13:23 -0400, Josh Blum wrote:
> See recv async message:
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1d
I have forked the Ettus github repo (usrp-fpga-mirror) and added a
branch with my alternate rx-buffer / timestamp fixes.
git://github.com/etschneider/usrp-fpga-inband.git
Use the 'ets-inband' branch, I'm leaving master to follow the Ettus
upstream.
If anyone uses it, please let me know.
--Eric
On Thu, 2010-08-12 at 23:25 +0200, Sylvain Munaut wrote:
> Unfortunately :
>
> Error (10663): Verilog HDL Port Connection error at
> rx_buffer_inband.v(273): output or inout port "num_packets" must be
> connected to a structural net expression
>
> And altough I'm fluent in VHDL, I have no idea a
On Thu, 2010-08-12 at 17:14 +0200, Sylvain Munaut wrote:
> Mmm, in the code I've read, the tx timestamp counter was different than
> the rx timestamp counter and with different reset signals.
This is all from memory...
There were two clocks, but the resets should have been tied together.
If the
Correction: As Brian stated, I think 0x is the correct "NOW"
timestamp.
On Thu, 2010-08-12 at 09:08 -0600, Eric Schneider wrote:
> Sylvain -
>
> On Thu, 2010-08-12 at 14:27 +0200, Sylvain Munaut wrote:
>
> > - How can I know the 'current'
Sylvain -
On Thu, 2010-08-12 at 14:27 +0200, Sylvain Munaut wrote:
> - How can I know the 'current' TX timestamp ? I want to send a ping
> command, but I don't see a way to know what timestamp I should use.
It is in the header of every Rx packet. If you need to send a command
without knowing t
Josh,
as far as I know, I was the last one to work on the "inband" firmware.
I used it extensively for a project I was working on and didn't have
problems with it, but more testing would be warranted before considering
for the default firmware. (Which I would like to see)
As to the rationale for
On Sun, 2010-06-13 at 08:12 -0700, Damien S. wrote:
> Hi all,
> I'm trying to use the external clock input of the usrp2 with WBX in receive
> mode. Unfortunately after processing the recorded signal there is still a
> clock drift despite the fact i'm using a GPS reference clock. So i suppose
> that
Damien,
I use:
Clock Source
usrp2_clock_src
usrp2.MC_WE_DONT_LOCK
enum
Internal
usrp2.MC_WE_DONT_LOCK
On Fri, 2010-04-23 at 14:58 -0400, Marcus D. Leech wrote:
> Anyone know of any reasonably-priced network analysers, up to 2 or
> 3GHz? Basic S21 and S11
> measurements would be a good start.
I've been contemplating trying such a thing using using a WBX
daughterboard. It hasn't got past the "ta
irmed that timestamps to the host are not
> jumping in any manner when there is no overrun, and have you confirmed
> that timestamps are being treated properly when trying to transmit?
>
> Thanks a bunch for updating this code.
>
> - George
>
>
> On Tue, Jan 26, 201
Echoing some feedback to the list...
On Mon, 2010-01-25 at 08:47 -0700, Eric Schneider wrote:
> 1. I do not intent to implement VRT over USB. Only to implement a VRT
> compatible interface on the host. The USB inband protocol will simply
> serve to make that possible in the most effi
I'm not aware of an existing way to do this on the USRP1. A function
similar to the USRP2 pps input (and start_streaming_at or at least
inband timestamps) would be required. In addition to a shared clock of
course.
Perhaps this would make a good addition for a future inband FPGA
revision. Is an
What is available?
I am trying to figure out how to accomplish some level of time
coordination between inband timestamps on the FPGA and the daughterboard
communication via the FX2.
Exact sample clock precision isn't expected and just a predictable
latency channel might do.
Can the FX2 peek/in
Hi all, I'm looking to be doing some more rework of the USRP1 inband
code, specifically to align with the USRP2 VRT work.
For those not familiar, USRP1 inband allows for timestamped rx/tx
samples (and commands), which is very useful for TDMA type systems. It
is a separate FPGA configuration and
On Thu, 2010-01-21 at 13:50 -0800, Matt Ettus wrote:
> On 01/21/2010 12:40 PM, Eric Schneider wrote:
> > Linearity does seem to be an issue above 0.1 or so, based on the
> > intermod products I'm seeing.
>
>
> Well, it depends on what you mean by "issue".
On Wed, 2010-01-20 at 18:11 -0800, Matt Ettus wrote:
> Because 0.2 amplitude doesn't clip. On a typical 1800, it will start to
> clip somewhere around 0.5 to 0.6, and a typical 2400 will be much closer
> to 1.0. But in any case, you want to back off on the power to get the
> linearity you need
On Sat, 2010-01-16 at 10:57 -0800, Matt Ettus wrote:
> On 01/16/2010 10:46 AM, Eric Schneider wrote:
> > Just out of curiosity, was there a design decision made to not use the
> > DAC PGAs to adjust Tx gain?
>
>
> The issue is that changing the DAC PGA not only
Just out of curiosity, was there a design decision made to not use the
DAC PGAs to adjust Tx gain?
On Sat, 2010-01-16 at 09:08 -0800, Josh Blum wrote:
> On 01/16/2010 01:36 AM, amarnath alapati wrote:
> > hi friends,
> > When I tried to print the Transmitter gain range by the following
> > com
On Mon, 2009-12-21 at 15:31 -0800, Jung Il Choi wrote:
> Does anyone has any clue/suggestion? I am using Ubuntu 8.04 with the
> kernel 2.6.24-21, and using D-Link DGE-560T gigabit pci-express adapter.
I had the same problem (same card) on Ubuntu 8.10. I have since
upgraded to 9.10, and rebuilt
FYI, the current development/master branch in the git repo has Johnathan
Corgan's work-around which solved my issue.
$ git clone http://gnuradio.org/git/gnuradio.git
(build as usual)
--ETS
On Sun, 2009-12-13 at 10:40 -0700, Eric Schneider wrote:
> I've been testing wi
I've been testing with a USRP2 by streaming a data file along with some
trivial type conversions. I receive several of the following errors:
usrp2::tx_raw: FIXME: short packet: 1 items (32 bytes)
I am running an up-to-date 3.2 branch build (which has EB's fragmenting
work around).
I noticed a c
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> If it's coming from two different parts of the chip with two
> independent reset signals, then yes there is always suspicion that
> they are unaligned.
I didn't realize there were different resets. It should be change
> -Original Message-
> From: George Nychis [mailto:[EMAIL PROTECTED]
> I'm not sure what code you started from, Eric S. ... I had mentioned I
> had some fixes in my own developer branch, one of which was making sure
> there was only 1 counter:
> http://gnuradio.org/trac/changeset/8987
> htt
> -Original Message-
> From: George Nychis [mailto:[EMAIL PROTECTED]
>
> Just going to chime in here with nothing really too important, because
> this isn't really my area. But, I am trying to follow discussion here,
> and I appreciate you working on this Eric.
>
> As for your segmentati
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
>
> No. It just seems silly to have a hard wrapper (fifo_1kx16_dc_la) for
> a generic wrapper (dcfifo). It would be nice if there was an
> identification of the different FIFOs and made those aspects generics
> to a t
Thanks for the input Brian. A few comments inline.
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 08, 2008 7:58 AM
> To: Eric Schneider
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] FPGA / new rx_buf
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 07, 2008 3:03 PM
> I am disappointed by the prioritization scheme for the channels and
> would have rather seen a more fair round-robin approach instead of a
> priority encoder.
Man, tough cro
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 07, 2008 7:21 AM
>
> Were these results for the 2 channel mode?
>
> What is the size difference within the USRP when using 2 channels? Is
> it significant or pretty insignificant?
They were f
For those interested,
I've committed my changes to the inband RX buffering subsystem. It is
available at:
http://gnuradio.org/svn/gnuradio/branches/developers/ets/inband/usrp/fpga
Source only at the moment, I'm not sure of the policy for RBFs in dev
branches.
Caveat emptor. The m
Arg. Ok, so the RD counter is cleared along with a drop of RD too. So I
guess I can assume that RD must be cleared for at least one cycle between
packets? Maybe some fresh air would be a good idea too. :-)
--ets
> -Original Message-
> From: Eric Schneider [mailto:[EMAIL PRO
The new rx_buffer_inband.v is very nearly complete.
The FX2/USB interface code refers to a "FX2 Bug Fix" or "257 Bug Fix" in the
non inband rx_buffer. I'm assuming that this bug is that the FX2 keeps the
RD line set for 257 usbclk cycles instead of 256. The coded fix is a 256
step counter preven
I'm a bit confused by the communication signals between the rx and tx inband
buffers. Maybe it's the names that are throwing me. Can anyone help
explain the design?
Inband communication signals (from rx buffer):
input [15:0] rx_databus //data from inband_tx
input rx_WR
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
>
> You're generating significantly less muxing at the interface to the
> FX2. In the pull design, you have 2 muxes per channel and at least 2
> channels (one control, one data). Increasing the number of channels
> gr
Thanks for the comments Brian, my replies are inline.
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 26, 2008 11:41 AM
> Maximum throughput for 16-bit IQ is a decimation by 8, so 6 clock
> cycles for header setup should be fine. Even for dec
design docs for the new stuff...
--ets
> -Original Message-
> From: George Nychis [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 23, 2008 4:20 PM
> To: Eric Schneider
> Cc: discuss-gnuradio
> Subject: Re: [Discuss-gnuradio] inband timestamp issues
>
> Hi Eric
Okay, so to elaborate on the design options a little more...
I see to primary topologies: packet push, and packet pull. Both designs
have a slimmed down packet_builder for each channel. The multichannel
multiplexing would be similar in either design.
### Packet Push:
Packet buffers only, packe
Regarding the rx_buffer design, is there a reason that there are two FIFO
stages in the current design? I seems that one layer of FIFOs should do.
Either on the channel side or the fx2 side, before or after packet building,
either should work. I haven't decided which I prefer, maybe I'll have
som
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 21, 2008 3:09 PM
> What do you think of those ideas? Do you have a proposed solution?
>
> Brian
Of the two, I would prefer the rollover flag solution.
If we are willing to put limit on how
Just thinking out loud here...
Given your suggested solution (which I like):
N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1 FIFO MUX
-> FX2 USB Interface
The FIFO MUX could be a module that implements a virtual FIFO output, and
automatically selects (and emulates) the input FI
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
>
> On Thu, Aug 21, 2008 at 3:11 AM, Eric Schneider
> <[EMAIL PROTECTED]> wrote:
> > 1. Is it true that there are N RX Sample FIFOs? It seems that the
> channels
> > are already muxed by the time they get to the pa
Hi all, I'd really like to help with this. I've been pouring over the
design (usrp_inband_usb), so my brain is a little mushy at the moment,
hopefully I'm not totally off track here.
1. Is it true that there are N RX Sample FIFOs? It seems that the channels
are already muxed by the time they ge
I was bit by this as well. In my case I get the AttributeError error if
config.conf is missing or has a typo ("type=nogl"). A present and correct
config.conf works fine.
-Original Message-
From: Johnathan Corgan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 10:04 AM
To: Firas
48 matches
Mail list logo
