[Discuss-gnuradio] Question about sampling colored image with TVRX

[Nan Zhang]

Hi,

I tried to sample NTSC signal with decimation rate = 8 (8Msps) using TVRX
board. The 8Mspc sample rate is supposed to covered the whole range of 6MHz
TV channel bandwidth. Thus, the obtained signal should contain all TV
information including luminance and color. I have two related questions:
1. For TVRX board, as we know, the output signal is a 6MHz chuck. But in
which band is this 6MHz bandwidth located? For example, if the carrier
frequency is 477.25MHz, is the output signal from 477.25-1.5MHz to
477.25+4.5MHz, or from 477.25-3MHz to 477.25+3MHz, or in other band?
2. I analyzed the frequency response of the sampled signal, and found there
are two peaks in spectrum. A higher peak is located in DC frequency. Another
one, which is a little bit lower, is located at roughly f = 2.5MHz. It is
different from what I expected. My original thought is that the second peak
should be in f=3.58MHz which is the frequency of the subcarrier carrying
color information. Could someone help to explain this?

Thanks,
Nan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] boost 1.35

[Brett L. Trotter]

I apologize for missing the announcement. I'm guilty of filtering out
most of the stuff that doesn't pertain to my application :)
SMP is a very good thing. My question was mainly if this was an
accidental dependency, did we really want to be using non-mainstream
software in the core, but 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 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 of a hassle. I updated the trunk not expecting any
>> major changes in the last week-ish and now have to make it work. Is
>> there anything truly requiring 1.35? If not, 1.33 would be much preferred.
>>
>> 
>
> I announced more than 2 weeks ago that boost 1.35 was going to be
> required, and that then was a good time to do something about.
>
> Directions on building from source are in README.building-boost.
> It takes about 5 minutes to build the part we need, and it can coexist
> with the already installed version.
>
> And yes, we need it.  I didn't just randomly introduce what I know to
> be a problematic dependency.   Do you want SMP support?  :-)
>
> If this is inconvenient for you, there are two other options:  
> the 3.1 stable branch or the tarballs.
>
>   $ svn co http://gnuradio.org/svn/gnuradio/branches/releases/3.1
>
>
> Meanwhile, we're charging ahead on the trunk!
>
> Eric
>   

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

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
something more insightful to say tomorrow...

--ets





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] boost 1.35

[Eric Blossom]

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 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 of a hassle. I updated the trunk not expecting any
> major changes in the last week-ish and now have to make it work. Is
> there anything truly requiring 1.35? If not, 1.33 would be much preferred.
> 

I announced more than 2 weeks ago that boost 1.35 was going to be
required, and that then was a good time to do something about.

Directions on building from source are in README.building-boost.
It takes about 5 minutes to build the part we need, and it can coexist
with the already installed version.

And yes, we need it.  I didn't just randomly introduce what I know to
be a problematic dependency.   Do you want SMP support?  :-)

If this is inconvenient for you, there are two other options:  
the 3.1 stable branch or the tarballs.

  $ svn co http://gnuradio.org/svn/gnuradio/branches/releases/3.1


Meanwhile, we're charging ahead on the trunk!

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[Eric Blossom]

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 half the counter range would provide a 32s range, and should be
> (way) more than enough.  The host can delay longer before sending the packet
> if longer delays are required.
> 
> The basic logic would be to check the delta, and if greater than 2^31, then
> make go/wait/drop decisions assuming a wrap is involved.
> 

Yes.  If it looks like it's more than 2^31 away, then it's late.
Drop it and report an error.

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

> -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 far ahead we can schedule then we
should be able to decide implicitly if a wrap has occurred.  

2^31, or half the counter range would provide a 32s range, and should be
(way) more than enough.  The host can delay longer before sending the packet
if longer delays are required.

The basic logic would be to check the delta, and if greater than 2^31, then
make go/wait/drop decisions assuming a wrap is involved.

--ets




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] boost 1.35

[Brian Padalino]

