Re: Symbol Sync Block Still in Sync but Symbols are Incorrect

[Dan CaJacob]

It's been a while, but maybe it has locked onto 90 deg phase rotation, so
the constellation looks good, but the sync word is now shifted?

On Thu, Jan 4, 2024 at 4:02 AM Ceren Karaköse 
wrote:

> Hi all,
>
> First off, thank you for all the amazing work you've put into this
> community.
>
> I'm working with 1.024M baud QPSK signal with sample rate of 4.096M. This
> symbol sync block works perfectly 99% of time. I can successfully
> demodulate input symbols, perform convolutional decoding and find sync word
> using Sync and Create PDU block. However, when I close and re-open the flow
> while the source is still transmitting, sometimes it stops finding sync
> word despite the constellation being correct. In other words, constellation
> sink shows perfect 4 dots on the screen. I tried delaying constellation
> decoder output for 1 symbol time to cover for bit shifts. It did not work.
> I want to highlight that this only happens when I close and re-open the
> flow, but it never stops finding sync word while running. Also, it never
> starts finding the sync word once it fails to find one. What might the
> problem be? GNU radio version is 3.10.7.0 (Python 3.10.12). Flow is
> attached.
>
> Thanks in advance!
>
> Ceren.
>


-- 
Very Respectfully,

Dan CaJacob

Re: DVB-T receiving

[Dan CaJacob]

I don't know anything about DVB-T, but since this is a wide recording, is
there any chance you got overflows when recording it and thus have
discontinuities?

On Tue, Feb 15, 2022 at 12:10 PM Szilassi Andras 
wrote:

> Hello,
>
> Once again I am asking for some help with the DVB-T functionality of GNU
> radio.
>
> I am using complex binary files recorded with a USRP at 10 Ms/s. The DVB-T
> rx example chain can't decode it at all. I have changed every setting
> according to Hungarian transmit parameters (64QAM, 1/4 GI, 3/4 code rate
> etc.).
>
> I think the problem might be with symbol acquisition, but cant really
> confirm my suspicion.
>
> Below you can see the signal I am talking about. Could it be that for this
> type of synchronization this SNR is not sufficient?
>
> [image: image.png]
>
> Thanks,
> András Szilassi
>
>

-- 
Very Respectfully,

Dan CaJacob

Re: [Discuss-gnuradio] PSK Mod problem? or QT GUI problem?

[Dan CaJacob]

I think this happens when you don't have matched filters?

On Thu, Nov 1, 2018 at 10:45 AM Mercado, Alejandra 
wrote:

> Dear GnuRadio folks,
>
> I have a questions about the "PSK Mod" block of GnuRadio. I am following
> the tutorial found here:
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
> (the grc is attached)
>
> I followed the instructions to see the output of PSK Mod for 4
> constellation points. To my surprise, the constellation graph shows points
> that are ambiguously between quadrants (see the screenshot).
>
> What causes this? Is it the PSK Mod block that creates output points that
> do not correspond to one of the four points? Or is it the QT GUI that is
> not displaying the output correctly? Or both?
>
> Thanks and regards
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Half duplex flowgraph

[Dan CaJacob]

You can have your TX and RX in the same flowgraph...

On Mon, Oct 22, 2018 at 10:12 AM Albin Stigö  wrote:

> Hi GNURadio folks,
>
> I'm hacking on a small half duplex (classic ptt) transceiver
> application using GNUradio as backend and I'm looking for the best way
> for switching between two flowgraphs?
>
> Is it necessary to lock()-reconfigure-runlock() or is there some
> clever way of having two separate flowgraphs and enable only one of
> them for rx/tx.
>
>
> --Albin
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] DVB-S2/X Block Party at GNU Radio Conference 2018

[Dan CaJacob]

Absolutely. It's kind of insane to build an RFNOC system without first
having a software implementation. This will be exciting!

On Mon, Jun 25, 2018 at 5:22 PM Martin Braun  wrote:

> It would be great to have both. Even if you can't do real-time decoding,
> you can get pretty far with non-realtime decoding. And at least, we'd
> have a reference design (even it's too slow). Although of course, I'd
> very much love to see RFNoC blocks for various other reasons :)
>
> -- M
>
> On 06/21/2018 08:30 AM, Michelle Thompson wrote:
> > "Enthusiastic Yes" on RFNoC.
> >
> > Our assumption is that we will need RFNoC. I think we could certainly
> > use some advice on workflow.
> >
> > The LDPC FEC decode effort right now includes attempts with Xilinx SDSoC
> > to convert functions from the GPU codebase into hardware accelerated
> > FPGA code. From there, package for RFNoC.
> >
> > This plan has advantages and disadvantages. We're here to learn and
> > contribute whatever we can.
> >
> > We have several SDSoC licenses and several full Vivado licenses. We have
> > at least one X310, several B210s, and a variety of other FPGA dev boards
> > (Snickerdoodls, Ultra96, etc).
> >
> > We have plenty of Plutos and some LimeSDRs.
> >
> > -Michelle W5NYV
> >
> >
> > On Wed, Jun 20, 2018 at 3:42 PM, Dan CaJacob  > <mailto:dan.caja...@gmail.com>> wrote:
> >
> > I'd suggest incorporating RFNOC at least as an option. I suspect
> > actual use of DVBS2X might be rather boring if you're stuck on a
> > processor.
> >
> > On Wed, Jun 20, 2018 at 4:38 PM Michelle Thompson
> > mailto:mountain.miche...@gmail.com>>
> > wrote:
> >
> > Hello everyone,
> >
> > GNU Radio Conference is coming up in September. If you haven't
> > registered and want to go, please do at
> > https://www.gnuradio.org/grcon-2018/
> > <https://www.gnuradio.org/grcon-2018/>
> >
> > There's a special event this year called Block Party.
> >
> > It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.
> >
> > We will have our own room and tables and swag. We will have
> > docents enthusiasm and test equipment. We're looking for more!
> > We'll have documentation and refreshments.
> >
> > We need blocks!
> >
> > Most blocks needed for DVB-S2/X receive do, in some form,
> > already exist. Some do not. Some just need additional modulation
> > and codings added to them.
> >
> > Receiver design is hard, but breaking it up into small blocks
> > makes it tractable.
> >
> > The DVB protocol documents are all open. There are
> > implementation guidelines. See https://www.dvb.org/
> >
> > There are several community members that are experts in this
> > area. There is a team (Phase 4 Ground - find out more at
> > https://phase4ground.github.io/
> > <https://phase4ground.github.io/>) that needs DVB-S2/X to work
> > in GNU Radio. There is a lot of interest from a variety of other
> > groups including Libre Space, ARRL, AMSAT, and TAPR.
> >
> > If you are able to contribute to this effort, I want to know
> > about it! I am here to support it. I'd like nothing better than
> > to complete the Block Party at GNU Radio Conference with
> > working, tested, documented blocks for a DVB-S2/X receiver. This
> > contribution makes our open source terrestrial and space radio
> > designs for Phase 4 Ground possible, and also opens up a lot of
> > other work.
> >
> > The thing that is considered the hardest part is the LDPC FEC
> > decode. We have an open source implementation that targets GPUs.
> > We want to take this and get it into RFNoC. If you are working
> > on this as well, we want to collaborate and support and combine
> > and promote.
> >
> > The GPU implementation (by Charles Brain G4GUO) of LDPC decode
> > can be found at our repository folder here:
> >
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
> > <
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
> >
> >
> > Phase 4 Ground is devoted to an open source implementation of
> > DVB-S2 and DVB-S2X for amateur radio 

Re: [Discuss-gnuradio] USRP N210 Not transmitting simulated satellite signals

[Dan CaJacob]

GPS playback or simulation is *really* sensitive to underflows. If you have
them, you're hosed. When playing back a GPS recording, I always read the
file from a RAMdisk. SSDs (generally) and spinning disks just aren't fast
enough usually, and sometimes your OS even gets in the way.

On Sat, Jun 23, 2018 at 6:58 AM Marcus Müller 
wrote:

> underruns mean your computer isn't fast enough at supplying samples to
> the SDR device.
> In other words, you can only solve that by optimizing performance of
> you computer. You might need a better computer, or set up your computer
> more efficiently; this might or might not be solvable by following the
> windows-specific tips on http://files.ettus.com/manual/page_transport.h
> tml#transport_udp
> <http://files.ettus.com/manual/page_transport.html#transport_udp> .
> Chances are you just need a faster computer.
>
> Best regards,
> Marcus
> On Sat, 2018-06-23 at 13:28 +0300, evans ryanada wrote:
> > i  have cloned gps-sdr-sim and i have taken all the steps towards
> > achieving GPS simulated signals unfortunately upon typing this
> > command prompt . My micro controller can receive simulated GPS
> > signals.
> >
> > working environment
> > Windows 8
> > Gnurado companion 3.7.11
> >
> > On the command prompt it is displaying U this i understand this
> > is all about underan
> > how can i sort my problem
> > ___
> > 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] DVB-S2/X Block Party at GNU Radio Conference 2018

[Dan CaJacob]

I'd suggest incorporating RFNOC at least as an option. I suspect actual use
of DVBS2X might be rather boring if you're stuck on a processor.

On Wed, Jun 20, 2018 at 4:38 PM Michelle Thompson <
mountain.miche...@gmail.com> wrote:

> Hello everyone,
>
> GNU Radio Conference is coming up in September. If you haven't registered
> and want to go, please do at https://www.gnuradio.org/grcon-2018/
>
> There's a special event this year called Block Party.
>
> It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.
>
> We will have our own room and tables and swag. We will have docents
> enthusiasm and test equipment. We're looking for more! We'll have
> documentation and refreshments.
>
> We need blocks!
>
> Most blocks needed for DVB-S2/X receive do, in some form, already exist.
> Some do not. Some just need additional modulation and codings added to
> them.
>
> Receiver design is hard, but breaking it up into small blocks makes it
> tractable.
>
> The DVB protocol documents are all open. There are implementation
> guidelines. See https://www.dvb.org/
>
> There are several community members that are experts in this area. There
> is a team (Phase 4 Ground - find out more at
> https://phase4ground.github.io/) that needs DVB-S2/X to work in GNU
> Radio. There is a lot of interest from a variety of other groups including
> Libre Space, ARRL, AMSAT, and TAPR.
>
> If you are able to contribute to this effort, I want to know about it! I
> am here to support it. I'd like nothing better than to complete the Block
> Party at GNU Radio Conference with working, tested, documented blocks for a
> DVB-S2/X receiver. This contribution makes our open source terrestrial and
> space radio designs for Phase 4 Ground possible, and also opens up a lot of
> other work.
>
> The thing that is considered the hardest part is the LDPC FEC decode. We
> have an open source implementation that targets GPUs. We want to take this
> and get it into RFNoC. If you are working on this as well, we want to
> collaborate and support and combine and promote.
>
> The GPU implementation (by Charles Brain G4GUO) of LDPC decode can be
> found at our repository folder here:
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
>
> Phase 4 Ground is devoted to an open source implementation of DVB-S2 and
> DVB-S2X for amateur radio terrestrial and space use. We are part of Open
> Research Institute. Learn more about this non-profit here:
> https://openresearch.institute/
>
> -Michelle W5NYV
>
> _______
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Hello GNURadio from the Amateur Radio World

[Dan CaJacob]

Will,

I think you will find a wide variety of real-world applications GNURadio
has been used for. For myself, that includes ground to space and space to
ground communications systems, encompassing both common desktop machines as
well as embedded processors and FPGAs. Certainly it is easier to write a
modem for a desktop CPU, but a good C++ developer (I am not one, but I work
with them) can take advantage of pipelined operations in both embedded and
desktop CPUs to make distinction between the platforms less crippling. The
Volk project even makes this win more or less free (no need to write your
own instrinsics) if you profile it for your specific embedded device.

That said, I notice a lot of people new to GR wanting to jump right into
doing something hard on a Raspberry Pi or similar SBC. I think you'll find
that's generally a mistake. I'd suggest getting comfortable with GR and SDR
on the desktop before moving on to embedded systems, because there's a lot
to learn in both and it's going to be worse if you have to learn them both
at the same time.

- Dan

On Sat, May 26, 2018 at 7:00 PM Nick Foster <bistrom...@gmail.com> wrote:

> Will,
>
> Do you have a specific problem we can try to help you with? "Not pleasant"
> gives us very little to chew on.
>
> Nick
>
>
> On Sat, May 26, 2018, 9:20 PM Will Gilliam <hipotok1...@gmail.com> wrote:
>
>> Hello Peoples, I just signed up for the discuss list, so I thought I
>> would introduce myself
>>
>> My name is Will Gilliam and I am a FCC licensed General amateur radio
>> operator. (Ki7OXA)
>>
>> My first draw into GNURadio was the possibility of operating a high
>> frequency 5W radio
>> built from a Raspberry Pi 3, an Soundcard SDR radio. I love the idea of
>> embedded computing, SDR radios and GNURadio. Its small, its portable, and
>> because it involves a computer, the radio can be anything, even a modem.
>> Add amateur radio license, even the Element 2 technicians, your still
>> having fun VHF and up...
>>
>> Doing anything on a large computer is easy. Got more work? throw more cpu
>> time on the task, but anyone that tinkers within the Embedded world, you
>> know you really can't do that to a large degree.
>>
>> My experience with GNURadio is so far self taught and not pleasant. I am
>> uncertain if my poor experiences are from lack of experience, not enough
>> computer power, or a mix of both.
>>
>> Is there anyone that is using raspberry pi's and GNURadio on any sort of
>> realtime projects? Is there a better board to use or one that GNURadio is
>> going to try to support?
>>
>>
>> Look forward to learning and chatting with you all
>>
>>
>> Will Gilliam
>> ___
>> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Flowgraph

[Dan CaJacob]

I'll do all the work for 1 x 10^-5 BERCoin.

On Sat, May 26, 2018 at 9:59 AM Derek Kozel <derek.ko...@ettus.com> wrote:

> Hello Dewan,
>
> I'm glad that you are using GNU Radio, but no one here is going to do your
> entire project for you. We are happy to help with specific questions or
> problems, but not until you show us what you have tried and what problem
> you are having with it.
> https://wiki.gnuradio.org/index.php/ReportingErrors
>
> I see that you have no synchronization blocks in your flowgraphs, they
> will be needed when using actual hardware. Are you able to correctly send
> and receive a file when you are doing a pure simulation, no hardware?
>
> Regards,
> Derek
>
> On Sat, May 19, 2018 at 6:17 AM, Dewan Arif <ceoav...@gmail.com> wrote:
>
>> I hope you are doing great. I need your help for one of my project. I
>> want to transmit data in wireless communication using gnuradio and usrp
>> 2901. After that I want to calculate BER and plot BER vs SNR.
>>
>> First, you have to give me the Gnuradio Flowgraph. I want to transmit
>>
>> a. Text
>> b. Picture
>> c. Audio
>> d. Video.
>>
>> and you have to save at .txt ; .png ; .wav and .avi format in the
>> receiver end.
>>
>> you have to give two flow graph one for simulation and other for
>> real-time transmission (each data type text, picture, audio, and video)
>>
>> you have to use two scheme one is DPSK and other is WIFI.
>>
>> The second part is you have to calculate the BER and plot the BER vs SNR
>> curve in Matlab  for each transmission (text, picture, audio, and video)
>>
>>
>> It should not take much time if you are an expert.  I have attached the
>> picture as an example.
>>
>> List What I Want :
>>
>> 1) TransceiverFlowgraph.grc in Gnuradio ( data type: text, audio, video,
>> picture) DPSK and WiFi Simulation
>>
>> 2) Transceiver Flowgraph.grc in Gnuradio ( data type: text, audio, video,
>> picture) DPSK and WIFI Real-time transmission
>>
>> 3) Matlab code BER Calculation, plot BER vs SNR curve for simulation
>>
>> 4) Matlab code BER Calculation, plot BER vs SNR curve for real-time
>> transmission.
>>
>>
>> Please help me out
>>
>> ___
>> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] An analog RF question

[Dan CaJacob]

Hey Marcus,

This may not be what you are looking for, but these are awesome. They may
be going to space soon :)
http://www.newedges2.com/products/SAX239-R2_Datasheet_February-27th-2018.pdf

On Sun, May 20, 2018 at 10:13 PM li...@lazygranch.com <li...@lazygranch.com>
wrote:

> I used to work at Maxim, but my dealings with those RF guys dealt more
> with coffee and the quality thereof.
>
> I looked at the Maxim chip. The filter is relatively steep but not
> complex. Looks like two or three poles maximum. I don't know
> specifically about that chip, but that group had SiGe technology, so
> I'm leaning towards variable transconductance to do the tuning.
>
> You quickly learn just how bad google is at doing a search for this
> technology. The buzz phrase you need is continuous time, so I suggest
> "variable continuous time baseband filter". Sadly OTA gets links to
> "over the air." (And yet, they claim artificial intelligence will take
> over the world.)
>
> The thing to note in any highly integrated analog chip is that you
> don't see the sausage being made. Once you have a system on a chip, the
> metric is the system performance, not the performance per se of any
> individual block. So those filters may not be as great as you think.
> Note the Maxim part shows a tempco on the corner frequency, which could
> imply variable transconductance. One you have bipolar elements in the
> process, variable transconductance is just a matter of tail current.
> (SCF performance was relatively temperature independent.)
>
> Getting back to seeing the sausage, take the old analog modem market.
> Initially the SCF tech was used to make the official Bell 212 filters.
> Once the modem was fully integrated, the on-board filters were
> simplified for a number of really good engineering reasons, not just
> cost. One was the harmonic distortion of the band split filters. The
> harmonics of the in-band signal were far greater than the out-band
> signal that you were trying to reduce.
>
> Getting back to these baseband filters, if you use a ladder design, the
> filter is relatively immune to component error, well as opposed
> (contrasted) to a chain of biquads. If you go full differential, the
> variable transconductance amp are reasonably linear. But probably they
> limit the number of poles for the same harmonic distortion problem.
> Filters should subtract, not add.
>
> Most of the transconductance based filter designs probably are
> derivatives of integrated video filters. Plenty of papers online for
> those designs.
>
> If your goal is to roll together your own filter, TI has app notes on
> how to make analog tracking filters.
>
>  On Sun, 20 May 2018 21:19:47
> -0400 "Marcus D. Leech" <mle...@ripnet.com> wrote:
>
> > On 05/20/2018 09:13 PM, li...@lazygranch.com wrote:
> > >
> > > Can you be more specific about the corner frequency?
> > Corner frequencies step-tunable from perhaps 20Mhz down to perhaps
> > 2MHz.
> >
> > Many chips, like the R820T2, the MAX2112, and the higher-integration
> > devices like the AD9361 and LMS7002M have
> >programmable analog low-pass corner frequencies, for bandwidth
> > tailoring of the complex baseband.
> >
> > Just not sure how its done. The chips have very low external parts
> > count, so whatever it is, it's got to be done
> >internally...
> >
> >
> > >
> > > Cell phones use chips that have switchable banks of capacitors for
> > > antenna tuning. st.com IIRC is a source.
> > >
> > > I used to design switched capacitor filter chips in the 80/90s. The
> > > technology was killed by oversampled converters and DSP. The SCF
> > > players went into continuous time video filters using
> > > transconductance amps and such.
> > >
> > >
> > > ___
> > > 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] I miss the TCP server and client blocks!

[Dan CaJacob]

Yeah, use the ZeroMQ blocks.

On Wed, May 9, 2018 at 12:01 AM Brad Hein <linuxb...@gmail.com> wrote:

> Trying to get the socket PDU blocks to send and receive a stream of data
> is proving to be a significant challenge. I miss the simplicity and
> reliability of the TCP server and client blocks - they always "just worked"
> for me. I don't understand why they were deprecated only to leave us with
> these buggy and difficult to use socket PDU blocks.
>
> Sorry for the rant, I'm just running into one problem after another trying
> to get two flowgraphs to communicate using the socket PDU blocks (issue IDs
> 1770,1769,1763,1762).
>
> These new ZeroMQ blocks look cool. Are they a good alternative?
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] FSK Burst emission

[Dan CaJacob]

Speaking of gr-eventstream, Marcus: is there any intent to pull that or
something like it into core in this new Gnuradio world?

On Wed, Mar 28, 2018 at 3:22 PM Müller, Marcus (CEL) <muel...@kit.edu>
wrote:

> Hi Samuel,
> On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote:
> > I forgot to say that my graph is connected to hardware (bladerf or
> limesdr) via osmocom block. This one give me the error that there is not
> enough data.
>
> Jeff's mail recommending gr-eventstream was on-spot.
>
> Best regards,
> Marcus___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] FSK transmitter tutorial

[Dan CaJacob]

Check out the FSK : Digital section of
https://wiki.gnuradio.org/index.php/SignalProcessing Shows you how to set
up some variables you'll need. Freq modulator and quadrature demodulator
are important. So is filtering.

On Tue, Mar 20, 2018 at 7:49 AM Murray Thomson <murraythomson...@gmail.com>
wrote:

> Hi,
>
> I would like to build an FSK modulator/demodulator. I'm using file
> sink/sources for the moment. I need to be able to specify the two
> frequencies, baud rate and sample rate (ideally at runtime).
> I started with the gr-tutorial for qpsk, hoping to replace the
> modulation/demodulation with gfsk blocks, but I didn't get the result I was
> hoping for. I don't fully understand the gfsk module or how to change the
> frequencies after the modulation. I tried the fsk burst modem example, but
> it's not what I want. I would rather not use PDUs and I don't want to
> transmit in bursts.
>  I would really appreciate if someone could point me to a tutorial or
> example on this. These are the resources I have read so far:
>
>
> https://github.com/gnuradio/gr-tutorial/blob/master/examples/tutorial7/mpsk_stage6.grc
> https://nccgroup.github.io/RFTM/fsk_transmitter.html
>
> https://www.reddit.com/r/GNURadio/comments/3u5zp2/gnu_radio_gfsk_modulation_rate_deviation/
>
> http://www.indigresso.com/wiki/doku.php?id=opentag:radios:testing_with_gnuradio
>
> https://oshearesearch.com/index.php/2015/05/31/building-a-burst-fsk-modem-in-gnu-radio-with-message-lambda-blocks-and-eventstream/
>
> Many thanks,
> Murray
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Continous PSK/ FSK transmitter with discrete data

[Dan CaJacob]

Sure, but it is an example of doing it in software with minimal latency.
You could do the same with HDLC Flags for idle symbols. That's quite common.

On Tue, Mar 13, 2018, 3:07 AM Mehmet Ozcelebi <mehmetozcel...@gmail.com>
wrote:

