Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Geof,

thanks for the suggestions.

I get the same problem even when i run volk_profile.exe
which means that the problem is pretty basic...

Anyway after searching around on the web i see that everyone suggests a
different thing so most probably no one knows what the real issue is...

I am giving up on that for now...

thank you,
Achilleas



On Mon, Apr 18, 2016 at 12:46 PM, Geof Nieboer 
wrote:

> No that should be it.  I just doublechecked on my plain vanilla Win7 VM
> that it worked and that VM has nothing installed but SP1 and security
> updates.
>
> OK... let's try this... go to the GR python prompt and try to import
> different gnuradio libraries and see if maybe we can find a pattern?  I.E.
> from gnuradio import fft
> from gnuradio import audio
> from gnuradio import wxgui
> {keep going}
>
>
>
> On Mon, Apr 18, 2016 at 6:45 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Geof,
>>
>> thanks again for your help.
>> Indeed I am running SP1.
>>
>> Here is what I have on my computer at this point:
>> I have a bunch of applications (seen in the control
>> panel/Programs/Programs and Features)
>> named:
>>
>> Microsoft Visual C++ 2005 Redistributable (x64)
>> Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022
>> Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161
>> Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
>> Microsoft Visual Studio 2010 Tools for Office Runtime (x64)
>>
>> I just downloaded and installed the following
>>
>> Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026
>> Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.23026
>>
>>
>> but i get the same error.
>> Is there anything else that is required?
>>
>> thanks
>> Achilleas
>>
>>
>>
>>
>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CT1FFU converter with RTL-SDR and gqrx

[Daniel Pocock]

On 18/04/16 22:32, Ron Economos wrote:
> There's a high pass filter on the output that is designed to pass
> frequencies above 150 MHz. If the LO is only 40 MHz, the high pass
> filter will greatly attenuate the entire HF band.
> 

That had occurred to me as well, although I notice they are now offering
a 65.52 MHz LO[1] and their full SDR receiver box does advertise having
a 40 MHz LO, so I presume they have to adjust the high pass filter for
those models.  The 40 MHz signal comes through quite strongly and is
detected by the RTL-SDR.

I sent them an email earlier today, I'll see how they respond, maybe it
was just a manufacturing issue.


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

Re: [Discuss-gnuradio] BER & constellation plot for OFDM transmit/receive

[Jingyi Sun]

We are not compensating for any lost packets, although we would be aware of
them thanks to the packet number. Could you tell us if there’s a block to
do this, or would we need a custom block?


Also, could you tell us why the constellation diagram is not displaying
properly?


Thanks,

Jenny



On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun 
wrote:

> Are you comparing the correct packets? E.g., if packets get lost, do you
> take that into account?
>
> M
>
> On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> > Hi everyone,
> >
> > We are working on an experiment for a conference paper deadline in two
> > weeks, and need to transmit and receive OFDM packets and want to study
> > the constellation diagram and BER.
> >
> > I put together a flow graph consisting of an *OFDM transmitter block*
> > and an *unpacked OFDM receiver* based on the online example rx_ofdm.grc.
> > Here's how I'm trying to measure constellation diagram and BER:
> >
> >   * I inserted a QT constellation sink right before the constellation
> > decoder on the payload IQ stream, but it does not seem to output
> > anything meaningful. The plot just shows single, clean points, which
> > I am pretty sure does not correspond to real data. I suspect that
> > the plots are not triggering properly, but am not sure.
> >
> >   * For BER, we tried several different configurations, and they mostly
> > give BER = 0.5 (i.e. random).  Our leading theory is that we're not
> > comparing the data at the correct points in the flow graph. Any
> > suggestions as to what the BER inputs should be would be helpful.
> >
> > We've been running some diagnostics that seem to eliminate our
> > communication channel as the problem:
> >
> >   * We are transmitting the data over-the-air at 915 MHz using
> > two omnidirectional antennas, placed roughly 1 meter apart. The
> > output spectra at the transmitter output and receiver input are
> > attached - all signals are comfortably above the noise floor.
> >   * From the tag debug output, we see that the OFDM packet headers are
> > being received. For example, we can see when the packets are
> > received, the packet numbers, as well as the channel estimation tap
> > values. We take this to mean that we are receiving data
> > successfully, and that our difficulties regarding BER and
> > constellation diagram are something we're executing incorrectly in
> > the software.
> >
> >
> > The relevant annotated GRC block diagrams are attached.
> >
> > Thanks so much,
> > Jenny
> >
> >
> > ___
> > 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] CT1FFU converter with RTL-SDR and gqrx

[Ron Economos]

There's a high pass filter on the output that is designed to pass 
frequencies above 150 MHz. If the LO is only 40 MHz, the high pass 
filter will greatly attenuate the entire HF band.


Ron

On 04/18/2016 11:12 AM, Daniel Pocock wrote:


After looking at the different upconverters, I decided to try the CT1FFU
device[1] first.

The marketing says it is available with either 106.25 MHz or 65.520 MHz
LO.  The manual[2] only mentions a 106.25 MHz LO

I was initially using the offset -106.25 in the gqrx configuration.  I
wasn't receiving anything, so I started to investigate:

- the RTL-SDR doesn't see anything on 106.25

- the upconverter I received has a 40 MHz oscillator on the board in the
same place as the 106.25 oscillator in the photo

- the RTL-SDR detects the 40 MHz signal and if I pull the power from the
upconverter, the 40 MHz signal disappears

Using -40.0 MHz in the gqrx config, I still don't find anything on HF though

Are there any known issues with gqrx or GNU Radio in general with this
type of setup?

Is it necessary to add band pass filters or LNAs with the upconverters
or should they work standalone?

Can anybody make any other comments on testing it further?


1.
http://www.rtl-sdr.com/version-5-0-of-the-ct1ffu-upconverter-now-available/
2. http://www.ct1ffu.com/site/images/stories/FCD5a.pdf

___
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] costas ambiguity and correlate-and-sync block in qpsk

[Andy Walls]

On Mon, 2016-04-18 at 00:44 +, Landsman, Arik wrote:
> So the generic_mod() shifts the expected output by 50 samples to the right, 
> thus dropping 50 samples off the end. with this in mind, generating *two* 
> modulated vectors should do the trick: 
> 
> - generate an untrimmed sequence 2 preambles long (seq1)
> - generate another sequence 3 preambles long (seq2)
> - samples_per_preamble = (preamble_length_bytes * [8*2/mod_order] * sps) 
> #[8*2/mod_order] is the symbols_per_byte  for a given mod_order
> - in seq2, start_of_preamble = len(seq1) + 
> - in seq2, end_of_preamble = len(seq1) + samples_per_preamble +  in generic_mod>
> - lost_samples = seq1 - 2 * samples_per_preamble   #remainder after 
> subtracting all preamble lengths from seq1
> 
> this works, at least manually, and should be generic enough to work for all 
> cases, e.g. mod orders, preamble lengths, etc and regardless of the inner 
> workings of generic_mod (which is good in case it gets changed). 

Hi Arik:

Glad you found a way to make things easier.  Be advised that other
modulators (e.g. GFSK_mod, GMSK_mod) probably have different properties,
so what you've come up with may only work for QAM and PSK modulations
using generic_mod. 

Regards,
Andy

> Just need to python it into the Rx in a neat way.


