Re: [Discuss-gnuradio] Error with gnuradio 3.8 and python 3
Hi Mark - Interesting issue. Is SWIG/Python -not- enabled in your GR install? Following the code, that could cause the error you're seeing. If you look through the file "/opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake", line 37 will show whether ENABLE_PYTHON is enabled or not. - MLD On Mon, Sep 16, 2019 at 2:57 PM Mark Koenig < mark.koe...@iubelttechnologies.com> wrote: > Hello, > > > > I am trying to build a module and I keep seeing the error below during > cmake. Any deas? > > > > #9 3.713 -- Found VOLK: Volk::volk > > #9 3.729 -- Checking for module 'thrift' > > #9 3.761 -- Found thrift, version 0.10.0 > > #9 3.840 CMake Error at > /opt/truearrow/6.3/lib/cmake/gnuradio/FindTHRIFT.cmake:68 > (GR_PYTHON_CHECK_MODULE): > > #9 3.840 Unknown CMake command "GR_PYTHON_CHECK_MODULE". > > #9 3.840 Call Stack (most recent call first): > > #9 3.840 /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48 > (find_package) > > #9 3.840 > /opt/truearrow/6.3/lib/cmake/gnuradio/gnuradio-runtimeConfig.cmake:24 > (find_dependency) > > #9 3.840 /opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake:45 > (include) > > #9 3.840 CMakeLists.txt:23 (find_package) > > #9 3.840 > > #9 3.840 > > #9 3.842 -- Configuring incomplete, errors occurred! > > #9 3.842 See also > "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeOutput.log". > > #9 3.842 See also > "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeError.log". > > #9 3.849 [ Build gr-vrt (Release) FAILED with error code 1 ] > > > > > > Thank you > > > > Mark > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sending Data/Messages to GNU Radio via Python Application
Hi,
On 08/09/2019 21:29, Rajen Goradia wrote:
I am trying to make use of the ZMQ blocks in GNU Radio to act as a
server and have a separate python client application send data/messages
to GNU Radio. I was successful in getting data out of GNU Radio and
using a separate python application such as using the “ZMQ PUSH Sink”
block in GNU Radio and using the zmq library in Python
(context.socket(zmq.PULL) function) but I was unable to reverse the
procedure. Has anybody successfully tried doing this, either with or
without using the zmq library or the ZMQ blocks in GNU Radio? Please let
me know and thank you for looking.
Happen to have just done this a few weeks ago, to compensate for doppler
shift on 21cm (Hydrogen line) observations. What worked for me is listed
below. This should work with Python 2 and GR 3.7 as well, but I ended up
using GNU Radio 3.8 because astropy requires python 3. The code sends a
'freq' message, which you can feed to e.g. the command port of a
Frequency XLAT FIR filter, see the attached image.
#!/usr/bin/python3
# Note: use Python 2 for older versions of GR
import pmt
import zmq
import time
# Open a ZeroMQ publisher socket on localhost, port
context = zmq.Context()
socket = context.socket(zmq.PUB)
socket.bind("tcp://127.0.0.1:")
doppler = 0.1
while(1):
msg = pmt.cons(pmt.intern("freq"), pmt.from_double(doppler))
sb = pmt.serialize_str(msg)
socket.send(sb)
doppler = doppler + 0.1
time.sleep(1)
# Code ends here
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error with gnuradio 3.8 and python 3
Hello, I am trying to build a module and I keep seeing the error below during cmake. Any deas? #9 3.713 -- Found VOLK: Volk::volk #9 3.729 -- Checking for module 'thrift' #9 3.761 -- Found thrift, version 0.10.0 #9 3.840 CMake Error at /opt/truearrow/6.3/lib/cmake/gnuradio/FindTHRIFT.cmake:68 (GR_PYTHON_CHECK_MODULE): #9 3.840 Unknown CMake command "GR_PYTHON_CHECK_MODULE". #9 3.840 Call Stack (most recent call first): #9 3.840 /usr/share/cmake-3.10/Modules/CMakeFindDependencyMacro.cmake:48 (find_package) #9 3.840 /opt/truearrow/6.3/lib/cmake/gnuradio/gnuradio-runtimeConfig.cmake:24 (find_dependency) #9 3.840 /opt/truearrow/6.3/lib/cmake/gnuradio/GnuradioConfig.cmake:45 (include) #9 3.840 CMakeLists.txt:23 (find_package) #9 3.840 #9 3.840 #9 3.842 -- Configuring incomplete, errors occurred! #9 3.842 See also "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeOutput.log". #9 3.842 See also "/workspaces/ta/gr-vrt/Release/CMakeFiles/CMakeError.log". #9 3.849 [ Build gr-vrt (Release) FAILED with error code 1 ] Thank you Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to find out if device sink is finished writing samples to radio
Hi Adrian - It's non-trivial to determine the state of the buffers from inside blocks, but with the correct C++ class/type coercion it can be done -- even if you're not supposed to do that. I don't recommend doing so, of course. Thinking there will be a better way to do what you're hoping to do. - MLD On Mon, Sep 16, 2019 at 11:41 AM Adrian Musceac wrote: > Hi Kevin, > Thanks for the answer, unfortunately in my case I want to keep the > flowgraph running and I'd need a way to check the state of the block > buffers. Maybe I can do that with a custom block before the source or maybe > I should rethink my approach. > > Adrian > > On September 16, 2019 2:42:06 PM UTC, Kevin Reid > wrote: >> >> On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac >> wrote: >> >>> So far I haven't found a way (callback?) to tell when the last sample is >>> out of the flowgraph. I am using the C++ API of GNU radio. >>> >> >> The wait() method of a top_block will block the calling thread until all >> items have passed through. >> >> Note that this will only succeed if your *source* blocks indicate there >> are no more items, by returning -1 (gr::block::WORK_DONE). Vector and >> file sources and other such standard fixed-length sources do, but if your >> source is merely emitting no items at this time (e.g. a network source >> that's not currently receiving packets) the flow graph will still be >> running waiting for more. I do not know of a way to ask for "when all >> buffers are currently empty", if that's what you need. >> > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to find out if device sink is finished writing samples to radio
Hi Kevin, Thanks for the answer, unfortunately in my case I want to keep the flowgraph running and I'd need a way to check the state of the block buffers. Maybe I can do that with a custom block before the source or maybe I should rethink my approach. Adrian On September 16, 2019 2:42:06 PM UTC, Kevin Reid wrote: >On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac >wrote: > >> So far I haven't found a way (callback?) to tell when the last sample >is >> out of the flowgraph. I am using the C++ API of GNU radio. >> > >The wait() method of a top_block will block the calling thread until >all >items have passed through. > >Note that this will only succeed if your *source* blocks indicate there >are >no more items, by returning -1 (gr::block::WORK_DONE). Vector and file >sources and other such standard fixed-length sources do, but if your >source >is merely emitting no items at this time (e.g. a network source that's >not >currently receiving packets) the flow graph will still be running >waiting >for more. I do not know of a way to ask for "when all buffers are >currently >empty", if that's what you need. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to find out if device sink is finished writing samples to radio
On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac wrote: > So far I haven't found a way (callback?) to tell when the last sample is > out of the flowgraph. I am using the C++ API of GNU radio. > The wait() method of a top_block will block the calling thread until all items have passed through. Note that this will only succeed if your *source* blocks indicate there are no more items, by returning -1 (gr::block::WORK_DONE). Vector and file sources and other such standard fixed-length sources do, but if your source is merely emitting no items at this time (e.g. a network source that's not currently receiving packets) the flow graph will still be running waiting for more. I do not know of a way to ask for "when all buffers are currently empty", if that's what you need. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to find out if device sink is finished writing samples to radio
Hi, I have a problem with my flowgraphs: at the end of a transmission, I am pushing into the GNU radio source a number of bits which represent the tail end of the transmission. The rate of the flowgraph is not fixed, for some modes the bits will get through faster then for others. I'd like to know when the device sink has finished writing the last sample to the radio so I can stop the transmitting flowgraph, start the receiving flowgraph or adjust the gain or operate an antenna switch. So far I haven't found a way (callback?) to tell when the last sample is out of the flowgraph. I am using the C++ API of GNU radio. Can anyone help me here? Thanks, Adrian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
