Combining Packet Header and Vector Source for BPSK tx
Hi, I have an example of BPSK tx/rx in GNU Radio generated from a vector source and was trying to send a packet that has a sync word, header, and body/data being sent. I see the example at this tutorial Packet Communications - GNU Radio<https://wiki.gnuradio.org/index.php/Packet_Communications> and the example file "Pkt_xmt_gr38.grc" I guess I'm not understanding how I would add the vector source data to the embedded python block "Packet Format GR38"? If you have any suggestions on where I can start to understand this that would be appreciated. Thanks for your help! Michelle
Re: Promblems with gr-air-modes in gnuradio 3.10
Please could you do it? gr-air-modes and gr-adsb are the only applications with which it is possible to decode using USRP as receivers. And both have lower versions of gnuradio than mine (3.10.4.0 ). On 2022-10-03 15:14, Nick Foster wrote: Yep, gr-air-modes hasn't been built, installed, or tested by me. Needs the usual rebuild-from-gr-modtool, and I haven't gotten around to it. Nick On Mon, Oct 3, 2022 at 11:52 AM Philip Balister wrote: On 10/3/22 09:34, Michelle wrote: > Hi Cinaed, > > thank you for your answer, It seems like modes_rx (gr3.9 branch) under > GNU Radio 3.10 hangs somewhere on startup. @willcode4 will try to debug > it. https://github.com/bkerler/gnuradio_install/blob/main/install.sh#L275 Suggests this is not fully ported to 3.10 yet. Philip > > have a good day. > > On 2022-10-02 19:52, Cinaed Simson wrote: >> Hi Michelle - the source code version of gr-air-modes from github >> >> https://github.com/bistromath/gr-air-modes.git >> >> indicates it should build under 3.9 but it doesn't build 3.10 - it >> can't find >> >> GrSwig >> >> which is no longer supported. >> >> Sometimes OOT modules which work on 3.9 work on 3.10 - sometimes they >> don't. >> >> It's possible your version gr-air-modes has a different author from >> git hub version above. >> >> And I don't have a version of 3.9 either so I can't test it on 3.9 . >> >> -- Cinaed >> >> >> >> On 10/1/22 05:18, Michelle wrote: >>> Hello, >>> >>> I have gnuradio 3.10 and I wanted to install gr-air-modes. In the >>> chat one of the moderators told me the version of gr-air-modes that >>> is compatible with gr3.9 would work with gr3.10. >>> So I installed this version in my computer, the installation was >>> successfull however when I execute rx_modes I do not receive any >>> signal. The output of the command is : >>> >>> Inspiron-3793:~$ modes_rx >>> gr-air-modes warning: numpy+scipy not installed, FlightGear interface >>> not supported >>> [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; >>> UHD_3.15.0.0-2build5 >>> [INFO] [B200] Loading firmware image: >>> /usr/share/uhd/images/usrp_b200_fw.hex... >>> [INFO] [B200] Detected Device: B200 >>> [INFO] [B200] Loading FPGA image: >>> /usr/share/uhd/images/usrp_b200_fpga.bin... >>> [INFO] [B200] Operating over USB 2. >>> [INFO] [B200] Detecting internal GPSDO >>> [INFO] [GPS] No GPSDO found >>> [INFO] [B200] Initialize CODEC control... >>> [INFO] [B200] Initialize Radio control... >>> [INFO] [B200] Performing register loopback test... >>> [INFO] [B200] Register loopback test passed >>> [INFO] [B200] Setting master clock rate selection to 'automatic'. >>> [INFO] [B200] Asking for clock rate 16.00 MHz... >>> [INFO] [B200] Actually got clock rate 16.00 MHz. >>> [INFO] [B200] Asking for clock rate 32.00 MHz... >>> [INFO] [B200] Actually got clock rate 32.00 MHz. >>> Setting gain to 38 >>> Gain is 38 >>> Rate is 400 >>> >>> please can i get some support to solve this problem? >>> >>> >> >> >
Re: Promblems with gr-air-modes in gnuradio 3.10
Hi Cinaed, thank you for your answer, It seems like modes_rx (gr3.9 branch) under GNU Radio 3.10 hangs somewhere on startup. @willcode4 will try to debug it. have a good day. On 2022-10-02 19:52, Cinaed Simson wrote: Hi Michelle - the source code version of gr-air-modes from github https://github.com/bistromath/gr-air-modes.git indicates it should build under 3.9 but it doesn't build 3.10 - it can't find GrSwig which is no longer supported. Sometimes OOT modules which work on 3.9 work on 3.10 - sometimes they don't. It's possible your version gr-air-modes has a different author from git hub version above. And I don't have a version of 3.9 either so I can't test it on 3.9 . -- Cinaed On 10/1/22 05:18, Michelle wrote: Hello, I have gnuradio 3.10 and I wanted to install gr-air-modes. In the chat one of the moderators told me the version of gr-air-modes that is compatible with gr3.9 would work with gr3.10. So I installed this version in my computer, the installation was successfull however when I execute rx_modes I do not receive any signal. The output of the command is : Inspiron-3793:~$ modes_rx gr-air-modes warning: numpy+scipy not installed, FlightGear interface not supported [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5 [INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... [INFO] [B200] Detected Device: B200 [INFO] [B200] Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... [INFO] [B200] Operating over USB 2. [INFO] [B200] Detecting internal GPSDO [INFO] [GPS] No GPSDO found [INFO] [B200] Initialize CODEC control... [INFO] [B200] Initialize Radio control... [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Setting master clock rate selection to 'automatic'. [INFO] [B200] Asking for clock rate 16.00 MHz... [INFO] [B200] Actually got clock rate 16.00 MHz. [INFO] [B200] Asking for clock rate 32.00 MHz... [INFO] [B200] Actually got clock rate 32.00 MHz. Setting gain to 38 Gain is 38 Rate is 400 please can i get some support to solve this problem?
Promblems with gr-air-modes in gnuradio 3.10
Hello, I have gnuradio 3.10 and I wanted to install gr-air-modes. In the chat one of the moderators told me the version of gr-air-modes that is compatible with gr3.9 would work with gr3.10. So I installed this version in my computer, the installation was successfull however when I execute rx_modes I do not receive any signal. The output of the command is : Inspiron-3793:~$ modes_rx gr-air-modes warning: numpy+scipy not installed, FlightGear interface not supported [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5 [INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... [INFO] [B200] Detected Device: B200 [INFO] [B200] Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... [INFO] [B200] Operating over USB 2. [INFO] [B200] Detecting internal GPSDO [INFO] [GPS] No GPSDO found [INFO] [B200] Initialize CODEC control... [INFO] [B200] Initialize Radio control... [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Setting master clock rate selection to 'automatic'. [INFO] [B200] Asking for clock rate 16.00 MHz... [INFO] [B200] Actually got clock rate 16.00 MHz. [INFO] [B200] Asking for clock rate 32.00 MHz... [INFO] [B200] Actually got clock rate 32.00 MHz. Setting gain to 38 Gain is 38 Rate is 400 please can i get some support to solve this problem?
Video about how useful GNU Radio is with using Ayecka SR-1 Pro in the Remote Labs at ORI
https://youtu.be/pWAz7GnuXJ8 GNU Radio helps the Open Research Institute accomplish R&D goals for the community. -Michelle Thompson
Re: Problems with the Frequency Xlating FIR Filter
Good morning Martin, please can you explain to me what you mean by REPL? Thank you have a good day On 2022-01-25 05:04, Martin Braun wrote: Can you try running this in a REPL to see what the return value of firdes.lowpass(...) is? --M On Tue, Jan 25, 2022 at 2:03 AM Michelle wrote: hello, I'm using a FIR filter and I have the error : "Param - Taps(taps): Expression None is invalid for type'complex_vector'." my taps is : firdes.low_pass ( 1, samp_rate, frec_carrier, 25000,firdes.WIN_HAMMING ) samp_rate and frec_carrier are both variables in my graph. I don't understand why I have an error. Please could you tell me what I am doing wrong? Thank you.
Problems with the Frequency Xlating FIR Filter
hello, I'm using a FIR filter and I have the error : "Param - Taps(taps): Expression None is invalid for type'complex_vector'." my taps is : firdes.low_pass ( 1, samp_rate, frec_carrier, 25000,firdes.WIN_HAMMING ) samp_rate and frec_carrier are both variables in my graph. I don't understand why I have an error. Please could you tell me what I am doing wrong? Thank you.
Re: Error No module named 'TheNameOfMyModule' in GRC
Hello Ivan, ahhh okay I will do it! thank you for the advice. I have another question, I would like to make a slight modification in the work function of my block. But as I have already installed the block in GRC I was wondering if it's enough to modify the file that contains the work function. On 2022-01-19 5:01 a.m., Ivan Iudice wrote: This is not a final solution… You need to add your library path in /etc/ld.so.conf.d/ in order to see your library everywhere. Have a nice day. Ivan Il giorno 19 gen 2022, alle ore 10:52, Michelle ha scritto: Good morning Vasil, I followed your indications and it works. Thank you :) On 2022-01-18 9:18 a.m., Vasil Velichkov wrote: Hi Michelle, On 18/01/2022 14.01, Michelle wrote: hello, I created an OOT module, added a block and made the block available in GRC. Then I installed the module and called ldconfig (as I'm in ubuntu). My block appears in GRC but when I insert the block in a graph and execute that graph I get an error *No module named 'TheNameOfMyModule'. * Please can you enlighten me on how to fix this issue? I followed the instructions of the wiki https://wiki.gnuradio.org/index.php/OutOfTreeModules Most probably you need to add /usr/local/lib/python3/dist-packages to PYTHONPATH environment variable as this directory is not in the default python search paths (sys.path) Open a new terminal and execute the following export PYTHONPATH=/usr/local/lib/python3/dist-packages:$PYTHONPATH gnuradio-companion to make this change permanent you can add the export line to ~/.profile file and then logout/login or reboot. See also https://wiki.gnuradio.org/index.php/ModuleNotFoundError Regards, Vasil
Re: Error No module named 'TheNameOfMyModule' in GRC
Good morning Vasil, I followed your indications and it works. Thank you :) On 2022-01-18 9:18 a.m., Vasil Velichkov wrote: Hi Michelle, On 18/01/2022 14.01, Michelle wrote: hello, I created an OOT module, added a block and made the block available in GRC. Then I installed the module and called ldconfig (as I'm in ubuntu). My block appears in GRC but when I insert the block in a graph and execute that graph I get an error *No module named 'TheNameOfMyModule'. * Please can you enlighten me on how to fix this issue? I followed the instructions of the wiki https://wiki.gnuradio.org/index.php/OutOfTreeModules Most probably you need to add /usr/local/lib/python3/dist-packages to PYTHONPATH environment variable as this directory is not in the default python search paths (sys.path) Open a new terminal and execute the following export PYTHONPATH=/usr/local/lib/python3/dist-packages:$PYTHONPATH gnuradio-companion to make this change permanent you can add the export line to ~/.profile file and then logout/login or reboot. See also https://wiki.gnuradio.org/index.php/ModuleNotFoundError Regards, Vasil
Re: Error No module named 'TheNameOfMyModule' in GRC
Hi Ivan, thank you for your answer, I had already done it but the error still appears. On 2022-01-18 7:22 a.m., Ivan Iudice wrote: Try to run ldconfig after male install your OOT module. Ivan Il giorno 18 gen 2022, alle ore 13:16, Michelle ha scritto: hello, I created an OOT module, added a block and made the block available in GRC. Then I installed the module and called ldconfig (as I'm in ubuntu). My block appears in GRC but when I insert the block in a graph and execute that graph I get an error *No module named 'TheNameOfMyModule'. * Please can you enlighten me on how to fix this issue? I followed the instructions of the wiki https://wiki.gnuradio.org/index.php/OutOfTreeModules Thank you.
Error No module named 'TheNameOfMyModule' in GRC
hello, I created an OOT module, added a block and made the block available in GRC. Then I installed the module and called ldconfig (as I'm in ubuntu). My block appears in GRC but when I insert the block in a graph and execute that graph I get an error *No module named 'TheNameOfMyModule'. * Please can you enlighten me on how to fix this issue? I followed the instructions of the wiki https://wiki.gnuradio.org/index.php/OutOfTreeModules Thank you.
Re: module SWIG disabled when running cmake
Hello Marcus, No I didn't. Thank you very much, the test passed :) On 2022-01-13 1:45 p.m., Marcus Müller wrote: Hi Michelle! looking at this: have you re-run cmake, and make, before doing ctest? Best regards, Marcus On 13.01.22 19:33, Michelle wrote: Hi Marcus :) I installed swig ( SWIG Version 4.0.1) but when I make the test I still have the same issue: $ ctest -V -R sig_source UpdateCTestConfiguration from :/home/michelle/gr-signalSource/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/michelle/gr-signalSource/build/DartConfiguration.tcl Test project /home/michelle/gr-signalSource/build Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end test 1 Start 1: qa_sig_source 1: Test command: /usr/bin/sh "/home/michelle/gr-signalSource/build/python/qa_sig_source_test.sh" 1: Test timeout computed to be: 1000 1: Traceback (most recent call last): 1: File "/home/michelle/gr-signalSource/python/qa_sig_source.py", line 24, in 1: import signalSource_swig as signalSource 1: ModuleNotFoundError: No module named 'signalSource_swig' 1/1 Test #1: qa_sig_source ***Failed 0.24 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.24 sec The following tests FAILED: 1 - qa_sig_source (Failed) Errors while running CTest On 2022-01-13 12:44 p.m., Marcus Müller wrote: Hi Michelle, On 13.01.22 18:41, Michelle wrote: Good morning Marcus, Hello Marcus, I believe that installing swig is a prerequisite for installing gnuradio. No, it's only necessary for *building* GNU Radio binaries (For GNU Radio 3.7 and 3.8). When I execute locate swig I get the output below so I must have a version of swig. No, these are just swig bindings, not the swig program itself. However when I execute swig -version I get "Command 'swig' not found, but can be installed with: sudo apt install swig". So I don't know what to do. Install swig :) Best regards, Marcus
Re: module SWIG disabled when running cmake
Hi Marcus :) I installed swig ( SWIG Version 4.0.1) but when I make the test I still have the same issue: $ ctest -V -R sig_source UpdateCTestConfiguration from :/home/michelle/gr-signalSource/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/michelle/gr-signalSource/build/DartConfiguration.tcl Test project /home/michelle/gr-signalSource/build Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end test 1 Start 1: qa_sig_source 1: Test command: /usr/bin/sh "/home/michelle/gr-signalSource/build/python/qa_sig_source_test.sh" 1: Test timeout computed to be: 1000 1: Traceback (most recent call last): 1: File "/home/michelle/gr-signalSource/python/qa_sig_source.py", line 24, in 1: import signalSource_swig as signalSource 1: ModuleNotFoundError: No module named 'signalSource_swig' 1/1 Test #1: qa_sig_source ***Failed 0.24 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.24 sec The following tests FAILED: 1 - qa_sig_source (Failed) Errors while running CTest On 2022-01-13 12:44 p.m., Marcus Müller wrote: Hi Michelle, On 13.01.22 18:41, Michelle wrote: Good morning Marcus, Hello Marcus, I believe that installing swig is a prerequisite for installing gnuradio. No, it's only necessary for *building* GNU Radio binaries (For GNU Radio 3.7 and 3.8). When I execute locate swig I get the output below so I must have a version of swig. No, these are just swig bindings, not the swig program itself. However when I execute swig -version I get "Command 'swig' not found, but can be installed with: sudo apt install swig". So I don't know what to do. Install swig :) Best regards, Marcus
module SWIG disabled when running cmake
Hello, I am writing my own block and when I executed /cmake ..// I get the warning "/Disabling SWIG because version check failed/". then when I did the qa test I get the error "/ModuleNotFoundError: No module named 'signalSource_swig'/ " (signalSource is the name of my module). Do I have to install a new version of swig? My concern is that this new version could interfere with the proper functioning of gnuradio. Please could you give me some guidance? Thank you.
Re: Problems when passing messages to a source block
Good morning Jeff,
yes "/data/" was a double, but I already understood the problem (there
was a discussion about that). The source signal block expects the
messages to be in dictionary format not pairs. Finally it works, thank
you for your help :)
Here is the final code:
from gnuradio import gr, blocks
from threading import Thread
import pmt
import numpy
import time
class messageGenerator(gr.sync_block):
def __init__(self, input=[0.5,0,1.5,0]):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=None,
out_sig=None
)
self.message_port_register_out(pmt.intern('out_port'))
self.input = input
self.finished = False
self.thread = None
self.message_list = self.handler(self.input)
def handler(self, aList):
pmt_dict = pmt.make_dict()
msg_list = []
for i in aList:
pmt_dict = pmt.dict_add(pmt_dict, pmt.intern("ampl"),
pmt.from_double(i))
msg_list.append(pmt_dict)
return msg_list
def start(self):
self.finished = False
self.thread = Thread(target=self.run, args=(self.message_list,
), daemon=True)
self.thread.start()
return True
def stop(self):
self.finished = True
self.thread.terminate()
self.thread.join()
return True
def run(self, data):
counter = 0
while(self.finished==False):
for i in data:
self.message_port_pub(pmt.intern('out_port'), i)
time.sleep (1)
return len(data)
On 2021-12-06 7:07 p.m., Jeff Long wrote:
Is "data" a double? Thread() passes "args" to self.run() ...
On Mon, Dec 6, 2021 at 6:32 PM Michelle <mailto:mkprojects...@gmail.com>> wrote:
Hi Jeff,
Thank you very much, all this time I didn't realize.
Now I have the following error:/Warning: failed to XInitThreads()//
//thread[thread-per-block[0]: ]: *pmt_car:
wrong_type : ampl",*/
there is something bad with the red marked line (below) , but
according to what is explained in the wiki that' s how commands
should be encoded. And the doc said that the key for the amplitude
is "ampl"
Please could you review the line marked in red and tell me what is
wrong?
class messageGenerator(gr.sync_block):
def __init__(self, msg=1):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=None,
out_sig=None
)
self.message_port_register_out(pmt.intern('out_port'))
self.msg = msg
self.finished = False
self.thread = None
def start(self):
self.finished = False
self.thread = Thread(target=self.run, args=(self.msg, ),
daemon=True)
self.thread.start()
return True
def stop(self):
self.finished = True
self.thread.stop()
self.thread.join()
return True
def run(self, data):
while(self.finished == False):
msgToSend = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
self.message_port_pub(pmt.intern('out_port'), msgToSend)
time.sleep (1)
return (1)
m=messageGenerator(3)
m.start()
On 2021-12-06 5:14 p.m., Jeff Long wrote:
It is message_port_pub, not msg_port_pub, if that helps.
On Mon, Dec 6, 2021 at 4:48 PM Michelle mailto:mkprojects...@gmail.com>> wrote:
Good evening,
I wonder where the function *msg_port_pub* is defined, I do
not find it anywhere.
I ask because the error "/can't interpret source code:
'messageGenerator' object has no attribute 'msg_port_pub'/**"
persists. I have implemented a handler that calls the
function but it doesn't fix the issue. So I would like to try
2 things:
1) define the original function in my embedded python block
and invoke it. And if it doesn't work,
2) invoke the original C++ function with pybinds.
Thanks you and have a nice evening.
On 2021-12-01 11:26 a.m., Michelle wrote:
Good morning Jeff,
I didn't write you yesterday because the code doesn't work
yet as I want and I was trying to understand why. I don't
have any error message but when I execute my flowgraph the
value of the amplitude doesn't change and I have the warning
"failed to XInitThreads()".I have almost always this warning
in gnuradio so it does not worry me for the moment. below is
my code:
from gnuradio import gr, blocks
from thre
Re: Problems when passing messages to a source block
Hi Jeff,
Thank you very much, all this time I didn't realize.
Now I have the following error:/Warning: failed to XInitThreads()//
//thread[thread-per-block[0]: ]: *pmt_car:
wrong_type : ampl",*/
there is something bad with the red marked line (below) , but according
to what is explained in the wiki that' s how commands should be encoded.
And the doc said that the key for the amplitude is "ampl"
Please could you review the line marked in red and tell me what is wrong?
class messageGenerator(gr.sync_block):
def __init__(self, msg=1):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=None,
out_sig=None
)
self.message_port_register_out(pmt.intern('out_port'))
self.msg = msg
self.finished = False
self.thread = None
def start(self):
self.finished = False
self.thread = Thread(target=self.run, args=(self.msg, ),
daemon=True)
self.thread.start()
return True
def stop(self):
self.finished = True
self.thread.stop()
self.thread.join()
return True
def run(self, data):
while(self.finished == False):
msgToSend = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
self.message_port_pub(pmt.intern('out_port'), msgToSend)
time.sleep (1)
return (1)
m=messageGenerator(3)
m.start()
On 2021-12-06 5:14 p.m., Jeff Long wrote:
It is message_port_pub, not msg_port_pub, if that helps.
On Mon, Dec 6, 2021 at 4:48 PM Michelle <mailto:mkprojects...@gmail.com>> wrote:
Good evening,
I wonder where the function *msg_port_pub* is defined, I do not
find it anywhere.
I ask because the error "/can't interpret source code:
'messageGenerator' object has no attribute 'msg_port_pub'/**"
persists. I have implemented a handler that calls the function
but it doesn't fix the issue. So I would like to try 2 things:
1) define the original function in my embedded python block and
invoke it. And if it doesn't work,
2) invoke the original C++ function with pybinds.
Thanks you and have a nice evening.
On 2021-12-01 11:26 a.m., Michelle wrote:
Good morning Jeff,
I didn't write you yesterday because the code doesn't work yet as
I want and I was trying to understand why. I don't have any error
message but when I execute my flowgraph the value of the
amplitude doesn't change and I have the warning "failed to
XInitThreads()".I have almost always this warning in gnuradio so
it does not worry me for the moment. below is my code:
from gnuradio import gr, blocks
from threading import Thread
import pmt
import numpy
import time
class messageGenerator(gr.sync_block):
def __init__(self, msg=1, period=1):
# calling init of a parent class
gr.sync_block.__init__(
self,
name="message generator",
in_sig=None,
out_sig=None
)
d_port =
self.message_port_register_out(pmt.intern('out_port'))
self.msg = msg
self.period = period
self.finished = False
def start(self):
self.finished = False
a_thread = Thread(target = self.run, args =(self.msg, ))
return True
def stop(self):
self.finished = True
#a_thread.stop()
#a_thread.join()
return True
def run(self, data):
msgToSend = pmt.cons(pmt.intern("ampl"),
pmt.from_double(data))
self.msg_port_pub(d_port, msgToSend)
time.sleep (period)
return (1)
m = messageGenerator(3,1)
m.start()
m.stop()
When I compare your code with mine I realize some of my mistakes:
1) in the start() function I don't start the thread. It is
necessary to add thread.start()
2) same error in the stop function.
3) thread must be an attribute. This answers a problem I had when
I tried to stop and join the thread in the stop function.
I'll try it all and get back to you.
thank you!
On 2021-11-30 4:14 p.m., Jeff Long wrote:
Ha! No, not emailing myself, just a user who was replying
directly. But to continue my conversation (hopefully with the
OP), here is some working code. It does a print() because I
didn't get around to actually sending a pmt as a message, but
you get the idea. Picture of flowgraph attached.
import threading
import time
import numpy as np
from gnuradio import gr
import pmt
class blk(gr.sync_block):
def __init__(self, val=0):
gr.sync_block.__init__(
Re: Problems when passing messages to a source block
Good evening,
I wonder where the function *msg_port_pub* is defined, I do not find it
anywhere.
I ask because the error "/can't interpret source code:
'messageGenerator' object has no attribute 'msg_port_pub'/**" persists.
I have implemented a handler that calls the function but it doesn't fix
the issue. So I would like to try 2 things:
1) define the original function in my embedded python block and invoke
it. And if it doesn't work,
2) invoke the original C++ function with pybinds.
Thanks you and have a nice evening.
On 2021-12-01 11:26 a.m., Michelle wrote:
Good morning Jeff,
I didn't write you yesterday because the code doesn't work yet as I
want and I was trying to understand why. I don't have any error
message but when I execute my flowgraph the value of the amplitude
doesn't change and I have the warning "failed to XInitThreads()".I
have almost always this warning in gnuradio so it does not worry me
for the moment. below is my code:
from gnuradio import gr, blocks
from threading import Thread
import pmt
import numpy
import time
class messageGenerator(gr.sync_block):
def __init__(self, msg=1, period=1):
# calling init of a parent class
gr.sync_block.__init__(
self,
name="message generator",
in_sig=None,
out_sig=None
)
d_port = self.message_port_register_out(pmt.intern('out_port'))
self.msg = msg
self.period = period
self.finished = False
def start(self):
self.finished = False
a_thread = Thread(target = self.run, args =(self.msg, ))
return True
def stop(self):
self.finished = True
#a_thread.stop()
#a_thread.join()
return True
def run(self, data):
msgToSend = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
self.msg_port_pub(d_port, msgToSend)
time.sleep (period)
return (1)
m = messageGenerator(3,1)
m.start()
m.stop()
When I compare your code with mine I realize some of my mistakes:
1) in the start() function I don't start the thread. It is necessary
to add thread.start()
2) same error in the stop function.
3) thread must be an attribute. This answers a problem I had when I
tried to stop and join the thread in the stop function.
I'll try it all and get back to you.
thank you!
On 2021-11-30 4:14 p.m., Jeff Long wrote:
Ha! No, not emailing myself, just a user who was replying directly.
But to continue my conversation (hopefully with the OP), here is some
working code. It does a print() because I didn't get around to
actually sending a pmt as a message, but you get the idea. Picture of
flowgraph attached.
import threading
import time
import numpy as np
from gnuradio import gr
import pmt
class blk(gr.sync_block):
def __init__(self, val=0):
gr.sync_block.__init__(
self,
name='Show Value',
in_sig=[],
out_sig=[]
)
self.message_port_register_out(pmt.intern("msgout"))
self.val = val
self.thread = None
print('init')
def start(self):
print('start')
self.stopit = False
self.thread = threading.Thread(target=self.run, daemon=True)
self.thread.start()
return True
def stop(self):
print('stop')
self.stopit = True
self.thread.join()
return True
def set_val(self, val):
self.val = val
def run(self):
while(not self.stopit):
print(f'val={self.val} (would send as message)')
time.sleep(1)
On Tue, Nov 30, 2021 at 2:13 AM Marcin Puchlik
mailto:m.puch...@is-wireless.com>> wrote:
Jeff,
Are you mailing with yourself?
wt., 30 lis 2021 o 00:46 Jeff Long mailto:willco...@gmail.com>> napisał(a):
Sounds good. Only look at the C++ to figure out the general
idea. I'd learn Python threading first in a standalone
program so you're not learning (debugging) GR and python
threading at the same time. Good luck - let us know how it goes.
Also, please respond to the mailing list so everyone can
benefit from the conversation.
On Mon, Nov 29, 2021 at 5:11 PM Michelle
mailto:mkprojects...@gmail.com>> wrote:
Hi Jeff,
thank you for your help and sorry for the delay, I was in
class.
it is now that I start to work on it. My first step is to
master how the c++ code of the strobe message block work,
specially the functions:
-bool message_strobe_impl::start()
-bool message_strobe_impl::stop()
-void message_strobe_impl::run()
Then I will implement the python vers
Re: Problems when passing messages to a source block
Good morning Jeff,
I didn't write you yesterday because the code doesn't work yet as I want
and I was trying to understand why. I don't have any error message but
when I execute my flowgraph the value of the amplitude doesn't change
and I have the warning "failed to XInitThreads()".I have almost always
this warning in gnuradio so it does not worry me for the moment. below
is my code:
from gnuradio import gr, blocks
from threading import Thread
import pmt
import numpy
import time
class messageGenerator(gr.sync_block):
def __init__(self, msg=1, period=1):
# calling init of a parent class
gr.sync_block.__init__(
self,
name="message generator",
in_sig=None,
out_sig=None
)
d_port = self.message_port_register_out(pmt.intern('out_port'))
self.msg = msg
self.period = period
self.finished = False
def start(self):
self.finished = False
a_thread = Thread(target = self.run, args =(self.msg, ))
return True
def stop(self):
self.finished = True
#a_thread.stop()
#a_thread.join()
return True
def run(self, data):
msgToSend = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
self.msg_port_pub(d_port, msgToSend)
time.sleep (period)
return (1)
m = messageGenerator(3,1)
m.start()
m.stop()
When I compare your code with mine I realize some of my mistakes:
1) in the start() function I don't start the thread. It is necessary to
add thread.start()
2) same error in the stop function.
3) thread must be an attribute. This answers a problem I had when I
tried to stop and join the thread in the stop function.
I'll try it all and get back to you.
thank you!
On 2021-11-30 4:14 p.m., Jeff Long wrote:
Ha! No, not emailing myself, just a user who was replying directly.
But to continue my conversation (hopefully with the OP), here is some
working code. It does a print() because I didn't get around to
actually sending a pmt as a message, but you get the idea. Picture of
flowgraph attached.
import threading
import time
import numpy as np
from gnuradio import gr
import pmt
class blk(gr.sync_block):
def __init__(self, val=0):
gr.sync_block.__init__(
self,
name='Show Value',
in_sig=[],
out_sig=[]
)
self.message_port_register_out(pmt.intern("msgout"))
self.val = val
self.thread = None
print('init')
def start(self):
print('start')
self.stopit = False
self.thread = threading.Thread(target=self.run, daemon=True)
self.thread.start()
return True
def stop(self):
print('stop')
self.stopit = True
self.thread.join()
return True
def set_val(self, val):
self.val = val
def run(self):
while(not self.stopit):
print(f'val={self.val} (would send as message)')
time.sleep(1)
On Tue, Nov 30, 2021 at 2:13 AM Marcin Puchlik
mailto:m.puch...@is-wireless.com>> wrote:
Jeff,
Are you mailing with yourself?
wt., 30 lis 2021 o 00:46 Jeff Long mailto:willco...@gmail.com>> napisał(a):
Sounds good. Only look at the C++ to figure out the general
idea. I'd learn Python threading first in a standalone program
so you're not learning (debugging) GR and python threading at
the same time. Good luck - let us know how it goes.
Also, please respond to the mailing list so everyone can
benefit from the conversation.
On Mon, Nov 29, 2021 at 5:11 PM Michelle
mailto:mkprojects...@gmail.com>> wrote:
Hi Jeff,
thank you for your help and sorry for the delay, I was in
class.
it is now that I start to work on it. My first step is to
master how the c++ code of the strobe message block work,
specially the functions:
-bool message_strobe_impl::start()
-bool message_strobe_impl::stop()
-void message_strobe_impl::run()
Then I will implement the python version following your
advice. I will write to you to show you the result.
Once again thank you, I was really lost.
Have a good afternoon.
OK, it does work, as long as there is a message port
defined and connected in a flowgraph. I was trying too
simple an example. You would do your thread management in
the start() and stop() functions.
"""
Embedded Python Blocks:
Each time this file is saved, GRC will instantiate the
first class it finds
Problems when passing messages to a source block
Good morning,
I want to generate a source controlled by voltage. Basically, I send
messages to a source in order to change its amplitude. I have built a
block to generate messages and pass them to the source. To do so, I
created an "embedded python block " that generates and transmits a
message every second, here is the python code of my block:
from gnuradio import gr, blocks
import pmt
import numpy
import time
#The block receives input data (the amplitude of a signal) then
generates a message to be passed to a constant source so that the latter
modifies its amplitude"
class message_generator(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=[numpy.float32], #amplitude that the signal must have
out_sig=None
)
self.message_port_register_out(pmt.intern('out_port'))
def work(self, input_items, output_items):
self.msg_port_pub(pmt.intern('out_port'),
pmt.cons(pmt.intern("ampl"), pmt.from_double(input_items[0][0])))
time.sleep(1)
return 1
when I execute my flowgraph in gnuradio I have the error :
self.msg_port_pub(pmt.intern('out_port'), pmt.cons(pmt.intern("ampl"),
pmt.from_double(input_items[0][0])))
AttributeError: 'message_generator' object has no attribute
'msg_port_pub' . And I can't understand why if in the
qa_python_message_passing.py
(below ) the function message_port_pub is called the same way as I do in
mine.
class message_generator(gr.sync_block):
def __init__(self, msg_interval = 10):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=[numpy.float32], #amplitude that the signal must have
out_sig=None
)
self.msg_list = []
#self.message_port_register_in(pmt.intern('in_port'))
self.message_port_register_out(pmt.intern('out_port'))
self.msg_interval = msg_interval
self.msg_ctr = 0
def work(self, input_items, output_items):
inLen = len(input_items[0])
# Create a new PMT for each input value and put it in the
message list
self.msg_list.append(pmt.from_double(input_items[0][0]))
while self.msg_ctr < len(self.msg_list) and \
(self.msg_ctr * self.msg_interval) < \
(self.nitems_read(0) + inLen):
self.message_port_pub(pmt.intern('out_port'),
pmt.cons(pmt.intern("ampl"),self.msg_list[self.msg_ctr]))
self.msg_ctr += 1
return inLen
PLease can you explain to me what is wrong on my code? I even tried to
put an attribute "msg_port_pub" when declaring the class but I still
have the same error.
from gnuradio import gr, blocks
import pmt
import numpy
import time
class message_generator(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=[numpy.float32], #amplitude that the signal must have
out_sig=None
)
d_port= self.message_port_register_out(pmt.intern('out_port'))
self.msg_port_pub(d_port, self.buildMessage)
def buildMessage(self, data):
msg = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
return msg
def work(self, input_items, output_items):
messageToSend = builMessage(input_items=[0][0])
self.msg_port_pub(d_port, messageToSend)
time.sleep(1)
return 1
You can find attached my flowgraph and the resulting python code.
Thank you in advance and have a good day.
xx.grc
Description: application/gnuradio-grc
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# SPDX-License-Identifier: GPL-3.0
#
# GNU Radio Python Flow Graph
# Title: xx
# Author: me
# GNU Radio version: 3.8.2.0
from distutils.version import StrictVersion
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print("Warning: failed to XInitThreads()")
from PyQt5 import Qt
from gnuradio import qtgui
from gnuradio.filter import firdes
import sip
from gnuradio import analog
from gnuradio import blocks
from gnuradio import gr
import sys
import signal
from argparse import ArgumentParser
from gnuradio.eng_arg import eng_float, intx
from gnuradio import eng_notation
import epy_block_1
from gnuradio import qtgui
class xx(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "xx")
Qt.QWidget.__init__(self)
self.setWindowTitle("xx")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top
Re: RF signals are pure noise in Python implementation
I'm doing a similar thing for something that works like zigbee. Do you have a link to your code? I think it should be working better than what you're seeing. -Michelle W5NYV On Thu, Nov 25, 2021 at 5:59 AM Verónica Toro Betancur wrote: > Hi, > > I am trying to detect and decode WiFi and ZigBee signals in GNURadio. For > the detection, I have implemented my own blocks in Python. It all works > well with simulated signals but the problem comes when I use radios to > acquire real signals. I'm using Pluto SDR and it works perfectly when I use > it in workflow examples but not in my own implementation. I mean, I plot > the data that comes directly from the radio and it looks good in the given > examples but, in mine, it looks like noise. > > I am using the exact same parameters in both cases. The only difference I > see is that the blocks in the example are all in C++ while mine are in > Python. Could this be the problem? If so, is there a way to solve it other > than writing the blocks in C++? > > Thanks in advance. > > > Best regards, > Verónica >
Re: Call for Submissions: GNU Radio "Block Party" Articles for ARRL QEX Magazine
Greetings all! Special thanks to Jean-Michel Friedt for submitting the first Block Party article for QEX Magazine. If you are thinking about submitting an article for this series, then please get in touch and I will do all I can to make the job easier. -Michelle W5NYV On Wed, Jun 30, 2021 at 4:27 PM Michelle Thompson < mountain.miche...@gmail.com> wrote: > Call for Submissions: GNU Radio "Block Party" Articles for ARRL QEX > Magazine > > You are invited to contribute an article for ARRL QEX Magazine. The QEX > editor Kai Siwiak (https://www.linkedin.com/in/kai-siwiak-002123/) at > ARRL's QEX Magazine (http://www.arrl.org/qex) is open to and interested > in publishing a number of articles about GNU Radio Blocks! > > This may become a regular series of articles. Authors receive financial > compensation for accepted contributions and make a direct and enduring > contribution to increased technical expertise in the amateur radio > community with their published work. > > What do you need to do? > 1) pick a block! > 2) use the template! > 3) write your amazing 1000-1500 word article! > 4) submit your article! If you want it to be considered for this special > category of writing, please send it to me at w5...@arrl.net > 5) enjoy being able to teach the amateur radio world more about GNU Radio, > one block at a time. > > Here is the GNU Radio Block Party article template. > > A. Introduction > > GNU Radio is a free and open-source software development toolkit. It > provides signal processing blocks that implement software radios. GNU Radio > can be used with readily-available low-cost external RF hardware to create > software-defined radios, or without hardware in a simulation-like > environment. GNU Radio is widely used in amateur radio. > > GNU Radio is used in a format called flowgraphs. These graphs are composed > of functional blocks. Each of these blocks performs a specific task. Each > block is connected to other blocks by inputs and/or outputs. Connections > between blocks are represented on the screen as directional arrows. > > Flowgraphs look very much like traditional system block diagrams. > Flowgraphs can serve as a description or documentation of a radio > architecture. Unlike a block diagram on a sheet of paper, GNU Radio > flowgraphs operate directly on live signals, can do almost any digital > signal processing, and produce a huge variety of useful signals. > > B. Introduce and Describe Your Block > > > > Introduce a block of interest to radio amateurs. > Describe the block's function in detail. > Describe an application where this block would be used. > Include any necessary theory for understanding this block. > Provide or reference an example flowgraph. > > C. Writing Prompts > > Use some, all, or none of the following Writing Prompts. These are > suggestions to spark your creativity and are not coverage requirements. > > What does this block "really" do? > Is the function "under the hood" not exactly the same as what people > assume it to be? > Is this block designed for a particular type of communication or for a > particular community? > What would the equivalent hardware circuit look like? > Does the block have no achievable equivalent in hardware? > What is the advantage to using a software component instead of the > equivalent hardware? > Who are the primary contributors? Why did they write this block? If they > had to do it over, what would they do differently? > Are there any open issues with this block? If someone wanted to help with > this block, how would they contribute? > How do digital samples get into and/or out of this block? > Does this block require other blocks to work properly? > What is configurable in the block? > What things can't be changed in this block? > Are there any quirks? > Are there any "war stories" in this block's history? > Have there been any major bugs with this block? > Is there a way this block can be mis-used or create unexpected results? > Is the block computationally efficient, or not? Why? > Does the block use any notable or unusual programming or mathmatic > techniques? > > > D. Questions? Comments? Critique? Please let me know at: > > w5...@arrl.net > > -Michelle W5NYV >
Call for Submissions: GNU Radio "Block Party" Articles for ARRL QEX Magazine
Call for Submissions: GNU Radio "Block Party" Articles for ARRL QEX Magazine You are invited to contribute an article for ARRL QEX Magazine. The QEX editor Kai Siwiak (https://www.linkedin.com/in/kai-siwiak-002123/) at ARRL's QEX Magazine (http://www.arrl.org/qex) is open to and interested in publishing a number of articles about GNU Radio Blocks! This may become a regular series of articles. Authors receive financial compensation for accepted contributions and make a direct and enduring contribution to increased technical expertise in the amateur radio community with their published work. What do you need to do? 1) pick a block! 2) use the template! 3) write your amazing 1000-1500 word article! 4) submit your article! If you want it to be considered for this special category of writing, please send it to me at w5...@arrl.net 5) enjoy being able to teach the amateur radio world more about GNU Radio, one block at a time. Here is the GNU Radio Block Party article template. A. Introduction GNU Radio is a free and open-source software development toolkit. It provides signal processing blocks that implement software radios. GNU Radio can be used with readily-available low-cost external RF hardware to create software-defined radios, or without hardware in a simulation-like environment. GNU Radio is widely used in amateur radio. GNU Radio is used in a format called flowgraphs. These graphs are composed of functional blocks. Each of these blocks performs a specific task. Each block is connected to other blocks by inputs and/or outputs. Connections between blocks are represented on the screen as directional arrows. Flowgraphs look very much like traditional system block diagrams. Flowgraphs can serve as a description or documentation of a radio architecture. Unlike a block diagram on a sheet of paper, GNU Radio flowgraphs operate directly on live signals, can do almost any digital signal processing, and produce a huge variety of useful signals. B. Introduce and Describe Your Block Introduce a block of interest to radio amateurs. Describe the block's function in detail. Describe an application where this block would be used. Include any necessary theory for understanding this block. Provide or reference an example flowgraph. C. Writing Prompts Use some, all, or none of the following Writing Prompts. These are suggestions to spark your creativity and are not coverage requirements. What does this block "really" do? Is the function "under the hood" not exactly the same as what people assume it to be? Is this block designed for a particular type of communication or for a particular community? What would the equivalent hardware circuit look like? Does the block have no achievable equivalent in hardware? What is the advantage to using a software component instead of the equivalent hardware? Who are the primary contributors? Why did they write this block? If they had to do it over, what would they do differently? Are there any open issues with this block? If someone wanted to help with this block, how would they contribute? How do digital samples get into and/or out of this block? Does this block require other blocks to work properly? What is configurable in the block? What things can't be changed in this block? Are there any quirks? Are there any "war stories" in this block's history? Have there been any major bugs with this block? Is there a way this block can be mis-used or create unexpected results? Is the block computationally efficient, or not? Why? Does the block use any notable or unusual programming or mathmatic techniques? D. Questions? Comments? Critique? Please let me know at: w5...@arrl.net -Michelle W5NYV
Re: Survey regarding GNU radio usage in amateur radio
Thank you for posting this. I will definitely participate. There’s been a lot of effort over the past 4 years to include and enable amateur radio participation and representation in GNU Radio, especially at the conference. This includes multiple technical presentations, on-site special event stations, very successful license exam sessions, three years of amateur developer summit meetups, amateur-friendly vendors, a dedicated room for amateur demos in 2018, and more. I think this effort has paid off in several significant ways, and I hope it continues in the upcoming SETI era. I look forward to the published results and will help spread the word about the survey. -Michelle W5NYV On Sat, Nov 14, 2020 at 00:12 Adrian Musceac wrote: > Hello, > > > > I am doing a survey regarding the topic of GNU radio usage in amateur > radio > > activities. > > This survey is aimed at GNU radio users who are also amateur radio > operators. > > The result of the survey will be published in an article freely available > on > > the Internet and may also be translated to other languages for reading by > > other amateur radio operators. > > > > Your contribution to the survey will remain anonymous unless you express a > > wish to have author attribution for the answers. > > You should be comfortable with the license of publication which will be > one of > > Creative Commons Attribution 4.0 license or GNU Free Documentation license. > > You may reply directly or send me the answers privately. The date limit > for > > answers is 30 December current year. > > > > I will ask you to respond to the following questions (you may omit > questions > > where you do not have answers): > > > > > > 1. Are you actively using GNU radio in amateur radio activities? > > > > 2. If yes, how are you using GNU radio, please provide some details. > > > > 3. Do you think GNU radio and applications using it solve some specific > problem > > for amateur operators which is not solved by other free software DSP > > libraries, or, on the contrary, do you think it should implement a > solution > > that already exists elsewhere? > > > > 4. What would you consider strong and weak points in GNU radio when > related to > > amateur radio usage? > > > > 5. Is your local amateur radio community generally aware of the existence > of > > GNU radio? > > > > 6. If you have any authored / co-authored published papers, talk slides, > > seminars etc. related to the topic of this survey, can you provide a short > > description and a link if available? > > > > 7. Are you involved in research projects which use amateur radio > crowd-sourced > > data, and if so, can you provide a short description of the project? > > > > 8. Do you have any suggestions for raising general amateur radio public > > awareness of free software in general and specifically GNU radio? > > > > > > Thanks in advance for answering. > > > > Adrian > > > > > > > > -- -Michelle W5NYV "Potestatem obscuri lateris nescis."
Re: CTF
You're very welcome! Best of luck and I hope to be able to participate. -Michelle W5NYV On Wed, Oct 14, 2020 at 2:35 PM Federico 'Larroca' La Rocca < flarr...@gmail.com> wrote: > Hi everyone, > > I wanted to let you all know about the upcoming (virtual) capture the flag > we are organizing at our university. The main event's website is > http://idm.uy/ and our's is https://ctf.idm.uy/. > > It is completely open, so anyone can register (although the webpage is in > spanish). It starts next sunday. > > Let me know if you have any questions. > Thanks to Michelle Thompson from whom we got several ideas. > > Best > Federico > >
Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group
I can present about the Final Determination letter recently received from the US State Department concerning the amateur radio satellite service. Open Source satellite work has been determined to be free of ITAR. -Michelle W5NYV On Tue, Sep 22, 2020 at 5:33 AM Barry Duggan wrote: > Thank you for your feedback! It looks like we have a viable idea. > > Here are some additional items to consider: > > ** use BigBlueButton or Zoom > > ** have a host / moderator present a topic with a demonstration > > ** limit to one hour (especially if using BigBlueButton) > > ** a time on the weekend might be better - something like 20:00 UTC? > > ** I will put out a news entry on the gnuradio.org homepage as soon as a > kickoff seems feasible. Marcus will help "as much as he can" > > ** possibly start a GR Ham Radio mailing list like discuss-gnuradio > > Thank you for your continued interest and ideas. > > 73 and stay safe, > --- > Barry Duggan KV4FV > https://github.com/duggabe > > On Mon, 21 Sep 2020 11:13:29 +0200, Marcus Müller wrote: > > Hello Barry, hi everyone, > > I just wanted to say I was very impressed with all the activity in the > breakout session, and how productive everything was. > > I'd find it super interesting if aside from the social benefit of > ragchewing (no matter whether that happens on a video conference, via > pure voice comms, or in a text chat), people had would also take the > chance to give a short "impulse" presentation on what they think would > be interesting for the rest; for example, I think Barry's digital > modulations tutorials would be extremely interesting for a lot of people. > > But also, a bit on stuff like (brainstorming here) "how to make use of > the new digital predistortion module to get the most out of my system", > "I've invented a digital mode, and you'll never guess what happened > next", "how it took me a month to figure out why I wasn't seeing any > satellites and why I hate storks", "SDR in club education settings", …. > > Nothing that takes 2 hours, but something to get discussion off the > ground, and then if discussion shows people like where things are going, > go deeper into it. > > Cheers, > Marcus > >
Virtual GNU Radio Conference 2020 - Call for Participation
Virtual GRCon20 - Call for Participation Greetings! I'm the chair of GNU Radio Conference 2020, starting 14 September 2020. This will be a fun, accessible, and exciting experience. All participants will be welcomed and supported. We have your back! What do we need in order to succeed? GNU Radio content. Submit your work for presentation at https://www.gnuradio.org/grcon/grcon20/submit/ We are looking for papers, presentations, posters, workshops, and lightning talks. Don't have time or energy for a complete submission? Don't let that stop you. If you have real interest in presenting in September 2020, start the process today. Enter in as much as you can about what you want to share with the community. The organizing team is here to help you make it happen and have fun doing it. Need convincing, feel your work isn't good enough to share, or don't really know how things could possibly work for a virtual event? Read on! We have excellent professional support for this event from ConFreaks. We have outstanding keynote speakers lined up. We have numerous workshop proposals submitted from organizations you know and trust. What do we need? You, sharing your work! The barriers to participate at GRCon have never been lower. This gives us the best possible chance to raise expectations on what we can achieve with the event. Traditional GRCon is expensive to attend. It's held during the work week in a US time zone. Virtual GRCon cannot replace everything we lose by not being able to have an in-person event, but we can make it radically affordable, inclusive, meaningful, and interactive for a large part of the globe. I hear from many community members all year long that have doubts about their work being "good enough" to present at the conference. I want to make it clear that the conference team is here to help, support, and develop quality presentations, not just "review" and "judge" complete work. No, we can't do the engineering for you, but we can help you put your work in the best possible light with feedback and encouragement. That is, if you start now and submit your work. Registration for presentation track is free. Workshop fee (covers all workshops) is $50. Students are completely free, including the workshops. Register here: https://tickets.gnuradio.org/grcon20/ Questions? Comments? Want to volunteer? We need reviewers and people interested in gaining experience with running an online conference event. Write gr...@gnuradio.org or me directly. Know someone that needs to know about GRCon20? Pass along the attached pdf. -Michelle Thompson W5NYV w5...@arrl.net C4A_GRCon20_Virtual.pdf Description: Adobe PDF document
Re: Lunar Orbiting Platform Gateway
Here are the slides from recent ARISS presentations at AMSAT Space Symposium, and a paper presented at IAC about ARISS' view of amateur radio on the Gateway project. The IAC presentation can be downloaded from: https://www.dropbox.com/s/73yhtpmo8nn5x46/IAC%20Gateway%2010-21-19%20Final.pptx?dl=0 Here are the slides about amateur radio for Gateway: AMSAT BoD Presentation: https://www.dropbox.com/s/tf65twlojkw4zce/ARISS-AMSAT%20BoD%202019.pptx?dl=0 Gateway Presentation given in the symposium: https://www.dropbox.com/s/rkd6wfjeu5c4iie/Gateway-AREx%20AMSAT%20Symposium%202019.pptx?dl=0 Thank you to Frank Bauer for providing all of this content. What can we do to support, extend, and enhance the effort to get open source DSP framework content better represented in space through the Gateway project? -Michelle W5NYV On Wed, Oct 30, 2019 at 11:57 AM John Malsbury wrote: > And you mentioned something about amateur radio portions, Michelle? > > On Wed, Oct 30, 2019 at 11:52 AM Kevin K Gifford < > kevin.giff...@colorado.edu> wrote: > >> Hi - >> >> I am involved in recommending the radio communications architecture for >> Gateway which is baselined to utilize CCSDS (see cases.org) protocols. >> >> For long-haul RF links (Gateway to Earth) Unified Space Link Protocol >> (USLP). >> >> For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS >> >> For proximity wireless networks (around Gateway and on lunar surface) >> 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration. >> >> Please feel free to respond directly if additional information is needed >> and I’ll strive to assist. >> >> Kevin >> -- >> *From:* Discuss-gnuradio > colorado@gnu.org> on behalf of John Malsbury < >> jmalsbury.perso...@gmail.com> >> *Sent:* Wednesday, October 30, 2019 12:34 PM >> *To:* Michelle Thompson >> *Cc:* discuss-gnuradio@gnu.org >> *Subject:* Re: Lunar Orbiting Platform Gateway >> >> It was a cheap joke on my part (and not at all commentary on the gateway >> concept). Disregard. >> >> I'd be down to collaborate on something open source. Could you point to >> publicly available documents that summarize the standards/specs? >> >> -John >> >> On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson < >> mountain.miche...@gmail.com> wrote: >> >> I was hesitant to ask why, but I'm curious now. >> >> I know the Gateway is controversial. I understand there's a lot of doubt >> it will actually happen. The heavy emphasis on commercial activity is >> another aspect. >> >> However, I've been asked for help on a receiving station for the amateur >> radio portions that might be included. There's a lot of overlap between >> what I do and the type of communications proposed. >> >> Comment and critique would be very appreciated here. >> >> -Michelle W5NYV >> >> >> >> >> On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) >> wrote: >> >> Hey John, >> >> > > Anyone working on… >> > Definitely not >> >> Does that imply they're finished? >> >> Best regards, >> Marcus >> >>
Re: Lunar Orbiting Platform Gateway
Thank you. This, along with the ICSIS, have been very helpful in learning about what's going on and what to expect in the developing radio environment. A proposed amateur radio plan (from ARISS) is in addition to what's covered in the Architecture report and the ICSIS. I'll forward whatever I can get as soon as I can. -Michelle W5NYV On Fri, Nov 1, 2019 at 4:23 AM Kevin K Gifford wrote: > Hi Space-RF-SDR enthusiasts - > > Please see below link for the recent (9/25/2019) space agencies lunar > communications architecture final report that has detailed information on > the planned communications links, protocols and frequencies. > > > https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=2ahUKEwi85KXB8sjlAhUDWa0KHcQhA7MQFjABegQIBBAC&url=https%3A%2F%2Fwww.ioag.org%2FPublic%2520Documents%2FLunar%2520communications%2520architecture%2520study%2520report%2520Final%25209-25-2019.docx&usg=AOvVaw127_IRN2aAY9Kbmnt4IBlt > > This is the current baseline for Gateway and downstream lunar surface > operational infrastructure. The protocol specifications are all available > at ccsds.org. > > Kevin > -- > *From:* Michelle Thompson > *Sent:* Thursday, October 31, 2019 5:41 PM > *To:* John Malsbury > *Cc:* Kevin K Gifford ; > discuss-gnuradio@gnu.org > *Subject:* Re: Lunar Orbiting Platform Gateway > > Yes - I'm attempting to get a copy of the slides from recent ARISS > presentations. There was a diagram with planned frequencies. Plenty to work > with. > > -Michelle W5NYV > > > > > On Wed, Oct 30, 2019 at 11:57 AM John Malsbury < > jmalsbury.perso...@gmail.com> wrote: > > And you mentioned something about amateur radio portions, Michelle? > > On Wed, Oct 30, 2019 at 11:52 AM Kevin K Gifford < > kevin.giff...@colorado.edu> wrote: > > Hi - > > I am involved in recommending the radio communications architecture for > Gateway which is baselined to utilize CCSDS (see cases.org > <http://secure-web.cisco.com/14BfF4_24IRkgzQdyG_jVmFaYx-p8IuZGUlAWDhtloQT8XzN1W3LBL_cN4g9UjzZYzfzFwZYsCSX9rbuLRipLqtFi_vFoOeD7UoxtQjgChHIHjVL1DjRmZaBxaCP97TiIon4SuS1OlazDts1JZkzLqqo_Hl0qA06M5CBsHM5F5Fsda-LQZqgszJV3969nFHeMXUlFEbOWB9XQxWVyQI5nqx4os_FIe5eTaHe-XgVMFwMsz0KPRA8508CeME_1tOZFpMfD3N_nZEWdxFrutEx-r0vU4g6eHdXPRo-6dTGSJZINF4NfgAeonKOsrHV0wB_XuI9bKTxba5cxUUjmSFT6fuHDaud1jnKtNj2lND4zj98TRcXGKyxtsWzlMKeq9miIB20mSjOTK0ymPTqoRcScFE6vX4eyTdsdoSETs9ICb23WVbioaFtfrts5GvWi7XzOPYo4bohK-DVr6VEnfDu1SQ/http%3A%2F%2Fcases.org>) > protocols. > > For long-haul RF links (Gateway to Earth) Unified Space Link Protocol > (USLP). > > For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS > > For proximity wireless networks (around Gateway and on lunar surface) > 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration. > > Please feel free to respond directly if additional information is needed > and I’ll strive to assist. > > Kevin > -- > *From:* Discuss-gnuradio colorado@gnu.org> on behalf of John Malsbury < > jmalsbury.perso...@gmail.com> > *Sent:* Wednesday, October 30, 2019 12:34 PM > *To:* Michelle Thompson > *Cc:* discuss-gnuradio@gnu.org > *Subject:* Re: Lunar Orbiting Platform Gateway > > It was a cheap joke on my part (and not at all commentary on the gateway > concept). Disregard. > > I'd be down to collaborate on something open source. Could you point to > publicly available documents that summarize the standards/specs? > > -John > > On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson < > mountain.miche...@gmail.com> wrote: > > I was hesitant to ask why, but I'm curious now. > > I know the Gateway is controversial. I understand there's a lot of doubt > it will actually happen. The heavy emphasis on commercial activity is > another aspect. > > However, I've been asked for help on a receiving station for the amateur > radio portions that might be included. There's a lot of overlap between > what I do and the type of communications proposed. > > Comment and critique would be very appreciated here. > > -Michelle W5NYV > > > > > On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) > wrote: > > Hey John, > > > > Anyone working on… > > Definitely not > > Does that imply they're finished? > > Best regards, > Marcus > >
Re: Lunar Orbiting Platform Gateway
Yes - I'm attempting to get a copy of the slides from recent ARISS presentations. There was a diagram with planned frequencies. Plenty to work with. -Michelle W5NYV On Wed, Oct 30, 2019 at 11:57 AM John Malsbury wrote: > And you mentioned something about amateur radio portions, Michelle? > > On Wed, Oct 30, 2019 at 11:52 AM Kevin K Gifford < > kevin.giff...@colorado.edu> wrote: > >> Hi - >> >> I am involved in recommending the radio communications architecture for >> Gateway which is baselined to utilize CCSDS (see cases.org) protocols. >> >> For long-haul RF links (Gateway to Earth) Unified Space Link Protocol >> (USLP). >> >> For short-haul RF (Gateway to lunar surface): Proximity-1 and AOS >> >> For proximity wireless networks (around Gateway and on lunar surface) >> 802.11 n/ac baselined, 802.11ax and LTE are under strong consideration. >> >> Please feel free to respond directly if additional information is needed >> and I’ll strive to assist. >> >> Kevin >> -- >> *From:* Discuss-gnuradio > colorado@gnu.org> on behalf of John Malsbury < >> jmalsbury.perso...@gmail.com> >> *Sent:* Wednesday, October 30, 2019 12:34 PM >> *To:* Michelle Thompson >> *Cc:* discuss-gnuradio@gnu.org >> *Subject:* Re: Lunar Orbiting Platform Gateway >> >> It was a cheap joke on my part (and not at all commentary on the gateway >> concept). Disregard. >> >> I'd be down to collaborate on something open source. Could you point to >> publicly available documents that summarize the standards/specs? >> >> -John >> >> On Wed, Oct 30, 2019 at 8:50 AM Michelle Thompson < >> mountain.miche...@gmail.com> wrote: >> >> I was hesitant to ask why, but I'm curious now. >> >> I know the Gateway is controversial. I understand there's a lot of doubt >> it will actually happen. The heavy emphasis on commercial activity is >> another aspect. >> >> However, I've been asked for help on a receiving station for the amateur >> radio portions that might be included. There's a lot of overlap between >> what I do and the type of communications proposed. >> >> Comment and critique would be very appreciated here. >> >> -Michelle W5NYV >> >> >> >> >> On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) >> wrote: >> >> Hey John, >> >> > > Anyone working on… >> > Definitely not >> >> Does that imply they're finished? >> >> Best regards, >> Marcus >> >>
Re: Lunar Orbiting Platform Gateway
I was hesitant to ask why, but I'm curious now. I know the Gateway is controversial. I understand there's a lot of doubt it will actually happen. The heavy emphasis on commercial activity is another aspect. However, I've been asked for help on a receiving station for the amateur radio portions that might be included. There's a lot of overlap between what I do and the type of communications proposed. Comment and critique would be very appreciated here. -Michelle W5NYV On Wed, Oct 30, 2019 at 7:14 AM Müller, Marcus (CEL) wrote: > Hey John, > > > > Anyone working on… > > Definitely not > > Does that imply they're finished? > > Best regards, > Marcus >
Lunar Orbiting Platform Gateway
Anyone working on blocks specifically for Lunar Orbiting Platform Gateway? Or interested in doing so? -Michelle W5NYV -- -Michelle W5NYV "Potestatem obscuri lateris nescis."
[Discuss-gnuradio] Fwd: [hamsci-swstation] A Little Fun with Digital RF
I enjoyed reading this writeup from a GNU Radio user, and wanted to share it. -Michelle W5NYV -- Forwarded message - From: Greg KF5N Date: Sun, Dec 2, 2018 at 5:01 PM Subject: [hamsci-swstation] A Little Fun with Digital RF To: hamsci-swstation I had a great time at the TAPR Conference in Albuquerque, and I was especially intrigued by the Space Weather discussion in the Sunday seminar. Nathaniel's description of "Digital RF" really got my attention, and I decided I wanted to experiment with it. That took some doing, because I had to get a receiver and come up to speed on GNU Radio. So about 3 months later playing with radios, computers, and software here is a report on my experiments: https://github.com/Greg-R/explore_digital_rf/blob/master/docs/explore_digital_rf.pdf The top of the repository is here: https://github.com/Greg-R/explore_digital_rf I want to do more experimenting using HF band signals. Unfortunately I am in a hostile RF environment. I've got my hands on a broadband loop antenna, so getting that mounting and working is next. I hope I can pursue further experiments with the combination of GNU Radio and Digital RF. Cool stuff! 73 Greg KF5N -- Please follow the HamSCI Community Participation Guidelines at http://hamsci.org/hamsci-community-participation-guidelines. --- You received this message because you are subscribed to the Google Groups "hamsci-swstation" group. To unsubscribe from this group and stop receiving emails from it, send an email to hamsci-swstation+unsubscr...@googlegroups.com. To post to this group, send email to hamsci-swstat...@googlegroups.com. Visit this group at https://groups.google.com/group/hamsci-swstation. To view this discussion on the web visit https://groups.google.com/d/msgid/hamsci-swstation/161a202e-b3fa-49dd-97aa-5d9fa86c4045%40googlegroups.com <https://groups.google.com/d/msgid/hamsci-swstation/161a202e-b3fa-49dd-97aa-5d9fa86c4045%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DVB-S2/X Block Party at GNU Radio Conference 2018
"Enthusiastic Yes" on RFNoC. Our assumption is that we will need RFNoC. I think we could certainly use some advice on workflow. The LDPC FEC decode effort right now includes attempts with Xilinx SDSoC to convert functions from the GPU codebase into hardware accelerated FPGA code. From there, package for RFNoC. This plan has advantages and disadvantages. We're here to learn and contribute whatever we can. We have several SDSoC licenses and several full Vivado licenses. We have at least one X310, several B210s, and a variety of other FPGA dev boards (Snickerdoodls, Ultra96, etc). We have plenty of Plutos and some LimeSDRs. -Michelle W5NYV On Wed, Jun 20, 2018 at 3:42 PM, Dan CaJacob wrote: > I'd suggest incorporating RFNOC at least as an option. I suspect actual > use of DVBS2X might be rather boring if you're stuck on a processor. > > On Wed, Jun 20, 2018 at 4:38 PM Michelle Thompson < > mountain.miche...@gmail.com> wrote: > >> Hello everyone, >> >> GNU Radio Conference is coming up in September. If you haven't registered >> and want to go, please do at https://www.gnuradio.org/grcon-2018/ >> >> There's a special event this year called Block Party. >> >> It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio. >> >> We will have our own room and tables and swag. We will have docents >> enthusiasm and test equipment. We're looking for more! We'll have >> documentation and refreshments. >> >> We need blocks! >> >> Most blocks needed for DVB-S2/X receive do, in some form, already exist. >> Some do not. Some just need additional modulation and codings added to >> them. >> >> Receiver design is hard, but breaking it up into small blocks makes it >> tractable. >> >> The DVB protocol documents are all open. There are implementation >> guidelines. See https://www.dvb.org/ >> >> There are several community members that are experts in this area. There >> is a team (Phase 4 Ground - find out more at https://phase4ground.github. >> io/) that needs DVB-S2/X to work in GNU Radio. There is a lot of >> interest from a variety of other groups including Libre Space, ARRL, AMSAT, >> and TAPR. >> >> If you are able to contribute to this effort, I want to know about it! I >> am here to support it. I'd like nothing better than to complete the Block >> Party at GNU Radio Conference with working, tested, documented blocks for a >> DVB-S2/X receiver. This contribution makes our open source terrestrial and >> space radio designs for Phase 4 Ground possible, and also opens up a lot of >> other work. >> >> The thing that is considered the hardest part is the LDPC FEC decode. We >> have an open source implementation that targets GPUs. We want to take this >> and get it into RFNoC. If you are working on this as well, we want to >> collaborate and support and combine and promote. >> >> The GPU implementation (by Charles Brain G4GUO) of LDPC decode can be >> found at our repository folder here: https://github.com/ >> phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx >> >> Phase 4 Ground is devoted to an open source implementation of DVB-S2 and >> DVB-S2X for amateur radio terrestrial and space use. We are part of Open >> Research Institute. Learn more about this non-profit here: >> https://openresearch.institute/ >> >> -Michelle W5NYV >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > -- > Very Respectfully, > > Dan CaJacob > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DVB-S2/X Block Party at GNU Radio Conference 2018
Hello everyone, GNU Radio Conference is coming up in September. If you haven't registered and want to go, please do at https://www.gnuradio.org/grcon-2018/ There's a special event this year called Block Party. It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio. We will have our own room and tables and swag. We will have docents enthusiasm and test equipment. We're looking for more! We'll have documentation and refreshments. We need blocks! Most blocks needed for DVB-S2/X receive do, in some form, already exist. Some do not. Some just need additional modulation and codings added to them. Receiver design is hard, but breaking it up into small blocks makes it tractable. The DVB protocol documents are all open. There are implementation guidelines. See https://www.dvb.org/ There are several community members that are experts in this area. There is a team (Phase 4 Ground - find out more at https://phase4ground.github.io/) that needs DVB-S2/X to work in GNU Radio. There is a lot of interest from a variety of other groups including Libre Space, ARRL, AMSAT, and TAPR. If you are able to contribute to this effort, I want to know about it! I am here to support it. I'd like nothing better than to complete the Block Party at GNU Radio Conference with working, tested, documented blocks for a DVB-S2/X receiver. This contribution makes our open source terrestrial and space radio designs for Phase 4 Ground possible, and also opens up a lot of other work. The thing that is considered the hardest part is the LDPC FEC decode. We have an open source implementation that targets GPUs. We want to take this and get it into RFNoC. If you are working on this as well, we want to collaborate and support and combine and promote. The GPU implementation (by Charles Brain G4GUO) of LDPC decode can be found at our repository folder here: https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx Phase 4 Ground is devoted to an open source implementation of DVB-S2 and DVB-S2X for amateur radio terrestrial and space use. We are part of Open Research Institute. Learn more about this non-profit here: https://openresearch.institute/ -Michelle W5NYV ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RTP block / Opus vocoder
Hi Albin, We have a similar interest in getting RTP functionality in GNU Radio. Phil Karn recently wrote and published an SDR package for Phase 4 Ground that includes RTP multicast functionality. We have been talking about getting this functionality into GNU Radio. Another person interested in seeing this happen is David Rowetel from FreeDV. He and Phil have started talking about this. Ron and Marcus are of course correct in that RTP streams are already handled pretty well in GNU Radio. No, we do not want to reinvent the wheel. We would like to combine Opus/CODEC2 and RTP multicast to have stereo field audio. The sources of the audio appear at different points in the stereo field, so that a roundtable conversation feels more like a roundtable, or so that two streams from two different SDRs are distinct. Everyone is welcome to comment and contribute. The repository with the RTP multicast code from Phil Karn is here: https://github.com/phase4ground/ka9q-sdr If it can be done without a new block, then great. If there is value in handling bookkeeping, or functions in RTP multicast that would be much easier or much more useful in flowgraphs with a new block, then that's what we want to do. I have advice that it would be useful to get it into blocks. We want to do the right thing and we want comment and critique. Phase 4 Ground will have a "block party" at GNU Radio Conference 2018. The overall goal of Phase 4 Ground is to get DVB-S2 and DVB-S2X receive in GNU Radio. We have a dedicated room/lab for the week of the conference and will bring as much test equipment as we can fit into a minivan. Several satellite/modem/DVB docents have signed up and we're working on swag! If you have interest or expertise in any area of DVB-S2 receiver design, then we enthusiastically welcome you. We have a Slack and a mailing list. https://lists.openresearch.institute/ One of the hard parts of the receiver is the LDPC FEC decode. We have one working implementation from Charles Brain, written for a GPU. It needs some work to get adaptive coding and modulation (we want ACM) working due to the architectural choices. It's a big achievement and it puts success more within reach. There are other hard parts in this receiver, but LDPC is challenging work. Having an open source version is a big step forward. Aside from ACM, we want to use generic stream encapsulation or GSE, which replaces the MPEG transport layer with a protocol that supports, well, you guessed it, generic data. This makes the downlink much more useful as a multiple access amateur radio system, which is where we're trying to go with all this work. Several of us have contributed GSE work that can be found in Wireshark and in GNU Radio, so working with GSE streams can be easier. -Michelle W5NYV "Potestatem obscuri lateris nescis." On Wed, May 9, 2018 at 9:54 AM, Albin Stigö wrote: > I'm looking specifically to improve the audio streaming of the GQRX > program which is based on gnuradio so it needs to be a block. I'll > experiment and see if I can come up with something useful. > > Thanks for all the suggestions though! > > > Albin > > > On Wed, May 9, 2018, 18:30 Müller, Marcus (CEL) wrote: > >> Well, I think you and Ron basically recommend the same functionality, >> but Ron is hesitant to reinvent the wheel: >> >> For local transport, UDP between your flowgraph and VLC works just >> fine. Also fine would be simply using a named pipe (FIFO, as in `man >> mkfifo`, if you're on something vaguely resembling UNIX) and a simple >> file sink (or source). >> >> Then, use VLC to receive those UDP packets containing raw samples, and >> encode them with Opus, and encapsulate them with RTP. (In the opposite >> direction, use VLC to receive an RTP stream, decompress the audio to >> raw audio samples, and send them via UDP to your flow graph) >> >> That would alleviate the need to have all this in a block, and test it >> yourself. >> >> Best regards, >> Marcus >> >> On Wed, 2018-05-09 at 12:30 +0200, Albin Stigö wrote: >> > > RTP is encapsulated in UDP. If you send an RTP stream to the GNU >> Radio UDP block, you will get an RTP stream. >> > >> > Exactly. But do you know if there already is a project to handle RTP >> bookkeeping..? Otherwise I will start one. RTP is very application specific >> but I'm looking to implement raw audio and opus. I'll try to make it >> modular so that others can be built on top. >> > >> > --Albin >> > >> > >> > On Wed, May 9, 2018, 10:38 Ron Economos wrote: >> > > RTP is encapsulated in UDP. If you send an RTP stream to the GNU >> Radio >> > > UDP block, you will get an RTP stream. >> >
