Re: [Discuss-gnuradio] Windows install building oot modules

[Geof Nieboer]

Yes, ability to build OOT modules is the key work for the next release.
(a), (b), and (c) are all generated during the build, so it's just a
question of including them in the .msi.

I will keep your requests in mind as I build the next installer, thanks!

Geof

On Fri, Sep 29, 2017 at 5:27 PM, Eugene Grayver 
wrote:

> First, kudos for getting Windows builds up and running.  I’ve been doing
> it manually myself for years and it has always been a pain.  Can I request
> two small changes:
>
> 1.   Please include enough extras to allow building oot modules
>
> a.   Boost includes and .libs
>
> b.  Swig.exe
>
> c.   Zeromq includes and .libs (I think a few oot use this)
>
> 2.   I could not get ‘pip’ to work.  The pip-script.py works just
> fine, but pip.exe gives ‘failed create process’  Not a big deal, but threw
> me for a loop.
>
>
>
>
>
> ___
> 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

Re: [Discuss-gnuradio] cheap sdr platform

[Kyeong Su Shin]

To whom it may concern:

As Marcus Müller said, ADALM-PLUTO is too slow for LTE/WIFI, unless you can
come up with clever FPGA-level hacks dedicated for your jobs, or you are
okay with NOT receiving signals from actual LTE/WIFI transmitters. It can
only stably stream ~4MS/s(!) of effective sampling rate over USB, and I
believe that it does not support 8bit streaming mode. I am not sure why it
can only do approx. 4MS/s - especially since other SDRs can stream faster
even with the USB 2.

I'd also recommend LimeSDR mini (shipping this December, but please be
advised that it can be delayed further). If you need to get a unit soon,
standard LimeSDR could be your best bet. Also, if you want to implement
your own BTS, you may want to look for a device that you can attach a
stable external clock source.

Regards,
Kyeong Su Shin

On Fri, Sep 29, 2017 at 9:04 AM, Vitt Benv  wrote:

> Take a look also at LimeSDR... there is a "mini" version for about 150$.
> If I recall right it's a fullduplex 12 bit ADC/DDC, ranging 1MHz / 6GHz
> with 20 MSPS, with USB port.
>
> https://www.crowdsupply.com/lime-micro/limesdr-mini#details-top
>
> victor
>
> Il 29 set 2017 10:21, "w xd"  ha scritto:
>
>> Hello guys,
>>
>>   Have some suggestion on the cheaper SDR platform for us
>> to use with the GNURADIO software? As a student, I cannot buy the expensive
>> usrp ,but I want to learn the knowledge by the hardware and software. Any
>> recommend? For example,use the hardware to do some experiments about
>> LTE/WIFI.
>>
>>
>>
>> ___
>> 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] Should I see R82XX PLL not locked?

[Chris Kuethe]

I think that's a normal side effect of some some code to allow fast
retuning and extended range by not waiting for PLL lock. Try receiving a
few local FM radio stations. If that works without dropping too many
samples or getting a steady stream of PLL errors your RTL is probably fine.

On Fri, Sep 29, 2017 at 7:13 AM, Ed Troy  wrote:

> I finally have gnuradio-companion up and running with a RTL-SDR (by
> Nooelec). Whenever I start up a workspace, I get the following message. Is
> this indicative of a bad RTL-SDR, or something wrong in my setup, or is
> this normal?
>
> Using device #0 Realtek RTL2838UHIDIR SN: 0001
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> [R82XX] PLL not locked!
>
> Ed
>
>
> ___
> 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?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Downconversion to 45 MHz Intermediate

[Marcus Müller]

Hi Ernest,

basically, there's a lot of things that could do what you want, and 
using an SDR for that sounds like not inherently the best way. What is 
it that you want to do in the bigger picture, and how does it relate to 
GNU Radio?


Best regards,
Marcus


On 09/29/2017 07:01 PM, ERNEST MATEY wrote:

Hi experts

My work requires the downconversion from 437MHz to 45MHz of the 
received signal.
I am told some SDR device with IF at 45.05MHz output are already in 
market. Do you know any? Could you please refer to me? I know about 
"AOR 2003" but too expensive for student work.


Is there any?

Thank You
Ernest Teye



___
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] Windows install building oot modules

[Eugene Grayver]

First, kudos for getting Windows builds up and running.  I've been doing it 
manually myself for years and it has always been a pain.  Can I request two 
small changes:

1.   Please include enough extras to allow building oot modules

a.   Boost includes and .libs

b.  Swig.exe

c.   Zeromq includes and .libs (I think a few oot use this)

2.   I could not get 'pip' to work.  The pip-script.py works just fine, but 
pip.exe gives 'failed create process'  Not a big deal, but threw me for a loop.


___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

>> you don't get the sound card clock anywhere in software. If you did, there 
>> would >> be no problem

Jack uses audio clock  and maps this audio clock to system one
with the use of DLL (delay locked loop).

-ben

From: Benny Alexandar
Sent: Wednesday, September 27, 2017 10:45 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing


>>Could you maybe elaborate how you're planning to solve all a),b),c) instead 
>>of asking for new feedback?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for this approach of course is increased latency.
This way any variable work-load length is not going to affect and the local 
fifo will have fixed length.
Timing errors needs to be filtered using DLL which is  the same used in JACK.

-ben









And as also said earlier, I don't believe very much that it will work that 
easily, since the CPU clock is a) worse than the typical SDR and sound card 
clocks, b) has different resolutions, c) and needs to still be sufficiently 
interpolatable for the jittery, variable-workload-length that GNU Radio has. 
The point c) is what's different for Jack internally, because that can work on 
fixed-length buffers.


This is a comment that you've gotten from me (and by the way, Fons, too) 
multiple times now. Could you maybe elaborate how you're planning to solve all 
a),b),c) instead of asking for new feedback?



From: Benny Alexandar
Sent: Wednesday, September 27, 2017 6:50 AM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

Hi Marcus,

As said earlier there is no true clock as such. We need to rely on CPU clock 
and measure the deviation. The reference clock is the transmitter time duration 
between two symbols which is a preset value. Do you have any suggestions for a 
*better reference clock*

-ben

--

Hi Benny,

you're, again, missing the core problem: it's hard to measure the time 
deviation between two symbols without a better reference clock. And you don't 
have that. And thus, we're back at the start of all our email chain.

Best regards,

Marcus

From: Benny Alexandar
Sent: Tuesday, September 26, 2017 10:56 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

Hello,

Now the timing of input side is after detecting the start of symbol. Every 
symbol will be timestamped and  measure the time deviation between two symbols.

d = t1 -  t0,
where t0 - time of arrival of symbol (n)
 t1 - time of arrival of symbol (n+1)
  d - time deviation between two symbols.

D - time duration between two symbols according to digital radio standards, 
then  error =  ( D / d )  -  1

Please send your suggestions feedback regarding this approach.

-ben

From: Benny Alexandar
Sent: Friday, September 22, 2017 10:26 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

Hi Marcus,

Please find the attached  figure on how the audio control loop will be placed in
Gnu Radio chain. In the figure the first block is the RF IQ  acquisition block 
which samples the RF samples and put a timestamp. It is then passed on  to 
channel and audio decoder and finally reaches the audio sink. Audio sink does 
the audio playback on fragments of audio.

The audio control loop module has two inputs and one output. The inputs are for 
sending the timestamp of write side and read side. In this case write side is 
RF capture and read is from audio sink. Note these two time stamps are coming 
from different clock, the RF capture uses PC CPU clock where as the audio sink 
has sound card clock. The output of audio control loop is used to control the 
re sampler which sits in between audio decoder and audio sink.More details on 
how the audio control loop will be send soon.

Please send your feedback regarding this approach.


-ben

From: Marcus Müller 
Sent: Tuesday, September 19, 2017 10:47 PM
To: Benny Alexandar; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing


Hi Ben,


May I know why not with JACK ?


>From the very same email you're referring to:


 (not much sense writing it for the Jack sink, if Jack can already do it 
internally)
Also,

Here, I need your inputs.
I spent around 5 hrs on input on this topic already. I don't feel like you need 
more input, it feels more like you haven't had the chance yet to understand all 
the input that there is on the GNU Radio mailing 

[Discuss-gnuradio] Downconversion to 45 MHz Intermediate

[ERNEST MATEY]

 Hi expertsMy work requires the downconversion from 437MHz to 45MHz of the received signal.  I am told some SDR device with IF at 45.05MHz output are already in market. Do you know any? Could you please refer to me? I know about "AOR 2003" but too expensive for student work.Is there any? Thank YouErnest Teye 

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

Re: [Discuss-gnuradio] cheap sdr platform

[Vitt Benv]

Take a look also at LimeSDR... there is a "mini" version for about 150$.
If I recall right it's a fullduplex 12 bit ADC/DDC, ranging 1MHz / 6GHz
with 20 MSPS, with USB port.

https://www.crowdsupply.com/lime-micro/limesdr-mini#details-top

victor

Il 29 set 2017 10:21, "w xd"  ha scritto:

> Hello guys,
>
>   Have some suggestion on the cheaper SDR platform for us
> to use with the GNURADIO software? As a student, I cannot buy the expensive
> usrp ,but I want to learn the knowledge by the hardware and software. Any
> recommend? For example,use the hardware to do some experiments about
> LTE/WIFI.
>
>
>
> ___
> 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] cheap sdr platform

[Marcus Müller]

Hi Ed,

as said about the general case, with the ADALM-Pluto's USB2 bandwidth, 
you can barely squeeze in one 20 MHz WiFi Channel if you're using 8 bit 
samples, which probably won't cut it for WiFi. For LTE: this might make 
more sense, but again, that depends on the LTE bandwidth. Also, as ADI's 
Robin never tired to say at GRCon: ADALM-Pluto doesn't contain 
sufficient output filtering, so use at your own peril, and please don't 
break the law :) Other than that, yes, indeed, looks like a pretty nice SDR!


Best regards,
Marcus

On 09/29/2017 04:23 PM, Ed Troy wrote:


I just got the Analog Devices ADALM-Pluto module. It seems really 
nice, but I have not had any time to work with it yet. It covers 325 
MHz to 3.2 GHz and has transmit as well as receive. I was one of the 
very few who actually got one since Analog Devices was having some 
production issues. But, they should be back on the market soon. And, 
as a student you can probably get one for $99. The worst case would be 
$150.


Ed


On 9/29/2017 4:18 AM, w xd wrote:

Hello guys,

  Have some suggestion on the cheaper SDR platform 
for us to use with the GNURADIO software? As a student, I cannot buy 
the expensive usrp ,but I want to learn the knowledge by the hardware 
and software. Any recommend? For example,use the hardware to do some 
experiments about LTE/WIFI.





___
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] cheap sdr platform

[Ed Troy]

I just got the Analog Devices ADALM-Pluto module. It seems really nice, 
but I have not had any time to work with it yet. It covers 325 MHz to 
3.2 GHz and has transmit as well as receive. I was one of the very few 
who actually got one since Analog Devices was having some production 
issues. But, they should be back on the market soon. And, as a student 
you can probably get one for $99. The worst case would be $150.


Ed


On 9/29/2017 4:18 AM, w xd wrote:

Hello guys,

                  Have some suggestion on the cheaper SDR platform for 
us to use with the GNURADIO software? As a student, I cannot buy the 
expensive usrp ,but I want to learn the knowledge by the hardware and 
software. Any recommend? For example,use the hardware to do some 
experiments about LTE/WIFI.





___
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] Should I see R82XX PLL not locked?

[Ed Troy]

I finally have gnuradio-companion up and running with a RTL-SDR (by 
Nooelec). Whenever I start up a workspace, I get the following message. 
Is this indicative of a bad RTL-SDR, or something wrong in my setup, or 
is this normal?


Using device #0 Realtek RTL2838UHIDIR SN: 0001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!

Ed


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

[Discuss-gnuradio] gr-osmocom source segfaults on startup roughly 90 % of the time

[Tom McDermott]

I am using gr-osmocom source module to talk to a soapy remote device.
It works correctly about 10 percent of the time. The other ~90 percent of
the time it segfaults on startup. It might run twice in a row, then it might
take 15 attempts before it starts correctly.

The value of set_if_gain is 20
The device type is  soapy=remote:rtlsdr
Here is a trace of the segfault, it seems to always be the same fault:

(gdb) run first_remote_no_gui.py
Starting program: /usr/bin/python first_remote_no_gui.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.002.000-3-g122bfae1

gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy soapy redpitaya
[New Thread 0x7fffe57a5700 (LWP 4300)]
[New Thread 0x7fffe4fa4700 (LWP 4301)]

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x7fffea3d47d9 in soapy_source_c::set_if_gain(double, unsigned long) ()
   from /usr/local/lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0
(gdb) bt
#0  0x7fffea3d47d9 in soapy_source_c::set_if_gain(double, unsigned
long) ()
   from /usr/local/lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0
#1  0x7fffea35d152 in source_impl::set_if_gain(double, unsigned long) ()
   from /usr/local/lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0
#2  0x7fffea63bfd6 in _wrap_source_sptr_set_if_gain ()
   from /usr/local/lib/python2.7/dist-packages/osmosdr/_osmosdr_swig.so
#3  0x004c468a in call_function (oparg=,
pp_stack=0x7fffd1b0) at ../Python/ceval.c:4350
#4  PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#5  0x004c2765 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#6  0x004ca099 in fast_function (nk=0, na=,
n=, pp_stack=0x7fffd3c0,
func=) at ../Python/ceval.c:4445
#7  call_function (oparg=, pp_stack=0x7fffd3c0)
at ../Python/ceval.c:4370
#8  PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#9  0x004c2765 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#10 0x004de6fe in function_call.lto_priv ()
at ../Objects/funcobject.c:523
#11 0x004b0cb3 in PyObject_Call () at ../Objects/abstract.c:2546
#12 0x004f492e in instancemethod_call.lto_priv ()
at ../Objects/classobject.c:2602
#13 0x004b0cb3 in PyObject_Call () at ../Objects/abstract.c:2546

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

[Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 10

[Håkon Vågsether]

Hi all,

I have updated my blog with my tenth and final weekly blog post. You can
read more at

http://grccpp.wordpress.com

Best regards,
Håkon Vågsether
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cheap sdr platform

[Marcus Müller]

Hi daniel,

so, obviously, the RTL-SDR dongles (can be had from 6€ upwards if bought
in bulk directly from China) is the SDR of choice for low-bandwidth
experiments. However, LTE and WiFi with bandwidths in the 10s of MHz
simply widely exceed their bandwidth.

Bandwidth-wise, and considering high-rate links won't be sensibly
receivable with 8-bit quantization, you'll need to have USB3 (or Gigabit
Ethernet up to ca 30 MS/s, or PCIe, or such for anything above) if you
need to receive 20 MHz wide WiFi or 10 MHz wide LTE. There's only so
many boards that do that. Some of which are cheaper than USRP B2xx
series devices, some not. Notice that LTE exists in smaller bandwidth
variants, too, but I can't comment on hardware useful for these.

Best regards,

Marcus


On 09/29/2017 01:18 AM, w xd wrote:
> Hello guys,
>
>   Have some suggestion on the cheaper SDR platform for
> us to use with the GNURADIO software? As a student, I cannot buy the
> expensive usrp ,but I want to learn the knowledge by the hardware and
> software. Any recommend? For example,use the hardware to do some
> experiments about LTE/WIFI.
>
>
>
>
> ___
> 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] cheap sdr platform

[w xd]

Hello guys,

  Have some suggestion on the cheaper SDR platform for us
to use with the GNURADIO software? As a student, I cannot buy the expensive
usrp ,but I want to learn the knowledge by the hardware and software. Any
recommend? For example,use the hardware to do some experiments about
LTE/WIFI.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio