[Discuss-gnuradio] [UHD] Release Announcement 3.9.0

Dear USRP users,

after nearly 2 weeks of testing, the release candidate was deemed fit
(with minor changes) for release, and as such I present the 3.9.0
release of UHD!

The list of changes is pretty long, so I'll refer to the changelog for
details. Packagers and developers building from source will need to make
sure to update the list of dependencies: Since 3.8.5, ORC has been
removed, Cheetah was replaced by Mako (note: this is a build dependency,
not a runtime dependency!), and python-requests is required to run our
Py3k-compatible version of uhd_images_downloader.

Devices with integrated RFIC have received a lot of feature updates, but
also signal integrity improvements. The same goes for the X-Series
devices. The B200mini, which was announced and demoed at GRCon last
week, will work with this release as soon as it's available.

Developers will find some UHD changes that might come in handy. An API
for using UHD from C is now available (can be disabled at compile-time,
though). multi_usrp has received a couple of new functions, as well.

This is just a high-level list of changes! Have a peek at the changelog
below for details, or the git commit logs for even more detail.

Tarballs and installers for Debian and Fedora are online, as well as the
updated manual.

As usual, this resets maint branch to master. Going forward, we will
continue to fix bugs on maint, and add features on master, which will
become the next release (3.10) eventually. So, as usual, users
interested in the most stable code should stick to our maint branch.

The tag for this release is available here:
https://github.com/EttusResearch/uhd/tree/release_003_009_000

Cheers,
Martin


## 003.009.000
* X300: Updated DAC ctrl, FPGA toolchain is now entirely Vivado,
improved master clock controls, added ADC self-cal capability,
prepared for revisions 7 and 8, fixed flow control issue which
could cause device to hang when receiving too many overruns
* B2XX: Auto clock rate setting, added PID/VID pairs to support
all B2XX- and derivatives, added temperature sensor, improved
DC offset and IQ imbalance correction, added AGC support,
support for FPGPIO connector on Rev6+ boards, full clock range support,
updated FX3 firmware (side-channel logging capabilities, updated
tx voltage swing, better configurability), default tick rate now
16 MHz, added B200mini support
* E3XX: Added temperature sensor, FPGA toolchain is now entirely Vivado,
improved DC offset and IQ imbalance correction, added AGC support,
improved FPGA capture interface robustness for RFIC, make frame
sizes configurable, replaced GPS control code with gpsd interfacing
capabilities
* Octoclock: Fixed bootloader + ethernet capabilities
* Compilers: Supported MSVC versions are now 2012, 2013, 2015
(dropped 2010 support), added MinGW capabilities
* Documentation: Many minor fixes and updates, merged all the
info from code.ettus.com
* UHD: Added sid_t, CHDR-specific transports now get their own
(un)packer codes, fixed a lot of compiler warnings, added
filter API (currently available for AD9361 frontend), added
soft-register API, replaced Cheetah with Mako, full Py3k
compliance, updated images downloader tool (now is one tool
for all devices), CMake minimum version is now 2.8, refactored
general AD9361 peripheral management, refactored most core
control management, added usb_error type (used by B2xx devices),
better exception handling at runtime, added C wrapper API,
new dependency: python-requests
* C API: Added to UHD (wraps C++ calls in C)
* multi_usrp: Added normalized gain setters/getters, IQ imbalance
+ DC offset correction API, filter API
* Converters: Converter symbols now exported, better logging,
removed ORC dependency, added u8 converters
* Examples: Whitespace- and other cleanup, multi-channel fixes for
some examples
* Utils: Read more property tree types from the command line
* Tools: kitchen sink updated, added mega_fft

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

Re: [Discuss-gnuradio] FSK receiver

Thank you Rich,
I have added Rational Resample with the formular : Fs_out = Fs_in x Interpolation / Decimation

Then the grc run without error.

On Fri, Aug 28, 2015 at 7:03 PM, Richard Bell <richard.bell4@gmail.com> wrote:

Hi Hoang,

Yes it's a problem with your design. You have 2 Msps feeding into an audio sink that probably goes up to 48 ksps. You need to change your sample rate from 2 Msps to a rate your sound card supports. I would target one of the default rates you can select from the audio sink. You can use polyphase arbitrary resampler block with the proper resampling ratio 2M/48k entered leaving the taps blank and the other parameters to default.

Hope that helps,

Rich

On Fri, Aug 28, 2015 at 2:19 PM, Hoang Nguyen Tran <hoangnt09@gmail.com> wrote:

Dear all,

I have just built a FSK receiver aim to receive Cubesat data with FSK modulation with 9600 baud rate, below is my flow graph.

I have just tested it with usb dongle RTL-SDR, however when I'm using audio sink, I received  OOOOO (overrun I think) continuously .
Does it have anything wrong with my set up ?

samplerate 2M

cut off freq 9600

transition 4800

I really appriciate for any comment on my FSK receiver flowgraph, I am a newbie :)

Thank you and best regard,

Hoang

--

 -HoangNT-
PhoneNo :  +841654248782

Skype : hoangastro

FB : https://www.facebook.com/kenshin.rorouni

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

--

 -HoangNT-
PhoneNo :  +841654248782

Skype : hoangastro

FB : https://www.facebook.com/kenshin.rorouni

Re: [Discuss-gnuradio] USRP N210

Hey Abs,

we'll need more info than that to help you. Also, please don't forget to
respond to the mailing list. So, please supply more info about your
setup, what exactly you're doing etc.

Thanks,
Martin

On 31.08.2015 15:30, Abdeslam Bourkane wrote:
> Hi Martin,
>
> Thank you for your reply. I have problem running the
> usrp_spectrum_sense.py I thought maybe the max_power.py that caused the
> problem.
> The problem is that I cannot get the power any more it just showing an
> output of ~ 5dB ! Before I got ~14 dB ! when connecting N210 to the feed.
> I don't know why any help would be much appreciated.
> Regards
> Abs
>
> *Abdeslam Bourkane*
>
> On 31 August 2015 at 23:57, Martin Braun <martin.braun@ettus.com
> <mailto:martin.braun@ettus.com>> wrote:
>
> Hi Abs,
>
> it's just a flow graph that'll receive and transmit at max gain. You
> don't have to revert the settings, they're not persistent.
>
> Cheers,
> Martin
>
> On 31.08.2015 14 <tel:31.08.2015%2014>:46, Abdeslam Bourkane wrote:
> > Hello,
> >
> > What is the result/consequence of running the max_power.py on USRP2 ?
> > How to revert back ?
> >
> > Thank you
> > Abs
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto: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] Gain and Sample Rate Setting

Thank you for the reply Martin. I have changed the benchmark_tx.py
script and there seems to be different error to have occured.

Using Volk machine: avx_64_mmx
Traceback (most recent call last):
File "./benchmark_tx.py", line 154, in <module>
main()
File "./benchmark_tx.py", line 118, in main
tb = my_top_block(mods[options.modulation], options)
File "./benchmark_tx.py", line 54, in __init__
options.lo_offset, options.tx_gain,
AttributeError: Values instance has no attribute 'lo_offset'

Is this error also the same thing as you have explained earlier which
might be a bug or is it something else? I don't know why there errors
are suddenly recurring because I have already tried to send the data
packets and the transmitter seemed to be fine that day. Please help me
with this as I am new to this.

Thanks,
Ben

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] USRP N210

Hi Abs,

it's just a flow graph that'll receive and transmit at max gain. You
don't have to revert the settings, they're not persistent.

Cheers,
Martin

On 31.08.2015 14:46, Abdeslam Bourkane wrote:
> Hello,
>
> What is the result/consequence of running the max_power.py on USRP2 ?
> How to revert back ?
>
> Thank you
> Abs
>
>
> _______________________________________________
> 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] USRP N210

Hello,

What is the result/consequence of running the max_power.py on USRP2 ?

How to revert back ?

Thank you

Abs

Re: [Discuss-gnuradio] Gain and Sample Rate Setting

On 30.08.2015 16:15, Ben Gustin wrote:
> File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 70, in set_sample_rate
> asked_samp_rate = bitrate * req_sps
> TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

This is what you want to track down. See what req_sps is in the file
mentioned above, and where it's set.
If your receiver is working, this seems like some simple Python bug.

> But the receiver is working just fine. I don't know what mistake is
> present in my benchmark transmission file. Please help me with this. I
> am attaching the same benchmark scripts.

If you want to attach files, I suggest you subscribe to the mailing list
instead of using 'ruby forum'. Most people handle the mailing list in
this way.

Cheers,
Martin

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

Re: [Discuss-gnuradio] Gain and Sample Rate Setting

Please Help with this problem.

Thanks,
Ben

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] ofdm plateau_detector_fb_impl//ofdm_sync_sc_cfb_impl

On 31.08.2015 07:15, zs wrote:
> According to the step 2 and step3, we copy the
> d_items_per_symbol * d_itemsize bytes after (in + d_gi * d_itemsize) to
> the output.In the example, cdef+abcdef,the d_gi is 4. (in + d_gi *
> d_itemsize) will correspond to the c.Then output d_items_per_symbol is
> 6,then output cdef..But the true head data is abcdef,so I think maybe
> the source code have some problems.Is my understanding right?

Not sure I'm understanding you correctly, but maybe these factoids help you:

- If you check out ofdm_rx.grc, you'll see a couple of delays that try
and align things.
- The qa_ofdm_*.py files check the OFDM stuff pretty exhaustively, and
you might be interested in qa_ofdm_sync_sc_cfb.py in particular.
- If we start copying at the first 'e' in your example, the receiver
will still work fine (minus a phase offset).

Cheers,
Martin

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

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

Thanks a lot.

It works!!

At least it doesn't show an error in the code.

Now, I'm going to test the system.

thanks for your help

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

time_spec_t() is a helper function in class "uhd", it is not a method in a uhd.usrp_source/sink.

 

self.cmd_time = uhd.time_spec_t(0.1)

 

Would be the correct idiom.

 

 

 

 

On 2015-08-31 15:31, Tibisay Sanchez wrote:

my line is    self.cmd_time = self.uhd_usrp_source_0.uhd.time_spec_t(.1)    but it shows an error when it calls uhd.time_spec_t(.1)    it says usrp_source_sptr' object has no attribute 'uhd_time_spect_t'.    I need both LO are align to synch the phase  

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

my line is

self.cmd_time = self.uhd_usrp_source_0.uhd.time_spec_t(.1)

but it shows an error when it calls uhd.time_spec_t(.1)

it says usrp_source_sptr' object has no attribute 'uhd_time_spect_t'.

I need both LO are align to synch the phase

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Dr Mitola's Keynote slides

Hi Jason - Our hope is to get slides from Dr Mitola as well as
permission from Paul Tilghman / DARPA to release his slides. I have
queries into both of them, and am waiting to hear back from the former.
Maybe Tom can query Mitola specifically about this topic as well? No
promises, but these are our hopes. - MLD

On Mon, Aug 31, 2015, at 02:40 PM, Jason Matusiak wrote:
> I was wondering if there were plans to get Dr Mitola's slides from his Keynote talk at GRCON15 on the website? I had made some notes to look at a couple of things in there, but I just noticed that there isn't even a COMING SOON dead link for his slides, so I didn't know if he asked for them not to be published.

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

[Discuss-gnuradio] Dr Mitola's Keynote slides

I was wondering if there were plans to get Dr Mitola's slides from his Keynote talk at GRCON15 on the website? I had made some notes to look at a couple of things in there, but I just noticed that there isn't even a COMING SOON dead link for his slides, so I didn't know if he asked for them not to be published.

Re: [Discuss-gnuradio] Changing code rate (FEC)

Thank you for your reply. So from what I understand, code rates other
than the default one are untested and the code rate is difficult to
change? Also, I still can't read the video at the output of the decoder.
I used the highly optimized default values (R=2, K=7, poly: 79, 109) and
the output of the decoder is still different that my input signal
(before the encoder) so I'm unable to read my output video. Is there
something that I'm missing? Thanks.

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Changing code rate (FEC)

On Wed, Aug 26, 2015 at 8:07 PM, Eric Eric <lists@ruby-forum.com> wrote:

Hi,

I would like to be able to change the code rate with PSK and QAM
modulations (e.g QPSK 3/4, 16QAM 1/2). I was thinking of using a FEC
encoder/decoder as you can see in the attached files but it doesn't
really work. I'm trying to send a video file and I would like to be able
to read the received video. What can I do to make it work or is there
another way to change the coding rate?

Thanks

Attachments:
http://www.ruby-forum.com/attachment/11055/fec1.jpg
http://www.ruby-forum.com/attachment/11056/fec2.jpg
http://www.ruby-forum.com/attachment/11057/fec3.jpg