On Thu, Aug 21, 2008 at 9:50 PM, Brett L. Trotter <[EMAIL PROTECTED]> 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 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 of a hassle. I updated the trunk not expecting any
> major changes in the last week-ish and now have to make it work. Is
> there anything truly requiring 1.35? If not, 1.33 would be much preferred.

Eric stated that the new SMP scheduler requires it.

He also posted install directions here:

http://gnuradio.org/trac/browser/gnuradio/trunk/README.building-boost

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] boost 1.35

[Brett L. Trotter]

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 of a hassle. I updated the trunk not expecting any
major changes in the last week-ish and now have to make it work. Is
there anything truly requiring 1.35? If not, 1.33 would be much preferred.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[George Nychis]

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 or
who would be responsible for setting the flag.  Maybe it's getting a
bit complicated?

What do you think of those ideas?  Do you have a proposed solution?



I was thinking about this problem when writing the TDMA MAC.  I like the 
rollover flag idea much better than the assumption everything will be 
transmitted.  It's very easy for the host to detect and set a bit like 
this.  The host is generating the timestamps, and can easily tell 
something like this.


But, I'd say lets take care of the RX issue first...

- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

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 implements a virtual FIFO output, and
> automatically selects (and emulates) the input FIFO based on fullness, so
> that the fullest FIFO always gets read first.  A tie would default to
> natural ordering.  There should also be a minimum size (128?) or a
> channel_ready input to prevent premature FX2 transfer.  Sounds pretty simple
> and should just drop-in to the existing design.

There is already a FIFO which has the master_clock on one side, and
the FX2 on the other side.  I was thinking we connect the output of
the packet_builder to those FIFOs.  They already have a have_pkt
output which can be fed into the FIFO mux.  The mux can cycle through
the have_pkt signals of each of the FIFOs without giving precedence to
one or the other and signal the FX2 there is a packet ready to
transfer - muxing the USB data lines for the DMA transfer.  I believe
this is similar to what you're talking about, but I also think the
packet_builder has to have some changes since it is not a streaming
module.

Ideally I'd like to see the packet_builder turn into something that
just inserts headers at the appropriate times in the stream and can
have a mechanism to build an indefinite number of packets (infinite
receive) or a specific number (possibly a 16 or 32-bit count?).

> What about moving the Packet FIFO into packet_builder?  It seems like we are
> just be wasting cycles by pushing headers to an external FIFO when we could
> handle that with some read logic.  In this way, the first "FIFO" reads from
> packet_builder actually output internally generated/stored header values,
> then later the internal FIFO with the channel data.  But maybe it's more
> trouble than it's worth.
>
> --ets

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

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 of the
> sample read out of the fifo is current_timestamp - usedw, correct?
>
> I do think that building the packets before buffering is a better idea, but
> adjusting the timestamps might be a quick interim fix.

I think doing the actual fix is better than doing some interim one.

> If timestamp_clock is near its max (every ~67s), and a packet is scheduled
> such that its future time will cause wraparound (making it a smallish
> number), then the reader will detect that pkt_timestamp < timestamp_clock
> and discard the packet even though in a "few" ticks timestamp_clock would be
> 0 again.

Right - looking at the code, I don't think the logic is there and a
testbench probably should be written to verify the problem/make sure
it works properly anyway.

One idea is that it may be OK to assume that packets will never be
delivered out of date and to always transmit and never drop.
Unfortunately, if one expired packet is delivered, it will be an
entire rollover before it gets back to transmitting - stalling the
pipe for quite a long time.

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 or
who would be responsible for setting the flag.  Maybe it's getting a
bit complicated?

What do you think of those ideas?  Do you have a proposed solution?

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

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 FIFO based on fullness, so
that the fullest FIFO always gets read first.  A tie would default to
natural ordering.  There should also be a minimum size (128?) or a
channel_ready input to prevent premature FX2 transfer.  Sounds pretty simple
and should just drop-in to the existing design.

What about moving the Packet FIFO into packet_builder?  It seems like we are
just be wasting cycles by pushing headers to an external FIFO when we could
handle that with some read logic.  In this way, the first "FIFO" reads from
packet_builder actually output internally generated/stored header values,
then later the internal FIFO with the channel data.  But maybe it's more
trouble than it's worth.

--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: [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 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
> initial
> >> RX clock time.
> >>
> >> Now, you go by the fact that you're sampling at a constant rate and
> >> timestamp packets based on that.  The next packet gets timestamped
> at
> >> last_timestamp + 126samples_per_packet * decimation_rate.
> >>
> >> That way you're not timestamp on packet building, but logically the
> time the
> >> first sample of the packet arrived at the RX buffer.
> >
> > Correct me if I misunderstand, but you're not actually clocking
> > anything this way.  Theoretically it should work, but there's nothing
> > telling me there weren't actually a million clock cycles between two
> > packets.  There should definitely be a timestamp clock tied to the
> > master clock, in my opinion.
> >
> > Ketan and I discussed a couple possibilities earlier today.  One
> might
> > be to have a timestamp buffer in parallel with the RX FIFO.  Although
> > problems arise with making sure the timestamp changes at the border
> of
> > packets, unless there is one timestamp per sample, which is almost
> > certainly too excessive.
> >
> > Another idea is to move the FIFO to the other side of the packet
> > builder, as long as the packet builder can keep up with the
> > ADC/decimator output.  It then outputs to the buffer.  This was
> > Ketan's idea, so I apologize if I'm communicating it incorrectly.
> 
> 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
> 
> I believe the TX chain looks more like this, except with the arrows
> going in the opposite direction.
> 
> On a side note, it might be interesting to have a command that can
> turn on the receiver and receive a specific number of inband packets.
> For example, if you know you may be receiving a transmission that is
> only 2ms long in a specific slot, it might be beneficial to only
> schedule 2ms (+/- a guard time) worth of samples to be delivered to
> the host, freeing up more CPU cycles for signal processing and using
> the USB bandwidth a little more efficiently.
> 
> Comments or suggestions?
> 
> Brian
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] NICE, mp schedule and stand alone library

[Marcus Leech]

Indeed.  I'm running my radio astronomy code on the latest build with
SMP support, and it's working really well.  I can now run
  two different daughtercards with my RA code, sucking in 8Msps each,
with 8-bit samples, and some fairly hairy processing.
 
This is awesome!
 
[Need to sneak the receiver into work where I have a quad-core Q6600
that's largely idle!]



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bob McGwier
Sent: Thursday, August 21, 2008 4:14 PM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] NICE, mp schedule and stand alone library



The new check-ins with the full scheduler support for SMP machines, the
ability to write code that calls libgnuradio.so, and also runs the USRP
and other hardware from C++ is really awesome work.   This is all pretty
breathtaking in its scope and impact.

 

THANKS!!

 

Bob

 

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow   Hurdle the dead"

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

> 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 builder itself actually does the muxing: 
> 
> http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_li
> b/packet_builder.v

I only see one chan_fifodata input to packet builder:

http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/pac
ket_builder.v#L8

It would appear that the muxing is between the fifos and the packet builder
at:

http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/rx_
buffer_inband.v#L205

Not a big difference, but it might make your "N Packet Builders" solution
that much easier.


> The N RX sample FIFOs are built here:

I was looking at RTL schematics on a 1Rx1Tx configuration, which oddly
enough only has 1 RX FIFO, go figure!  *blush*
 
> > 2. Can we just subtract the FIFO size (usedw?) from the timestamp in
> the
> > packet builder?
> 
> Sure, but what for?  I suppose I am not sure what this is addressing?

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 of the
sample read out of the fifo is current_timestamp - usedw, correct?

I do think that building the packets before buffering is a better idea, but
adjusting the timestamps might be a quick interim fix.