> 
> 
> 
> 
> 
> From: Landsman, Arik
> Sent: Sunday, April 17, 2016 7:44 PM
> To: Andy Walls
> Cc: discuss-gnuradio@gnu.org; t...@trondeau.com
> Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> Hi Andy,
> 
> Just a quick update - I changed sps from 10 to 5 to repeat your trimming 
> procedure. Works like a charm. Certainly clear why you picked the 2nd 
> preamble copy and not the 1st..
> 
> as expected correlation is not as strong with decreasing sps (assuming unmod 
> preamble stays same size).
> 
> Looks like it is possible to come up with an "auto-trimming" algorithm after 
> all. if the number of lost samples (distorted, nulled, etc) is a function of 
> sps, modulation order, and preamble length (and lost samples in 
> digital.generic_mod that I guess just don't get shifted out), then exact 
> placement can be calculated based on these parameters alone and some initial 
> experimentation.
> 
> i'll try experimenting, lets see if this holds :)
> 
> Best Regards,
> Arik
> 
> 
> 
> From: Landsman, Arik
> Sent: Sunday, April 10, 2016 4:25 PM
> To: Andy Walls
> Cc: discuss-gnuradio@gnu.org; t...@trondeau.com
> Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> Hi Andy,
> 
> Sorry for delayed response, the weekend finally arrived.. added some comments 
> inline below. Your comments on zero-IF receiving are well taken - going to 
> try a low-IF approach instead. This maybe the source of some phase noise 
> issues I had on the hardware last night. Using the USRP N210 btw.
> 
> Overall, the aim in this case, at least for now, is three-fold:
> 
> - design / fine tune a QPSK Rx capable of performance similar to a 
> diff-encoded Rx. Thus, at low SNR we could use non-diff and at higher SNR use 
> diff encoding. Or possibly just non-diff if the latter outperforms.
> - implement it as a testbed for encoding/networking algorithms for 
> heterogeneous networking (big topic for 5G). Not an expert in networking, but 
> we have RA's devoted to the topic. So ultimately the Tx-Rx network should 
> work reliably enough to allow performance testing their algorithms without 
> hardware bottlenecking the performance.
> - on the personal front I am here for the long howl, as the topic is of 
> personal interest. And contribute back into gnu-radio. Looks like this 
> flowgraph is going in the "psk mod" footsteps as a non diff-encoding 
> implementation. so if it appears feasible to create a python wrapper and a 
> block i'll certainly start there. the big hurdle is the hand-tuning the 
> corr_est block, which I'm going to contemplate a way to auto-cal it.
> 
> Best Regards,
> Arik
> 
> 
>  Andy Walls [a...@silverblocksystems.net]
> Sent: Tuesday, April 05, 2016 7:23 PM
> To: Landsman, Arik
> Cc: discuss-gnuradio@gnu.org; t...@trondeau.com
> Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> On Tue, 2016-04-05 at 00:00 +, Landsman, Arik wrote:
> > Hi Andy,
> >
> > Added a few comments inline (marked with "==" in lieu of a better email 
> > client)..
> >
> > But overall corr_est works very consistently. I did have a few observations:
> 
> Hi Arik:
> 
> For my responses to the next two, I'm assuming that ultimately you'll be
> working with a radio modem that sends bursts of energy and then cuts off
> RF energy.   And that yoHi Andy,
> 
> Sorry for delayed response, the weekend finally arrived.. added some comments 
> inline below. Your comments on zero-IF receiving are well taken - going to 
> try a low-IF approach instead. This maybe the 

[Discuss-gnuradio] CT1FFU converter with RTL-SDR and gqrx

[Daniel Pocock]

After looking at the different upconverters, I decided to try the CT1FFU
device[1] first.

The marketing says it is available with either 106.25 MHz or 65.520 MHz
LO.  The manual[2] only mentions a 106.25 MHz LO

I was initially using the offset -106.25 in the gqrx configuration.  I
wasn't receiving anything, so I started to investigate:

- the RTL-SDR doesn't see anything on 106.25

- the upconverter I received has a 40 MHz oscillator on the board in the
same place as the 106.25 oscillator in the photo

- the RTL-SDR detects the 40 MHz signal and if I pull the power from the
upconverter, the 40 MHz signal disappears

Using -40.0 MHz in the gqrx config, I still don't find anything on HF though

Are there any known issues with gqrx or GNU Radio in general with this
type of setup?

Is it necessary to add band pass filters or LNAs with the upconverters
or should they work standalone?

Can anybody make any other comments on testing it further?


1.
http://www.rtl-sdr.com/version-5-0-of-the-ct1ffu-upconverter-now-available/
2. http://www.ct1ffu.com/site/images/stories/FCD5a.pdf

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

Re: [Discuss-gnuradio] UHD clock rate in the usrp e310 - release 4

[Martin Braun]

Gabriel,

I didn't realize you were also tx'ing. You won't be able to go to an
interpolation of 1024 on the Tx side.

M

On 04/16/2016 09:37 AM, Gabriel Pechiarovich wrote:
> Hi I just tried your suggestion and it was ok for the RX side, but in
> the Tx side the decimation wont go up to 1024, it only decimates up to 512, 
> 
> -- Asking for clock rate 16.384 MHz
> -- Actually got clock rate 16.384 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> 
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 0.016000 MSps
> Actual sample rate: 0.032000 MSps
> 
> so is this locked for security or something, or the hardware simple
> doesn't have the capabilities?
> 
> 
> 
> 2016-04-07 5:33 GMT+00:00 Martin Braun  >:
> 
> On 04/06/2016 10:26 PM, Martin Braun wrote:
> > On the release 4 image, you can't do that. But you can set the clock to
> > 16 MHz and use a decimation of 1000. Or you can use a clock rate of
> > 16384e3 and a decimation of 1024, for a better decimation filter 
> response.
> 
> ...they'll probably be about the same, as the same number of halfbands
> will be active. But the point is, you can't go below 10 MHz MCR on
> release 4, and not above decimation 1024.
> 
> Cheers,
> M
> >
> > Cheers,
> > Martin
> >
> > On 04/06/2016 06:11 PM, Gabriel Pechiarovich wrote:
> >> Hi, thanks for your answeri wasn't able to answer earlier.
> >>
> >> I was aiming to a 8MHz clock rate in order to use the DDC and get a
> >> 16000 sample rate.
> >> So i think i was misunderstood.
> >>
> >> Thank you very much
> >> Gabriel
> >>
> >>
> >> 2016-03-31 13:25 GMT-05:00 Martin Braun  
> >> >>:
> >>
> >> On the release 4 image, you can't set the clock speed under
> 10 MHz.
> >> However, you can use a DDC (which is built in and
> automatically used).
> >> Simply set the clock rate to 32 MHz (or 16 MHz if this is
> MIMO) and the
> >> sample rate to 8 MHz.
> >>
> >> Cheers,
> >> Martin
> >>
> >> On 03/30/2016 05:02 PM, Gabriel Pechiarovich wrote:
> >> > Hi all,
> >> > I've developed a flowgraph wich includes  a qpsk modulator
> and and
> >> audio
> >> > encoder, I used to run it in the E310 using the first release
> >> > (http://files.ettus.com/e3xx_images/e3xx-release-001/) and now
> >> trying to
> >> > use the release 4.
> >> >
> >> > The problem is:
> >> > in the UHD sink and source the clock rate was set to 8e6
> Hz, and it
> >> > worked fine, in the release 1, but in the relese 4 the
> Clock rate wont
> >> > go lower than 10e6 Hz, so i cant archive the same results.
> >> >
> >> > Any idea how to force the use of 8MHz as the clock rate
> using the
> >> release4
> >> >
> >> > Thank you very much
> >> > Gabriel Pechiarovich Salas
> >> >
> >> >
> >> >
> >> > ___
> >> > 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
> >>
> >>
> >>
> >>
> >> --
> >> Gabriel Pechiarovich Salas
> >> Red Dragon Games
> >> Designers and game developers
> >
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> -- 
> Gabriel Pechiarovich Salas
> Red Dragon Games
> Designers and game developers


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

Re: [Discuss-gnuradio] BER & constellation plot for OFDM transmit/receive

[Martin Braun]

Are you comparing the correct packets? E.g., if packets get lost, do you
take that into account?

M

On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> Hi everyone,
> 
> We are working on an experiment for a conference paper deadline in two
> weeks, and need to transmit and receive OFDM packets and want to study
> the constellation diagram and BER. 
> 
> I put together a flow graph consisting of an *OFDM transmitter block*
> and an *unpacked OFDM receiver* based on the online example rx_ofdm.grc.
> Here's how I'm trying to measure constellation diagram and BER:
> 
>   * I inserted a QT constellation sink right before the constellation
> decoder on the payload IQ stream, but it does not seem to output
> anything meaningful. The plot just shows single, clean points, which
> I am pretty sure does not correspond to real data. I suspect that
> the plots are not triggering properly, but am not sure. 
> 
>   * For BER, we tried several different configurations, and they mostly
> give BER = 0.5 (i.e. random).  Our leading theory is that we're not
> comparing the data at the correct points in the flow graph. Any
> suggestions as to what the BER inputs should be would be helpful.
> 
> We've been running some diagnostics that seem to eliminate our
> communication channel as the problem:
> 
>   * We are transmitting the data over-the-air at 915 MHz using
> two omnidirectional antennas, placed roughly 1 meter apart. The
> output spectra at the transmitter output and receiver input are
> attached - all signals are comfortably above the noise floor. 
>   * From the tag debug output, we see that the OFDM packet headers are
> being received. For example, we can see when the packets are
> received, the packet numbers, as well as the channel estimation tap
> values. We take this to mean that we are receiving data
> successfully, and that our difficulties regarding BER and
> constellation diagram are something we're executing incorrectly in
> the software. 
> 
> 
> The relevant annotated GRC block diagrams are attached.
> 
> Thanks so much,
> Jenny
> 
> 
> ___
> 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] Feedback with Transmitters and Receiver

[Martin Braun]

Pavan,

this is still a pretty generic scenario. I'll be able to help you with
specific questions on UHD usage etc., so if you break it down you'll get
some better answers.

Cheers,
Martin

On 04/17/2016 10:02 PM, Pavan Yedavalli wrote:
> Hi Martin,
> 
> Thank you again for getting back to me. Let me elaborate on the process
> that I am doing, and hopefully what I need will be clarified.
> 
> I have two USRPs connected via MIMO cable that are transmitting a sin
> wave and one USRP receiving that sin wave.
> 
> I am trying to implement a system in which I determine the power of the
> received signal, feed it back to the transmitters, adjust weights that
> I'm multiplying the transmitted signals by (according to some
> algorithm), and then send again to the receiver, and this goes on for a
> certain number of iterations.
> 
> The problem I am having is that I have no idea how to make sure that the
> received signal is the one that I am transmitting with my correct
> weights. In other words, I want to turn that receiver on only for it to
> receive my signal that I transmitted, then turn it off again as I adjust
> the weights, and then transmit again, and have it receive again. So,
> it's basically a full feedback loop that is sequential: transmit new
> signal, receive that signal, send back some information about that,
> transmit new signal, receive that signal, etc.
> 
> I still feel like I'm not able to describe this articulately, so please
> keep me posted. I am a bit unclear on how the rx_time could work in this
> above scenario. Thank you so much again!
> 
> 
> 
> -- 
> Pavan
> 
> 
> ___
> 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] Synced MIMO cable clock of both boards changes at every call to tb.start()?

