Re: RTL-SDR v3 dongle support
Just a comment that I've had a lot of difficulty contributing to the osmocom rtlsdr driver. I've had multiple patches that addressed instabilities go unresponded to on their mailing list. After some years they said they had a new maintainer but that it was my responsibility to find my patches and send them to the new maintainer. It would be nice if there were a driver with a gentler barrier to contribution, speaking as somebody who has difficulty interacting with both computers and human beings. On Fri, Mar 26, 2021, 1:16 PM geraldfenkell wrote: > 2021-03-26 > > Thank you Jeff. > > 1. I did not realize that I was replying off the list. This time I did a > reply all and I hope that should fix the > location to the list. > > 2. I greatly appreciate your response and believe that I made a mistake in > saying version 3.8.2 of > gnuradio. It is the automatic version that I installed using apt-get > on Ubuntu 20.04. Probably > 3..8.1.? and I think the ? represents a further refinement. I do not > know for sure. (I know not > that of which I speak) > > 3. I never knew that gr-osmosdr and rtl-sdr were installed automatically > with apt-get. I do have a > hackrf radio and I will at some point pursue gr-osmosdr using gnu > radio as well as rtl-sdr. > > *I truly appreciate your guidance and thank you for that.* > > *regards* > > *Jerry (VE3OBX)* > > > > > [Please keep discussion on the mailing list] > > The rtl-sdr package does not depend on the version of gnuradio. > > Ubuntu 20.04 currently packages gnuradio 3.8.1. Installing that brings in > gr-osmosdr and rtl-sdr automatically when you use > apt install gnuradio > > If you have gnuradio 3.8.2, then the answer depends on how you installed > it. > > There is more information on GNU Radio installation here: > https://wiki.gnuradio.org/index.php/InstallingGR > > On Fri, Mar 26, 2021 at 11:45 AM geraldfenkell < > geraldfenk...@computechnics.ca> wrote: > >> 2021-03-26 >> >> 1. Is there a version of gr-osmosdr and rtl-sdr available for gnuradio >> version 3.8.2 that comes as a package >>that could be loaded to 3.8.2 using a form of sudo apt-get? >> >> 2. If such is available could you kindly provide the exact "sudo apt-get >> " that would load it. >> >> 3. Would the point 2. above automatically bring in any required drivers >> for Ubuntu 20.04? >> >> 4. If the answer to 3. is no could you kindly provide any required >> details on obtaining and loading the >> drivers. >> >> Thank you in advance. >> >> Jerry >> >> -- >> >> >> >> >> gr-osmosdr and rtl-sr dare used by GNU Radio, but they are maintained by >> the Osmocom project. Distributions may call something 0.6.0 but actually >> use the latest code. Some RTLs, like the Smart Tee have the bias tee turned >> on permanently. There is also a rtl_biast application that comes with >> recent rtl-sdr versions. >> >> On Fri, Mar 26, 2021 at 9:19 AM Wojciech Kazubski >> wrote: >> >>> Hello >>> Now improved RTL-SDR dongles are widely available, according to sellers' >>> notice they support bias tee and direct conversion. So far rtl-sdr >>> driver has >>> support for bias tee for some time, but the last tag 0.6.0 is quite old >>> and >>> does not have this. >>> Some distributions tend to stick to releases/tags of packages, so they >>> still >>> have rtl-sdr-0.6.0 without bias tee support. >>> >>> Is there a chance to have new tag of rtl-sdr (if the bias tee support is >>> finished)? >>> >>> -- >>> Wojciech >>> >>> >>> >> >>
Re: RTL-SDR v3 dongle support
On Fri, Mar 26, 2021, 2:08 PM Jeff Long wrote: > This is true. GNU Radio is looking at directly supporting gr-iio (PLUTO) > and gr-soapy (drivers available for a number of SDRs) in the future to give > users more choices. We will still be dependent on outside projects/vendors > to maintain the drivers, though. GNU Radio (this list) is a user of rtl-sdr > and gr-osmosdr, but does not maintain those packages or any other drivers. > Thanks for your reply. It sounds like this is maybe off-topic, but so you are aware the soapy sdr driver depends on the same osmocom library that the the osmocom gnuradio blocks do. There is only one rtl-sdr driver that I am aware of, but hopefully the maintenance situation has improved since the years of having diverse forks referenced on blogs and youtube videos, each supporting a different set of features. > On Fri, Mar 26, 2021 at 1:47 PM Karl wrote: > >> Just a comment that I've had a lot of difficulty contributing to the >> osmocom rtlsdr driver. I've had multiple patches that addressed >> instabilities go unresponded to on their mailing list. After some years >> they said they had a new maintainer but that it was my responsibility to >> find my patches and send them to the new maintainer. It would be nice if >> there were a driver with a gentler barrier to contribution, speaking as >> somebody who has difficulty interacting with both computers and human >> beings. >> >> On Fri, Mar 26, 2021, 1:16 PM geraldfenkell < >> geraldfenk...@computechnics.ca> wrote: >> >>> 2021-03-26 >>> >>> Thank you Jeff. >>> >>> 1. I did not realize that I was replying off the list. This time I did >>> a reply all and I hope that should fix the >>> location to the list. >>> >>> 2. I greatly appreciate your response and believe that I made a mistake >>> in saying version 3.8.2 of >>> gnuradio. It is the automatic version that I installed using >>> apt-get on Ubuntu 20.04. Probably >>> 3..8.1.? and I think the ? represents a further refinement. I do >>> not know for sure. (I know not >>> that of which I speak) >>> >>> 3. I never knew that gr-osmosdr and rtl-sdr were installed >>> automatically with apt-get. I do have a >>> hackrf radio and I will at some point pursue gr-osmosdr using gnu >>> radio as well as rtl-sdr. >>> >>> *I truly appreciate your guidance and thank you for that.* >>> >>> *regards* >>> >>> *Jerry (VE3OBX)* >>> >>> >>> >>> >>> [Please keep discussion on the mailing list] >>> >>> The rtl-sdr package does not depend on the version of gnuradio. >>> >>> Ubuntu 20.04 currently packages gnuradio 3.8.1. Installing that brings >>> in gr-osmosdr and rtl-sdr automatically when you use >>> apt install gnuradio >>> >>> If you have gnuradio 3.8.2, then the answer depends on how you installed >>> it. >>> >>> There is more information on GNU Radio installation here: >>> https://wiki.gnuradio.org/index.php/InstallingGR >>> >>> On Fri, Mar 26, 2021 at 11:45 AM geraldfenkell < >>> geraldfenk...@computechnics.ca> wrote: >>> >>>> 2021-03-26 >>>> >>>> 1. Is there a version of gr-osmosdr and rtl-sdr available for gnuradio >>>> version 3.8.2 that comes as a package >>>>that could be loaded to 3.8.2 using a form of sudo apt-get? >>>> >>>> 2. If such is available could you kindly provide the exact "sudo >>>> apt-get " that would load it. >>>> >>>> 3. Would the point 2. above automatically bring in any required drivers >>>> for Ubuntu 20.04? >>>> >>>> 4. If the answer to 3. is no could you kindly provide any required >>>> details on obtaining and loading the >>>> drivers. >>>> >>>> Thank you in advance. >>>> >>>> Jerry >>>> >>>> -- >>>> >>>> >>>> >>>> >>>> gr-osmosdr and rtl-sr dare used by GNU Radio, but they are maintained >>>> by the Osmocom project. Distributions may call something 0.6.0 but actually >>>> use the latest code. Some RTLs, like the Smart Tee have the bias tee turned >>>> on permanently. There is also a rtl_biast application that comes with >>>> recent rtl-sdr versions. >>>> >>>> On Fri, Mar 26, 2021 at 9:19 AM Wojciech Kazubski >>>> wrote: >>>> >>>>> Hello >>>>> Now improved RTL-SDR dongles are widely available, according to >>>>> sellers' >>>>> notice they support bias tee and direct conversion. So far rtl-sdr >>>>> driver has >>>>> support for bias tee for some time, but the last tag 0.6.0 is quite >>>>> old and >>>>> does not have this. >>>>> Some distributions tend to stick to releases/tags of packages, so they >>>>> still >>>>> have rtl-sdr-0.6.0 without bias tee support. >>>>> >>>>> Is there a chance to have new tag of rtl-sdr (if the bias tee support >>>>> is >>>>> finished)? >>>>> >>>>> -- >>>>> Wojciech >>>>> >>>>> >>>>> >>>> >>>>
Re: Transport stream source
On Sat, Apr 3, 2021, 3:48 PM Ralf Gorholt wrote: > Dear all, > > instead of using a file source, I would like to get data from a video > stream into GNU Radio. Is this possible? > > With VLC, I can connect to the stream using a URL like > udp://230.0.0.10:1234. How can I do this in GNU Radio? I have tried to > use a UDP source with this address and payload size 1316 (needed for VLC > when it connects to a UDP sink in GNU Radio) and to pass the data to a > UDP sink at address 230.0.0.20:1 and payload size 1316 to which I > can connect with VLC to see if it works but when I start the flow graph, > nothing seems to come out, VLC tries in vain to connect. > Hi list, I'm a sometimes-lurker. I noticed there weren't a lot of options mentioned in replies yet, here's another: You could narrow this issue down by using a packet logger such as ethereum or tcpdump to verify that correct udp traffic is being generated. If it is, then it may be a bug in gnuradio.
Updating in-tree block documentation
Hi,
I am just learning gnuradio and I find it takes a lot of time to look
up the blocks on the wiki.
The attached python script, if run in the gnuradio source tree root,
will update all the blocks' local documentation from the wiki.
It uses requests, pyyaml, and mwparserfromhell.
It makes a _lot_ of updates. A patch updating them all would be pretty large.
Here is an example:
--- a/gr-blocks/grc/blocks_add_const_vxx.block.yml
+++ b/gr-blocks/grc/blocks_add_const_vxx.block.yml
@@ -49,4 +49,14 @@ cpp_templates:
callbacks:
- set_k(${const})
+documentation: |-
+Category:Block Docs
+Adds a constant value to each item that passes though. output[m]
= input[m] + constant vector.
+
+Parameters
+(R): Run-time adjustable
+
+Constant (R)
+The entered value must be of the same type as the input / output
ports (i.e. complex, float, etc.).
+
#!/usr/bin/env python3
import requests
import mwparserfromhell
import yaml
import os
import sys
def update_files(*filenames):
blocklabels = {
yaml.safe_load(open(filename))['label']: filename
for filename in filenames
}
pages = requests.get(
'https://wiki.gnuradio.org/api.php',
params={
'action': 'query',
'format': 'json',
'prop': 'revisions',
'rvprop': 'content',
'titles': '|'.join((blocklabel.replace(' ', '_') for blocklabel in blocklabels))
}
).json()
pages = {
page['title']: page['revisions'][0]['*']
for page in pages['query']['pages'].values()
if 'revisions' in page
}
for blocklabel, filename in blocklabels.items():
if blocklabel not in pages:
print('Not found on wiki:', blocklabel)
continue
print(filename, blocklabel)
page = pages[blocklabel]
page = mwparserfromhell.parse(page)
sections = page.get_sections(matches='Parameters', include_lead=True)
sections = (section.strip_code() for section in sections)
doc = '\n\n'.join(sections)
block_lines = [*open(filename)]
replaced_doc = False
old_doc_start = -1 if block_lines[-1].rstrip() == 'file_format: 1' else len(block_lines)
for index, line in enumerate(block_lines):
if line.startswith('documentation:'):
old_doc_start = index
break
old_doc_end = old_doc_start
for index, line in enumerate(block_lines[old_doc_start:]):
if not line.startswith('') and line.strip() and not line.startswith('documentation'):
old_doc_end = index + old_doc_start
break
doc_lines = ['documentation: |-\n', *['' + line.strip() + '\n' for line in doc.split('\n')], '\n']
block_lines[old_doc_start:old_doc_end] = doc_lines
open(filename, 'w').write(''.join(block_lines))
if __name__ == '__main__':
if sys.argv[1:]:
update_files(*sys.argv[1:])
else:
files = []
for root, dirs, files in os.walk("."):
files = [os.path.join(root, file) for file in files if file.endswith('.block.yml')]
if files:
update_files(*files)
Re: Adding uhd-style tags, to soapy driver?
hi josh,
i'm not a maintainer, but I wanted to comment that i've been looking for
features like this for years and the contribution is welcome to see. most
open source projects accept work if it's presented in the ways they're used
to.
i've also found the developer of soapy to be relatively responsive and
inclusive on github.
On Mon, Oct 18, 2021, 6:42 PM Bailey, Josh wrote:
> Hi all,
>
> The gr-uhd driver, tags samples when center frequency changes and some
> other events):
>
>
> https://github.com/gnuradio/gnuradio/blob/8b23f906844c9784c784934ae06dfdfe10d31a1f/gr-uhd/lib/usrp_source_impl.cc#L619
>
> I've been able to make a minimal patch to the soapy driver (see
> following), that does the same thing for all other SDRs supported by soapy
> (the patch is for proof of concept/illustrative purposes only - I
> appreciate that it isn't compatible with the contribution guidelines).
>
> My question - would a suitable patch that provides these tags, be
> acceptable to the maintainers? I can appreciate that it's possible that
> there are flow graphs that just happen to use these same tags perhaps for
> other purposes - perhaps I could then add a flag to make them optional? In
> any case, the gr-uhd driver appears to always send them, already.
>
> Thanks,
>
> diff --git a/gr-soapy/lib/block_impl.h b/gr-soapy/lib/block_impl.h
> index a1e95fdd0..74b2beffe 100644
> --- a/gr-soapy/lib/block_impl.h
> +++ b/gr-soapy/lib/block_impl.h
> @@ -90,6 +90,7 @@ protected:
> public:
> bool start() override;
> bool stop() override;
> +bool _tag_now;
>
> /*** Begin public API implementation ***/
>
> diff --git a/gr-soapy/lib/source_impl.cc b/gr-soapy/lib/source_impl.cc
> index f76d4437f..93aa06bb2 100644
> --- a/gr-soapy/lib/source_impl.cc
> +++ b/gr-soapy/lib/source_impl.cc
> @@ -47,6 +47,10 @@ source_impl::source_impl(const std::string& device,
> {
> }
>
> +static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time");
> +static const pmt::pmt_t FREQ_KEY = pmt::string_to_symbol("rx_freq");
> +static const pmt::pmt_t RATE_KEY = pmt::string_to_symbol("rx_rate");
> +
> int source_impl::general_work(int noutput_items,
>__GR_ATTR_UNUSED gr_vector_int&
> ninput_items,
>__GR_ATTR_UNUSED gr_vector_const_void_star&
> input_items,
> @@ -57,6 +61,11 @@ int source_impl::general_work(int noutput_items,
> const long timeout_us = 50; // 0.5 sec
> int nout = 0;
>
> +std::stringstream str;
> +str << name() << unique_id();
> +pmt::pmt_t _id = pmt::string_to_symbol(str.str());
> +std::time_t time_now = std::time(nullptr);
> +
> for (;;) {
>
> // No command handlers while reading
> @@ -66,6 +75,25 @@ int source_impl::general_work(int noutput_items,
> result = d_device->readStream(
> d_stream, output_items.data(), noutput_items, flags,
> time_ns, timeout_us);
> }
> +if (_tag_now) {
> +_tag_now = false;
> +// create a timestamp pmt for the first sample
> +// TODO: use timestamp from radio hardware, and < 1s
> granularity?
> +const pmt::pmt_t val =
> +pmt::make_tuple(pmt::from_uint64(time_now),
> +pmt::from_double(0));
> +// create a tag set for each channel
> +for (size_t i = 0; i < 1; i++) { // TODO: get actual number
> of channels.
> +this->add_item_tag(i, nitems_written(0), TIME_KEY, val,
> _id);
> +this->add_item_tag(
> +i, nitems_written(0), RATE_KEY,
> pmt::from_double(this->get_sample_rate(i)), _id);
> +this->add_item_tag(i,
> + nitems_written(0),
> + FREQ_KEY,
> +
> pmt::from_double(this->get_frequency(i)),
> + _id);
> +}
> +}
>
> if (result >= 0) {
> nout = result;
>
>
>
Wikis for Learning Radio Communication and Signal Processing
Hi list, I just subscribed, I'm very interested in SDR but don't have very much relevant academic training. I was wondering if anybody knew of a place for people to exchange their learning on things like this, similar to wikipedia or wikiversity, but with an eye towards sdr: or any major wikipedia/wikiversity topics that would be good places to add to as one learned. I found https://wiki.gnuradio.org/index.php/SuggestedReading which mostly seems to link to static articles, not things the community can contribute to. And I'm noting there are other SDR frameworks than gnuradio. I'm kind of imagining that if there were a place for people to contribute information to in an organized manner, the difficult learning curve towards understanding radio communications could be eventually made a lot tighter for the goals that people enter with. k
Re: [Discuss-gnuradio] How can i determine my current phone's frequency?
Probably the best way to do this is to get your phone to either tell you the ARFCN it's on (and not many do), or the cell ID. If you get a cell ID, you'd need to scan the downlink frequencies for that particular cell ID. Once you find the downlink frequency, the uplink should be a constant offset away. On Thu, Dec 17, 2015 at 1:06 PM, Meny Sidar wrote: > Hi guys, > I want to know which frequency my cellular phone is using (for uplink - > UMTS). > I'm using USRP B210, i tried the spectrum analyzer tool but i don't really > know what to expect- isn't the transmitting power of my cellular supposed > to be higher (in a single frequency) than all other frequencies? > my goal is to try and see if i can notice a change in dB when i get my > phone closer/further to the B210. > > Thanks a lot, > Meny > > ___ > 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] detecting covert RFID scans
There are also far-field RFID systems, such as the EPC Gen2 standard that was intended to replace product barcodes but has found itself in other applications such as toll road tags and DHS-compliant IDs. One potential problem with trying to detect these systems with GNU Radio is that the tags themselves will operate over a wide frequency range (e.g. the entire 900 MHz ISM band), so the readers will hop around the band for FCC compliance. On Sun, Dec 27, 2015 at 10:03 AM, Marcus Müller wrote: > The problem is that technically, the energy sent out by an RFID reader > isn't big enough to detect readers from afar; they are near-field > devices, as opposed to the typical far-field antenna based radio > transmitters. > > Cheers, > Marcus > > On 12/27/2015 06:01 PM, Daniel Pocock wrote: > > > > I did a search for RFID on the wiki and it didn't find anything > > > > > http://gnuradio.org/redmine/projects/gnuradio/search?utf8=%E2%9C%93&wiki_pages=1&q=rfid > > > > Looking through the mailing list history there have been some > > discussions though, e.g. > > > > > https://lists.gnu.org/archive/html/discuss-gnuradio/2006-10/msg00296.html > > > > One interesting GNU Radio use case that comes to mind is to build some > > kind of device that can sniff covert attempts to scan RFID cards. It > > would be interesting to carry the device around shopping malls and > > railway stations and discover the locations of all the hidden scanners > > that are tracking people these days. > > > > Regards, > > > > Daniel > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to handle sources with variable bitrate
Hi all, i want to transmitt a video stream with gnuradio and usrps. There are some examples on the web and i got it working with vlc. The problem is, that the playback is quite choppey. This is because the digital transmission over the usrps has a fixed rate but the encoded video has a variable rate. If i set the transmission rate higher than the (mean) rate of the video, i get a lot of underruns on the tranmitting usrp (= chopped of rf signal). Which is bad because the transmission designed to be continous (for example the clockloop, ...). The transmission is based on fixed size fec code blocks starting with an preambel. A possible solution could be to stuff zeros between two blocks while waiting on the (video) source. On the receiver this stuffed zeros would be trown away automatically. That "zero stuffing" could be realized with a block, that puts out N (N= payload size of one block) input samples (first sample marked with a tag) at one "piece" or (if it has no N input samples in some internal buffer) it puts out zeros). Based on the tag a downstream block could mux in the preambel and everything would be fine. But here is my question: I don´t know how to write a block, that always has output samples available. Is there i kind of a non-blocking block template? Best regards, *Anselm* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to handle sources with variable bitrate
Thank you. I will look at it! Am 17.03.2016 19:03 schrieb "Francisco Albani" : > Hi Anselm. > > Go to http://lists.gnu.org/archive/html/discuss-gnuradio/ and search this > "Asynchronous source with zeros in between" > > You will find an email I wrote to this list asking a similar question. I'm > not pasting a link here because I couldn't find the starting message; the > thread is split in many parts (I don't know why). I hope you should be able > to find all the pieces in the search results. If not, please write to me > and I will find a way of send it to you. > > I think my problem was different that yours and my solution will not be > fit, but it may give you some ideas. The key was to bring the payload in a > PDU message and to have a block that manages the "padding" before entering > to the "stream domain". > > Bye! > > > 2016-03-17 5:50 GMT-03:00 Anselm Karl : > >> Hi, Nikos, >> >> adding a buffer / fifo and matching the mean video rate to the rate of my >> transmission system should work. >> >> But i don't really want to match the rates, because i'll have to do that >> every time i change something on the source. It can be quite an effort, >> too. (Like interpolation the base-band signal) Or consider a asynchronous >> source (something like a serial terminal) with large intervals with no data. >> >> With the "zero stuffing solution" you just have to make sure, that the >> transmission is fast enough for the source, "plug in" the source and >> everything should be fine. >> >> I've done some gnu radio blocks. But i don't now how to tell the work >> function how many samples the down stream block needs. In my understanding >> the work functions gets some input samples and calculates some output >> samples out of them. It's like the block gets actively written to and >> passively read from. And i would need it the other way. >> >> BR, >> Anselm >> >> >> >> 2016-03-17 9:17 GMT+01:00 Nikos Balkanas : >> >>> Hi, >>> >>> Have you tried using a FIFO block in your flow? There a few around and >>> it seems to me it would normalize your flow. >>> >>> BR, >>> Nikos >>> >>> On Thu, Mar 17, 2016 at 10:01 AM, Anselm Karl < >>> anselmkarl.in...@googlemail.com> wrote: >>> >>>> Hi all, >>>> >>>> i want to transmitt a video stream with gnuradio and usrps. There are >>>> some examples on the web and i got it working with vlc. >>>> >>>> The problem is, that the playback is quite choppey. This is because the >>>> digital transmission over the usrps has a fixed rate but the encoded video >>>> has a variable rate. If i set the transmission rate higher than the (mean) >>>> rate of the video, i get a lot of underruns on the tranmitting usrp (= >>>> chopped of rf signal). Which is bad because the transmission designed to be >>>> continous (for example the clockloop, ...). >>>> >>>> The transmission is based on fixed size fec code blocks starting with >>>> an preambel. A possible solution could be to stuff zeros between two blocks >>>> while waiting on the (video) source. On the receiver this stuffed zeros >>>> would be trown away automatically. >>>> >>>> That "zero stuffing" could be realized with a block, that puts out N >>>> (N= payload size of one block) input samples (first sample marked with a >>>> tag) at one "piece" or (if it has no N input samples in some internal >>>> buffer) it puts out zeros). Based on the tag a downstream block could mux >>>> in the preambel and everything would be fine. >>>> >>>> But here is my question: >>>> I don´t know how to write a block, that always has output samples >>>> available. Is there i kind of a non-blocking block template? >>>> >>>> >>>> Best regards, >>>> >>>> *Anselm* >>>> >>>> >>>> >>>> ___ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >> >> >> -- >> Mit freundlichen Grüßen >> >> *Anselm Karl* >> >> >> >> ___ >> 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] how to handle sources with variable bitrate
Hi, Nikos, adding a buffer / fifo and matching the mean video rate to the rate of my transmission system should work. But i don't really want to match the rates, because i'll have to do that every time i change something on the source. It can be quite an effort, too. (Like interpolation the base-band signal) Or consider a asynchronous source (something like a serial terminal) with large intervals with no data. With the "zero stuffing solution" you just have to make sure, that the transmission is fast enough for the source, "plug in" the source and everything should be fine. I've done some gnu radio blocks. But i don't now how to tell the work function how many samples the down stream block needs. In my understanding the work functions gets some input samples and calculates some output samples out of them. It's like the block gets actively written to and passively read from. And i would need it the other way. BR, Anselm 2016-03-17 9:17 GMT+01:00 Nikos Balkanas : > Hi, > > Have you tried using a FIFO block in your flow? There a few around and it > seems to me it would normalize your flow. > > BR, > Nikos > > On Thu, Mar 17, 2016 at 10:01 AM, Anselm Karl < > anselmkarl.in...@googlemail.com> wrote: > >> Hi all, >> >> i want to transmitt a video stream with gnuradio and usrps. There are >> some examples on the web and i got it working with vlc. >> >> The problem is, that the playback is quite choppey. This is because the >> digital transmission over the usrps has a fixed rate but the encoded video >> has a variable rate. If i set the transmission rate higher than the (mean) >> rate of the video, i get a lot of underruns on the tranmitting usrp (= >> chopped of rf signal). Which is bad because the transmission designed to be >> continous (for example the clockloop, ...). >> >> The transmission is based on fixed size fec code blocks starting with an >> preambel. A possible solution could be to stuff zeros between two blocks >> while waiting on the (video) source. On the receiver this stuffed zeros >> would be trown away automatically. >> >> That "zero stuffing" could be realized with a block, that puts out N (N= >> payload size of one block) input samples (first sample marked with a tag) >> at one "piece" or (if it has no N input samples in some internal buffer) it >> puts out zeros). Based on the tag a downstream block could mux in the >> preambel and everything would be fine. >> >> But here is my question: >> I don´t know how to write a block, that always has output samples >> available. Is there i kind of a non-blocking block template? >> >> >> Best regards, >> >> *Anselm* >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Mit freundlichen Grüßen *Anselm Karl* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Please solve this problem
The volk issue is old: https://gnuradio.org/redmine/issues/722 On Sun, Mar 27, 2016 at 6:21 PM, Alexander Levedahl < alexanderleved...@gmail.com> wrote: > Two questions: > 1) Have you been able to run any that do not require a GUI? There error > appears to be related to a GUI. > 2) What happens when you run volk_profile? There is a warning or error > associated with VOLK. > > VOLK is a component of GnuRadio that speeds up math computations by using > the processors SIMD instructions. > > Also, for the title of a help request, it would be nice if it contained > some information. > > On Sun, Mar 27, 2016 at 7:41 PM, Geof Nieboer > wrote: > >> Ankit, >> >> First off, how did you install GNURadio on windows? What method did you >> use? >> >> Second, can we see the actual GRC before you ran it so we can see what >> you trying to do? Please post a screenshot and the actual .grc file. >> >> Finally, what examples you been able to run already? Is this the first >> block you have ever run? >> >> There are many helpful people here, but we will need some more >> information about what things you have tried to accomplish to get it >> working if they are to be of useful assistance. >> >> Geof >> >> >> On Mon, Mar 28, 2016 at 12:44 AM, Ankit Saharia >> wrote: >> >>> I have installed gnuradio in windows 8.It was installed successfully. >>> After i have finished making the block and i clicked on the generate and >>> execute file button i get the problem attached below. >>> >>> It will be very kind of you if you can please solve my problem. >>> >>> Thankyou. >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK Demod block
I believe so; see gnuradio/gr-digital/python/digital/generic_mod_demod.py: ... # symbol timing recovery with RRC data filter taps = filter.firdes.root_raised_cosine(nfilts, nfilts*self._samples_per_symbol, 1.0, self._excess_bw, ntaps) self.time_recov = digital.pfb_clock_sync_ccf(self._samples_per_symbol, self._timing_bw, taps, nfilts, nfilts//2, self._timing_max_dev) ... On Fri, Oct 31, 2014 at 3:16 PM, Daniel Batista wrote: > Hi, > do you know if the default PSK Demodulation block does any frecuency > correction or time recovery? > After running some tests, I have noticed that when I use a Channel Model > between PSK mod and PSK demod, I successfully decode my data even I have a > small frecuency offset or time offset (Epsilon)! > > > ___ > 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] Weird behavior of the correlate_and_sync block
I'm trying to use the correlate_and_sync block to get an initial timing estimate from a packet radio, but it doesn't seem to work at all. I decided to dig a bit deeper and try to figure out what it was doing. As it turns out, the sequence it correlates against seems to be completely wrong. Here's a simple test script to demonstrate the problem: #!/usr/bin/python from gnuradio import digital from gnuradio.filter import firdes from pylab import * preamble = [1,1,-1,-1] * 10 taps = firdes.root_raised_cosine(32, 32, 1, 0.35, 11*4*32) corr_and_sync = digital.correlate_and_sync_cc(preamble, taps, 8, 32) plot(corr_and_sync.symbols()) show() This produces a non-deterministic graph, but will often show wildly oscillating samples, with an amplitude as high as 1e31. Clearly something is amiss. When I extend the preamble to be 64 symbols long, everything seems to work. However, when I change the filter it uses, it breaks again. Any ideas what's going on? - Karl ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating short bursts of BPSK
If the packets have a preamble, there's a block called correlate_and_sync which should do what you want, although it has some issues. See a thread I started a few days ago about that... On Thu, Apr 2, 2015 at 3:36 PM, Mike Willis wrote: > I have an application that needs to decode short bursts of DBPSK data > (which I am not generating myself). The problem I am having is that > the standard PSK Demod blocks don't lock up in time to correctly > decode the first few flags in the packetised data, which means I > generally lose the first packet. Is there a solution to this - e.g. > once the demodulator has locked up, go back some time (samples) and > start again knowing the locked parameters? > > Mike > > ___ > 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] Work around for gr.multiply_cc( ) for non NEON enabled ARM devices
Has anyone developed a work around for replacing gr.multiple_cc() to work on ARM devices that have to disable NEON in order to install? I have two lines in gr.ais that keep giving me overflow. Thanks ahead of time, karl ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for non NEON enabled ARM devices
The Pi is having some problems running: sudo volk_profile It pegs out at 100% and I just cut it at 24 hours. I am going to reboot and run it on terminal only with it overclocked for the weekend, but do you have any other suggestions? I was really excited about Volk after reading up on it, but unfortunately it seems to be too much for the RPi. Thanks karl From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Thursday, February 14, 2013 10:42 AM To: Karl Petrow Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for non NEON enabled ARM devices On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow mailto:kpet...@maritimeinfosystems.com>> wrote: Has anyone developed a work around for replacing gr.multiple_cc() to work on ARM devices that have to disable NEON in order to install? I have two lines in gr.ais that keep giving me overflow. Thanks ahead of time, karl You can turn it off. Have you run 'volk_profile' on the system, yet? If so, that would have generated a ~/.volk/volk_config. You can edit that file by hand to specify the architecture you want as 'generic' for whatever kernel is causing you trouble. This just runs a standard C for loop with no SIMD instructions (except whatever the compiler tries to do). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] : gnuradio install script fails at
I am an extreme newb, but I had to install gr-osmocom and rtl_sdr separately following this recipe: http://sdr.osmocom.org/trac/wiki/rtl-sdr But as I said I have 1 week of GNURADIO under my belt so far. Karl Y Petrow Maritime Information Systems, Inc. http://www.maritimeinfosystems.com<http://www.maritimeinfosystems.com/> kpet...@maritimeinfosystems.com<mailto:kpet...@maritimeinfosystems.com> Tel: +1 401-247-7780 Cell: +1 901-570-0349 IM karl.pet...@yahoo.com<mailto:karl.pet...@yahoo.com> Skype karl.petrow [cid:image001.gif@01CE0B77.3B3584E0] <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for non NEON enabled ARM devices
I recompiled the program with commenting out all non-multiply kernels(see attached). Still pegged out for 2 hours and still going. Do you know specifically which kernel relates to the multiply_cc function? Thanks again, kyp From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: Friday, February 15, 2013 1:09 PM To: Karl Petrow Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for non NEON enabled ARM devices On Fri, Feb 15, 2013 at 12:21 PM, Karl Petrow mailto:kpet...@maritimeinfosystems.com>> wrote: The Pi is having some problems running: sudo volk_profile It pegs out at 100% and I just cut it at 24 hours. I am going to reboot and run it on terminal only with it overclocked for the weekend, but do you have any other suggestions? I was really excited about Volk after reading up on it, but unfortunately it seems to be too much for the RPi. Thanks karl You can edit volk/apps/volk_profile.cc and change the the number of samples and iterations it runs for each kernel. The function call is (from volk/lib/qa_utils.h): #define VOLK_PROFILE(func, tol, scalar, len, iter, results) So len and iter can be decreased for your processor's needs. Tom From: trond...@trondeau.com<mailto:trond...@trondeau.com> [mailto:trond...@trondeau.com<mailto:trond...@trondeau.com>] On Behalf Of Tom Rondeau Sent: Thursday, February 14, 2013 10:42 AM To: Karl Petrow Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for non NEON enabled ARM devices On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow mailto:kpet...@maritimeinfosystems.com>> wrote: Has anyone developed a work around for replacing gr.multiple_cc() to work on ARM devices that have to disable NEON in order to install? I have two lines in gr.ais that keep giving me overflow. Thanks ahead of time, karl You can turn it off. Have you run 'volk_profile' on the system, yet? If so, that would have generated a ~/.volk/volk_config. You can edit that file by hand to specify the architecture you want as 'generic' for whatever kernel is causing you trouble. This just runs a standard C for loop with no SIMD instructions (except whatever the compiler tries to do). Tom volk_profile.cc Description: volk_profile.cc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU on ARM
I got it working somewhat on a Raspberry using this recipe: http://k1gto.blogspot.com/2012/09/compiling-gnuradio-on-raspberry-pi-raspi.html I was trying to run gr.ais, but kept getting overflow with gr.multiply_cc(), due to having NEON disabled. Karl Y Petrow Maritime Information Systems, Inc. http://www.maritimeinfosystems.com<http://www.maritimeinfosystems.com/> kpet...@maritimeinfosystems.com<mailto:kpet...@maritimeinfosystems.com> Tel: +1 401-247-7780 Cell: +1 901-570-0349 IM karl.pet...@yahoo.com<mailto:karl.pet...@yahoo.com> Skype karl.petrow [cid:image001.gif@01CE2936.CB465500] <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GR-Radar, Passive Radar
Does anyone have a link to any recent progress made on this? I recently saw this lecture: http://diydrones.com/profiles/blogs/detect-airplaneuav-using and this project http://comsec.com/gnuradio-project-2006.html but nothing in the past 7 years?? Thanks Karl Y Petrow Maritime Information Systems, Inc. http://www.maritimeinfosystems.com<http://www.maritimeinfosystems.com/> kpet...@maritimeinfosystems.com<mailto:kpet...@maritimeinfosystems.com> Tel: +1 401-247-7780 Cell: +1 901-570-0349 IM karl.pet...@yahoo.com<mailto:karl.pet...@yahoo.com> Skype karl.petrow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR-Radar, Passive Radar
Could you just use Yagi's and send I/Q streams to a server? Maybe a time issue with TCP/IP lag. But you could possibly time stamp the I/Q data.. Additionally, I am interested in larger, slower marine vessels more than small, fast moving planes. What do you mean by Dynamic Range? I have briefly looked at the University of Washington setup where they are separated by mountains. I assume since they are observing such a far distance, the receiving stations are relatively not far apart(150km). Couldn't you network two stations like they do here and just use yagi's(one pointed directly toward the tower and one towards your area of interest?) They would need to be close since your observation field is at a much shorter distance. Why would you need to use only one USRP? I can send a I/Q stream with a Raspberry Pi and have all demodulation and processing done on the server side. Thanks for the help, Karl Petrow -Original Message- From: Johnathan Corgan [mailto:johnat...@corganlabs.com] Sent: Tuesday, March 26, 2013 9:53 AM To: Karl Petrow Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GR-Radar, Passive Radar On Mon, Mar 25, 2013 at 9:18 AM, Karl Petrow wrote: > Does anyone have a link to any recent progress made on this? I > recently saw this lecture: We've done work with some commercial customers researching low-power active radar with USRPs, but these were (customer) internal projects that did not get published externally. Regarding passive radar--it is very difficult with low-cost hardware such as the USRP to get the dynamic range needed to simultaneously receive the direct path from an emitter and the echoes from an airborne target. Some types of scene geometry would allow physical shielding to attenuate the direct path for a subset of the antenna array, which would help reduce the dynamic range necessary. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] : RTL-SDR: Failed to open rtlsdr device
You need to use this line: sudo make install-udev-rules look at this link: http://sdr.osmocom.org/trac/wiki/rtl-sdr Karl Y Petrow Maritime Information Systems, Inc. http://www.maritimeinfosystems.com<http://www.maritimeinfosystems.com/> kpet...@maritimeinfosystems.com<mailto:kpet...@maritimeinfosystems.com> Tel: +1 401-247-7780 Cell: +1 901-570-0349 IM karl.pet...@yahoo.com<mailto:karl.pet...@yahoo.com> Skype karl.petrow Message: 2 Date: Mon, 1 Apr 2013 21:57:41 +0530 From: Manu T S mailto:manu.t.s...@gmail.com>> To: GNURadio Discussion List mailto:discuss-gnuradio@gnu.org>> Subject: [Discuss-gnuradio] RTL-SDR: Failed to open rtlsdr device Message-ID: mailto:cacjh7qwryufhbczljx1k7cv0-fwfuhf57c2qggapkgszafx...@mail.gmail.com>> Content-Type: text/plain; charset="iso-8859-1" I have installed rtl-sdr driver in my machine. The tarball of the source I used is attached. The commands I used ( after cd-ying to the source directory ) are listed. [manu@iota rtl-sdr]$ cmake -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_UDEV_RULES=ON . [manu@iota rtl-sdr]$ make [manu@iota rtl-sdr]$ sudo make install [manu@iota rtl-sdr]$ sudo cp rtl-sdr.rules /etc/udev/rules.d/15-rtl-sdr.rules [manu@iota rtl-sdr]$ sudo chown root:root /etc/udev/rules.d/15-rtl-sdr.rules [manu@iota rtl-sdr]$ sudo udevadm control --reload-rules But when I run rtl_test I get the following message. [root@iota ~]# rtl_test Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle usb_claim_interface error -6 Failed to open rtlsdr device #0. I'm working on Arch linux x86_64, installed from Currnt Release (2013.03.01) I googled, but not much info is available on this*.* Has anyone come across such a situation? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Want to contribute as a open source.
Hi Anurag, It's a little unclear whether you mean _gnuradio_ or _gnu in general_. I'm not a part of gnuradio, but I'm trying out answering your question because I find it hard to understand and I worry busy people could ignore it. I quickly searched the gnuradio website to find answers. The contact information for gnuradio is at https://www.gnuradio.org/categories/contribute/ . There are chats on Matrix at #gnuradio:gnuradio.org and on IRC in #gnuradio on libera.chat . There's a lot of information at https://wiki.gnuradio.org/index.php/Development . The following issues are listed as good first issues for contribution: https://github.com/gnuradio/gnuradio/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 K >
Re: Discuss-gnuradio Digest, Vol 213, Issue 17
schrieb am Fr., 17. Juli 2020, 18:03: > Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > or, via email, send a message with subject or body 'help' to > discuss-gnuradio-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > >1. Project call today (Marcus Müller) >2. Re: Problem with Gnuradio convolution encoder/decoder! (rear1019) >3. Re: Project call today (Glen Langston) >4. Re: Problem with Gnuradio convolution encoder/decoder! > (George Edwards) >5. Re: Project call today (Marcus Müller) >6. gnuradio (+ friends) packages for conda on Linux, macOS, and > Windows (Ryan Volz) >7. Re: gnuradio (+ friends) packages for conda on Linux, macOS, > and Windows (Glen Langston) >8. Creating synchronized USRP source block (Marcin Wachowiak) >9. problem in making a project (Yasser Attarizi) > 10. Re: GPIO lines on RPi4 (jean-michel.fri...@femto-st.fr) > > > -- > > Message: 1 > Date: Thu, 16 Jul 2020 18:35:59 +0200 > From: Marcus Müller > To: GNURadio Discussion List > Subject: Project call today > Message-ID: <68eff59d-ab19-cda4-eac1-962a3c024...@kit.edu> > Content-Type: text/plain; charset="utf-8"; format=flowed > > Hi bestest SDR community, > > Heads up: the July project all is happening in 30 minutes. > > Cheers, > Marcus > > > > -- > > Message: 2 > Date: Thu, 16 Jul 2020 18:53:38 +0200 > From: rear1019 > To: discuss-gnuradio@gnu.org > Subject: Re: Problem with Gnuradio convolution encoder/decoder! > Message-ID: <20200716165338.GA1065@thewire.localdomain> > Content-Type: text/plain; charset=utf-8 > > On Thu, 16 Jul 2020 at 07:40:14 -0600, George Edwards wrote: > > […] > > I have also tried some of the other CC encoder/decoder blocks and they > > failed. > > > > I will appreciate any help or suggestions about the CCSDS 27 or the CC > > encoder/decoder in GNURadio. > > Which version of GNU Radio do you use? The convolutional decoder is > known to be broken in 3.8 [1][2]. > > [1] https://github.com/gnuradio/gnuradio/issues/2642 > [2] https://github.com/gnuradio/gnuradio/issues/3376 > > > > -- > > Message: 3 > Date: Thu, 16 Jul 2020 13:01:10 -0400 > From: Glen Langston > To: Marcus Müller > Cc: GNURadio Discussion List > Subject: Re: Project call today > Message-ID: <546a7e57-3ed4-4117-ba43-aad1bda3a...@gmail.com> > Content-Type: text/plain; charset=utf-8 > > Hi > > Could you remind us (ie me) of the link to the call? > > Thanks > > Glen > > > > On Jul 16, 2020, at 12:35 PM, Marcus Müller wrote: > > > > Hi bestest SDR community, > > > > Heads up: the July project all is happening in 30 minutes. > > > > Cheers, > > Marcus > > > > > > > -- > > Message: 4 > Date: Thu, 16 Jul 2020 11:59:31 -0600 > From: George Edwards > To: discuss-gnuradio@gnu.org > Subject: Re: Problem with Gnuradio convolution encoder/decoder! > Message-ID: > < > caan5zogexrtzngjzqfpxznuytbd6rckjdykovxzpv8wb+j7...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > Thanks for the response! I am using 3.8. However, I just found a pair which > work using the DVB-T Inner Coder and Viterbi Decoder. > > Regards, > George > > On Thu, Jul 16, 2020 at 10:54 AM rear1019 wrote: > > > On Thu, 16 Jul 2020 at 07:40:14 -0600, George Edwards wrote: > > > […] > > > I have also tried some of the other CC encoder/decoder blocks and they > > > failed. > > > > > > I will appreciate any help or suggestions about the CCSDS 27 or the CC > > > encoder/decoder in GNURadio. > > > > Which version of GNU Radio do you use? The convolutional decoder is > > known to be broken in 3.8 [1][2]. > > > > [1] https://github.com/gnuradio/gnuradio/issues/2642 > > [2] https://github.com/gnuradio/gnuradio/issues/3376 > > > > > -- next part -- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200716/45e0a36e/attachment.html > > > > -- > > Message: 5 > Date: Thu, 16 Jul 2020 20:34:58 +0200 > From: Marcus Müller > To: Glen Langston > Cc: GNURadio Discussion List > Subject: Re: Project call today > Message-ID: <81bb9d18-26a8-7161-fa4b-7dd9202c2...@kit.edu> > Content-Type: text/plain; charset="utf-8"; format=flowed > > Hi Glen, > > sorry, I wrote that email in a hurry and forgot to add the link to the > stream. > It's always twitch.tv/gnuradio . > > But: we'll also upload it to the GNU Radio youtube channel, > https://www.youtube.com/c/GNURadioProject/videos > >
