Re: [Discuss-gnuradio] No BPSK modulator?

[David I. Emery]

On Tue, Feb 27, 2007 at 11:01:58PM -0800, Matt Ettus wrote:
> 
> >(which makes me
> >curious, does anyone use non-differential 8PSK?).
> >  
> 
> Yes, satellites often do.

I might add that non differential PSK/QPSK has a theoretical
noise advantage if some mechanism exists to figure out the correct
initial rotation and not lose it later on.  And this is often pretty
easy to do when using convolutional code inner FEC from the FEC
correction which works with few errors for only one of the two or four
possible rotations.

Basicly best case in differential modulation an error in
detecting a symbol causes TWO bit errors in the data while a single
symbol error in absolute phase, non-differential modulation causes only
one bit error in the data before FEC.

-- 
   Dave Emery N1PRE,  [EMAIL PROTECTED]  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in 
celebration of what could have been, but wasn't and is not to be now either."



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

[Discuss-gnuradio] USRP french users

[Olivier REYNET]

Hello,
I am interested in using USRP and gnuradio for university teaching.
I am looking for USRP french users to advise me.
Please let me known about your experience with gnuradio and USRP.
Thanks,
Olivier



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

Re: [Discuss-gnuradio] No BPSK modulator?

[Matt Ettus]

(which makes me
curious, does anyone use non-differential 8PSK?).
  


Yes, satellites often do.

Matt


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

Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Eric Blossom]

On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg Troxel wrote:
> 
> Eric Blossom <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote:
> >>   I'm thinking layer 2 with a unique Ethernet packet type (probably use
> >>   some abandoned packet type).  That said, there's nothing stopping us
> >>   from doing UDP, except the additional bandwidth.  I don't see any need
> >>   to do TCP.
> >> 
> >> I think that it should be possible for an unprivileged user (on most
> >> Free systems) to interact with a USRP over GigE.  Actually this raises
> >> the issue of authorization and confidentiality/integrity of the data,
> >> probably taken care of by a dedicated ethernet port.
> >
> > Under GNU/Linux they may need to be holding CAP_NET_RAW, since I
> > think the way to get the raw ethernet frames is with libpcap and/or
> > opening a raw socket using socket(PF_PACKET, SOCK_RAW, ...)
> >
> > Any idea how we would get this done under *BSD?
> 
> Two ways:
> 
>   use bpf.  This requires r/w access to /dev/bpf, but that also
>   enables reading and writing other traffic.  Presumably CAP_NET_RAW
>   on Linux does too, and that's overly broad.
> 
>   write a protocol family driver for the USRP ethertype (hard)

OK.

> To me, this all argues for IP/UDP (at the cost of 28 bytes) being the
> standard approach, with raw being an optimization if needed.  It
> handles the privilege issues, and gives you multiplexing hooks (which
> we may not usually need).

OK.

> > I'm hoping on suitable machines to be able to run near wire-speed, so
> > that also argues for a dedicated ethernet port.
> 
> Sure, but speed should be an orthogonal design issue from security and
> multiplexing.

OK.

> > Also, absent some driver hacking to mux and demux commands and
> > responses, we may need a user space process to handle that stuff.  In
> > that case, only that processes would need access to the magic socket,
> > and the rest of the user code would use some kind of IPC to talk to
> > that one.
> 
> OK, but that's likely to be somewhat slower.   But I don't understand
> the mux/demux need, beyond connecting a USRP to a user process.  Do
> you envision two programs each accessing some part of the resources on
> a single GigE connected USRPng?

Sure.  It's a common operation now.  We often run an fft in one
process and some kind of transmitter in another.  Somebody's got to
handle the dumuxing of command replies.  Using your UDP example, we'd
have the source port of the request to route the reply.  That still
leaves the flags such as Overrun, Underrun, etc., which I was thinking
were only going to get reported once, and then cleared.  (I didn't see
a good reason for forcing the host to explicitly clear the flag.)


> > Pause frames provide flow control.  According to folks at Vanu
> > (who use Gigabit ethernet to implement their basestations), that's
> > been sufficient, assuming any switches along the way aren't brain
> > damaged. 
> 
> Locally, sure one can enforce that by declaring them broken and
> replacing them.
> 
> > If somebody wanted to ship samples a long way reliably, then some
> > higher-level protocol is probably in order.
> 
> It may make sense to define a TCP or SCTP method, but then again it
> may not - this is perhipheral attachment.

I'd hate to try to stuff either of those in an inexpensive FPGA.  Of
course if somebody wanted those, they could stick some kind of single
board computer next to the USRPng and have it run TCP or SCTP or
whatever.

Eric


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

Re: [Discuss-gnuradio] Hierarchical C++ blocks

[Eric Blossom]

On Tue, Feb 27, 2007 at 08:38:05PM -0800, Daniel Garcia wrote:
> Is it possible to build hierarchical blocks (block
> containing other blocks) using only C++? I've seen
> some python examples in the tree but don't know where
> to look for blocks that only use C++.
> 
> Can someone point me in the right direction?
> 
> -Daniel

It's not fully baked yet, but should be ready in the not-too-distant future.

To have everything in C++, the usrp daughterboard code needs to be
moved into C++, along with some other odds and ends.

This stuff will all be in the 3.1 release.

Eric


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

Re: [Discuss-gnuradio] increase gain on tx