> > 3. When checking timestamps for expired command/data packets, is an
> > overflow/wraparound on the timestamp_clock handled?  (ref
> cmd_reader.v:107,
> > chan_fifo_reader.v:145)
> 
> I don't think it's explicitly being taken care of, but I am also not
> sure if the logic just ends up working out.  This should probably be
> looked at and a testbench written.
 
If timestamp_clock is near its max (every ~67s), and a packet is scheduled
such that its future time will cause wraparound (making it a smallish
number), then the reader will detect that pkt_timestamp < timestamp_clock
and discard the packet even though in a "few" ticks timestamp_clock would be
0 again.

> > --ets
> 
> Brian

--ets



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] NICE, mp schedule and stand alone library

[Bob McGwier]

The new check-ins with the full scheduler support for SMP machines, the
ability to write code that calls libgnuradio.so, and also runs the USRP and
other hardware from C++ is really awesome work.   This is all pretty
breathtaking in its scope and impact.

 

THANKS!!

 

Bob

 

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow   Hurdle the dead"

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using two USRPs in one computer

[JUAN LARA AMBEL]

Hi all,

I've got two USRP from Ettus Research. After having mounted both individually 
with success, i'm trying to connect both of them to my PC via two
different USB plugs; just to run comfortably some experiments prior setting up 
a larger testbed.

I've browsed the mailing list archives back to a post on Thu, 9 Aug 2007 
11:31:54, where is suggested to let the 'usrp.source_c' Python function know
which usrp we're addressing, i.e. invoking something like:

src1 = usrp.source_c(which=0)
src2 = usrp.source_c(which=1)

I've modified slightly some Python Receiver examples (from the BBN guys 
repository, but for the matter of my question i'think it makes no difference) 
so that now
I can specify this 'which' variable to either 0/1 from the command line and 
feed the "usrp.source_c" from GnuRad properly.

The result is that if I run the Receiver in say USRP '1', so that its FPGA gets 
loaded (which can be checked through the frequency of the blinking small green 
LEDs on
the USRP motherboard) and afterwards run again the Receiver into USRP '1' then 
I got a crash and the second USRP FPGA is not loaded. So far, totally normal.

However, when I run the receiver example in say, URSP 0, whose FPGA gets loaded 
without problems, and afterwards run the receiver example in USRP 1, there
is a collision. Indeed, the later USRP doesn't seem to get loaded correctly its 
FPGA because the right (D402) green LED doesn't blink at any time when it 
should do it once;
but the left one (D403) changes to a lower blinking frequency as normally.

Further in this situation I got something like this in the Ubuntu Cmd for USRP 
0 (totally normal log but the last two lines):

You selected (default) USRP #0
Bits Per Encoded Sample = 8
adc frequency =  6400
decimation frequency =  16
input_rate =  400
gain =  45.0
desired freq =  24.0
baseband frequency 239600.0
dxc frequency -400.0
Samples per data bit =  8
>>> gr_fir_ccf: using SSE
_reap: usb->status = -71, actual_length =  2560
fusb: (rd status -71) Protocol error

And got this for USRP 1:

usrp_open_interface:usb_claim_interface: failed interface 2
could not claim interface 2: Device or resource busy
usrp_basic_rx: can't open rx interface
Traceback (most recent call last):
  File "bbn_80211b_rx_USRP_SELECT.py", line 198, in 
main ()
  File "bbn_80211b_rx_USRP_SELECT.py", line 193, in main
app = app_flow_graph()
  File "bbn_80211b_rx_USRP_SELECT.py", line 177, in __init__
options.freq, options.which_usrp)
  File "bbn_80211b_rx_USRP_SELECT.py", line 76, in __init__
self.u = usrp.source_c(which_usrp, decim_rate=decim)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line 249, in 
__init__
fpga_filename, firmware_filename)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line 1232, 
in source_c
return _usrp1.source_c(*args)
RuntimeError: can't open usrp1

So I figure that there some point below "usrp.source_c" where the "pipes" 
towards each USB/USRP may collide.
¿or is it maybe some another missconfiguration from my side?

May anybody give me a clue on this?

Thanks in advance,

