[Discuss-gnuradio] running error

[kerry]

Hi,all:

I try to run an example about gnu radio. The runtime errors are captured as:

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace 
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError: 
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace 

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace 
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError: 
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done



But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".

It said that

Images destination:  /usr/local/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
Downloader raised an unhandled exception: request() got an unexpected
keyword argument 'stream'
You can run this again with the '--verbose' flag to see more information
If the problem persists, please email the output to: supp...@ettus.com
-

Could anyone tell my why? Thx.

-Kerry



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] running error

[James Humphries]

Hi Kerry,

Did you hook your computer back up to the internet before you ran
uhd_images_downloader.py?

-Trip

On Mon, Nov 30, 2015 at 3:22 PM, kerry  wrote:

> Hi,all:
>
> I try to run an example about gnu radio. The runtime errors are captured
> as:
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> FATAL: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
> path!
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> >>> Done
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>
> FATAL: No supported devices found to pick from.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> >>> Done
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>
> Using Volk machine: sse4_1_64_orc
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> FATAL: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
> path!
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> >>> Done
>
> 
>
> But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".
>
> It said that
>
> Images destination:  /usr/local/share/uhd/images
> Downloading images from:
> http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
> Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
> Downloader raised an unhandled exception: request() got an unexpected
> keyword argument 'stream'
> You can run this again with the '--verbose' flag to see more information
> If the problem persists, please email the output to: supp...@ettus.com
> -
>
> Could anyone tell my why? Thx.
>
> -Kerry
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVBT project receiver probelm

[Federico Larroca]

Hi Ihab,
I've just realized that the flowgraph obtaining_the_parameters is not very
clear, and I will modify it shortly.Thanks for the feedback. Could you
please connect the output of Sym Align OFDM that reads "Likelihood" to a
Time Sink? That is the one that should show a triangle. (BTW, you may also
disable the OFDM Synchronization and TMCC decoder blocks, since they only
work for ISDB-T only and are causing all that text in the terminal).
Regarding your constellation, I don't think you'll get a decent transport
stream with it, it's too noisy. You should try to receive a better signal.
Things I would try:
 1 - You are still getting several O's. Delete the noise source, which was
there on the first place to simulate a channel. You already have one. In my
experience, random generators are a costly thing.
 2 - Delete the multiplication at the input, which purpose I ignore.
However, since it also multiplies noise, I don't think it will change much.
 3 - Record the signal at a better spot, where the signal is better.
Regarding the use of our ofdm_sym_acquisition, if I am not mistaken,
gr-dvbt blocks downstream expect a certain tag which we changed. You should
be careful with that too.
Best
Federico

2015-11-30 9:17 GMT-03:00 Ihab Zine :

> Hi Frederico,Marcus and
>
> *Ron, *
> *I have good news and bad news. *
>
> *Frederico I used the flow graph  (obtaining parameters) **you told me to
> use but i didn't get the triangle or spike, i have attached a screen shot
> please see (* obtaining_parameters.grc, Screenshot from ObtainingParameter
> & Screenshot_obtaining_parameters_Terminal)*. *
>
> Marcus I have tried the command "sysctl -w kernel.shmmax" to increase the
> available shared memory but i got (bash: sysctl: command not found).
>
> The good news is that i'm finally able to get the DVBT signal synchronized
> and it was working earlier and i got some video and audio working from the
> source,  please see ( Screenshot_receiving  & 
> Screenshot_after_ISDBT_ofdm_sym_acuistion)
> attached blow. i think the problem was because of  samples dropped, after i
> used *stream to vector & vector to stream* at the start of the flow graph
> i start seeing something working then i was adjusting *SNR* and then it
> was working. Now im not able to get a video don't know why at lease i'm
> getting the constellation  which is good. I'll keep going and trying to get
> the video and audio working again. I'll let you know guys when i have
> something new.
>
> Big Thanks :)
>
> Ihab
>
>
> On 27 November 2015 at 18:20, Ihab Zine  wrote:
>
>>
>>
>> -- Forwarded message --
>> From: *Federico Larroca* 
>> Date: Friday, November 27, 2015
>> Subject: DVBT project receiver probelm
>> To: Ihab Zine 
>>
>>
>> Hi Ihab,
>> You only answered to me, maybe you should forward your mail to the list.
>> Regarding the grc, I would also remove the channel model (used for
>> simulations), as in my experience it consumes much CPU.
>> best
>> Federico
>>
>> 2015-11-27 7:22 GMT-03:00 Ihab Zine :
>>
>>> --
>>> Hi Frederico,Marcus and
>>>
>>> *Ron*
>>>
>>> *I just got access to the system, ill try to follow what you have told
>>> me guys and ill let you know how it goes.*
>>>
>>>
>>> *Thanks*
>>>
>>> *Ihab *
>>>
>>> On 26 November 2015 at 17:22, Federico Larroca 
>>> wrote:
>>>
 Hi Ihab,
 Those "restart aquisition" are generated by the ofdm_sym_acquisition
 block when it does not find a peak on the correlation function he uses to
 detect the beginning of the OFDM symbol. You should verify there is indeed
 a DVB signal precisely at 570 MHz. To do this you may use our "Sym Align
 OFDM" block (not a very nice name) available with gr-isdbt (
 https://github.com/git-artes/gr-isdbt) and check that you see a
 "triangle" (please refer to the readme, the examples, and even the issues
 on our git). The symbol alignment is totally equivalent between DVB-T and
 ISDB-T.
 Moreover, I see several "O"s, meaning that somewhere samples are being
 dropped. That does not help either. If you do not have a very fast machine,
 you may use at the beginning of the flowgraph a "Stream to Vector" followed
 by a "Vector to Stream" with a very big "Num Items" (some millions).
 best
 Federico

 2015-11-26 12:59 GMT-03:00 Ihab Zine :

> Hi,
>
> I’m trying to receive a live signal from an antenna on the roof
> through a cable connected to my SDR (hackrf one ).The bandwidth of the
> DVB-T in ireland is 8 Mhz , and the parametetrs Here in ireland as
> following:
>
> Bandwidth: 8 MHz
> Stream code rate (hi prio): FEC 2/3
> Stream code rate (lo prio): FEC 2/3
> Modulation: QAM 64
> Transmission mode: 8k mode
> Guard interval: 1/32
> Hierarchy: none
>
> 

[Discuss-gnuradio] Asynchronous source with zeros in between

[Francisco Albani]

Hi to all.

(this email subject may be inaccurate)

I need a block with the following characteristics:

* Input port for messages.
* Output port for complex/float/byte/etc. stream.
* Forecast always answers 0.
* Work function first check the message queue. If there are no messages,
emits zeros; if there are, it emits the samples inside the message.

I'm willing to write it, but first I want to hear from the people in the
list in case this can be crafted using existing blocks or if this idea is
deemed to fail for some reason I can't see.

I need this in order to transmit N parallel burst radios using something
like Polyphase Channel Synthesizer. The problem emerges when not all the
transmitters have data to send and stop the other transmitters flows.

Many thanks!

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

Re: [Discuss-gnuradio] running error

[Neel Pandeya]

Hello Kerry:

Perhaps your computer is behind a firewall or proxy server?? Many companies
and universities use them, and they often block these type of downloads.

--Neel



On 30 November 2015 at 13:41, James Humphries 
wrote:

> Hi Kerry,
>
> Did you hook your computer back up to the internet before you ran
> uhd_images_downloader.py?
>
> -Trip
>
> On Mon, Nov 30, 2015 at 3:22 PM, kerry  wrote:
>
>> Hi,all:
>>
>> I try to run an example about gnu radio. The runtime errors are captured
>> as:
>>
>> Using Volk machine: sse4_1_64_orc
>> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
>> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>>
>> FATAL: RuntimeError:
>> Please update the firmware and FPGA images for your device.
>> See the application notes for USRP2/N-Series for instructions.
>> Expected FPGA compatibility number 11, but got 10:
>> The FPGA build is not compatible with the host code build.
>> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
>> path!
>> Please run:
>>
>>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>>
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>>
>> >>> Done
>>
>> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>>
>> Using Volk machine: sse4_1_64_orc
>> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
>> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>>
>> FATAL: No supported devices found to pick from.
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>>
>> >>> Done
>>
>> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> Generating: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> Executing: "/usr/local/share/gnuradio/examples/audio/hello_world.py"
>>
>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.009.000-1-g71985969
>>
>> Using Volk machine: sse4_1_64_orc
>> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
>> built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>>
>> FATAL: RuntimeError:
>> Please update the firmware and FPGA images for your device.
>> See the application notes for USRP2/N-Series for instructions.
>> Expected FPGA compatibility number 11, but got 10:
>> The FPGA build is not compatible with the host code build.
>> Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in your images
>> path!
>> Please run:
>>
>>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>>
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>>
>> >>> Done
>>
>> 
>>
>> But when I run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py".
>>
>> It said that
>>
>> Images destination:  /usr/local/share/uhd/images
>> Downloading images from:
>> http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
>> Downloading images to:   /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
>> Downloader raised an unhandled exception: request() got an unexpected
>> keyword argument 'stream'
>> You can run this again with the '--verbose' flag to see more information
>> If the problem persists, please email the output to: supp...@ettus.com
>> -
>>
>> Could anyone tell my why? Thx.
>>
>> -Kerry
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] running error

[Marcus D. Leech]

On 11/30/2015 08:39 PM, Neel Pandeya wrote:

Hello Kerry:

Perhaps your computer is behind a firewall or proxy server?? Many 
companies and universities use them, and they often block these type 
of downloads.


--Neel

Actually, looking at the message, it looks like an incompatibility 
between whatever version of "python-requests" is on the computer, and
  what uhd_images_downloader.py is expecting see the "unexpected 
keyword argument" error below.






On 30 November 2015 at 13:41, James Humphries 
> wrote:


Hi Kerry,

Did you hook your computer back up to the internet before you ran
uhd_images_downloader.py?

-Trip

On Mon, Nov 30, 2015 at 3:22 PM, kerry > wrote:

Hi,all:

I try to run an example about gnu radio. The runtime errors
are captured as:

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in
your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800;
UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done

Generating:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

Generating:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

Executing:
"/usr/local/share/gnuradio/examples/audio/hello_world.py"

linux; GNU C++ version 4.6.3; Boost_104800;
UHD_003.009.000-1-g71985969

Using Volk machine: sse4_1_64_orc
gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.7.2
built-in source types: file fcd rtl rtl_tcp uhd bladerf rfspace
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

FATAL: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Could not find usrp_n210_fw.bin and usrp_n210_r4_fpga.bin in
your images
path!
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"


Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done



But when I run:
"/usr/local/lib/uhd/utils/uhd_images_downloader.py".

It said that

Images destination:  /usr/local/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_003.009.git-rc1.zip
Downloading images to:
 /tmp/tmpqVXGpZ/uhd-images_003.009.git-rc1.zip
Downloader raised an unhandled exception: request() got an
unexpected
keyword argument 'stream'
You can run this again with the '--verbose' flag to see more
information
If the problem persists, please email the output to:
supp...@ettus.com 

-

Could anyone tell my why? Thx.

-Kerry



--
View this message in context:
http://gnuradio.4.n7.nabble.com/running-error-tp57136.html
Sent from 

[Discuss-gnuradio] Schedule for GNU Radio 3.7.9 release

[Johnathan Corgan]

The next feature release of GNU Radio, 3.7.9, is targeted for mid-late
December, just before the holiday period.  Here are the key dates:

   - 12/07/15 - Feature freeze.  Bug fix merges only until final release;
   git/PyBOMBS users can do testing on master branch
   - 12/11/15 - 3.7.9rc1 tarball and ISO image release - users who do
   source builds and distribution maintainers can test build scripts
   - 12/22/15 - 3.7.9 release tarball, ISO image, gnuradio.org site update

If you have any pending bug fixes or finalized feature branches, please
submit pull requests as soon as possible.

Thank you,

-Johnathan

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SSB/CW/FM tranceiver

[Hi Hello]

Ron,


Thankk you for your answer.  I have 2 USRP1s now and both loads the
firmware correctly, but one refuses to work with ANY "SDR App".

I post a separate thread for that.

Thanks!


On Sun, Nov 8, 2015 at 11:00 PM, Ron Economos  wrote:

> You should be able to replace the osmocom Sink and Source blocks with UHD
> sink and source blocks. Alternatively, you can compile the osmocom blocks
> with UHD support. Then you just have to change the "Device Arguments"
> string to remove the bladeRF specific arguments (probably just leave it
> blank if you only have one USRP).
>
> Also, on my system I had to change the FFT sizes on some of the QT GUI
> Frequency Sink blocks to a power of two.
>
> Ron
>
>
> On 11/08/2015 07:34 AM, Hi Hello wrote:
>
> Ron,
>
>
> Thank you for the info, but does anyone know how to modify the
> Radio.Presidio.grc file to work with the USRP1 ?
>
> That's all I have available to me :
>
> Here's a link to a project.
> http://sodaradio.sourceforge.net/Site/SoDaRadio.html
>
> Also, one of the folks on #bladerf has developed a big ham radio orientated
> GRC flow graph.
>
> http://www.unm.edu/~goatman/RadioPresidio.grc
>
> Ron W6RZ
>
> On 11/07/2015 01:13 PM, Mike Willis wrote:
>
> GQRX works very well but is there or might there be any plans to
> develop a comprehensive tranceiver based on gnuradio?
>
> SDRs like the hackRF and the Ettus USRPs provide great building blocks
> for a VHF/UHF amateur radio station, with only filtering and
> amplification needed to cover all bands from 4m to 6cm, yet I see
> little work on such things, which is odd. Maybe there is no interest
> but there might be.
>
> Mike
>
> ___
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] message port declaration problem after changing to 3.7.8

[David Halls]

Hi Nemanja, Marcus,

Did you get anywhere with this issue?

We have an equivalent problem that sprung up with one of our flow graphs, 
seemingly randomly. We’re not sure what changed…! We then found that *any* of 
our blocks that used MSG input or output ports gave equivalent errors when in 
even the simplest of flowgraphs. The same does not happen with GR blocks.

By rebuilding our whole out of tree module, the problem seems to have gone 
away. For now. Strange…

Also strange is when I click ‘reload blocks’, all MSG connection arrows are 
deleted and have to be redrawn.

Regards,

David

From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On 
Behalf Of Nemanja Savic
Sent: 05 November 2015 12:20
To: Marcus Müller 
Cc: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] message port declaration problem after changing 
to 3.7.8

Hi,
here is a simple photo representing my block. The block is hierarchical and 
consists of a few deframers. When deframers decode correct message, they are 
supposed to send message to db_logger who write information from the message 
into a database. Deframers are written in c++ while db_logger is written in 
python. All deframers have output port whose name is hardcoded to "out_port", 
while db_logger has input port whose name was hardcoded as "in_port"
In previous case, self is db_logger. I have shown there how the message port 
inside that block was defined.

Inside hier block where everything is packed I have lines like this
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger, in_port)
here self references hier block.
Cheers,
Nemanja

On Wed, Nov 4, 2015 at 10:49 PM, Marcus Müller 
> wrote:
I've lost oversight.. is self a hier block, in this case?

On 11/04/2015 06:49 PM, Nemanja Savic wrote:
So, a block called db_logger is written in python and port is defined in 
following way:
self.message_port_register_in(pmt.pmt_intern(in_port))
Well, I am not sure, this works fine in older version.

On Wed, Nov 4, 2015 at 6:41 PM, Marcus Müller 
> wrote:
What does your message_port_register_in call look like?
Or is it a message_port_register_hier_in call? (should it be?)

Cheers,
Marcus

On 11/04/2015 06:37 PM, Nemanja Savic wrote:
Hi,
ok thanks. Does it matter how I everything is declared, but it is clear that 
something changed since 3.6.5.1.
So i have hier block written in python where i define
in_port = 'in_port'
out_port='out_port'
These arguments are passed in the following way:
in_port is receiving port of a block that receives messages from blocks which 
have registered out_block as their transmitting port.
out_port is passed to constructors of all transmitting blocks. They are passed 
as type const char*. Blocks have member d_msg_out_port defined as string. So 
something like this:
d_msg_out_port(msg_out_port)
...
body of constructor:
message_port_register_out(pmt::mp(d_msg_out_port));
So, later on, at the end of hier block I call:
self.msg_connect(self.SFL_90518279_pkt_def, out_port, self.db_logger, in_port)
Could it be that problem is something with strings (I am not sure is null 
character is passed, no idea)?
Nemanja

On Wed, Nov 4, 2015 at 6:26 PM, Marcus Müller 
> wrote:
Hi,

not really, what it says is really "I can't find  in ", with that list being the names of the registered ports.
So, the interesting thing is that seemingly,comparin pmt::symbol("in_port") 
with pmt::symbol("in_port") doesn't quite work well.

I'd have to look into what pmt::comparator looks like; it's my first suspect 
for why that might fail.

Best regards,
Marcus


On 11/04/2015 06:20 PM, Nemanja Savic wrote:
Hi,
hm, could just tell me if I am thinking wrong, but this looks like some of my 
blocks is also called in_port?
Nemanja

On Wed, Nov 4, 2015 at 6:14 PM, Marcus Müller 
> wrote:
Hi Nemanja,

a blind suspicion: as "system" is a port that should be registered by the 
runtime for each block, there might be some confusion happening.
Does it work better when you rename your block to something else?

Best regards,
Marcus

On 11/04/2015 06:05 PM, Nemanja Savic wrote:
Hi all guys,
I recently installed 3.7.8, and before that I had 3.6.5.1.
I was using message passing in some of my blocks, but now I get error which is 
following:
Could not find port: in_port in:
in_port
system

Traceback (most recent call last):
  File "./top_block.py", line 178, in 
tb = top_block()
  File "./top_block.py", line 124, in __init__
self.TPMS_univ_TPMS_rec2_0 = TPMS.univ_TPMS_rec2("WBX_proba", samp_rate, 
0.5, 45, "localhost", 2, "TEST_TRACK_TPMS", "nemanja", "nemanja", 
"det_id_proba", "detectors")
  File 

[Discuss-gnuradio] Compatibility with Mac OS X

[Jeon]

With some struggles, I've finally installed GNU Radio (from the source) on
Mac OS X 10.11 El Captian.

Lots of things including Python and UHD were installed via Homebrew.
Thrift for ControlPort, this is installed from the source.

Some quick test,

1. make test

It says 4 among 201 tests failed:



qa_test_all


qa_polar_decoder_sc


qa_polar_decoder_sc_list


qa_polar_encoder

The rest of the tests, all passed.

2. uhd_usrp_probe

I can successfully probe USRP N210 with one LFTX and one LFRX.

3. gnuradio-companion

I can execute gnuradio-companion.
Although it's not ready for Retina display, that's okay. I don't care.
(But, I didn't run some flow graphs, yet.)

Then, I think GNU Radio will work fine in the most of cases.
However, I still wonder if there is a case that GNU Radio fails to run on
Mac OS X 10.11.

If someone having trouble with Mac OS X El Capitan, I'd like to hear your
case.

*Problems of OOT modules are not my concern

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

Re: [Discuss-gnuradio] Compatibility with Mac OS X

[Michael Dickens]

Hi Jeon - I maintain GNU Radio / Volk / UHD within MacPorts, and they
generally work on OS X 10.8 through 10.11; I know of folks using than on
10.6/7, and I believe they can be coerced into working on 10.5 (Intel or
PPC). There are issues here and there, such as that ControlPort doesn't
really work (Thrift issues on OS X), and sometimes the UHD interface
needs updating between UHD and gr-uhd (rebuilding in the correct order
takes care of this). A few users have issues with GRC on 10.11 that I
don't experience & we're working on debugging them. I'm not sure what
you mean by that GR is "not ready for Retina display" ... I've used a
MacBook Pro retina 15" since 2012 & never had issues except with using
Qt for a while back in 2012-3; I think we fixed that bug in MacPorts's
Qt4 install (but, I might be wrong; it's kinda old now). I know of
others who install GR via HomeBrew, and I'd be curious hear from them as
to how well it functions -- both "make test" as well as actual runtime &
GRC. Good luck! - MLD

On Mon, Nov 30, 2015, at 08:05 AM, Jeon wrote:
> With some struggles, I've finally installed GNU Radio (from the
> source) on Mac OS X 10.11 El Captian.


> Lots of things including Python and UHD were installed via Homebrew.
>
Thrift for ControlPort, this is installed from the source.
> Some quick test,


> 1. make test


> It says 4 among 201 tests failed:


>> qa_test_all


>>  qa_polar_decoder_sc
>>
qa_polar_decoder_sc_list
>>
qa_polar_encoder
> The rest of the tests, all passed.


> 2. uhd_usrp_probe


> I can successfully probe USRP N210 with one LFTX and one LFRX.


> 3. gnuradio-companion


> I can execute gnuradio-companion.
>
Although it's not ready for Retina display, that's okay. I don't care.
>
(But, I didn't run some flow graphs, yet.)
> Then, I think GNU Radio will work fine in the most of cases.
>
However, I still wonder if there is a case that GNU Radio fails to run
on Mac OS X 10.11.
> If someone having trouble with Mac OS X El Capitan, I'd like to hear
> your case.


> *Problems of OOT modules are not my concern


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