> I am aware of your example, you use ccsds idle frame insert as a mechanism
> to achieve continous modulation. However, that is a pretty specific
> implementation.
>
>
>
>
> 2018-03-13 6:22 GMT+03:00 Dan CaJacob <dan.caja...@gmail.com>:
>
>> I've got a pretty complicated example at
>> https://github.com/dcajacob/gr-ccsds However, it could be simplified by
>> removing the convolutional encoding.
>>
>> On Mon, Mar 12, 2018 at 10:15 AM Mehmet Ozcelebi <
>> mehmetozcel...@gmail.com> wrote:
>>
>>> Dear All,
>>>  I have been playing with the blocks shown in " Guided Tutorial PSK
>>> Demodulation" and want to
>>> implement my own Transmitter/ Receiver pair.
>>>  First I tried to replace the "Random Source" or "File Source" blocks
>>> with a "Socket PDU-TCP Server". I observed that modulation happens only
>>> when I sent some characters and of course the demodulator could not lock
>>> properly and the data sent is not received correctly.
>>>  What I want is a continous transmission (no burst solutions please).
>>> Maybe something where the flowgraph generates "0" s if there is no data
>>> from the "Socket PDU" and enters a scrambler.
>>>  Which blocks should I use.
>>>  Thank you in advance.
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>
> --
Very Respectfully,

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

Re: [Discuss-gnuradio] Continous PSK/ FSK transmitter with discrete data

[Dan CaJacob]

I've got a pretty complicated example at
https://github.com/dcajacob/gr-ccsds However, it could be simplified by
removing the convolutional encoding.

On Mon, Mar 12, 2018 at 10:15 AM Mehmet Ozcelebi <mehmetozcel...@gmail.com>
wrote:

> Dear All,
>  I have been playing with the blocks shown in " Guided Tutorial PSK
> Demodulation" and want to
> implement my own Transmitter/ Receiver pair.
>  First I tried to replace the "Random Source" or "File Source" blocks with
> a "Socket PDU-TCP Server". I observed that modulation happens only when I
> sent some characters and of course the demodulator could not lock properly
> and the data sent is not received correctly.
>  What I want is a continous transmission (no burst solutions please).
> Maybe something where the flowgraph generates "0" s if there is no data
> from the "Socket PDU" and enters a scrambler.
>  Which blocks should I use.
>  Thank you in advance.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Convolutional decoder

[Dan CaJacob]

Use the FEC Extended Encoder/Decoder with the CC Encoder/Decoder definition
blocks. This assumes you are implementing a continuous modulation, like the
CCSDS standard and not a bursty system.

On Mon, Mar 12, 2018 at 9:03 AM samuel verdon <sam.ver...@gmail.com> wrote:

> Hello everybody,
>
>
>
> I am looking for a convolutional decoder for my ground station. I have
> found the ccsds 27 which does the 1/2 code rate. Unfortunately I would like
> to have ¾ code rate.
>
> I found the cc decoder definition with the FEC extended decoder. In
> documentation, it is written that it cannot operate with another code rate
> than ½.
>
>
>
> Do I misunderstood something or is there any generic “like” convolutional
> decoder that I can use for my purpose?
>
>
>
> Thanks a lot
>
>
>
> Sam
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] pfb_clock_sync fails with high signal amplitudes

[Dan CaJacob]

What is the actual amplitude where it fails? Many of the clock sync blocks
in GR expect a signal between -1.0 and +1.0, though I am not sure about the
PFB Clock Sync.

On Sun, Mar 11, 2018 at 10:37 AM Milos Milosavljevic <
milos.milosavlje...@spire.com> wrote:

> Dear All,
>
> I am using the pfb_clock_sync to estimate the timing offset in my QPSK
> receiver and I have a problem that I would like to ask about.
>
> Basically if the amplitude of the incoming signal is set relatively high
> (havent checked what actual threshold is) the flowgraph just hangs. After
> the process of elimination I discovered that it is actually the
> pfb_clock_sync block that causes this. Then I put some printf statements in
> the code and found out that the d_k (phase) value becomes -NaN when signal
> amplitude becomes high. The same thing is with the d_error from
> here d_error = (error_i + error_r) / 2.0.
>
> I suspect it is due to some filtering (either the RC or diff filter).
>
> Do you have any suggestions on where this might be coming from?
>
> Any comments will be highly appreciated.
>
> Many thanks,
>
> Kind Regards
> Milos
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Rounding values in QT Number

[Dan CaJacob]

I don't remember if the QT sink has this, but I seem to recall that some
GUI sinks have "formatters" which are basically the same as the python
formatter concept.

On Mon, Mar 5, 2018 at 4:41 PM John Ackermann N8UR <j...@febo.com> wrote:

> I hate to put such a dumb question to the list, but I'm going nuts
> trying to do something that ought to be simple.
>
> I am using a QT Number Sink to display dB values in float format.  It is
> showing many more decimal places than have any meaning.  I'd like to
> round the display to one or two decimal places.
>
> I tried making an embedded python block to do the rounding and finally
> succeeded (it was a long and painful process, and frankly I don't
> understand why I had to do what I did to get it to work), but the number
> sink is still printing all the extra decimal places, they're just now
> set to zero.
>
> Is there any trick to round or even just truncate the number of decimal
> places shown in the QT Number Sink?
>
> Thanks,
> John
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Just posted 2 job offerings

[Dan CaJacob]

LOL, $30 - $250 budget for a CCSDS modem.

On Sun, Mar 4, 2018 at 5:39 AM mehtap özkan <kurtulmeh...@gmail.com> wrote:

>
> https://discourse.myriadrf.org/t/just-posted-two-freelance-jobs/2421?u=booth
>
> If you are interested send me a message.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Fsk demodulation and sync trouble

[Dan CaJacob]

I'd suggest using the quadrature modulator block to build a better TX side.
Iterate on that until your signal looks correct. Then you can focus on the
RX.

On Wed, Feb 14, 2018 at 3:14 AM samuel verdon <sam.ver...@gmail.com> wrote:

> Hello everybody,
>
> I am building a FSK receiver to recover data on UHF. The bit rate of the
> data is 9,6kbps sent at 437MHz. I put all the information of the flowgraph.
>
> The data sent are a Stream of 0x55 or in binar « 1010 ». the medium
> between the emitter and the receiver is coax cable.
>
> Here is my flowgraph on GRC : https://ibb.co/ixMYkn
>
>
>
> I Use a bladeRF to record the signal. The Spectrum of the reception is the
> following : https://ibb.co/gA6Nd7
>
> As I can see the signal does not saturate the reception, then the signal
> should be readable.
>
>
>
> To summarize my flowgraph :
>
>- Multiply : to center of my signal
>- Low pass filter : gross filter to have the signal
>- Quadratur demod : demodulate the signal
>- Low pass filter (decimation) : keep only the signal and decimate the
>sample rate for the next block to 10 symbol per sample
>- Clock recovery MM : find the clock
>- Binary slicer : define 0 and 1
>
>
>
> At the end of the flowgraph I save the data received in a file and here is
> the result : https://ibb.co/dJyeQn
>
> I have some holes in my file that I do not understand. I tried to use the
> polyphase clock sync, I also changed the filter size, Nothing change.
>
>
>
> Does anyone has an idea where my mistake is ? I am sure that my emitter
> send the right data. If I miss information, tell me I will provide it/them.
> I also can send the gnuradio flowgraph.
>
>
>
> Thank you
>
>
>
>
>
> Samv
>
>
> ___________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Help needed regarding implementing spring mass system in GRC

[Dan CaJacob]

Hey Afaq,

Unfortunately, GNURadio doesn't allow for signal feedback the way Simulink
does. You can do feedback *within* a block, but that probably defeats the
flexibility you were seeking?

- Dan

On Mon, Dec 4, 2017 at 9:33 AM Afaq Ahmed <engineer.aa...@gmail.com> wrote:

> Hello,
> I want to implement spring mass system with PID controller of example
> mentioned in following link
>
> [
> http://ctms.engin.umich.edu/CTMS/index.php?example=Introduction=ControlPID
> ]
>
> I want to create a flow graph exactly as given in the figure
> "Spring_mass_simulink" . Can you please help me how can i achieve this
> target? As i tried to implement it but unfortunately i always get an error
> of "Flow graph has loops"
> Thanks a lot
> Afaq
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Rounding errors in PFB channelizer?

[Dan CaJacob]

Does the number of channels have to be a power of 2?

On Wed, Nov 29, 2017 at 10:39 AM John Ackermann N8UR <j...@febo.com> wrote:

> I'm building a ridiculous flowgraph that breaks the AM broadcast band
> (540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
> the energy in each.  The thing is working but I see a frequency offset
> in the output channels that is not present in the data before
> channelizing.  The output channels seem to have an offset in the range
> of 400 to 700 Hz versus the unchannelized input.
>
> The signal chain is:
>
> 2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
> output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
> a channel rate of 10,683.760683.. samples per second.
>
> Looking at the spectrum at the output of the xlating filter, the carrier
> frequencies are correct.  Looking at the output of a channel, the
> carriers are offset by several hundred Hertz, always high.  (Given the
> absolute frequency is in the 1 MHz range, these offsets are parts in
> 1e3, a pretty large amount.)
>
> I wonder if the large number of PFB channels is causing a rounding error
> that results in these frequency offsets.  Or is there something else
> going on?
>
> I can probably fudge the xlating filter frequency a bit to move the
> carriers closer to nominal, but would like to understand what's happening.
>
> I'm attaching the (absurdly huge) .grc file.  The canvas is 4192 pixels
> tall, so the flowgraph is smaller than the screenshot. :-)
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Global socket in the flowgraph

[Dan CaJacob]

This kinda looks like a good application for ZMQ, btw.

On Fri, Nov 17, 2017 at 8:12 AM Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com> wrote:

> Perfect!! Thank you :)
>
> 2017-11-17 12:42 GMT+01:00 Marcus Müller <muel...@kit.edu>:
>
>> You'd pass that object – all the objects that you create in Python have
>> a name that you can pass around.
>>
>> Notice that you usually very much would want to avoid this. The blocks
>> run in different threads, so you need take care that accesses to your
>> shared object are thread save, e.g. by having internal mutexes.
>>
>> In your case, having a block that manages the socket, and which sends
>> GNU Radio messages to your other blocks, would sound easier and safer.
>>
>> Best regards,
>> Marcus
>>
>> On Fri, 2017-11-17 at 12:13 +0100, Carlos Alberto Ruiz Naranjo wrote:
>> > Hi Marcus,
>> >
>> > I apologize if I have not explained myself well.
>> >
>> > I want to use a global object (an open socket) inside blocks. Similar
>> to using a global variable with the 'Python Module' block.
>> >
>> > The problem is that I do not know how to access to an object/variable
>> created in 'Python Module' inside another module.
>> >
>> > Thank you.
>> >
>> > 2017-11-17 11:08 GMT+01:00 Marcus Müller <muel...@kit.edu>:
>> > > Hi Carlos,
>> > > I'm a little bit confused; this sounds a lot more like you want to
>> design a client/server protocol with logical "subchannels" or something
>> than a GNU Radio question.
>> > >
>> > > If you asked me, sounds like you wouldn't go for a single socket, but
>> three ZeroMQ sockets of the right usage paradigm (might be pub/sub,
>> req/rep, or any of the roundrobin ones).
>> > >
>> > > In any case, your block has no provisions for talking to a socket, so
>> not quite sure what you're asking me – "write a program that talks to
>> sockets" isn't really a great question for the GNU Radio mailing list ;)
>> > >
>> > > Best regards,
>> > > Marcus
>> > >
>> > > On Fri, 2017-11-17 at 10:07 +0100, Carlos Alberto Ruiz Naranjo wrote:
>> > > > Hi Marcus,
>> > > >
>> > > > It is the code: https://pastebin.com/Ts07d0wg
>> > > >
>> > > > Depends on the data of the block makes a request to the server or
>> another. I want to have a common socket for all the blocks, not to use one
>> client per block.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > 2017-11-16 20:56 GMT+01:00 Marcus Müller <muel...@kit.edu>:
>> > > > > Hi Carlos,
>> > > > > I don't know the blocks, hence I can't tell you anything about
>> them.
>> > > > > Best regards,
>> > > > > Marcus
>> > > > >
>> > > > > On 16.11.2017 19:32, Carlos Alberto Ruiz Naranjo wrote:
>> > > > > > Thank you Marcus.
>> > > > > >
>> > > > > > Where do I create the socket and how I pass it to the blocks?
>> > > > > >
>> > > > > > On Nov 16, 2017 19:07, "Marcus Müller" <muel...@kit.edu> wrote:
>> > > > > > > Sure, unless the dataCapture blocks (which I don't know) have
>> a bug.
>> > > > > > >
>> > > > > > > Best regards,
>> > > > > > > Marcus
>> > > > > > > On Thu, 2017-11-16 at 15:26 +0100, Carlos Alberto Ruiz
>> Naranjo wrote:
>> > > > > > > > Hello,
>> > > > > > > >
>> > > > > > > > dataCapture blocks are TCP clients with different requests.
>> I want use the same socket for the 3 blocks. It is posible?
>> > > > > > > >
>> > > > > > > > Thank you.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > ___
>> > > > > > > > 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Dan CaJacob]

I suppose if you don't have 64 bit, you can just shift it to be 32-bit and
sacrifice the lost precision. There's probably other possibilities, but I
think the newer ARM stuff is going 64-bit anyhow.

On Mon, Nov 13, 2017 at 2:01 PM Marcus Müller <muel...@kit.edu> wrote:

> Ok, see your point. I was a bit hesitant at first because that will end
> up needing 64bit division (which might really not be much fun on many
> ARMs), but meh, it's not like someone should be pushing tags around as
> if they're samples.
>
> Cheers,
> Marcus
>
> On Sun, 2017-11-12 at 23:33 +, Dan CaJacob wrote:
> > Why not make the sub-second offset a uint64. That way you can express
> time to the atto second (I think). The precision is overkill, but uint32,
> which barely breaks a picosecond is underkill.
> >
> > On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller <marcus.muel...@ettus.com>
> wrote:
> > > Hi Eugene,
> > > yup, fully agree, the whole concept is slightly broken.
> > > So, first of all, I really think the key problem we're constantly
> working around is that tags have an integer offset – which leads to
> rounding errors, even in relatively benign scenarios.
> > > I'd propose we add a fractional part: that would only extend tag_t by
> another integer field, so existing blocks wouldn't break, and would allow
> non-1:1-sync blocks to properly rewrite tag positions.
> > > As you say, floating point is a bad idea when dealing with times (it
> always has been – see uhd::time_spec_t, where we're constantly paying off
> the technical debt of having floating point as "suggested" default
> representation of time, albeit underneath things should (and to some
> degree, are) counted in ticks). Thus, I'd imagine a tag_t like
> > > struct tag_t {
> > > uint64_t offset; //integer offset, as had
> > > uint32_t fractional_offset; //interpret as fractional part, i.e.
> ·2^{-32}
> > > pmt::pmt_t key;
> > > pmt::pmt_t tag;
> > > pmt::pmt_t srcid; // might as well drop this; maybe someone is
> using this, but I haven't met them
> > > std::vector marked_deleted;
> > > }
> > > Would the fractional offset solve the issues you're seeing, assuming
> that we add proper handling to all the existing resamplers?
> > > Best regards,
> > > Marcus
> > >
> > >
> > > On 09.11.2017 20:52, Eugene Grayver wrote:
> > > > There is a major problem with the way tags are propagated in blocks
> with non-integer relative rate. If the ratio is not a power of two, the
> numerical accuracy of the floating point will cause the output tags to
> diverge from the input tags.  Consider the fractional resampler. It
> accumulates the timing offset in the range of 0 to 1. However tag
> propagation multiplies the ratio by the sample number. As the sample number
> grows the LSB accuracy of the ratio gets scaled by the ever larger value.
> For a ratio of 1.001 we saw divergence of 1000s of samples over a few
> minutes at 10msps. I rewrote tag propagation for the resampler but did not
> rework the generic logic. I think the key point is to use the delta between
> read and written items to take out the large integer difference and then
> apply the scaling to a local delta within the current window.
> > > >
> > > > ___
> > > > Eugene Grayver, Ph.D.
> > > > Aerospace Corp., Sr. Eng. Spec.
> > > > Tel: 310.336.1274 <(310)%20336-1274>
> > > > 
> > > >
> > > >
> > > >
> > > > ___
> > > > 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
> >
> > --
> > Very Respectfully,
> >
> > Dan CaJacob
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Dan CaJacob]

Why not make the sub-second offset a uint64. That way you can express time
to the atto second (I think). The precision is overkill, but uint32, which
barely breaks a picosecond is underkill.

On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Eugene,
>
> yup, fully agree, the whole concept is slightly broken.
>
> So, first of all, I really think the key problem we're constantly working
> around is that tags have an integer offset – which leads to rounding
> errors, even in relatively benign scenarios.
>
> I'd propose we add a fractional part: that would only extend tag_t by
> another integer field, so existing blocks wouldn't break, and would allow
> non-1:1-sync blocks to properly rewrite tag positions.
>
> As you say, floating point is a bad idea when dealing with times (it
> always has been – see uhd::time_spec_t, where we're constantly paying off
> the technical debt of having floating point as "suggested" default
> representation of time, albeit underneath things should (and to some
> degree, are) counted in ticks). Thus, I'd imagine a tag_t like
>
> struct tag_t {
> uint64_t offset; //integer offset, as had
> uint32_t fractional_offset; //interpret as fractional part, i.e. ·2^{-32}
> pmt::pmt_t key;
> pmt::pmt_t tag;
> pmt::pmt_t srcid; // might as well drop this; maybe someone is using 
> this, but I haven't met them
> std::vector marked_deleted;
> }
>
> Would the fractional offset solve the issues you're seeing, assuming that
> we add proper handling to all the existing resamplers?
> Best regards,
> Marcus
>
>
> On 09.11.2017 20:52, Eugene Grayver wrote:
>
> There is a major problem with the way tags are propagated in blocks with
> non-integer relative rate. If the ratio is not a power of two, the
> numerical accuracy of the floating point will cause the output tags to
> diverge from the input tags.  Consider the fractional resampler. It
> accumulates the timing offset in the range of 0 to 1. However tag
> propagation multiplies the ratio by the sample number. As the sample number
> grows the LSB accuracy of the ratio gets scaled by the ever larger value.
> For a ratio of 1.001 we saw divergence of 1000s of samples over a few
> minutes at 10msps. I rewrote tag propagation for the resampler but did not
> rework the generic logic. I think the key point is to use the delta between
> read and written items to take out the large integer difference and then
> apply the scaling to a local delta within the current window.
>
>
>
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274 <(310)%20336-1274>
> 
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] GNU radio implementation for measuring frequency response

[Dan CaJacob]

If you just want to sweep a filter, that's pretty easy. Just TX into one
port and RX from the other. Sweep a sine wave on the TX range and attach an
FFT sink to the RX port and set max hold.

On Fri, Oct 20, 2017 at 5:50 PM Suman Bhunia <su...@sbhunia.me> wrote:

> Hi !
>
> I want to measure frequency response of of a material in the 2.4 GHz ISM
> band. I was wondering if there is any GNURadio based implementation anyone
> is aware of that I can use instantly. Any suggestion regarding the
> implementation is also welcome.
>
>
> I want to measure the frequency response from 2.4 GHz to 2.5 GHz. I want
> to use 2 USRP boards one as Tx and another as Rx. Alternatively, I can use
> the same board and use the two different ports if it makes more sense.
>
> Thanks for your help in advance.
>
> Suman
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Synchronisation

[Dan CaJacob]

I could be wrong, but I thought the SBX was one of the few daughter cards
that starts with s known phase offset?

On Sun, Sep 10, 2017, 2:49 PM Fulcrum Associates <sla1nte2...@gmail.com>
wrote:

> Dear All,
>
>   I have a couple of USRPs connected, through  a strong
> attenuator to a signal generator (NWT4001). While the units have a MIMO
> option, I don't have that cable. (Option A) When I run the GRC as
> attached, I see too good a result to the extent that the differential
> Phi seems to range over +/- 5 degrees.
>
>
>   What I had hoped to prove to myself that two N200 with SBX
> would have a varying offset without MIMO cable, then I would connect the
> MIMO cable and move the USRPs into a multi-unit and enable GPSD O/B on
> the unit which has the feature and MIMO for one without (Option B) and
> that the phase differential would improve noticeably and be a variable
> constant, but it didn't.
>
>
>If it had, but there still was a fixed phase offset which
> varied each time it was setup (which is what I would expect under B)
> then I would hand-code the SBX stream initialisation code to remove the
> offset.
>
>
>Does my FG not measure what I claim to be wishing to
> measure?
>
>If it does measure it correctly, why do my expectations
> of options A and B leading to a different (though improved) situation
> not eventuate?
>
>
>Kind Regards,
>
>
>   John
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Bit Sync- Frame Sync Lock indication?

[Dan CaJacob]

I haven't seen it outside of some closed source GUIs, but frame sync
indication wouldn't be too hard. It's usually just part of a state machine
that checks to see if you've seen n good frame sync markers in a row.

On Tue, Aug 29, 2017 at 6:10 PM Mehmet Ozcelebi <mehmetozcel...@gmail.com>
wrote:

> Dear All,
>  I have been playing with the Frame sync, Packet-Header blocks recently.
> However I could not find any block that has an "FRAME LOCK" indication
> (when the correct  Header is found).
> Any block, OOT suggestions?
>
> Also I see "Bit Sync" in some Modem HW.
> Is there anything like that in GNU Radio receiver blocks?
>
> Thank you in advance.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] The use of scrambler/ descrambler blocks

[Dan CaJacob]

Or add fill bytes/frames, since this sounds rather like a streaming modem.

On Tue, Aug 29, 2017 at 11:17 AM Marcus Müller <muel...@kit.edu> wrote:

> Then, you very likely want to pad your data with zeros; there's Tim
> O'Shea's gr-eventstream, which is designed for that operation!
>
> Best regards,
>
> Marcus
>
> On 08/29/2017 04:34 PM, Mehmet Ozcelebi wrote:
>
> I just want to transmit scrambled data continously, even if there is no
> input data.
> For continous sources like "Vector source" it works fine since data flows
> continously.
> For source like qtgui_edit_box_msg or a few characters from TCP/IP or
> Message Strobe,modulation occurs only if input data is present and this is
> not wanted. I am missing something but do't know what.
>
>
> 2017-08-29 15:41 GMT+03:00 Marcus Müller <muel...@kit.edu>:
>
>> Hi Mehtap,
>>
>> unlike your FPGA, the GNU Radio blocks don't work data-synchronously. So,
>> they simply won't give you any output if you don't call them with input!
>> Maybe you could elaborate on what you mean with "got stuck"?
>>
>> So, I'm not quite sure what the problem actually is, albeit I'm pretty
>> sure your solution isn't really the solution.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 08/28/2017 09:54 PM, mehtap özkan wrote:
>>
>> Some years ago I implemented a scrambler block in FPGA for a transmitter.
>> It produced an output every clock cycle.
>> Now I try the GNU Radio scrambler/descrambler blocks. They work great if
>> the data flows continously like from a Vector source or File.
>> However if I have a discontinous source like a text message or a TCP/IP
>> Source, the scrambler got stuck and has no output. In others words I need
>> something analogous to a CLOCK for discontinous sources.
>> How to achieve that? Maybe XORing the discontinous source with a source
>> of 0's produced at "sample rate"?
>>  Thanks for your time.
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Simulating non linearity and distortion

[Dan CaJacob]

Here they are:

https://www.youtube.com/watch?v=wqKNUXDdIvU
https://www.youtube.com/watch?v=PNMOwhEHE6w

The blocks that he uses in the presentations have been a part of core
GNURadio for a while, so you can use them yourself to help understand
things. This is what Marcus was refering to.

On Sat, Aug 26, 2017 at 8:39 PM Robert McGwier <rwmcgw...@gmail.com> wrote:

> And one of the best talks Matt Ettus has ever given was his talk on
> learning about impairments using gnuradio.
>
> See if you can dig that up or maybe someone can point to it that has a
> better memory than mine.
>
> Bob
>
>
> On Aug 18, 2017 1:45 PM, "Marcus Müller" <marcus.muel...@ettus.com> wrote:
>
>> Yes. There's a whole category "impairment models" in GRC.
>>
>> Best regards,
>>
>> Marcus
>> On 08/18/2017 07:11 PM, mohammad nejati wrote:
>>
>> Hi ,
>> is there any block ( or OOT module) for simulating power amplifier non
>> linearity ?
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Packet encoding example (Packet_loopback_hier.grc)

[Dan CaJacob]

I am offering advice without looking at the flowgraph, so take this with a
grain of salt, but sps usually stands for samples per *symbol*, not seconds.

On Sat, Aug 26, 2017 at 4:04 AM Marcus Müller <muel...@kit.edu> wrote:

> Hi Mehtap,
>
> huh, if increasing sps = 100 is all that it takes to trigger this, then
> this is probably¹ a bug. And as such, we should fix it. Just to confirm: If
> you take a totally unmodified packet_loopback_hier.grc and **only** change
> sps=100, then you get this?
>
> Generally, sps=100 seems… unintuitive. Use something like sps=20 and
> interpolate by 5? The ISI suppression gain you get from a longer RRC will
> decrease with growing RRC length.
>
> Best regards,
>
> Marcus
> ¹: I say "probably", because I don't have packet_rx in front of me right
> now, and there might be a "logical" limitation, where something else
> depends on sps and another factor, and you'd have to adjust that other
> factor, too, for the flow graph to "make sense".
> On 25.08.2017 21:33, mehtap özkan wrote:
>
> Thanks to Marcus Müller I became aware of the Packet TX and RX blocks.
>  I use the Packet_loopback_hier.grc example. However the example is set to
> 2 samples per seconds=sps. When I try to increase sps=100, the number of
> taps of the RRC filter becomes( 5*sps*nfilts) exceeds its limit.
>  I get
> ../.grc_gnuradio\packet_rx.py", line 49, in __init__
> self.mark_delay = mark_delay = mark_delays[sps]
> IndexError: list index out of range
>
> Is there another way to increase the speed limit?
>
> Thanks
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Daemonizing a flowgraph

[Dan CaJacob]

Marcus' suggestions are great. In the past, I have also used supervisord to
"daemonize" a flowgraph. If it ever dies, supervisord brings it right back
if that's what you want. It's like systemd for python, kinda.

On Wed, Jul 12, 2017 at 3:30 AM Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Oh, by the way, maybe you, instead, simply would want to run your whole
> flowgraph using `nohup`, or simply in a `screen` or `tmux` session :)
>
> On 07/12/2017 09:22 AM, Marcus Müller wrote:
>
> If you can, update to the most current UHD – we've worked on the logging
> infrastructure, and you can simply disable that.
> This will probably require building both UHD, and as soon as you've done
> that, GNU Radio from source.
>
> Best regards,
> Marcus
>
> On 07/11/2017 10:39 PM, devin kelly wrote:
>
> Hello,
>
> I have a flowgraph that I made with  GRC and modified.  All I want to do
> with the flowgraph is make it run as a daemon.  I understand that if there
> are overflows or underflows I'll miss them, that's OK.
>
> I added some basic python code to daemonize my flowgraph:
>
>
> # Fork once
> try:
> pid = os.fork()
> except OSError:
> print 'error forking'
>
> if pid > 0:  # if parent, return
> return
>
> os.umask(0)
>
> # Reset the session ID
> try:
> os.setsid()
> except OSError:
> sys.exit(1)
>
> # Fork twice, giving up ownership of first parent's SID
> try:
> pid = os.fork()
> except OSError:
> print 'error forking'
>
> if pid != 0:  # if parent, return
> sys.exit(0)
>
> # Change PWD
> try:
> os.chdir('/')
> except OSError:
> return
>
> # Close open files
> sys.stdin.close()
> sys.stdout.close()
> sys.stderr.close()
>
> with open('/dev/null', 'r+') as devnull:
> sys.stdin = devnull
> sys.stdout = devnull
> sys.stderr = devnull
>
> tb = top_block_cls(options)
> tb.start()
> time.sleep(60.0)
> tb.stop()
> tb.wait()
>
> When I run this, it works at first (I get my prompt back, you can see me
> trying to open the file).  But then the UHD hijacks my stdout/stderr and
> resumes as if nothing happened.
>
> $ ./flowgraph.py -t
> 30
>
> linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.005-0-g32951af2
>
> $ vim flowgraph.py -- X300 initialization
> sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
>
> How do I stop the UHD from doing this?
>
> Thanks for any help,
> Devin
>
>
> _______
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Managing clutter in GRC GUI

[Dan CaJacob]

You can't manage the lines manually, but you can probably make things
closer to what you want by using virtual sources and sinks.

On Fri, Jun 9, 2017 at 1:52 AM Vipin Sharma <vipinsha...@photonpace.com>
wrote:

> I have an application with multiple blocks in the GUI. When I finish
> connecting all the blocks the picture looks really messy. I cannot seem to
> manually move/drag the connections from going over the blocks.
>
> Is there any way to guide connection routes manually so that my
> application looks more readable in the GUI?
>
> Vipin
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Which block for Fast PSK demodulation under some doppler shift?

[Dan CaJacob]

That's fine for low rate stuff, but for Mehmeto's application, he probably
needs to be more coherent.  Correlating on a preamble would be a good idea,
I think.

On Fri, Apr 28, 2017 at 9:04 AM Vitt Benv <vitt...@gmail.com> wrote:

> Hi Mehmeto,
> in my opinion and in my experience with LEO sats, it's usefull to retune
> the receiver using doppler correction info coming from external app.
> In the past I used to query old beloved Predict via socket to control a
> ICOM PR1000 receiver with a little utility that I wrote ( google "pcrsat" ).
> It worked fine to demodulated 1200BPSK or CW telemetry also on heavy
> doppler (ovehead pass).
>
> Ciao,
> Victor
>
>
> 2017-04-28 13:40 GMT+02:00 Mehmeto <mehmetozcel...@gmail.com>:
>
>> Dear All,
>>  I have a situation where I need to demodulate a wide bandwidth signal (70
>> Mbps QPSK modulated, having 35 MHz IF bandwidth and sampled at 105 MSPS )
>> in
>> our lab. However, the signal generator will also add some amount of
>> doppler
>> shift at a rate of 1 kHz/s. Which PSK demodulation blocks are suitable for
>> fast demodulation under some doppler shift. I
>>  I know that I can not use the Costas Loop or any other block that uses a
>> feedback loop because of their speed limitations.
>>  I am considering to add a preamble to simplify things since I know high
>> speed Satellite downlinks use Preamble. I guess the use of preambles make
>> demodulation easier.
>>
>> Please advise.
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/Which-block-for-Fast-PSK-demodulation-under-some-doppler-shift-tp63700.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
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Is 100 Mbps PSK demodulation in GNU RADIO possible? (x310 HW)

[Dan CaJacob]

I am working on a similar system.  In short, the answer is no, your i7
won't keep up that fast.  But you could if you push some processing down
into the FPGA.

For example, my non optimized QPSK modem with 1/2 rate convolutional coding
+ RS coding only works up to about 1 Mbps without over/under flowing.

While optimization will help, 100 Mbps seems like too much of a stretch for
real-time on normal CPUs, but possible on FPGA.  Or maybe possible with
like 40 i7s.

On Fri, Apr 14, 2017, 5:30 AM Mehmeto <mehmetozcel...@gmail.com> wrote:

> Dear All,
>  We just bought an Ettus X310 with PCIe interface.
> We will try to transmit a 100 Mbps OQPSK signal and receive it back using
> the PSK demodulator blocks.
> In your opinion is this possible. Assuming that the HW support such a
> speed,
> will the speed of the GNU Radio Blocks be sufficient? (We will be using one
> of the latest i7 processors.)
>  We couldn't find any max. speed data on these blocks.
> We are also considering to use some high speed GPU but could not find any
> CUDA/ OpenCL based GNU Radio blocks.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Is-100-Mbps-PSK-demodulation-in-GNU-RADIO-possible-x310-HW-tp63527.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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] AWGN using E310 (Update)

[Dan CaJacob]

That's out of my experience.  But it's not easy - you have to learn RFNOC.
It's a lot of work.  Try the Ettus channel.

On Mon, Apr 10, 2017 at 10:11 AM John B. Wood <john.w...@nrl.navy.mil>
wrote:

> On 04/10/2017 09:31 AM, Dan CaJacob wrote:
> > It's probably unreasonable to expect the ARM processor to deliver 56 Msps
> > to the 9361 without underflowing.  It's just not that fast.  It's
> marginal
> > even on a high performance desktop CPU.  You could try implementing a
> noise
> > source in the FPGA using RFNOC.  That would almost certainly eliminate
> your
> > bottleneck.
> Thanks for the quick reply, Dan.  How do I get the RFNoC blocks to
> appear as selectable itmes in the GRC menu list?
>
>
>  John Wood
>  U.S. Naval Research Laboratory
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] AWGN using E310 (Update)

[Dan CaJacob]

It's probably unreasonable to expect the ARM processor to deliver 56 Msps
to the 9361 without underflowing.  It's just not that fast.  It's marginal
even on a high performance desktop CPU.  You could try implementing a noise
source in the FPGA using RFNOC.  That would almost certainly eliminate your
bottleneck.

On Mon, Apr 10, 2017 at 9:27 AM John B. Wood <john.w...@nrl.navy.mil> wrote:

> Hello, all.  Perhaps I was a little too optimistic in attempting to use
> the Ettus E310 as a broadband noise source.  I'm using the GRC models
> "Fast Noise Source" with uniform noise type connected to a "UHD: USRP
> Sink" with a CF of 1 GHZ and sample rate set to 4 Msps.  Running the
> GRC-generated .py code on the E310's embedded Arm processor results in a
> reasonably flat noise spectrum over ~3.5 MHz about the CF as displayed
> on a spectrum analyzer.  Attempting to increase the sample rate above 4
> Msps to obtain a wider noise BW results in a whole lot of buffer
> underruns (all those "U"s in the terminal window and a ragged noise output.
>
> The advertised instantaneous BW of the E310 is 56 MHz but clearly the
> available flat noise spectrum is no where near that.  As always your
> comment is most appreciated.  Sincerely,
>
>
> John Wood
> U.S. Naval Research Laboratory
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] FEC: Convolutional Encoder Gnuradio and Matlab: different results

[Dan CaJacob]

Hi Emanuel,

Try bit-reversing the polynomials.  By the way, even though the block
definitions can take any python representation of the numbers.  For
instance 91 decimal is 0x5B (hex) and 091 (octal) in python.  I often use
the leading zero octal notation for stuff like this since the weirdos who
came up with conv encoding like to use octal to specify their polynomials.

- Dan

On Wed, Mar 22, 2017 at 10:16 AM Usman Haider <usmanhaide...@gmail.com>
wrote:

> Hi Emanuel,
>
> Maybe you find following thread useful.
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-09/msg00404.html
>
> --
> Usman
>
>
>
> On Wed, Mar 22, 2017 at 1:07 PM, <emanuel.staudin...@dlr.de> wrote:
>
> Hi together,
>
>
>
> I’m using the FEC Async Encoder with the CC Encoder Definition.
> Input/Output are unpacked and I use the terminated behavior. In Gnuradio
> the polynomials for the CC Encoder Definition are defined on a base of 10,
> and not as octals like in MATLAB, right?
>
>
>
> I tried the following: 1 bit with ‘1’ as input to the FEC Async Encoder
> and the same in MATLAB to check the response of the encoder. The results
> don’t match. No matter if I use different constraint lengths, rates or
> polynomials.
>
> e.g. in Matlab: K = 7, 1/R=2, Polynomials (octal) [171,133] and Gnuradio
> Polynomials (10-base) [121,91] give completely different outputs.
>
>
>
> No matter what I do, e.g., using octal representation in Gnuradio, or
> changing the polynomials’ positions in the specified vector, gives me a
> result which matches.
>
>
>
> Did anyone compare results before? Any clues?
>
> Regards,
>
> Emanuel
>
>
>
> ___
> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] GPU accelerated Viterbi decoder?

[Dan CaJacob]

What data rates are you working at?  I haven't had so much trouble with
Viterbi being a limiting factor up to about 1 Mbps QPSK with concatenated
coding.

Sadly, I have no experience moving this to GPU.

On Tue, Mar 21, 2017 at 5:25 AM Mehmeto <mehmetozcel...@gmail.com> wrote:

> Dera All,
>  In almost all cases the Viterbi decoder block eats a lot of CPU time. The
> best alternative is a GPU solution. I have searched for an open source GPU
> implementation but could not find one. There is a MATLAB implementation but
> that one is far from open source.
> Any Ideas? Is it easy to port gr-fec to a CUDA/ openCL based platform?
> Thanks
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/GPU-accelerated-Viterbi-decoder-tp63205.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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Punctured viterbi decoder?

[Dan CaJacob]

Try the gr-fec blocks - specifically the Extended En/Decoders.  The CCSDS27
blocks are fine, but they're older and for a specific set of polys.

On Mon, Mar 20, 2017 at 11:57 AM Ron Economos <w...@comcast.net> wrote:

> In the "Error Coding" category of GNU Radio Companion, there are
> Puncture and Depuncture blocks.
>
> Here are some example parameters that work for DVB-S.
>
> 1/2 code rate = Puncture Size = 2, Puncture Pattern = 0b11
> 2/3 code rate = Puncture Size = 4, Puncture Pattern = 0b1101
> 3/4 code rate = Puncture Size = 6, Puncture Pattern = 0b110110
> 5/6 code rate = Puncture Size = 10, Puncture Pattern = 0b1101100110
> 7/8 code rate = Puncture Size = 14, Puncture Pattern = 0b11010101100110
>
> Ron
>
> On 03/20/2017 08:40 AM, Booth wrote:
> > Dear All,
> > I've been playing with the CCSDS27 viterbi decoder block which supports
> 1/2
> > rate. However we also need punctured codes like 3/4, 5/6, 7/8. Which
> block
> > should we use. Any recommendations?
> >
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Adding An Image File In GRC

[Dan CaJacob]

Use the raster sink :)

On Thu, Mar 16, 2017 at 5:22 PM Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Find the .xml file that describes the Qt label GRC block – it's very
> likely in gnuradio/gr-qtgui/grc – copy and modify it to your needs :) That
> way, you can have your own "image label". GNU Radio as project certainly
> wouldn't mind getting that new XML file as addition, neither :)
> Best regards,
> Marcus
>
>
> On 16.03.2017 21:20, Timothy Coyle wrote:
>
> Hi Marcus,
>
> I already got the Qt Label to show an image by editing the python file
> that GRC creates. The problem is that if I want to use GRC “interactively”
> to change parameters/settings/etc. that’s not available in the GUI I create
> then the python file is overwritten by GRC. So I was just wondering if
> there was a way inside of GNU Radio to use the Qt Label widget to display
> an image file. Thinking about it may be I could use an embedded python
> block or module – I’ll have to look into that.
>
>
>
> Thanks,
>
>
>
> Tim
>
>
>
> *From:* Discuss-gnuradio [
> mailto:discuss-gnuradio-bounces+tcoyle=environetix@gnu.org
> <discuss-gnuradio-bounces+tcoyle=environetix@gnu.org>] *On Behalf Of 
> *Marcus
> Müller
> *Sent:* Thursday, March 16, 2017 2:26 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Adding An Image File In GRC
>
>
>
> Hi Timothy,
>
> hm, basically, all the Qt GUI things are really Qt QWidgets and
> subclasses. The python file generated by GRC sets up the window and stuff.
> I think the quickest way of understanding how this all works together is
> making a small Qt-GUI-based flow graph, and diff'ing the python code before
> and after you add a Qt Label. You might be able to add a picture label just
> the same way.
>
> If you haven't noticed these before: you can basically configure a grid
> layout by filing the "gui hint" field in the Qt GUI blocks with
> "row,col,rowspan,colspan", where rows and columns start with 0.
>
> Best regards,
>
> Marcus
>
>
>
> On 03/16/2017 02:46 PM, Timothy Coyle wrote:
>
> Hi,
>
> I am using GRC to create a flow graph that has a GUI and I’m looking for a
> way to add an image (a logo) to the GUI. Is there a way to use one of the
> Qt GUI widgets to add an image file? I know I can edit the python file
> created by GRC and add image file where I want but I think if I’m using GRC
> to make changes it will overwrite my modifications to the python file.
>
>
>
> Thanks,
>
>
>
> Timothy Coyle
>
> Staff Engineer
>
> Environetix Technologies
>
>
>
> 20 Godfrey Drive
>
> Orono, ME  04473
>
>
>
> Office: (207) 866-6551
>
> Cell: (207)844-0951 <(207)%20844-0951>
>
>
>
> www.environetix.com
>
>
>
>
>
>
> _______
>
> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] intermittent pulse detection

[Dan CaJacob]

ion blocks? I found the "correlation estimator" but not
> clear how to use it. As for dealing with the frequency uncertainty
> problem. Does one just try correlating with different freuencies and
> pick the best one? Or what is the good thing to do here given I may
> also have to deal with quite a bit of noise.
>
> Any guidance appreciated.
>
> Many thanks,
>
> Dirk
>
> ___________
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> _
> Dr. Dirk Gorissen
> Mob: +44-7763-806-809 <+44%207763%20806809>
> Web: dirkgorissen.com
> Skype: dirk.gorissen
> Twitter  : twitter.com/dirkgor
> LinkedIn: linkedin.com/in/dirkgorissen
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Block "Max" GNU Radio

[Dan CaJacob]

Make a new block based on the original?

On Mon, Jan 16, 2017 at 2:51 PM adrianapa <pablosanro...@live.com> wrote:

> Hi all,
>
> I want to modify the block Max: instead calculate a maximum, I want to
> calculate the maximum and two bins (two points) on each side and do a
> average with this three values. Should I modify this code?[1]
> Any help is welcome.
>
>
> Best regards,
>
> Pablo
>
> [1]
> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/ca7bef020515c27d7a9d732cf60a79ab055ea196/entry/gr-blocks/lib/max_XX_impl.cc.t
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Block-Max-GNU-Radio-tp62533.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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Bug in GPS time reported by the USRP

[Dan CaJacob]

Hi Eugene,

Please check that time stamp here: http://www.unixtimestamp.com/index.php
It looks alright to me.  It *is* reporting the correct time in a unix
timestamp format.  Maybe you are making a more subtle point about
nomenclature?  As in the GPS epoch is not the same as the Unix timestamp
epoch  in 1970?  In any event, a unix time stamp is fairly common,
unambiguous way to specify a time.

Thanks,

Dan

On Tue, Dec 6, 2016 at 8:19 PM Eugene Grayver <eugene.gray...@aero.org>
wrote:

> This is being posted to both GR and Ettus forums because both groups
> should be aware.
>
>
> The value returned by  USRP.get_mboard_sensor('gps_time') is incorrect.
> It is NOT the GPS epoch, but is time relative to the UNIX epoch.  Only off
> by a decade or so...
>
>
> 'GPS epoch time: 1481073287 seconds'
>
>
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274 <(310)%20336-1274>
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] GNUradio and external electronic relay switching?

[Dan CaJacob]

This is possible.  You'd write a custom block to do this.  You could even
do a simple POC with a python block, though it wouldn't be very fast for
T/R functionality.

On Mon, Nov 28, 2016 at 3:08 PM Bob Mattaliano <n6r...@gmail.com> wrote:

> Hi,
>
> Pretty new to GNUradio, GRC and Linux.  Does anyone have experience with
> or know if possible to create a flow graph or block to switch a USB
> relay (as in the kind used for home automation)?
>
>   What I am interested in is a block or flowgraph which examines output
> which also goes to the the monitor window.  If a specific string is not
> observed, a signal will be sent to switch the relay for a defined
> period.  The goal is some sort of automated antenna polarity switching
> depending on what is (or is not) received.
>
> Suggestions welcome.
>
> Thanks,
>
> Bob
> N6RFM
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Saving GNURadio flowgraph as vector graphics

[Dan CaJacob]

Try converting the png to a vector format first, but yes, a native vector
format would be nice.

On Wed, Nov 16, 2016 at 1:57 PM Suman Bhunia <su...@sbhunia.me> wrote:

> Hello,
>
> I want to include a flowgraph in my paper. When I save it as png, the
> picture becomes little blurry in the final pdf version. I was wondering
> if I could save the flowgraph in vector graphics format such as eps,
> svg, etc.
>
> Thanks,
> Suman
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Paid Project: Need a gnuradio BPSK/QPSK receiver for satellite modem data

[Dan CaJacob]

Hi Chris,

I've been using GNURadio for sat comm like this for a while, as have
others.  It's a great tool for the job!  To be frank though, this is more
than a $500 hit job.  Good luck in your search.

- Dan

On Fri, Oct 7, 2016 at 5:45 PM Chris Cook <ch...@chriswcook.com> wrote:

> I have a project that requires a gnu radio receiver that can receive,
> demodulate, and decode BPSK and QPSK data coming from a satellite modem.
> The modem also has FEC that will need to be handled.
>
> I can provide remote access to our lab machine that has a USRP connected
> to our modem for testing.
>
> I am willing to pay $500 USD for a solution.
>
> Please let me know if you’re interested and we can move the conversation
> offline.
>
> Thank You,
> Chris
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] E310 with larger micro SD card

[Dan CaJacob]

Same here.  Just burn to the larger disk, then expand the partition using
parted.

On Fri, Sep 30, 2016 at 8:59 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

>  > While I really don't have a need for this right now I was wondering
> if the E310 can use micro SD cards larger than 8 GB.
>
> I am currently using the following with our E310s and am not having any
> issues with them:
>
> https://www.amazon.com/Samsung-MicroSDXC-Memory-MB-MD128DA-AM/dp/B01CO48M36/
>
> I haven't tried to get larger than 128GB (I was concerned about the
> write speed, so didn't try to find a U3 in 256MB).
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] How to use correlate access code

[Dan CaJacob]

Hi Gabriel,

I think this block may be scheduled for deprecation...  You May want to
look at the Correlation Estimator block instead.

On Mon, Sep 26, 2016 at 11:19 AM Gabriel Pechiarovich <
gaps.18.2...@gmail.com> wrote:

> Hi all,
> I wanted to know how to use correlate access code block, if there is a
> example it will be usefull.
> I am tring to use it to syncronize bits in reception.
>
> Thank you all
> Gabriel Pechiarovich Salas
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] USRP B200 Not Transmitting

[Dan CaJacob]

What gain are you using?

On Thu, Sep 1, 2016 at 7:32 PM Hasini Abeywickrama <hva...@gmail.com> wrote:

> Hi Derek,
>
> Thank you for suggesting the USRP-users mailing list. I will try that too.
>
> I have tried a simple waveform too and that is not being received too. Yes
> the TX LED and the RX LED are lit when the flow graphs are running.
>
> I am trying to figure out what the problem might be. Is it necessary to
> supply power to the USRP B200 when transmitting?
>
> Regards,
> Hasini
>
> On Thu, Sep 1, 2016 at 4:49 PM, Derek Kozel <derek.ko...@ettus.com> wrote:
>
>> Hello Hasini,
>>
>> The USRP-users mailing list is an excellent place to ask such questions.
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> I do not have experience with the dpsk flowgraphs. Have you verified that
>> you can see a simple sinewave from one B200 to another? uhd_fft and
>> uhd_siggen_gui are excellent tools for testing that. When transmitting with
>> the B200, do you see the TX LED come on and the RX LED on the other one?
>>
>> Thanks,
>> Derek
>>
>> On Wed, Aug 31, 2016 at 10:31 PM, Hasini Abeywickrama <hva...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a USRP B200 set to transmit a signal (using uhd_tx_dpsk.grc in
>>> the GNURadio examples) and another USRP B200 receive the signal (using
>>> uhd_rx_dpsk.grc in the GNURadio examples). But the receiving USRP does not
>>> receive the signal that is being transmitted by the other USRP, even though
>>> they are placed very close to each other.
>>>
>>> If I user a USRP2 as the transmitter the receiver can receive the signal
>>> without any issue.
>>>
>>> Can someone please suggest what might be the problem with this. (Please
>>> excuse if this is not directly related to GNU Radio)
>>>
>>> Cheers
>>> Hasini
>>>
>>> ___
>>> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Porting from 3.6.something

[Dan CaJacob]

Note that the shell script is for converting 3.6 GRC flowgraphs to 3.7, not
CPP code.  I don't think such a unicorn exists, but maybe that's not what
you were asking for after all.

When I upgraded an old codebase, I broke down and started over from scratch
with gr-modtool, copying over the relevant code into the new skeleton
blocks.

On Tue, Jul 26, 2016 at 3:04 PM Chris Kuethe <chris.kue...@gmail.com> wrote:

> Also, http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7
>
> On Tue, Jul 26, 2016 at 12:01 PM, Chris Kuethe <chris.kue...@gmail.com>
> wrote:
> > https://github.com/n-west/n-west.github.com/blob/master/grc_to_37.sh
> >
> > On Tue, Jul 26, 2016 at 11:47 AM, John Malsbury
> > <jmalsbury.perso...@gmail.com> wrote:
> >> I am toying with the hypothetical idea of bringing a large and
> fragmented
> >> OOT codebase out of the stone age.  I remember hearing about a tool that
> >> would convert Cpp blocks from 3.6 to the 3.7 API.  Was that a real
> thing?
> >>
> >> Also, what will 3.8 break and will everyone think less of me if I spend
> 4-5
> >> years on 3.7?   :)
> >>
> >> -John
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> >
> >
> > --
> > GDB has a 'break' feature; why doesn't it have 'fix' too?
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dan CaJacob]

You'll likely have to buffer the output to a ramdisk and then slowly bleed
that to the disk.  Compression typically doesn't work well on IQ data
unless you've got a structured signal in there.  If there's a lot of white
noise, you won't get much compression

On Sat, Jul 16, 2016 at 12:00 AM Dave NotTelling <dmp250...@gmail.com>
wrote:

> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through
> a compression tool and then to disk?  I'd like to be able to take really
> wide band snaps for several minutes.  Currently that would take up 16 * 2 *
> SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
> MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
> through gzip by way of pigz was my first thought, but even on an 8 core
> Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
> but that's it.  And I know it's not a hard disk limitation as the M.2 drive
> I am using can easily sustain 800 MBytes/s of uncompressed data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Code Reuse Question

[Dan CaJacob]

You can use a head block inline (already in core).

On Wed, May 11, 2016 at 4:09 PM Richard Bell <richard.be...@gmail.com>
wrote:

> Hello,
>
> I want to add an additional parameter to the existing file sink block that
> lets the user tell it how many items to save to file. This amounts to
> adding a few lines to the existing file sink work function.
>
> What's the smartest way to do this? What I would do currently is create a
> new block, copy and paste the existing file sink code to my new block and
> add the few lines of code to change it. Is there a smarter way?
>
> Rich
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] How do I use formatter in QT GUI Label?

[Dan CaJacob]

I am not sure about this, but you may try the standard python formatters.
See https://docs.python.org/2/library/string.html

On Fri, May 6, 2016 at 5:13 PM Richard Bell <richard.be...@gmail.com> wrote:

> I am displaying a number using QT GUI Label in GRC like this
>
> 20.6u
>
> when I want it to display like this
>
> 20.6e-6 or 20.6x10-6, something along these lines.
>
> What do I put in the formatter section to make this happen?
>
> Rich
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] GRCON 16 hotels

[Dan CaJacob]

I heard the Air Force Academy glider team will be offering a an aerial
ferry service from Denver to Boulder...

On Thu, Apr 7, 2016 at 6:38 PM Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Hi Jason -
>
> Hotels will get posted on the website shortly. If you need something right
> away, this will be one of the recommended places:
>
> *Millennium Hotel* <http://www.millenniumhotels.com/millenniumboulder/>
>
> www.millenniumhotels.com
> 1345 28th St
> Boulder, CO 80302
> (303) 443-3850
>
>
> I'm not sure who started a rumor about GRCon running buses from Denver,
> but I'll go ahead and squash that one, now, hah. That said, I would be very
> surprised if there isn't already a selection of hotel bus services that do
> exactly this. We'll try to locate some information on these and get them on
> the website, as well.
>
>
> Cheers,
>
> Ben
>
> On Tue, Apr 5, 2016 at 8:58 AM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> Do we have an idea when preferred hotels will be announced?  Also I heard
>> rumor that there might be some shuttles lining up to take people from DEN
>> to the hotels, is that still a possibility (just trying to book things
>> soon)?
>>
>> ___
>> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Dan CaJacob]

Derek is spot on.  0 dB into any USRP is screaming loud.  Most of the units
are very sensitive, so it's perfectly fine to err on the side of too much
attenuation to start and dial the gain as you need.  It depends on the USRP
type, but signals much above -15dB can physically damage the hardware if
you set the gain too high.

On Wed, Mar 23, 2016 at 9:35 PM Derek Kozel <derek.ko...@ettus.com> wrote:

> Hello Tom,
>
> The input power to the USRP daughterboard should not be above -15dBm. I
> would recommend putting as much attenuation as you have available inline
> and raising the gain until just before a timesink shows the signal
> clipping, as Andy says having the maximum attenuation set will be raising
> your noise figure.
>
> Regards,
> Derek
>
>
> On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls <a...@silverblocksystems.net>
> wrote:
>
>>
>> >  From:
>> > Tom Golden
>> >   Subject:
>> > Re: [Discuss-gnuradio] Ettus N210
>> > GMSK 9600
>> >  Date:
>> > Wed, 23 Mar 2016 13:14:18 -0600
>> >
>> > __
>> > Here's my flow-graph along with a snapshot of the constellation and
>> > FFT.
>> >
>> >
>> > Thanks!!
>> > -Tom
>>
>> Hi Tom,
>>
>> A couple of things:
>>
>> a) The polyphase resampler isn't going to work well without a filter
>> definition in the taps field.
>>
>> b) The constellation sink will not display anything meaningful without
>> sample timing synchronization; it is not useful at its current position
>> in the flowgraph.  The constellation sink also doesn't display anything
>> useful for an FSK modulation normally; (G)MSK being an exception, if
>> treating it like a PSK modulation vs. FSK.
>>
>> c) You don't have any coarse or fine frequency synchronization.  That
>> will cause you major problems, if trying to treat GMSK as a PSK
>> modulation.  It will cause you minor problems, if treating GMSK as an
>> FSK modulation.
>>
>> d) Timing recovery blocks usually want a signal that has peaks (which
>> you get by putting the signal through a matched filter), and those peaks
>> should nominally be scaled to +/- 1.0.  You don't have a matched filter
>> or an AGC before the Clock Recovery block.
>>
>> e) The USRP's 0 dB gain setting is actually the USRP inserting the
>> maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
>> your signal to noise ratio.  You may want to consider adding "gain" as
>> long as the time domain signal doesn't look clipped (sometimes hard to
>> tell with FSK).
>>
>> f) You may wish to look at what Nick Foster's gr-ais does to demodulate
>> a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
>> point; just ignore the stuff about correlating to a preamble.
>> https://github.com/bistromath/gr-ais
>>
>> If you share your datafile somewhere, I might be inspired to whip a
>> flowgraph that works on it. :)  But that could rob you of the learning
>> process.
>>
>> Regards,
>> Andy
>>
>> >
>> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech <address@hidden>
>> > wrote:
>> > On 03/23/2016 02:48 PM, Tom Golden wrote:
>> > Hi,
>> >
>> > I'm a novice gnu radio user.  I'm using gnuradio with
>> > an Ettus N210 cabled to a modem transmitting GMSK
>> > 9600bps.  This is just for a test to verify the modem
>> > transmit bits.
>> >
>> > I'm having issues with resampling.  The N210 clock
>> > can't be set to a multiple of 9600, so I'm attempting
>> > to resample. I've tried various mechanisms but the
>> > output after resampling to 96000 is too noisy to
>> > successfully decode bits.  I've tried the GMSK demod
>> > block as well as the combination of Quadrature
>> > Demod->Clock Recovery MM->Binary Slicer - and neither
>> > works.
>> >
>> > I've also played with the Polyphase clock sync but I
>> > don't see any noticeable difference. Can anyone
>> > recommend a solution?
>> >
>> > Thanks!!
>> > -Tom
>> >
>> > For a first step, it would be useful for you to share your
>> > flow-graph with the list.
>>
>>
>>
>> ___
>> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Picking up RF cellular signals

[Dan CaJacob]

I don't know much about cell phones, but would it help if you placed a call
to a known number?  Does that force a response?  Of course, this might be
counter-productive in a congested disaster environment.

- Dan

On Mon, Mar 14, 2016 at 10:56 AM Meny Sidar <sidar.m...@gmail.com> wrote:

> Hi guys,
>
> I am currently working on a project for my university, where i'm trying to
> locate cellular phones using SDR (USRP B210).
> The idea of the project is to be able to find survivors/victims in
> disaster areas, such as earthquakes, by assuming they have their cellular
> on them.
>
> What i did so far, is a program that calculates and outputs in a loop the
> power transmitted from a cellular phone from it's uplink channel. that can
> tell me my distance to it.
> problem is, that cellular phones are usually in idle mode and not
> transmitting at all.
> So it works, but only if the phone is currently transmitting to the
> network (phone call, internet, etc..)
>
> I'm trying to find a solution for this,
> There has to be a way of knowing that some kind of RF transmitter/receiver
> is near me...
> If anyone can shed some light on this subject, what can i do or if i need
> to go in another way, i'll be very grateful!
> right now i'm stuck.
>
> Thanks a lot,
> Meny
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Pybombs 2.0 woes

[Dan CaJacob]

I had the same pip error.  It seemed to be related to a conflicting version
of requests.  I am running Ubuntu 15.10  to fix the problem, I uninstalled
my pip-installed pybombs and apt-installed python-pip.  I then installed
pip and requests via easy_install (generally don't go this route, but it
worked).  Then I was able to install pybombs via pip again and this time
build was completely successful.

On Sat, Mar 5, 2016 at 1:54 PM West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> On Sat, Mar 5, 2016 at 10:45 AM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Hi Mike,
>>
>
>> Following advice here I descended down a rabbit hole and tried to start
>> again “pip uninstall pybombs”. Pip was not found.
>>
>> Uninstalling pybombs via pip only makes sense if you've installed it via
>> pip ("pip install pybombs"). Seemingly, you've either gotten PyBombs
>> through different means, so investigating pip doesn't really make sense, or
>> something uninstalled pip after you've installed it, and installed Pybombs
>> with it. That would be strange.
>>
>
> I don't think that's true. It's unintuitive, but pip is the generally
> accepted way to uninstall anything installed through setup.py. See
> http://stackoverflow.com/questions/1550226/python-setup-py-uninstall
>
>
>> That has fixed the pip problem but not the UHD installation crash, but as
>> a by product the error messages have become more verbose – and guess what?
>> The problem is an undeclared type. *THIS SAME ISSUE WITH UNDEFINED TYPES*
>> (shout so it sinks in, then repeat because it didn’t) *THIS SAME ISSUE
>> WITH UNDEFINED TYPES*  that has been around for over a YEAR in UHD and
>> in this case rx_dsp_core_200.cpp.
>>
>> There is no such issue I know of. Now, that doesn't mean there's no
>> issue, it just means that none of the other users I've talked to nor myself
>> encountered it. However, probabilistically speaking, that's indicative of
>> something being wrong with your system...
>>
>> Every so often I point it out and someone fixes it and later on someone
>> else (I wonder if this is the same person who broke it last time) then adds
>> some new code somewhere else recreating the same errors. In this case its
>> uintptr_t that is not declared.
>>
>> Um, sorry, I don't even see uintptr_t in rx_dsp_core_200.cpp, and I've
>> searched through its file history: It never occurred there. So to research
>> this issue, I'll need your full "make" output. Maybe your version of Ubuntu
>> fell off the testing bandwagon: which version of Ubuntu are you using?
>>
>> A good motto is to assume nothing and please make sure you declare
>> everything.
>>
>> uintptr_t is a standard type. See "man stdint.h".
>>
>>
> Looks potentially familiar... Two things might be going on. 1) If you have
> a UHD installed and the current build picks up on it things might get messy
> in non-intuitive ways. Make sure you remove any stray UHD installations.
> That seems likely in this case. 2) There's a similar issue with some
> versions of glibc and boost. See
> https://github.com/gnuradio/gr-recipes/pull/4#issuecomment-181188909
> (seems unlikely in this case). BTW, if you see a problem in the code that
> keeps coming back you don't have to wonder who does it... you can use git
> to know. Anyway, indeed without errors/build logs I'm not sure what you
> expect anyone to do here.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Saving Waterfall to Video File

[Dan CaJacob]

In the past, I have saved decimated vectors of the signal to a file and
used that to recreate a long, static waterfall plot for debug of satellite
passes.

On Sun, Feb 28, 2016 at 2:19 PM Stephen Berger <
stephen.berger.temconsult...@gmail.com> wrote:

> I would like to save a waterfall plot (spectrograph) to a video file so
> that I can share it and cut out portions of interest for presentation.  Has
> anyone found a way to directly save the output to an MP4 or some other
> video format?
>
>
>
> I have been using a screen recorder but that takes a good time of time and
> the process ends up requiring 2 to 4 different programs by the time you
> record, edit and have your file ready for presentation.  It would be a time
> savings to save it directly.
>
>
>
> Best Regards,
>
>
>
> Stephen Berger
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Dan CaJacob]

I like keeping the algorithm logic in comments.  I can't count how many
times I have optimized something, overwriting the original readable code,
then come back in a few months to discover I have no idea how it works
anymore.

On Wed, Sep 23, 2015 at 1:54 PM Martin Braun <martin.br...@ettus.com> wrote:

> On 23.09.2015 10:39, Richard Bell wrote:
> > Hey everyone,
> >
> > I'm in the process of submitting my first OOT module for merge with GNU
> > Radio base. It's a log gain AGC which converges much faster then the
> > current AGCs when the input signal energy is low. I've read through the
> > following link:
> >
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
> >
> > 1) My first question relates to documentation. Up to now, I've added
> > documentation into my XML files as  tags. To use Doxygen, am
> > I correct to put them in the public *.h file? Is this the only place it
> > should go, or should I add it to the XML as well? I've never been able
> > to get my documentation to propagate through to the GRC block without
> > putting it into the XML, is this a sign of a problem?
>
> You should only need to put your docs in the Doxygen block.
>
> > 2) If I understand the above link correctly, I should fork GNU Radio,
> > create a new branch which I might call Log_AGC, add my code to that
> > branch and then make a pull request. Am I misunderstanding anything?
>
> That's the way to go. See also
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Development
>
> > 3) As far as code style goes, should I avoid using
> >
> > #define DEBUG
> > #ifdef DEBUG
> > std::cout << "Debug stuff" << "\n";
> > #endif
>
> Absolutely. Please use the logging interface. See also
> http://gnuradio.org/doc/doxygen/page_logger.html
> >
> > statements to hide debug code? That is what I currently do but I know
> > it's not prevalent in the source.
> >
> > 4) I currently have an Optimize option in the GRC block which picks
> > between the way you would write the block if you just used standard C++
> > statements (not optimized) and if you use Volk (optimized). Using
> > control ports to compare the two, there is an improvement with volk. But
> > I like that someone looking into the block can see how not to do it and
> > then how to do it. Good for beginners jumping into GNU Radio.
>
> That's noble, but for core GNU Radio stuff it's probably best if you
> stick with the VOLK implementation.
>
> M
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis

[Dan CaJacob]

Hi Sean,

Any chance you can share your work?

On Tue, Sep 15, 2015 at 2:33 PM Nowlan, Sean <sean.now...@gtri.gatech.edu>
wrote:

> Thanks, that did the trick. I got about 4e-5 BER and 1.1 % PER at 6dB
> Es/N0 with my particular CPFSK parameters.
>
>
>
> *From:* Achilleas Anastasopoulos [mailto:anas...@umich.edu]
> *Sent:* Saturday, September 12, 2015 1:21 PM
> *To:* Nowlan, Sean <sean.now...@gtri.gatech.edu>
> *Cc:* Discuss-gnuradio@gnu.org
>
>
> *Subject:* Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi
> algorithm using gr-trellis
>
>
>
> Sean,
>
> I guess there was a missing normalization of the pulse.
>
> Please add the line
>
> p=p/sum(p)*Q/2.0;
>
> just after the definition of the p pulse
>
> p = numpy.ones(L*Q)
>
>
> In addition, make sure you increase the Q (samples per symbol)
> considerably, ie make it 16 or more. The reason is that h=25/3 results in a
> BIG bandwidth for this constellation so it has to be appropriately samples
> in order to be represented accurately.
>
>
>
> let me know how it goes
>
> Achilleas
>
>
>
>
>
>
>
> On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean <sean.now...@gtri.gatech.edu>
> wrote:
>
> Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the
> format now, and I managed to build the gr-trellis documentation, which does
> spell out answers for a lot of what I asked.
>
>
>
> I’ve abandoned making my own FSM since I can just use the CPM utilities in
> gr-trellis. However, I’m getting unexpected BER and PER when running
> gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3
> and L=1.
>
>
>
> Diff of test_cpm.py with my simple modifications:
>
> https://gist.github.com/nowls/5b2bc2aada87dc197e3f
>
>
>
> $ python test_cpm.py
>
> Using Volk machine: avx_64_mmx_orc
>
> 100 16868 100 0.16868 1.0
>
> 200 33852 200 0.16926 1.0
>
> 300 50786 300 0.16928667 1.0
>
> 400 67667 400 0.1691675 1.0
>
> […]
>
>
>
> As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The
> construction of the phase response, q, looks correct to me. Any idea what
> might be going wrong?
>
>
>
> Thanks,
>
> Sean
>
>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On
> Behalf Of *Achilleas Anastasopoulos
> *Sent:* Thursday, September 10, 2015 1:28 PM
> *To:* Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi
> algorithm using gr-trellis
>
>
>
> Sean,
>
> I just wanted to add to the previous answer:
>
> Indeed gr-trellis (and the fsm class specifically) has a built in
> constructor for generating the FSM corresponding to ANY CPM scheme.
>
> It only requires three parameters as explained in the comments
>
> in the file fsm.cc
>
> The constructed FSM is NOT based on Proakis decomposition, but on the more
> elegant decomposition by:
> "A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
>   See also my own notes at
> http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
>
> for all the details.
>
> In this case for h=K/P, it does not matter whether K is even or odd, the
> number of states is always = M^{L-1} * P (where M is the cardinality of the
> input alphabet),
>
> so in your case you'll have a trellis with 3 states as the previous email
> suggested.
>
> You may also find useful the python utility
>
> make_cpm_signals(K,P,M,L,q,frac)
>
> that can be found in gr-trellis/python
>
> that generates the signal space for you.
>
> (please see the above references for more info).
>
> Finally, you can take a look at the example "test_cpm.py"
>
> in the gr-trellis/examples/python
>
> and make appropriate changes for your CPFSK signal.
>
>
> 
>
> Now you can always drop all the above and design your FSM and signals from
> scratch. You can create the FSM from a file (this is explained in the
> gr-trellis documentaion--which is generated from
> gr-trellis/doc/gr-trellis.xml).
>
> The ouput symbol mapping is defined EXACTLY as you suggested in your email:
>
> every line corresponds to the current state and every column to an input.
>
> The entry is a number from 0 to I-1 (where I is the input cardinality).
>
> How this index is translated to an actual signal IS NOT PART OF  THE FSM
> DEFINITION but part of the modulation definition as explained very
> extensively in the gr-trellis documentation.
>
>
>
> let me know if you have any further questions,
>
> Achilleas
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Struggling with gr-perf-monitorx

[Dan CaJacob]

It looks like this also applies to blocks that have been "bypassed."  Makes
sense.

On Fri, Sep 4, 2015 at 11:48 PM Dan CaJacob <dan.caja...@gmail.com> wrote:

> Hey Tom,
>
> I ran into this "math domain error" with CtrlPort recently.  Based on your
> suggestion that it might be related to zero work blocks causing a divide by
> zero, I started hacking away anything that might be being short-circuited
> in the relatively complex flowgraph.  First, an shorted branch of a select
> tree - no dice.  Then a copy block.  BAM!  That was it.  I guess copy must
> be super efficient and not really do any work.
>
> Anyhow, I figure that using a copy block in a fg should reliably reproduce
> this problem an perhaps serve as a model for working around it.
>
> In my fg, the copy block was serving as a valve that would prevent
> downstream blocks from executing if it was shut.  In my case, the "valve"
> was open, and data was flowing through the copy block.
>
> Thanks!
>
> On Tue, Jun 16, 2015 at 11:44 PM Tom Rondeau <t...@trondeau.com> wrote:
>
>> On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting <gnura...@pki2.com>
>> wrote:
>>
>>>
>>> I have this "nearly" working. MX brings up a window, connects to GRC,
>>> briefly displays a graph, then blanks out. Displayed in the command line
>>> window:
>>>
>>> gr-perf-monitorx: radio.getKnobs threw exception (math domain error).
>>> ...
>>> (repeats)
>>>
>>> I'm not sure what that message is telling me in the operation/debug
>>> domain. Clue please.
>>>
>>> The paper "Inspecting GNU Radio Applications with ControlPort and
>>> Performance Counters" shows various blocks in Figures 2 and 5 named
>>> "Ctrlport...". Are those necessary for MX? I haven't found anything that
>>> indicates yes or no. Clue please.
>>>
>>> Operationally:
>>>
>>> root@Tori-Radio:~/thrift# gnuradio-companion  --version
>>> GNU Radio Companion v3.7.7.1-131-g71ab508d
>>>
>>>
>>> root@Tori-Radio:~/thrift# lsb_release  -a
>>> No LSB modules are available.
>>> Distributor ID: Ubuntu
>>> Description:Ubuntu 15.04
>>> Release:15.04
>>> Codename:   vivid
>>>
>>
>>
>> I'm not sure what MX is? Are you using that as shorthand for
>> gr-perf-monitorx?
>>
>> If that's the case, then no, the Ctrlport Probes are there for other
>> purposes and not necessary for Performance Monitor.
>>
>> I'm seen that Math Domain error before, but I've never been able to
>> replicate it reliably. I think it's something related to a divide by zero
>> and I think happens when one block's performance measure of work time comes
>> back with 0 -- which doesn't often happen. Are you using any of your own
>> blocks in the flowgraph? What if you run the Controlport Monitor tool
>> instead of Performance Monitor? That will just show you a list of all
>> available parameters exposed by the application over ControlPort.
>>
>> Tom
>>
>> ___
>> 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] Struggling with gr-perf-monitorx

[Dan CaJacob]

Hey Tom,

I ran into this "math domain error" with CtrlPort recently.  Based on your
suggestion that it might be related to zero work blocks causing a divide by
zero, I started hacking away anything that might be being short-circuited
in the relatively complex flowgraph.  First, an shorted branch of a select
tree - no dice.  Then a copy block.  BAM!  That was it.  I guess copy must
be super efficient and not really do any work.

Anyhow, I figure that using a copy block in a fg should reliably reproduce
this problem an perhaps serve as a model for working around it.

In my fg, the copy block was serving as a valve that would prevent
downstream blocks from executing if it was shut.  In my case, the "valve"
was open, and data was flowing through the copy block.

Thanks!

On Tue, Jun 16, 2015 at 11:44 PM Tom Rondeau  wrote:

> On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting 
> wrote:
>
>>
>> I have this "nearly" working. MX brings up a window, connects to GRC,
>> briefly displays a graph, then blanks out. Displayed in the command line
>> window:
>>
>> gr-perf-monitorx: radio.getKnobs threw exception (math domain error).
>> ...
>> (repeats)
>>
>> I'm not sure what that message is telling me in the operation/debug
>> domain. Clue please.
>>
>> The paper "Inspecting GNU Radio Applications with ControlPort and
>> Performance Counters" shows various blocks in Figures 2 and 5 named
>> "Ctrlport...". Are those necessary for MX? I haven't found anything that
>> indicates yes or no. Clue please.
>>
>> Operationally:
>>
>> root@Tori-Radio:~/thrift# gnuradio-companion  --version
>> GNU Radio Companion v3.7.7.1-131-g71ab508d
>>
>>
>> root@Tori-Radio:~/thrift# lsb_release  -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 15.04
>> Release:15.04
>> Codename:   vivid
>>
>
>
> I'm not sure what MX is? Are you using that as shorthand for
> gr-perf-monitorx?
>
> If that's the case, then no, the Ctrlport Probes are there for other
> purposes and not necessary for Performance Monitor.
>
> I'm seen that Math Domain error before, but I've never been able to
> replicate it reliably. I think it's something related to a divide by zero
> and I think happens when one block's performance measure of work time comes
> back with 0 -- which doesn't often happen. Are you using any of your own
> blocks in the flowgraph? What if you run the Controlport Monitor tool
> instead of Performance Monitor? That will just show you a list of all
> available parameters exposed by the application over ControlPort.
>
> Tom
>
> ___
> 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] eye diagram error

[Dan CaJacob]

I'll add one thing to Marcus' recommendation: turn on persistence in the
scope widget.  Then you've got a great eye-diagram!

Very Respectfully,

Dan CaJacob

On Thu, Feb 19, 2015 at 4:33 AM, Marcus Müller marcus.muel...@ettus.com
wrote:

  Hi Mostafa,

 yep, these are not GNU Radio core visualizations, but come with gr-baz.
 You might be using a GNU Radio 3.6-compatible version of gr-baz instead of
 one that works with GR 3.7. Make sure to install the master branch of
 github.com/balint256/gr-baz , after removing all remnants of the gr-baz
 version that you have.

 My hint regarding the eye diagram was just to build an eye diagram like
 it's in the books [1]: An oscilloscope that is triggered on the symbol rate.

 Best regards,
 Marcus

 [1]http://en.wikipedia.org/wiki/Eye_pattern

 On 02/19/2015 07:35 AM, Mostafa Alizadeh wrote:

 Hi Marcus,

  I'm using GNURadio 3.7.5.1. Under [Graphical Sinks], I have Baudline
 Sink , Fast AutoCorrelation Sink and also Eye diagram. It doesn't work!

  I didn't get your hint of creating an eye diagram :(

  Best,
 Mostafa

 On Tue, Feb 17, 2015 at 9:39 PM, Marcus Müller marcus.muel...@ettus.com
 wrote:

  Hi Mostafa,

 which GNU Radio version are you using?
 GNU Radio itself (to my knowledge) doesn't come with a dedicated eye
 diagram, and it's possible that you're trying to use an out-of-tree module
 that was meant for another version of GNU Radio.
 You can try to emulate an eye diagram by using the Scope Sink, and
 triggering on a signal that has an edge on every symbol center.

 Best regards,
 Marcus


 On 02/17/2015 06:30 PM, Mostafa Alizadeh wrote:

  Hello,

  When I used eye diagram block (which seems to be a member of WxGUI
 class), the following error appeared:

File /usr/local/lib/python2.7/dist-packages/baz/eye.py, line 98, in
 __init__
 self.st = gr.message_sink(gr.sizeof_float, msgq, dont_block=1)
 AttributeError: 'module' object has no attribute 'message_sink'


  what is the main problem?

  best,
 Mostafa



  ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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




  --
  ***
 Department of Electrical Engineering
 Aboureyhan Building
 MMWCL LAB
 Amirkabir University Of Technology
 Tehran
 IRAN
 Tel: +98 (919) 158-7730
 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
 Homepage: http://ele.aut.ac.ir/~alizadeh/
 ***



 ___
 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] Automatically Restart UHD/gr-uhd blocks

[Dan CaJacob]

I worked around a problem like this by installing an in-line power relay in
my remote nodes.  Not ideal, but in some rare situations, even forcing the
FPGA to reload was not successful.  Sometimes a power cycle was the only
hope.

That said, I've heard some lovely things about reset commands available for
the newer boards, but it's not clear to me if they are integrated into the
driver.  Seems likely, though.

Very Respectfully,

Dan CaJacob

On Wed, Feb 18, 2015 at 4:29 PM, John Malsbury jmalsbury.perso...@gmail.com
 wrote:

 I've recently received a request to have GNU Radio flowgraphs recover
 gracefully in the event of power glitches, or transient Ethernet anomalies
 that are severe enough to break the dataflow.  ie. the event should be
 noted, but there should be a way to re-init the USRP for continued
 operation with restart the .py.

 I haven't really been keeping up.

- Has there been any discussion on how we might modify gr-uhd, and
maybe UHD, to allow automatic re-initialization of the USRP?
- If not, is this a reasonable place to brainstorm on the problem?
- Has anyone already solved this?

 It doesn't seem that complex, but I'd like to pick the most
 straight-forward path.
 -John

 ___
 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] Getting time each time power squelch is on

[Dan CaJacob]

Hi Luis,

I am pretty certain there is a block in mainline GR to do this with
tagging.  Burst tagger maybe?  The tags define the burst boundaries and a
timestamp is recorded as well.
 On Jan 2, 2015 5:46 PM, Luis Colunga lccolung...@gmail.com wrote:

 Hello,

 I have a Python handcoded block in which I want every time that power
 squelch is triggered, grab the actual time and then use that filename
 to write a wav file with a decoded stream.

 What would be a good approach? I tried using variables but I see they
 don't update at runtime and I am not sure if you are able to change
 the wav sink name on runtime and just expect it to work or if it
 neccesary to do something else there.

 Thanks.

 ___
 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] Best Resample Method For Resampling LTE Data

[Dan CaJacob]

The PFB Arb Resampler is the newest.  I've been using it to do all my
resampling for every application because it's dead simple - handles all the
nyquist filtering for you and allows fractional resampling.

On Sunday, November 30, 2014, Paul Creaser drpaulcrea...@gmail.com wrote:

 Hi,

 I'm currently using the Rational Resampler in GUNURADIO to resample LTE
 data, for example from 30.72MHz to 15.36MHz and 50MHz to 15.36MHz. I`m able
 to decode the data, so every thing seems to be well.

 I chose the Rational Resampler, simply because it is easy to use. However I
 noticed, GNURADIO has a number of resample modules, Fractional Resampler,
 Polyphase Arbitrary Resampler etc... I'm guessing each resampler has it`s
 strengths and weaknesses. Perhaps one is better for audio, another is
 better
 for LTE data etc..

 At this stage, I have found the equations for the various resamplers, but
 have no practical experience, with regards to the merits or demerits of the
 different modules.

 Any pointers to any online resources or offline books would be appreciated.



 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Best-Resample-Method-For-Resampling-LTE-Data-tp51496.html
 Sent from the GnuRadio mailing list archive at Nabble.com.

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



-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Saving to file with a timestamp

[Dan CaJacob]

You can also use some Python string concatenation to add a Timestamp to
your file name in GRC.  GRC is actually quite liberal in what it will 
allow you to add in this way.

On Saturday, November 22, 2014, Tom Rondeau t...@trondeau.com wrote:

 On Sat, Nov 22, 2014 at 6:15 AM, Marcus Müller mar...@hostalia.de
 javascript:_e(%7B%7D,'cvml','mar...@hostalia.de'); wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 There's been a thread on exactly that a few days ago [1].

 Short version: maybe there's something not too complex you can do in
 GRC, but if you want to do something that looks like a program, you
 might just want to program something ;)

 Greetings,
 Marcus

 [1]
 http://lists.gnu.org/archive/html/discuss-gnuradio/2014-11/msg00154.html
 [2]
 http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials


 There is the tagged_file_sink:


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

 This is an early implementation of using stream tags for controlling
 things like this, so you might want to use this as a guide.

 Tom




 On 11/22/2014 12:04 PM, Mike Willis wrote:
  I have a flowgraph working that I want to use to save data to a
  file. I would like the file name to update each time, ideally with
  a time stamp as part of the name. Is this possible directly from
  GRC of will I need to write a block?
 
 
 
  Mike



 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJUcHBkAAoJEAFxB7BbsDrLB44H/Rb0pvvBHOcbJHndGFaiedaI
 xrfzOAnzrmaqLOK5Qfr1UYLPDvZp+EOIEr5s2/jAQj5jkHkDQz/5/GPenHYqVRN1
 nvrs+QJ70kSGgqDWjg4GAEo/rz1n3pmyqfPmErMi9J5rmcoPep6NA2xCek7SyHzm
 AehN7fwX7L1y2zQMRIit3Q1pFrfzEeojS6KZsGqrJBL1/nMHqAoqU6lawruxtkL1
 NViNr49Dtur6EXwf6ejv/ptMuojUNouMSyqg6s4KXQEu+b3tGPpW7jPRbWiuIzp0
 +GHF6gvt6Ss1KBXkSRWDSqlYpkbl3J/b6/nNqDFmY8iiZjIyCKMt9JYUaN0y72E=
 =AM87
 -END PGP SIGNATURE-

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 javascript:_e(%7B%7D,'cvml','Discuss-gnuradio@gnu.org');
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] BFSK

[Dan CaJacob]

Hi Richard,

I suffered through understanding the quadrature mod/demod block settings a
while back.  I provide some links to that information below.  I provide a
formula for the settings for both digital and audio applications.  As you
can see (from the reading), the settings can be derived from
samples-per-symbol and modulation index or deviation and baud rate.  Or
just peak deviation and sample rate for audio.

The quadrature demod gain is really just a gain, btw.  If you set it right,
your demodulated audio will have unity gain, which is nice/necessary for
most of the clock synchronizers.

Thread:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-07/msg00058.html
Wiki Summary:
http://gnuradio.org/redmine/projects/gnuradio/wiki/SignalProcessing

Very Respectfully,

Dan CaJacob

On Mon, Nov 17, 2014 at 2:09 PM, Richard Bell richard.be...@gmail.com
wrote:

 Would someone please recommend a book that steps through the
 implementation used in GNU Radio for the Frequency Mod and Quadrature Mod
 blocks? I've looked at the source code and I have seen posts trying to
 explain what sensitivity and gain are, but my lack of background knowledge
 is making those sources not very helpful.

 Really appreciated,
 Rich



 ___
 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] URSP noise

[Dan CaJacob]

Thanks, Marcus.  You're absolutely right.  I didn't read carefully enough.

Very Respectfully,

Dan CaJacob

On Tue, Nov 11, 2014 at 11:33 AM, mle...@ripnet.com wrote:

  Dan:

 That's generally good advice, with the single exception of the BASIC/LF
 card family--they don't have any gain--they're just ADC/DAC buffers, so
 it's generally safe to loop them directly.




 On 2014-11-11 11:27, Dan CaJacob wrote:

 Hi Lucas,

 You say you connected TXA to RXA directly via a cox cable?  Did you put an
 attenuator inline?  I am afraid you may have damaged your RX side by
 transmitting directly into it without protection.  Most USRPs can be
 damaged with input power greater than -10 dBm.  Disconnect that cable
 immediately and try testing the RX side alone to make sure that it is not
 damaged.  Then, if you want to go back to a looback test, make sure that
 you put about 60 dB of attenuation between the RX and TX ports.

 The noise you were seeing was almost certainly not a problem with your
 source block, but your RX being over-driven (dying).

 Good luck.

  Very Respectfully,

 Dan CaJacob

 On Tue, Nov 11, 2014 at 11:07 AM, Lucas Lopez luckas1...@gmail.com
 wrote:

  hi everyone. i was working with the USRP1. I'm testing a MOD/DEMOD
 DBPSK. I have only one USRP, so, i connected TX_A( from  daughterboard
 LFTX-LF)  to RX_A ( from daughterborad LFRX-LF) with  a coaxil.  All system
 works well without URSP but when i taste with the USRP i get so much noise
 and the SNR give me -infinite. I checked the problem comes from uhd ursp
 sourse block, that make me think the problem is the noise from URSP. some
 suggestions?
 Regards.
 Lucas.

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


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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] URSP noise

[Dan CaJacob]

Hi Lucas,

You say you connected TXA to RXA directly via a cox cable?  Did you put an
attenuator inline?  I am afraid you may have damaged your RX side by
transmitting directly into it without protection.  Most USRPs can be
damaged with input power greater than -10 dBm.  Disconnect that cable
immediately and try testing the RX side alone to make sure that it is not
damaged.  Then, if you want to go back to a looback test, make sure that
you put about 60 dB of attenuation between the RX and TX ports.

The noise you were seeing was almost certainly not a problem with your
source block, but your RX being over-driven (dying).

Good luck.

Very Respectfully,

Dan CaJacob

On Tue, Nov 11, 2014 at 11:07 AM, Lucas Lopez luckas1...@gmail.com wrote:

 hi everyone. i was working with the USRP1. I'm testing a MOD/DEMOD DBPSK.
 I have only one USRP, so, i connected TX_A( from  daughterboard LFTX-LF)
  to RX_A ( from daughterborad LFRX-LF) with  a coaxil.  All system works
 well without URSP but when i taste with the USRP i get so much noise and
 the SNR give me -infinite. I checked the problem comes from uhd ursp
 sourse block, that make me think the problem is the noise from URSP. some
 suggestions?
 Regards.
 Lucas.

 ___
 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] How to save bit stream?

[Dan CaJacob]

I often use the unpacked_to_packed block inline as well to save space and
transfer time if I am saving a bunch of decoded data.  This may not be an
issue if you aren't doing things remotely.

Very Respectfully,

Dan CaJacob

On Wed, Oct 22, 2014 at 9:07 AM, Tom Rondeau t...@trondeau.com wrote:

 On Wed, Oct 22, 2014 at 8:51 AM, Su Li liis...@gmail.com wrote:

 Hi,

 After demodulation, I get a stream of 0 and 1 in UChar format, I want
 to save this stream to a file and have a look at these raw bits before
 decoding them. I tried to use File Sink block to save them, but I cannot
 open the saved file with gedit. It can be opened with  GVim, but the
 content are not 0 and 1. They are ^@ and ^A.

 Is there anyway to save the bit stream so that when I can open the saved
 file I can get the stream shown as 0 and 1?

 The flow graph is shown as following


 ​Thanks in advance.

 Best regards,
 Su


 Files are saved as binary bit streams. What you're seeing is the ASCII
 representation of random 1's and 0's for each bit in the data stream. Have
 a look here:


 http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink-How-can-I-read-files-produced-by-a-file-sink

 Tom


 ___
 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] Works with GR 3.6, breaks with 3.7

[Dan CaJacob]

John,

I use the BE FLL for auto-doppler correction in the rare case where I am
not actively correcting for doppler.  But, the correction is *really*
slow.  I'm probably not using it correctly, but it works OK in that rare
case when it's all I've got.

Very Respectfully,

Dan CaJacob

On Fri, Oct 17, 2014 at 2:28 AM, John Malsbury jmalsbury.perso...@gmail.com
 wrote:

 Luke,

 I researched this for a bit  (OK, maybe it was more like staring
 blankly)... unfortunately on a windows machine w/out git.  Nothing stands
 out at the momentt.  I'll give it another try tomorrow! =)

 Also, I've never used the PLL blocks for freq demod before. Can you set
 something up with a graphical sink and send some snapshots showing what the
 output of that looks like?

 Also also, is the Band-Edge FLL ideal for GMSK?  My possibly, incorrect
 understanding of that block is that it was more ideal for PAM with common
 RRC.

 -John

 On Thu, Oct 16, 2014 at 7:19 AM, Luke Berndt l...@robotastic.com wrote:

 I just tried doing a complete PyBombs reinstall and that didn't seem the
 help. I checked and simple GRC files run fine. I can also see the signal
 where I expect it to be in GQRX, so I think my tuning parameters are
 correct.

 Are there some other things I should try?

 Sent from my iPhone

 On Oct 13, 2014, at 1:38 PM, Luke Berndt l...@robotastic.com wrote:

 I have a GnuRadio C++ program that decodes and records a SmartNet Trunked
 radio system. It is running great under GnuRadio 3.6.5.1, but it doesn’t
 seem to be working under 3.7.6.

 3.6 is installed in /usr/local and 3.7.6 was installed in my home
 directory using PyBombs. My updated program compiles against 3.7 with no
 problem and runs. It will pick up a few of the trunking commands, so it is
 working, but the ratios is about 1 to 100 compared to 3.6. I also tried
 running it in a Ubuntu VM with 3.7 installed at /usr/local and had the same
 results.

 I corrected for the change with XlatingFirFilter in 3.7, so it is the
 opposite offset of 3.6. It looks like it could be a tuning error though,
 the flow graph seems to be failing mostly at the CRC check. Did anything
 else change with Blocks in 3.7? I looked at gr-osmosdr but I didn’t notice
 huge discrepancies between the 3.6 and 3.7 branches.

 Are there some obvious things I could be missing? I feel like this is
 something small and stupid that I missing.

 The diff between the two versions is here, smartness.cc is the main file
 that decodes the control channel. As you can see, there is not that much
 different:


 https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40

 Here is the central code block that does it. Anything obviously dumb here?

 * float samples_per_second = samp_rate;*
 * float syms_per_sec = 3600;*
 * float gain_mu = 0.01;*
 * float mu=0.5;*
 * float omega_relative_limit = 0.3;*
 * float offset = chan_freq - center_freq;  // have to reverse it for 3.7
 because it swapped in the switch.*
 * float clockrec_oversample = 3;*
 * int decim = int(samples_per_second / (syms_per_sec *
 clockrec_oversample));*
 * float sps = samples_per_second/decim/syms_per_sec;*
 * const double pi = boost::math::constants::pidouble();*

 * cout  Control channel offset:   offset  endl;*
 * cout  Decim:   decim  endl;*
 * cout  Samples per symbol:   sps  endl;*

 *  std::vectorfloat lpf_taps;*

 *  init_loggers(max_loggers, center_freq, samp_rate);*

 *  gr::msg_queue::sptr queue = gr::msg_queue::make();*

 * lpf_taps =  gr::filter::firdes::low_pass(1, samp_rate, 1, 12000);*

 * gr::filter::freq_xlating_fir_filter_ccf::sptr prefilter =
 gr::filter::freq_xlating_fir_filter_ccf::make(decim,*
 *   lpf_taps,*
 *   offset,*
 *   samp_rate);*

 * gr::digital::fll_band_edge_cc::sptr carriertrack =
 gr::digital::fll_band_edge_cc::make(sps, 0.6, 64, 0.35);*

 *  gr::analog::pll_freqdet_cf::sptr pll_demod =
 gr::analog::pll_freqdet_cf::make(2.0 / clockrec_oversample,
 2*pi/clockrec_oversample, -2*pi/clockrec_oversample);*

 * gr::digital::clock_recovery_mm_ff::sptr softbits =
 gr::digital::clock_recovery_mm_ff::make(sps, 0.25 * gain_mu * gain_mu, mu,
 gain_mu, omega_relative_limit);*

 * gr::digital::binary_slicer_fb::sptr slicer =
  gr::digital::binary_slicer_fb::make();*

 * gr::digital::correlate_access_code_tag_bb::sptr start_correlator =
 gr::digital::correlate_access_code_tag_bb::make(10101100,0,smartnet_preamble);*

 * smartnet_deinterleave_sptr deinterleave = smartnet_make_deinterleave();*

 * smartnet_crc_sptr crc = smartnet_make_crc(queue);*

 * tb-connect(src,0,prefilter,0);*
 * tb-connect(prefilter,0,carriertrack,0);*
 * tb-connect(carriertrack, 0, pll_demod, 0);*
 * tb-connect(pll_demod, 0, softbits, 0);*
 * tb-connect(softbits, 0, slicer, 0);*
 * tb-connect(slicer, 0, start_correlator, 0);*
 * tb-connect(start_correlator, 0, deinterleave, 0);*
 * tb-connect(deinterleave, 0, crc, 0);*

 * tb-start

[Discuss-gnuradio] A BERT Block with Offset Compensation

[Dan CaJacob]

I am working on a GR block that will test two incoming bit streams (one a
reference and one a received result) for equality and return the estimated
BER.  Blocks already exist that do this, but they assume the streams are
aligned.  My block will allow and correct for offsets in the bit streams.
The goal is to use this with existing physical comm systems - i.e. Generate
and transmit a PRBS with GR and USRP to a legacy comm system, capture the
RX's data and clock, bring them back into the flowgraph and compare the
reference data to the received data to get estimated BER.

My block does work for streams that are aligned, but I am having difficulty
dealing with misalignment.  Somehow, the blocks needs to have more of the
reference signal (if not all of it) to compare against the smaller segments
of received data every time the work function is called.

I see several possible approaches and the purpose of this email is to
solicit advice from those with more experience than I.

1) Use set_history() and history() to good effect.
I've tried this, but haven't gotten the desired results.  This may be
misunderstanding of the feature on my part, but I think the fundamental
problem is comparing two streams of equal length when one is offset from
the other.

2) Accumulate a specified window of reference signal before comparing to
received signal.
This approach would accumulate the reference signal in a buffer that would
be used for comparison.  Until the work function calls accumulated some
threshold of reference data in the buffer, the received signal would be
passed without comparison or BER calculation.  Once the threshold is met,
the small chunks of received data would be compared against the much larger
(and growing, but limited to repeat length) reference buffer.

I have not implemented this approach yet, but I suspect it will work as
long as the window is picked reasonably - the safest bet being the length
of the PRBS used in the test.

The disadvantage of this method is that the PRBS may be very long, but the
sample rate may be slow and therefore there would be a long waiting period
as the reference buffer fills before the test even truly begins.

3) Variation on previous approach.
To alleviate the setup time of filling the reference buffer, perhaps we
could generate the whole PRBS in the block constructor.  The block would
then have a menu of standard PRBS's commonly used int BER testing.  We'd
probably want to make a companion PRBS source block with the same menu for
the transmitting segment.

If anyone has any thoughts on this, I'd appreciate the input.  This is one
of those problems that's pretty simple in a standalone python program, but
gets a little more complicated when implemented in GR.  But there's a lot
of benefit in the implementation too.

To anticipate a few questions: For my testing, I have been using no
hardware, just a GLFSR source with skiphead to implement offset (delay
block adds zeros, which get interpreted as bit errors).  I use a separate
sequence to modify the stream with a known number of errors for testing.
As I said, the block works perfectly with no offset.

Alignment is implemented by shifting the reference sequence relative to the
received sequence, calculating the residual between the two at each step
and using the minimum value of that residual as the current error count.
This should be the point where the sequences are most ideally aligned,
which works as long as the error rate is relatively low.  The reason
alignment doesn't work in my current implementation is because the
reference and received sequences are the same length, so if there is any
offset, even when aligned, it looks like there are n errors where n is the
offset between the sequences.  So, the reference sequence needs to be
longer than the reference sequence, and ideally approaching the length of
the PRBS itself to correct for any offset.

Thanks for suffering through to the end.

Very Respectfully,

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

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Dan CaJacob]

Hey John,

I am way out of my depth here, but while working on a custom python block
the other day, I saw some weird behavior in 3.7.5 that was similar.
Setting the global max output had no effect, but setting the just-upstream
block(s) min/max output buffer size(s) low fixed my apparent slowliness.

Very Respectfully,

Dan CaJacob

On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury jmalsbury.perso...@gmail.com
 wrote:

 Default scheduler.

 tb.start(1024), with different values, etc, etc.

 Most of the downstream blocks are stock GNU Radio blocks - a delay block
 (max delay is 1 sample), logical operators, etc.  I guess I'll add some
 printf debugging?

 -John




 On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller marcus.muel...@ettus.com
 wrote:

  Hi John,
 On 10.10.2014 19:33, John Malsbury wrote:

 Toward the end of the receive chain, there are a multitude of blocks that
 are used for Viterbi node synchronization. I've found that the number of
 blocks in series (3-5), combined with the low datarates at this point in
 the flowgraph, lead to latencies on the order of 1-2 minutes.  That is to
 say, once the node synchronization is accomplished, it takes 1-2 minutes to
 flush these blocks and get the fresh, good data through.  This is measured
 with function probes on the state of the sync process, and BERT analysis of
 the demodulator output [through TCP/IP socket].

  I see you found the hidden interplanetary signal delay simulator.
 Congrats! Watch out for the red shift in downstream samples.

 No, seriously, that sounds like a lot.
 You are using 3.6.4.1 with the default scheduler, tpb?

- I've tried messing around with the output buffer size option in the
flowgraph, but this seems l to have a negligible impact.

  That surprises me. How did you mess around? top_block-run(1024)?
  Do your blocks really get called with smaller input item sizes? (do a
 little printf-debugging)

- I can write some custom blocks to reduce the overall block count, but
I have demonstrated that this provides a linear improvement, rather than
the two-order-magnitude improvement I need.

 Any general advice anyone can offer?  It feels like the right solution is
 to force small buffer sizes on the relevant blocks...

  agreed. But still. That sounds *bad*. Are you sure none of the block
 demands a large input/output multiple?


 Greetings,
 Marcus

 -John




 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM

[Dan CaJacob]

Does this change affect the recommended block settings to make the magic
happen?

Very Respectfully,

Dan CaJacob

On Fri, Sep 26, 2014 at 2:29 PM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl bloe...@ccs-labs.org
 wrote:


 On 09 Sep 2014, at 15:42, Tom Rondeau t...@trondeau.com wrote:

  On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org
 wrote:
  Hi all,
 
  looking at the clock recovery MM code, I wonder if
 d_omega_relative_limit is a relative or absolute deviation from d_omega.
 
  Here it looks like absolute
 
 https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107
 
  Here it is relative
 
 https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57
 
  (even though this code has no impact since d_{min,max}_omega is not
 used.)
 
 
  I don’t have access to the book linked in the docs atm.
 
  Best,
  Bastian
 
 
  It is supposed to be relative. I'd have to verify the math on that line
 107 in the .cc file, but it's supposed to adjust the center position of the
 current omega estimate and then apply the clipping. Then it adds the mid
 point back to get it back to where it's centered. Try walking through that
 line one more time to verify that it's doing that properly. But yes, it's
 supposed to be relative to the original setting of omega.
 

 So this line asserts that the current (absolute) deviation (d_mega -
 d_omega_mid) is smaller than the maximum allowed absolute deviation
 (d_omega_mid * d_omega_relative_limit). AFAIS, the second argument is
 missing “* d_omega_mid”.

 I will create a patch, then you can check if I got you right.

 Bastian



 Just to follow up, Bastian was correct and we merged his patch in this
 week.

 Tom



 ___
 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] state of offline signal analysis tools in 2014?

[Dan CaJacob]

I've never used it for RF work, but pandas is a very powerful framework for
working with timeseries and multi-dimensional data.

Very Respectfully,

Dan CaJacob


On Wed, Jul 16, 2014 at 11:20 AM, Marcus Müller marcus.muel...@ettus.com
wrote:

 Hi Peter,

 GNU Radio is based very much on the idea of a data stream, so it might
 not actually be the tool of choice for static analysis.
 However, there is quite a lot which can be done with on-board tools, so
 let me comment in-text.
 On 16.07.2014 16:52, Peter A. Bigot wrote:
  GNU Radio is a great tool for applications and dynamic
  experimentation, but it doesn't have a lot of support for
  static/offline analysis of time-series data.  I.e. I've captured some
  signal data and I want to explore its properties interactively so I
  can figure out what I want to do with it in GNU Radio.
 
  The sort of capabilities I'm looking for include:

  Read time-series data from files of different formats (some too large
  to fit in physical memory).
 So far, only raw samples in machine float format are supported, and the
 GNU Radio-specific metadata/samples interleaved format along with the
 Wav audio file format. As far as I know, all of the sources/sinks for
 these file formats don't need to store data in RAM but read/write it
 sequentially.

 If you feel like there is something obviously missing in this list, you
 could just use the awesome powers of python and/or C++ to read your
 favourite file format, write a database adapter or a twitter source; the
 reason we don't have things like native CSV or HDF support is that I
 guess noone cared to implement a source for these formats, because they
 don't lend themselves to streaming very well, and not because it's hard.

 Anyway, there's a series of small tools for sample files, called
 gr_{plot,plot_fft,spectrogram}_type, that at least allow you to
 visualize recorded data easily, included in GNU Radio.

  Display the data, optionally applying linear transformations.
 Well the problem here is that our visual sinks usually want to
 periodically update the display, and that GNU Radio flow graphs usually
 terminate when sources have finished producing items (e.g. when the
 source file has been read completely). Many of these issues can be
 worked around be setting your file source to repeat and pausing the
 graphical sink when you see something interesting, after throttling your
 item flow enough to make the signal observable by the naked eye.

 The linear transformation thing is something you'd have to implement in
 a DSPish manner, and most probably can be done.
  Interactively pan and zoom.
 Most of the graphical sinks can do that
  Jump forwards and backwards among time-registered events.
 Nope, I'm afraid that won't work with the stream-oriented architecture
 of GNU Radio.
Enable/disable/time-shift data overlays.
 Again, if you feed a graphical sink with a signal and a time-shifted
 version, you get a DSPified method of doing your visualization
  Export selected data to new files.
 not really available (yet?).
  Calculate and display statistics and other non-linear transformations
  of selected data.
 Depends. Again, if you can translate your statistics to a signal
 processing algorithm, then it's almost certainly already been done or is
 easy to do.
 
  Ideally I'd like an open-source analysis framework that I can extend
  in Python or C++; something like the Midas DSP tool family.
 Not aware of these, sorry, and google turned up some defense program
 along with large audio mixers. Do you have a URL to refer to?
  I'm aware of some Qt widgets like QtCustomPlot, and generic frameworks
  like matplotlib and octave, but not of any ready-to-use applications
  or frameworks that already provide the basic functionality described
  above.
 I think you should take a look at things like R, GNUplot etc.
 Anyway, this is a very interesting topic, and I would really enjoy
 hearing from cool software that does what you describes in a manner that
 could e.g. be explained to EE first-semester students or so.
  The keywords I've tossed at Google haven't produced any obvious
  solutions, and discussions I find in the archives here are a couple
  years old and seem to summarize as use maplotlib/octave.
 I'm afraid my 2014 reply will disappoint you a little... it's if you
 know what characteristics you're looking for, go for a few lines of
 python; if you don't know, go for python and some additional lines.
 Actually, I've grown so used to numpy/scipy/matplotlib/pyqtgraph that I
 wouldn't trade it for Matlab (I have access to that and rarely use it),
 especially because python is something I would consider a real language
 whereas the matlab syntax and the matlab interpreter performance...
 well, matlab has fantastic documentation.

 
  Is any such framework available now or in development?  If not, is
  anybody interested in joining me offline to discuss the requirements
  and design for such a thing?
 Count me

Re: [Discuss-gnuradio] difference b/w sample rate and symbols per second

[Dan CaJacob]

Also, see
http://gnuradio.org/redmine/projects/gnuradio/wiki/SignalProcessing where
some of my own questions have been answered.

Very Respectfully,

Dan CaJacob


On Sat, Jul 5, 2014 at 11:37 AM, jason sam user0...@gmail.com wrote:

 ok thanx for the replies!

 On Sat, Jul 5, 2014 at 7:19 PM, Vanush Vaswani van...@gmail.com wrote:
  You may refer to this example to see how to transmit 9.6kbps GFSK
  signal through an AWGN channel.
 
  https://www.youtube.com/watch?v=N1hR6VgWeowfeature=youtu.be
 
 
 
  On Sun, Jul 6, 2014 at 12:00 AM, Marcus Müller marcus.muel...@ettus.com
 wrote:
  We might be talking about different blocks.
  I'm referring to gr::analog::frequency_modulator_fc, where the
  documentation only says[1]
 
  radians/sample = amplitude * sensitivity
 
  From what you paste as formulas this does not look like the general
  frequency modulation, but like a digital modulation scheme, e.g. GMSK.
 
  Anyway, we will not be able to tell you what you'll need to use as
  parameters for your transmitter -- that is something that you, based on
  your communication engineering skills, will need to decide yourself.
 
  Sincerely,
  Marcus Müller
 
  [1]
 http://gnuradio.org/doc/doxygen/classgr_1_1analog_1_1frequency__modulator__fc.html#a9c252eeb8c9daf6ccd50427d3bc55bd3
 
  On 05.07.2014 09:59, jason sam wrote:
  Sorry for prolonging the discussion but I am a bit confused here.The
  sensitivity parameter for Freq Mod block is defined as:
 
  sensitivity = (pi * modulation_index) / samples_per_symbol
  where,
 
  modulation_index = deviation / (baud_rate / 2)
 
  So what values should i plug in for samples_per_symbol and baud_rate
  in the formulas?
 
 
  On Fri, Jul 4, 2014 at 9:14 PM, Marcus Müller 
 marcus.muel...@ettus.com wrote:
  Not at all, because for these blocks, symbols have no meaning.
 
  On 04.07.2014 17:38, jason sam wrote:
  Yes Marcus,u are r right and i am also asking about such blocks like
  the FM Mod block..In this block u have an option to set sample rate
  but how can u set samples per symbol??
 
  On Fri, Jul 4, 2014 at 6:08 PM, Marcus Müller 
 marcus.muel...@ettus.com wrote:
  Hi Ali,
  as said several times: Sampling rate, samples per symbol etc are
  concepts that are meaningful only for certain blocks, and thus
 there is
  no sense in setting those globally.
 
  Greetings,
  Marcus
  On 04.07.2014 08:33, jason sam wrote:
  Thanx Martin,but where in GRC we can set samples per symbol??I am
 new
  to this so i don't know yet...
 
  Ali
 
  On Tue, Jul 1, 2014 at 2:18 PM, Martin Braun 
 martin.br...@ettus.com wrote:
  On 06/26/2014 11:06 AM, jason sam wrote:
  I am bit confused b/w the two terms.I have read some material
 and i
  got the following relationship b/w the two:
  samples/second =samples/symbol * symbols/second
  And i think in GRC samples per symbol is 1(plz correct if i am
  wrong).So sample rate becomes equal to baud
 rate(symbols/second)??
  samples per symbol is whatever you set it to; common values are 2
 and 4
  (this also depends on the modulation used). Higher values are
 often used
  for demo purposes.
 
  M
 
 
  ___
  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 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] ColtrolPort IC Timeout

[Dan CaJacob]

Hey Tom,

Yes, it was definitely pulling the correct endpoint.  Even though it is
backgrounded, I have a log for everything that ran.

Very Respectfully,

Dan CaJacob


On Fri, May 23, 2014 at 11:26 AM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, May 22, 2014 at 11:09 AM, Dan CaJacob dan.caja...@gmail.comwrote:

 I have a gui-less flowgraph that runs in the background with sudo
 privileges.  While I can run ControlPort normally from GRC, it doesn't seem
 to work properly with my backgrounded FG - I get timeout errors.  My config
 files are setup so that both FGs do actually call ControlPort and Perf Mon
 (verified in log files).  The FG and the monitoring apps are all running on
 the same PC.

 Setup is Ubuntu 12.04 x64 with GR 3.7.4, built on the weekend.

 Attempting to run Perf Mon, I get:

 $ gr-perf-monitorx 127.0.0.1 23456



 Hey Dan,

 When you're running the flowgraph that you're trying to connect to over
 ControlPort, can you verify that they are setting up the correct endpoint?
 If you run it yourself, not as a background task, it should print out
 information about the endpoints. That will tell you the port number. Just
 want to check to make sure your config file is getting read correctly and
 setting it up on port 23456 like you specified.

 We really should move the endpoint information to be sent out by the
 gr-log system so you can redirect the info to a file and see the info
 without requiring you to have access to stdout.

 Tom




 2014-05-22 11:01:54.450720 /usr/bin/gr-perf-monitorx: error: Traceback
 (most recent call last):
   File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main
 status = self.doMain(args, initData)
   File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain
 return self.run(args)
   File
 /usr/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
 line 102, in run
 ex = self.parentClass(radio, port, self)
   File /usr/bin/gr-perf-monitorx, line 74, in __init__
 self.newCon(radio, port)
   File /usr/bin/gr-perf-monitorx, line 88, in newCon
 child = MForm(radio, port, len(self.conns), self)
   File /usr/bin/gr-perf-monitorx, line 696, in __init__
 knobs = self.radio.get([])
   File /usr/lib/python2.7/dist-packages/gnuradio_ice.py, line 1221, in
 get
 return _M_gnuradio.ctrlport.GNURadio.ControlPort._op_get.invoke(self,
 ((knobs, ), _ctx))
 ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
 {
 }

 Attempting to run Ctrl Port Mon, I get:

 A blank canvas screen like this: http://i.imgur.com/8N88fcU.png

 and console output like:

 $ gr-ctrlport-monitor 127.0.0.1 23456
 X Error: BadAccess (attempt to access private resource denied) 10
   Extension:129 (MIT-SHM)
   Minor opcode: 1 (X_ShmAttach)
   Resource id:  0x421
 X Error: BadShmSeg (invalid shared segment parameter) 128
   Extension:129 (MIT-SHM)
   Minor opcode: 5 (X_ShmCreatePixmap)
   Resource id:  0x4200012
 X Error: BadDrawable (invalid Pixmap or Window parameter) 9
   Major opcode: 62 (X_CopyArea)
   Resource id:  0x4200013
 X Error: BadDrawable (invalid Pixmap or Window parameter) 9
   Major opcode: 62 (X_CopyArea)
   Resource id:  0x4200013
 ctrlport-monitor: radio.get threw exception (exception
 ::Ice::ConnectTimeoutException
 {
 }).
 ...

 My ctrlport.conf file has just one uncommented line:

 ControlPort.Endpoints = tcp -t 5000 -h 127.0.0.1 -p 23456

 I had extended the timeout, attempting to resolve the problem, but had no
 luck.

 Very Respectfully,

 Dan CaJacob

 ___
 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] ColtrolPort IC Timeout

[Dan CaJacob]

I have a gui-less flowgraph that runs in the background with sudo
privileges.  While I can run ControlPort normally from GRC, it doesn't seem
to work properly with my backgrounded FG - I get timeout errors.  My config
files are setup so that both FGs do actually call ControlPort and Perf Mon
(verified in log files).  The FG and the monitoring apps are all running on
the same PC.

Setup is Ubuntu 12.04 x64 with GR 3.7.4, built on the weekend.

Attempting to run Perf Mon, I get:

$ gr-perf-monitorx 127.0.0.1 23456

2014-05-22 11:01:54.450720 /usr/bin/gr-perf-monitorx: error: Traceback
(most recent call last):
  File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main
status = self.doMain(args, initData)
  File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain
return self.run(args)
  File
/usr/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py,
line 102, in run
ex = self.parentClass(radio, port, self)
  File /usr/bin/gr-perf-monitorx, line 74, in __init__
self.newCon(radio, port)
  File /usr/bin/gr-perf-monitorx, line 88, in newCon
child = MForm(radio, port, len(self.conns), self)
  File /usr/bin/gr-perf-monitorx, line 696, in __init__
knobs = self.radio.get([])
  File /usr/lib/python2.7/dist-packages/gnuradio_ice.py, line 1221, in get
return _M_gnuradio.ctrlport.GNURadio.ControlPort._op_get.invoke(self,
((knobs, ), _ctx))
ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
{
}

Attempting to run Ctrl Port Mon, I get:

A blank canvas screen like this: http://i.imgur.com/8N88fcU.png

and console output like:

$ gr-ctrlport-monitor 127.0.0.1 23456
X Error: BadAccess (attempt to access private resource denied) 10
  Extension:129 (MIT-SHM)
  Minor opcode: 1 (X_ShmAttach)
  Resource id:  0x421
X Error: BadShmSeg (invalid shared segment parameter) 128
  Extension:129 (MIT-SHM)
  Minor opcode: 5 (X_ShmCreatePixmap)
  Resource id:  0x4200012
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x4200013
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x4200013
ctrlport-monitor: radio.get threw exception (exception
::Ice::ConnectTimeoutException
{
}).
...

My ctrlport.conf file has just one uncommented line:

ControlPort.Endpoints = tcp -t 5000 -h 127.0.0.1 -p 23456

I had extended the timeout, attempting to resolve the problem, but had no
luck.

Very Respectfully,

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

Re: [Discuss-gnuradio] Installation issues with gnuradio on Ubuntu 12.04 64-bit

[Dan CaJacob]

Try:

sudo apt-get remove --purge libboost*
sudo apt-get install libboost1.48-all-dev

You may then have to install gnuradio and uhd again, since they depend on
boost:

sudo apt-get install gnuradio uhd

Very Respectfully,

Dan CaJacob


On Wed, May 21, 2014 at 4:40 PM, muse_ee brian.bubn...@jhuapl.edu wrote:

 Hello,

 I'm having some issues when I attempt to install gnuradio on a computer
 running Ubuntu 12.04 64-bit. I followed the installation guide on the Ettus
 wiki (using the Releases/Bugfixes path)
 (http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Linux) but
 when I run the command gnuradio-config-info I get an error message stating:

 gnuradio-config-info: error while loading shared libraries:
 libboost_program_options.so.1.48.0: cannot open shared object file: No such
 file or directory.

 I'm not very experienced with gnuradio or linux, but it looks like when I
 apt-get install gnuradio, the libboost packages being downloaded are
 version
 1.46, but when I run my command it is looking for version 1.48. Is there a
 way I can work around this? As I said, I'm not really familiar with apt-get
 or gnuradio in general. Any help you can provide would be very much
 appreciated!





 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Installation-issues-with-gnuradio-on-Ubuntu-12-04-64-bit-tp48405.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

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

Re: [Discuss-gnuradio] Ice-related Build Problem

[Dan CaJacob]

Tom,

Interestingly, when I was retesting the cmake output for you, I built it
manually after that and it worked this time - no ice complaints.  So, the
problem seems likely to be somehow brought out when pybombs does the build
(maybe passing options that I did not when compiling manually).

The original problem was on multiple machines and across multiple tries to
build with pybombs, so this final success was definitely the result of
something done differently.

Very Respectfully,

Dan CaJacob


On Fri, May 16, 2014 at 12:05 PM, Dan CaJacob dan.caja...@gmail.com wrote:

 Thanks, Tom!  See my comments in context below:


 On Fri, May 16, 2014 at 9:05 AM, Tom Rondeau t...@trondeau.com wrote:

 On Fri, May 16, 2014 at 1:21 AM, Dan CaJacob dan.caja...@gmail.comwrote:

 Running find to search for the missing library does find it at:

 /usr/lib64/libIce.so.35

 Very Respectfully,

 Dan CaJacob


 Wait, why do you have a lib64 on an Ubuntu machine? But, we do check in
 lib64, so that shouldn't be the problem.

 I don't know, but I do have ia32-libs installed on all of my nodes.  It
 had been necessary in the past for one of our binaries, but may no longer
 be so.

  However, package management is not one of ZeroC's strong suits, as
 Philip and I can attest to with the OE recipe work... And finding the
 libraries is a pain as well.

 Do you have /usr/include/Ice*? And specifically,
 /usr/include/IceUtil/Config.h. We use that to test if the Ice dev files are
 there, and if so, extract the version number from it.

 I do have those directories and the specific file you mentioned.


 Things seem to be completely different for Ice 3.4 and Ice 3.5 and on
 different versions of Ubuntu as well as other distros. It's kind of a mess.
 Can you get the CMake output for me? For the latest Ice 3.5 cmake script,
 there's a lot more output info to see what's happening.

 Sure.  I assume you mean for gnuradio and no Ice.

 http://pastebin.com/3z26M3xN


 Tom




  On Fri, May 16, 2014 at 1:20 AM, Dan CaJacob dan.caja...@gmail.comwrote:

 Building GR with the latest pybombs completes successfully, but when
 calling a GR binary, there's an error about ICE (which built without
 problems):

 $:~/pybombs/src/gnuradio/build$ gnuradio-config-info -v
 gnuradio-config-info: error while loading shared libraries:
 libIce.so.35: cannot open shared object file: No such file or directory

 This is on Ubuntu 12.04 x64

 Very Respectfully,

 Dan CaJacob



 ___
 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] Ice-related Build Problem

[Dan CaJacob]

Building GR with the latest pybombs completes successfully, but when
calling a GR binary, there's an error about ICE (which built without
problems):

$:~/pybombs/src/gnuradio/build$ gnuradio-config-info -v
gnuradio-config-info: error while loading shared libraries: libIce.so.35:
cannot open shared object file: No such file or directory

This is on Ubuntu 12.04 x64

Very Respectfully,

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

Re: [Discuss-gnuradio] Ice-related Build Problem

[Dan CaJacob]

Running find to search for the missing library does find it at:

/usr/lib64/libIce.so.35

Very Respectfully,

Dan CaJacob


On Fri, May 16, 2014 at 1:20 AM, Dan CaJacob dan.caja...@gmail.com wrote:

 Building GR with the latest pybombs completes successfully, but when
 calling a GR binary, there's an error about ICE (which built without
 problems):

 $:~/pybombs/src/gnuradio/build$ gnuradio-config-info -v
 gnuradio-config-info: error while loading shared libraries: libIce.so.35:
 cannot open shared object file: No such file or directory

 This is on Ubuntu 12.04 x64

 Very Respectfully,

 Dan CaJacob

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

Re: [Discuss-gnuradio] change value of variable in GRC when a message is received

[Dan CaJacob]

I'm not sure it's what you want, but the RPC Server block lets you change
the value of any GR variable in a running FG remotely.  There also seems to
be some work ongoing t bring zeromq endpoints into GR.

Very Respectfully,

Dan CaJacob


On Thu, May 8, 2014 at 1:07 PM, Achilleas Anastasopoulos
anas...@umich.eduwrote:

 Is there a simple way for a GRC block  to asynchronously
 change the value of a GRC variable when
 the block receives a specific message?

 thanks
 Achilleas

 ___
 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] convert old Gnu Radio applications

[Dan CaJacob]

This should get you most of the way:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

Very Respectfully,

Dan CaJacob


On Tue, May 6, 2014 at 12:08 PM, 王先达 wangxianda920...@163.com wrote:


 Hello all
  Now i want to convert old Gnu Radio applications which were 
 developed in the gnuradio 3.3.0 to the gnuradio 3.7.0.Can someone give me 
 some advices on this?Any advices will be appreciated.
  Thank you very much.
 Best regards,
 Xianda Wang




 ___
 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] Build problems with pybombs

[Dan CaJacob]

I got the same error at work on my newly upgraded 64 bit laptop running
Ubuntu 14.04  Strangely, I built last night on a similar laptop with no
problems.

Very Respectfully,

Dan CaJacob


On Fri, Apr 18, 2014 at 4:48 PM, Mike Willis willis...@gmail.com wrote:

 Yet more difficulties. Having found a work around for the Usb issue with
 the B200, I was then unable to get any of the audio examples to run again
 due to /dev/dsp not being present and gnuradio insisting on using oss. I
 Decided I must not have built it correctly so I tried re-building yet again
 with pybombs. This is slow as I have only access to slow broadband here.
 Now I have total build failure in uhd. Not sure how to proceed as I don't
 know what I am doing wrong here. It worked fine last time.

 Mike

 [  4%] Built target man_page_gzips
 [  4%] [  4%] [  4%] [  5%] Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/cores/radio_ctrl_core_3000.cpp.o
 Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/dboard/db_sbx_version3.cpp.o
 Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/dboard/db_sbx_version4.cpp.o
 Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard/db_cbx.cpp.o
 In file included from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21:0,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp: In static
 member function ‘static std::vectorunsigned char
 uhd::msg_task::buff_to_vector(boost::uint8_t*, size_t)’:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:36:
 error: ‘uint8_t’ was not declared in this scope
  return std::vectoruint8_t();
 ^
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:36:
 note: suggested alternative:
 In file included from /usr/local/include/boost/integer_fwd.hpp:17:0,
  from /usr/local/include/boost/integer.hpp:18,
  from
 /usr/local/include/boost/function/function_base.hpp:21,
  from
 /usr/local/include/boost/function/detail/prologue.hpp:17,
  from /usr/local/include/boost/function.hpp:24,
  from
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:24,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /usr/local/include/boost/cstdint.hpp:211:30: note:   ‘boost::uint8_t’
   typedef unsigned char   uint8_t;
   ^
 In file included from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21:0,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:43:
 error: template argument 1 is invalid
  return std::vectoruint8_t();
^
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:43:
 error: template argument 2 is invalid
 make[2]: ***
 [lib/CMakeFiles/uhd.dir/usrp/cores/radio_ctrl_core_3000.cpp.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
 make: *** [all] Error 2
 ERROR:root:PyBOMBS Make step failed for package (uhd) please see bash
 output above for a reason (hint: look for the word Error)

 ___
 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] Build problems with pybombs

[Dan CaJacob]

I haven't fixed it.  That's why I am piggy-backing on your email.

Very Respectfully,

Dan CaJacob


On Fri, Apr 18, 2014 at 5:00 PM, Mike Willis willis...@gmail.com wrote:

 That's interesting as its more or less the same here, except my last build
 was a couple of days ago. I am also running ubuntu 14.04, a fresh install.
 How did you fix the error?

 Mike


 On Fri, Apr 18, 2014 at 9:58 PM, Dan CaJacob dan.caja...@gmail.comwrote:

 I got the same error at work on my newly upgraded 64 bit laptop running
 Ubuntu 14.04  Strangely, I built last night on a similar laptop with no
 problems.

 Very Respectfully,

 Dan CaJacob


 On Fri, Apr 18, 2014 at 4:48 PM, Mike Willis willis...@gmail.com wrote:

 Yet more difficulties. Having found a work around for the Usb issue with
 the B200, I was then unable to get any of the audio examples to run again
 due to /dev/dsp not being present and gnuradio insisting on using oss. I
 Decided I must not have built it correctly so I tried re-building yet again
 with pybombs. This is slow as I have only access to slow broadband here.
 Now I have total build failure in uhd. Not sure how to proceed as I don't
 know what I am doing wrong here. It worked fine last time.

 Mike

 [  4%] Built target man_page_gzips
 [  4%] [  4%] [  4%] [  5%] Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/cores/radio_ctrl_core_3000.cpp.o
 Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/dboard/db_sbx_version3.cpp.o
 Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/dboard/db_sbx_version4.cpp.o
 Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard/db_cbx.cpp.o
 In file included from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21:0,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp: In
 static member function ‘static std::vectorunsigned char
 uhd::msg_task::buff_to_vector(boost::uint8_t*, size_t)’:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:36:
 error: ‘uint8_t’ was not declared in this scope
  return std::vectoruint8_t();
 ^
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:36:
 note: suggested alternative:
 In file included from /usr/local/include/boost/integer_fwd.hpp:17:0,
  from /usr/local/include/boost/integer.hpp:18,
  from
 /usr/local/include/boost/function/function_base.hpp:21,
  from
 /usr/local/include/boost/function/detail/prologue.hpp:17,
  from /usr/local/include/boost/function.hpp:24,
  from
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:24,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /usr/local/include/boost/cstdint.hpp:211:30: note:   ‘boost::uint8_t’
   typedef unsigned char   uint8_t;
   ^
 In file included from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21:0,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:43:
 error: template argument 1 is invalid
  return std::vectoruint8_t();
^
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:43:
 error: template argument 2 is invalid
 make[2]: ***
 [lib/CMakeFiles/uhd.dir/usrp/cores/radio_ctrl_core_3000.cpp.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
 make: *** [all] Error 2
 ERROR:root:PyBOMBS Make step failed for package (uhd) please see bash
 output above for a reason (hint: look for the word Error)

 ___
 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] Build problems with pybombs

[Dan CaJacob]

Yep, Mike, I am going to post this over on the Ettus ML.  I'll copy you.

Very Respectfully,

Dan CaJacob


On Fri, Apr 18, 2014 at 5:01 PM, Tom Rondeau t...@trondeau.com wrote:

 On Fri, Apr 18, 2014 at 4:58 PM, Dan CaJacob dan.caja...@gmail.comwrote:

 I got the same error at work on my newly upgraded 64 bit laptop running
 Ubuntu 14.04  Strangely, I built last night on a similar laptop with no
 problems.

 Very Respectfully,

 Dan CaJacob



 This appears to be a problem with Boost 1.55.

 I'm using Ubuntu 14.04 (I'm assuming, Mike, that you've just updated as
 well?) and using Boost 1.54 with no problems. 14.04 also has Boost 1.55
 available for install, and that might be what you're pulling down.

 This is really a UHD-related issue:
 https://github.com/EttusResearch/uhd/pull/2


 Tom




 On Fri, Apr 18, 2014 at 4:48 PM, Mike Willis willis...@gmail.com wrote:

 Yet more difficulties. Having found a work around for the Usb issue with
 the B200, I was then unable to get any of the audio examples to run again
 due to /dev/dsp not being present and gnuradio insisting on using oss. I
 Decided I must not have built it correctly so I tried re-building yet again
 with pybombs. This is slow as I have only access to slow broadband here.
 Now I have total build failure in uhd. Not sure how to proceed as I don't
 know what I am doing wrong here. It worked fine last time.

 Mike

 [  4%] Built target man_page_gzips
 [  4%] [  4%] [  4%] [  5%] Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/cores/radio_ctrl_core_3000.cpp.o
 Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/dboard/db_sbx_version3.cpp.o
 Building CXX object
 lib/CMakeFiles/uhd.dir/usrp/dboard/db_sbx_version4.cpp.o
 Building CXX object lib/CMakeFiles/uhd.dir/usrp/dboard/db_cbx.cpp.o
 In file included from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21:0,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp: In
 static member function ‘static std::vectorunsigned char
 uhd::msg_task::buff_to_vector(boost::uint8_t*, size_t)’:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:36:
 error: ‘uint8_t’ was not declared in this scope
  return std::vectoruint8_t();
 ^
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:36:
 note: suggested alternative:
 In file included from /usr/local/include/boost/integer_fwd.hpp:17:0,
  from /usr/local/include/boost/integer.hpp:18,
  from
 /usr/local/include/boost/function/function_base.hpp:21,
  from
 /usr/local/include/boost/function/detail/prologue.hpp:17,
  from /usr/local/include/boost/function.hpp:24,
  from
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:24,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /usr/local/include/boost/cstdint.hpp:211:30: note:   ‘boost::uint8_t’
   typedef unsigned char   uint8_t;
   ^
 In file included from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.hpp:21:0,
  from
 /home/mike/pybombs/src/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:18:
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:43:
 error: template argument 1 is invalid
  return std::vectoruint8_t();
^
 /home/mike/pybombs/src/uhd/host/include/uhd/utils/msg_task.hpp:51:43:
 error: template argument 2 is invalid
 make[2]: ***
 [lib/CMakeFiles/uhd.dir/usrp/cores/radio_ctrl_core_3000.cpp.o] Error 1
 make[2]: *** Waiting for unfinished jobs
 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
 make: *** [all] Error 2
 ERROR:root:PyBOMBS Make step failed for package (uhd) please see bash
 output above for a reason (hint: look for the word Error)

 ___
 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] New GRC behavior request for comment

[Dan CaJacob]

I think this change might be breaking a few things.  If anyone else can
check, please let me know if I'm nuts:

I am running v3.7.4git-95-g24191d86 on Ubuntu 13.10 x64.  In GRC, when I
try to change the type associated with a block via the select box, it
changes (and the text turns blue), but when I close the parameter window,
nothing actually changes.  I also saw similar behavior with combo boxes.
 In that case, selecting an option did not take, but overwriting it did.

Very Respectfully,

Dan CaJacob


On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech mle...@ripnet.com wrote:

 On 04/10/2014 04:13 PM, Ed Criscuolo wrote:



 How hard would it be to pop up a bother box if you attempt
 to enter with outstanding parameter error(s).  Give you
 a chance to confirm or cancel the enter, because you may want to
 deliberately enter something that's wrong now but will be
 fixed later (for instance a variable name that you haven't
 created yet).

 I certainly like the evaluate when you leave the box paradigm, but I'm
 also the kind of developer who will enter a variable name, etc, that
   hasn't actually been created yet.

 --
 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Include guard bug

[Dan CaJacob]

Yeah, start completely clean.

Very Respectfully,

Dan CaJacob


On Fri, Feb 21, 2014 at 11:17 AM, Ruecan naceuram...@gmail.com wrote:

 I just pulled the changes then did make but get the same error.

 I am not so familiar with git. After pulling your bugfix, do I need to make
 clean, remove the CMakeCache then do cmake again then make or am I missing
 some part of the process.




 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46457.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

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

Re: [Discuss-gnuradio] Different sensing results with same hypothesis

[Dan CaJacob]

I don't think there is any AGC on USRP hardware...

Very Respectfully,

Dan CaJacob


On Wed, Feb 19, 2014 at 9:57 AM, Aditya Dhananjay adi...@cs.nyu.edu wrote:




 On Wed, Feb 19, 2014 at 6:26 AM, Lebowski80 ale.rasche...@gmail.comwrote:

 Hello everyone,

 Before to explain my problem I give some technical information about my
 hardaware. I'm using USRPs v1 and the boards integrated are XCVR2450
 Transceivers.

 I'm using the script usrp_spectrum_sense.py in a USRP to detect a signal
 in
 a ISM channel. To have a signal expressed in db I did this simple
 operation
 to the received signal:

 signal_db = 20*(math.log10(math.sqrt(m.data[0]/tb.slot_number)))

 I can control the signal transmitted in the ISM channel; so, I know
 exactly
 the time when there is a signal to be detected in the channel. During the
 first hours the USRP detects the signal giving me a value of around 40 db
 but after some hours such a detected signal decreases up to roughly 10 db
 and it does not change anymore regardless of the signal transmitted in the
 ISM channel. Only if I kill the process running the usrp_spectrum_sense.py
 script and execute it again, the USRP starts to detect again the 40 db
 value. The signal to be detected in the ISM channel is always the same.
 Can
 anyone tell me which is the problem?

 Thanks in advance.


 I have no clue, but my first (and only) guess would be the automatic gain
 control (AGC) on the USRP hardware.

 If you figure it out, please let us know!

 best,
 aditya


 ___
 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] Need an indicator on the GUI display

[Dan CaJacob]

The number sink has a gauge option.

On Saturday, January 25, 2014, j...@moudy.com wrote:

 I've written an application for my client. The application works great
 (monitoring multiple channels for radio traffic and recording the demod FM
 stream). The client would like to see a couple of lights that show activity
 on the channel rather than a FFT GUI plot, which I like. Does anyone know
 of a indicator (on off light) that I can put on a GUI? Alternatively,
 maybe a VU meter widget?

 The Indicator would show when a squelch is active or a threshold has been
 crossed.

 Thanks for any ideas.



-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Passing a USRP pointer

[Dan CaJacob]

On Fri, Jan 17, 2014 at 5:40 PM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Jan 14, 2014 at 9:09 PM, Dan CaJacob dan.caja...@gmail.com
 wrote:
  Hey Tom,
 
  The block worked fine with the right symblic name passed!  The amp is
  getting PTTed now in 3.7  Thanks for your help with this!

 Great!


  It still seems weird that the USRP Sink symbolic name was formatted
  differently, though.

 Hm, yes, that is odd. Would you open a ticket about it? Low priority
 and a change in behavior that might have to wait for 3.8.


Will do!


  Also, would it be possible to automatically register symbolic name
 aliases
  that are based on the block names created in GRC/python?  That would make
  the lookup a little more obvious.

 Which names, exactly? Are you talking about the variable name itself?


I'm not sure what the nomenclature is, but I am talking about the name that
is auto-generated by GRC when a block is placed, but which can be modified
by the user.  This name becomes the blocks object name in the python file.


 For that, there's no way for the block to know that information. On
 the other hand, you can actually set the block alias yourself so you
 don't have to ask/guess/know what it is in advance using the
 set_block_alias(string) function.


I am aware of the alias function.  The question is - can we use that
somewhere so that the block automatically gets aliased as the name the
block instance is given in GRC?  Probably, this needs to live in GRC
itself, specifically in the code that generates a python file from the FG.
 Does that make sense?  I assume the alias function is a method of the
block objects in python.

Thanks for your help with this, Tom!  I'm really excited about 3.7!  I'm
already using it on one of my flatsat setups.



 Tom


  Thanks!
 
  Very Respectfully,
 
  Dan CaJacob
 
 
  On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob dan.caja...@gmail.com
 wrote:
 
  Hey Tom,
 
  We've been working on this, but we ran into a snag.  We couldn't seem to
  look up the usrp sink block's key.  Other blocks could be looked up
 with the
  keys we expected, just not the uhd sink.  I just un-commented a print
  statement in block_registry.cc so that we could see how each block
 actually
  gets registered, built it and ran a simple flowgraph.
 
  The flowgraph is just a signal source - throttle - uhd sink.  Here's
 the
  output:
 
  register_symbolic_name: top_block0
  register_symbolic_name: gr uhd usrp sink0
  register_symbolic_name: throttle0
  register_symbolic_name: sig_source_c0
 
  The UHD sink block gets an unexpected gr pre-pended and the
 underscores
  are replaced with spaces.
 
  We are going to attempt our OOT blocks with this in mind, but I thought
  I'd give you a heads up on this behavior.
 
  Thanks!
 
  Very Respectfully,
 
  Dan CaJacob
 
 
  On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote:
 
  On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com
  wrote:
   Hey Tom,
  
   Here's some more detail into our problem.
  
   When running the flowgraph, we get the following error:
  
   File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line
 679,
   in
   make
   return _sq_swig.usrp_pa_control_make(*args, **kwargs)
   TypeError: in method 'usrp_pa_control_make', argument 1 of type
   'gr::uhd::usrp_sink::sptr'
  
   When setting up a FG, the pa-control block accepts a reference to the
   downstream UHD sink.
  
   I have attached the specific block source.
  
   Thanks!
  
   Very Respectfully,
  
   Dan CaJacob
 
  It's probably the difference between a gr::uhd::usrp_sink and a
  gr::uhd::usrp_sink_impl.
 
  A safer way to handle this might be to use the new(ish) block_registry
  that we implemented to handle the message passing infrastructure. You
  can get a basic_block_sptr from global_block_registry.block_lookup;
  you should then be able to cast this to a usrp_sink_sptr. You'll pass
  it a PMT symbol containing the alias name of the UHD sink itself.
 
  Take a look at basic_block.cc for a look at how the
  global_block_registry is used. I've not done exactly this before, so
  it might not go completely smoothly, and I'd be interested in your
  experience.
 
  In general, this sounds like something more appropriately implemented
  as a message, though, but that would mean changing the gr-uhd code.
  Having a message handler for the GPIO stuff would probably be useful
  if done generically enough.
 
  Tom
 
 
 
 
   On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com
   wrote:
  
   Thanks Tom,
  
   No problem.  I hope you and the rest of the community had relaxing
   holidays!  I hope to have some better info for you by tomorrow, if
 not
   before.
  
   Another way to look at this is: does it make sense to keep doing
   things
   this way?  Is there a better way to reference the downstream USRP
 and
   toggle
   the IO?  I could imagine an async message stream or specific
   stream-tags,
   but both would probably

Re: [Discuss-gnuradio] Passing a USRP pointer

[Dan CaJacob]

Hey Tom,

The block worked fine with the right symblic name passed!  The amp is
getting PTTed now in 3.7  Thanks for your help with this!

It still seems weird that the USRP Sink symbolic name was formatted
differently, though.
Also, would it be possible to automatically register symbolic name aliases
that are based on the block names created in GRC/python?  That would make
the lookup a little more obvious.

Thanks!

Very Respectfully,

Dan CaJacob


On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob dan.caja...@gmail.com wrote:

 Hey Tom,

 We've been working on this, but we ran into a snag.  We couldn't seem to
 look up the usrp sink block's key.  Other blocks could be looked up with
 the keys we expected, just not the uhd sink.  I just un-commented a print
 statement in block_registry.cc so that we could see how each block actually
 gets registered, built it and ran a simple flowgraph.

 The flowgraph is just a signal source - throttle - uhd sink.  Here's the
 output:

 register_symbolic_name: top_block0
 register_symbolic_name: gr uhd usrp sink0
 register_symbolic_name: throttle0
 register_symbolic_name: sig_source_c0

 The UHD sink block gets an unexpected gr pre-pended and the underscores
 are replaced with spaces.

 We are going to attempt our OOT blocks with this in mind, but I thought
 I'd give you a heads up on this behavior.

 Thanks!

 Very Respectfully,

 Dan CaJacob


 On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com
 wrote:
  Hey Tom,
 
  Here's some more detail into our problem.
 
  When running the flowgraph, we get the following error:
 
  File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679,
 in
  make
  return _sq_swig.usrp_pa_control_make(*args, **kwargs)
  TypeError: in method 'usrp_pa_control_make', argument 1 of type
  'gr::uhd::usrp_sink::sptr'
 
  When setting up a FG, the pa-control block accepts a reference to the
  downstream UHD sink.
 
  I have attached the specific block source.
 
  Thanks!
 
  Very Respectfully,
 
  Dan CaJacob

 It's probably the difference between a gr::uhd::usrp_sink and a
 gr::uhd::usrp_sink_impl.

 A safer way to handle this might be to use the new(ish) block_registry
 that we implemented to handle the message passing infrastructure. You
 can get a basic_block_sptr from global_block_registry.block_lookup;
 you should then be able to cast this to a usrp_sink_sptr. You'll pass
 it a PMT symbol containing the alias name of the UHD sink itself.

 Take a look at basic_block.cc for a look at how the
 global_block_registry is used. I've not done exactly this before, so
 it might not go completely smoothly, and I'd be interested in your
 experience.

 In general, this sounds like something more appropriately implemented
 as a message, though, but that would mean changing the gr-uhd code.
 Having a message handler for the GPIO stuff would probably be useful
 if done generically enough.

 Tom




  On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com
 wrote:
 
  Thanks Tom,
 
  No problem.  I hope you and the rest of the community had relaxing
  holidays!  I hope to have some better info for you by tomorrow, if not
  before.
 
  Another way to look at this is: does it make sense to keep doing things
  this way?  Is there a better way to reference the downstream USRP and
 toggle
  the IO?  I could imagine an async message stream or specific
 stream-tags,
  but both would probably require changes to the actual UHD sinks.  I'm
 not
  sure our use case is generic enough to warrant that.
 
  Very Respectfully,
 
  Dan CaJacob
 
 
  On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote:
 
  On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com
  wrote:
   We are upgrading some of our custom blocks for 3.7 and have run
 into a
   snag.
   Our 3.6 era blocks included one that PTTed an external amplifier
 based
   on
   stream tags.  The IO was generated from the extra GPIO available on
 the
   WBX.
   One of the inputs to the block was a reference to the USRP sink
   downstream
   in the FG.  The block then calls the necessary methods to enable and
   disable
   the GPIO.  Everything worked nicely, but when we ported our blocks
 to
   3.87,
   there seemed to be a problem with this.  I did not personally do the
   testing, so I don't have the exact error, but I can probably
 re-create
   it
   given some time.
  
   I started the porting of the blocks myself and did notice that
 getting
   the
   pointer to a USRP object had changed.  But the blocks built without
   error
   when updated appropriately.
  
   Is there anything in principle that would prevent this from working
 in
   3.7?
   Or, is there a better approach to controlling the WBX GPIO based on
   stream
   tags that we should consider?
  
   I apologize for the vagueness on the actual error.  I'll try to
   reproduce it
   myself in the meantime.
  
   I can

Re: [Discuss-gnuradio] Multiple Versions of Libraries / Virtualenv (was: Re: PYBOMBs Testing)

[Dan CaJacob]

Thanks, Marcus.  It seemed too good to be true ;)

Very Respectfully,

Dan CaJacob


On Fri, Jan 10, 2014 at 1:20 PM, Marcus Müller mar...@hostalia.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Dan,

 no, Virtualenv is virtualenv is a tool to create isolated Python
 environments. only.

 For unix systems, having multiple versions of the same library is not
 a problem by itself, especially since there are several environment
 variables that control the behaviour of the dynamic run time linker.

 A nice method to employ this is described in

 http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Experts-only-How-can-I-deliberately-install-GNU-Radio-multiple-times-different-versions
 ; just install your application specific libraries, headers etc into
 ~/.usrlocal.

 Also, if you need to capsulate your system more thoroughly, consider
 using chroot; although this has become less popular over the last few
 years due to the fact that virtualization has become so easy.

 Hope that was a little insightful. If someone comes up with something
 interesting on this topic, a new thread should be started; although I
 consider this problem to be of a typical linux distribution concern,
 and not very much specific to GR.

 Greetings,
 Marcus

 On 10.01.2014 16:45, Dan CaJacob wrote:
  Thanks, Tom!
 
  Digression warning: While we're on the topic, I've always wondered
  if virtualenv would help with build dependency problems and
  multiple installed versions (e.g. for devs).  I have never immersed
  myself into the tool, but I know that it is intended for things
  like this where you want to install specific package versions for a
  specific application without affecting other things on your system.
  It's a sandbox, I guess.  What I've never been clear on is whether
  it works for C/C++ applications, since it seems to be a python
  tool.  Do you have any thoughts on that?
 
  Very Respectfully,
 
  Dan CaJacob
 
 
  On Fri, Jan 10, 2014 at 10:14 AM, Tom Rondeau t...@trondeau.com
  wrote:
 
  On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob
  dan.caja...@gmail.com wrote:
  Hey Tom,
 
  Thanks.  I didn't know how or what to search for, so that was
  useful. Here's the result:
 
  i   libzeroc-ice34 - Ice for C++
  runtime library
 
  That there confirms that the Ice 3.4.2 library is installed on
  your system, which is what I was expecting.
 
 
  Here's what I found in the gnuradio CMakeCache.txt file:
 
  ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include //Path to a
  library. ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so //Path
  to a library. ICE_ICE:FILEPATH=/usr/lib/libIce.so //Path to a
  library. ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so //Path
  to a library. ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so
  //Path to a library.
  ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so //Path to a
  file. ICE_INCLUDE_DIR:PATH=/usr/include //Path to a library.
  ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so
  //Path to a program.
  ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp //Path to a
  program. ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py //Details
  about finding ICE
 
 
 
 FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()]
 
 
 
 Very Respectfully,
 
  Dan CaJacob
 
 
  And that tells us that GNU Radio is trying to build using the Ice
  libs in /usr/lib, which is where apt-get would have installed
  ICE, so yeah, it's trying to build off Ice 3.4.2.
 
  You could solve this pretty easily by doing an aptitude remove
  libzeroc-ice to get rid of Ice 3.4.2 altogether on your system.
  But I'm more interested in solving this issue in general.
 
  I've brought up a VM that has this behavior. Let me see about
  working out a solution.
 
  Tom
 
 
 
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJS0Dn7AAoJEAFxB7BbsDrLEOwH/RTC+kW1/vgQ6NQxaoTDYFTv
 vxz9B5PbOxocH9/dnINdqtctJw63f/gfIqwUzZK2uuZOJKR1HYbbeIm6diheOexU
 B+KVgGDyMbcCIw2Xioo+B/Gr8b7sQPZjOnJNztg1Se1wpOLPtCcwP6fTv9j6xZog
 olcyQ1cxezRikja/DX/E52DxJ/fVgDawMoR+KoMQOQ4SvL98KiTuD/X6vRuc2TOz
 xt81GwAs6LJh8HVr+kMBXFq1UaN3WxrMPHXtg/db0uxWZXgvKoQYLv6fpCMb+9BZ
 eAXgzDkh1SXyaB9K6G6Q6qTO95el6W/VRDgbRyUC8SvP4IN72i4R+jhG6cwwCKg=
 =M0JC
 -END PGP SIGNATURE-

 ___
 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] Passing a USRP pointer

[Dan CaJacob]

Hey Tom,

We've been working on this, but we ran into a snag.  We couldn't seem to
look up the usrp sink block's key.  Other blocks could be looked up with
the keys we expected, just not the uhd sink.  I just un-commented a print
statement in block_registry.cc so that we could see how each block actually
gets registered, built it and ran a simple flowgraph.

The flowgraph is just a signal source - throttle - uhd sink.  Here's the
output:

register_symbolic_name: top_block0
register_symbolic_name: gr uhd usrp sink0
register_symbolic_name: throttle0
register_symbolic_name: sig_source_c0

The UHD sink block gets an unexpected gr pre-pended and the underscores
are replaced with spaces.

We are going to attempt our OOT blocks with this in mind, but I thought I'd
give you a heads up on this behavior.

Thanks!

Very Respectfully,

Dan CaJacob


On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote:

 On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com
 wrote:
  Hey Tom,
 
  Here's some more detail into our problem.
 
  When running the flowgraph, we get the following error:
 
  File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in
  make
  return _sq_swig.usrp_pa_control_make(*args, **kwargs)
  TypeError: in method 'usrp_pa_control_make', argument 1 of type
  'gr::uhd::usrp_sink::sptr'
 
  When setting up a FG, the pa-control block accepts a reference to the
  downstream UHD sink.
 
  I have attached the specific block source.
 
  Thanks!
 
  Very Respectfully,
 
  Dan CaJacob

 It's probably the difference between a gr::uhd::usrp_sink and a
 gr::uhd::usrp_sink_impl.

 A safer way to handle this might be to use the new(ish) block_registry
 that we implemented to handle the message passing infrastructure. You
 can get a basic_block_sptr from global_block_registry.block_lookup;
 you should then be able to cast this to a usrp_sink_sptr. You'll pass
 it a PMT symbol containing the alias name of the UHD sink itself.

 Take a look at basic_block.cc for a look at how the
 global_block_registry is used. I've not done exactly this before, so
 it might not go completely smoothly, and I'd be interested in your
 experience.

 In general, this sounds like something more appropriately implemented
 as a message, though, but that would mean changing the gr-uhd code.
 Having a message handler for the GPIO stuff would probably be useful
 if done generically enough.

 Tom




  On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com
 wrote:
 
  Thanks Tom,
 
  No problem.  I hope you and the rest of the community had relaxing
  holidays!  I hope to have some better info for you by tomorrow, if not
  before.
 
  Another way to look at this is: does it make sense to keep doing things
  this way?  Is there a better way to reference the downstream USRP and
 toggle
  the IO?  I could imagine an async message stream or specific
 stream-tags,
  but both would probably require changes to the actual UHD sinks.  I'm
 not
  sure our use case is generic enough to warrant that.
 
  Very Respectfully,
 
  Dan CaJacob
 
 
  On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote:
 
  On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com
  wrote:
   We are upgrading some of our custom blocks for 3.7 and have run into
 a
   snag.
   Our 3.6 era blocks included one that PTTed an external amplifier
 based
   on
   stream tags.  The IO was generated from the extra GPIO available on
 the
   WBX.
   One of the inputs to the block was a reference to the USRP sink
   downstream
   in the FG.  The block then calls the necessary methods to enable and
   disable
   the GPIO.  Everything worked nicely, but when we ported our blocks to
   3.87,
   there seemed to be a problem with this.  I did not personally do the
   testing, so I don't have the exact error, but I can probably
 re-create
   it
   given some time.
  
   I started the porting of the blocks myself and did notice that
 getting
   the
   pointer to a USRP object had changed.  But the blocks built without
   error
   when updated appropriately.
  
   Is there anything in principle that would prevent this from working
 in
   3.7?
   Or, is there a better approach to controlling the WBX GPIO based on
   stream
   tags that we should consider?
  
   I apologize for the vagueness on the actual error.  I'll try to
   reproduce it
   myself in the meantime.
  
   I can probably post the code for the PTT-controlling block if that
   would be
   any help.
  
   Very Respectfully,
  
   Dan CaJacob
 
 
  Hi Dan,
 
  Sorry for the silence. Partly due to the holidays, partly due to me
  not having a good answer for you. Most likely, your problem is related
  in some way to the public/private implementations that we are
  enforcing in 3.7 now. If you have more information or have figured
  this out, let us know and we can see where we need to go from here.
 
  Tom

Re: [Discuss-gnuradio] PYBOMBs Testing

[Dan CaJacob]

Thanks, Tom!

Digression warning:
While we're on the topic, I've always wondered if virtualenv would help
with build dependency problems and multiple installed versions (e.g. for
devs).  I have never immersed myself into the tool, but I know that it is
intended for things like this where you want to install specific package
versions for a specific application without affecting other things on your
system.  It's a sandbox, I guess.  What I've never been clear on is whether
it works for C/C++ applications, since it seems to be a python tool.  Do
you have any thoughts on that?

Very Respectfully,

Dan CaJacob


On Fri, Jan 10, 2014 at 10:14 AM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jan 9, 2014 at 12:09 PM, Dan CaJacob dan.caja...@gmail.com
 wrote:
  Hey Tom,
 
  Thanks.  I didn't know how or what to search for, so that was useful.
  Here's the result:
 
  i   libzeroc-ice34 - Ice for C++ runtime
  library

 That there confirms that the Ice 3.4.2 library is installed on your
 system, which is what I was expecting.


   Here's what I found in the gnuradio CMakeCache.txt file:
 
  ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include
  //Path to a library.
  ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so
  //Path to a library.
  ICE_ICE:FILEPATH=/usr/lib/libIce.so
  //Path to a library.
  ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so
  //Path to a library.
  ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so
  //Path to a library.
  ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so
  //Path to a file.
  ICE_INCLUDE_DIR:PATH=/usr/include
  //Path to a library.
  ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so
  //Path to a program.
  ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp
  //Path to a program.
  ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py
  //Details about finding ICE
 
 
 FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()]

  Very Respectfully,
 
  Dan CaJacob


 And that tells us that GNU Radio is trying to build using the Ice libs
 in /usr/lib, which is where apt-get would have installed ICE, so yeah,
 it's trying to build off Ice 3.4.2.

 You could solve this pretty easily by doing an aptitude remove
 libzeroc-ice to get rid of Ice 3.4.2 altogether on your system. But
 I'm more interested in solving this issue in general.

 I've brought up a VM that has this behavior. Let me see about working
 out a solution.

 Tom

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

Re: [Discuss-gnuradio] PYBOMBs Testing

[Dan CaJacob]

Hey guys, thanks for the responses!

I'm running Ubuntu 13.10 x64 and ICE version 3.5.1, I think, based on
pybombs list output:

iceinstalled  inventory f00c59983cc904bca977133c0a9b3e8 wget://
http://www.zeroc.com/download/Ice/3.5/Ice-3.5.1.tar.gz

pybombs did successfully build ice from source.

Very Respectfully,

Dan CaJacob


On Thu, Jan 9, 2014 at 9:29 AM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jan 9, 2014 at 7:15 AM, Martin Braun martin.br...@ettus.com
 wrote:
  On Wed, Jan 08, 2014 at 10:18:20PM -0500, Dan CaJacob wrote:
  OK,
 
  Here's a specific error.  Seems like it's related to ICE, which compiled
  successfully as a dependency.
 
  Dan,
 
  can you please post your exact ICE version as well as other relevant
  system info (distro, version etc.).
 
  MB

 I'll bet I can guess, the relevant parts at least. He's using Ice
 3.4.2 and GCC = 4.7. This is a nasty issue because of the default
 versions of many deb packages that don't actually work together.
 Either updating to Ice 3.5 or downgrading GCC to 4.6 will solve this
 issue. We were hoping for a patch against Ice 3.4.2, but I don't think
 that's going to happen.

 Now, PyBOMBS is set to look for Ice = 3.5, though, so we still need
 more information. My guess is that you have Ice 3.4.2 installed on the
 system already and for some reason, GNU Radio is finding that and not
 3.5, even though the script is supposed to look for 3.5 before
 anything else.

 In a slight look inside the process, I think it's time I do a blunt
 check for the GCC version if Ice 3.4 is found. I was holding off on
 this in hopes that a) it would be fixed in Ice and b) getting the
 compiler version isn't exactly simple. (Cmake does have a variable
 that holds the value of the compiler version, but it's only made
 available in newer versions of cmake, which we are not requiring yet,
 so we can't use it). But since it's only a problem if GCC is used, I
 can parse the version string from it and get the info I need. Much
 better to disable ControlPort in this case than to fail during
 compilation.

 Tom

 ___
 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] PYBOMBs Testing

[Dan CaJacob]

Hey Tom,

Thanks.  I didn't know how or what to search for, so that was useful.
 Here's the result:

p   kde-zeroconf   - zeroconf plugins and kio
 slaves for KDE
 p   kde-zeroconf:i386  - zeroconf plugins and kio
 slaves for KDE
 p   kde-zeroconf-dbg   - debug symbols for
 kde-zeroconf
 p   kde-zeroconf-dbg:i386  - debug symbols for
 kde-zeroconf
 p   libmono-zeroconf-cil-dev   - CLI library for multicast
 DNS service discovery
 p   libmono-zeroconf1.0-cil- CLI library for multicast
 DNS service discovery
 p   libqxt-zeroconf0   - library to use multicast
 DNS service discovery in Qt
 p   libqxt-zeroconf0:i386  - library to use multicast
 DNS service discovery in Qt
 v   libzeroc-ice-dev   -

 v   libzeroc-ice-dev:i386  -

 p   libzeroc-ice-ruby1.8   - Ice for Ruby modules

 p   libzeroc-ice-ruby1.8:i386  - Ice for Ruby modules

 p   libzeroc-ice3.4-cil- Ice for C# libraries

 p   libzeroc-ice3.4-java   - Ice for Java libraries

 i   libzeroc-ice34 - Ice for C++ runtime
 library
 p   libzeroc-ice34:i386- Ice for C++ runtime
 library
 i A libzeroc-ice34-dbg - Ice for C++ debugging
 symbols
 p   libzeroc-ice34-dbg:i386- Ice for C++ debugging
 symbols
 i   libzeroc-ice34-dev - Ice for C++ development
 libraries
 p   libzeroc-ice34-dev:i386- Ice for C++ development
 libraries
 p   monodoc-mono-zeroconf-manual   - compiled XML
 documentation for mono-zeroconf
 p   php-zeroc-ice  - Ice for PHP extension

 p   php-zeroc-ice:i386 - Ice for PHP extension

 p   pulseaudio-module-zeroconf - Zeroconf module for
 PulseAudio sound server
 p   pulseaudio-module-zeroconf:i386- Zeroconf module for
 PulseAudio sound server
 p   pulseaudio-module-zeroconf-dbg - Zeroconf module for
 PulseAudio sound server (debuggin
 p   pulseaudio-module-zeroconf-dbg:i386- Zeroconf module for
 PulseAudio sound server (debuggin
 i   python-zeroc-ice   - Ice for Python libraries

 p   python-zeroc-ice:i386  - Ice for Python libraries

 v   python2.7-zeroc-ice-

 v   python2.7-zeroc-ice:i386   -

 v   zeroc-ice  -

 p   zeroc-ice-manual   - Ice documentation in pdf

 p   zeroc-ice34- Internet Communications
 Engine
 p   zeroc-icee - Embedded edition of the
 ZeroC Ice


 Here's what I found in the gnuradio CMakeCache.txt file:

ICE_CONFIG_INCLUDE_DIR:PATH=/usr/include
 //Path to a library.
 ICE_GLACIER2:FILEPATH=/usr/lib/libGlacier2.so
 //Path to a library.
 ICE_ICE:FILEPATH=/usr/lib/libIce.so
 //Path to a library.
 ICE_ICEGRID:FILEPATH=/usr/lib/libIceGrid.so
 //Path to a library.
 ICE_ICESTORM:FILEPATH=/usr/lib/libIceStorm.so
 //Path to a library.
 ICE_ICEUTIL:FILEPATH=/usr/lib/libIceUtil.so
 //Path to a file.
 ICE_INCLUDE_DIR:PATH=/usr/include
 //Path to a library.
 ICE_PTHREAD:FILEPATH=/usr/lib/x86_64-linux-gnu/libpthread.so
 //Path to a program.
 ICE_SLICE2CPP:FILEPATH=/usr/bin/slice2cpp
 //Path to a program.
 ICE_SLICE2PY:FILEPATH=/usr/bin/slice2py
 //Details about finding ICE

 FIND_PACKAGE_MESSAGE_DETAILS_ICE:INTERNAL=[/usr/lib/libIce.so;/usr/lib/libIceUtil.so][/usr/include][v()]
 //ADVANCED property for variable: ICE_INCLUDE_DIR
 ICE_INCLUDE_DIR-ADVANCED:INTERNAL=1
 PC_ICE_CFLAGS:INTERNAL=
 PC_ICE_CFLAGS_I:INTERNAL=
 PC_ICE_CFLAGS_OTHER:INTERNAL=
 PC_ICE_FOUND:INTERNAL=
 PC_ICE_INCLUDEDIR:INTERNAL=
 PC_ICE_Ice-3.5_INCLUDEDIR:INTERNAL=
 PC_ICE_Ice-3.5_LIBDIR:INTERNAL=
 PC_ICE_Ice-3.5_PREFIX:INTERNAL=
 PC_ICE_Ice-3.5_VERSION:INTERNAL=
 PC_ICE_LIBDIR:INTERNAL=
 PC_ICE_LIBS:INTERNAL=
 PC_ICE_LIBS_L:INTERNAL=
 PC_ICE_LIBS_OTHER:INTERNAL=
 PC_ICE_LIBS_PATHS:INTERNAL=
 PC_ICE_PREFIX:INTERNAL=
 PC_ICE_STATIC_CFLAGS:INTERNAL=
 PC_ICE_STATIC_CFLAGS_I:INTERNAL=
 PC_ICE_STATIC_CFLAGS_OTHER:INTERNAL=
 PC_ICE_STATIC_LIBDIR:INTERNAL=
 PC_ICE_STATIC_LIBS:INTERNAL=
 PC_ICE_STATIC_LIBS_L:INTERNAL=
 PC_ICE_STATIC_LIBS_OTHER:INTERNAL=
 PC_ICE_STATIC_LIBS_PATHS:INTERNAL=
 PC_ICE_VERSION:INTERNAL=
 __pkg_config_checked_PC_ICE:INTERNAL=1



Very Respectfully,

Dan CaJacob


On Thu, Jan 9, 2014 at 11:22 AM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jan 9, 2014 at 10:44 AM, Dan CaJacob dan.caja...@gmail.com
 wrote:
  Hey guys, thanks for the responses!
 
  I'm running Ubuntu 13.10 x64 and ICE version 3.5.1, I think, based on
  pybombs list output:
 
  iceinstalled  inventory f00c59983cc904bca977133c0a9b3e8