Juan


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Some questions regarding timestamps on packets

[call5_99]

Hello,
  Thank you for the clarifications.

Prasanna.

Eric Blossom wrote:
> 
> On Tue, Aug 19, 2008 at 02:53:57PM -0700, call5_99 wrote:
>> 
>> Hello,
>>I am new to GNU radio. So far I have been playing with
>> benchmark_rx
>> and benchmark_tx. Now, I am trying to estimate the distance between the
>> transmitter and the receiver. For this I need a very accurate timestamp
>> on
>> my packets. So my questions are-
>> 
>> 1) I need the time stamp in the order of nano seconds. Is it possible to
>> get
>> such accurate timestamp with GNU radio?
> 
> The best we're likely to do with the USRP is 1/64e6 == 15.625ns
> This is based on the frequency of the master clock in the FPGA.
> The master clock is not locked to any kind of a global reference.
> 
>> 2) How do I add timestamp on packet headers? Though I saw many posts on
>> packets with timestamp, I didn't find any, which explained how I go about
>> adding the timestamp at transmitter end, and retrieve  it at receiving
>> end. 
> 
> Folks are working on sorting out the code that handles timestamps right
> now.
> 
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Some-questions-regarding-timestamps-on-packets-tp19059455p19093125.html
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[George Nychis]

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 Interface


I agree with this solution, I think this is what Ketan's idea was that
I explained terribly in my last email.  Hopefully removing the USB
FIFO will allow the extra packet builders room on the chip.



I think that this is the right thing to do.  Now we just have to get it 
done.  I could probably start working on it Monday when I get back.



On a side note, it might be interesting to have a command that can
turn on the receiver and receive a specific number of inband packets.
For example, if you know you may be receiving a transmission that is
only 2ms long in a specific slot, it might be beneficial to only
schedule 2ms (+/- a guard time) worth of samples to be delivered to
the host, freeing up more CPU cycles for signal processing and using
the USB bandwidth a little more efficiently.


I'm not too concerned about this, although it would certainly improve
the flexibility of the receiver.  This might also require redesigning
the usrp_rx mblock, but I'm not confident about that.



This is definitely possible, and would be best implemented over the CS 
channel to the USRP.  usrp_rx would not need changed, as it simply does 
a read().  If the USRP is withholding samples, its simply going to block.


- George


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[Steve Peters]

> 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

I agree with this solution, I think this is what Ketan's idea was that
I explained terribly in my last email.  Hopefully removing the USB
FIFO will allow the extra packet builders room on the chip.

> On a side note, it might be interesting to have a command that can
> turn on the receiver and receive a specific number of inband packets.
> For example, if you know you may be receiving a transmission that is
> only 2ms long in a specific slot, it might be beneficial to only
> schedule 2ms (+/- a guard time) worth of samples to be delivered to
> the host, freeing up more CPU cycles for signal processing and using
> the USB bandwidth a little more efficiently.

I'm not too concerned about this, although it would certainly improve
the flexibility of the receiver.  This might also require redesigning
the usrp_rx mblock, but I'm not confident about that.

> Brian

Steve


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uses of gnuradio

[Wireless Monster]

Hi Joreen,
Listening to GSM broadcast channles and initaiating a RACH procedure with a
GSM handset using the USRP is possible.

Take a loook to http://wiki.thc.org/gsm . It may help.
++


On Thu, Aug 21, 2008 at 1:56 AM, Joreen Tan <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I am totally new to gnuradio but have to use it as a basic GSM base station
> for my final year project. the main criteria is to satisfy the basic
> handshaking protocol between the a handset and the base station. But due to
> my inexperience in programming, i am not very sure if it is possible, so
> would like to ask for some advice regarding this.
>
> Please help! Appreciate it..
>
> Joreen
>
> --
> Make the most of what you can do on your PC and the Web, just the way you
> want. Windows Live 
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

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 N RX Sample FIFOs?  It seems that the channels
> are already muxed by the time they get to the packet_builder, no?