Dynamics here haven't been tested much. A lot of the codes defined now are single-purpose because there's a lot of initialization and setup that occurs that might interfere with the running of things. It'd be interesting to see where different codes can be modified live. But for the CC encoder/decoder you're using, look at the man page:

http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__decoder.html

That code is highly optimized to do that one rate and K factor that it does.

You might have better luck making multiple variables and switching them in and out of the FEC extended encoder/decoder blocks. I feel we might have to do something to invalidate any data due to changes in cipher/plain text, though.

Tom

 

Re: [Discuss-gnuradio] Better approach for FEC

On Wed, Aug 26, 2015 at 2:14 PM, Marcus D. Leech <mleech@ripnet.com> wrote:

I think many of the folks who would have comments on this are at the Gnu Radio conference this week....

On 08/26/2015 02:09 PM, bob wole wrote:

On Tue, Aug 25, 2015 at 11:36 PM, bob wole <bnwole@gmail.com> wrote:

Hi,

I have a burst system in gnuradio which is working fine with usrps. I have used tags (tx_time, tx_eob and tx_sob) to define packet boundaries and transmission time. Tags are inserted by a block which is connected before the usrp sink. I did not use any "tagged stream block" in the burst system. All the blocks used are streaming blocks.

Now I want to insert FEC in my system. After going through the FEC API, I realized that I can use any of FEC deployments (Streaming, Tagged stream, Asynchronus). Are there any difference(s) performance wise? Which one should is better for my system? 

I have attached a picture of my current system and identified where I want to insert FEC in tx and rx.

Comments are appreciated.

--

Bob

Comments please ?

--

Bob

Bob,

The various models of handling packets through a GNU Radio system are dependent on a few things, none of which are easy black/white issues to describe or offer support on. Partly, it can just be your opinion on where the lines are between the different models; or based on what blocks are available in the different models. You don't want to go back and forth, though, so when you move from a stream into a PDU-based system, you'll want to stay there.

Performance is going to be dependent on the rest of your system as well. We can't tell you one is better than the other, but we've put in a lot of hooks into the system to help you understand those issues for yourself, like using the performance counters and naming each thread with the block name so top/htop can help.

Tom

Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

Ciao Maurizio,

On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio
<maurizio.crozzoli@telecomitalia.it> wrote:
> Moritz,
> if you wanted to scare me, you succeeded!

That wasn't my intend, sorry. I merely tried to elaborate on different
factors that might play into the choice of solution that will work
best for your solution.
>
> What you propose goes far beyond my current skills and it also looks excessively complicated compared to my needs: really no easier way to detect an external trigger?

I'm still not clear on how tight your latency requirements for that
trigger detection are. If you are ok to just poll with a 'slow'
software loop then using the get_gpio_attr() function will probably be
fast enough.
>
> Furthermore I cannot understand the meaning of the example in "The E3x0/X3x0 Front Panel GPIO" manual:
>
> "We are also using GPIO4, which we want to control manually, as an output.
> [...]
> // set up our values for ATR control: 1 for ATR, 0 for manual
> [...]
> After the above code is run, the ATR in the FPGA will automatically control GPIO6, as we have described, based on the radio state, and we have direct manual control over GPIO4."

What this means is that the GPIO6 will be controlled by the ATR's
logic, while the GPIO4 is user controlled via the set_gpio_attr()
functions, i.e. the state of GPIO6 is controlled by the radio state
{tx,rx,xx} while GPIO4 is controlled by API calls.
>
> So, what does it mean "After the above code is run, [...] we have direct manual control over GPIO4."? It thought it could be the solution to my need (a GPIO port to read an external trigger - except for the GPIO direction, a detail) but according to what you write (which is coherent with the introduction of the cited manual page: "These GPIO pins are controlled directly by the FPGA, where they are controlled by an ATR (Automatic Transmit / Receive).") it looks it is not: could you please explain the point?

See above. As you correctly observed you just want to set the mode to
manual control (so the FPGA's state machine will not interfere), and
control the GPIOs using {get,set}_gpio_attr, possibly in a separate
thread.

>
> TIA!
>
> BR,
> Maurizio.
>
> -----Messaggio originale-----
> Da: Moritz Fischer [mailto:moritz.fischer@ettus.com]
> Inviato: mercoledì 5 agosto 2015 23:56
> A: Crozzoli Maurizio
> Cc: discuss-gnuradio@gnu.org
> Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
>
> Maurizio,
>
> On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli <maurizio.crozzoli@telecomitalia.it> wrote:
>> Hi Martin or others who can support me, I have a problem which is
>> similar as Frank's: I have an E310 and I want to receive a and
>> external trigger on a pin which starts an acquisition process of a
>> burst of samples from the radio source.
>
> In the default FPGA image the GPIO pins are wired up to ATR pins that are connected to the radio0.
>
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304
>
> would be your places to start.
>
> If you want to use our GPIO API take a look at:
>
> http://files.ettus.com/manual/page_gpio_api.html
>
>>
>> Stated that I have to remove the box around the E310 to have access to
>> the GPIO ports (not a problem!), according to what I have read so far
>> in this thread, no way to reach my goal but using C++ (no GRC!). Not
>> an easy task for me but I do hope I can do it.
>>
>> What I need you support about is related to the right approach I
>> should follow. I would think that I should write a "while" loop which
>> runs in ARM processors where one on the available GPIO port is constantly monitored:
>> when the trigger is detected the acquisition process of a burst of
>> samples from the radio source is started and, once it has been
>> completed, the flow goes back to the GPIO port monitoring.
>
> You could either fork of a thread to monitor the ports through the UHD API, or rewire stuff in the FPGA (as pointed out above) to use the Zynq's GPIO_I signals in the FPGA.
> You could then use the default kernel sysfs GPIO API to use GPIO interrupts.
>
> places to start investigating are:
>
> https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
> http://elinux.org/GPIO#GPIO_interrupts_from_user_space
>
> maybe there are python bindings available?
>
>>
>> Is there any example code I be inspired from? OF course I have to
>> study what can be found in the manual page "The E3x0/X3x0 Front Panel
>> GPIO", but, together with the suggested gpio.cpp example under UHD, it
>> looks like there is more emphasis on the ATR mechanism, which - I
>> think - has nothing to do with the problem I have to solve.
>
> That is true, see the above links. Depending on latency requirements, and your input signal, the ATR API might not be what you need.
>>
>> Martin or others, could you please comment on my problem?
>>
>> TIA!
>>
>> BR,
>> Maurizio.
>>
>> PS If you think that, according to what I have understood so far, I
>> will need to use RFNoC in order to cope with the sampling speed
>> constraints of the acquisition process of a burst of samples from the
>> radio source, you might well understand how much I need your help, and
>> not just for this post...
>
> Just for the GPIO part no requirement of using RFNOC.
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979
>> p55274.html Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> Happy hacking,
>
> Moritz
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
>

I hope I could clarify this a bit

- Moritz

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

Re: [Discuss-gnuradio] General_Work Not Executing

On Mon, Aug 31, 2015 at 11:28 AM, Washbourne, Logan <lwashbo@ostatemail.okstate.edu> wrote:

Tom,

Thanks for the reply!

So unfortunately I started using git after I found out that the code wasn't entering general_work. It was actually the reason I started using git, so this wouldn't happen again haha. Thanks for the temp files tip, I'll try to fix that today.

For the blocks, I think I just want them to pass messages. I'm trying to model it directly after the ChatApp tutorial, and I'm pretty sure that's what the send and receive blocks in that project were doing.

Is this not a good practice or infeasible? 

Logan Washbourne

Electrical Engineering Graduate Student

(Electromagnetics)

Hi Logan,

Have another look at the Python code you were copying from. The chat_sanitizer just creates a message output port and we call it's post_message from the main app when a user is ready to post. There's nothing automatic about it, so no work function to be called. The chat_receiver code just waits until a message is posted to it, at which point it wakes up and fires off its handle_msg function to process the message.

What you're trying to do is feasible, but I think you'll need to understand the message passing system in the scheduler instead of the data streaming model to get a better handle on it.

Tom

 

On Mon, Aug 31, 2015 at 8:44 AM, Tom Rondeau <tom@trondeau.com> wrote:

On Fri, Aug 28, 2015 at 12:49 PM, Washbourne, Logan <lwashbo@ostatemail.okstate.edu> wrote:

Hello All,

I recently rewrote the Chat Sanitize and Chat Receiver blocks from the Tutorial module(Example 5) in C++. I did this because I wanted to add an acknowledgment feature into the blocks in order to add some robustness to it(I'm not sure yet if the chat example will lend itself to being robust but it was the starting point I chose). The problem arose when I added an input port to the Text Sanitize block and added an output to the Chat Receiver block and connected them together. Instead of a linear program I now had a loop of a program. I did something wrong because now the Text Sanitize block wasn't outputting anything, so I commented out the input code for Text Sanitize and the output code for Chat Receiver. I went to retest the program to see if it behaved just like Example 5(which it was before I started adding on the acknowledgment bits) but now Text Sanitize wasn't outputting anything still.

I tried putting some cout's in the general _work function where the message publishing code is and I have determined that it's not even entering the general_work function. 

Does anyone have any thoughts on the matter? I must have changed something when I commented out the input portion of the Text_Sanitize code but for the life of me I can't figure out what it is. I have even since made two new blocks to try and redo the functionality of Text Sanitize but the same problem still persists.

So this will be a good lesson in using git! It's good to keep small, quantified changes in git so that you know where you are versus where you started when making a change. "git diff" is your friend here. Lots of ways to use this tool to help in your development cycle.

(Also, looking at your git repo, you've checked in the '~' temp files from your editor [emacs I assume]. You don't want any temp or auto-generated files in a git repository; just stuff that you've created that needs to be tracked.)

The problem is that this block is designed only to output messages, not a data stream. You can see in the constructor that the io_signature is using (0, 0, 0) for both inputs and outputs. The scheduler doesn't recognize this block in the stream and so never things to call the general_work. The original blocks you are referring to only have message interfaces.

Hope this helps get you in the right direction.

Tom

 

My code can be found at: https://github.com/loganwashbourne/Thesis.git

The juicy files are in the Thesis/OOT/gr-ACK/lib folder.

There might be some profanity in the commit messages, it was a stressful day.

I appreciate your time,

Logan Washbourne

Electrical Engineering Graduate Student

(Electromagnetics)

_______________________________________________
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] Using the UHD API for Python Programming

On 08/31/2015 12:34 PM, Tibisay Sanchez wrote:
> Actually, it dindn't work if I use uhd.time_spec_t(.1)
>
I should have looked closer:

you want:

cmd_time = uhd.time_spec_t(0.1)



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

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

Actually, it dindn't work if I use uhd.time_spec_t(.1)

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

On 08/31/2015 12:04 PM, Tibisay Sanchez wrote:
> Hi people.
>
> I'm using the same code to synchronize channel phase. I'm using MIMO
> cable, and the next lines are used to do that
>
> self.uhd_usrp_source_0.set_clock_source("mimo", 1)
> self.uhd_usrp_source_0.set_time_source("mimo", 1)
> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> self.uhd_usrp_source_0.set_center_freq(1.2e9, 0)
> self.uhd_usrp_source_0.set_gain(10, 0)
> self.uhd_usrp_source_0.set_antenna("RX2", 0)
> self.uhd_usrp_source_0.set_center_freq(1.2e9, 1)
> self.uhd_usrp_source_0.set_gain(10, 1)
> self.uhd_usrp_source_0.set_antenna("RX2", 1)
>
> To synch the phase I used
>
> self.cmd_time = self.uhd_usrp_source_0.uhd_time_spect_t(.1)
> self.uhd_usrp_source_0.set_command_time(self.cmd_time)
> self.uhd_usrp_source_0.clear_command_time()
>
> When I run the python file, I have an error, it says: " File
> "sync_mimo_nophase_grc.py", line 73, in __init__
> self.cmd_time = self.uhd_usrp_source_0.uhd_time_spect_t(.1)
> AttributeError: 'usrp_source_sptr' object has no attribute
> 'uhd_time_spect_t'"
>
> Anyone can help me with my problem.
>
> Thanks
>
It's uhd_time_spec_t, not uhd_time_spect_t



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

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

Hi people.

I'm using the same code to synchronize channel phase. I'm using MIMO
cable, and the next lines are used to do that

self.uhd_usrp_source_0.set_clock_source("mimo", 1)
self.uhd_usrp_source_0.set_time_source("mimo", 1)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(1.2e9, 0)
self.uhd_usrp_source_0.set_gain(10, 0)
self.uhd_usrp_source_0.set_antenna("RX2", 0)
self.uhd_usrp_source_0.set_center_freq(1.2e9, 1)
self.uhd_usrp_source_0.set_gain(10, 1)
self.uhd_usrp_source_0.set_antenna("RX2", 1)

To synch the phase I used

self.cmd_time = self.uhd_usrp_source_0.uhd_time_spect_t(.1)
self.uhd_usrp_source_0.set_command_time(self.cmd_time)
self.uhd_usrp_source_0.clear_command_time()

When I run the python file, I have an error, it says: " File
"sync_mimo_nophase_grc.py", line 73, in __init__
self.cmd_time = self.uhd_usrp_source_0.uhd_time_spect_t(.1)
AttributeError: 'usrp_source_sptr' object has no attribute
'uhd_time_spect_t'"

Anyone can help me with my problem.

Thanks

--
Posted via http://www.ruby-forum.com/.

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

[Discuss-gnuradio] R: Front Panel GPIO on Ettus X310

Moritz,
if you wanted to scare me, you succeeded!

What you propose goes far beyond my current skills and it also looks excessively complicated compared to my needs: really no easier way to detect an external trigger?

Furthermore I cannot understand the meaning of the example in "The E3x0/X3x0 Front Panel GPIO" manual:

"We are also using GPIO4, which we want to control manually, as an output.
[...]
// set up our values for ATR control: 1 for ATR, 0 for manual
[...]
After the above code is run, the ATR in the FPGA will automatically control GPIO6, as we have described, based on the radio state, and we have direct manual control over GPIO4."

So, what does it mean "After the above code is run, [...] we have direct manual control over GPIO4."? It thought it could be the solution to my need (a GPIO port to read an external trigger - except for the GPIO direction, a detail) but according to what you write (which is coherent with the introduction of the cited manual page: "These GPIO pins are controlled directly by the FPGA, where they are controlled by an ATR (Automatic Transmit / Receive).") it looks it is not: could you please explain the point?

TIA!

BR,
Maurizio.

-----Messaggio originale-----
Da: Moritz Fischer [mailto:moritz.fischer@ettus.com]
Inviato: mercoledì 5 agosto 2015 23:56
A: Crozzoli Maurizio
Cc: discuss-gnuradio@gnu.org
Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

Maurizio,

On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli <maurizio.crozzoli@telecomitalia.it> wrote:
> Hi Martin or others who can support me, I have a problem which is
> similar as Frank's: I have an E310 and I want to receive a and
> external trigger on a pin which starts an acquisition process of a
> burst of samples from the radio source.

In the default FPGA image the GPIO pins are wired up to ATR pins that are connected to the radio0.

https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304

would be your places to start.

If you want to use our GPIO API take a look at:

http://files.ettus.com/manual/page_gpio_api.html

>
> Stated that I have to remove the box around the E310 to have access to
> the GPIO ports (not a problem!), according to what I have read so far
> in this thread, no way to reach my goal but using C++ (no GRC!). Not
> an easy task for me but I do hope I can do it.
>
> What I need you support about is related to the right approach I
> should follow. I would think that I should write a "while" loop which
> runs in ARM processors where one on the available GPIO port is constantly monitored:
> when the trigger is detected the acquisition process of a burst of
> samples from the radio source is started and, once it has been
> completed, the flow goes back to the GPIO port monitoring.

You could either fork of a thread to monitor the ports through the UHD API, or rewire stuff in the FPGA (as pointed out above) to use the Zynq's GPIO_I signals in the FPGA.
You could then use the default kernel sysfs GPIO API to use GPIO interrupts.

places to start investigating are:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
http://elinux.org/GPIO#GPIO_interrupts_from_user_space

maybe there are python bindings available?

>
> Is there any example code I be inspired from? OF course I have to
> study what can be found in the manual page "The E3x0/X3x0 Front Panel
> GPIO", but, together with the suggested gpio.cpp example under UHD, it
> looks like there is more emphasis on the ATR mechanism, which - I
> think - has nothing to do with the problem I have to solve.

That is true, see the above links. Depending on latency requirements, and your input signal, the ATR API might not be what you need.
>
> Martin or others, could you please comment on my problem?
>
> TIA!
>
> BR,
> Maurizio.
>
> PS If you think that, according to what I have understood so far, I
> will need to use RFNoC in order to cope with the sampling speed
> constraints of the acquisition process of a burst of samples from the
> radio source, you might well understand how much I need your help, and
> not just for this post...

Just for the GPIO part no requirement of using RFNOC.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979
> p55274.html Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Happy hacking,

Moritz

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

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

Re: [Discuss-gnuradio] General_Work Not Executing

Tom,

Thanks for the reply!

So unfortunately I started using git after I found out that the code wasn't entering general_work. It was actually the reason I started using git, so this wouldn't happen again haha. Thanks for the temp files tip, I'll try to fix that today.

For the blocks, I think I just want them to pass messages. I'm trying to model it directly after the ChatApp tutorial, and I'm pretty sure that's what the send and receive blocks in that project were doing.

Is this not a good practice or infeasible? 

Logan Washbourne

Electrical Engineering Graduate Student

(Electromagnetics)

On Mon, Aug 31, 2015 at 8:44 AM, Tom Rondeau <tom@trondeau.com> wrote:

On Fri, Aug 28, 2015 at 12:49 PM, Washbourne, Logan <lwashbo@ostatemail.okstate.edu> wrote:

Hello All,

I recently rewrote the Chat Sanitize and Chat Receiver blocks from the Tutorial module(Example 5) in C++. I did this because I wanted to add an acknowledgment feature into the blocks in order to add some robustness to it(I'm not sure yet if the chat example will lend itself to being robust but it was the starting point I chose). The problem arose when I added an input port to the Text Sanitize block and added an output to the Chat Receiver block and connected them together. Instead of a linear program I now had a loop of a program. I did something wrong because now the Text Sanitize block wasn't outputting anything, so I commented out the input code for Text Sanitize and the output code for Chat Receiver. I went to retest the program to see if it behaved just like Example 5(which it was before I started adding on the acknowledgment bits) but now Text Sanitize wasn't outputting anything still.

I tried putting some cout's in the general _work function where the message publishing code is and I have determined that it's not even entering the general_work function. 

Does anyone have any thoughts on the matter? I must have changed something when I commented out the input portion of the Text_Sanitize code but for the life of me I can't figure out what it is. I have even since made two new blocks to try and redo the functionality of Text Sanitize but the same problem still persists.

So this will be a good lesson in using git! It's good to keep small, quantified changes in git so that you know where you are versus where you started when making a change. "git diff" is your friend here. Lots of ways to use this tool to help in your development cycle.

(Also, looking at your git repo, you've checked in the '~' temp files from your editor [emacs I assume]. You don't want any temp or auto-generated files in a git repository; just stuff that you've created that needs to be tracked.)

The problem is that this block is designed only to output messages, not a data stream. You can see in the constructor that the io_signature is using (0, 0, 0) for both inputs and outputs. The scheduler doesn't recognize this block in the stream and so never things to call the general_work. The original blocks you are referring to only have message interfaces.

Hope this helps get you in the right direction.

Tom

 

My code can be found at: https://github.com/loganwashbourne/Thesis.git

The juicy files are in the Thesis/OOT/gr-ACK/lib folder.

There might be some profanity in the commit messages, it was a stressful day.

I appreciate your time,

Logan Washbourne

Electrical Engineering Graduate Student

(Electromagnetics)

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

[Discuss-gnuradio] ofdm plateau_detector_fb_impl//ofdm_sync_sc_cfb_impl

Hi all,
           I have a question on the synchronization of ofdm example,namely the sch&cox source code.
   
           The plateau_detector_fb_impl.cc can find the plateau,and then header_payload_demux_impl can find the head data.
            STEP 1: plateau_detector_fb_impl find the plateau.
            flank_start = i;
          while(i < noutput_items && in[i] >= d_threshold)
            i++;
          if((i - flank_start) > 1) { // 1 Sample is not a plateau
            out[flank_start + (i-flank_start)/2] = 1;
            i = std::min(i+d_max_len, noutput_items-1);
          }
            STEP 2:header_payload_demux_impl can find the head data
            case STATE_HEADER:
              if (check_items_available(d_header_len, ninput_items, noutput_items, nread)) {
                copy_n_symbols(in, out_header, PORT_HEADER, d_header_len);
              STEP  3:
             memcpy((void *) out, (void *) (in + d_gi * d_itemsize), d_items_per_symbol * d_itemsize);


            I think may be the code have some errors.For example,the data is    cdef+abcdef,the cyclic prefix is cdef,and the data is abcdef.
According step1,the output will ouput 0010000000.Because the sch&cox will output a plateau in the cyclic prefix,namely the index corresponding to the cdefa will be the plateau.The source code output 1 in the middle.Namely the index corresponding to the middle "e" output 1.
           According to the step 2 and step3, we copy the d_items_per_symbol * d_itemsize bytes after (in + d_gi * d_itemsize) to the output.In the example, cdef+abcdef,the d_gi is 4. (in + d_gi * d_itemsize) will correspond to the c.Then output d_items_per_symbol is 6,then output cdef..But the true head data is abcdef,so I think maybe the source code have some problems.Is my understanding right?
            Thank you.
Best regards,
zswx
         

夏日畅销榜大牌美妆只要1元

Re: [Discuss-gnuradio] General_Work Not Executing

On Fri, Aug 28, 2015 at 12:49 PM, Washbourne, Logan <lwashbo@ostatemail.okstate.edu> wrote:

Hello All,

I recently rewrote the Chat Sanitize and Chat Receiver blocks from the Tutorial module(Example 5) in C++. I did this because I wanted to add an acknowledgment feature into the blocks in order to add some robustness to it(I'm not sure yet if the chat example will lend itself to being robust but it was the starting point I chose). The problem arose when I added an input port to the Text Sanitize block and added an output to the Chat Receiver block and connected them together. Instead of a linear program I now had a loop of a program. I did something wrong because now the Text Sanitize block wasn't outputting anything, so I commented out the input code for Text Sanitize and the output code for Chat Receiver. I went to retest the program to see if it behaved just like Example 5(which it was before I started adding on the acknowledgment bits) but now Text Sanitize wasn't outputting anything still.

I tried putting some cout's in the general _work function where the message publishing code is and I have determined that it's not even entering the general_work function. 

Does anyone have any thoughts on the matter? I must have changed something when I commented out the input portion of the Text_Sanitize code but for the life of me I can't figure out what it is. I have even since made two new blocks to try and redo the functionality of Text Sanitize but the same problem still persists.

So this will be a good lesson in using git! It's good to keep small, quantified changes in git so that you know where you are versus where you started when making a change. "git diff" is your friend here. Lots of ways to use this tool to help in your development cycle.

(Also, looking at your git repo, you've checked in the '~' temp files from your editor [emacs I assume]. You don't want any temp or auto-generated files in a git repository; just stuff that you've created that needs to be tracked.)

The problem is that this block is designed only to output messages, not a data stream. You can see in the constructor that the io_signature is using (0, 0, 0) for both inputs and outputs. The scheduler doesn't recognize this block in the stream and so never things to call the general_work. The original blocks you are referring to only have message interfaces.

Hope this helps get you in the right direction.

Tom

 

My code can be found at: https://github.com/loganwashbourne/Thesis.git

The juicy files are in the Thesis/OOT/gr-ACK/lib folder.

There might be some profanity in the commit messages, it was a stressful day.

I appreciate your time,

Logan Washbourne

Electrical Engineering Graduate Student

(Electromagnetics)

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

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

Hi Antonio,

The problem might be due to delay introduced by the processing blocks.

Your OFDM modulator and demodulator don't work instantaneously, they take some time to do their processing and forward their outputs to the next block in line. Therefore, there is a delay between the output of the OFDM demod block and the original signal.

What you need to do is add a delay block between your Random source and the BER block and set the delay properly.

When you're not adding any noise, your BER should be 0. So you can try to find the delay value this way.

Then add noise and see how your BER evolves.

I hope this helps.

Regards,

Jawad

2015-08-31 13:21 GMT+02:00 ANTONIO TAMAYO <atamayo2703@gmail.com>:

The configuration to which I refer in the previous email is the corresponding to the image attached

2015-08-31 13:18 GMT+02:00 ANTONIO TAMAYO <atamayo2703@gmail.com>:

Hello,

 I'm doing my College final project about gnuradio companion. Specifically I have to calculate the BER with OFDM using different modulations to the subcarriers. After that, I have to do a graphic with the BER numbers. The configuration I use is in the image attached.

When I'm using GRC to calculate BER I always have the same problem. First I try to simulate without introducing any noise and get a BER data. Then I try to introduce AWGN noise and the BER data is the same. Clearly I'm making a mistake, but I'm not able to identify what it is. In view of the configuration used, someone could tell me which are my mistakes?

Also, I would like to know how to configure the block Channel Model correctly.

Thank you all.

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

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

The configuration to which I refer in the previous email is the corresponding to the image attached

2015-08-31 13:18 GMT+02:00 ANTONIO TAMAYO <atamayo2703@gmail.com>:

Hello,

 I'm doing my College final project about gnuradio companion. Specifically I have to calculate the BER with OFDM using different modulations to the subcarriers. After that, I have to do a graphic with the BER numbers. The configuration I use is in the image attached.

When I'm using GRC to calculate BER I always have the same problem. First I try to simulate without introducing any noise and get a BER data. Then I try to introduce AWGN noise and the BER data is the same. Clearly I'm making a mistake, but I'm not able to identify what it is. In view of the configuration used, someone could tell me which are my mistakes?

Also, I would like to know how to configure the block Channel Model correctly.

Thank you all.

[Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

Hello,

 I'm doing my College final project about gnuradio companion. Specifically I have to calculate the BER with OFDM using different modulations to the subcarriers. After that, I have to do a graphic with the BER numbers. The configuration I use is in the image attached.

When I'm using GRC to calculate BER I always have the same problem. First I try to simulate without introducing any noise and get a BER data. Then I try to introduce AWGN noise and the BER data is the same. Clearly I'm making a mistake, but I'm not able to identify what it is. In view of the configuration used, someone could tell me which are my mistakes?

Also, I would like to know how to configure the block Channel Model correctly.

Thank you all.

[Discuss-gnuradio] path issue with pybombs env

Greetings all,

Could someone confirm this as a problem?

Base system: Win 7

VM: VMPlayer free v10

OS: Ubunto v14.04lts

pybombs download: git clone git://github.com/gnuradio/pybombs

We have an invalid path entry for this configuration:

export PATH= <lots of correct stuff>...then /usr/lib/x86_64-linux-gnu/qt4/bin::/usr/lib64/qt4/bin/

bash was upset.

I noticed QT4 bin stuff here:  :/usr/lib64/qt4/bin/

Quick edit (in my case usr/gratcliff) fixed things:

# WARNING: This file is auto-generated by pybombs, any manual changes to it may be overwritten!
export PATH="/home/gratcliff/Downloads/target/bin/:/home/gratcliff/Downloads/target/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/x86_64-linux-gnu/qt4/bin:"

Thanks,

Greg

nz8r

Re: [Discuss-gnuradio] Gain and Sample Rate Setting

Besides the problem I had above, there seems to be a new one. Till that
day, I used to get some output, but today, when I tried to run the
./benchmark_tx.py -f 2.435G command, I am getting the following error

Traceback (most recent call last):
File "./benchmark_tx.py", line 147, in <module>
main()
File "./benchmark_tx.py", line 111, in main
tb = my_top_block(mods[options.modulation], options)
File "./benchmark_tx.py", line 49, in __init__
options.antenna, options.verbose)
File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 135, in __init__
freq, gain, antenna)
File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 62, in __init__
self._rate, self._sps = self.set_sample_rate(bitrate, sps)
File
"/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
line 70, in set_sample_rate
asked_samp_rate = bitrate * req_sps
TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

But the receiver is working just fine. I don't know what mistake is
present in my benchmark transmission file. Please help me with this. I
am attaching the same benchmark scripts.

Thanks,
Ben

Attachments:
http://www.ruby-forum.com/attachment/11065/uhd_interface.py
http://www.ruby-forum.com/attachment/11066/benchmark_tx.py
http://www.ruby-forum.com/attachment/11067/transmit_path.py


--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Gain and Sample Rate Setting

Hi,
Thanks for the advice. I am sorry that I didn't understand what you have
said. So what you suggest is that I need to make some changes to the
benchmark scripts. But I have changed gain and frequency already in the
uhd_interface program. Do i need to use the gnuradio-companion for
uhd_interface program? Because, I am giving all the commands in the
terminal itself. Please suggest me further. Excuse me if I am asking
some noob doubts because I am new to gnuradio.

Thanks,
Ben

--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Gain and Sample Rate Setting

Hi,
what Jeon writes is correct so far, but two comments:
> You can check XCVR2450's dsp rate

XCVR2450 is your daughterboard, not your USRP. The mainboard has a master clock rate. 100M is a good example, because it's the MCR of the USRP N2x0.

> But in case of LFTX, LFRX, it is 200k.

As explained above, it's not a feature of the daughterboard, but of your USRP. My assumption would be the minimum rate for you is 100M/512 = 192.something kHz

And as Jeon pointed out, you should see a warning on the console, saying which sampling rate was actually used.
Now, I'm not quite sure what tools you're using that use the uhd_interface.uhd_transmitter and uhd_interface.uhd_receiver, but if it's one of the benchmark_* scripts, you will need to adjust symbol rate or samples_per_symbol, or likely both, to yield a valid sampling rate.

Best regards,
Marcus

On 30.08.2015 23:42, Jeon wrote:

Note before the text: my answer might have some incorrect terminologies.

I am unable to know how to set the sample rate and sps for my device.

1. DSP rate should be an integer multiple of sampling rate

You can check XCVR2450's dsp rate by `uhd_usrp_probe` command. Let's say it is 100M (not a true value!)
If you set sampling rate to 30k, 100M/30k = 3.333k, not an integer

2. There is some lower limit of sampling rate

Since I've never used XCVR2450, I don't know the exact value of it.

But in case of LFTX, LFRX, it is 200k.

If 50k that you've set is below such lower limit, you can see warning message on the console.

Regards,
Jeon.

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

Re: [Discuss-gnuradio] Gain and Sample Rate Setting

Note before the text: my answer might have some incorrect terminologies.

I am unable to know how to set the sample rate and sps for my device.

1. DSP rate should be an integer multiple of sampling rate

You can check XCVR2450's dsp rate by `uhd_usrp_probe` command. Let's say it is 100M (not a true value!)
If you set sampling rate to 30k, 100M/30k = 3.333k, not an integer

2. There is some lower limit of sampling rate

Since I've never used XCVR2450, I don't know the exact value of it.

But in case of LFTX, LFRX, it is 200k.

If 50k that you've set is below such lower limit, you can see warning message on the console.

Regards,
Jeon.

[Discuss-gnuradio] Gain and Sample Rate Setting

Hello all,
I have XCVR2450 USRP's. I have been trying to send the data between two
USRP's. I have made some changes to the python code in uhd_interface.py
where I have changed the gain to 25 and set the frequency for
transmitter and receiver to 2.435G. I have run uhd_fft program only to
find that my sample rate of 50k is not being supported. I am unable to
know how to set the sample rate and sps for my device. Because of that,
I have been receiving some errors like

ok = False pktno = 88 n_rcvd = 1 n_right = 0
ok = False pktno = 105 n_rcvd = 2 n_right = 0
ok = False pktno = 49227 n_rcvd = 3 n_right = 0
ok = False pktno = 117 n_rcvd = 4 n_right = 0
ok = False pktno = 121 n_rcvd = 5 n_right = 0
ok = False pktno = 122 n_rcvd = 6 n_right = 0
ok = False pktno = 126 n_rcvd = 7 n_right = 0

I also have attached a graph of uhd_fft program. I think I have got a
wave which represents a transmission gain of 25 and received gain of 15
because I have specified it in the uhd_interface.py program. Please
advice as to where I can change these settings so that I might be able
to receive packet in a right order. Thank you

Regards,
Ben

Attachments:
http://www.ruby-forum.com/attachment/11064/Screenshot_from_2015-08-27_15_01_49.png


--
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] GRCon15 Talk recordings

> Message: 2
> Date: Sat, 29 Aug 2015 17:30:29 -0400
> From: Sylvain Munaut
> To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
> Subject: [Discuss-gnuradio] GRCon15 Talk recordings

> Hi,
>
>
> For anyone interested into digging into this, here are some recordings
> of the mic RF signal during talks at GRCon 15
>
> http://people.osmocom.org/~tnt/grcon/mic-f5.030000e%2b08-s2.000000e%2b06-t20150826090018.cfile
> http://people.osmocom.org/~tnt/grcon/mic-f5.030000e%2b08-s2.000000e%2b06-t20150826090030.cfile
>
> (Hehe, I bet you didn't expect that when you clicked on that email title :p)
>
>
> Microphone system is from Shure, their ULXD line of products (
> http://www.shure.com/americas/products/wireless-systems/ulxd-systems )
> FCC filing for the microphone that was used: https://fcc.io/DD4ULXD1G50
>
> Modulation is 8-PSK and symbol rate is 156250 sym/s

This brief may confirm a lot of what you already figured out:
http://cdn.shure.com/uploaded_file/upload/80/Advanced_Wireless_Seminar_July_2013.pdf
http://cdn.shure.com/uploaded_file/upload/118/2013-11-19_Advanced_Wireless_Seminar_Portland_OR.pdf
http://cdn.shure.com/uploaded_file/upload/174/advanced_wireless_seminar_may_2014_english.pdf
Slide 70 or 72, in particular, shows the symbol values for a Gray Coded
8-PSK constellation.


8-PSK at 156,250 symbols/sec = 1.25 Mbps.
At 44.1 ksps audio, one could still fit 24-bit uncompressed audio
samples in 1.25 Mbps and still keep up with some room still for
overhead. I'm going to speculate whatever audio coding Shure is using,
it is compressing audio to use 16 bits per sample for over the air.

Also, Shure mentions in a few places that their audio codec has 2.9 ms
latency. On page 26 of the PDF of this journal publication:
http://www.aes.org/journal/sample_issue/JAES_V50_11_ALL.pdf
it notes that 128 samples / 44.1 ksamples/sec = 2.9025 ms.

So I'm going to speculate that Shure's audio codec operates on blocks of
samples that are N*128 samples long. That payload block size might be
visible in OTA transmissions. It may be easiest to spot with audio
near-silence samples that are at the end of a transmission (when the VOX
decides to cut off).

I have not looked at the files BTW.

Regards,
Andy

>
> Cheers,
>
> Sylvain
>



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

[Discuss-gnuradio] CC1101

I want to demodulate signal generated by CC1101 with USRP and Gnuradio, and my signal information listed below:

Modulation : GFSK
Preamble 4 bytes
sync 4 byte
Packet length fix

Manchester  Disable

CRC Check no
White spacing Yes

Data rate: 9600k
Bandwidth :58036Hz
F(IF) :380860 Hz
Carrier Frequency: 450Mhz
Fdeviation: 5157.5
Channel:49988Hz

Sampling Rate 1MHz

I try to use one of the sample in internet by demoudulating with QuadDemode also I used GFSK Demod too in both of them I could not detect any frame. Could you please check attached picture and see If I missed anything .

Thanks,
Behnam

[Discuss-gnuradio] AHRPT

Hello,

   I have managed to get the gr-noaa modules working quite nicely on HRPT signals

from the NOAA satellites.      I have also attempted to detect strong signals from

METOP-B and METEOR-M2.    In the case of METEOR-M2, the signal looked very

much like the BPSK signal from the NOAA satellites, whereas with the METOP, the 

FFT looked qualitatively different.

    Based on what I have found on the web, it does not seem like the METOP is 

"open source."    But I am wondering about the METEOR-M2.   Does anyone 

have (or know of) any experience decoding this AHRPT signal?    My hope is

that it can be done with a relatively small tweak of the existing gr-noaa module(s).

Sincerely,

Dan Marlow

P.S.  I attach a false color HRPT image received from NOAA 19 yesterday using usrp_rx_hrpt.py

Re: [Discuss-gnuradio] Installing OOT Module on Mac

Hi Vamsi, hi Rich :)

There's two different directories you need to look at here:
1. the GRC block path. This is directory where GRC looks for the XML defining how a block looks like
2. the Pythonpath. This is the directory Python looks in when you do something like "import modulename".

Examine your $PYTHONPATH variable, and see if

export $PYTHONPATH=$PYTHONPATH:</path/to/folder/containing/installed/<modulename>.py

before starting your Python Flowgraph (ie. before starting GRC from the same shell) helps.

Best regards,
Marcus

On 29.08.2015 22:55, Richard Bell wrote:

Hello,

I'm using GNURadio 3.7.8 installed from MacPorts on a MacBook Air.

I have tried to create a custom module on my MacBook Air using gr_modtool.

I was able to write, compile and build the code.

After this I edited the XML file for accessing on gnuradio-companion.

But the block didn't show up on gnuradio-companion.

so I have set the following in .bash_profile

export GRC_BLOCKS_PATH="<required folder>"

and I was able to see the newly generated block.

But when I run the flowgraph I get the following error.

ImportError: No module named <module name>

In linux there is sudo ldconfig command, but the command doesn't exist on Mac

So after 

"sudo make install"

Is there anything else to do for mac?

Thanks

Vamsi and Rich

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