[Martin Braun]

On 04/17/2016 06:53 PM, Pavan Yedavalli wrote:
> Hi Martin,
> 
> Thank you for getting back to me. I'm still a bit confused though. You
> are saying that I need to call set_time_now() or set_time_unknown_pps()
> to sync the clocks? So, simply connecting the MIMO cable between the two
> USRPs is not sufficient for the clocks to be synced?
> 
> And as far as the start() function is concerned, you are saying that
> calling it constantly will NOT reinitialize the clock? Is that correct? 

Yes.

> My concern is that I have a while loop in which I call tb.start() in
> every iteration, and I want to make sure that the random phase offset
> between the two boards that is generated (MIMO cable between the two)
> stays the same through these iterations. 

Which daughterboards do you have?

M
> 
> Please keep me posted! Thank you.
> 
> 
> 
> -- 
> Pavan
> 
> 
> ___
> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

You can run powershell in VS? Neat. I've been doing it all in the
powershell terminal, (and I fell back to a cygwin terminal when I had
a moment of weakness trying to tail -f something and not wanting to
type gc -wai -ta1 ) To be honest I haven't even opened VS.
However, when in Rome...lets see, I had to install an extension, also
found they have a vim extension. Tab completion is nice. Will try
this.

Yeah I saw that in the comment at the top of the script. For debugging
I actually copied the Python script and removed all the other sections
but wx, because you weren't kidding about it taking a while. I guess
from what I read nmake doesn't do parallel builds. Shame. Looks like 4
and 5 completed successfully though.


So on step 6... ran into:
"glfw...shallow cloned
cloning GNURadio...fatal: Not a git repository (or any of the parent
directories): .git
fatal: Not a git repository (or any of the parent directories): .git
complete"

Cryptic. Anywho. Log:
"Submodule 'volk' (https://github.com/gnuradio/volk.git) registered
for path 'volk'
Cloning into 'volk'...
error: no such remote ref fcfc49dbb6e1e861c4fbdb02502bf18599b2fd0c
Fetched in submodule path 'volk', but it did not contain
fcfc49dbb6e1e861c4fbdb02502bf18599b2fd0c. Direct fetching of that
commit failed."

Its odd, I can get to that path on github,
https://github.com/gnuradio/volk/tree/fcfc49dbb6e1e861c4fbdb02502bf18599b2fd0c
but it doesn't show up in git log, and wont work in git checkout. It
looks like this commit's parent was merged by Nathan West on Jan 29.
Perhaps he squashed the commit somehow when he did the merge? The code
changes in that commit do appear to be in place in maint. Anyway, I'll
pick this up tonight, but I'll probably just checkout the latest, or
at least your latest commit from maint and build with that, assuming
that you will eventually point the submodule to a newer commit anyway
as this seems to be just a git issue.

-Anon

On Apr 18, 2016 10:11 AM, "Geof Nieboer"  wrote:
>
> Good news.  The out-file fix must have missed a commit somehow, I distinctly 
> remember making and fixing that.  Oh well, thanks.
> The other is interesting, I'm not sure why it worked on mine then.  I'm 
> already patching that file to recognize VC14, so just need to amend the patch.
>
> As you continue to experiment, in case you haven't already figured it out, 
> once you open the scripts project the first time in VS 2015, just run 
> Setup.ps1 once to set the environment, then you can run any of the scripts 
> individually, and by setting the $configuration variable (shortcuts at bottom 
> of several scripts) you can usually just run any individual "sub-build" on 
> it's own to save time and incrementally move forward.  But it looks like 
> you've already gotten past the toughest part, so that's excellent..
>
> On Mon, Apr 18, 2016 at 2:27 PM, Anon Lister  wrote:
>>
>> Aha. Found the error. I don't know how you didn't encounter it in your
>> builds, but in the build-wxpython.py script, line 443 fails, it's up
>> in the log. It sets install_dir to some variables defined in a if not
>> windows block higher up. This causes the script to bomb at install due
>> to an undefined variable. I just set install_dir to "" and validate
>> was successful.
>>
>> Thanks for the tip on looking for the _core_.pyd, that's what lead me
>> to it, it wasn't present anywhere but in the build directory (and a
>> few other places on my box, but all from timestamps way before the
>> build). Anyway, that step of the script is rebuilding now, just to be
>> sure it works.
>>
>> I dug into the Step5-consolidation error a bit, it looks like its failing 
>> with
>>
>> "Consolidating Qt...Out-File : A parameter cannot be found that
>> matches parameter name 'path'.
>> At C:\gr-build\scripts\Step5-ConsolidateLibs.ps1:67 char:23
>> + "[Paths]" | out-file -path $root/build/$configuration/bin/qt.conf ...
>> +  ~
>> + CategoryInfo  : InvalidArgument: (:) [Out-File],
>> ParentContainsErrorRecordException
>> + FullyQualifiedErrorId :
>> NamedParameterNotFound,Microsoft.PowerShell.Commands.OutFileCommand"
>>
>> According to [1] out-file accepts -FilePath as an option. I switched
>> to that (actually just ran that line on console) and it seemed to
>> work, so that one may be an easy fix. I'll kick it off once the python
>> builds finish. Probably wont get back to it till tonight.
>>
>> Yeah my goal here is mainly to reproduce the build, (and use it as a
>> motivating project to learn a little powershell), then hopefully
>> contribute to getting my favorite OOT's building. So no taking the
>> cheap route. :) I'm still amazed you got all this stuff building on
>> windows, most of it is a pain to build even on its native platform.
>> heh.
>>
>> -Anon
>>
>>
>> [1] https://technet.microsoft.com/en-us/library/hh849882.aspx
>>
>> On Apr 18, 2016 4:02 AM, "Geof Nieboer"  wrote:
>> >
>> 

Re: [Discuss-gnuradio] Overflow error in benchmark receiver side "DDDD"

[monika bansal]

Hi Marcus,

Exact model is RTL8111/8168/8411 and vendor is Realtek Semiconductor Co.,
ltd.
OS: Ubuntu 14.04

Regards,
Monika

On Sat, Apr 16, 2016 at 10:27 PM, Marcus Müller 
wrote:

> Hm, those are usually good. What's the exact model ("lspci" will tell)?
> What's your OS?
>
>
>
> On 16.04.2016 18:10, monika bansal wrote:
>
> Hi Marcus
>
> The network card is PCI Express Gigabit Ethernet Controller with 1Gbps
> capacity.
>
> Thanks,
> Monika
>
> On Fri, Apr 15, 2016 at 6:38 PM, Marcus Müller 
> wrote:
>
>> No harm done :) So the point is that  is still pretty bad, and
>> usually shouldn't happen, unless your PC is *much* too slow, and usually
>> would be preceeded by a couple of "O".
>> There's two cases where this doesn't happen:
>> * Too small network buffers
>> * strangely misbehaving network hardware.
>>
>> So: what is your network card?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 15.04.2016 14:32, monika bansal wrote:
>>
>> Yes my mistake :). Sorry for that. I just did not think of the python
>> block at that time and then after i realized.
>>
>> Regards,
>> Monika
>>
>> On Fri, Apr 15, 2016 at 5:17 PM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Monika,
>>>
>>> no offense, but when you report a problem with software, it's pretty
>>> crucial you point out whether you've modified the software or not :)
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 15.04.2016 06:28, monika bansal wrote:
>>>
>>> Hii,
>>>
>>> Thank you for your help.
>>> That "" issue is not coming with original benchmark files.
>>> I added one python block in between the chain in benchmark code. I think
>>> due to which it was not fast enough to process the incoming data resulting
>>> "" issue.
>>>
>>> Regards,
>>> Monika
>>>
>>> On Tue, Apr 5, 2016 at 11:51 PM, < mle...@ripnet.com>
>>> wrote:
>>>
 What if you make the file "/dev/null" -- does this still happen?






 On 2016-04-05 14:12, monika bansal wrote:

 Hii,

 I am running benchmark code and on the receiver side after receiving
 some number of packets(8000 so), it starts showing overflow errors ("")
 on terminal.
 Following is the system configuration

 python benchmark_rx.py -f 1100M --args "addr=10.32.38.163"
 --to-file=/home/ashokbandi/GNU/a_rx.txt --bandwidth=50

 Decreasing the bandwidth delays the error.

 I tried changing buffer size by setting net.core.rmem_max and
 net.core.wmem_max to 33445532 but to no avail.


 Following is the screen shot of terminal

 DDok: True  pktno: 24116  n_rcvd: 9730  n_right: 9723
 ok: True  pktno: 24182  n_rcvd: 9731  n_right: 9724
 DDok: True  pktno: 24319  n_rcvd: 9732
  n_right: 9725
 ok: True  pktno: 24442  n_rcvd: 9733
  n_right: 9726
 DDDok: True  pktno: 24477  n_rcvd: 9734  n_right: 9727
 Dok: True  pktno: 24568  n_rcvd: 9735  n_right: 9728
 Dok:
 False  pktno: 22729  n_rcvd: 9736  n_right: 9728


 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

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Geof Nieboer]

No that should be it.  I just doublechecked on my plain vanilla Win7 VM
that it worked and that VM has nothing installed but SP1 and security
updates.

OK... let's try this... go to the GR python prompt and try to import
different gnuradio libraries and see if maybe we can find a pattern?  I.E.
from gnuradio import fft
from gnuradio import audio
from gnuradio import wxgui
{keep going}



On Mon, Apr 18, 2016 at 6:45 PM, Achilleas Anastasopoulos  wrote:

> Geof,
>
> thanks again for your help.
> Indeed I am running SP1.
>
> Here is what I have on my computer at this point:
> I have a bunch of applications (seen in the control
> panel/Programs/Programs and Features)
> named:
>
> Microsoft Visual C++ 2005 Redistributable (x64)
> Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022
> Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161
> Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
> Microsoft Visual Studio 2010 Tools for Office Runtime (x64)
>
> I just downloaded and installed the following
>
> Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026
> Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.23026
>
>
> but i get the same error.
> Is there anything else that is required?
>
> thanks
> Achilleas
>
>
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Geof,

thanks again for your help.
Indeed I am running SP1.

Here is what I have on my computer at this point:
I have a bunch of applications (seen in the control panel/Programs/Programs
and Features)
named:

Microsoft Visual C++ 2005 Redistributable (x64)
Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022
Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161
Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
Microsoft Visual Studio 2010 Tools for Office Runtime (x64)

I just downloaded and installed the following

Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026
Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.23026


but i get the same error.
Is there anything else that is required?

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

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[West, Nathan]

On Mon, Apr 18, 2016 at 3:27 AM, Douglas Geiger <
doug.gei...@bioradiation.net> wrote:

> I know I'm a little late to this party, but I thought I'd point this out:
> the output "VOLK: Error allocating memory (posix_memalign: 22)" suggests
> you are running into this known issue:
> http://gnuradio.org/redmine/issues/692
>
> If this is indeed a rPi Rev B, then this is the known/old issue of
> volk_get_alignment() returning a value on 1 on that arch, which then breaks
> posix_memalign. I believe this has been fixed in more recent releases, so
> perhaps jessie-backports can help you there?
>

Indeed.
https://github.com/gnuradio/volk/commit/cc1abd2ea27c7f303efaa6466e97970915ed
has been in VOLK since before v1.0


>
>  Good luck,
>   Doug
>
> On Wed, Apr 13, 2016 at 4:45 AM, Rob Roschewsk  wrote:
>
>> Marcus,
>>
>> Thanks for responding.
>>
>> I'm looking to build a headless FM receiver to record and stream public
>> service communication (fire, police, etc.). We will stream as many channels
>> as possible that fall into a given passband.
>>
>> I already have a system running on a PC and now would like to port it to
>> the PI.
>>
>> I understand it maybe an "up hill" path, but the thought is to deploy
>> multiple inexpensive units around a geographic area all feeding a central
>> streaming server.
>>
>> The Pi is running Raspian Jesse  I started with the distribution
>> packages but ran into problems right out of the blocks and thought it would
>> be best to use the latest code before asking questions :)
>>
>> I understand cross compiling is the way to go.
>>
>> Since I brought it up, here was the error I saw when I tried to run the
>> script that runs on the PC but fails spectacularly on the raspberry pi with
>> the precompiled packages 
>>
>> roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py -s 49 noaa.xml
>> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0
>> <0030070030>-unknown
>>
>> high=16250 low=16240 span=10
>> center=16245
>> gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
>> bladerf rfspace airspy
>> Using device #0 Realtek RTL2838UHIDIR SN: 0108
>> Found Elonics E4000 tuner
>> Exact sample rate is: 100.026491 Hz
>> Using Volk machine: generic_orc
>> VOLK: Error allocating memory (posix_memalign: 22)
>> VOLK: Error allocating memory (posix_memalign: 22)
>> VOLK: Error allocating memory (posix_memalign: 22)
>> Segmentation fault
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Doug Geiger
> doug.gei...@bioradiation.net
>
> ___
> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Geof Nieboer]