[Matt Ettus]

[EMAIL PROTECTED] wrote:

I am using the fm_tx4.py example to transmit a simple signal using the Basic TX 
daughterboard.  On the oscilloscope, I am seeing about a 30mV peak-to-peak 
signal and I want to increase this output.  I think you can program the pga 
after the D/A up to 20 dB but I don't know how to do this.  I don't even know 
if this is the best way to do this.  Any help would be appreciated.

  


They highest signal output is obtained with the TX PGA gain set to the 
maximum, and the digital signal level set to 32767.  You can use that 
for the gain instead of 4000.


Matt


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

Re: [Discuss-gnuradio] FPGA Questions

[Matt Ettus]

Eric Blossom wrote:

On Sat, Feb 24, 2007 at 05:13:22PM -0500, Brian Padalino wrote:
  

On 2/24/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:


Hi all,

I have dived into the fpga code and I have now much clearer picture of
what is going on, but also much more questions :)

The Tx CORDIC is disabled in the code I checked out. Why?
  

I could be wrong, but I think the TX CORDIC is disabled due to the
fact that the samples being delivered over USB are already complex.
Any other frequency translation is done within the AD9862 transmit
path.

Anyone can feel free to correct me if I am wrong.



You are correct ;)

  


Actually, he isn't.   The TX CORDIC is not used since the AD9862 has its 
own upconverter.  It doesn't have anything to do with whether the 
samples are real or complex.


Matt



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

[Discuss-gnuradio] Hierarchical C++ blocks

[Daniel Garcia]

Is it possible to build hierarchical blocks (block
containing other blocks) using only C++? I've seen
some python examples in the tree but don't know where
to look for blocks that only use C++.

Can someone point me in the right direction?

-Daniel



 

Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121


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

RE: [Discuss-gnuradio] No BPSK modulator?

[Tom Rondeau]

> -Original Message-
> From: Eric Blossom [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 27, 2007 5:46 PM
> To: Tom Rondeau
> Cc: 'gnuradio mailing list'
> Subject: Re: [Discuss-gnuradio] No BPSK modulator?
> 
> On Tue, Feb 27, 2007 at 05:07:31PM -0500, Tom Rondeau wrote:
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> [mailto:discuss-
> > > [EMAIL PROTECTED] On Behalf Of Trond Danielsen
> > > Sent: Tuesday, February 27, 2007 10:46 AM
> > > To: gnuradio mailing list
> > > Subject: [Discuss-gnuradio] No BPSK modulator?
> > >
> > > Hi,
> > >
> > > Is there a reason why there is no "ordinary" n-PSK modulator and
> > > demodulator available, only the differential one? If not, I'll modify
> > > the existing one and submit a patch.
> >
> > It's not so much that there isn't a non-differential BPSK modulator,
> it's
> > that there is no demod for it. Basically, we have to be able to
> determine
> > the phase orientation of the incoming signal in some way to know what
> our
> > phase is. In BPSK, this is simple, and this was the original reason why
> > gr_correlate_access_code_bb had a d_flip variable in it, so that when
> the
> > phase inversion was detected, it would decode it properly.
> >
> > However, this was never a good solution and ended up hurting us because
> > sometimes we'd trigger this flip with random data, which would screw up
> the
> > packets. This was the reason the SSH sessions would crash and why
> Johnathan
> > made the original fix in the whitener.
> >
> > The solution to this is to use the correlator to detect the phase, but
> let
> > the next guy down the line understand what to do with it. We probably
> want
> > to send a control signal out to set the phase derotation and trigger the
> > access code found state at the same time, specifically, in the simple
> framer
> > state machine.
> 
> You could use bit 2 of the output stream of
> gr_correlate_access_code_bb to encode the "I've seen the inverted
> pattern".  Then anybody who cared could look at it and take action if
> they wanted to, but it wouldn't interfere with any existing code.
> 
> Eric

Yes, I realize that, but I'm not a huge fan of doing it this way, quite
frankly. It's a bit more inefficient to use multiple output streams for
this, but by putting the flag inside the data stream seems to obfuscate the
system. I'd much rather open a separate control stream to pass this kind of
information around. This would, of course, require reworking the block (or
adding a new one to avoid any conflicts), so if there is a consensus to add
more information, sure. I would suggest, though, that we might use at least
3 bits for this to support up to 8 phase rotations for 8PSK (which makes me
curious, does anyone use non-differential 8PSK?).

Also, is there a clever way of figuring out the phase rotation from the
access code without going through the permutations? For BPSK we only need to
test two, the access code and its bitwise compliment, but for QPSK we have
four and 8PSK has eight possible phases. At least with QAM, we should be
able to just use 4, so I think 8 is the maximum we would ever need to
account for.

Tom




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

Re: [Discuss-gnuradio] svn-4661: gr-qtgui not building on NetBSD

[Berndt Josef Wulf]

On Wednesday 28 February 2007 13:24:19 you wrote:
> Berndt Josef Wulf wrote:
> > configure detects qt3 but fails to find qwt-5.0.1 and hence won't build
> > gr-qtqui. It appears that the configure script uses the pkg-config
> > utility to retrieve metainformation about installed libraries. However,
> > qwt does not install a pkg-config metadata file. Does qwt install a
> > pkg-config metadata file on Linux?
>
> No.
>
> First, the new gr-qtgui component is a work-in-progress, so it doesn't
> do anything much useful yet (other than in a very specific test scenario
> used last week during the OFDM bash).
>
> The configure script is incomplete.  The group was using a manually
> created qwt.pc file as a substitute to fishing this out autotools
> macros.  Bob McGwier will be updating the .m4 file to work without the
> .pc file, and then it should start working on several platforms.
>
> > gr-qtgui built fine after manually creating a pkg-config metadata file
> > for qwt. I believe that I shouldn't need to do this.
>
> Correct, see above.

Sorry, I didn't realise that gr-qtgui wasn't ready for public release yet. It 
caught my attention as I've been writing some widgets using pyqt.

cheerio Berndt


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

Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing

[Berndt Josef Wulf]

On Wednesday 28 February 2007 13:19:12 you wrote:
> Berndt Josef Wulf wrote:
> > I beg to differ. It worked within the pkgsrc environment and only broke
> > in recent RC2.
>
> Yes, it appears this was "accidentally" working before, as we were
> allowing the system library paths to be included when building inside
> the tree.  Now that we've cleaned things up, we'll need to come up with
> a different way for this to succeed.

By my recollection it was the intent of having these switches to enable 
developers to select and build individual modules.

> Greg Troxel has an idea (posted earlier) to address this; unfortunately,
> it's too large of a change to make it into the stable branch until we
> get thorough testing on the trunk.  So release 3.03 will work as-is.

In this case I will base the pkgsrc collection on RC1 for now, which I have 
ready for commit.

It would be nice to see a solution for future releases.

cheerio Berndt



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

Re: [Discuss-gnuradio] svn-4661: gr-qtgui not building on NetBSD

[Johnathan Corgan]

Berndt Josef Wulf wrote:

> configure detects qt3 but fails to find qwt-5.0.1 and hence won't build 
> gr-qtqui. It appears that the configure script uses the pkg-config utility to 
> retrieve metainformation about installed libraries. However, qwt does not 
> install a pkg-config metadata file. Does qwt install a pkg-config metadata 
> file on Linux? 

No.

First, the new gr-qtgui component is a work-in-progress, so it doesn't
do anything much useful yet (other than in a very specific test scenario
used last week during the OFDM bash).

The configure script is incomplete.  The group was using a manually
created qwt.pc file as a substitute to fishing this out autotools
macros.  Bob McGwier will be updating the .m4 file to work without the
.pc file, and then it should start working on several platforms.

> gr-qtgui built fine after manually creating a pkg-config metadata file for 
> qwt. I believe that I shouldn't need to do this.

Correct, see above.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing

[Johnathan Corgan]

Berndt Josef Wulf wrote:

> I beg to differ. It worked within the pkgsrc environment and only broke in 
> recent RC2.

Yes, it appears this was "accidentally" working before, as we were
allowing the system library paths to be included when building inside
the tree.  Now that we've cleaned things up, we'll need to come up with
a different way for this to succeed.

Greg Troxel has an idea (posted earlier) to address this; unfortunately,
it's too large of a change to make it into the stable branch until we
get thorough testing on the trunk.  So release 3.03 will work as-is.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

Re: [Discuss-gnuradio] mblock linking error

[Johnathan Corgan]

Josh Blum wrote:

> The same problem occurs on cygwin. I know cygwin is a lower priority,
> but the issue may not be ubuntu specific. -josh
> 
> Roshan Baliga wrote:
>> I've run into the same problem on Ubuntu 6.06 (Dapper Drake) at trunk
>> rev 4662 (current). The trunk tree built fine for me on the same box a
>> month ago. (I already tried make distclean and bootstrap.)

Could you gentlemen please update and retry?

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

Re: [Discuss-gnuradio] modification of gr-trellis to support, multiple initial and/or final states

[Tim Meehan]

Achilleas and Eric,

I have attached a patch to trellis_viterbi_X.cc.t,
trellis_viterbi_X.i.t and trellis_viterbi_X.h.t

This patch allows for multiple initial and/or final states by calling
viterbi with a vector for S0 and/or SK.  The call is overloaded so
that viterbi can still be called with a scalar.  The two accessor
methods for d_S0 and d_SK still work for scalars but just return the
first element if S0 or SK are vectors.  I was not sure how to overload
this based on return type.

I would be happy to write a patch for the test code qa_trellis.py but
it does not seem to have a test for viterbi right now.

I would also be happy to write a patch for the documentation
gr_trellis.xml (was this written by hand or machine generated?)

I don't think there was any bounds checking for the scalar call with
S0 and SK so I did not add any for the vector call.  i.e. you can call
viterbi with a value for SK that is greater than the number of states.


Tim


gr_trellis.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USB packet format / inband signaling

[Thibaud Hottelier]

Brian Padalino wrote:
> Hi Thibaud,
> 
> Here is my response as to how I understand things to work - which
> could be completely wrong.
> 
> On 2/27/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> First of all, I would like to make sure that I have understood what is
>> going to be modified. I have made a diagram with the whole Gnuradio
>> component stack: http://img168.imageshack.us/img168/415/groveralleb2.png
>>
>> 1) The new usb packet will be encoded/decoded in the gnuradio uspr
>> driver and in the FX2 firmare right?
> 
> On the host side, the message blocks will queue up the commands and
> create the packet structure that will go down to the USRP driver and
> be delivered by libusb.
> 
> A specific endpoint within the FX2 will be used to figure out if it's
> an m-block packet or something else (like a packet to tell the FX2 to
> program the FPGA).
> 
> The FX2 firmware will then be pretty transparent and pass along the
> information over the same datapath as the current TX/RX samples.
> 
> Once inside the FPGA, some command parsing happens and the samples are
> sent on through to a FIFO where they sit until their timestamp comes
> up while the control words go on to some kind of control FSM that will
> take care of all those commands based on timestamp.
> 
> The packets going from the USRP to the host will be created within the
> FPGA and send on out through the m-block FIFO that the FX2 will read.
> 
> Again - I am not sure if this is how it is supposed to be, but this is
> how I have read it thus far.

So the usb packets will be decoded/encoded in the fpga itself. The tx
fifo would store 512 bytes of usb data and then parse it, send the
samples and execute the command right? This could be a first thing to
work on.
> 
>> 2) The FX2 and the fpga communicate using the serial bus (SDI/SDO) (plus
>> some control signal like usb_ctl, usb_rdy) and the usb_data bus. Will
>> the commands be sent trough the serial bus or through the usb_data bus ?
> 
> I suppose I answered this a bit up above.
> 
>> What is exactly the daughter board role and its responsibilities ? Is it
>> only a physical interface for the antenna ?
> 
> For the most part, it's our link to the outside world.  When doing a
> frequency hopping scheme or a TDMA scheme, you have to transmit at
> extremely specific times, or change frequencies very quickly and
> accurately.  To do this, you need tight control over the PLL,
> synthesizer, mixer, any tuners, etc that will govern how and where
> your signal shows up in the spectrum.  The role of the daugherboard is
> really to make sure the signal gets out as cleanly as possible.
> 
>> I also a few question about the format itself:
>>
>> I don't understand the purpose of the Tag field. Can you explain it a
>> little bit ?
> 
> I think this is just a specific identifier for future use.  I am not
> exactly certain myself.
> 
>> I don't understand how the timestamps will work on OUT packets: How the
>> host will know what the value of the 32 bits counter incremented by the
>> A/D sample clock ? Is the timestamps the absolute value of the clock or
>> a delta?
> 
> Usually a TDMA sequence will do a search first to try to get a lock on
> a signal.  Once that happens, it's synchronized to the system.  It
> will probably search for a signal, and once a signal is detected -
> reset the free-running counter in the FPGA to be aligned with the
> start of the TDMA epoch.
> 
>> SPI is used to write to the AD9862 register but what is I2C ?
> 
> SPI is basically the same thing with a different physical interface.
> SPI uses 3 wires where I2C uses 2, if I am not mistaken.
> 
> Currently, the SPI bus is used to write to both the FPGA and the
> AD9862.  Since the FPGA will be writing to the SPI, the in-band
> signaling code should only have to write to the AD9862.
> 
> The I2C bus is used to control the daugherboard.  I believe the USRP
> does not have a connection to the I2C bus right now, and will possibly
> require a modification of the board to connect it up.
> 
> If I have screwed up, I am sorry and please, someone correct me.
> 
> Brian
> 

Thanks for this detailed explanation :)
Thibaud


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

Re: [Discuss-gnuradio] mblock linking error

[Josh Blum]

The same problem occurs on cygwin. I know cygwin is a lower priority, 
but the issue may not be ubuntu specific. -josh


Roshan Baliga wrote:
I've run into the same problem on Ubuntu 6.06 (Dapper Drake) at trunk 
rev 4662 (current). The trunk tree built fine for me on the same box a 
month ago. (I already tried make distclean and bootstrap.)


-Roshan

Josh Blum wrote:
I just checked out the trunk rev 4659, did a bootstrap, configure, it 
fails on the make.
I am running ubuntu edgy. Is this an issue with the new 
linking/integrating mblock?


-Josh


/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall 
-Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o 
libmblock-qa.la  libmblock.la 

g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock 
test_mblock.o  ./.libs/libmblock-qa.so ./.libs/libmblock.so 
-Wl,--rpath -Wl,/usr/local/lib
./.libs/libmblock-qa.so: undefined reference to 
`pmt_list3(boost::shared_ptr, boost::shared_ptr, 
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to 
`pmt_list1(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to 
`pmt_list2(boost::shared_ptr, boost::shared_ptr)'

collect2: ld returned 1 exit status
make[4]: *** [test_mblock] Error 1
make[4]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/gnuradio_trunk/mblock'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/gnuradio_trunk'
make: *** [all] Error 2





___
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] USB packet format / inband signaling

[Brian Padalino]

Hi Thibaud,

Here is my response as to how I understand things to work - which
could be completely wrong.

On 2/27/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:

Hi all,

First of all, I would like to make sure that I have understood what is
going to be modified. I have made a diagram with the whole Gnuradio
component stack: http://img168.imageshack.us/img168/415/groveralleb2.png

1) The new usb packet will be encoded/decoded in the gnuradio uspr
driver and in the FX2 firmare right?


On the host side, the message blocks will queue up the commands and
create the packet structure that will go down to the USRP driver and
be delivered by libusb.

A specific endpoint within the FX2 will be used to figure out if it's
an m-block packet or something else (like a packet to tell the FX2 to
program the FPGA).

The FX2 firmware will then be pretty transparent and pass along the
information over the same datapath as the current TX/RX samples.

Once inside the FPGA, some command parsing happens and the samples are
sent on through to a FIFO where they sit until their timestamp comes
up while the control words go on to some kind of control FSM that will
take care of all those commands based on timestamp.

The packets going from the USRP to the host will be created within the
FPGA and send on out through the m-block FIFO that the FX2 will read.

Again - I am not sure if this is how it is supposed to be, but this is
how I have read it thus far.


2) The FX2 and the fpga communicate using the serial bus (SDI/SDO) (plus
some control signal like usb_ctl, usb_rdy) and the usb_data bus. Will
the commands be sent trough the serial bus or through the usb_data bus ?


I suppose I answered this a bit up above.


What is exactly the daughter board role and its responsibilities ? Is it
only a physical interface for the antenna ?


For the most part, it's our link to the outside world.  When doing a
frequency hopping scheme or a TDMA scheme, you have to transmit at
extremely specific times, or change frequencies very quickly and
accurately.  To do this, you need tight control over the PLL,
synthesizer, mixer, any tuners, etc that will govern how and where
your signal shows up in the spectrum.  The role of the daugherboard is
really to make sure the signal gets out as cleanly as possible.


I also a few question about the format itself:

I don't understand the purpose of the Tag field. Can you explain it a
little bit ?


I think this is just a specific identifier for future use.  I am not
exactly certain myself.


I don't understand how the timestamps will work on OUT packets: How the
host will know what the value of the 32 bits counter incremented by the
A/D sample clock ? Is the timestamps the absolute value of the clock or
a delta?


Usually a TDMA sequence will do a search first to try to get a lock on
a signal.  Once that happens, it's synchronized to the system.  It
will probably search for a signal, and once a signal is detected -
reset the free-running counter in the FPGA to be aligned with the
start of the TDMA epoch.


SPI is used to write to the AD9862 register but what is I2C ?


SPI is basically the same thing with a different physical interface.
SPI uses 3 wires where I2C uses 2, if I am not mistaken.

Currently, the SPI bus is used to write to both the FPGA and the
AD9862.  Since the FPGA will be writing to the SPI, the in-band
signaling code should only have to write to the AD9862.

The I2C bus is used to control the daugherboard.  I believe the USRP
does not have a connection to the I2C bus right now, and will possibly
require a modification of the board to connect it up.

If I have screwed up, I am sorry and please, someone correct me.

Brian


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

Re: [Discuss-gnuradio] mblock linking error

[Roshan Baliga]

I've run into the same problem on Ubuntu 6.06 (Dapper Drake) at trunk 
rev 4662 (current). The trunk tree built fine for me on the same box a 
month ago. (I already tried make distclean and bootstrap.)


-Roshan

Josh Blum wrote:
I just checked out the trunk rev 4659, did a bootstrap, configure, it 
fails on the make.
I am running ubuntu edgy. Is this an issue with the new 
linking/integrating mblock?


-Josh


/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall 
-Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o 
libmblock-qa.la  libmblock.la 
g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock 
test_mblock.o  ./.libs/libmblock-qa.so ./.libs/libmblock.so -Wl,--rpath 
-Wl,/usr/local/lib
./.libs/libmblock-qa.so: undefined reference to 
`pmt_list3(boost::shared_ptr, boost::shared_ptr, 
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to 
`pmt_list1(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to 
`pmt_list2(boost::shared_ptr, boost::shared_ptr)'

collect2: ld returned 1 exit status
make[4]: *** [test_mblock] Error 1
make[4]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/gnuradio_trunk/mblock'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/gnuradio_trunk'
make: *** [all] Error 2





___
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

[Discuss-gnuradio] USB packet format / inband signaling

[Thibaud Hottelier]

Hi all,

First of all, I would like to make sure that I have understood what is
going to be modified. I have made a diagram with the whole Gnuradio
component stack: http://img168.imageshack.us/img168/415/groveralleb2.png

1) The new usb packet will be encoded/decoded in the gnuradio uspr
driver and in the FX2 firmare right?

2) The FX2 and the fpga communicate using the serial bus (SDI/SDO) (plus
some control signal like usb_ctl, usb_rdy) and the usb_data bus. Will
the commands be sent trough the serial bus or through the usb_data bus ?

What is exactly the daughter board role and its responsibilities ? Is it
only a physical interface for the antenna ?

I also a few question about the format itself:

I don't understand the purpose of the Tag field. Can you explain it a
little bit ?

I don't understand how the timestamps will work on OUT packets: How the
host will know what the value of the 32 bits counter incremented by the
A/D sample clock ? Is the timestamps the absolute value of the clock or
a delta?

SPI is used to write to the AD9862 register but what is I2C ?

Thanks,
Thibaud



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

Re: [Discuss-gnuradio] No BPSK modulator?

[Eric Blossom]

On Tue, Feb 27, 2007 at 05:07:31PM -0500, Tom Rondeau wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:discuss-
> > [EMAIL PROTECTED] On Behalf Of Trond Danielsen
> > Sent: Tuesday, February 27, 2007 10:46 AM
> > To: gnuradio mailing list
> > Subject: [Discuss-gnuradio] No BPSK modulator?
> > 
> > Hi,
> > 
> > Is there a reason why there is no "ordinary" n-PSK modulator and
> > demodulator available, only the differential one? If not, I'll modify
> > the existing one and submit a patch.
> 
> It's not so much that there isn't a non-differential BPSK modulator, it's
> that there is no demod for it. Basically, we have to be able to determine
> the phase orientation of the incoming signal in some way to know what our
> phase is. In BPSK, this is simple, and this was the original reason why
> gr_correlate_access_code_bb had a d_flip variable in it, so that when the
> phase inversion was detected, it would decode it properly.
> 
> However, this was never a good solution and ended up hurting us because
> sometimes we'd trigger this flip with random data, which would screw up the
> packets. This was the reason the SSH sessions would crash and why Johnathan
> made the original fix in the whitener.
> 
> The solution to this is to use the correlator to detect the phase, but let
> the next guy down the line understand what to do with it. We probably want
> to send a control signal out to set the phase derotation and trigger the
> access code found state at the same time, specifically, in the simple framer
> state machine.

You could use bit 2 of the output stream of
gr_correlate_access_code_bb to encode the "I've seen the inverted
pattern".  Then anybody who cared could look at it and take action if
they wanted to, but it wouldn't interfere with any existing code.

Eric


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

RE: [Discuss-gnuradio] No BPSK modulator?

[Tom Rondeau]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
> [EMAIL PROTECTED] On Behalf Of Trond Danielsen
> Sent: Tuesday, February 27, 2007 10:46 AM
> To: gnuradio mailing list
> Subject: [Discuss-gnuradio] No BPSK modulator?
> 
> Hi,
> 
> Is there a reason why there is no "ordinary" n-PSK modulator and
> demodulator available, only the differential one? If not, I'll modify
> the existing one and submit a patch.

It's not so much that there isn't a non-differential BPSK modulator, it's
that there is no demod for it. Basically, we have to be able to determine
the phase orientation of the incoming signal in some way to know what our
phase is. In BPSK, this is simple, and this was the original reason why
gr_correlate_access_code_bb had a d_flip variable in it, so that when the
phase inversion was detected, it would decode it properly.

However, this was never a good solution and ended up hurting us because
sometimes we'd trigger this flip with random data, which would screw up the
packets. This was the reason the SSH sessions would crash and why Johnathan
made the original fix in the whitener.

The solution to this is to use the correlator to detect the phase, but let
the next guy down the line understand what to do with it. We probably want
to send a control signal out to set the phase derotation and trigger the
access code found state at the same time, specifically, in the simple framer
state machine.

Tom




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

[Discuss-gnuradio] svn-4661: gr-qtgui not building on NetBSD

[Berndt Josef Wulf]

G'day,

configure detects qt3 but fails to find qwt-5.0.1 and hence won't build 
gr-qtqui. It appears that the configure script uses the pkg-config utility to 
retrieve metainformation about installed libraries. However, qwt does not 
install a pkg-config metadata file. Does qwt install a pkg-config metadata 
file on Linux? 

The qwt files are currently installed in ${PREFIX}/{include/qwt,lib} and the 
plugin in ${QTDIR}/plugin/designer.

gr-qtgui built fine after manually creating a pkg-config metadata file for 
qwt. I believe that I shouldn't need to do this.

cheerio Berndt


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

Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Greg Troxel]

Eric Blossom <[EMAIL PROTECTED]> writes:

> On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote:
>>   I'm thinking layer 2 with a unique Ethernet packet type (probably use
>>   some abandoned packet type).  That said, there's nothing stopping us
>>   from doing UDP, except the additional bandwidth.  I don't see any need
>>   to do TCP.
>> 
>> I think that it should be possible for an unprivileged user (on most
>> Free systems) to interact with a USRP over GigE.  Actually this raises
>> the issue of authorization and confidentiality/integrity of the data,
>> probably taken care of by a dedicated ethernet port.
>
> Under GNU/Linux they may need to be holding CAP_NET_RAW, since I
> think the way to get the raw ethernet frames is with libpcap and/or
> opening a raw socket using socket(PF_PACKET, SOCK_RAW, ...)
>
> Any idea how we would get this done under *BSD?

Two ways:

  use bpf.  This requires r/w access to /dev/bpf, but that also
  enables reading and writing other traffic.  Presumably CAP_NET_RAW
  on Linux does too, and that's overly broad.

  write a protocol family driver for the USRP ethertype (hard)

To me, this all argues for IP/UDP (at the cost of 28 bytes) being the
standard approach, with raw being an optimization if needed.  It
handles the privilege issues, and gives you multiplexing hooks (which
we may not usually need).

> I'm hoping on suitable machines to be able to run near wire-speed, so
> that also argues for a dedicated ethernet port.

Sure, but speed should be an orthogonal design issue from security and
multiplexing.

> Also, absent some driver hacking to mux and demux commands and
> responses, we may need a user space process to handle that stuff.  In
> that case, only that processes would need access to the magic socket,
> and the rest of the user code would use some kind of IPC to talk to
> that one.

OK, but that's likely to be somewhat slower.   But I don't understand
the mux/demux need, beyond connecting a USRP to a user process.  Do
you envision two programs each accessing some part of the resources on
a single GigE connected USRPng?

> Pause frames provide flow control.  According to folks at Vanu
> (who use Gigabit ethernet to implement their basestations), that's
> been sufficient, assuming any switches along the way aren't brain
> damaged. 

Locally, sure one can enforce that by declaring them broken and
replacing them.

> If somebody wanted to ship samples a long way reliably, then some
> higher-level protocol is probably in order.

It may make sense to define a TCP or SCTP method, but then again it
may not - this is perhipheral attachment.




pgpb5PPvkikQ3.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Eric Blossom]

On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote:
>   I'm thinking layer 2 with a unique Ethernet packet type (probably use
>   some abandoned packet type).  That said, there's nothing stopping us
>   from doing UDP, except the additional bandwidth.  I don't see any need
>   to do TCP.
> 
> I think that it should be possible for an unprivileged user (on most
> Free systems) to interact with a USRP over GigE.  Actually this raises
> the issue of authorization and confidentiality/integrity of the data,
> probably taken care of by a dedicated ethernet port.

Under GNU/Linux they may need to be holding CAP_NET_RAW, since I
think the way to get the raw ethernet frames is with libpcap and/or
opening a raw socket using socket(PF_PACKET, SOCK_RAW, ...)

Actually, according to man 7 packet, socket(PF_PACKET, SOCK_DGRAM, 
hton(ETH_P_foo)) 
may work too.  It's been a while since I played with this stuff.

Any idea how we would get this done under *BSD?

I'm hoping on suitable machines to be able to run near wire-speed, so
that also argues for a dedicated ethernet port.

Also, absent some driver hacking to mux and demux commands and
responses, we may need a user space process to handle that stuff.  In
that case, only that processes would need access to the magic socket,
and the rest of the user code would use some kind of IPC to talk to
that one.

> USB is said to be reliable.   Presumably you mean to have that same
> property via pause frames.

Pause frames provide flow control.  According to folks at Vanu
(who use Gigabit ethernet to implement their basestations), that's
been sufficient, assuming any switches along the way aren't brain
damaged. 

If somebody wanted to ship samples a long way reliably, then some
higher-level protocol is probably in order.

Eric


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

[Discuss-gnuradio] mblock linking error

[Josh Blum]

I just checked out the trunk rev 4659, did a bootstrap, configure, it fails
on the make.
I am running ubuntu edgy. Is this an issue with the new linking/integrating
mblock?

-Josh


/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o
libmblock-qa.la libmblock.la
g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmblock-qa.so ./.libs/libmblock.so -Wl,--rpath
-Wl,/usr/local/lib
./.libs/libmblock-qa.so: undefined reference to
`pmt_list3(boost::shared_ptr, boost::shared_ptr,
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`pmt_list1(boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`pmt_list2(boost::shared_ptr, boost::shared_ptr)'
collect2: ld returned 1 exit status
make[4]: *** [test_mblock] Error 1
make[4]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/gnuradio_trunk/mblock'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/gnuradio_trunk'
make: *** [all] Error 2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Standard Output

[Eric Blossom]

On Tue, Feb 27, 2007 at 10:14:54AM +0100, Davide Anastasia wrote:
> Is it available a module which write samples on unix standard output?
> 
> Regards,
> -- 
> Davide Anastasia

You could use

  dst = gr.file_descriptor_sink(gr.sizeof_foo, 1)

Eric


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

[Discuss-gnuradio] No BPSK modulator?

[Trond Danielsen]

Hi,

Is there a reason why there is no "ordinary" n-PSK modulator and
demodulator available, only the differential one? If not, I'll modify
the existing one and submit a patch.

--
Trond Danielsen


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

RE: [Discuss-gnuradio] OFDM - on air?

[Tom Rondeau]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
> [EMAIL PROTECTED] On Behalf Of Dominik Auras
> Sent: Tuesday, February 27, 2007 10:09 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] OFDM - on air?
> 
> Hello,
> 
> I'm currently trying to make your ofdm simulation work with two usrp
> rev4. The scripts benchmark_ofdm_tx.py and ...rx.py are modified in
> order to send (I looked on the examples in the directory
> "examples/python/digital/").
> 
> Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
> Flex2400RF boards used. (Maybe my first faults lay here)

Actually, your first fault was using the code ;) We made a lot of progress
last week, but we still have a ways to go before we get it to work over the
air. OFDM requires a high dynamic range, and clipping can happen easily. We
haven't really analyzed this yet. 

If you want to start playing around with it, benchmark_ofdm.py does a
loopback simulation with optional AWGN and multipath channels between the Tx
and Rx blocks. We're hoping to inject some quiet time into this simulation
to test the signal acquisition capabilities. That is, we know that under
steady-state conditions we synchronize pretty well, but we don't know the
transient behavior when we first get s signal into the receiver.
 
> I also recorded some seconds to a file so I can now replay the same
> scenario.
> 
> The first thing I observe is that the synchronisation needs to know a
> value for the SNR. Fiddling around with that, the synchronizer starts
> the sampler even if no signal present (at high SNR-value), but no
> samples get through it if the value is lower than 8.

Yes. We hope to make that more automatic if we can.
 
> The correlator block thinks to have found the known symbols sometimes in
> the noise. And, very confusing to me, the first ofdm symbol, after the
> correlation found a peak, is always the first known symbol - even in
> absence of a signal.
> 
> The message "found at search delta..." appears very often, compared to
> your simulation.
> It looks like the following lines (I also edited some blocks to output
> debug info):

That's a little disturbing. The search delta should only appear if we
correlate to the known PN sequences. Granted, we didn't do a good job in
creating these two symbols, I still don't think we should often randomly
correlate against noise with 200 symbols.
 
> found at search delta: 1,
> demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
> 9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
> bin 1   h_sqrd = ( 37442.839844, 1714.728149 )   power = 42633.847656
> real(h)/p = 0.878242angle = 0.045764
> 
> This is repeated until I kill the process. There are also other outputs,
> with more "demod out" lines grouped together etc.

Yes, we've injected a lot of debug information here, but I thought the code
checked in had that output turned off. Are you using the newest code (and
yes, I did just check a few new things in that we didn't do before Matt
left).
 
> e.g. the first lines after the gr_buffer warning
> bin 0   h_sqrd = ( 2.125927, 1.626051 )  power = 2.299746
> real(h)/p = 0.924418angle = 0.652948
> found at search delta: 0,
> demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
> 9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
> demod out:   18  3c  8d  b3  e7   9  5b  cf  f4  d6  52  3d  a0  d2  be
> 1a  a8  9c  4a  a7  a1  36  9a  85  19 len: 25
> demod out:   e9  9c  88  d9  c4  93  db  c7  c6  9d  87  49  21  b1  3a
> 40  12  6f  27  30  de  a5  c8  97  f2 len: 25
> demod out:   7f  a5  bb  14  54  b4  84  e5  e9  3f  e9  9d  f5  a5  44
> 54   0  fb   6  21   0  44  49  9f  fa len: 25
> 
> 
> Thank you very much in advance
> You did a great work on gnuradio!!
> Dominik

Thanks! It's a bit premature still, but I'm sure we'll all be glad for more
feedback as it comes together.

Tom




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

[Discuss-gnuradio] OFDM - on air?

[Dominik Auras]

Hello,

I'm currently trying to make your ofdm simulation work with two usrp
rev4. The scripts benchmark_ofdm_tx.py and ...rx.py are modified in
order to send (I looked on the examples in the directory
"examples/python/digital/").

Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
Flex2400RF boards used. (Maybe my first faults lay here)

I also recorded some seconds to a file so I can now replay the same
scenario.

The first thing I observe is that the synchronisation needs to know a
value for the SNR. Fiddling around with that, the synchronizer starts
the sampler even if no signal present (at high SNR-value), but no
samples get through it if the value is lower than 8.

The correlator block thinks to have found the known symbols sometimes in
the noise. And, very confusing to me, the first ofdm symbol, after the
correlation found a peak, is always the first known symbol - even in
absence of a signal.

The message "found at search delta..." appears very often, compared to
your simulation.
It looks like the following lines (I also edited some blocks to output
debug info):

found at search delta: 1,
demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
bin 1   h_sqrd = ( 37442.839844, 1714.728149 )   power = 42633.847656
real(h)/p = 0.878242angle = 0.045764

This is repeated until I kill the process. There are also other outputs,
with more "demod out" lines grouped together etc.

e.g. the first lines after the gr_buffer warning
bin 0   h_sqrd = ( 2.125927, 1.626051 )  power = 2.299746
real(h)/p = 0.924418angle = 0.652948
found at search delta: 0,
demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
demod out:   18  3c  8d  b3  e7   9  5b  cf  f4  d6  52  3d  a0  d2  be
1a  a8  9c  4a  a7  a1  36  9a  85  19 len: 25
demod out:   e9  9c  88  d9  c4  93  db  c7  c6  9d  87  49  21  b1  3a
40  12  6f  27  30  de  a5  c8  97  f2 len: 25
demod out:   7f  a5  bb  14  54  b4  84  e5  e9  3f  e9  9d  f5  a5  44
54   0  fb   6  21   0  44  49  9f  fa len: 25


Thank you very much in advance
You did a great work on gnuradio!!
Dominik





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

Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Greg Troxel]

  I'm thinking layer 2 with a unique Ethernet packet type (probably use
  some abandoned packet type).  That said, there's nothing stopping us
  from doing UDP, except the additional bandwidth.  I don't see any need
  to do TCP.

I think that it should be possible for an unprivileged user (on most
Free systems) to interact with a USRP over GigE.  Actually this raises
the issue of authorization and confidentiality/integrity of the data,
probably taken care of by a dedicated ethernet port.

USB is said to be reliable.   Presumably you mean to have that same
property via pause frames.

-- 
Greg Troxel <[EMAIL PROTECTED]>


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

Re: [Discuss-gnuradio] Standard Output

[Trond Danielsen]

I haven't tested this myself, but you can try using a file sink with
/dev/stdout as argument.

2007/2/27, Davide Anastasia <[EMAIL PROTECTED]>:

Is it available a module which write samples on unix standard output?

Regards,
--
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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




--
Trond Danielsen


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

[Discuss-gnuradio] rx_buffer testbench

[Davide Anastasia]

Hi again,
I'm trying to modify the rx_buffer module, in order to obtain a 1 bit
quantization. Is it available a testbench for this module?

Regards,
-- 
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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

[Discuss-gnuradio] Standard Output

[Davide Anastasia]

Is it available a module which write samples on unix standard output?

Regards,
-- 
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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