The packet builder itself actually does the muxing:


http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/packet_builder.v

The N RX sample FIFOs are built here:


http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/rx_buffer_inband.v#L168

> 2. Can we just subtract the FIFO size (usedw?) from the timestamp in the
> packet builder?

Sure, but what for?  I suppose I am not sure what this is addressing?

> 3. When checking timestamps for expired command/data packets, is an
> overflow/wraparound on the timestamp_clock handled?  (ref cmd_reader.v:107,
> chan_fifo_reader.v:145)

I don't think it's explicitly being taken care of, but I am also not
sure if the logic just ends up working out.  This should probably be
looked at and a testbench written.

> 4. I wholeheartedly agree that it would be nice to have a "read N samples at
> time T command".
>
> --ets

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Prf radar mono.py

[Naoufel Amri]

Hello, 

I work on the USRP to achieve a single static radar. I
use the function: 
usrp_radar_mono.py  to issue a chirp and receive echoes  in
my tests to show echos which are in the file "F-FILENAME - filename
= FILENAME". I see  that  the Tlook do not have the same
size and vary from one another cycle . To me,it's a problem to deal these
data.
Can you tell me why the registered Tlook change from a circle to another?
Thanks.

Amri Naoufel



  
_ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Apols for the spam

[Steve Glass]

Just a quick apology for the spam Bebo sent using my email.

I have unsubscribed and will take greater care in future about whom I let
look in my inbox.

Regards

Steve

-- 
The highest human happiness is not the exploitation of the present but the
preparation of the future.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New invitation from Steve Glass

[Steve Glass]

You have been invited to connect as friends with Steve Glass <[EMAIL PROTECTED]>

Please accept or reject this invitation by clicking below:
http://www.bebo.com/in/7678246824a187378506b135

..
Please do not reply directly to this email.

This email was sent to you at the direct request of Steve Glass <[EMAIL 
PROTECTED]>. You have not been added to a mailing list.

If you would prefer not to receive invitations from ANY Bebo members please 
click here - http://www.bebo.com/unsub/7678246824a187378506

Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

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 get to the packet_builder, no?

2. Can we just subtract the FIFO size (usedw?) from the timestamp in the
packet builder?

3. When checking timestamps for expired command/data packets, is an
overflow/wraparound on the timestamp_clock handled?  (ref cmd_reader.v:107,
chan_fifo_reader.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: [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 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
initial
>> RX clock time.
>>
>> Now, you go by the fact that you're sampling at a constant rate and
>> timestamp packets based on that.  The next packet gets timestamped at
>> last_timestamp + 126samples_per_packet * decimation_rate.
>>
>> That way you're not timestamp on packet building, but logically the time
the
>> first sample of the packet arrived at the RX buffer.
>
> Correct me if I misunderstand, but you're not actually clocking
> anything this way.  Theoretically it should work, but there's nothing
> telling me there weren't actually a million clock cycles between two
> packets.  There should definitely be a timestamp clock tied to the
> master clock, in my opinion.
>
> Ketan and I discussed a couple possibilities earlier today.  One might
> be to have a timestamp buffer in parallel with the RX FIFO.  Although
> problems arise with making sure the timestamp changes at the border of
> packets, unless there is one timestamp per sample, which is almost
> certainly too excessive.
>
> Another idea is to move the FIFO to the other side of the packet
> builder, as long as the packet builder can keep up with the
> ADC/decimator output.  It then outputs to the buffer.  This was
> Ketan's idea, so I apologize if I'm communicating it incorrectly.

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

I believe the TX chain looks more like this, except with the arrows
going in the opposite direction.

On a side note, it might be interesting to have a command that can
turn on the receiver and receive a specific number of inband packets.
For example, if you know you may be receiving a transmission that is
only 2ms long in a specific slot, it might be beneficial to only
schedule 2ms (+/- a guard time) worth of samples to be delivered to
the host, freeing up more CPU cycles for signal processing and using
the USB bandwidth a little more efficiently.

Comments or suggestions?

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio