Re: (gnuradio3.8) module 'gnuradio.blocks' has no attribute 'message_sink'
Hi Criss,
Unfortunately it seems there is no easy solution to this problem. But at
least I can go back to Ubuntu18 which installs gnuradio 3.7 and I can
still use my old codes.
Regards,
Ting Wu
On 2021/01/15 1:49, Criss Swaim wrote:
Hi Ting:
I have been working on this same issue for a couple of day and have
not found a solution. Did you find a solution to the missing
"message_sink"?
Criss Swaim
csw...@tpginc.net
cell: 505.301.5701
On 1/6/2021 8:46 PM, Ting Wu wrote:
Hi!
I recently upgraded to gnuradio 3.8 and my old code threw the
following error:
module 'gnuradio.blocks' has no attribute 'message_sink'
Is the 'message_sink' has been deprecated in the recent version of
gnuradio? If so, what should I use now for the message source and
sink? I really do not want to rewrite all the codes, so I would be
really grateful if there is a simple way to make the following code
work with the recent version of gnuradio. The code simply gets data
stream from a USRP N200 (LFRX daughterboard).
=
class my_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args('sc16', 'sc16', args="scalar=1024"))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = blocks.message_sink(gr.sizeof_short*2,
self.queue, False) #This line throws the error
self.connect(self.source, self.sink)
=======
Thanks in advance!
Ting Wu
(gnuradio3.8) module 'gnuradio.blocks' has no attribute 'message_sink'
Hi!
I recently upgraded to gnuradio 3.8 and my old code threw the following
error:
module 'gnuradio.blocks' has no attribute 'message_sink'
Is the 'message_sink' has been deprecated in the recent version of
gnuradio? If so, what should I use now for the message source and sink?
I really do not want to rewrite all the codes, so I would be really
grateful if there is a simple way to make the following code work with
the recent version of gnuradio. The code simply gets data stream from a
USRP N200 (LFRX daughterboard).
=
class my_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args('sc16', 'sc16', args="scalar=1024"))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = blocks.message_sink(gr.sizeof_short*2, self.queue,
False) #This line throws the error
self.connect(self.source, self.sink)
===
Thanks in advance!
Ting Wu
Re: [Discuss-gnuradio] USRP N200 Overflow (printing D) when using a new Intel NUC
Hi Marcus, Thank you for your prompt response. I had a look at the datasheet of the new NUC (https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/NUC7i5BN_NUC7i7BN_TechProdSpec.pdf), and it seems that it uses Intel I219V Ethernet controller rather than 82579LM as you mentioned. I also looked at the datasheet of the old NUC which worked fine, and it was using Intel I218-V Ethernet controller. Does this mean the I219V is also bad as the 82579LM? Ting On 2018/07/27 12:00, Marcus D. Leech wrote: On 07/26/2018 10:53 PM, Ting Wu wrote: Hi! I have been using USRP N200 (with LFRX daughterboard) with an Intel NUC (BOXNUC5I5RYH) for quite a long time, and everything has been working well. Recently I purchased a new NUC of a recent version (BOXNUC7I5BNK), and the overflow problem (printing D) occurred. So I made a test. I installed Ubuntu 17.10 on both the old and the new NUCs, and installed exactly the same software. Then I tested these two NUCs with the same USRP and confirmed that the overflow problem only occurs with the new NUC. I made a simple script for the test as shown in the attached figure. With the new NUC, the letter D is printed once in a while as shown below: ---Output linux; GNU C++ version 6.2.0 20161027; Boost_106200; UHD_003.009.005-0-unknown -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929 -- Setting references to the internal GPSDO 1532658018 3595 1532658019 3362 1532658020 2861 D1532658021 666 1532658022 587 1532658023 722 1532658024 780 1532658025 477 1532658026 703 DD1532658027 759 1532658028 553 1532658029 618 1532658030 581 1532658031 474 --- With the old NUC, there is no overflow at all. So it seems the overflow problem is associated with the hardware of the new NUC (BOXNUC7I5BNK). My question is that is there any method to avoid this overflow problem? If I have to drop this new NUC, what part of the NUC is causing this problem and what types of PCs may have the same problem and I should avoid in the future? Thanks in advance! Ting Wu The Intel 82579LM Ethernet chip is known to have serious issues with dropping frames from time to time, and we've seen this type of behavior with 82579LM on motherboards. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No attribute 'message_sink'
Hi Marcus, Thanks! I changed the line to self.sink = blocks.message_sink(gr.sizeof_short*2, self.queue, False) and now it works. Wu -Original Message- From: Marcus Müller [mailto:mar...@hostalia.de] Sent: Friday, November 01, 2013 6:23 PM To: Ting Wu Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] No attribute 'message_sink' Hi Wu, yes, something has changed: GNU Radio made a version progression from 3.6 to 3.7. Part of this progress was that the standards blocks are now part of the blocks module, and no longer of the gr module. Please refer to the official GR wiki to learn about conversion from 3.6 to 3.7. Greetings, Marcus On Fri, 2013-11-01 at 17:00 +0900, Ting Wu wrote: Hi, I’m using USRP N210 with LFRX. I installed uhd and gnuradio with build-gnuradio script without any problem. However, when I run an application, it has such error message: self.sink = gr.message_sink(gr.sizeof_short*2, self.queue, False) AttributeError: 'module' object has no attribute 'message_sink' Several months ago, I installed on several computers with the build-gnuradio script and run the same application, and there was no such problem. Has gnuradio changed something recently? Best regards, Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Resolution of USRP N210 and N200
Hi, Both of USRP N210 and N200 have 14 bit ADC, which means a range of +/-2e13=+/-8129. However, as I tested a N210 with LFRX, I got values from -32704 ~ 30073, close to +/-2e15=32768. Last year, I also tested a N200 with LFRX, I got values from -16357 ~ 16241, close to +/-2e14=16384. The sampling rate was set to 4 MHz. So why does the ADC has a real resolution higher than 14 bit, and are N210 and N200 the same? I'm really new to the world of ADC, so some basics would be very helpful. Thanks! Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] No attribute 'message_sink'
Hi, I'm using USRP N210 with LFRX. I installed uhd and gnuradio with build-gnuradio script without any problem. However, when I run an application, it has such error message: self.sink = gr.message_sink(gr.sizeof_short*2, self.queue, False) AttributeError: 'module' object has no attribute 'message_sink' Several months ago, I installed on several computers with the build-gnuradio script and run the same application, and there was no such problem. Has gnuradio changed something recently? Best regards, Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD make test failed
Hi all, I used to use build-gnuradio script to build gnuradio and uhd. Usually everything is fine, but today when I run the script, it always stops with UHD build apparently failed. So I am trying to build from the source. When I run make test, it shows following errors: lrg@FKCL:~/gnuradio/uhd/host/build$ make test Running tests... Test project /home/lrg/gnuradio/uhd/host/build Start 1: addr_test 1/15 Test #1: addr_test Passed0.01 sec Start 2: buffer_test 2/15 Test #2: buffer_test .. Passed0.03 sec Start 3: byteswap_test 3/15 Test #3: byteswap_test Passed0.02 sec Start 4: convert_test 4/15 Test #4: convert_test . Passed0.21 sec Start 5: dict_test 5/15 Test #5: dict_test Passed0.01 sec Start 6: error_test 6/15 Test #6: error_test ... Passed0.01 sec Start 7: gain_group_test 7/15 Test #7: gain_group_test .. Passed0.01 sec Start 8: msg_test 8/15 Test #8: msg_test . Passed0.01 sec Start 9: property_test 9/15 Test #9: property_test Passed0.01 sec Start 10: ranges_test 10/15 Test #10: ranges_test .. Passed0.01 sec Start 11: sph_recv_test 11/15 Test #11: sph_recv_test Passed0.06 sec Start 12: sph_send_test 12/15 Test #12: sph_send_test Passed0.01 sec Start 13: subdev_spec_test 13/15 Test #13: subdev_spec_test . Passed0.01 sec Start 14: time_spec_test 14/15 Test #14: time_spec_test ...***Failed0.00 sec Start 15: vrt_test 15/15 Test #15: vrt_test .***Failed0.00 sec 87% tests passed, 2 tests failed out of 15 Total Test time (real) = 0.46 sec The following tests FAILED: 14 - time_spec_test (Failed) 15 - vrt_test (Failed) Errors while running CTest make: *** [test] Error 8 How should I fix this problem? Thanks in advance. Ting Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Requested decimation is odd
Hi all, I am using USRP N200 with LFRX daughter board. The newest version of images has been loaded. The sampling rate is set as 4 MHz. There is constantly a UHD warning: The requested decimation is odd; the user should expect CIC rolloff. Select an even decimation to ensure that a halfband filter is enabled. How do I change the decimation value? And what value should I set it? Thanks! Ting Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Requested decimation is odd
Thank you for your response! We need to use the sampling rate of 4 MHz. How can I deal with this problem? Actually we have been running the same application on several USRPs (N200 and N210), and there was no such warning. Any suggestions? Ting Wu From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Monday, November 12, 2012 11:29 AM To: Ting Wu Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Requested decimation is odd Hi all, I am using USRP N200 with LFRX daughter board. The newest version of images has been loaded. The sampling rate is set as 4 MHz. There is constantly a UHD warning: The requested decimation is odd; the user should expect CIC rolloff. Select an even decimation to ensure that a halfband filter is enabled. How do I change the decimation value? And what value should I set it? Thanks! Ting Wu 100e6 / 4e6 = 25 Which is odd value which changes the line up of filtering in the FPGA. Select a sample rate that results in an even decimation value, unless you can live with the edge roll-off for an odd value. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Requested decimation is odd
I see. Thanks a lot! Ting Wu From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Monday, November 12, 2012 12:05 PM To: Ting Wu Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Requested decimation is odd On 11/11/12 09:42 PM, Ting Wu wrote: Thank you for your response! We need to use the sampling rate of 4 MHz. How can I deal with this problem? Actually we have been running the same application on several USRPs (N200 and N210), and there was no such warning. Any suggestions? Ting Wu From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Monday, November 12, 2012 11:29 AM To: Ting Wu Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Requested decimation is odd Hi all, I am using USRP N200 with LFRX daughter board. The newest version of images has been loaded. The sampling rate is set as 4 MHz. There is constantly a UHD warning: The requested decimation is odd; the user should expect CIC rolloff. Select an even decimation to ensure that a halfband filter is enabled. How do I change the decimation value? And what value should I set it? Thanks! Ting Wu 100e6 / 4e6 = 25 Which is odd value which changes the line up of filtering in the FPGA. Select a sample rate that results in an even decimation value, unless you can live with the edge roll-off for an odd value. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org The warning is new. But nothing else has changed. If your application has been running fine, it will continue to run fine. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About the sampling rate
Dear all, I find the sampling rate of USRP is surprisingly accurate. Now I set the sampling rate as 4 MHz, and there are always exactly 4M points between two pps signals. Even if I take off the GPS antenna, the sampling rate is still very accurate. This means I only need the GPS antenna at the beginning to get an accurate time stamp. Later I can take off the antenna and still can get accurate time from sampling rate. My colleagues and I do not understand how does USRP make the sampling rate so accurate. We had used other types of A/D converters before. They usually do not have such accurate sampling rate. Sometimes they have around 4M plus and minus 100 points in one second under 4M sampling rate. Thanks for your attention. Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Waiting too much time for the GPS to be synchronized
I think you need to put the antenna outside. In my situation, I put the antenna on the balcony. It usually takes me only several minutes to get an accurate time (diff0.01). Wu From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org [mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or g] On Behalf Of Alex Zhang Sent: Monday, September 24, 2012 2:51 PM To: gnuradio mailing list; usrp-users Cc: Tom Rondeau; j...@ettus.com Subject: [Discuss-gnuradio] Waiting too much time for the GPS to be synchronized Hi, I have two USRPs with GPS equipped. I found it always took too much for the two GPS to be sychronized to the same time (diff 0.1s). Previously, I wait about 1 or 2 hours, but today 10 hours later, they still have time difference of 5s. I am using GPS indoor environment. -- Alex, Dreams can come true - just believe. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio server is down?
Hi all, I cannot connect to GNURadio home page http://gnuradio.org/ And I cannot install GNURadio by build-gnuradio script. Is there something wrong? Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi all, Now I'm using several USRP N200 and N210 to build an observation network. I have bought several new computers, which are exactly the same. When I connect a USRP N210 with one computer, it has overflow problem (occasionally print 'O'). However, when I connect the same USRP with another computer (exactly the same model), it does not have such problem. Several months ago, when I used a USRP N200, it also had similar problem. When I connect the USRP to a laptop (a very new and fast one), it occasionally has overflow problem. However, when I connect it to other computers (some of them are very old and slow), it did not have the problem. This really bothers me because I don't know what is the reason of this problem, so we are not sure what computers we should buy in future operation. Does anyone have any clue? Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi,
I made more tests, and even stranger things happened. Let me clarify this
problem all over again.
I have two USRP (N210 Rev.4) (Let's say U1 and U2) with LFRX daughterboard,
and two computers (Endeavo ST160E) (Let's say P1 and P2).
First, U1 is connected with P1 and running test code (see below) works well.
U2 is connected with P2, and running the code below prints 'O', indicating
overflow problem.
Then, I connect U1 to P2. Overflow problem happens again, and printing of
'O' becomes more frequent.
Then, I connect U2 to P2. Same as above, frequent printing of 'O'.
Then I rebooted P2, and connect it with U1. No overflow problem.
Then I connect P2 with U2. Again there is overflow problem.
Then I rebooted P2 again, and connect it to U2. No overflow problem again.
For P1, there is always overflow problem even if I reboot it and no matter
it is connected with U1 or U2.
This is the code for making tests:
###code##
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import uhd
import time
from time import sleep
from struct import unpack
samp_rate = 4e6
gain = 0
class trig_with_pretrig(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr=,
stream_args=uhd.stream_args('sc16', 'sc16', args=scalar=1024))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = gr.message_sink(gr.sizeof_short*2, self.queue,
False)
self.connect(self.source, self.sink)
if __name__==__main__:
tb = trig_with_pretrig()
tb.start()
while True:
#Test speed of computer
tb.queue.flush()
for i in range(1000):
msg = tb.queue.delete_head()
payload = msg.to_string()
loadLen = int(msg.arg2())
format = str(loadLen*2)+'h'
data = unpack(format, payload)
datach1 = data[0::2]
dataMax = max(datach1)
wait_len = tb.queue.count()
sleep(1)
##code
When there is overflow problem, it is like this:
lrg@lrg:~$ ./test_overflow.py
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-224-gc2e197c0
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1448 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
OO
Anyone has any clue what might be the reason for this overflow problem?
Any suggestion is appreciated.
Wu
From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
[mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or
g] On Behalf Of Ting Wu
Sent: Tuesday, September 18, 2012 5:36 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi all,
Now I'm using several USRP N200 and N210 to build an observation network.
I have bought several new computers, which are exactly the same.
When I connect a USRP N210 with one computer, it has overflow problem
(occasionally print 'O').
However, when I connect the same USRP with another computer (exactly the
same model), it does not have such problem.
Several months ago, when I used a USRP N200, it also had similar problem.
When I connect the USRP to a laptop (a very new and fast one), it
occasionally has overflow problem.
However, when I connect it to other computers (some of them are very old and
slow), it did not have the problem.
This really bothers me because I don't know what is the reason of this
problem, so we are not sure what computers we should buy in future
operation.
Does anyone have any clue?
Wu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
