From: "address@hidden" <address@hidden>
To: address@hidden
Sent: Tuesday, October 16, 2012 9:00 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 16
Send Discuss-gnuradio mailing list submissions to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help'
to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: cannot make new signal processing block (Tom Rondeau)
2. Re: problem with 3.6.2 (Josh Blum)
3. Very weird about my N210 board. (Pan)
4. Re: Very weird about my N210 board. (Josh Blum)
5. Re: Very weird about my N210 board. (
address@hidden)
6. Re: GRC: set order of block instantiations
(Gerald Baier)
7. Re: Very weird about my N210 board. (Ben Hilburn)
8. Re: GRC: set order of block instantiations (Josh Blum)
9. Wireless Camera Reception? (Joel Mayer)
10. Re: Reg : difference between gr.file_descriptor_source/sink
and gr.file_source/sink (sumitstop)
11. Re: Wireless Camera Reception? (Marcus D. Leech)
12. Re: Discuss-gnuradio Digest, Vol 119, Issue 15
(Usrp_nbfm_ptt.py) (Sajjad Safdar)
13. Re: Discuss-gnuradio Digest, Vol 119, Issue 15
(Usrp_nbfm_ptt.py) (Martin Braun (CEL))
14. Re: cannot make new signal processing block (nexy_sm)
15. Re: cannot make new signal processing block (Martin Braun (CEL))
16. Re: cannot make new signal processing block (nexy_sm)
17. Re: cannot make new signal processing block (Martin Braun (CEL))
18. Re: Wireless Camera Reception? (Tom Rondeau)
19. Re: cannot make new signal processing block (Tom Rondeau)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Oct 2012 12:09:18 -0400
From: Tom Rondeau <
address@hidden>
To: nexy_sm <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID:
<CA+SzT6iXchJbkYoQ=siNjKwt5Ma-E+
address@hidden>
Content-Type: text/plain;
charset=ISO-8859-1
On Mon, Oct 15, 2012 at 11:24 AM, nexy_sm <
address@hidden> wrote:
> Finaly it works.
> Thanks!!!!!!!!!!!!!!!!!!!!!!!
That's great!
Can you say a few words about what you did to get it working for the
benefit of others that might be having problems?
Tom
------------------------------
Message: 2
Date: Mon, 15 Oct 2012 09:27:51 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] problem with 3.6.2
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/14/2012 03:02 PM, Stephen wrote:
>
>
> On 10/14/2012 12:06 PM, Josh Blum wrote:
>>
>>
>>
>> set_history needs to be at least 1.
>>
>> (because this actually means a history of user_history_setting-1 is
>> prepended to the start of the buffer)
>>
>> -josh
>>
>
> thanks for the reply but I don't know what that means. What is
> set_history? I don't explicitly use gr_buffer in my application. I do
> use gr message queues. But all of my message queues are initialized
> with a size.
>
Somewhere (probably) there is a block in your flow graph that is calling
set_history(0). Perhaps you have some filter taps that
are unset (empty
array)?
-josh
> steve
>
------------------------------
Message: 3
Date: Mon, 15 Oct 2012 12:36:26 -0400
From: Pan <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Very weird about my N210 board.
Message-ID:
<CAM7k3FSLNacd2+
address@hidden>
Content-Type: text/plain; charset="gb2312"
Hi,
Sorry for bothering you guys. I encountered some very weird thing about my
N210 board.
When the board is powered up, it seems very thing works well. Actually, I
can even ping this
board. However, if I run any applications in the
applications?such as uhd_fft? uhd/siggen in the /usr/local/bin folder, the
terminal shows there are many errors as following. After that, this board
reset again and again for several minutes. It is very weird! Is there
anyone can tell me what happened with my N210 board. Any suggestion or hint
will be very appreciated. Thank you so much.
Best,
Pan
address@hidden:/usr/local/bin$ ./uhd_siggen
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-255-gc7054ce5
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO.... not found
UHD Error:
The daughterboard manager encountered a recoverable error in init.
Loading the "unknown" daughterboard implementations to continue.
The
daughterboard cannot operate until this error is resolved.
RuntimeError: fifo ctrl timed out looking for acks
UHD Error:
Control packet attempt 0, sequence number 318:
RuntimeError: no control response, possible packet loss
UHD Error:
Control packet attempt 1, sequence number 319:
RuntimeError: no control response, possible packet loss
UHD Error:
Control packet attempt 2, sequence number 320:
RuntimeError: no control response, possible packet loss
UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK
UHD Error:
Control packet attempt 0, sequence number 321:
RuntimeError: no control response,
possible packet loss
UHD Error:
Control packet attempt 1, sequence number 322:
RuntimeError: no control response, possible packet loss
UHD Error:
Control packet attempt 2, sequence number 323:
RuntimeError: no control response, possible packet loss
RuntimeError: fifo ctrl timed out looking for acks
address@hidden:/usr/local/bin$ ./uhd_fft
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-255-gc7054ce5
Traceback (most recent call last):
File "./uhd_fft", line 337, in <module>
main ()
File "./uhd_fft", line 333, in main
app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 38, in __init__
wx.App.__init__ (self, redirect=False)
File
"/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7981, in __init__
self._BootstrapApp()
File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 42, in OnInit
self._max_noutput_items)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 64, in __init__
self.panel = stdpanel (self, self, top_block_maker, max_nouts)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 86, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File "./uhd_fft", line 91, in __init__
otw_format=options.wire_format,
args=options.stream_args))
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 116, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2834, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Empty Device Address
address@hidden:/usr/local/bin$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/ca387f69/attachment.html>
------------------------------
Message: 4
Date: Mon, 15 Oct 2012 09:40:41 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Very weird about my N210 board.
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=UTF-8
On 10/15/2012 09:36 AM, Pan wrote:
> Hi,
>
> Sorry for bothering you guys. I encountered some very weird thing about my
> N210 board.
>
> When the board is powered up, it seems very thing works well. Actually, I
> can even ping this board. However, if I run any applications in the
> applications?such as uhd_fft? uhd/siggen in the /usr/local/bin folder, the
> terminal shows there are many errors as following. After that, this board
> reset again and
again for several minutes. It is very weird! Is there
> anyone can tell me what happened with my N210 board. Any suggestion or hint
> will be very appreciated. Thank you so much.
>
Looks like the ethernet link is dying on you. Could be an issue w/ the
driver for your ethernet card. Can you try a different ethernet or PC
and see if the problem follows?
> Best,
>
> Pan
>
>
>
> address@hidden:/usr/local/bin$ ./uhd_siggen
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-255-gc7054ce5
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Detecting internal GPSDO.... not found
>
> UHD Error:
> The daughterboard manager encountered a recoverable error in init.
> Loading the "unknown" daughterboard
implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> RuntimeError: fifo ctrl timed out looking for acks
>
> UHD Error:
> Control packet attempt 0, sequence number 318:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> Control packet attempt 1, sequence number 319:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> Control packet attempt 2, sequence number 320:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> An unexpected exception was caught in a task loop.
> The task loop will now exit, things may not work.
> RuntimeError: link dead: timeout waiting for control packet
ACK
>
> UHD Error:
> Control packet attempt 0, sequence number 321:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> Control packet attempt 1, sequence number 322:
> RuntimeError: no control response, possible packet loss
>
> UHD Error:
> Control packet attempt 2, sequence number 323:
> RuntimeError: no control response, possible packet loss
> RuntimeError: fifo ctrl timed out looking for acks
> address@hidden:/usr/local/bin$ ./uhd_fft
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-255-gc7054ce5
>
> Traceback (most recent call last):
> File "./uhd_fft", line 337, in <module>
> main ()
> File "./uhd_fft", line 333, in main
> app =
stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 38, in __init__
> wx.App.__init__ (self, redirect=False)
> File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> line 7981, in __init__
> self._BootstrapApp()
> File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> line 7555, in _BootstrapApp
> return _core_.PyApp__BootstrapApp(*args, **kwargs)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 42, in OnInit
> self._max_noutput_items)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 64, in __init__
> self.panel = stdpanel (self, self, top_block_maker, max_nouts)
>
File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> line 86, in __init__
> self.top_block = top_block_maker (frame, self, vbox, sys.argv)
> File "./uhd_fft", line 91, in __init__
> otw_format=options.wire_format, args=options.stream_args))
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 116, in constructor_interceptor
> return old_constructor(*args)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2834, in usrp_source
> return _uhd_swig.usrp_source(*args)
> RuntimeError: LookupError: KeyError: No devices found for ----->
> Empty Device Address
> address@hidden:/usr/local/bin$
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 5
Date: Mon, 15 Oct 2012 12:40:45 -0400
From:
address@hiddenTo: <
address@hidden>
Subject: Re: [Discuss-gnuradio] Very weird about my N210 board.
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
Do you perhaps have more than one device at
the same address on the
same network segment?
Are you running custom firmware/FPGA image on
the N210?
What happens when you flash matching firmware on the N210,
power-cycle it, and run:
uhd_usrp_probe --args "addr=192.168.10.2"
Against it?
On 15 Oct 2012 12:36, Pan wrote:
> Hi,
>
> Sorry for
bothering you guys. I encountered some very weird thing about my N210
board.
>
> When the board is powered up, it seems very thing works
well. Actually, I can even ping this board. However, if I run any
applications in the applications?such as uhd_fft? uhd/siggen in the
/usr/local/bin folder, the terminal shows there are many errors as
following. After that, this board reset again and again for several
minutes. It is very weird! Is there anyone can tell me what happened
with my N210 board. Any suggestion or hint will be very appreciated.
Thank you so
much.
>
> Best,
>
> Pan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/d701746a/attachment.html>
------------------------------
Message: 6
Date: Mon, 15 Oct 2012 21:10:15 +0200
From: Gerald Baier <
address@hidden>
To: <
address@hidden>
Subject: Re: [Discuss-gnuradio] GRC: set order of block instantiations
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
On 11.10.2012 21:03, Gerald Baier wrote:
> is there a way to set the order of block instantiations in GNU Radio
> companion?
> The reason I am asking is, that I want to pass one block as a parameter
> to another block to get access to its methods. Is there an easier way to
> do this?
Just for future reference, I found out that, at least for my purposes,
there already exists an elegant way to access a block's methods. It is
possible to define a "function probe" in GNU Radio companion which
periodically calls a block's method and saves the result as a variable.
Best regards
Gerald
>
> Somehow related: Variables configured in GRC are defined before the
> block instantiations. Is it possible to tell GRC where in the
final
> python script a variable should be defined?
>
> Best regards
>
> Gerald
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
Message: 7
Date: Mon, 15 Oct 2012 12:11:04 -0700
From: Ben Hilburn <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] Very weird about my
N210 board.
Message-ID:
<CAOEVZkLbpdna8vB6KVZ2KQpG6nZFky0_Rmqtv-p5RFpLZBNO=
address@hidden>
Content-Type: text/plain; charset="utf-8"
Also, are you using Network Manager on your PC? If so, have you told it to
ignore the ethernet interface? If not, NM will try to re-negotiate DHCP on
that interface over and over, bringing down your link every time.
Cheers,
Ben
On Mon, Oct 15, 2012 at 9:40 AM, Josh Blum <
address@hidden> wrote:
>
>
> On 10/15/2012 09:36 AM, Pan wrote:
> > Hi,
> >
> > Sorry for bothering you guys. I encountered some very weird thing about
> my
> > N210 board.
> >
> > When the board is powered up, it seems very thing works well. Actually, I
> >
can even ping this board. However, if I run any applications in the
> > applications?such as uhd_fft? uhd/siggen in the /usr/local/bin folder,
> the
> > terminal shows there are many errors as following. After that, this
> board
> > reset again and again for several minutes. It is very weird! Is there
> > anyone can tell me what happened with my N210 board. Any suggestion or
> hint
> > will be very appreciated. Thank you so much.
> >
>
> Looks like the ethernet link is dying on you. Could be an issue w/ the
> driver for your ethernet card. Can you try a different ethernet or PC
> and see if the problem follows?
>
> > Best,
> >
> > Pan
> >
> >
> >
> > address@hidden:/usr/local/bin$ ./uhd_siggen
> > linux; GNU C++ version 4.6.3; Boost_104601;
UHD_003.004.003-255-gc7054ce5
> >
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > -- Detecting internal GPSDO.... not found
> >
> > UHD Error:
> > The daughterboard manager encountered a recoverable error in init.
> > Loading the "unknown" daughterboard implementations to continue.
> > The daughterboard cannot operate until this error is resolved.
> > RuntimeError: fifo ctrl timed out looking for acks
> >
> > UHD Error:
> > Control packet attempt 0, sequence number 318:
> > RuntimeError: no control response, possible packet loss
> >
> > UHD Error:
> > Control packet attempt 1, sequence number 319:
> >
RuntimeError: no control response, possible packet loss
> >
> > UHD Error:
> > Control packet attempt 2, sequence number 320:
> > RuntimeError: no control response, possible packet loss
> >
> > UHD Error:
> > An unexpected exception was caught in a task loop.
> > The task loop will now exit, things may not work.
> > RuntimeError: link dead: timeout waiting for control packet ACK
> >
> > UHD Error:
> > Control packet attempt 0, sequence number 321:
> > RuntimeError: no control response, possible packet loss
> >
> > UHD Error:
> > Control packet attempt 1, sequence number 322:
> > RuntimeError: no control response, possible packet loss
> >
> > UHD
Error:
> > Control packet attempt 2, sequence number 323:
> > RuntimeError: no control response, possible packet loss
> > RuntimeError: fifo ctrl timed out looking for acks
> > address@hidden:/usr/local/bin$ ./uhd_fft
> > linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-255-gc7054ce5
> >
> > Traceback (most recent call last):
> > File "./uhd_fft", line 337, in <module>
> > main ()
> > File "./uhd_fft", line 333, in main
> > app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)
> > File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> > line 38, in __init__
> > wx.App.__init__ (self, redirect=False)
> > File
>
"/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> > line 7981, in __init__
> > self._BootstrapApp()
> > File
> "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> > line 7555, in _BootstrapApp
> > return _core_.PyApp__BootstrapApp(*args, **kwargs)
> > File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> > line 42, in OnInit
> > self._max_noutput_items)
> > File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> > line 64, in __init__
> > self.panel = stdpanel (self, self, top_block_maker, max_nouts)
> > File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
> > line 86, in __init__
> > self.top_block =
top_block_maker (frame, self, vbox, sys.argv)
> > File "./uhd_fft", line 91, in __init__
> > otw_format=options.wire_format, args=options.stream_args))
> > File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> > line 116, in constructor_interceptor
> > return old_constructor(*args)
> > File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> > line 2834, in usrp_source
> > return _uhd_swig.usrp_source(*args)
> > RuntimeError: LookupError: KeyError: No devices found for ----->
> > Empty Device Address
> > address@hidden:/usr/local/bin$
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/18083918/attachment.html>
------------------------------
Message: 8
Date: Mon, 15 Oct 2012 12:44:07 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] GRC: set order of block instantiations
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/15/2012 12:10 PM, Gerald Baier wrote:
> On 11.10.2012 21:03, Gerald Baier wrote:
>> is there a way to set the order of block instantiations in GNU Radio
>> companion?
>> The reason I am asking is, that
I want to pass one block as a parameter
>> to another block to get access to its methods. Is there an easier way to
>> do this?
> Just for future reference, I found out that, at least for my purposes,
> there already exists an elegant way to access a block's methods. It is
> possible to define a "function probe" in GNU Radio companion which
> periodically calls a block's method and saves the result as a variable.
Sorry, should have mentioned that too!
Function probe gets around this by having a try/catch in its loop so the
block to be probed doesnt have to yet be instantiated when the thread
starts.
-josh
>
> Best regards
>
> Gerald
>>
>> Somehow related: Variables configured in GRC are defined before the
>> block instantiations. Is it possible to tell GRC where in the final
>> python script a variable should be
defined?
>>
>> Best regards
>>
>> Gerald
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
address@hidden>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
Message: 9
Date: Mon, 15 Oct 2012 17:26:58 -0500
From:
"Joel Mayer" <
address@hidden>
To: <
address@hidden>, <
address@hidden>
Subject: [Discuss-gnuradio] Wireless Camera Reception?
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear GNUradio enthusiasts-
Beneath these lines (attached as a virus free pdf) you will find a table of frequencies
assigned to wireless cameras. I'm wondering, would it be possible to modify the SDR#
radio in such a way as to make it wireless camera capable?
Thanks
For Reading This!
FREQUENCY
VIDEO MODE
MANUFACTURER
USE/ALLOCATION
2.411 Ghz
NFMTV
X-10
Channel A
2.434 Ghz
NFMTV
X-10
Channel B
2.453 Ghz
NFMTV
X-10
Channel C
2.473 Ghz
NFMTV
X-10
Channel D
2.400 Ghz
NFMTV
PTS
Channel A
2.428 Ghz
NFMTV
PTS
Channel B
2.456 Ghz
NFMTV
PTS
Channel C
2.484 Ghz
NFMTV
PTS
Channel D
2.411 Ghz
NFMTV
HPAL16/07/02
Channel A
2.434 Ghz
NFMTV
HPAL16/07/02
Channel B
2.411 Ghz
NFMTV
ARL0225/5200/1500
Channel A
2.434 Ghz
NFMTV
ARL0225/5200/1500
Channel B
2.458 Ghz
NFMTV
Minilink 2.4 T-90
Channel A
2.474
Ghz
NFMTV
Minilink 2.4 T-90
Channel B
421.250 Mhz
ATV
ATV Cable Ch 59
Channel 57
427.250 Mhz
ATV
ATV Cable Ch 59
Channel 58
433.250 Mhz
ATV
ATV Cable Ch 59
Channel 59
439.250 Mhz
ATV
ATV Cable Ch 59
Channel 60
2.400 Ghz
NFMTV
Matco Wireless
2.427 Ghz
NFMTV
Matco Wireless
2.454 Ghz
NFMTV
Matco Wireless
2.481 Ghz
NFMTV
Matco Wireless
2.413 Ghz
NFMTV
ECL2400 Mini
Channel 1
2.432 Ghz
NFMTV
ECL2400 Mini
Channel 2
2.451 Ghz
NFMTV
ECL2400 Mini
Channel 3
2.470 Ghz
NFMTV
ECL2400 Mini
Channel 4
1.080 Ghz
NFMTV
ECL2400CK/ LCD
Channel 1
1.120
Ghz
NFMTV
ECL2400CK/ LCD
Channel 2
1.160 Ghz
NFMTV
ECL2400CK/ LCD
Channel 3
1.200 Ghz
NFMTV
ECL2400CK/ LCD
Channel 4
2.4125 Ghz
NFMTV
Internet Videocomms
2.4325 Ghz
NFMTV
Internet Videocomms
2.4525 Ghz
NFMTV
Internet Videocomms
2.4725 Ghz
NFMTV
Internet Videocomms
2.4 - 2.4835 Ghz
NFMTV
Home Spy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/0c189218/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WirelessCam FreqsRadio .pdf
Type: application/pdf
Size: 7865 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/0c189218/attachment.pdf>
------------------------------
Message: 10
Date: Mon, 15 Oct 2012 16:29:19 -0700
(PDT)
From: sumitstop <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Reg : difference between
gr.file_descriptor_source/sink and gr.file_source/sink
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Thanks Tom .. got it !!
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Reg-difference-between-gr-file-descriptor-source-sink-and-gr-file-source-sink-tp37991p38015.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 11
Date: Mon, 15 Oct 2012 19:31:49 -0400
From: "Marcus D. Leech" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Wireless Camera Reception?
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 10/15/2012 06:26 PM, Joel Mayer wrote:
> Dear GNUradio enthusiasts-
> Beneath these lines (attached as a
virus free pdf) you will find a
> table of frequencies
> assigned to wireless cameras. I'm wondering, would it be possible to
> modify the SDR#
> radio in such a way as to make it wireless camera capable?
> Thanks For Reading This!
>
> *FREQUENCY*
>
>
>
> *VIDEO MODE*
>
>
>
> *MANUFACTURER*
>
>
>
> *USE/ALLOCATION*
>
> 2.411 Ghz
>
>
>
> NFMTV
>
>
>
> X-10
>
>
>
> Channel A
>
> 2.434 Ghz
>
>
>
> NFMTV
>
>
>
> X-10
>
>
>
> Channel B
>
> 2.453 Ghz
>
>
>
> NFMTV
>
>
>
> X-10
>
>
>
> Channel C
>
> 2.473 Ghz
>
>
>
> NFMTV
>
>
>
> X-10
>
>
>
> Channel D
>
> 2.400 Ghz
>
>
>
> NFMTV
>
>
>
> PTS
>
>
>
> Channel A
>
> 2.428 Ghz
>
>
>
> NFMTV
>
>
>
> PTS
>
>
>
> Channel B
>
> 2.456 Ghz
>
>
>
> NFMTV
>
>
>
> PTS
>
>
>
> Channel C
>
>
2.484 Ghz
>
>
>
> NFMTV
>
>
>
> PTS
>
>
>
> Channel D
>
> 2.411 Ghz
>
>
>
> NFMTV
>
>
>
> HPAL16/07/02
>
>
>
> Channel A
>
> 2.434 Ghz
>
>
>
> NFMTV
>
>
>
> HPAL16/07/02
>
>
>
> Channel B
>
> 2.411 Ghz
>
>
>
> NFMTV
>
>
>
> ARL0225/5200/1500
>
>
>
> Channel A
>
> 2.434 Ghz
>
>
>
> NFMTV
>
>
>
>
ARL0225/5200/1500
>
>
>
> Channel B
>
> 2.458 Ghz
>
>
>
> NFMTV
>
>
>
> Minilink 2.4 T-90
>
>
>
> Channel A
>
> 2.474 Ghz
>
>
>
> NFMTV
>
>
>
> Minilink 2.4 T-90
>
>
>
> Channel B
>
> 421.250 Mhz
>
>
>
> ATV
>
>
>
> ATV Cable Ch 59
>
>
>
> Channel 57
>
> 427.250 Mhz
>
>
>
> ATV
>
>
>
> ATV Cable Ch 59
>
>
>
> Channel 58
>
> 433.250
Mhz
>
>
>
> ATV
>
>
>
> ATV Cable Ch 59
>
>
>
> Channel 59
>
> 439.250 Mhz
>
>
>
> ATV
>
>
>
> ATV Cable Ch 59
>
>
>
> Channel 60
>
> 2.400 Ghz
>
>
>
> NFMTV
>
>
>
> Matco Wireless
>
>
>
> 2.427 Ghz
>
>
>
> NFMTV
>
>
>
> Matco Wireless
>
>
>
> 2.454 Ghz
>
>
>
> NFMTV
>
>
>
> Matco Wireless
>
>
>
> 2.481 Ghz
>
>
>
> NFMTV
>
>
>
> Matco Wireless
>
>
>
> 2.413 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400 Mini
>
>
>
> Channel 1
>
> 2.432 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400 Mini
>
>
>
> Channel 2
>
> 2.451 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400 Mini
>
>
>
> Channel 3
>
> 2.470 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400
Mini
>
>
>
> Channel 4
>
> 1.080 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400CK/ LCD
>
>
>
> Channel 1
>
> 1.120 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400CK/ LCD
>
>
>
> Channel 2
>
> 1.160 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400CK/ LCD
>
>
>
> Channel 3
>
> 1.200 Ghz
>
>
>
> NFMTV
>
>
>
> ECL2400CK/ LCD
>
>
>
> Channel 4
>
> 2.4125 Ghz
>
>
>
> NFMTV
>
>
>
> Internet Videocomms
>
>
>
> 2.4325 Ghz
>
>
>
> NFMTV
>
>
>
> Internet Videocomms
>
>
>
> 2.4525 Ghz
>
>
>
> NFMTV
>
>
>
> Internet Videocomms
>
>
>
> 2.4725 Ghz
>
>
>
> NFMTV
>
>
>
> Internet Videocomms
>
>
>
> 2.4 - 2.4835 Ghz
>
>
>
> NFMTV
>
>
>
> Home Spy
>
>
>
>
>
_______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioNot to be a pedantic piss head or anything, but what in the name of all
of Mary's children does SDR# have to do with Gnu Radio?
Other than they support an overlapping set of radio devices, they are
entirely different and distinct signal processing frameworks.
Indeed, SDR# isn't a signal processing "framework" so much as it is
an end-application that has a bit of a "plug in" architecture.
I'd suggest that you contact, Youssef, the guy who wrote SDR# and see if
he has plans for an FMTV plug-in. Keep in mind that FMTV
occupies about 10Mhz of
bandwidth, so you need a fairly "crunchy"
computer to process the frames.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/5b15cff6/attachment.html>
------------------------------
Message: 12
Date: Tue, 16 Oct 2012 01:14:30 -0700 (PDT)
From: Sajjad Safdar <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 119,
Issue 15 (Usrp_nbfm_ptt.py)
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear Martin,
Yes i can see that i hve errors because of the red marks, but i first want to know that whether i have all the control stuff in my reciever as from usrp_nbfm_ptt.py or should i have to add some more stuff which is not exactly translated into my GRC.
Best Regards,
SAJJAD SAFDAR
________________________________
From: "
address@hidden" <
address@hidden>
To:
address@hidden Sent: Monday, October 15, 2012 9:00 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 15
Send Discuss-gnuradio mailing list submissions to
???
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
???
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help' to
???
address@hiddenYou can reach the person managing the list at
???
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
? 1. Re: problem with 3.6.2 (Josh Blum)
? 2. Re: problem with 3.6.2 (Stephen)
? 3. Help to understand "UHD AMsg Source" (Jose Torres Diaz)
? 4. Re: Error using block UHD AMsg Source (Jose Torres Diaz)
? 5. Re: Error using block UHD AMsg Source (Jose Torres Diaz)
? 6. Re: cannot make new signal processing block (nexy_sm)
? 7. Re: 4. Re: usrp_nbfm_ptt.py in Gnu Radio??? Companion. (Martin
? ? ? Braun (CEL)) Discuss-gnuradio Digest,??? Vol 119, Issue 13
? ? ?
(Sajjad Safdar)
? 8. Re: cannot make new signal processing block (Tom Rondeau)
? 9. Re: Reg : difference between gr.file_descriptor_source/sink
? ? ? and gr.file_source/sink (Tom Rondeau)
? 10. Re: OOK Modulation (Tom Rondeau)
? 11. Re: Can the io signatur of the gnuradio blocks be dynamically
? ? ? updated? (Tom Rondeau)
? 12. How to report to gnuradio.org (Pol Henarejos)
? 13. Re: How to report to gnuradio.org (Tom Rondeau)
? 14. Re: cannot make new signal processing block (nexy_sm)
----------------------------------------------------------------------
Message: 1
Date: Sun, 14 Oct 2012 10:06:43 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] problem with
3.6.2
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/13/2012 11:36 AM, Stephen wrote:
>
> Hi,
>
> I was using 3.6 with no issues. Today I updated to 3.6.3 and get the
> following error when I try to start the flowgraph. I did rebuild all
> parts of my application.
>
> terminate called after throwing an instance of 'Using Volk machine:
> sse4_1_64_orc
> std::invalid_argument'
>? what():? gr_buffer_add_reader: nzero_preload must be >= 0
> The program has unexpectedly finished.
>
> Does anyone have any idea where I could start looking?
set_history needs to be at least 1.
(because this actually means a history of user_history_setting-1 is
prepended to the start of the
buffer)
-josh
>
> thanks,
> steve
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 2
Date: Sun, 14 Oct 2012 17:02:24 -0500
From: Stephen <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] problem with 3.6.2
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/14/2012 12:06 PM, Josh Blum wrote:
>
>
>
> set_history needs to be at least 1.
>
> (because this actually means a history of user_history_setting-1 is
> prepended to the start of the buffer)
>
> -josh
>
thanks for the reply but I don't know what that means. What is
set_history? I don't explicitly use gr_buffer in my application. I do
use? gr message queues. But all of my message queues are initialized
with a size.
steve
------------------------------
Message: 3
Date: Mon, 15 Oct 2012 09:32:32 +1030
From: Jose Torres Diaz <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Help to understand "UHD AMsg Source"
Message-ID:
??? <CANLn+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Community,
I would like to ask if someone can give a hand to figure out how "UHD AMsg
Source" block works. I mean, I would like to understand in particular how
this block can post message using pmt_dict type. The piece of routine that
I'm keen on it's this:
void post_async_md(const uhd::async_metadata_t &md){
? ? ? ? pmt::pmt_t value_dict =
pmt::pmt_make_dict();
? ? ? ? if (md.has_time_spec){
? ? ? ? ? ? pmt::pmt_t timestamp = pmt::pmt_make_tuple(
? ? ? ? ? ? ? ? pmt::pmt_from_uint64(md.time_spec.get_full_secs()),
? ? ? ? ? ? ? ? pmt::pmt_from_double(md.time_spec.get_frac_secs())
? ? ? ? ? ? );
? ? ? ? ? ? pmt::pmt_dict_add(value_dict, TIME_KEY, timestamp);
? ? ? ? }
? ? ? ? pmt::pmt_dict_add(value_dict, CHAN_KEY,
pmt::pmt_from_uint64(md.channel));
? ? ? ? pmt::pmt_dict_add(value_dict, EVENT_KEY,
pmt::pmt_from_uint64(md.event_code));
? ? ? ? *this->post_msg(0, AMSG_KEY, value_dict, _id); // <--Here the
message is post downstream, but using pmt_dict*
? ? }
I've tried to create my own block using stream to blob, using pmt_dict.
However, it was not possible to do such a post message with a pmt_dict type
of variable.
I think I'm missing/misunderstanding something important in this block UHD
AMsg source, that allows to post
dictionaries downstream. However, I
couldn't figure out what it is.
Thanks a lot for your comments and help,
Regards,
Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/648b3a47/attachment.html>
------------------------------
Message: 4
Date: Mon, 15 Oct 2012 11:54:12 +1030
From: Jose Torres Diaz <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re:
[Discuss-gnuradio] Error using block UHD AMsg Source
Message-ID:
??? <CANLn+is=wK4DDcpMLxtye=ZnV+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
You mentioned that:
"the code to add a key/value actually returns a new dictionary and doesnt
change the old ones.
I know this pmt stuff is crazy. Why didnt we just use std::map? :-)"
I'm confused with this, because I created the dictionary and added the
values. However, when I've checked the type, it shows that it is a
dictionary (as I expected), but also it is always empty.
? ? ? pmt::pmt_t value_dict = pmt::pmt_make_dict();
? ? ? std::cout << std::endl << "Making a dictionary" << std::endl;
? ? ? pmt::pmt_dict_add(value_dict, TIME_KEY,?
pmt::pmt_from_uint64(3200));
? ? ? ? ? ? this->post_msg(0, AMSG_KEY, value_dict, _id);
? ? ? std::cout << std::endl << "Posting downstream" << std::endl;
? std::cout << std::endl << "checking if null:"
<<pmt::pmt_is_null(value_dict)<< std::endl; //Return true
? std::cout << std::endl << "checking if dict:"
<<pmt::pmt_is_dict(value_dict)<< std::endl; //Return true
So, does it mean that I cannot access the values that are added into the
dictionary "value_dict"?. If it is possible, how should I access them?.
*Sort of related question:*
Since this is dictionary, in order to debug my code I printed out the
items, keys and values. I expected to see at least the items inside the
dictionary, but again everything is empty.
std::cout << std::endl << "Checking items ;"
<<
pmt::pmt_dict_items(value_dict)<<std::endl;
std::cout << std::endl << "Checking keys ;" <<
pmt::pmt_dict_keys(value_dict)<<std::endl;
std::cout << std::endl << "Checking values;" <<
pmt::pmt_dict_values(value_dict)<<std::endl;
Thanks a lot for your help,
Kind Regards,
Jose
On Thu, Oct 11, 2012 at 2:43 PM, Josh Blum <
address@hidden> wrote:
>
>
> On 10/10/2012 07:16 PM, Jose Torres Diaz wrote:
> > Hi Josh,
> >
> > I am very keen on this block (UHD_AMSG_SOURCE), because I saw that you
> post
> > a dictionary downstream in this example. Thus, I would like to analyze
> how
> > it works. I've tried to replicate your code in a different block, but I
> > have some issues with the
dictionary.
> >
> > Here is my summary:
> >
> > *Issue (1):* According to the wiki:
> >
http://gnuradio.org/redmine/projects/gnuradio/wiki/TypePMT#Dictionaries.
> If
> > I want to set values in the dictionary, I should use
> >
> > pmt_dict_set(%parameters here)
>
> Doesnt exist. I think it should be added. This version could add the
> key/value to the existing dictionary. vs the pmt_dict_add which creates
> a new one
>
> >
> > However, this command it doesn't work for me (as it is not part of pmt).
> >
> > The command that works without problem is:
> >
> > pmt_dict_add(%parameters here)
> >
> >
> > *Issue (2):* I've set a dictionary with one value on it. (See the
code
> > below). However, it is always empty when I tried to check the items, keys
> > or values:
> >
> > pmt::pmt_t value_dict=pmt::pmt_make_dict();
> >? ? std::cout << std::endl << "Making a dictionary : " << value_dict
> > <<std::endl;
> >? ? pmt::pmt_dict_add (value_dict,blob_key,pmt::pmt_from_uint64(10));
> >? ? std::cout << std::endl << "Adding the value, items : " <<
> > pmt::pmt_dict_items(value_dict) <<std::endl;
> >? ? std::cout << std::endl << "Adding the value, keys : " <<
> > pmt::pmt_dict_keys(value_dict) <<std::endl;
> >? ? std::cout << std::endl << "Adding the value, values : " <<
> > pmt::pmt_dict_values(value_dict) <<std::endl;
> >
> > Results (always empty!):
>
> the
code to add a key/value actually returns a new dictionary and doesnt
> change the old ones.
>
> I know this pmt stuff is crazy. Why didnt we just use std::map? :-)
>
> >
> > Adding the value, items : ()
> > Adding the value, keys : ()
> > Adding the value, values : ()
> >
> >
> > *Issue (3):* I post the dictionary downstream similar to the code in
> > "UHD_AMSG_SOURCE":
> >
> > this->post_msg(0,value_dict,_msg.value,_id);
>
> The key has to the a pmt that holds a string, the value does not have
> the restriction.
>
> >
> > However, similarly to my previous post, the flow graph complains that
> this
> > is a wrong type:
> >
> > thread[thread-per-block[8]: <gr_block msg_sourcer (9)>]:
> > gr_block_detail::add_item_tag key: wrong_type : ()
>
>
> > For these reasons, I would like to see how your code is working with
> these
> > dictionaries.
> >
> > Thanks again,
> >
> > Jose
> >
> > On Thu, Oct 11, 2012 at 12:05 PM, Jose Torres Diaz <
> >
address@hidden> wrote:
> >
> >> Hi Josh,
> >>
> >> I've changed the .xml file. Also, I've checked the new top_block.py file
> >> and it is generated as follows:
> >>
> >> self.extras_uhd_amsg_source_0 =
> >> gr_extras.uhd_amsg_source(uhd.device_addr="172.17.3.140"
> >>
> >> However, it is still complaining when I run the flow graph:
> >>
> >>? File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
>
line 33
> >>? ? self.extras_uhd_amsg_source_0 =
> >> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
> >> SyntaxError: keyword can't be an _expression_
> >>
> >> Thanks,
> >>
> >> Jose.
> >>
> >>
> >>
> >> On Thu, Oct 11, 2012 at 11:44 AM, Josh Blum <
address@hidden> wrote:
> >>
> >>>
> >>>
> >>> On 10/10/2012 06:09 PM, Jose Torres Diaz wrote:
> >>>> Hi Josh,
> >>>>
> >>>> Do you mean to change in the top_block.py?. I did this, but when I run
> >>>> again the top_block.py, it changes back to:
> >>>>
> >>>>
gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
> >>>>
> >>>> even if I try:
> >>>>
> >>>> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
> >>>>
> >>>> Thanks again Josh,
> >>>>
> >>>
> >>> I see. Its the xml definition. Too bad python/swig does get the
> >>> constructor overloads that c++ sees.
> >>>
> >>> I pushed this change to the repo:
> >>>> diff --git a/grc/extras_uhd_amsg_source.xml
> >>> b/grc/extras_uhd_amsg_source.xml
> >>>> index 5f8c261..5bb59f0 100644
> >>>> --- a/grc/extras_uhd_amsg_source.xml
> >>>> +++ b/grc/extras_uhd_amsg_source.xml
> >>>> @@ -4,7 +4,7 @@
> >>>>? ? ?
<key>extras_uhd_amsg_source</key>
> >>>>? ? ? <import>from gnuradio import uhd</import>
> >>>>? ? ? <import>import gnuradio.extras as gr_extras</import>
> >>>> -? ? <make>gr_extras.uhd_amsg_source(device_addr=$dev_addr)</make>
> >>>> +
>? <make>gr_extras.uhd_amsg_source(uhd.device_addr($dev_addr))</make>
> >>>>? ? ? <param>
> >>>>? ? ? ? ? <name>Device Addr</name>
> >>>>? ? ? ? ? <key>dev_addr</key>
> >>>
> >>> -josh
> >>>
> >>>> Regards,
> >>>>
> >>>> Jose
> >>>>
> >>>> On Thu, Oct 11, 2012 at 11:24 AM, Josh Blum <
address@hidden>
> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 10/10/2012 05:51 PM, Jose Torres Diaz wrote:
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I'm checking the functionality of the block "UHD AMsg Source" using
> >>> the
> >>>>>> USRP N210. The device is correctly detected as you can see:
> >>>>>>
> >>>>>> uhd_find_devices
> >>>>>> linux; GNU C++ version 4.6.1; Boost_104601;
> >>> UHD_003.004.003-221-g9d6f9492
> >>>>>>
> >>>>>> --------------------------------------------------
> >>>>>> -- UHD Device 0
> >>>>>>
--------------------------------------------------
> >>>>>> Device Address:
> >>>>>>? ? type: usrp2
> >>>>>>? ? addr: 172.17.3.140
> >>>>>>? ? name:
> >>>>>>? ? serial: E0R17TCUP
> >>>>>>
> >>>>>> I've attached a screen-shot of the GRC file. When I run the flow
> >>> graph, I
> >>>>>> get the following error:
> >>>>>>
> >>>>>> Traceback (most recent call last):
> >>>>>>? File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
> >>> line
> >>>>>> 54, in <module>
> >>>>>>? ? tb = top_block()
> >>>>>>? File "/home/asrpuser/Desktop/Jose
Torres Material /top_block.py",
> >>> line
> >>>>>> 33, in __init__
> >>>>>>? ? self.extras_uhd_amsg_source_0 =
> >>>>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
> >>>>>
> >>>>> try gr_extras.uhd_amsg_source(uhd.device_addr("addr=172.17.3.140"))
> >>>>>
> >>>>>>? File
> >>>>>>
> >>>
> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
> >>>>>> line 5384, in make
> >>>>>>? ? return _extras_swig.uhd_amsg_source_make(*args, **kwargs)
> >>>>>> TypeError: in method 'uhd_amsg_source_make', argument 1 of type
> >>>>>> 'uhd::device_addr_t const &'
> >>>>>>
>
>>>>>> Anyone has seen an error like this before?, How can? I
> >>> solve/workaround
> >>>>>> this error?
> >>>>>>
> >>>>>> Thanks a lot for your help,
> >>>>>>
> >>>>>> Jose.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Discuss-gnuradio mailing list
> >>>>>>
address@hidden> >>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>>
> >>>>>
>
>>>>> _______________________________________________
> >>>>> Discuss-gnuradio mailing list
> >>>>>
address@hidden> >>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/2e38622b/attachment.html>
------------------------------
Message: 5
Date: Mon, 15 Oct 2012 12:16:25 +1030
From: Jose Torres Diaz <
address@hidden>
To:
address@hiddenCc:
address@hiddenSubject: Re: [Discuss-gnuradio] Error using block UHD AMsg Source
Message-ID:
??? <CANLn+
address@hidden>
Content-Type: text/plain;
charset="iso-8859-1"
Hi Josh,
I've figure out the problem. I didn't check this:
https://github.com/guruofquality/grextras/commit/075bf6ec7e9f8169d9dee59fb9e74d13146b6ddbwhere you changed this:
- pmt::pmt_dict_add(value_dict, TIME_KEY, timestamp);
+ value_dict = pmt::pmt_dict_add(value_dict, TIME_KEY, timestamp);
Thanks,
Jose.
On Mon, Oct 15, 2012 at 11:54 AM, Jose Torres Diaz <
address@hidden> wrote:
> Hi Josh,
>
> You mentioned that:
>
>
> "the code to add a key/value actually returns a new dictionary and doesnt
> change the old ones.
>
> I know this pmt stuff is crazy. Why didnt we just use std::map?
:-)"
>
> I'm confused with this, because I created the dictionary and added the
> values. However, when I've checked the type, it shows that it is a
> dictionary (as I expected), but also it is always empty.
>
>? ? ? pmt::pmt_t value_dict = pmt::pmt_make_dict();
>? ? ? std::cout << std::endl << "Making a dictionary" << std::endl;
>? ? ? pmt::pmt_dict_add(value_dict, TIME_KEY,? pmt::pmt_from_uint64(3200));
>? ? ? ? ? ? this->post_msg(0, AMSG_KEY, value_dict, _id);
>? ? ? std::cout << std::endl << "Posting downstream" << std::endl;
>
>? std::cout << std::endl << "checking if null:"
> <<pmt::pmt_is_null(value_dict)<< std::endl; //Return true
>? std::cout << std::endl << "checking if dict:"
> <<pmt::pmt_is_dict(value_dict)<< std::endl;
//Return true
>
> So, does it mean that I cannot access the values that are added into the
> dictionary "value_dict"?. If it is possible, how should I access them?.
>
> *Sort of related question:*
>
> Since this is dictionary, in order to debug my code I printed out the
> items, keys and values. I expected to see at least the items inside the
> dictionary, but again everything is empty.
>
> std::cout << std::endl << "Checking items ;" <<
> pmt::pmt_dict_items(value_dict)<<std::endl;
> std::cout << std::endl << "Checking keys ;" <<
> pmt::pmt_dict_keys(value_dict)<<std::endl;
> std::cout << std::endl << "Checking values;" <<
> pmt::pmt_dict_values(value_dict)<<std::endl;
>
>
> Thanks a lot for your help,
>
> Kind Regards,
>
>
Jose
>
>
> On Thu, Oct 11, 2012 at 2:43 PM, Josh Blum <
address@hidden> wrote:
>
>>
>>
>> On 10/10/2012 07:16 PM, Jose Torres Diaz wrote:
>> > Hi Josh,
>> >
>> > I am very keen on this block (UHD_AMSG_SOURCE), because I saw that you
>> post
>> > a dictionary downstream in this example. Thus, I would like to analyze
>> how
>> > it works. I've tried to replicate your code in a different block, but I
>> > have some issues with the dictionary.
>> >
>> > Here is my summary:
>> >
>> > *Issue (1):* According to the wiki:
>> >
http://gnuradio.org/redmine/projects/gnuradio/wiki/TypePMT#Dictionaries.
>> If
>> > I want to set values in the dictionary, I should use
>> >
>> > pmt_dict_set(%parameters here)
>>
>> Doesnt exist. I think it should be added. This version could add the
>> key/value to the existing dictionary. vs the pmt_dict_add which creates
>> a new one
>>
>> >
>> > However, this command it doesn't work for me (as it is not part of pmt).
>> >
>> > The command that works without problem is:
>> >
>> > pmt_dict_add(%parameters here)
>> >
>> >
>> > *Issue (2):* I've set a dictionary with one value on it. (See the code
>> > below). However, it is always empty when I tried to check the items,
>> keys
>> > or values:
>>
>
>> > pmt::pmt_t value_dict=pmt::pmt_make_dict();
>> >? ? std::cout << std::endl << "Making a dictionary : " << value_dict
>> > <<std::endl;
>> >? ? pmt::pmt_dict_add (value_dict,blob_key,pmt::pmt_from_uint64(10));
>> >? ? std::cout << std::endl << "Adding the value, items : " <<
>> > pmt::pmt_dict_items(value_dict) <<std::endl;
>> >? ? std::cout << std::endl << "Adding the value, keys : " <<
>> > pmt::pmt_dict_keys(value_dict) <<std::endl;
>> >? ? std::cout << std::endl << "Adding the value, values : " <<
>> > pmt::pmt_dict_values(value_dict) <<std::endl;
>> >
>> > Results (always empty!):
>>
>> the code to add a key/value actually returns a new dictionary and
doesnt
>> change the old ones.
>>
>> I know this pmt stuff is crazy. Why didnt we just use std::map? :-)
>>
>> >
>> > Adding the value, items : ()
>> > Adding the value, keys : ()
>> > Adding the value, values : ()
>> >
>> >
>> > *Issue (3):* I post the dictionary downstream similar to the code in
>> > "UHD_AMSG_SOURCE":
>> >
>> > this->post_msg(0,value_dict,_msg.value,_id);
>>
>> The key has to the a pmt that holds a string, the value does not have
>> the restriction.
>>
>> >
>> > However, similarly to my previous post, the flow graph complains that
>> this
>> > is a wrong type:
>> >
>> > thread[thread-per-block[8]: <gr_block msg_sourcer (9)>]:
>> >
gr_block_detail::add_item_tag key: wrong_type : ()
>> >
>> > For these reasons, I would like to see how your code is working with
>> these
>> > dictionaries.
>> >
>> > Thanks again,
>> >
>> > Jose
>> >
>> > On Thu, Oct 11, 2012 at 12:05 PM, Jose Torres Diaz <
>> >
address@hidden> wrote:
>> >
>> >> Hi Josh,
>> >>
>> >> I've changed the .xml file. Also, I've checked the new top_block.py
>> file
>> >> and it is generated as follows:
>> >>
>> >> self.extras_uhd_amsg_source_0 =
>> >> gr_extras.uhd_amsg_source(uhd.device_addr="172.17.3.140"
>> >>
>> >> However, it is still
complaining when I run the flow graph:
>> >>
>> >>? File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
>> line 33
>> >>? ? self.extras_uhd_amsg_source_0 =
>> >> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
>> >> SyntaxError: keyword can't be an _expression_
>> >>
>> >> Thanks,
>> >>
>> >> Jose.
>> >>
>> >>
>> >>
>> >> On Thu, Oct 11, 2012 at 11:44 AM, Josh Blum <
address@hidden>
>> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 10/10/2012 06:09 PM, Jose Torres Diaz wrote:
>> >>>> Hi Josh,
>> >>>>
>>
>>>> Do you mean to change in the top_block.py?. I did this, but when I
>> run
>> >>>> again the top_block.py, it changes back to:
>> >>>>
>> >>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
>> >>>>
>> >>>> even if I try:
>> >>>>
>> >>>> gr_extras.uhd_amsg_source(uhd.device_addr="add=172.17.3.140")
>> >>>>
>> >>>> Thanks again Josh,
>> >>>>
>> >>>
>> >>> I see. Its the xml definition. Too bad python/swig does get the
>> >>> constructor overloads that c++ sees.
>> >>>
>> >>> I pushed this change to the repo:
>> >>>> diff --git a/grc/extras_uhd_amsg_source.xml
>> >>>
b/grc/extras_uhd_amsg_source.xml
>> >>>> index 5f8c261..5bb59f0 100644
>> >>>> --- a/grc/extras_uhd_amsg_source.xml
>> >>>> +++ b/grc/extras_uhd_amsg_source.xml
>> >>>> @@ -4,7 +4,7 @@
>> >>>>? ? ? <key>extras_uhd_amsg_source</key>
>> >>>>? ? ? <import>from gnuradio import uhd</import>
>> >>>>? ? ? <import>import gnuradio.extras as gr_extras</import>
>> >>>> -? ? <make>gr_extras.uhd_amsg_source(device_addr=$dev_addr)</make>
>> >>>> +
>>? <make>gr_extras.uhd_amsg_source(uhd.device_addr($dev_addr))</make>
>> >>>>? ? ? <param>
>> >>>>? ? ? ? ? <name>Device Addr</name>
>> >>>>? ? ? ? ?
<key>dev_addr</key>
>> >>>
>> >>> -josh
>> >>>
>> >>>> Regards,
>> >>>>
>> >>>> Jose
>> >>>>
>> >>>> On Thu, Oct 11, 2012 at 11:24 AM, Josh Blum <
address@hidden>
>> wrote:
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> On 10/10/2012 05:51 PM, Jose Torres Diaz wrote:
>> >>>>>> Hi All,
>> >>>>>>
>> >>>>>> I'm checking the functionality of the block "UHD AMsg Source" using
>> >>> the
>> >>>>>> USRP N210. The device is correctly detected as you can see:
>>
>>>>>>
>> >>>>>> uhd_find_devices
>> >>>>>> linux; GNU C++ version 4.6.1; Boost_104601;
>> >>> UHD_003.004.003-221-g9d6f9492
>> >>>>>>
>> >>>>>> --------------------------------------------------
>> >>>>>> -- UHD Device 0
>> >>>>>> --------------------------------------------------
>> >>>>>> Device Address:
>> >>>>>>? ? type: usrp2
>> >>>>>>? ? addr: 172.17.3.140
>> >>>>>>? ? name:
>> >>>>>>? ? serial: E0R17TCUP
>> >>>>>>
>> >>>>>> I've attached a screen-shot of the GRC file. When I run the flow
>> >>> graph, I
>>
>>>>>> get the following error:
>> >>>>>>
>> >>>>>> Traceback (most recent call last):
>> >>>>>>? File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
>> >>> line
>> >>>>>> 54, in <module>
>> >>>>>>? ? tb = top_block()
>> >>>>>>? File "/home/asrpuser/Desktop/Jose Torres Material /top_block.py",
>> >>> line
>> >>>>>> 33, in __init__
>> >>>>>>? ? self.extras_uhd_amsg_source_0 =
>> >>>>>> gr_extras.uhd_amsg_source(device_addr="add=172.17.3.140")
>> >>>>>
>> >>>>> try gr_extras.uhd_amsg_source(uhd.device_addr("addr=172.17.3.140"))
>> >>>>>
>>
>>>>>>? File
>> >>>>>>
>> >>>
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py",
>> >>>>>> line 5384, in make
>> >>>>>>? ? return _extras_swig.uhd_amsg_source_make(*args, **kwargs)
>> >>>>>> TypeError: in method 'uhd_amsg_source_make', argument 1 of type
>> >>>>>> 'uhd::device_addr_t const &'
>> >>>>>>
>> >>>>>> Anyone has seen an error like this before?, How can? I
>> >>> solve/workaround
>> >>>>>> this error?
>> >>>>>>
>> >>>>>> Thanks a lot for your help,
>> >>>>>>
>> >>>>>> Jose.
>> >>>>>>
>>
>>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Discuss-gnuradio mailing list
>> >>>>>>
address@hidden>> >>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Discuss-gnuradio mailing list
>> >>>>>
address@hidden>> >>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> >>>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/73476cc9/attachment.html>
------------------------------
Message: 6
Date: Mon, 15 Oct 2012 03:15:44 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
??? block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Any suggestions how to make this thing working?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37997.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 7
Date: Mon, 15 Oct 2012 05:11:40 -0700 (PDT)
From: Sajjad Safdar <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] 4. Re: usrp_nbfm_ptt.py in Gnu Radio
??? Companion. (Martin Braun (CEL)) Discuss-gnuradio Digest,??? Vol 119,
??? Issue 13
Message-ID:
??? <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear Martin,
Yes i can see that i hve errors because of the red marks, but i first want to know that whether i have all the control
stuff in my reciever as from usrp_nbfm_ptt.py or should i have to add some more stuff which is not exactly translated into my GRC.
Best Regards,
SAJJAD SAFDAR
________________________________
From: "
address@hidden" <
address@hidden>
To:
address@hidden Sent: Saturday, October 13, 2012 9:00 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 13
Send Discuss-gnuradio mailing list submissions to
???
address@hiddenTo subscribe or unsubscribe via the World Wide Web,
visit
???
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help' to
???
address@hiddenYou can reach the person managing the list at
???
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
?? 1. Problem with vector insert (Volker Schroer)
?? 2. Re: Problem with vector insert (Tom Rondeau)
?? 3. usrp_nbfm_ptt.py in Gnu Radio Companion. (Sajjad Safdar)
?? 4. Re: usrp_nbfm_ptt.py in Gnu Radio Companion. (Martin Braun (CEL))
??
5. Re: Can the io signatur of the gnuradio blocks be dynamically
? ? ? updated? (Alex Zhang)
?? 6. Re: [ USRP configuration with/without MIMO in??? unshared
? ? ? Ethernet mode ] (Ashish Raste)
?? 7. Re: cannot make new signal processing block (nexy_sm)
?? 8. grextras "make test" failure (Rick Graham)
?? 9. Re: grextras "make test" failure (Josh Blum)
? 10. OOK Modulation (sibar002)
? 11. OOK Modulation (sibar002)
? 12. Re: Can the io signatur of the gnuradio blocks be dynamically
? ? ? updated? (Alex Zhang)
? 13. Re: GRC: set order of block instantiations (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Oct 2012 18:02:59 +0200
From: Volker Schroer <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Problem with vector insert
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hi all,
I just tried to play around with the vector insert block.
It works if the elements are of type byte.
But if I try another type such as int I get the error
?? File "./top_block.py", line 29, in __init__
? ?? self.gr_vector_insert_x_0 = gr.vector_insert_i((10,12,13), 4, 3)
AttributeError: 'module' object has no attribute 'vector_insert_i'
If I look into the build directory I see only gr_vector_insert _b.* files.
So I tried to modify the generate_common.py in
gnuradio/gnuradio-core/src/lib/gengen. But it seems that I didn't find
the proper place. Only gr_vector_insert _b.*
files will be generated.
Any ideas ?
Thanks -- Volker
------------------------------
Message: 2
Date: Fri, 12 Oct 2012 12:06:37 -0400
From: Tom Rondeau <
address@hidden>
To: Volker Schroer <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Problem with vector insert
Message-ID:
??? <CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 12:02 PM, Volker Schroer
<
address@hidden> wrote:
> Hi all,
>
> I just tried to play around with the vector insert block.
> It works if the elements are of type byte.
> But if I try another type such as int I get the error
>
>?? File "./top_block.py", line 29, in __init__
>? ?? self.gr_vector_insert_x_0 = gr.vector_insert_i((10,12,13), 4, 3)
> AttributeError: 'module' object has no attribute 'vector_insert_i'
>
> If I look into the build directory I see only gr_vector_insert _b.* files.
>
> So I tried to modify the generate_common.py in
> gnuradio/gnuradio-core/src/lib/gengen. But it seems that I didn't find the
> proper place. Only gr_vector_insert _b.* files will be generated.
>
> Any ideas ?
>
> Thanks -- Volker
Volker,
Take a look at gengen/CMakeLists.txt on line 85. You should
just be
able to add the data types you want there. Depending on the guys of
the vector_insert block, you should be able to use any of the standard
data types.
Tom
------------------------------
Message: 3
Date: Fri, 12 Oct 2012 09:13:52 -0700 (PDT)
From: Sajjad Safdar <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] usrp_nbfm_ptt.py in Gnu Radio Companion.
Message-ID:
??? <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am trying to implement usrp_nbfm_ptt.py receiver side in GRC, but i am not sure whether I have translated the code into graphical manner right or there is something wrong, because there is always error.??
Screen shoot is attached for reference.
Best Regards,
SAJJAD SAFDAR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/0f67f228/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ptt_recieve.grc.png
Type: image/png
Size: 98289
bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/0f67f228/attachment.png>
------------------------------
Message: 4
Date: Fri, 12 Oct 2012 18:30:09 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] usrp_nbfm_ptt.py in Gnu Radio
??? Companion.
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Fri, Oct 12,
2012 at 09:13:52AM -0700, Sajjad Safdar wrote:
> I am trying to implement usrp_nbfm_ptt.py receiver side in GRC, but i am not
> sure whether I have translated the code into graphical manner right or there is
> something wrong, because there is always error.?
In that case, there's probably something wrong :)
Everything that's marked red, you must check. Also, check the error
messages. Perhaps you haven't set the rates to integer values?
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was
scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/f9fb238d/attachment.pgp>
------------------------------
Message: 5
Date: Fri, 12 Oct 2012 11:39:04 -0500
From: Alex Zhang <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re:
[Discuss-gnuradio] Can the io signatur of the gnuradio
??? blocks be dynamically updated?
Message-ID:
??? <CA+
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Tom, thanks for the response, but I am still have questions regarding
your comments as below inline:
On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM
blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have
different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress:
https://github.com/osh/gr-eventstream.
>
>
It seems that the event stream scheduler can only handle finite options for
selection?
This is different with what I am expecting. Sometimes, you don't know the
actual options and the dynamic parameters is computed based on some other
optimization algorithm. Thus I can not pre-configure finite graphs for my
selection, but just adjust the exiting graph with specified parameter.
BTW, maybe my expectation is kind of over-design which brings more risk
than benefits. But from the Software defined radio
perspective, the
dynamic/adaptive signal processing chain with expecting flexibility really
deserves? more attention.
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the current gnuradio blocks framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make
the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true ? just believe.
> >>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true ? just believe.
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/829cfe67/attachment.html>
------------------------------
Message: 6
Date: Sat, 13 Oct 2012 01:06:04 +0800
From: Ashish Raste <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] [ USRP configuration with/without MIMO
??? in??? unshared Ethernet mode
]
Message-ID:
??? <CALAnUMTS-qjq+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
*Thanks Josh.
Now I've got a clear idea on how the MIMO acts in different Ethernet
configurations**.
*
>
>
> Message: 1
> Date: Thu, 11 Oct 2012 11:34:39 -0700
> From: Josh Blum <
address@hidden>
> To:
address@hidden> Subject: Re: [Discuss-gnuradio] [ USRP configuration with/without MIMO
>? ? ? ?? in unshared Ethernet mode ]
> Message-ID: <
address@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> > received/transmitted via its own Ethernet interface? and the master?s
> > basedband data within the GRC design is received/transmitted? via its own
> > Ethernet interface? So, this means that the MIMO cable is only used for
> >? sending the clock and time signals from the Master to the Slave ?*
>
> Thats correct. When each USRP has its own ethernet link, the MIMO cable
> is only used for clock and time signals.
>
> >
> > * *
> >
> > *Next, I retained the MIMO cable, set the Master USRP?s clock source to
> > external? and have a 10MHz source connected to the Reference input. The
> > slave USRP?s clock source and time source remained as MIMO mode.? So my
> > question is would the Slave USRP
received the 10MHz Reference via the
> MIMO
> > cable? ? *
> >
>
> Yes. The slave device will still get 10MHz over the MIMO cable. This is
> regardless of how the master gets his reference.
>
> > * *
> >
> > *My second question is:
> > In a 4X4 USRP setup, how can we synchronize all the 4 USRPs without a
> MIMO
> > connection (between 2 USRPs within a pair), using a 10MHz reference split
> > to each of the USRP and a PPS source?
>
> Yes, you can split 10MHz and PPS signal to all 4 units.
>
>
--
Ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121013/67039a4d/attachment.html>
------------------------------
Message: 7
Date: Fri, 12 Oct 2012 11:04:57 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
??? block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Python path is OK. Gnuradio works fine, I have tried some examples using GRC,
etc.
I also used gr-modtool like it was explained on the website.
I haven't looked at swig
interface file since it was not part of the
tutorial, but I think it should have been generated correctly by gr-modtool.
How can I check installation of the SWIG?
Anyway I will not have chance to try anything until monday.
Regards and thanks
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37982.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 8
Date: Fri, 12 Oct 2012 17:06:52 -0400
From: Rick Graham <
address@hidden>
To: gnuradio <
address@hidden>
Subject: [Discuss-gnuradio] grextras "make test" failure
Message-ID:
??? <CAF+zCGQ+Hj8X9WVpemCUybZ7xv-dbPNd=
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Is this a cause for concern?
[from "ctest -V"]
? ? Start 4: qa_noise_source
4: Test command: /bin/sh
"/usr/local/src/build-gnuradio/grextras/build/python/qa_noise_source_test.sh"
4: Test timeout computed to be: 9.99988e+06
4: linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2);
Boost_104700; UHD_003.004.003-255-gc7054ce5
4:
4: F
4: ======================================================================
4: FAIL: test_001 (__main__.test_noise_source)
4: ----------------------------------------------------------------------
4:
Traceback (most recent call last):
4:?? File "/usr/local/src/build-gnuradio/grextras/python/qa_noise_source.py",
line 55, in test_001
4:? ?? self.assertEqual (expected_result, dst_data)
4: AssertionError: Tuples differ: (-6.88858699798584, 26.1499595... !=
(-6.88858699798584, 26.1499595...
4:
4: First differing element 10:
4: 1.21760773659
4: 1.21761083603
4:
4:?? (-6.88858699798584,
4:? ? 26.149959564208984,
4:? ? 20.575775146484375,
4:? ? -7.934014320373535,
4:? ? 5.335927486419678,
4:? ? -12.552099227905273,
4:? ? 6.333674430847168,
4:? ? -23.830753326416016,
4:? ? -16.603046417236328,
4:? ? 2.9676761627197266,
4: -? 1.2176077365875244,
4: +? 1.2176108360290527,
4:? ? 15.100193977355957)
4:
4: ----------------------------------------------------------------------
4: Ran 1 test in 0.008s
4:
4: FAILED (failures=1)
4/9 Test #4: qa_noise_source
..................***Failed? ? 0.35 sec
------------------------------
Message: 9
Date: Fri, 12 Oct 2012 14:37:12 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] grextras "make test" failure
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/12/2012 02:06 PM, Rick Graham wrote:
> Is this a cause for concern?
Nah, just a slight rounding issue. And in one of the blocks that doesnt
even need predictable output :-) I will take a look...
-josh
>
> [from "ctest -V"]
>? ?? Start 4:
qa_noise_source
>
> 4: Test command: /bin/sh
> "/usr/local/src/build-gnuradio/grextras/build/python/qa_noise_source_test.sh"
> 4: Test timeout computed to be: 9.99988e+06
> 4: linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2);
> Boost_104700; UHD_003.004.003-255-gc7054ce5
> 4:
> 4: F
> 4: ======================================================================
> 4: FAIL: test_001 (__main__.test_noise_source)
> 4: ----------------------------------------------------------------------
> 4: Traceback (most recent call last):
> 4:?? File "/usr/local/src/build-gnuradio/grextras/python/qa_noise_source.py",
> line 55, in test_001
> 4:? ?? self.assertEqual (expected_result, dst_data)
> 4: AssertionError: Tuples differ: (-6.88858699798584, 26.1499595... !=
> (-6.88858699798584, 26.1499595...
> 4:
> 4: First differing element 10:
> 4:
1.21760773659
> 4: 1.21761083603
> 4:
> 4:?? (-6.88858699798584,
> 4:? ? 26.149959564208984,
> 4:? ? 20.575775146484375,
> 4:? ? -7.934014320373535,
> 4:? ? 5.335927486419678,
> 4:? ? -12.552099227905273,
> 4:? ? 6.333674430847168,
> 4:? ? -23.830753326416016,
> 4:? ? -16.603046417236328,
> 4:? ? 2.9676761627197266,
> 4: -? 1.2176077365875244,
> 4: +? 1.2176108360290527,
> 4:? ? 15.100193977355957)
> 4:
> 4: ----------------------------------------------------------------------
> 4: Ran 1 test in 0.008s
> 4:
> 4: FAILED (failures=1)
> 4/9 Test #4: qa_noise_source ..................***Failed? ? 0.35 sec
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 10
Date: Fri, 12 Oct 2012 14:39:41 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] OOK Modulation
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
--
View this message in context:
http://gnuradio.4.n7.nabble.com/OOK-Modulation-tp37985.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 11
Date: Fri, 12 Oct 2012 14:43:54 -0700 (PDT)
From: sibar002 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] OOK Modulation
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hello,
I am working on creating a OOK Modulation block. I have created a block
using the bpsk.py file as an example. I changed the constellation points
such that 1+0j and 0+0j. I am now
trying to change the waveform that is
outputted from the USRP. I would like to transmit a square wave for 1 and
nothing for 0. I am not sure how I can do these. I would greatly appreciate
any help or advise that any one could give me. Thank you for your time and
help.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/OOK-Modulation-tp37986.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 12
Date: Fri, 12 Oct 2012 16:57:52 -0500
From: Alex Zhang <
address@hidden>
To: Tom Rondeau <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
??? blocks be dynamically updated?
Message-ID:
??? <CA+FEAnciERbLpgKtJ-_=5Tvbp-JfgNuJ=
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Tom,
There is the other thing I need to confirm:
It looks that the block's output buffer size can not be changed after its
construction, right?
On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
> On Thu, Oct 11, 2012 at 7:41 PM, Alex Zhang <
address@hidden>
> wrote:
> > Let me take an example for my question.
> >
> > For some OFDM blocks, the io signature is determined by the fft length,
> > during the constructing the block. However, sometimes, we need to adjust
> the
> > the fft length dynamically based on some physical environment or
> computing
> > environment.
>
> Hi Alex,
>
> I haven't thought about this too much, so my recollection of how
> things work could be a bit off. But I'm pretty sure that the answer is
> no, you cannot dynamically adjust this. You'd be messing too much with
> the scheduler.
>
> The way that you can do it is to lock the flowgraph, swap out the
> block in question with a new block that has the new parameters, and
> unlock to restart
the graph. But you are going to lose samples in the
> buffers into the block that you're removing.
>
> This would actually be a great case for the event stream scheduler.
> You could have different processing graphs that are selected based on
> the state that you need. So you could populate graphs of different FFT
> lengths and then dynamically select the right graph based on an event
> when you detect a different length is required. This is still a
> work-in-progress:
https://github.com/osh/gr-eventstream.
>
> Tom
>
>
> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
> wrote:
> >>
> >> Hi,
> >>
> >> I know it may not be possible in the
current gnuradio blocks framework,
> >> but I am still curious if it can be done.
> >> When I write a signal processing block, the io signature could be
> >> determined by some parameters. It is ok, if these parameters are fixed.
> But
> >> sometimes, especially in the adaptive system, I need to dynamically
> update
> >> these parameter, which result in the updating of io signature of the
> blocks.
> >> I can make the io_signature to be independent with the dynamic
> parameters,
> >> but it could be more convenient if the io signature can be adapted. Of
> >> course, it is not easy, as the io signature change could impact the
> upstream
> >> and downstream.
> >>
> >> Thanks,
> >>
> >> --
> >>
> >> Alex,
> >> Dreams can come true ? just
believe.
> >>
> >
> >
> >
> > --
> >
> > Alex,
> > Dreams can come true ? just believe.
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> >
address@hidden> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121012/a6561e96/attachment.html>
------------------------------
Message: 13
Date: Fri, 12 Oct 2012 18:39:18 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] GRC: set order of block instantiations
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 10/11/2012 12:03 PM, Gerald Baier wrote:
> Hi list,
>
> is there a way to set the order of block instantiations in GNU Radio
> companion?
> The reason I am asking is, that I want to pass one block as a
parameter
> to another block to get access to its methods. Is there an easier way to
> do this?
I think the order is either 1) alphabetical or 2) the z dimension of the
blocks in the flowgrah.
>
> Somehow related: Variables configured in GRC are defined before the
> block instantiations. Is it possible to tell GRC where in the final
> python script a variable should be defined?
>
The variable blocks are sorted by order of dependency amongst each other.
-josh
> Best regards
>
> Gerald
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 119, Issue 13
*************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/bfae81f5/attachment.html>
------------------------------
Message:
8
Date: Mon, 15 Oct 2012 10:23:55 -0400
From: Tom Rondeau <
address@hidden>
To: nexy_sm <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
??? block
Message-ID:
??? <CA+SzT6h4cphgerOrXpUWmyJW5zGMF_Wmp38om9+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 2:04 PM, nexy_sm <
address@hidden> wrote:
> Python path is OK. Gnuradio works fine, I have tried some examples using
GRC,
> etc.
Have you verified that that module is actually installed where you
think it is? If you are just building the gr-howto-write-a-block like
this:
cmake -DCMAKE_INSTALL_PREFIX=/opt/howto [path to source]/gr-howto-write-a-block
make && sudo make install
When you look in /opt/howto/lib/python2.7/dist-packages, you will find
a 'howto' directory. Under that, you'll find:
howto_swig.py
howto_swig.pyc
howto_swig.pyo
_howto_swig.so
__init__.py
__init__.pyc
__init__.pyo
All of those files have to be there. Then, if
PYTHONPATH=/opt/howto/lib/python2.7/dist-packages, you can 'import
howto' from inside Python.
Tom
> I also used gr-modtool like it was explained on the website.
> I haven't looked at swig interface file since it was not part of the
> tutorial, but I think it should have been generated correctly by gr-modtool.
>
>
How can I check installation of the SWIG?
>
> Anyway I will not have chance to try anything until monday.
>
> Regards and thanks
>
>
>
> --
> View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p37982.html> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
Message: 9
Date: Mon, 15 Oct 2012
10:27:37 -0400
From: Tom Rondeau <
address@hidden>
To: sumitstop <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Reg : difference between
??? gr.file_descriptor_source/sink and gr.file_source/sink
Message-ID:
??? <CA+SzT6h6t8nSu0CP0-uu+LS04mbpLQPFQNh7+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Oct 14, 2012 at 10:18 AM, sumitstop
<
address@hidden> wrote:
> Q: What is the difference between gr.file_descriptor_source/sink and
> gr.file_source/sink .. I mean when shall we prefer one over other ?
file_source/sink takes in a string for a file name. This block will
create a new file with that name.
file_descriptor_source/sink takes in a file descriptor and writes to
that. This means you create your file descriptor externally and pass
it to the block. The file descriptor can be anything, now, an actual
file, FIFO, device, etc.
Tom
------------------------------
Message: 10
Date: Mon, 15 Oct 2012 10:32:21 -0400
From: Tom Rondeau <
address@hidden>
To: sibar002 <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] OOK Modulation
Message-ID:
??? <CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 12, 2012 at 5:43 PM, sibar002 <
address@hidden> wrote:
> Hello,
>
> I am working on creating a OOK Modulation block. I have created a block
> using the bpsk.py file as an example. I changed the constellation points
> such that 1+0j and 0+0j. I am now trying to change the waveform that is
> outputted from the USRP. I would like to transmit a square wave for 1
and
> nothing for 0. I am not sure how I can do these. I would greatly appreciate
> any help or advise that any one could give me. Thank you for your time and
> help.
What are you seeing when you change the bpsk.py file for your new
constellation? That should be close. The bpsk modulator uses a root
raised cosine pulse shaping filter, is that what your problem is? If
you really want to transmit a square wave (but remember, doing that is
going to throw a lot of signal into the spectrum; also your
transmitter, receiver, and channel are all going to filter this signal
in their own way to distort it), you can change this to a LPF filter
with a wide enough passband to pass the square wave. The filter also
interpolates the signal, which you'll want to do, too.
Tom
------------------------------
Message: 11
Date: Mon, 15 Oct 2012 10:34:52 -0400
From: Tom Rondeau <
address@hidden>
To: Alex Zhang <
address@hidden>
Cc:
address@hidden, gnuradio mailing list <
address@hidden>
Subject: Re: [Discuss-gnuradio] Can the io signatur of the gnuradio
??? blocks be dynamically updated?
Message-ID:
??? <CA+SzT6hgYJa413bCEgc8R1_RFTdwDLnivpq4KD8S+GCxh+
address@hidden>
Content-Type: text/plain; charset=windows-1252
On Fri, Oct 12, 2012 at 5:57 PM, Alex Zhang <
address@hidden>
wrote:
> Hi Tom,
>
> There is the other thing I need to confirm:
> It looks that the block's output buffer size can not be changed after its
> construction, right?
On the latest git master/next, you can change the buffer size once
before you run the flowgraph. The buffers are actually created when
you call top_block.start(), and we've put in a call to the gr_blocks
that allows you to set the maximum buffer size. But you cannot change
it afterwards, even when you lock/unlock (you'd have to delete the old
block and create a new one).
The allocation of gr_buffer space is a very costly operation. You
really, really don't want to be adjusting this during runtime.
Tom
> On Fri, Oct 12, 2012 at 10:12 AM, Tom Rondeau <
address@hidden> wrote:
>>
>> On Thu, Oct 11, 2012 at 7:41 PM, Alex
Zhang <
address@hidden>
>> wrote:
>> > Let me take an example for my question.
>> >
>> > For some OFDM blocks, the io signature is determined by the fft length,
>> > during the constructing the block. However, sometimes, we need to adjust
>> > the
>> > the fft length dynamically based on some physical environment or
>> > computing
>> > environment.
>>
>> Hi Alex,
>>
>> I haven't thought about this too much, so my recollection of how
>> things work could be a bit off. But I'm pretty sure that the answer is
>> no, you cannot dynamically adjust this. You'd be messing too much with
>> the scheduler.
>>
>> The way that you can do it is to lock the flowgraph, swap out
the
>> block in question with a new block that has the new parameters, and
>> unlock to restart the graph. But you are going to lose samples in the
>> buffers into the block that you're removing.
>>
>> This would actually be a great case for the event stream scheduler.
>> You could have different processing graphs that are selected based on
>> the state that you need. So you could populate graphs of different FFT
>> lengths and then dynamically select the right graph based on an event
>> when you detect a different length is required. This is still a
>> work-in-progress:
https://github.com/osh/gr-eventstream.
>>
>> Tom
>>
>>
>> > On Thu, Oct 11, 2012 at 6:29 PM, Alex Zhang <
address@hidden>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I know it may not be possible in the current gnuradio blocks framework,
>> >> but I am still curious if it can be done.
>> >> When I write a signal processing block, the io signature could be
>> >> determined by some parameters. It is ok, if these parameters are fixed.
>> >> But
>> >> sometimes, especially in the adaptive system, I need to dynamically
>> >> update
>> >> these parameter, which result in the updating of io signature of the
>> >> blocks.
>> >> I can make the io_signature to be independent with the dynamic
>> >> parameters,
>> >> but it could be more convenient if the io signature can be adapted.
Of
>> >> course, it is not easy, as the io signature change could impact the
>> >> upstream
>> >> and downstream.
>> >>
>> >> Thanks,
>> >>
>> >> --
>> >>
>> >> Alex,
>> >> Dreams can come true ? just believe.
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Alex,
>> > Dreams can come true ? just believe.
>> >
>> >
>> > _______________________________________________
>> > Discuss-gnuradio mailing list
>> >
address@hidden>> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> >
>
>
>
>
> --
>
> Alex,
> Dreams can come true ? just believe.
>
------------------------------
Message: 12
Date: Mon, 15 Oct 2012 16:41:48 +0200
From: Pol Henarejos <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] How to report to gnuradio.org
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear list,
I am trying to report several bugs to gnuradio.org webpage but I cannot
see the option for reporting in the bug tracker.
I am registered.
Thanks.
--
Pol Henarejos
Research Engineer, MSc
address@hiddenCentre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70? Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 549 bytes
Desc: OpenPGP digital signature
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121015/062c3313/attachment.pgp>
------------------------------
Message:
13
Date: Mon, 15 Oct 2012 10:51:50 -0400
From: Tom Rondeau <
address@hidden>
To: Pol Henarejos <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] How to report to gnuradio.org
Message-ID:
??? <CA+SzT6icTs+3m7KB41KREX6Lo3TLBHpZLwE37m4apf=
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Oct 15, 2012 at 10:41 AM, Pol Henarejos <
address@hidden> wrote:
> Dear list,
>
> I am trying to report several bugs to
gnuradio.org webpage but I cannot
> see the option for reporting in the bug tracker. I am registered.
>
> Thanks.
>
> --
>
> Pol Henarejos
Pol,
Due to an excessive amount of spam on the site, I've had to lock it
down. You now have to be manually assigned to a project in order to
make edits.
I have now added you, so you can make your edits.
Thanks for contributing!
Tom
------------------------------
Message: 14
Date: Mon, 15 Oct 2012 08:24:31 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
??? block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Finaly it works.
Thanks!!!!!!!!!!!!!!!!!!!!!!!
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38005.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest,
Vol 119, Issue 15
*************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121016/834b0cf6/attachment.html>
------------------------------
Message: 13
Date: Tue, 16 Oct 2012 10:27:04 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 119,
Issue 15 (Usrp_nbfm_ptt.py)
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Tue, Oct 16, 2012 at 01:14:30AM -0700, Sajjad Safdar wrote:
> Yes i can see that i hve errors because of the red marks, but i first want to
> know that whether i have all the control stuff in my reciever as from
> usrp_nbfm_ptt.py or should i have to add some more stuff which is not exactly
> translated into my GRC.
Sajjad,
are you saying you want to know whether or not your flow graph will work
once you fix the error messages? I'd guess yes. Just try it!
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721
608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121016/9056e2c7/attachment.pgp>
------------------------------
Message: 14
Date: Tue, 16 Oct 2012 02:08:42 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal
processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Of course, that's at least what I can do.
First of all, I would like to say that the biggest problem was lack of my
knowledge in Linux.
I was strictly following instructions from gnuradio.org about making out of
tree signal processing block, and there is not stated that i have to do
/make install/ before testing module.
Also, nowhere is stated stest -V, for getting more error information, and
also using -DCMAKE_INSTALL_PREFIX, whish is used for setting base address or
whatever.
Maybe somebody should make detailed tutorials, for the people that knows
only signal processing, not Linux, just for smooth start, unti they
get
used.
Regards
Nemanja
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38019.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 15
Date: Tue, 16 Oct 2012 11:26:13 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Tue, Oct 16, 2012 at 02:08:42AM -0700, nexy_sm wrote:
> First of all, I would like to say that the biggest problem was lack of my
> knowledge in Linux.
> I was strictly following instructions from gnuradio.org about making out of
> tree signal processing block, and there is not stated that i have to do
> /make install/ before testing module.
Hm, you shouldn't need to do that. (That's why it's not in the
instructions.)
> Also, nowhere is stated stest -V, for getting more error information, and
> also using -DCMAKE_INSTALL_PREFIX, whish is used for setting base address or
> whatever.
That's already what I'd consider 'advanced' usage, which is why it's not
in the tutorial, either. Although I guess 'ctest -V' could be in
there.
> Maybe somebody should make detailed tutorials, for the people that knows
> only signal processing, not Linux, just for smooth start, unti they get
> used.
Since you just went through the process, how about writing something
while the knowledge is still fresh?
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121016/9b1e1b5f/attachment.pgp>
------------------------------
Message: 16
Date: Tue, 16 Oct 2012 03:14:31 -0700 (PDT)
From: nexy_sm <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Do you mean some kind of tutorial or what?
Well, that means that
my test don't work, since you said that make install
isn't necesary.
So, let's start again, what might be a problem?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/cannot-make-new-signal-processing-block-tp37924p38021.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 17
Date: Tue, 16 Oct 2012 13:19:30 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Tue, Oct 16, 2012 at 03:14:31AM -0700, nexy_sm wrote:
> Do you mean some kind of tutorial or what?
>
> Well, that means that my test don't work, since you said that make install
> isn't necesary.
>
> So, let's start again, what might be a problem?
That's still impossible to tell from what you've written.
I've just checked that gr_modtool and the tutorial are correct.
Here's what I did:
1) Create an out-of-tree module
~/tmp % gr_modtool.py create test
Module directory is "./gr-test".
Creating directory...
Copying howto example...
Unpacking...
Replacing occurences of 'howto' to 'test'... Done.
Use 'gr_modtool add' to add a new block to this currently
empty module.
2) Then, I add a sync-block:
~/tmp% cd gr-test
tmp/gr-test % gr_modtool.py add -t sync square_ff
Operating in directory .
GNU Radio module name identified: test
Code is of type: sync
Block/code identifier: square_ff
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n]
Add C++ QA code? [Y/n] n
Traversing lib...
Adding file 'square_ff_impl.h'...
Adding file 'square_ff_impl.cc'...
Adding file 'square_ff.h'...
Traversing swig...
Editing swig/test_swig.i...
Traversing python...
Adding file 'qa_square_ff.py'...
Editing python/CMakeLists.txt...
Traversing grc...
Adding file 'test_square_ff.xml'...
Editing grc/CMakeLists.txt...
3) Next, I edit the work() function of the block (this only needs one
line to be changed) to look like this:
Before this is done, the 'make' command won't work!
{
const
float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
for (int i = 0; i < noutput_items; i++) {
out[i] = in[i] * in[i];
}
// Tell runtime system how many output items we produced.
return noutput_items;
}
4) Finally, I edit the file python/qa_square_ff.py such that the test case contains this:
Before this is done, the 'make test' or 'ctest' commands won't work!
def test_001_t (self):
test_data = (1, 2, 3, 4)
correct_res = (1, 4, 9, 16)
sink = gr.vector_sink_f()
self.tb.connect(gr.vector_source_f(test_data), test.square_ff(), sink)
self.tb.run()
self.assertEqual(sink.data(), correct_res)
Then, I go to the build directory and invoke the make process:
gr-test/build % cmake .. # Output omitted
gr-test/build % make # Output omitted
gr-test/build % make test
Running tests...
Test project /home/braun/tmp/gr-test/build
Start 1: test_test
1/2 Test #1: test_test ........................ Passed 0.02 sec
Start 2: qa_square_ff
2/2 Test #2: qa_square_ff ..................... Passed 0.23 sec
100% tests passed, 0 tests failed out of 2
The End.
This entire process took me less than 10 minutes. If you're taking
longer, you're wasting time.
Other notes:
* I never installed
* The only editing necessary was three lines in the work() function and the
test case in qa_square_ff
So go
through your module once again, start from scratch and it will
work.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121016/8d74a74d/attachment.pgp>
------------------------------
Message:
18
Date: Tue, 16 Oct 2012 10:30:13 -0400
From: Tom Rondeau <
address@hidden>
To: Joel Mayer <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Wireless Camera Reception?
Message-ID:
<CA+SzT6hU+3kRoDEhw=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Oct 15, 2012 at 6:26 PM, Joel Mayer <
address@hidden> wrote:
>
**
> Dear GNUradio enthusiasts-
>
> Beneath these lines (attached as a virus free pdf) you will find a table
> of frequencies
> assigned to wireless cameras. I'm wondering, would it be possible to
> modify the SDR#
> radio in such a way as to make it wireless camera capable?
>
> Thanks For Reading This!
>
Joel,
I don't know about SDR# since this is the GNU Radio mailing list. But yes,
in principle GNU Radio could be made to work with these. You'd need a
system that can handle the bandwidth, so you'd be looking at a USRP N200
with the appropriate daughterboard.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121016/5be0212c/attachment.html>
------------------------------
Message: 19
Date: Tue, 16 Oct 2012 10:46:10 -0400
From: Tom Rondeau <
address@hidden>
To: nexy_sm <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] cannot make new signal processing
block
Message-ID:
<CA+SzT6j_YS+
address@hidden>
Content-Type: text/plain;
charset=ISO-8859-1
On Tue, Oct 16, 2012 at 5:08 AM, nexy_sm <
address@hidden> wrote:
> Of course, that's at least what I can do.
>
> First of all, I would like to say that the biggest problem was lack of my
> knowledge in Linux.
> I was strictly following instructions from gnuradio.org about making out of
> tree signal processing block, and there is not stated that i have to do
> /make install/ before testing module.
> Also, nowhere is stated stest -V, for getting more error information, and
> also using -DCMAKE_INSTALL_PREFIX, whish is used for setting base address or
> whatever.
>
> Maybe somebody should make detailed tutorials, for the people that knows
> only signal processing, not Linux, just for smooth start, unti they get
> used.
>
> Regards
>
Nemanja
Unfortunately, you cannot separate the signal processing of SDR from
the operating system. You need to understand a bit of each if you're
going to do anything really, truly useful. So while you're struggling
to get some of this stuff started, you are also learning a lot about
Linux and the build tools. This will serve you immeasurably well in
the future. I am right now struggling through similar issues with OSX.
That having been said, we are slowly producing more information to
help people out. Look at the Doxygen manual that get's generated when
you install GNU Radio. There's a lot more information in there to help
people understand some features of GNU Radio and of the build system.
The -V 'trick' for ctest is kind of outside of the scope of GNU Radio.
That's something that's documented with ctest. I learned about this
myself by just searching for help on getting information out of
'make
test.'
One of the biggest problems we can have as developers is that we are
probably the worst people to document the code, especially features
like what you are talking about. It's hard to know what others don't
know. A lot of what is on the instructions and manuals that I've put
in are because I was just learning something, like using cmake
properly, and thought, "oh, this is something that should be
documented." We have to rely on people to help us put this together.
Tom
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 119,
Issue 16
*************************************************