Wednesday, November 30, 2011

Re: [Discuss-gnuradio] UHD - Tx still transmitting

> I believe you have to make sure that "end-of-burst" is set and wait for an ACK from the USRP. This allows the FPGA buffers to clear, at which point you should be able to start RX. Someone please correct me if I'm wrong :)
>
> Sean
Yup. In .../uhd/examples/tx_burst.cpp

Shows how this is done using the raw UHD interface (not mediated by Gnu
Radio).

There are latencies involved in many parts of the "stack", so if you
want to know that it's safe to
start receiving, you have to wait for the End-Of-Burst ACK. When you
"->send()" a lump of data
in UHD, when that send completes, it only means that the OS kernel
has accepted the data. It doesn't
mean that the ethernet interface has transmitted, or that the other
end has finished receiving it, or that
the FPGA is finished with it and the last sample has left the DAC.
That's what the EOB-ACK protocol is
about.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD - Tx still transmitting

I believe you have to make sure that "end-of-burst" is set and wait for an ACK from the USRP. This allows the FPGA buffers to clear, at which point you should be able to start RX. Someone please correct me if I'm wrong :)

Sean
________________________________________
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org [discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] on behalf of Martin Phisel [martin.phisel@crc.gc.ca]
Sent: Wednesday, November 30, 2011 3:16 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] UHD - Tx still transmitting

Hi,


I'm developing a waveform in C++
I'm using the UHD drivers and the USRP1.
The daugtherboard being used is the WBX.

I have 2 antennas:
One antenna (Rx) is connected to the Rx2 connector on the WBX board
the other antenna (Tx) is connected to Tx/Rx connector on the WBX board.

I'm not doing Rx and Tx at the same time (for now....)

Tx is working fine.
Rx is not because Tx is still sending data (last packet??).
Rx and Tx are using close frequencies....
so the Tx is interfering with the Rx....

I tried after stopping the Tx, so send a bunch of packet with 0 data in
them...no difference.

For now the only solution I found is when a switch to Rx mode, I set the
Tx frequency to a different value (ex: 800MHz instead of 200MHz).


Is there a way to completely stop the Tx?

Thanks,

Martin


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRUG change of venue

We normally go to Bailey's after the GRUG, but it's booked up. We will instead go to the Crystal City Sports Pub (NOT the Crystal City Resaurant). Probably about 9:30-9:45 after the meeting for those unable to join us in the Hyatt.

Tom

Sent from my iPhone
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Raw Samples from Receiver

> As background, I have 10 32-bit words of "metadata" prefixed to a burst
> of complex samples and I need to extract (and remove) them. I noticed
> recently that the trunk has some code related to tagging; in your
> opinion would the transport of my "metadata" be better done using
> tagging or is there an alternative method you can suggest. It is
> important that the "metadata" remain associated exactly with the burst
> samples.
>
So, a friendly note that if you're running non-standard firmware/FPGA,
you should note that earlier, rather than later,
when you're asking for help from this list. 99% of the folks on
this list use the as-shipped FPGA/Firmware that
is compatible directly with gr-uhd/Gnu Radio.

So when a question is asked the "context" that most answerers have is
the as-shipped FPGA/Firmware. Which is why I delivered
my "lecture" about ADC samples getting mangled by the decimators in
the FPGA, and why would you care, etc, etc.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD - Tx still transmitting

Hi,


I'm developing a waveform in C++
I'm using the UHD drivers and the USRP1.
The daugtherboard being used is the WBX.

I have 2 antennas:
One antenna (Rx) is connected to the Rx2 connector on the WBX board
the other antenna (Tx) is connected to Tx/Rx connector on the WBX board.

I'm not doing Rx and Tx at the same time (for now....)

Tx is working fine.
Rx is not because Tx is still sending data (last packet??).
Rx and Tx are using close frequencies....
so the Tx is interfering with the Rx....

I tried after stopping the Tx, so send a bunch of packet with 0 data in
them...no difference.

For now the only solution I found is when a switch to Rx mode, I set the
Tx frequency to a different value (ex: 800MHz instead of 200MHz).


Is there a way to completely stop the Tx?

Thanks,

Martin


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRUG meeting tonight!

On Wed, Nov 30, 2011 at 11:43 AM, Paul M. Bendixen <paulbendixen@gmail.com> wrote:
Damn it!
Why couldn't you have put this up yestoday? Now it's too late to book the flight from Denmark ;)

Have a good one 
Paul

I announced it last week. Plenty of time for you to have flow out for the evening. Flights out of National Airport mid afternoon tomorrow.

Tom
 

Re: [Discuss-gnuradio] Raw Samples from Receiver

Hi Josh,

Thank you for the answer... I can now see the data of interest in my C++
code.

Your comments, and Marcus', have raised a few question...

Is the item32 data the same before the type conversion regardless of
which type is specified for the source in Python.

By that I mean, if I use gr.COMPLEX_INT16 rather than gr.COMPLEX_FLOAT32
will the system operate the same or does it affect other aspects of the
system? Is the only difference that the IQ samples in the (initial) C++
block will be between -32767 to 32768 rather than in the {+1.0, -1.0}
set.

As background, I have 10 32-bit words of "metadata" prefixed to a burst
of complex samples and I need to extract (and remove) them. I noticed
recently that the trunk has some code related to tagging; in your
opinion would the transport of my "metadata" be better done using
tagging or is there an alternative method you can suggest. It is
important that the "metadata" remain associated exactly with the burst
samples.

Kind regards,

Lukasz

-----Original Message-----
From: discuss-gnuradio-bounces+lukasz.suleja=roke.co.uk@gnu.org
[mailto:discuss-gnuradio-bounces+lukasz.suleja=roke.co.uk@gnu.org] On
Behalf Of Josh Blum
Sent: 30 November 2011 14:26
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Raw Samples from Receiver


> Is there a way of transferring the 32-bit words from the FPGA to a C++
> GR block without the UHD code modifying it?
>
>

You can use the sc16 data type, this will involve a conversion from
item32 to complex<int16> which is basically a byte swap.

You can also use the item32 data type which will just perform endianess
conversion.

Also, both options are available in GRC.

>
> Using wireshark I can see the bytes of interested, but I cannot see
> these in the UHD item32_to_fc32 function. Should I not be able to see
> the bytes as seen in wireshark (UDP payload minus VITA framing) within
> this function?
>
>

All vita payload words pass through the converter function.

-josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Queen's Award for Enterprise and Innovation 2011

Roke Manor Research Ltd
Romsey, Hampshire, SO51 0ZN, United Kingdom
http://www.roke.co.uk
Part of the Chemring Group
Registered in England & Wales at:
Chemring Group PLC, Chemring House, 1500 Parkway,
Whiteley, Fareham, Hampshire PO15 7AF, ENGLAND.
Registered No: 267550
------------------------------------------------------------------------
The information contained in this e-mail and any attachments is
proprietary to Roke Manor Research Ltd and must not be passed to any
third party without permission. This communication is for information
only and shall not create or change any contractual relationship.
------------------------------------------------------------------------
Please consider the environment before printing this email


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Anyone do you know good GPS receiver Method?

Positioning............. :-)

On Tue, Nov 29, 2011 at 9:55 AM, Wolfarth, Ryan <wolfarra@muohio.edu> wrote:
I had never heard of fastGPS; sounds pretty useful.  What is the end goal for your receiver? 

Ryan


On Tue, Nov 29, 2011 at 5:10 AM, Nick Othieno <nickothieno@gmail.com> wrote:
I am using fastGPS to do the correlation as well as writing my own MATLAB correlation scripts.

Nick


On Fri, Nov 25, 2011 at 8:40 PM, Nick Foster <nick@ettus.com> wrote:
On Fri, Nov 25, 2011 at 7:01 AM, Nick Othieno <nickothieno@gmail.com> wrote:
> Hi Ryan,
>
> What did you use for your setup, ie daughterboards, antenna and LNA (if you
> do not mind my asking). I have been trying a setup for months that uses a
> DBSRX2 and a mighty mouse 2 antenna only, but I have never been able to
> acquire the L1 signal. I am wondering where I have gone wrong in the setup.

I've successfully used a DBSRX + active antenna to receive GPS signals
before. What software are you using to do the correlation and find the
L1 signal?

--n

>
> Nick
>
> On Fri, Nov 18, 2011 at 9:47 AM, Wolfarth, Ryan <wolfarra@muohio.edu> wrote:
>>
>> Hi folks,
>>
>> My group is using USRPs to do the task Kouki described, although our flow
>> diagram is a little different.  We only use the USRP2 to receive the raw RF
>> data which is written to file.  This data is processed to the point where we
>> decode the navigation bits, but no position is ever found.  We're more
>> interested in the effects of ionosphere scintillations on GNSS signal
>> structure so we don't need to calculate antenna position.
>>
>> I can recommend two books that have helped me immensely.  The Kaplan "blue
>> book:"
>>
>>
>> http://www.amazon.com/Understanding-GPS-Principles-Applications-Second/dp/1580538940/ref=sr_1_1?ie=UTF8&qid=1321627222&sr=8-1
>>
>> And the Kaplan "blue book:"
>>
>> http://www.gpstextbook.com/
>>
>> I do know of a group that has used a USRP1 to develop a 4 channel L1
>> receiver, but they had to modify the FPGA to do all the real time
>> processing.  Let me know if you have additional questions!
>>
>> -Ryan
>>
>> On Fri, Nov 18, 2011 at 7:56 AM, Brian Padalino <bpadalino@gmail.com>
>> wrote:
>>>
>>> 2011/11/18 山本弘貴 <k.yamamoto.0819@gmail.com>:
>>> > Hi, All
>>> > I have  very trouble
>>> > My experiment enviroment isUBUNTU 11.04 , USRP N200, DBSRX2 ,active
>>> > antenna and gnuradio
>>> > I am worrying about good software GPS receiver is not exist .
>>> > I want to receive L1 signal , and want to demodulate that signal
>>> > However GPS signal is used  Spread spectrum modulation scheme.
>>> > I try to creating gnuradio-companion's blocks.(use to Spread spectrum
>>> > demodulation blocks)
>>> > but that is very difficult so Now I think method is
>>> >
>>> >  GPS L1 signal → USRP N200 → gnuradio-companion(UHD_source→File_sink)
>>> > → software decode soft → output(Location data)
>>> >
>>> >
>>> > Eventually I want to Calculate location data,
>>> > Please let me know if you're a good this way
>>>
>>> I recently came across this product listing at Spark Fun:
>>>
>>>    http://www.sparkfun.com/products/10981
>>>
>>> Which has a link to a book all about GPS receiving and even comes with
>>> MATLAB source code:
>>>
>>>
>>>  http://www.amazon.com/Software-Defined-GPS-Galileo-Receiver-Single-Frequency/dp/0817643907
>>>
>>> I am sure, with the source, you could adapt it to use the USRP
>>> recorded signal, and then possibly port the MATLAB over to either
>>> Python (using Josh's signal processing in Python blocks) or straight
>>> C++.
>>>
>>> > I am sorry that My English is not good
>>> >
>>> > Kouki
>>>
>>> Good luck - it's definitely not a trivial task, but it sounds extremely
>>> fun.
>>>
>>> Brian
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>



Re: [Discuss-gnuradio] GRUG meeting tonight!

Damn it!
Why couldn't you have put this up yestoday? Now it's too late to book the flight from Denmark ;)

Have a good one 
Paul


--
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//

[Discuss-gnuradio] GRUG meeting tonight!

>>>>> "Tom" == Tom Rondeau <trondeau1122@gmail.com> writes:
Tom> Hope to see many of your there!

Yes, count me in.

-Maitland

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRUG meeting tonight!

Since I'm local, I plan to be there!

@(^.^)@ Ed

On 11/30/11 10:10 AM, Tom Rondeau wrote:
> The GNU Radio Users Group (GRUG) meeting is tonight at the WinnForum's
> conference!
>
> 8PM in Regency C of the Hyatt Regency Crystal City (in Arlington, VA).
> We'll chat for an hour or so then head on to the pub, the Bailey's
> (otherwise known as The Fox and Hound).
>
> Hope to see many of your there!
> Tom
>


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Raw Samples from Receiver

On 30-11-2011 9:19 AM, Suleja, Lukasz wrote:

Hi,

 

I would like to view / manipulate the raw samples from the FPGA.

 

From what I see, in the UHD code each 32-bit word (item) is split to form a complex float and a scaling factor is used.

 

Is there a way of transferring the 32-bit words from the FPGA to a C++ GR block without the UHD code modifying it?

 

Using wireshark I can see the bytes of interested, but I cannot see these in the UHD item32_to_fc32 function. Should I not be able to see the bytes as seen in wireshark (UDP payload minus VITA framing) within this function?

 

MTIA

 

Lukasz


Given that the samples have been filtered and manipulated by the DDC and CIC decimator code in the FPGA, and thus are only
  *related* to what came off the ADC, I wonder why it's important to get the samples in something other than {-1.0,+1.0}.

Further, what goes into the ADC is only *related* to the physical phenomenon that it's measuring.



Re: [Discuss-gnuradio] GRUG meeting tonight!

On 30-11-2011 10:10 AM, Tom Rondeau wrote:
> The GNU Radio Users Group (GRUG) meeting is tonight at the WinnForum's
> conference!
>
> 8PM in Regency C of the Hyatt Regency Crystal City (in Arlington, VA).
> We'll chat for an hour or so then head on to the pub, the Bailey's
> (otherwise known as The Fox and Hound).
>
> Hope to see many of your there!
> Tom
>
>
And will there be much GROG consumed at GRUG? :-) :-)


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRUG meeting tonight!

The GNU Radio Users Group (GRUG) meeting is tonight at the WinnForum's conference!

8PM in Regency C of the Hyatt Regency Crystal City (in Arlington, VA). We'll chat for an hour or so then head on to the pub, the Bailey's (otherwise known as The Fox and Hound).

Hope to see many of your there!
Tom

Re: [Discuss-gnuradio] Raw Samples from Receiver

> Is there a way of transferring the 32-bit words from the FPGA to a C++
> GR block without the UHD code modifying it?
>
>

You can use the sc16 data type, this will involve a conversion from
item32 to complex<int16> which is basically a byte swap.

You can also use the item32 data type which will just perform endianess
conversion.

Also, both options are available in GRC.

>
> Using wireshark I can see the bytes of interested, but I cannot see
> these in the UHD item32_to_fc32 function. Should I not be able to see
> the bytes as seen in wireshark (UDP payload minus VITA framing) within
> this function?
>
>

All vita payload words pass through the converter function.

-josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Raw Samples from Receiver

Hi,

 

I would like to view / manipulate the raw samples from the FPGA.

 

From what I see, in the UHD code each 32-bit word (item) is split to form a complex float and a scaling factor is used.

 

Is there a way of transferring the 32-bit words from the FPGA to a C++ GR block without the UHD code modifying it?

 

Using wireshark I can see the bytes of interested, but I cannot see these in the UHD item32_to_fc32 function. Should I not be able to see the bytes as seen in wireshark (UDP payload minus VITA framing) within this function?

 

MTIA

 

Lukasz

--

Queen's Award for Enterprise and Innovation 2011

Roke Manor Research Ltd
Romsey, Hampshire, SO51 0ZN, United Kingdom
http://www.roke.co.uk

Part of the Chemring Group
Registered in England & Wales at:
Chemring Group PLC, Chemring House, 1500 Parkway,
Whiteley, Fareham, Hampshire PO15 7AF, England.
Registered No: 267550


The information contained in this e-mail and any attachments is
proprietary to Roke Manor Research Ltd and must not be passed to any
third party without permission. This communication is for information
only and shall not create or change any contractual relationship.


Please consider the environment before printing this email

Re: [Discuss-gnuradio] Spectral Estimation Toolbox: GUI and cyclo estimator now available

On Tue, Nov 29, 2011 at 9:37 AM, Martin Braun <martin.braun@kit.edu> wrote:
Hi list,

the SpecEst toolbox has more fun and exciting stuff:
- First thing is a GUI. It connects to a file or UHD and can show live
 spectral estimates of the incoming signal using any of the existing
 estimators. For simple debugging purpose, this is not as useful as
 uhd_fft.py, but it's a great tool to show how different estimators
 (parametric vs. non-parametric) work. And have you ever seen a live
 ESPRIT based sinusoid tracker?
- Cyclostationary estimation is now also possible. This is not
 integrated into the GUI, as the output is completely different, but
 comes with demo app that uses Matplotlib to show stuff that's going on
 (very slow, though!). There's a small example script that uses the
 output of the cyclo estimator to distinguish QPSK and BPSK, just to
 see how this can be used.

As usual, it's all on our github. You can find it all
at https://www.cgran.org/wiki/SpecEst.

Happy spectral estimating,
MB


Once again, great work Martin!

Tom
 

Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py

On Tue, Nov 29, 2011 at 4:18 PM, Alex Zhang <cingular.alex@gmail.com> wrote:
Hi Josh,

I have no d8psk*, dbpsk*, modulation_utils2*.
Which branch do you use for this?

The dXpsk blocks have been replaced with Xpsk modulators that allow both differential and non-differential with a flag to turn it on and off (should be on by default), and modulation_utils2 (unless Josh reintroduced that, too) is now must modulation_utils.

I updated the ChangeSets wiki page to mention this explicitly:

Tom

 
On Tue, Nov 29, 2011 at 1:30 PM, Josh Blum <josh@joshknows.com> wrote:


On 11/29/2011 01:40 AM, Alex Zhang wrote:
> I am using the this example to test the installed next branch of josh:
>
> http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
>
> How ever, the digital_swig is not recognized. And I also checked the
> changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
>
> Nothing related is found.
>
>
> Traceback (most recent call last):
>   File "./pkt2.py", line 23, in <module>
>     import digital_swig
> ImportError: No module named digital_swig
>
> Can someone tell me where to find this package now?
>
>
>
Here is my digital python directory, what is yours missing that mine has?

> ls /usr/local/lib/python2.7/dist-packages/gnuradio/digital/
> bpsk.py                _digital_swig.la       __init__.py            ofdm.pyo               ofdm_sync_pn.py        psk2.pyc
> bpsk.pyc               digital_swig.py        __init__.pyc           ofdm_receiver.py       ofdm_sync_pn.pyc       psk.py
> bpsk.pyo               digital_swig.pyc       __init__.pyo           ofdm_receiver.pyc      ofdm_sync_pn.pyo       psk.pyc
> cpm.py                 digital_swig.pyo       modulation_utils2.py   ofdm_receiver.pyo      packet_utils.py        psk.pyo
> cpm.pyc                _digital_swig.so       modulation_utils2.pyc  ofdm_sync_fixed.py     packet_utils.pyc       qam.py
> cpm.pyo                dqpsk.py               modulation_utils.py    ofdm_sync_fixed.pyc    packet_utils.pyo       qam.pyc
> crc.py                 dqpsk.pyc              modulation_utils.pyc   ofdm_sync_fixed.pyo    pkt2.py                qam.pyo
> crc.pyc                generic_mod_demod.py   modulation_utils.pyo   ofdm_sync_ml.py        pkt2.pyc               qpsk.py
> crc.pyo                generic_mod_demod.pyc  ofdm_packet_utils.py   ofdm_sync_ml.pyc       pkt2.pyo               qpsk.pyc
> d8psk.py               generic_mod_demod.pyo  ofdm_packet_utils.pyc  ofdm_sync_ml.pyo       pkt.py                 qpsk.pyo
> d8psk.pyc              gmsk.py                ofdm_packet_utils.pyo  ofdm_sync_pnac.py      pkt.pyc                utils/
> dbpsk.py               gmsk.pyc               ofdm.py                ofdm_sync_pnac.pyc     pkt.pyo
> dbpsk.pyc              gmsk.pyo               ofdm.pyc               ofdm_sync_pnac.pyo     psk2.py


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--

Alex,
Dreams can come true – just believe.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] minimum value of pk to pk voltage of 10MHz reference

On 30/11/11 04:48 AM, Nakajo Tomoyuki wrote:
> Dear all,
>
> Please tell me the minimum value of pk-pk voltage of external 10MHz
> reference so that internal 100MHz clock is locked to the external 10MHz
> reference. (According to FAQ, the maximum value of pk-pk voltage is 3 volt)
>
> Best regards,
> Nakajo Tomoyuki
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#hardware-setup-notes

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD vs. USRP2 driver questions



2011/11/29 Kevin Tien <kvn.tien@gmail.com>
Hi,

We're using USRP2s with the RFX2400 daughterboards, and we've recently
switched from the old USRP drivers to the UHD drivers as per general
recommendation. However, we've run into a few problems that have us
stumped:

1) Previously, our receiver gains were set to 0 dB and we had no
problem receiving a signal with >30 or 40 dB SNR. However, now the UHD
receiver blocks need specified gain around 30 or 40 dB to achieve this
same performance; did baseline values change?

As far as I remember, there was something about the old driver sending out signals that were ints
The new driver sends and receives +/- 1, so you will need some more gain (38 dB I believe somone calculated)
 

 
 2) As far as we can tell through searching the Internet, the sampling 
rate in the Tx/Rx blocks has replaced the decimation and interpolation
fields from the legacy blocks. But what exactly are we specifying with
the sampling rate now? Is it the sampling rate the rate at which the
transmitter transmits samples, with interpolation assumed if the data
going into the block isn't throttled? In which case, would higher
sampling rate imply lower 'interpolation' rate? Bottom line, we have
no idea how to play around with the sample rate, or how important it
is.

The UHD driver sets up the interpolation rate for you.
It will select the interpolation rate most appropriatly close to 100MHz / requestedSamplerate

With the caveat that it first checks if it is dividable by two(for the first hb filter), if that result is dividable by two( for the second hb filter)  and if the final result is less than 128 (for the CIC) it will be set.

If you select an "unobtainable" sampling rate, the output will tell you. 

in pseudocode:

%%%%%%%%%%%%%% Mechanism for chosing HB filters and interprate %%%%%%%%%%%
%%%%%%%%%%%%%% root / host / lib / usrp / cores / tx_dsp_core_200.cpp %%%%
%
% if (interp_rate > 128) interp_rate &= ~0x1;//CIC up to 128, have to use 1 HB
% if (interp_rate > 256) interp_rate &= ~0x3;//CIC up to 128, have to use 2 HB
% size_t interp = interp_rate;
%
% //determine which half-band filters are activated
% int hb0 = 0, hb1 = 0;
% if (interp % 2 == 0)
% {
% hb0 = 1;
% interp /= 2;
% }
% if (interp % 2 == 0)
% {
% hb1 = 1;
% interp /= 2;
% }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thanks for your help,
Kevin Tien

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Best
Paul
--
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//

[Discuss-gnuradio] minimum value of pk to pk voltage of 10MHz reference

Dear all,

Please tell me the minimum value of pk-pk voltage of external 10MHz
reference so that internal 100MHz clock is locked to the external 10MHz
reference. (According to FAQ, the maximum value of pk-pk voltage is 3 volt)

Best regards,
Nakajo Tomoyuki

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Tuesday, November 29, 2011

Re: [Discuss-gnuradio] Issues with benchmark_tx and benchmark_rx codes

Hi Tom,

Thanks for the reply. I have a few more question on this regard and also some additional questions on benchmark_rx and tx. 

1. There is a 'thres' parameter in the receive_path.py code, associated with the benchmark_rx.py code. The default value is 30. It says, thres = 30, # in dB, will have to adjust. What does it mean?

2. Does the 'packet Ok = true' in benchmark_rx inherently perform a CRC check? I implemented a CRC separately in the received payload, i.e., I was watching if there is a single bit error in the packet. I saw that whenever the benchmark_rx says 'packet Ok = true', it passes my CRC test and vice versa. It can't be coincidence, can it? 

3. I am using the June 2011 version of gnuradio. My colleague just recently downloaded the latest version and he is trying to install the firmware in the SD cards. Now, with that June 2011 version, my benchmark tx and rx codes work predictably for gmsk modulation. By predictable, I mean that the codes work for --tx-ampl ranging from 0.05 to 0.9. At very low and high tx amplitude, it probably suffers from low signal strength and saturation. However, the dbpsk and dqpsk modulation work somewhat randomly, i.e., at one moment dbpsk may receive 100% packets at --tx-ampl 0.1. But, in the next moment, it may receive all packets as false at --tx-ampl 0.1. Therefore, I think that the problem is arising from the phase synchronization in the receiver. You talked in great details about control loop gain variables in http://gnuradio.squarespace.com/blog/2011/8/13/control-loop-gain-values.html. I just wonder which options in benchmark_rx are associated with these variables, i.e., the options that we can control? I can think of --costas-alpha, --gain-mu, alpha (in the receive_path.py code). Is there any other?

4. What is the difference between --costas-alpha (benchmark_rx option) and alpha (given with default value = 0.001 in the receive_path.py code)?

Sorry for the long email. Your feedback will be very appreciated.

Thanks,

Nazmul

On Sat, Nov 26, 2011 at 12:23 PM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Sat, Nov 26, 2011 at 12:13 PM, Nazmul Islam <mnislam@winlab.rutgers.edu> wrote:
Tom,

Thanks a lot for your reply. I appreciate it. I will upgrade to GNUradio 3.5. But I have a few more questions on the options.

1. Is there a roughly standard range of the option values that one should use? (the values of --tx-ampl, --tx-gain, --rx-gain, threshold, alpha, --costas-alpha, etc). For example, the values of alpha and thresh are given as 0.001 and 30 in the receive_path.py program. Shall I change these? If so, by how much? Are these values completely dependent on the local daughterboards?

No since this is going to depend more on what USRP and daughterboard you are using (or some other RF platform if it's not a USRP). We have not made any measurements or analysis of this (and if you do, I hope you will share it with the rest of us; since there are manufacturing tolerances on all of these, any measurement should also come with a range (max/avg/min)).

So right now, you're going to have to look at the output of your transmitter to see if there is any distortion and play with the signal levels to understand your system's behaviro.

 
2. Is there any file or document that describe these options in more details? From my communication systems course, I can roughly understand these options. But some options, e.g. the effect of --tx-ampl versus the effect of --tx-gain are not clear to me. 

Any feedback will be really appreciated.

Thanks,

Nazmul

No, there is nothing on this, yet. You're right that there should be though...

For now (so as to be cataloged on this mailing list at least), the difference between --tx-ampl and --tx-gain is this.

--tx-gain is a USRP/HW setting. It is the gain value (in dB) that is applied by the analog stages of the USRP and daughterboard.

--tx-ampl is a digital setting that sets the scale of the transmitted signal. In the UHD world, all signals are between +/-1, so this scaling factor should be < 1.0.

Tom

 
On Sat, Nov 26, 2011 at 11:36 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Wed, Nov 23, 2011 at 1:49 PM, Nazmul Islam <mnislam@winlab.rutgers.edu> wrote:
Hello All,

I am trying to measure packet error rates for different modulation schemes using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450 USRP2 dughterboard and I am using the UHD_003_002_001 image (That image was downloaded on June, 2011 from the website, I believe). Now, I am getting strange results in terms of packet error rate. The benchmark_rx codes don't receive anything for d8psk modulation. It receives packets for dqpsk and qbpsk,  but the work-ability depends on the inputs in a weird way. I am listing down some of the results that I have observed for different commands:

Scenario 1:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m dbpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 --gain-mu 0.01

Results: All packets receiverd.


Scenario 2:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dbpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05 --gain-mu 0.01

Results: All packets are received as false.( The only difference between scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20 to 25).)


Scenario 3:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m dqpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05 --gain-mu 0.01

Result: All packets are received as OK. (The difference between scenario 2 and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).)


Scenario 4:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m d8psk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05 --gain-mu 0.01

Result: No packet gets received. The receiver sits idle waiting for the packets.


I observed my transmitted signal in the spectrum analyzer and I did not see any carrier offset, i.e., the received signal was centered at 2.4 GHz. I think that the error is coming from either over-saturation of transmission signal or the costas-loop at the receiver. At present, I am simply walking in the dark and trying random input values to make the schemes work. Is there any suitable range for these options? (--tx-ampl, --tx-gain, --costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know if any of you have found a suitable range for these options. Your suggestions will be valuable.

Thanks for reading the long email.

Nazmul


Nazmul,
You could try upgrading to version 3.5 of GNU Radio. There are a lot of changes in the digital modulation blocks that might help. There's still some work to be done with them, but the recovery loops used are more stable to the parameter settings than previously. It should help.

My guess from your post above is that, yes, you are having some issues with overloading the transmitters.

Tom
 
 



--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.





--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

Re: [Discuss-gnuradio] USRP1 starts passing garbage data

On 11/29/2011 08:20 PM, Ryan Pape wrote:
>
> I have an application that runs 24/7 with a USRP1. I am having
> occasional problems where it appears the USRP (using UHD) starts
> returning garbage data after an apparently random period of time. In
> the most recent case, the app ran with no problem for approximately 36
> hours, although previously we have run as long as 7 days without an
> issue or restart (not all restarts are due to a problem).
>
> I don't believe I am running out of memory. The flow graph appears to
> continue to run, and I don't think the data is zeored out as I get
> occasional partial frame syncs (random) during this time.
>
> Restarting the app is sufficient to fix the problem - I don't have to
> recycle USRP or reseat USB.
>
> What would be the best place to look to determine the root cause?
>
Could you describe your set-up in more detail?

Do you get overruns before you start getting "garbage", and what is the
character of your "garbage" is it samples full of noise, or zeros,
or some other fixed value?

Do you have completely up-to-date UHD and Gnu Radio? What type of host
machine is it? OS?


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP1 starts passing garbage data


I have an application that runs 24/7 with a USRP1.  I am having occasional problems where it appears the USRP (using UHD) starts returning garbage data after an apparently random period of time.  In the most recent case, the app ran with no problem for approximately 36 hours, although previously we have run as long as 7 days without an issue or restart (not all restarts are due to a problem).

I don't believe I am running out of memory.  The flow graph appears to continue to run, and I don't think the data is zeored out as I get occasional partial frame syncs (random) during this time.

Restarting the app is sufficient to fix the problem - I don't have to recycle USRP or reseat USB.

What would be the best place to look to determine the root cause?

Re: [Discuss-gnuradio] UHD vs. USRP2 driver questions

On 11/29/2011 03:37 PM, Josh Blum wrote:
>
>
> On 11/29/2011 02:38 PM, Kevin Tien wrote:
>> Hi,
>>
>> We're using USRP2s with the RFX2400 daughterboards, and we've recently
>> switched from the old USRP drivers to the UHD drivers as per general
>> recommendation. However, we've run into a few problems that have us
>> stumped:
>>
>> 1) Previously, our receiver gains were set to 0 dB and we had no
>> problem receiving a signal with>30 or 40 dB SNR. However, now the UHD
>> receiver blocks need specified gain around 30 or 40 dB to achieve this
>> same performance; did baseline values change?
>>
>
> Are you selecting the correct antenna? Its possible the default RX
> antenna setting is different.
>

Yes, I believe the default under the old usrp drivers was "TX/RX". The
default under the new setup is "RX2". You can make a call
usrp->set_rx_antenna("TX/RX"). That should, in theory, restore the old
behavior (although I've seen what might be unpredictable behavior in
this mode - I don't know for sure though) unless you have some full
duplex shenanigans going on. Alternatively, you can just screw on an
antenna on the RX2 port and you should see a strong signal, which is the
approach I often use.

Arun

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD vs. USRP2 driver questions

>Are you selecting the correct antenna? Its possible the default RX
>antenna setting is different.

We'll check it out, but we only have the one antenna hooked up...
It'd be interesting to find out that the SMA connector can pick up the
signal! So I gather there should /not/ be any change in received SNR
values?

>The sample rate is the rate of samples between host and USRP.
>
>on RX: sample_rate = dsp_rate/decimation
>on TX: sample_rate = dsp_rate/interpolation

Ah okay great, thanks for your help.

--Kevin


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py

Hi Josh,

I have no d8psk*, dbpsk*, modulation_utils2*.
Which branch do you use for this?

On Tue, Nov 29, 2011 at 1:30 PM, Josh Blum <josh@joshknows.com> wrote:


On 11/29/2011 01:40 AM, Alex Zhang wrote:
> I am using the this example to test the installed next branch of josh:
>
> http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
>
> How ever, the digital_swig is not recognized. And I also checked the
> changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
>
> Nothing related is found.
>
>
> Traceback (most recent call last):
>   File "./pkt2.py", line 23, in <module>
>     import digital_swig
> ImportError: No module named digital_swig
>
> Can someone tell me where to find this package now?
>
>
>
Here is my digital python directory, what is yours missing that mine has?

> ls /usr/local/lib/python2.7/dist-packages/gnuradio/digital/
> bpsk.py                _digital_swig.la       __init__.py            ofdm.pyo               ofdm_sync_pn.py        psk2.pyc
> bpsk.pyc               digital_swig.py        __init__.pyc           ofdm_receiver.py       ofdm_sync_pn.pyc       psk.py
> bpsk.pyo               digital_swig.pyc       __init__.pyo           ofdm_receiver.pyc      ofdm_sync_pn.pyo       psk.pyc
> cpm.py                 digital_swig.pyo       modulation_utils2.py   ofdm_receiver.pyo      packet_utils.py        psk.pyo
> cpm.pyc                _digital_swig.so       modulation_utils2.pyc  ofdm_sync_fixed.py     packet_utils.pyc       qam.py
> cpm.pyo                dqpsk.py               modulation_utils.py    ofdm_sync_fixed.pyc    packet_utils.pyo       qam.pyc
> crc.py                 dqpsk.pyc              modulation_utils.pyc   ofdm_sync_fixed.pyo    pkt2.py                qam.pyo
> crc.pyc                generic_mod_demod.py   modulation_utils.pyo   ofdm_sync_ml.py        pkt2.pyc               qpsk.py
> crc.pyo                generic_mod_demod.pyc  ofdm_packet_utils.py   ofdm_sync_ml.pyc       pkt2.pyo               qpsk.pyc
> d8psk.py               generic_mod_demod.pyo  ofdm_packet_utils.pyc  ofdm_sync_ml.pyo       pkt.py                 qpsk.pyo
> d8psk.pyc              gmsk.py                ofdm_packet_utils.pyo  ofdm_sync_pnac.py      pkt.pyc                utils/
> dbpsk.py               gmsk.pyc               ofdm.py                ofdm_sync_pnac.pyc     pkt.pyo
> dbpsk.pyc              gmsk.pyo               ofdm.pyc               ofdm_sync_pnac.pyo     psk2.py


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--

Alex,
Dreams can come true – just believe.

Re: [Discuss-gnuradio] UHD vs. USRP2 driver questions

On 11/29/2011 02:38 PM, Kevin Tien wrote:
> Hi,
>
> We're using USRP2s with the RFX2400 daughterboards, and we've recently
> switched from the old USRP drivers to the UHD drivers as per general
> recommendation. However, we've run into a few problems that have us
> stumped:
>
> 1) Previously, our receiver gains were set to 0 dB and we had no
> problem receiving a signal with >30 or 40 dB SNR. However, now the UHD
> receiver blocks need specified gain around 30 or 40 dB to achieve this
> same performance; did baseline values change?
>

Are you selecting the correct antenna? Its possible the default RX
antenna setting is different.

> 2) As far as we can tell through searching the Internet, the sampling
> rate in the Tx/Rx blocks has replaced the decimation and interpolation
> fields from the legacy blocks. But what exactly are we specifying with
> the sampling rate now? Is it the sampling rate the rate at which the
> transmitter transmits samples, with interpolation assumed if the data
> going into the block isn't throttled? In which case, would higher
> sampling rate imply lower 'interpolation' rate? Bottom line, we have
> no idea how to play around with the sample rate, or how important it
> is.
>

The sample rate is the rate of samples between host and USRP.

on RX: sample_rate = dsp_rate/decimation
on TX: sample_rate = dsp_rate/interpolation

-josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD vs. USRP2 driver questions

Hi,

We're using USRP2s with the RFX2400 daughterboards, and we've recently
switched from the old USRP drivers to the UHD drivers as per general
recommendation. However, we've run into a few problems that have us
stumped:

1) Previously, our receiver gains were set to 0 dB and we had no
problem receiving a signal with >30 or 40 dB SNR. However, now the UHD
receiver blocks need specified gain around 30 or 40 dB to achieve this
same performance; did baseline values change?

2) As far as we can tell through searching the Internet, the sampling
rate in the Tx/Rx blocks has replaced the decimation and interpolation
fields from the legacy blocks. But what exactly are we specifying with
the sampling rate now? Is it the sampling rate the rate at which the
transmitter transmits samples, with interpolation assumed if the data
going into the block isn't throttled? In which case, would higher
sampling rate imply lower 'interpolation' rate? Bottom line, we have
no idea how to play around with the sample rate, or how important it
is.

Thanks for your help,
Kevin Tien

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py

On 11/29/2011 10:57 AM, Tom Rondeau wrote:
> On Tue, Nov 29, 2011 at 1:40 AM, Alex Zhang <cingular.alex@gmail.com> wrote:
>
>> I am using the this example to test the installed next branch of josh:
>>
>> http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
>>
>> How ever, the digital_swig is not recognized. And I also checked the changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
>>
>> Nothing related is found.
>>
>>
>> Traceback (most recent call last):
>> File "./pkt2.py", line 23, in <module>
>> import digital_swig
>> ImportError: No module named digital_swig
>>
>> Can someone tell me where to find this package now?
>>
>> --
>>
>> Alex,
>> *Dreams can come true – just believe.*
>>
>
>
> It looks like you have some left-over code laying around. The pkt2.py is
> gone and we use pkt.py now, instead. Something must have gotten left behind
> with a checkout or merge at some point.
>

Sorry for the correction, pkt2 is my doing. I re-implemented pkt.py with
message passing capabilities.

> As for the digital_swig, that's the "real" name of the SWIG'd-up gr-digital
> module that we export into digital. The internal gr-digital python modules
> use digital_swig, though.
>
> Make sure you've cleaned up previous installs, to a git clean -dxf in your
> gnuradio checkout and reinstall. Hopefully that'll fix your problems.
>

I think Alex is importing pkt2.py from in-tree and not from an installed
location.

-josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py

On 11/29/2011 01:40 AM, Alex Zhang wrote:
> I am using the this example to test the installed next branch of josh:
>
> http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
>
> How ever, the digital_swig is not recognized. And I also checked the
> changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
>
> Nothing related is found.
>
>
> Traceback (most recent call last):
> File "./pkt2.py", line 23, in <module>
> import digital_swig
> ImportError: No module named digital_swig
>
> Can someone tell me where to find this package now?
>
>
>
Here is my digital python directory, what is yours missing that mine has?

> ls /usr/local/lib/python2.7/dist-packages/gnuradio/digital/
> bpsk.py _digital_swig.la __init__.py ofdm.pyo ofdm_sync_pn.py psk2.pyc
> bpsk.pyc digital_swig.py __init__.pyc ofdm_receiver.py ofdm_sync_pn.pyc psk.py
> bpsk.pyo digital_swig.pyc __init__.pyo ofdm_receiver.pyc ofdm_sync_pn.pyo psk.pyc
> cpm.py digital_swig.pyo modulation_utils2.py ofdm_receiver.pyo packet_utils.py psk.pyo
> cpm.pyc _digital_swig.so modulation_utils2.pyc ofdm_sync_fixed.py packet_utils.pyc qam.py
> cpm.pyo dqpsk.py modulation_utils.py ofdm_sync_fixed.pyc packet_utils.pyo qam.pyc
> crc.py dqpsk.pyc modulation_utils.pyc ofdm_sync_fixed.pyo pkt2.py qam.pyo
> crc.pyc generic_mod_demod.py modulation_utils.pyo ofdm_sync_ml.py pkt2.pyc qpsk.py
> crc.pyo generic_mod_demod.pyc ofdm_packet_utils.py ofdm_sync_ml.pyc pkt2.pyo qpsk.pyc
> d8psk.py generic_mod_demod.pyo ofdm_packet_utils.pyc ofdm_sync_ml.pyo pkt.py qpsk.pyo
> d8psk.pyc gmsk.py ofdm_packet_utils.pyo ofdm_sync_pnac.py pkt.pyc utils/
> dbpsk.py gmsk.pyc ofdm.py ofdm_sync_pnac.pyc pkt.pyo
> dbpsk.pyc gmsk.pyo ofdm.pyc ofdm_sync_pnac.pyo psk2.py


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py

Just found the digital_swig.py is located at /usr/local/lib/python2.7/dist-packages/gnuradio/digital
So I change "import digital_swig" to "from gnuradio.digital import digital_swig"  and the complaining disappeared. Seems for these python modules, i still need to give a full path, even I have imported the gnuradio, gnuradio.digital in the beginning of the code.

On Tue, Nov 29, 2011 at 9:57 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Tue, Nov 29, 2011 at 1:40 AM, Alex Zhang <cingular.alex@gmail.com> wrote:
I am using the this example to test the installed next branch of josh:
http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
How ever, the digital_swig is not recognized. And I also checked the changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
Nothing related is found. 

Traceback (most recent call last):   File "./pkt2.py", line 23, in <module>     import digital_swig ImportError: No module named digital_swig 
Can someone tell me where to find this package now?

--

Alex,
Dreams can come true – just believe.


It looks like you have some left-over code laying around. The pkt2.py is gone and we use pkt.py now, instead. Something must have gotten left behind with a checkout or merge at some point.

As for the digital_swig, that's the "real" name of the SWIG'd-up gr-digital module that we export into digital. The internal gr-digital python modules use digital_swig, though.

Make sure you've cleaned up previous installs, to a git clean -dxf in your gnuradio checkout and reinstall. Hopefully that'll fix your problems.

Tom
 



--

Alex,
Dreams can come true – just believe.

Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector

On Tue, Nov 29, 2011 at 11:32 AM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 29-11-2011 11:12 AM, Sebastian Döring wrote:
On Mon, 28 Nov 2011 10:32:28 -0500
 "Marcus D. Leech" <mleech@ripnet.com> wrote:
On 28-11-2011 10:21 AM, Sebastian Döring wrote:
Hello List,

just wanted to know exactly how the output vector of ..._rx_cfile.py is structured.
Is the first element of the complex vector v[0] the one at the desired frequency sprecified by "-f FREQ"?

Thanks

Sebastian

'
It's just raw complex-float samples in native-binary format.

The first item is I the second is Q then I then Q, etc.

They're time-series samples, not FFT outputs.




Uh ok -  explains a lot...
Since the data is getting recorded as 32-bit complex float, is "read_complex_binary()" the right octave method to put it into a vector I can use for further processing?
I found a gnuradio page that says "read_short_binary()" is supposed to be the right method, but the output vector does not make any sense to me...

Regards
Sebastian


Yup, read_complex_binary() is the one, as far as I can tell.  I'm not a MatLab/Octave user, but it seems like that reads complex-floats.

Yes, that should work for you. The "read_short_binary()" should be usable if you use the '-s' flag in the uhd_rx_cfile.py to output shorts. I think you'll have to deinterleave the I&Q after you read it in, IIRC.

Tom

Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector

On 29-11-2011 11:12 AM, Sebastian Döring wrote:
> On Mon, 28 Nov 2011 10:32:28 -0500
> "Marcus D. Leech" <mleech@ripnet.com> wrote:
>> On 28-11-2011 10:21 AM, Sebastian Döring wrote:
>>> Hello List,
>>>
>>> just wanted to know exactly how the output vector of ..._rx_cfile.py
>>> is structured.
>>> Is the first element of the complex vector v[0] the one at the
>>> desired frequency sprecified by "-f FREQ"?
>>>
>>> Thanks
>>>
>>> Sebastian
>>>
>>> '
>> It's just raw complex-float samples in native-binary format.
>>
>> The first item is I the second is Q then I then Q, etc.
>>
>> They're time-series samples, not FFT outputs.
>>
>>
>>
>>
> Uh ok - explains a lot...
> Since the data is getting recorded as 32-bit complex float, is
> "read_complex_binary()" the right octave method to put it into a
> vector I can use for further processing?
> I found a gnuradio page that says "read_short_binary()" is supposed to
> be the right method, but the output vector does not make any sense to
> me...
>
> Regards
> Sebastian
>
>
Yup, read_complex_binary() is the one, as far as I can tell. I'm not a
MatLab/Octave user, but it seems like that reads complex-floats.


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector

On Mon, 28 Nov 2011 10:32:28 -0500
"Marcus D. Leech" <mleech@ripnet.com> wrote:
> On 28-11-2011 10:21 AM, Sebastian Döring wrote:
>> Hello List,
>>
>> just wanted to know exactly how the output vector of
>>..._rx_cfile.py is structured.
>> Is the first element of the complex vector v[0] the one
>>at the desired frequency sprecified by "-f FREQ"?
>>
>> Thanks
>>
>> Sebastian
>>
>> '
> It's just raw complex-float samples in native-binary
>format.
>
> The first item is I the second is Q then I then Q, etc.
>
> They're time-series samples, not FFT outputs.
>
>
>
>
Uh ok - explains a lot...
Since the data is getting recorded as 32-bit complex
float, is "read_complex_binary()" the right octave method
to put it into a vector I can use for further processing?
I found a gnuradio page that says "read_short_binary()" is
supposed to be the right method, but the output vector
does not make any sense to me...

Regards
Sebastian


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py

On Tue, Nov 29, 2011 at 1:40 AM, Alex Zhang <cingular.alex@gmail.com> wrote:
I am using the this example to test the installed next branch of josh:
http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
How ever, the digital_swig is not recognized. And I also checked the changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
Nothing related is found. 

Traceback (most recent call last):   File "./pkt2.py", line 23, in <module>     import digital_swig ImportError: No module named digital_swig 
Can someone tell me where to find this package now?

--

Alex,
Dreams can come true – just believe.


It looks like you have some left-over code laying around. The pkt2.py is gone and we use pkt.py now, instead. Something must have gotten left behind with a checkout or merge at some point.

As for the digital_swig, that's the "real" name of the SWIG'd-up gr-digital module that we export into digital. The internal gr-digital python modules use digital_swig, though.

Make sure you've cleaned up previous installs, to a git clean -dxf in your gnuradio checkout and reinstall. Hopefully that'll fix your problems.

Tom
 

Re: [Discuss-gnuradio] Anyone do you know good GPS receiver Method?

I had never heard of fastGPS; sounds pretty useful.  What is the end goal for your receiver? 

Ryan

On Tue, Nov 29, 2011 at 5:10 AM, Nick Othieno <nickothieno@gmail.com> wrote:
I am using fastGPS to do the correlation as well as writing my own MATLAB correlation scripts.

Nick


On Fri, Nov 25, 2011 at 8:40 PM, Nick Foster <nick@ettus.com> wrote:
On Fri, Nov 25, 2011 at 7:01 AM, Nick Othieno <nickothieno@gmail.com> wrote:
> Hi Ryan,
>
> What did you use for your setup, ie daughterboards, antenna and LNA (if you
> do not mind my asking). I have been trying a setup for months that uses a
> DBSRX2 and a mighty mouse 2 antenna only, but I have never been able to
> acquire the L1 signal. I am wondering where I have gone wrong in the setup.

I've successfully used a DBSRX + active antenna to receive GPS signals
before. What software are you using to do the correlation and find the
L1 signal?

--n

>
> Nick
>
> On Fri, Nov 18, 2011 at 9:47 AM, Wolfarth, Ryan <wolfarra@muohio.edu> wrote:
>>
>> Hi folks,
>>
>> My group is using USRPs to do the task Kouki described, although our flow
>> diagram is a little different.  We only use the USRP2 to receive the raw RF
>> data which is written to file.  This data is processed to the point where we
>> decode the navigation bits, but no position is ever found.  We're more
>> interested in the effects of ionosphere scintillations on GNSS signal
>> structure so we don't need to calculate antenna position.
>>
>> I can recommend two books that have helped me immensely.  The Kaplan "blue
>> book:"
>>
>>
>> http://www.amazon.com/Understanding-GPS-Principles-Applications-Second/dp/1580538940/ref=sr_1_1?ie=UTF8&qid=1321627222&sr=8-1
>>
>> And the Kaplan "blue book:"
>>
>> http://www.gpstextbook.com/
>>
>> I do know of a group that has used a USRP1 to develop a 4 channel L1
>> receiver, but they had to modify the FPGA to do all the real time
>> processing.  Let me know if you have additional questions!
>>
>> -Ryan
>>
>> On Fri, Nov 18, 2011 at 7:56 AM, Brian Padalino <bpadalino@gmail.com>
>> wrote:
>>>
>>> 2011/11/18 山本弘貴 <k.yamamoto.0819@gmail.com>:
>>> > Hi, All
>>> > I have  very trouble
>>> > My experiment enviroment isUBUNTU 11.04 , USRP N200, DBSRX2 ,active
>>> > antenna and gnuradio
>>> > I am worrying about good software GPS receiver is not exist .
>>> > I want to receive L1 signal , and want to demodulate that signal
>>> > However GPS signal is used  Spread spectrum modulation scheme.
>>> > I try to creating gnuradio-companion's blocks.(use to Spread spectrum
>>> > demodulation blocks)
>>> > but that is very difficult so Now I think method is
>>> >
>>> >  GPS L1 signal → USRP N200 → gnuradio-companion(UHD_source→File_sink)
>>> > → software decode soft → output(Location data)
>>> >
>>> >
>>> > Eventually I want to Calculate location data,
>>> > Please let me know if you're a good this way
>>>
>>> I recently came across this product listing at Spark Fun:
>>>
>>>    http://www.sparkfun.com/products/10981
>>>
>>> Which has a link to a book all about GPS receiving and even comes with
>>> MATLAB source code:
>>>
>>>
>>>  http://www.amazon.com/Software-Defined-GPS-Galileo-Receiver-Single-Frequency/dp/0817643907
>>>
>>> I am sure, with the source, you could adapt it to use the USRP
>>> recorded signal, and then possibly port the MATLAB over to either
>>> Python (using Josh's signal processing in Python blocks) or straight
>>> C++.
>>>
>>> > I am sorry that My English is not good
>>> >
>>> > Kouki
>>>
>>> Good luck - it's definitely not a trivial task, but it sounds extremely
>>> fun.
>>>
>>> Brian
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


[Discuss-gnuradio] Spectral Estimation Toolbox: GUI and cyclo estimator now available

Hi list,

the SpecEst toolbox has more fun and exciting stuff:
- First thing is a GUI. It connects to a file or UHD and can show live
spectral estimates of the incoming signal using any of the existing
estimators. For simple debugging purpose, this is not as useful as
uhd_fft.py, but it's a great tool to show how different estimators
(parametric vs. non-parametric) work. And have you ever seen a live
ESPRIT based sinusoid tracker?
- Cyclostationary estimation is now also possible. This is not
integrated into the GUI, as the output is completely different, but
comes with demo app that uses Matplotlib to show stuff that's going on
(very slow, though!). There's a small example script that uses the
output of the cyclo estimator to distinguish QPSK and BPSK, just to
see how this can be used.

As usual, it's all on our github. You can find it all
at https://www.cgran.org/wiki/SpecEst.

Happy spectral estimating,
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

[Discuss-gnuradio] A function named "usb_control_msg"

Dear everyone:
      You see in usrp_basic.h there is a function named _write_9862() and it uses function usrp_9862_write(),defined in usrp_prims_common.h. And usrp_9862_write() uses function usrp_spi_write(), also defined in usrp_prims_common.h.
usrp_spi_write() uses function write_cmd(), defined in usrp_prims_libusb0.c and usrp_prims_libusb1.c.
     In usrp_prims_libusb0.c write_cmd() uses a function named usb_control_msg(). But I can not find where usb_control_msg() is. Can anyone tell me where it is???


Re: [Discuss-gnuradio] Anyone do you know good GPS receiver Method?

I am using fastGPS to do the correlation as well as writing my own MATLAB correlation scripts.

Nick

On Fri, Nov 25, 2011 at 8:40 PM, Nick Foster <nick@ettus.com> wrote:
On Fri, Nov 25, 2011 at 7:01 AM, Nick Othieno <nickothieno@gmail.com> wrote:
> Hi Ryan,
>
> What did you use for your setup, ie daughterboards, antenna and LNA (if you
> do not mind my asking). I have been trying a setup for months that uses a
> DBSRX2 and a mighty mouse 2 antenna only, but I have never been able to
> acquire the L1 signal. I am wondering where I have gone wrong in the setup.

I've successfully used a DBSRX + active antenna to receive GPS signals
before. What software are you using to do the correlation and find the
L1 signal?

--n

>
> Nick
>
> On Fri, Nov 18, 2011 at 9:47 AM, Wolfarth, Ryan <wolfarra@muohio.edu> wrote:
>>
>> Hi folks,
>>
>> My group is using USRPs to do the task Kouki described, although our flow
>> diagram is a little different.  We only use the USRP2 to receive the raw RF
>> data which is written to file.  This data is processed to the point where we
>> decode the navigation bits, but no position is ever found.  We're more
>> interested in the effects of ionosphere scintillations on GNSS signal
>> structure so we don't need to calculate antenna position.
>>
>> I can recommend two books that have helped me immensely.  The Kaplan "blue
>> book:"
>>
>>
>> http://www.amazon.com/Understanding-GPS-Principles-Applications-Second/dp/1580538940/ref=sr_1_1?ie=UTF8&qid=1321627222&sr=8-1
>>
>> And the Kaplan "blue book:"
>>
>> http://www.gpstextbook.com/
>>
>> I do know of a group that has used a USRP1 to develop a 4 channel L1
>> receiver, but they had to modify the FPGA to do all the real time
>> processing.  Let me know if you have additional questions!
>>
>> -Ryan
>>
>> On Fri, Nov 18, 2011 at 7:56 AM, Brian Padalino <bpadalino@gmail.com>
>> wrote:
>>>
>>> 2011/11/18 山本弘貴 <k.yamamoto.0819@gmail.com>:
>>> > Hi, All
>>> > I have  very trouble
>>> > My experiment enviroment isUBUNTU 11.04 , USRP N200, DBSRX2 ,active
>>> > antenna and gnuradio
>>> > I am worrying about good software GPS receiver is not exist .
>>> > I want to receive L1 signal , and want to demodulate that signal
>>> > However GPS signal is used  Spread spectrum modulation scheme.
>>> > I try to creating gnuradio-companion's blocks.(use to Spread spectrum
>>> > demodulation blocks)
>>> > but that is very difficult so Now I think method is
>>> >
>>> >  GPS L1 signal → USRP N200 → gnuradio-companion(UHD_source→File_sink)
>>> > → software decode soft → output(Location data)
>>> >
>>> >
>>> > Eventually I want to Calculate location data,
>>> > Please let me know if you're a good this way
>>>
>>> I recently came across this product listing at Spark Fun:
>>>
>>>    http://www.sparkfun.com/products/10981
>>>
>>> Which has a link to a book all about GPS receiving and even comes with
>>> MATLAB source code:
>>>
>>>
>>>  http://www.amazon.com/Software-Defined-GPS-Galileo-Receiver-Single-Frequency/dp/0817643907
>>>
>>> I am sure, with the source, you could adapt it to use the USRP
>>> recorded signal, and then possibly port the MATLAB over to either
>>> Python (using Josh's signal processing in Python blocks) or straight
>>> C++.
>>>
>>> > I am sorry that My English is not good
>>> >
>>> > Kouki
>>>
>>> Good luck - it's definitely not a trivial task, but it sounds extremely
>>> fun.
>>>
>>> Brian
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

Monday, November 28, 2011

[Discuss-gnuradio] can not import digital_swig for the example of pkt.py

I am using the this example to test the installed next branch of josh:
http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next
How ever, the digital_swig is not recognized. And I also checked the changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets
Nothing related is found. 

Traceback (most recent call last):   File "./pkt2.py", line 23, in <module>     import digital_swig ImportError: No module named digital_swig 
Can someone tell me where to find this package now?

--

Alex,
Dreams can come true – just believe.