Unfortunately, DCOMP.DLL is probably not causing your problem, as it's
being linked from a system library, not yours.

(re)install the VC14 redistributeable package above and then give it a
second shot.  Are you running Service Pack 1?

On Mon, Apr 18, 2016 at 4:16 PM, Achilleas Anastasopoulos  wrote:

> I have resolved one out of two issues.
> The problem with IESHIMS.DLL is resolved (it is in the internet explorer
> directory and all i needed was to add this to the path).
>
> Still don't know how to resolve the DCOMP.DLL issue.
>
> thanks again
> Achilleas
>
> On Mon, Apr 18, 2016 at 8:35 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Geof,
>>
>> thanks for your help.
>> There are two dll's missing as reported by the program.
>> Those are:
>>
>> DCOMP.DLL
>> IESHIMS.DLL
>>
>> any help on how to move forward is appreciated,
>>
>> thanks again
>> Achilleas
>>
>>
>>
>>
>>
>> On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer 
>> wrote:
>>
>>> Achilleas,
>>>
>>> To troubleshoot that problem:
>>> 1- download a program called "Dependency Walker",  (www.
>>> *dependencywalker*.com/)
>>> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
>>> default settings.  It will give a dialog saying something wasn't found,
>>> that's normal.
>>> 3- Go to Options->Configure Module Search Order
>>> 4- On the bottom right of the window, go to "Browse" and
>>> select C:\Program Files\GNURadio-3.7\bin and click "Add Directory", then
>>> say "Yes"
>>> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>>>
>>> Now on the top left you will see huge tree of all the dependencies...
>>> something in there is missing.  IGNORE the entries that look like
>>> "API_MS_WIN...", those are fine to be missing.
>>>
>>> Please tell me what you are missing.
>>>
>>> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime
>>> that is missing.  If the missing entries are "UCRTBASE.DLL",
>>> "MSVCP140.DLL", and VCRUNTIME140.DLL", that is the problem.  That's a
>>> download from Microsoft here:
>>> https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>>
>>> Geof
>>>
>>>
>>> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
 Some more information about the problem I have running the installed
 version.

 In the GNYRADIO command prompt shell I run python and then
 >> from gnuradio import filter


 and I get the following:

 Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Program
 Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
 .py", line 32, in 
 from filter_swig import *
   File "C:\Program
 Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
 wig.py", line 28, in 
 _filter_swig = swig_import_helper()
   File "C:\Program
 Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
 wig.py", line 24, in swig_import_helper
 _mod = imp.load_module('_filter_swig', fp, pathname, description)
 ImportError: DLL load failed with error code -1073741795

 =

 Any help is welcome,

 thanks
 Achilleas


 On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
 anas...@umich.edu> wrote:

> I installed the binary files
> gnuradio_3.7.9.2_win64.msi
> on a Win-8 machine succefullyon the default directory.
>
> After running gnuradio-companion file from the Gnuradio 3.7
> start menu folder I see a command window opening with message
> "setting gnuradio environment",
> then a couple of warnings of the sort:
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GMountMountFlags' as
>  enum when in fact it is of type 'GFlags'
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as
>  enum when in fact it is of type 'GFlags'
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GSocketMsgFlags' as
> enum when in fact it is of type 'GFlags'
>
>
> and then the "standard" gnuradio window appears with the import-error
> warning
>
>
> 
> Cannot import gnuradio.
>
> Is the python path environment variable set correctly?
> All OS: PYTHONPATH
>
> Is the library path environment variable set correctly?
> Linux: LD_LIBRARY_PATH
> Windows: PATH
> MacOSX: DYLD_LIBRARY_PATH
>
>
> (DLL load failed with error code -1073741795)
> ---
>
>
> any thoughts as to what is going wrong?
>
> thanks
> Achilleas
>


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Geof Nieboer]

Good news.  The out-file fix must have missed a commit somehow, I
distinctly remember making and fixing that.  Oh well, thanks.
The other is interesting, I'm not sure why it worked on mine then.  I'm
already patching that file to recognize VC14, so just need to amend the
patch.

As you continue to experiment, in case you haven't already figured it out,
once you open the scripts project the first time in VS 2015, just run
Setup.ps1 once to set the environment, then you can run any of the scripts
individually, and by setting the $configuration variable (shortcuts at
bottom of several scripts) you can usually just run any individual
"sub-build" on it's own to save time and incrementally move forward.  But
it looks like you've already gotten past the toughest part, so that's
excellent..

On Mon, Apr 18, 2016 at 2:27 PM, Anon Lister  wrote:

> Aha. Found the error. I don't know how you didn't encounter it in your
> builds, but in the build-wxpython.py script, line 443 fails, it's up
> in the log. It sets install_dir to some variables defined in a if not
> windows block higher up. This causes the script to bomb at install due
> to an undefined variable. I just set install_dir to "" and validate
> was successful.
>
> Thanks for the tip on looking for the _core_.pyd, that's what lead me
> to it, it wasn't present anywhere but in the build directory (and a
> few other places on my box, but all from timestamps way before the
> build). Anyway, that step of the script is rebuilding now, just to be
> sure it works.
>
> I dug into the Step5-consolidation error a bit, it looks like its failing
> with
>
> "Consolidating Qt...Out-File : A parameter cannot be found that
> matches parameter name 'path'.
> At C:\gr-build\scripts\Step5-ConsolidateLibs.ps1:67 char:23
> + "[Paths]" | out-file -path $root/build/$configuration/bin/qt.conf ...
> +  ~
> + CategoryInfo  : InvalidArgument: (:) [Out-File],
> ParentContainsErrorRecordException
> + FullyQualifiedErrorId :
> NamedParameterNotFound,Microsoft.PowerShell.Commands.OutFileCommand"
>
> According to [1] out-file accepts -FilePath as an option. I switched
> to that (actually just ran that line on console) and it seemed to
> work, so that one may be an easy fix. I'll kick it off once the python
> builds finish. Probably wont get back to it till tonight.
>
> Yeah my goal here is mainly to reproduce the build, (and use it as a
> motivating project to learn a little powershell), then hopefully
> contribute to getting my favorite OOT's building. So no taking the
> cheap route. :) I'm still amazed you got all this stuff building on
> windows, most of it is a pain to build even on its native platform.
> heh.
>
> -Anon
>
>
> [1] https://technet.microsoft.com/en-us/library/hh849882.aspx
>
> On Apr 18, 2016 4:02 AM, "Geof Nieboer"  wrote:
> >
> > Anon,
> >
> >>
> >> which seems to just be a sanity check that something we expected to
> build was not
> >
> >
> > Exactly right.  It's not perfect but usually works.
> >
> >> ran setup.ps1 before I saw the ~RUNME_FIRST.ps1
> >
> >
> > ~RUNME_FIRST creates the basic directory tree for the build in the
> location you specify. You will want to re-run that with I:/gr-build as the
> root to ensure all the directories you need were created (but that's likely
> not the problem with WX but might be related to the consolidation fail).
> You can abort it after it starts running the Step1 script.
> >
> >>  just symlinked C:/gr-build to I:/gr-build
> >
> >
> > Hmm, you shouldn't have had to do that, I will dig deeper there.
> >
> >> whats special about wx
> >
> >
> > WX is just plain special.  It was problematic to get to build
> consistently, so I'm not surprised that it is where your build failed,
> unfortunately.
> >
> >> I did see in the comments something about debug builds not working
> correctly,  and there's a workaround
> >
> >
> > Yes, that comment is about building WX itself in a debug mode, not the
> overall build.  The workaround is already in place which just to always
> builds WX in release.
> >
> >> Any ideas what could be wrong?
> >
> >
> > Well, like you said, the build logs look clean, which is certainly odd.
> I think I would start with trying to search the computer for _core_.pyd and
> see where copies of it are, perhaps it's installing the package in the
> wrong location?  Then I'd also look for the slew of Wx DLLs, they should be
> in $pythonroot/DLLs  I'm fairly certain.
> >
> > Later when I'm back at the machine I will rebuild mine and compare the
> logs side by side and perhaps something with jump out.  Obviously a cheap
> workaround is to download the dependency pack and manually copy over the
> WX-related dirs in site-packages and the DLLs into /DLLs.  But that doesn't
> fix the underlying issue.
> >
> > Geof
> >
> > On Sun, Apr 17, 2016 at 9:20 PM, Anon Lister 
> wrote:
> >>
> >> Yep, my bad on UHD, used to doing 

Re: [Discuss-gnuradio] how to use the gnuradio block with c programing

[Tom Rondeau]

On Mon, Apr 18, 2016 at 3:53 AM, Ekko  wrote:

> hello all
> i want to know how to write a c program with the lib of gnuradio.
> for example i want to write a c program,to add a 15HZ sin signal with a
> 135HZ sin signal,then send from the usrp.
> i know how to send the data to the usrp.but i don't know how to use the
> signal source and the add fnuction of gnuradio in c program,just like use
> the uhd api as a fnuction.
> i will not want to write a oot block,i just want to write a *.c file to
> accomplish this work.
> but i don't how to start.
> is there some demo in gnuradio about how to use the gnuradio with C?just
> like the tx_samples_c.c in uhd.
> or something others to teel me how to solve this .
>
>
>
> thank you
>
> --Ekko
>


Ekko,

No, you cannot write a C program. GNU Radio is all written in C++, so you
will have to do this with a C++ program.

You can find examples in the source code under gr-audio/examples/c++ and
gr-uhd/examples/c++.

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

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

I have resolved one out of two issues.
The problem with IESHIMS.DLL is resolved (it is in the internet explorer
directory and all i needed was to add this to the path).

Still don't know how to resolve the DCOMP.DLL issue.

thanks again
Achilleas

On Mon, Apr 18, 2016 at 8:35 AM, Achilleas Anastasopoulos  wrote:

> Geof,
>
> thanks for your help.
> There are two dll's missing as reported by the program.
> Those are:
>
> DCOMP.DLL
> IESHIMS.DLL
>
> any help on how to move forward is appreciated,
>
> thanks again
> Achilleas
>
>
>
>
>
> On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer 
> wrote:
>
>> Achilleas,
>>
>> To troubleshoot that problem:
>> 1- download a program called "Dependency Walker",  (www.
>> *dependencywalker*.com/)
>> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
>> default settings.  It will give a dialog saying something wasn't found,
>> that's normal.
>> 3- Go to Options->Configure Module Search Order
>> 4- On the bottom right of the window, go to "Browse" and
>> select C:\Program Files\GNURadio-3.7\bin and click "Add Directory", then
>> say "Yes"
>> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>>
>> Now on the top left you will see huge tree of all the dependencies...
>> something in there is missing.  IGNORE the entries that look like
>> "API_MS_WIN...", those are fine to be missing.
>>
>> Please tell me what you are missing.
>>
>> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime
>> that is missing.  If the missing entries are "UCRTBASE.DLL",
>> "MSVCP140.DLL", and VCRUNTIME140.DLL", that is the problem.  That's a
>> download from Microsoft here:
>> https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>
>> Geof
>>
>>
>> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Some more information about the problem I have running the installed
>>> version.
>>>
>>> In the GNYRADIO command prompt shell I run python and then
>>> >> from gnuradio import filter
>>>
>>>
>>> and I get the following:
>>>
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
>>> .py", line 32, in 
>>> from filter_swig import *
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 28, in 
>>> _filter_swig = swig_import_helper()
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 24, in swig_import_helper
>>> _mod = imp.load_module('_filter_swig', fp, pathname, description)
>>> ImportError: DLL load failed with error code -1073741795
>>>
>>> =
>>>
>>> Any help is welcome,
>>>
>>> thanks
>>> Achilleas
>>>
>>>
>>> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
 I installed the binary files
 gnuradio_3.7.9.2_win64.msi
 on a Win-8 machine succefullyon the default directory.

 After running gnuradio-companion file from the Gnuradio 3.7
 start menu folder I see a command window opening with message
 "setting gnuradio environment",
 then a couple of warnings of the sort:

 ** (python.exe:5392): WARNING **: Trying to register gtype
 'GMountMountFlags' as
  enum when in fact it is of type 'GFlags'

 ** (python.exe:5392): WARNING **: Trying to register gtype
 'GDriveStartFlags' as
  enum when in fact it is of type 'GFlags'

 ** (python.exe:5392): WARNING **: Trying to register gtype
 'GSocketMsgFlags' as
 enum when in fact it is of type 'GFlags'


 and then the "standard" gnuradio window appears with the import-error
 warning


 
 Cannot import gnuradio.

 Is the python path environment variable set correctly?
 All OS: PYTHONPATH

 Is the library path environment variable set correctly?
 Linux: LD_LIBRARY_PATH
 Windows: PATH
 MacOSX: DYLD_LIBRARY_PATH


 (DLL load failed with error code -1073741795)
 ---


 any thoughts as to what is going wrong?

 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Also a correction:

I am running Windows 7 (not 8 as I erroneously reported)

thanks again
Achilleas

On Mon, Apr 18, 2016 at 8:35 AM, Achilleas Anastasopoulos  wrote:

> Geof,
>
> thanks for your help.
> There are two dll's missing as reported by the program.
> Those are:
>
> DCOMP.DLL
> IESHIMS.DLL
>
> any help on how to move forward is appreciated,
>
> thanks again
> Achilleas
>
>
>
>
>
> On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer 
> wrote:
>
>> Achilleas,
>>
>> To troubleshoot that problem:
>> 1- download a program called "Dependency Walker",  (www.
>> *dependencywalker*.com/)
>> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
>> default settings.  It will give a dialog saying something wasn't found,
>> that's normal.
>> 3- Go to Options->Configure Module Search Order
>> 4- On the bottom right of the window, go to "Browse" and
>> select C:\Program Files\GNURadio-3.7\bin and click "Add Directory", then
>> say "Yes"
>> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>>
>> Now on the top left you will see huge tree of all the dependencies...
>> something in there is missing.  IGNORE the entries that look like
>> "API_MS_WIN...", those are fine to be missing.
>>
>> Please tell me what you are missing.
>>
>> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime
>> that is missing.  If the missing entries are "UCRTBASE.DLL",
>> "MSVCP140.DLL", and VCRUNTIME140.DLL", that is the problem.  That's a
>> download from Microsoft here:
>> https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>
>> Geof
>>
>>
>> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Some more information about the problem I have running the installed
>>> version.
>>>
>>> In the GNYRADIO command prompt shell I run python and then
>>> >> from gnuradio import filter
>>>
>>>
>>> and I get the following:
>>>
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
>>> .py", line 32, in 
>>> from filter_swig import *
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 28, in 
>>> _filter_swig = swig_import_helper()
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 24, in swig_import_helper
>>> _mod = imp.load_module('_filter_swig', fp, pathname, description)
>>> ImportError: DLL load failed with error code -1073741795
>>>
>>> =
>>>
>>> Any help is welcome,
>>>
>>> thanks
>>> Achilleas
>>>
>>>
>>> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
 I installed the binary files
 gnuradio_3.7.9.2_win64.msi
 on a Win-8 machine succefullyon the default directory.

 After running gnuradio-companion file from the Gnuradio 3.7
 start menu folder I see a command window opening with message
 "setting gnuradio environment",
 then a couple of warnings of the sort:

 ** (python.exe:5392): WARNING **: Trying to register gtype
 'GMountMountFlags' as
  enum when in fact it is of type 'GFlags'

 ** (python.exe:5392): WARNING **: Trying to register gtype
 'GDriveStartFlags' as
  enum when in fact it is of type 'GFlags'

 ** (python.exe:5392): WARNING **: Trying to register gtype
 'GSocketMsgFlags' as
 enum when in fact it is of type 'GFlags'


 and then the "standard" gnuradio window appears with the import-error
 warning


 
 Cannot import gnuradio.

 Is the python path environment variable set correctly?
 All OS: PYTHONPATH

 Is the library path environment variable set correctly?
 Linux: LD_LIBRARY_PATH
 Windows: PATH
 MacOSX: DYLD_LIBRARY_PATH


 (DLL load failed with error code -1073741795)
 ---


 any thoughts as to what is going wrong?

 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Geof,

thanks for your help.
There are two dll's missing as reported by the program.
Those are:

DCOMP.DLL
IESHIMS.DLL

any help on how to move forward is appreciated,

thanks again
Achilleas





On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer 
wrote:

> Achilleas,
>
> To troubleshoot that problem:
> 1- download a program called "Dependency Walker",  (www.*dependencywalker*
> .com/)
> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
> default settings.  It will give a dialog saying something wasn't found,
> that's normal.
> 3- Go to Options->Configure Module Search Order
> 4- On the bottom right of the window, go to "Browse" and select C:\Program
> Files\GNURadio-3.7\bin and click "Add Directory", then say "Yes"
> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>
> Now on the top left you will see huge tree of all the dependencies...
> something in there is missing.  IGNORE the entries that look like
> "API_MS_WIN...", those are fine to be missing.
>
> Please tell me what you are missing.
>
> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime that
> is missing.  If the missing entries are "UCRTBASE.DLL", "MSVCP140.DLL", and
> VCRUNTIME140.DLL", that is the problem.  That's a download from Microsoft
> here: https://www.microsoft.com/en-us/download/details.aspx?id=48145
>
> Geof
>
>
> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Some more information about the problem I have running the installed
>> version.
>>
>> In the GNYRADIO command prompt shell I run python and then
>> >> from gnuradio import filter
>>
>>
>> and I get the following:
>>
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
>> .py", line 32, in 
>> from filter_swig import *
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>> wig.py", line 28, in 
>> _filter_swig = swig_import_helper()
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>> wig.py", line 24, in swig_import_helper
>> _mod = imp.load_module('_filter_swig', fp, pathname, description)
>> ImportError: DLL load failed with error code -1073741795
>>
>> =
>>
>> Any help is welcome,
>>
>> thanks
>> Achilleas
>>
>>
>> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> I installed the binary files
>>> gnuradio_3.7.9.2_win64.msi
>>> on a Win-8 machine succefullyon the default directory.
>>>
>>> After running gnuradio-companion file from the Gnuradio 3.7
>>> start menu folder I see a command window opening with message
>>> "setting gnuradio environment",
>>> then a couple of warnings of the sort:
>>>
>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>> 'GMountMountFlags' as
>>>  enum when in fact it is of type 'GFlags'
>>>
>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>> 'GDriveStartFlags' as
>>>  enum when in fact it is of type 'GFlags'
>>>
>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>> 'GSocketMsgFlags' as
>>> enum when in fact it is of type 'GFlags'
>>>
>>>
>>> and then the "standard" gnuradio window appears with the import-error
>>> warning
>>>
>>>
>>> 
>>> Cannot import gnuradio.
>>>
>>> Is the python path environment variable set correctly?
>>> All OS: PYTHONPATH
>>>
>>> Is the library path environment variable set correctly?
>>> Linux: LD_LIBRARY_PATH
>>> Windows: PATH
>>> MacOSX: DYLD_LIBRARY_PATH
>>>
>>>
>>> (DLL load failed with error code -1073741795)
>>> ---
>>>
>>>
>>> any thoughts as to what is going wrong?
>>>
>>> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

Aha. Found the error. I don't know how you didn't encounter it in your
builds, but in the build-wxpython.py script, line 443 fails, it's up
in the log. It sets install_dir to some variables defined in a if not
windows block higher up. This causes the script to bomb at install due
to an undefined variable. I just set install_dir to "" and validate
was successful.

Thanks for the tip on looking for the _core_.pyd, that's what lead me
to it, it wasn't present anywhere but in the build directory (and a
few other places on my box, but all from timestamps way before the
build). Anyway, that step of the script is rebuilding now, just to be
sure it works.

I dug into the Step5-consolidation error a bit, it looks like its failing with

"Consolidating Qt...Out-File : A parameter cannot be found that
matches parameter name 'path'.
At C:\gr-build\scripts\Step5-ConsolidateLibs.ps1:67 char:23
+ "[Paths]" | out-file -path $root/build/$configuration/bin/qt.conf ...
+  ~
+ CategoryInfo  : InvalidArgument: (:) [Out-File],
ParentContainsErrorRecordException
+ FullyQualifiedErrorId :
NamedParameterNotFound,Microsoft.PowerShell.Commands.OutFileCommand"

According to [1] out-file accepts -FilePath as an option. I switched
to that (actually just ran that line on console) and it seemed to
work, so that one may be an easy fix. I'll kick it off once the python
builds finish. Probably wont get back to it till tonight.

Yeah my goal here is mainly to reproduce the build, (and use it as a
motivating project to learn a little powershell), then hopefully
contribute to getting my favorite OOT's building. So no taking the
cheap route. :) I'm still amazed you got all this stuff building on
windows, most of it is a pain to build even on its native platform.
heh.

-Anon


[1] https://technet.microsoft.com/en-us/library/hh849882.aspx

On Apr 18, 2016 4:02 AM, "Geof Nieboer"  wrote:
>
> Anon,
>
>>
>> which seems to just be a sanity check that something we expected to build 
>> was not
>
>
> Exactly right.  It's not perfect but usually works.
>
>> ran setup.ps1 before I saw the ~RUNME_FIRST.ps1
>
>
> ~RUNME_FIRST creates the basic directory tree for the build in the location 
> you specify. You will want to re-run that with I:/gr-build as the root to 
> ensure all the directories you need were created (but that's likely not the 
> problem with WX but might be related to the consolidation fail).  You can 
> abort it after it starts running the Step1 script.
>
>>  just symlinked C:/gr-build to I:/gr-build
>
>
> Hmm, you shouldn't have had to do that, I will dig deeper there.
>
>> whats special about wx
>
>
> WX is just plain special.  It was problematic to get to build consistently, 
> so I'm not surprised that it is where your build failed, unfortunately.
>
>> I did see in the comments something about debug builds not working 
>> correctly,  and there's a workaround
>
>
> Yes, that comment is about building WX itself in a debug mode, not the 
> overall build.  The workaround is already in place which just to always 
> builds WX in release.
>
>> Any ideas what could be wrong?
>
>
> Well, like you said, the build logs look clean, which is certainly odd.  I 
> think I would start with trying to search the computer for _core_.pyd and see 
> where copies of it are, perhaps it's installing the package in the wrong 
> location?  Then I'd also look for the slew of Wx DLLs, they should be in 
> $pythonroot/DLLs  I'm fairly certain.
>
> Later when I'm back at the machine I will rebuild mine and compare the logs 
> side by side and perhaps something with jump out.  Obviously a cheap 
> workaround is to download the dependency pack and manually copy over the 
> WX-related dirs in site-packages and the DLLs into /DLLs.  But that doesn't 
> fix the underlying issue.
>
> Geof
>
> On Sun, Apr 17, 2016 at 9:20 PM, Anon Lister  wrote:
>>
>> Yep, my bad on UHD, used to doing git builds and seeing 3.10. Cool yeah gqrx 
>> would be the priority, baz is just a nice to have (and its a bit dated as 
>> its all in WX which seems to be going the route of deprecation).
>> So for some feedback, I installed the binaries and everything seems to work 
>> good. Hooked up the UHD and was able to receive a decent sample rate without 
>> issue. Only small issue is was a popup on first run that said:
>>
>> "The xterm executable 'xterm' is missing.
>>
>> You can change this setting in your gnuradio.conf, in section [grc], 
>> 'xterm_executable'.
>>
>> (This message is shown only once)"
>>
>> Which is understandable, as xterm is not built.  Anyway, after clicking ok 
>> everything works.
>>
>> On the build side, first off, I'll say while I'm quite proficient on the 
>> Linux side, on the windows side I'm pretty noobish, so the first errors I 
>> received (missing io.h header, among other errors), appeared to be due to me 
>> having old VS 2012 only half removed which confused 14.. Anywho, 

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Geof Nieboer]

Anon,


> which seems to just be a sanity check that something we expected to build
> was not


Exactly right.  It's not perfect but usually works.

ran setup.ps1 before I saw the ~RUNME_FIRST.ps1


~RUNME_FIRST creates the basic directory tree for the build in the location
you specify. You will want to re-run that with I:/gr-build as the root to
ensure all the directories you need were created (but that's likely not the
problem with WX but might be related to the consolidation fail).  You can
abort it after it starts running the Step1 script.

 just symlinked C:/gr-build to I:/gr-build


Hmm, you shouldn't have had to do that, I will dig deeper there.

whats special about wx


WX is just plain special.  It was problematic to get to build consistently,
so I'm not surprised that it is where your build failed, unfortunately.

I did see in the comments something about debug builds not working
> correctly,  and there's a workaround


Yes, that comment is about building WX itself in a debug mode, not
the overall build.  The workaround is already in place which just to always
builds WX in release.

Any ideas what could be wrong?


Well, like you said, the build logs look clean, which is certainly odd.  I
think I would start with trying to search the computer for _core_.pyd and
see where copies of it are, perhaps it's installing the package in the
wrong location?  Then I'd also look for the slew of Wx DLLs, they should be
in $pythonroot/DLLs  I'm fairly certain.

Later when I'm back at the machine I will rebuild mine and compare the logs
side by side and perhaps something with jump out.  Obviously a cheap
workaround is to download the dependency pack and manually copy over the
WX-related dirs in site-packages and the DLLs into /DLLs.  But that doesn't
fix the underlying issue.

Geof

On Sun, Apr 17, 2016 at 9:20 PM, Anon Lister  wrote:

> Yep, my bad on UHD, used to doing git builds and seeing 3.10. Cool yeah
> gqrx would be the priority, baz is just a nice to have (and its a bit dated
> as its all in WX which seems to be going the route of deprecation).
> So for some feedback, I installed the binaries and everything seems to
> work good. Hooked up the UHD and was able to receive a decent sample rate
> without issue. Only small issue is was a popup on first run that said:
>
> "The xterm executable 'xterm' is missing.
>
> You can change this setting in your gnuradio.conf, in section [grc],
> 'xterm_executable'.
>
> (This message is shown only once)"
>
> Which is understandable, as xterm is not built.  Anyway, after clicking ok
> everything works.
>
> On the build side, first off, I'll say while I'm quite proficient on the
> Linux side, on the windows side I'm pretty noobish, so the first errors I
> received (missing io.h header, among other errors), appeared to be due to
> me having old VS 2012 only half removed which confused 14.. Anywho, after
> figuring that out and cleaning it up everything went good till the WX
> python build. But first I'll throw in that I did install VS2014 into an
> alternate path, this caused several issues with checks, I ended up creating
> the windows equivalent of a symlink (or maybe multi-disk hardlink, think
> its called a junction) and that solved that issue, but also the scripts ask
> for a location to place its build files, I tried I:/gr-build but received
> errors where directories in C:/gr-build were missing, I just symlinked
> C:/gr-build to I:/gr-build and things seemed fine. I only bring it up since
> the build scripts asked for a location. Perhaps it was something I did as I
> first ran setup.ps1 before I saw the ~RUNME_FIRST.ps1. Anyway, back to the
> WX error:
>
> Got the error "Validation Failed,
> C:/gr-build\src-stage2-python\gr-python27\lib\site-packages\wx-3.0-msw\wx\_core_.pyd
> was not found and is required" which seems to just be a sanity check that
> something we expected to build was not(i did independently verify its not
> there, theres no wx* in site-packages), I've uploaded the log for
> wx-python[1], let me know if you need any more info.
>
> The build appears to stop there. Not sure where to go with debugging as
> there appears to be no error, only some warnings? I'm also not familiar
> with wheel, though one would assume it produces the whl installer files. I
> did test removing the WX block and Step4 runs to completion. So it appears
> to be something with WX. I did see in the comments something about debug
> builds not working correctly,  and there's a workaround. For completeness,
> I went ahead and commented out the Verify line and all builds (AVX,
> ReleaseDLL, Debug ) appear to generate this same log (except for folder
> names and such), and all do not generate the appropriate pyd file.
>
> Any ideas what could be wrong? Or maybe whats special about wx as compared
> to the other python modules? If it was a bunch I would suspect something in
> my env may just be incorrect(Which, very well may be the case), but it
> seems just 

[Discuss-gnuradio] how to use the gnuradio block with c programing

[Ekko]

hello all
i want to know how to write a c program with the lib of gnuradio.
for example i want to write a c program,to add a 15HZ sin signal with a
135HZ sin signal,then send from the usrp.
i know how to send the data to the usrp.but i don't know how to use the
signal source and the add fnuction of gnuradio in c program,just like use
the uhd api as a fnuction.
i will not want to write a oot block,i just want to write a *.c file to
accomplish this work.
but i don't how to start.
is there some demo in gnuradio about how to use the gnuradio with C?just
like the tx_samples_c.c in uhd.
or something others to teel me how to solve this .



thank you

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

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[Douglas Geiger]

I know I'm a little late to this party, but I thought I'd point this out:
the output "VOLK: Error allocating memory (posix_memalign: 22)" suggests
you are running into this known issue:
http://gnuradio.org/redmine/issues/692

If this is indeed a rPi Rev B, then this is the known/old issue of
volk_get_alignment() returning a value on 1 on that arch, which then breaks
posix_memalign. I believe this has been fixed in more recent releases, so
perhaps jessie-backports can help you there?

 Good luck,
  Doug

On Wed, Apr 13, 2016 at 4:45 AM, Rob Roschewsk  wrote:

> Marcus,
>
> Thanks for responding.
>
> I'm looking to build a headless FM receiver to record and stream public
> service communication (fire, police, etc.). We will stream as many channels
> as possible that fall into a given passband.
>
> I already have a system running on a PC and now would like to port it to
> the PI.
>
> I understand it maybe an "up hill" path, but the thought is to deploy
> multiple inexpensive units around a geographic area all feeding a central
> streaming server.
>
> The Pi is running Raspian Jesse  I started with the distribution
> packages but ran into problems right out of the blocks and thought it would
> be best to use the latest code before asking questions :)
>
> I understand cross compiling is the way to go.
>
> Since I brought it up, here was the error I saw when I tried to run the
> script that runs on the PC but fails spectacularly on the raspberry pi with
> the precompiled packages 
>
> roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py -s 49 noaa.xml
> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0 <0030070030>
> -unknown
>
> high=16250 low=16240 span=10
> center=16245
> gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy
> Using device #0 Realtek RTL2838UHIDIR SN: 0108
> Found Elonics E4000 tuner
> Exact sample rate is: 100.026491 Hz
> Using Volk machine: generic_orc
> VOLK: Error allocating memory (posix_memalign: 22)
> VOLK: Error allocating memory (posix_memalign: 22)
> VOLK: Error allocating memory (posix_memalign: 22)
> Segmentation fault
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio