Eric,
> Tx timing Ref Pt
>|
>v
> USB --> buffers ---> DSP pipeline --> DAC
>
> USB <-- buffers <--- DSP pipeline <-- ADC
>^
>|
> Rx timing Ref Pt
I definitely see why the reference point for
On Tue, Aug 26, 2008 at 07:38:47PM -0500, Ketan Mandke wrote:
> The timestamp for packets should corrsepond to the
> time when the first sample in the packet is actually "strobed" off the
> ADC. This would also insure that the two channels on the board would
> have synchronous timestamps (i.e. if
> I prefer the packet pushing idea, but feel free to do what you feel is
> the better idea.
I agree with Brian. The push functionality is a better way to go. In
particular, I think it would insure a more "correct" operation for the
receive timestamps. The timestamp for packets should corrsepond to
> -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
On Tue, Aug 26, 2008 at 3:21 PM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
-- snip --
> What do you see as the advantage of the push design?
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 co
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
On Tue, Aug 26, 2008 at 12:03 PM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
> 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
> multiple
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
r
Cc: [EMAIL PROTECTED]
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Hi Eric,
Thanks for your interest! Sorry for a small response, but I'm about to
head to bed and I'm out of town for a conference.
Go to 'usrp/host/apps-inband/' and modify test_usrp_inband_rx.cc to add
t
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
On Thu, Aug 21, 2008 at 08:21:34PM -0600, Eric Schneider wrote:
> > -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
>
> 2^31, or ha
> -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
Brian Padalino wrote:
Another solution would be to have a "rollover" flag which tells the
FSM to first wait for a rollover before checking the timestamp. This
flag could be set by the host when it detects a rollover in timing. I
don't know if the host keeps track of the last transmission time
On Thu, Aug 21, 2008 at 5:04 PM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
> 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
On Thu, Aug 21, 2008 at 4:27 PM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
> I'm assuming that at least some of the rx timestamp inaccuracy is due to the
> variable latency introduced by the rx_chan_fifo(s). If usedw represents the
> number of samples currently in a FIFO, then the actual timestamp
iscuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] inband timestamp issues
>
> On Wed, Aug 20, 2008 at 6:45 PM, Steve Peters <[EMAIL PROTECTED]>
> wrote:
> >> As a non-hardware person, I was thinking that a simple solution is
> to not
> >> really use the cloc
> 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 packet_builder, no?
>
> The packet
Steve Peters wrote:
The current inband RX chain looks like:
N RX Sample Streams -> N RX Sample FIFOs -> 1 Packet Builder -> 1
USB FIFO -> FX2 USB Interface
What it should look like (in my opinion):
N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1
FIFO MUX -> FX2 USB In
> The current inband RX chain looks like:
>
>N RX Sample Streams -> N RX Sample FIFOs -> 1 Packet Builder -> 1
> USB FIFO -> FX2 USB Interface
>
> What it should look like (in my opinion):
>
>N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1
> FIFO MUX -> FX2 USB Interface
On Thu, Aug 21, 2008 at 3:11 AM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
> 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
er.v:145)
4. I wholeheartedly agree that it would be nice to have a "read N samples at
time T command".
--ets
-Original Message-
From: Brian Padalino [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 5:12 PM
To: Steve Peters
Cc: discuss-gnuradio@gnu.org
Subject: Re:
On Wed, Aug 20, 2008 at 6:45 PM, Steve Peters <[EMAIL PROTECTED]> wrote:
>> As a non-hardware person, I was thinking that a simple solution is to not
>> really use the clock on the RX directly, but timestamp packets indirectly.
>> You have a signal when the sample buffer is empty, when that signal
> As a non-hardware person, I was thinking that a simple solution is to not
> really use the clock on the RX directly, but timestamp packets indirectly.
> You have a signal when the sample buffer is empty, when that signal is
> de-asserted for the first time, read the clock and take this as your i
George,
The timestamp semantics that we are using on the USRP2 is that for Rx,
the timestamp refers to the time that we clock the sample out of the
DSP Rx pipeline (n.b., not the Rx FIFO). For transmit, it's the time
we clock the sample into the TX pipeline (not the Tx FIFO). In both
cases, t
Thanks Brian!
Brian Padalino wrote:
Just to clarify the situation - the current packet_builder is hooked
up after the sample buffers so as it is building one packet, it cannot
build another. That is why when 2 channels were used, they would be
received 270+ samples from each other as that is ar
On Mon, Aug 18, 2008 at 04:54:20PM -0700, George Nychis wrote:
> Okay, more on topic with the original problem: the timestamp issues. The
> problem that Steve noticed was that the timestamps jump.
>
> Brian and I wrote a testbench for this and found that the timestamp
> actually does not really c
On Mon, Aug 18, 2008 at 7:54 PM, George Nychis <[EMAIL PROTECTED]> wrote:
> Okay, more on topic with the original problem: the timestamp issues. The
> problem that Steve noticed was that the timestamps jump.
>
> Brian and I wrote a testbench for this and found that the timestamp actually
> does not
Okay, more on topic with the original problem: the timestamp issues.
The problem that Steve noticed was that the timestamps jump.
Brian and I wrote a testbench for this and found that the timestamp
actually does not really correspond to the first sample (per the design
doc), and not quite the
Hi Steve,
We certainly appreciate the work you've done (along with Thibauld et
al.) towards the inband functionality!
Thanks! It's been a major group effort along with Eric, Thibaud, Leo,
and Brian.
Anyway, we've found a solution that seems to work, although I'm having
troubles testing
Hi again George,
> 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 cod
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
> 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
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
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
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
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.
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()
Eric Blossom wrote:
On Tue, Jul 22, 2008 at 05:59:17PM -0500, Ketan Mandke wrote:
My colleague Steve and I have been working with the inband receive
code in an effort to understand how the timestamps work. Specifically,
we have been printing the timestamps from the usrp_rx block while
running
On Tue, Jul 22, 2008 at 05:59:17PM -0500, Ketan Mandke wrote:
> My colleague Steve and I have been working with the inband receive
> code in an effort to understand how the timestamps work. Specifically,
> we have been printing the timestamps from the usrp_rx block while
> running test_usrp_inband_
My colleague Steve and I have been working with the inband receive
code in an effort to understand how the timestamps work. Specifically,
we have been printing the timestamps from the usrp_rx block while
running test_usrp_inband_2rx.cc in usrp/host/apps-inband. There is
some puzzling behavior that
41 matches
Mail list logo
