Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks
Hi, That's a great idea! You may take a look at several blocks that are already in GNU Radio and are configurable through messages. Signal Source comes to my mind. More "sophisticated" blocks also use messages for configuration. For instance, UHD USRP Source, or some blocks of our OOT module gr-tempest (e.g. fine sampling synchronization). You should take a look at those, but it should be as "simple" as adding a setter method on the block for the parameter you want to change, and call it from the function that "listens" to messages. Hope that helps. best Federico El jue, 18 abr 2024 a las 13:40, Matt Clemons () escribió: > Hello, > > I’ve been using the dtv/dvbt blocks in GnuRadio Companion to decode dvbt > signal recordings. I noticed a lot of the blocks in the RX chain require > the user to select the modulation parameters (Constellation, Hierarchy, > Code Rate, etc.). My goal is to remove a lot of these user parameters with > the use of Transmission Parameter Signals (TPS) data called out in the > DVB-T spec. This would make the DVBT receiver more autonomous, and be > better than brute forcing all the modulation settings until you get a > recovered transport stream in the cases where you don't know the > transmitter settings. This solution seems to be a worthwhile improvement to > the current DVBT blocks by utilizing the TPS data called out in the spec. > Implementing this in the c++ code is where I'm running into issues and > where I'm looking for help/advice. > > In the DVB-T spec the Transmission Parameter Signals (TPS) data can be > recovered which will tell you all the modulation parameters of the main > signal. As long as you know the TX mode and Guard Time, you can configure > the OFDM Symbol Acquisition block and the FFT block, which are the only 2 > required blocks before the Demod Reference Signals (DRS) block. The DRS > code already decodes the TPS data but is only looking at 2 of the total 68 > bits to determine what the frame index is, and then clears the std::deque > of TPS data. > > My goal is to use all of the TPS data and either pass it in a tag or pass > through a new port so that all the remaining downstream blocks can get the > modulation parameters from that data rather than a user. I've dug into the > tags and the PMT types required to pass data, but I can't wrap my head > around how I would configure the modulation parameters of the downstream > blocks from the port or tag TPS data passed to it. > > For example, a lot of the DRS modulation parameters are not needed for the > DRS block to work, and when you recover Constellation Type, Hierarchy Type, > and Tx Mode you could then pass these parameters to the DVB-T Demap block > instead of having to create the block with those parameters. > > If there are any examples of other blocks using tags or ports to change > the functionality of another block, that would be useful. Since I am fairly > new to GnuRadio and C++ these modifications seem difficult to me, hoping > someone with more experience in both could point me in the right direction. > > thanks! >
Re: Figuring out different multipath components
Hi, As Jeff says, it all depends on the sampling rate. If the time difference between paths is smaller than the sampling period, then there's no hope of recovering each gain individually. In your case, since you have wi-fi, you have a somewhat large sampling rate, but in indoor environments the difference in time of arrival is typically smaller. Note furthermore that going from inverting the CSI of wi-fi to actually recovering the paths' gain, even if they are resolved by the sampling resolution, is not straightforward. You may check Gallager's great book for a very clear explanation (free at https://ocw.mit.edu/courses/6-450-principles-of-digital-communications-i-fall-2006/resources/book_9/, particularly section 9.4). best Federico El vie, 8 mar 2024 a las 11:53, Jeff Long () escribió: > The received signal is a combination of a large number of multipath > signals, which can not be separated out. It's sort of like a hash of the > environment - a one way calculation. Training signals can be used to > determine the multipath response and minimize or take advantage of it, but > the individual paths are lost. > > On Fri, Mar 8, 2024 at 9:36 AM Sourya Saha > wrote: > >> Hi, >> This is my first post to this list. I am quite new to GNU Radio. I have a >> wifi transmitter and a receiver in a room. The signals from the WiFi >> transmitter get relfected through the various walls and then reach the >> receiver, except the LOS signal. What i want to do is to calculate the AoA >> and RSSI of each of the signals from each of the multipaths. >> >> Could someone suggest how I can do that? Help is really appreciated. >> >
CTF next week
Hi everyone, For the fourth year in a row, we're organizing a little CTF during an exposition event at our University (https://idm.uy/). Since it is completely online (just like GNU Radio's CTF), we encourage people from all over to join and play. The only caveats it's that it is in spanish. If you're interested, you may read all the details at our webpage https://ctf.idm.uy/ (or directly at https://eva.fing.edu.uy/course/view.php?id=1557§ion=1#tabs-tree-start). You may register with a group of up to three people by sending a mail to c...@fing.edu.uy. The deadline is this thursday, and the CTF begins this weekend! best Federico
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
Hi Ralf, Good news! Regarding your question, In order to be sure that what the block was measuring was right, I've used a complete software transceiver together with a Channel Model block. You may take a look at https://github.com/git-artes/gr-isdbt/blob/master/examples/full_transceiver.grc. This example is easily reproduced in DVB-T by combining the TX and RX example flowgraphs. best Federico El lun, 13 dic 2021 a las 8:02, Ralf Gorholt () escribió: > Hello Federico, > > after a lot of thinking I have finally managed to adapt your OFDM > Synchronization and TMCC Decoder blocks for DVB-T :-) The problem was that > the frame and symbol indexes in the tags sent by the TPS decoder were not > correct. > > Although I can see the video now, I am not sure that I have really done > everything right, because I have still some problems of understanding. > Perhaps you can bring some light into the dark? > > I have connected GUI number sinks to the freq. error and samp. error > outputs of the OFDM Synchronization block to display the values and I have > noticed the following: > > 1) With interpolation in the OFDM Synchronization block turned on, when I > adjust the frequency of the source block (frequency correction ppm) so that > the freq. error output value is near to zero, this value drifts very slowly > in one direction, from higher to lower values, crossing zero (i.e. from > positive to negative values). > 2) The value at the samp. error output is zero and constant (at least I > have seen no change during about 30 minutes). > > Is this the correct behaviour? If not, how should it be? > > Thank you very much for your help and kind regards, > > Ralf > > Am 11.12.2021 um 16:11 schrieb Ralf Gorholt: > > Hello Federico, > > I have a lot of difficulties to generate the output and the tags for the > blocks that follow my TPS Decoder in the flowgraph. That's why I had the > idea to take a different approach. > > The OFDM Synchronization block outputs the payload carriers (1705 in 2K > mode) whereas the Demod Reference Symbols block that normally follows the > FFT expects 2048 carriers. My question sounds certainly silly but would it > be possible to fill in the missing carriers with zero carriers (amplitude > and phase == 0) to get 2048 carriers again and thus be able to use the > original DVB-T blocks? As far as I know, in DVB-T the carriers at the > borders are all set to zero (and perhaps the one in the middle too). > Perhaps this would be too simple to be true :-) > > Regards, > > Ralf > > Am 10.12.2021 um 14:41 schrieb Ralf Gorholt: > > Hi Federico, > > indeed, the "symbol_index" tag that is normally sent for each OFDM symbol > is missing. This might cause an unexpected situation for the following > deinterleaver block, "Access not within mapped region" according to > valgrind. > > I will see how I can generate the symbol index for each symbol. The "Demod > Reference Signals" block uses the dvbt_pilot_gen object to parse the input > data and to generate symbol and frame indices. > > As far as I have understood, in your block OFDM Synchronization you have > combined the symbol acquisition and the FFT. Then you connect a TMCC > decoder that eliminates the TMCC and auxiliary carriers, generates tags and > outputs the data carriers. My idea was to do the same for the TPS signals > in DVB-T. > > To my surprise, in principle what I have done seems to work. If not, my > TPS decoder would not be able to correctly decode the TPS information that > changes accordingly when I change settings in the transmitter, for instance > the modulation scheme. > > I will focus on the tags and see what is missing. > > Regards, > > Ralf > > Am 10.12.2021 um 14:25 schrieb Federico 'Larroca' La Rocca: > > Hi, > > I'd be more than happy to help. A couple of things that come into my mind. > > The OFDM Synchronization block is a combination of our "old" OFDM Symbol > acquisition (for a while now it's been part of GNU Radio) and Sync and > Channel estimation blocks (which performed equalization and integer > frequency correction) . The most important difference is that OFDM > Synchronization includes a loop with the estimated channel gains, which in > turn is used to estimate the sampling error (plus fine frequency errors). > It also indicates some events downstream via tags, just like the older > blocks. This new "DVB-T OFDM Synchronization" block should then be a > combination, if I'm not mistaken, of OFDM Symbol Acquisition plus Demod > Reference Signals (I'm sure Ron will know more on this). > > Anyhow, my point is that you should take a look at the OFDM S
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
Hi, I'd be more than happy to help. A couple of things that come into my mind. The OFDM Synchronization block is a combination of our "old" OFDM Symbol acquisition (for a while now it's been part of GNU Radio) and Sync and Channel estimation blocks (which performed equalization and integer frequency correction) . The most important difference is that OFDM Synchronization includes a loop with the estimated channel gains, which in turn is used to estimate the sampling error (plus fine frequency errors). It also indicates some events downstream via tags, just like the older blocks. This new "DVB-T OFDM Synchronization" block should then be a combination, if I'm not mistaken, of OFDM Symbol Acquisition plus Demod Reference Signals (I'm sure Ron will know more on this). Anyhow, my point is that you should take a look at the OFDM Symbol Acquisition and Demod Reference Signals blocks in GNU Radio, and check which tags are used and when. Maybe this lack of tags is generating an unforeseen situation on the downstream blocks which generate the segfault? Furthermore, if I'm not mistaken, the pilots in DVB-T (in particular continuous pilots) are not exactly the same as in ISDB-T. Another possibility is that the Demod Reference Signals block is not equivalent to our Sync and Channel estimation block, and further processing is needed for it to be ready for the DVB-T Demap... best Federico El vie, 10 dic 2021 a las 9:55, Ralf Gorholt () escribió: > Hi Vasil, > > thank you for your message. As I have no experience with GNU Radio and > command line debugging, your hints may be really helpful. I have > attached the gdb and valgrind output to this email. > > In the gdb output thread 27 that receives the SIGSEGV is the DVB-T > "Symbol Inner Interleaver" that comes with GNU Radio, not one of my blocks. > > As far as valgrind is concerned, it tells me for my block OFDM > Synchronization: "Conditional jump or move depends on uninitialised > value(s)". I will see if I can find out which variable is uninitialized > and how I can get rid of this problem. > > Kind regards, > > Ralf > > Am 10.12.2021 um 12:35 schrieb Vasil Velichkov: > > Hi Ralf, > > > > On 10/12/2021 11.52, Ralf Gorholt wrote: > >> Unfortunately, when I deactivate the original flowgraph, it does no > >> longer work and I get a -11 return code. > > The "-11" value means that you got a segmentation fault and the process > was kill with signal 11 (SIGSEGV) > > > > > https://docs.python.org/3.8/library/subprocess.html#subprocess.CalledProcessError.returncode > > https://www.man7.org/linux/man-pages/man7/signal.7.html > > > > In my opinion the easiest way to debug segfaults is to run the flowgraph > under gdb and valgrind. Open your flowgraph in the gnuradio-companion and > then Generate (F5) but do not Execute (F6). The open a terminal, go where > the flowgraph python (.py) file was generated and execute > > > > gdb -ex run --args /usr/bin/python3 test.py > > > > and then when it stops execute `bt` command in the gdb's shell and > provide the full output. To run it under valgrind execute > > > > valgrind --tool=memcheck /usr/bin/python3 test.py > > > > Adjust the path to your python interpreter and its version if needed. > > > > Regards, > > Vasil >
Re: Out Of Tree module works only partially
Hi,
I think you're not taking into account the fact that you're working with
vectors. The line
out[i] = in[i];
Should actually be
for(j=0; j)
escribió:
> Dear all,
>
> I am quite new to GNU Radio and in order to see how GNU Radio blocks
> work I would like to create my own block that (for the moment) just
> copies complex data from the input to the output. This works as long as
> I copy only one number but not when I want to copy packets of numbers
> that come from the preceeding block. My block takes one parameter:
> blk_size. I would like to insert it in my DVB-T receiver flowgraph to
> analyze data (in a later step).
>
> I had a look at the square_ff example and other blocks to see how they
> are built but I still don't see what I am doing wrong. It must be a
> silly mistake. Perhaps you can help me? Here is the code:
>
> myblock_impl::myblock_impl(int blk_size)
> : gr::block("myblock",
> gr::io_signature::make(1, 1, blk_size *
> sizeof(gr_complex)),
> gr::io_signature::make(1, 1, blk_size *
> sizeof(gr_complex)))
> {
> }
>
> void
> myblock_impl::forecast(int noutput_items, gr_vector_int
> &ninput_items_required)
> {
> ninput_items_required[0] = noutput_items;
> }
>
> int
> myblock_impl::general_work(int noutput_items,
> gr_vector_int &ninput_items,
> gr_vector_const_void_star &input_items,
> gr_vector_void_star &output_items)
> {
> const gr_complex *in = (const gr_complex *) input_items[0];
> gr_complex *out = (gr_complex *) output_items[0];
>
> for (int i = 0; i < noutput_items; i++) {
> out[i] = in[i];
> }
>
> consume_each(noutput_items);
>
> return noutput_items;
> }
>
> And the YML file:
>
> id: dl5eu_myblock
> label: myblock
> category: '[dl5eu]'
>
> templates:
>imports: import dl5eu
>make: dl5eu.myblock(${blk_size})
>
> parameters:
> - id: blk_size
>label: Block size
>dtype: int
>default: '1'
>
> inputs:
> - label: in
>domain: stream
>dtype: complex
>vlen: ${blk_size}
>optional: '0'
>
> outputs:
> - label: out
>domain: stream
>dtype: complex
>vlen: ${blk_size}
>optional: '0'
>
> file_format: 1
>
> Thank you very much for your help!
>
> Kind regards,
>
> Ralf
>
OOT module and wrong symbolic link
Hi everyone, I'm currently porting an OOT module to 3.8 and stumbled into a weird situation regarding the .so files that are installed on /usr/local/lib/x86_64-linux-gnu/. If I understood correctly, there are three files that are created there (files reflect my OOT's name): libgnuradio-isdbt.so, libgnuradio-isdbt.so.1.0.0git and libgnuradio-isdbt.so.XXX (where XXX is related to the commit's short id; for instance now I have libgnuradio-isdbt.so.17e304df). The first two files are actually symbolic links: libgnuradio-isdbt.so points to libgnuradio-isdbt.so.1.0.0git which in turn points to libgnuradio-isdbt.so.XXX. I was not very careful when (un)installling my OOT, so I got three or four versions of libgnuradio-isdbt.so.XXX in /usr/local/lib/x86_64-linux-gnu/. The problem was that the file libgnuradio-isdbt.so.1.0.0git stubbornly pointed to the wrong (old) version of libgnuradio-isdbt.so.XXX. This resulted in a really difficult to diagnose error, as the OOT worked on a Docker, but I repeatedly got an "AttributeError: module ..." error on my installation. The problem was solved by deleting the old libgnuradio-isdbt.so.XXX files. The question I have is then: why was the second symbolic link pointing to an older version of the .so file? Maybe someone can point me to the cmake file that creates and copies these files. best and thanks in advance Federico
Re: virtual CTF
Hi Nathan, Sure thing! Regarding your level on GNU Radio (or signal processing in general), we have two categories of competitors: Marconi (junior/newbies) and Shannon (senior/advanced). About non-Spanish speaking competitors, although the clues are in Spanish you may easily translate them (or ask for help in the discord channel we set up). Moreover, the flags that are audible are in Phonetic Code (i.e. alpha, beta, charlie, etc.). Hope that helps you decide yourself to enroll with a team (or alone). best Federico El mié, 6 oct 2021 a las 23:56, Nathan Van Ymeren () escribió: > Hi Federico, > > Will the challenges be available to people like me who are total neophytes > and want to just follow along (and who don't speak Spanish)? > > N >
virtual CTF
Hello everyone, Just like last year we're organizing a virtual CTF (or CTS as they called it during the last GRCon) here in our University in Uruguay. You may take a look at ctf.idm.uy/. All challenges will be available this Saturday and clues are in spanish (although I'm pretty sure they are solvable without any clues). The competition ends next Friday 10/15. In order to participate a mail has to be sent to c...@fing.edu.uy, along with the names and mails of up to 3 team members. If you have any doubt do not hesitate to contact me. best Federico
CTF
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
GNU Radio development mini-workshop
Hi everyone, This message is for those of you who speak spanish. I've organized a little workshop (or crash course) on development in GNU Radio. Basically, how to create new blocks and some tips I've learned during these years (especially when making gr-isdbt). I've recorded the four 1.5hs sessions which I share, and provide all of the generated code (and a little homework), at the course website: https://iie.fing.edu.uy/personal/flarroca/teaching/taller-de-desarrollo-en-gnu-radio/. Maybe it'll be useful for other people. Let me know if you have any feedback. best Federico
Re: fastest way to interpolate
Hi Martin, Thanks for the reply. I thought the same, and tested the system by using a corrected (by hand) sampling rate on the USRP (and disabling the resampling block): I get about 40-50 MSps with virtually no dropped samples. That's why I thought about correcting the sampling rate through messages, but would like to check whether there's a faster way to resample the signal on software. best Federico El jue., 28 may. 2020 a las 17:39, Martin Spears () escribió: > Frederico > > I am not certain about this but could it be the USB bus. I know with my > Fairwaves XTRX which connects through 2x miniPCI-e the transfer rate is > close to 8Gbps, and the SDR can do 120Msps is SISO mode > > Martin Spears > Chief Technical Officer > Ingenious Countermeasures Technologies Inc. > mspe...@icmt.ca > 705-885-1990 > > -- > *From:* Discuss-gnuradio > on behalf of Federico 'Larroca' La Rocca > *Sent:* Thursday, May 28, 2020 4:11:01 PM > *To:* GNURadio Discussion List > *Subject:* fastest way to interpolate > > Hi everyone, > > I've finally been testing gr-tempest with some SDR hardware and the > following problem arised: sampling correction takes way too much CPU. In my > (relatively new) laptop I get dropped samples at a sampling rate above 15 > MSps. I'm currently using the Fractional Resampler block, and I would need > at least 30MSps to get a decent image. > > The question is then: is there any other faster possibility to interpolate > and correct the incoming's signal sampling rate? Right now, I'm thinking > about sending messages to the USRP Source block, but it would not work with > other hardware. Note that recording the signal and passing it through the > provided flowgraph still works, but it would be much more interesting to > have a real-time system. > > best > Federico >
fastest way to interpolate
Hi everyone, I've finally been testing gr-tempest with some SDR hardware and the following problem arised: sampling correction takes way too much CPU. In my (relatively new) laptop I get dropped samples at a sampling rate above 15 MSps. I'm currently using the Fractional Resampler block, and I would need at least 30MSps to get a decent image. The question is then: is there any other faster possibility to interpolate and correct the incoming's signal sampling rate? Right now, I'm thinking about sending messages to the USRP Source block, but it would not work with other hardware. Note that recording the signal and passing it through the provided flowgraph still works, but it would be much more interesting to have a real-time system. best Federico
Re: gr-tempest: an implementation of TempestSDR for GNU Radio
Hello everyone, Just a quick mail to let you know that gr-tempest now supports GNU Radio 3.8 too. It was actually much easier than I thought it would be, thanks to the guide at the wiki. I had a little bit of trouble creating both branches (one for 3.7 and master supporting 3.8), but that's my lack of experience on using git (i.e. using it for other than the typical git add, git commit, git push :-) ). best Federico PS Thanks Jared for your comments. El vie., 15 may. 2020 a las 0:18, U L () escribió: > Federico, > > Well, I've been doing docker for a bit longer than you and I am impressed > with how quickly you got this up and running. Getting a reference GR docker > image defined has been a goal of mine and I'll see what I might change from > this point. I'll address in your github issues if I find something that > works better. > > Well done, > Jared. > > On Thu, May 14, 2020 at 4:25 PM Federico 'Larroca' La Rocca < > flarr...@gmail.com> wrote: > >> Hi again, >> So I've learned some docker and prepared a couple of containers that may >> be useful for other people: one with the latest releases version of GNU >> Radio on the latest stable Ubuntu, and one with GNU Radio 3.7 on an Ubuntu >> 18.04. I share them in https://github.com/git-artes/docker-gnuradio. I >> provide there the run command that enables both sound and GUI (so as to run >> GNU Radio companion). >> Keep in mind that I'm a total newbie to docker. Feedback is always >> welcome. >> best >> Federico >> >> El vie., 8 may. 2020 a las 13:39, Federico 'Larroca' La Rocca (< >> flarr...@gmail.com>) escribió: >> >>> Thanks Marcus and Jared. Regarding the question of Jared, TEMPEST >>> definitely works on non-CRT monitors. However, since the signal is now >>> emitted only by the cable and the connectors, it will be much less >>> powerful. Note that the principle is the same as in osmo-fl2k [1], although >>> they avoid the nulls at the harmonics of the pixel rate, which complicates >>> TEMPEST (resulting in a sort of horizontal border detector). In my >>> experience, cheap cables and adapters (specially "splitters") generate >>> signals that are easy to spy on from some meters away. >>> >>> Regarding Docker, I'll give it a try. It's a great excuse to finally >>> learn how to use them. >>> >>> best >>> Federico >>> >>> [1] https://osmocom.org/projects/osmo-fl2k/wiki >>> >>> El vie., 8 may. 2020 a las 13:11, Marcus Müller () >>> escribió: >>> >>>> Hi Federico, >>>> >>>> this is pretty awesome! Thanks for sharing it. >>>> >>>> You can actually install both, if you use separate installation prefixes >>>> for the two and make sure that the PYTHONPATH and LD_LIBRARY_PATH and >>>> GRC_BLOCKS_PATH environment only include one of these. >>>> >>>> Easier, and less error-prone, definitely, is just using a Linux >>>> container. (You could run debian buster in a podman- or docker-run >>>> container, for example. Debian buster comes with 3.8.1.0 out of the >>>> box.). >>>> For non-graphical stuff, that's relatively easy, for graphical (like >>>> yours), there's more fiddling involved until your containers can access >>>> your X server (don't know about Wayland, honestly). >>>> >>>> Best regards, >>>> Marcus >>>> >>>> El vie., 8 may. 2020 a las 1:13, U L () escribió: >>>> >>>>> Federico, >>>>> >>>>> This looks very impressive and I can't wait to play with it. This >>>>> works with non-CRT screens too? >>>>> >>>>> Without a whole lot of hassle you can install GNURadio 3.8 in a >>>>> container (e.g. docker) from an ubuntu or debian base image to avoid >>>>> dependency conflicts between 3.7 and 3.8. >>>>> >>>>> Jared. >>>>> >>>> >>>> On 07.05.20 23:50, Federico 'Larroca' La Rocca wrote: >>>> > Hi everyone, >>>> > >>>> > The last weeks I've been working on a little project I've had in mind >>>> > for a long time now: an implementation of Martin Marinov's excellent >>>> > TempestSDR [1] in GNU Radio. Although it's still work in progress, the >>>> > code is available at https://github.com/git-artes/gr-te
Re: GNU Radio 3.7 on Ubuntu 20.04
Hi,
I've been playing around with docker these last days, and I got a running
3.7 on an Ubuntu 18.04 and compiled some OOTs. You may want to check my
repo: https://github.com/git-artes/docker-gnuradio (although it's similar
to what Johannes suggests).
best
Federico
El vie., 15 may. 2020 a las 5:17, Johannes Demel ()
escribió:
> Hi all,
>
> we all saw the Python clock [0] run out on 2020-01-01 after over 10 years.
>
> Also, Maitland Bottoms had to add GR patches to switch from Qt4 to Qt5
> for GR 3.7 even earlier to be able to get GR3.7 into newer Debian
> versions. Apps are not accepted to the repos if they run with Qt
> versions < 5.
>
> All in all, new systems require new software. In this case GR3.8.
>
> If you really need a GR3.7 install, this worked for me:
> `sudo docker run --rm -it --net=host --env="DISPLAY"
> --volume="$HOME/.Xauthority:/root/.Xauthority:rw"
> `. cf [1]
> At least I could open and run flowgraphs and run UHD commands. I used
> GR3.8 from `ppa:gnuradio` though the docker command should work as well.
> USB devices might be another adventure.
> You probably want to set up a new container with the latest GR3.7 release.
>
> Cheers
> Johannes
>
>
> [0] https://pythonclock.org/
> [1]
>
> https://medium.com/@SaravSun/running-gui-applications-inside-docker-containers-83d65c0db110
>
> On 15.05.20 03:31, James Hayek wrote:
> > I tried it and ran into a ton of problems... I posted it earlier today.
> > Nothing as of yet, but I am still researching. I might give up and
> > install Ubuntu 18 so I can use the new Pluto I bought. ;)
> >
> >
> > iio Block Errors (WSL) Ubuntu 20.04 LTS
> >
> > I am running a Windows 10 system where I have installed the Windows
> > Subsystem for Linux running Ubuntu 20.04 LTS.
> > I followed the steps outlined here:
> > http://wiki.analog.com/resources/tools-software/linux-software/gnuradio
> >
> > After doing the steps outlined above, I ran into the following error.
> >
> > ·Traceback (most recent call last):
> >
> > ·File
> > "/home/jameshayek/GNURadio-Projects/FMReceiver/Simple_FM_Receiver.py",
> > line 35, in
> >
> > ·from gnuradio.qtgui import Range, RangeWidget
> >
> > ·File "/usr/lib/python3/dist-packages/gnuradio/qtgui/__init__.py", line
> > 36, in
> >
> > ·from .qtgui_swig import *
> >
> > ·File "/usr/lib/python3/dist-packages/gnuradio/qtgui/qtgui_swig.py",
> > line 13, in
> >
> > ·from . import _qtgui_swig
> >
> > ·ImportError: libQt5Core.so.5: cannot open shared object file: No such
> > file or directory
> >
> >
> > I assume this is an issue with mapping the location of swig, so copied
> > the recursive directory to the gnuradio folder as the lesson said if
> > there is a swig import error. Still no luck.
> >
> > I also thought it was an issue with the qt5 library, so I ran "sudo
> > apt-get install -y qt5-default"
> >
> > But still no luck.
> >
> > /Is this an issue with Ubuntu 20?/
> >
> > /
> > /
> >
> > My exact steps are shown below.
> >
> > 1.Moving Post-Install to Pre-Install:
> >
> > oFor Python 3.8 I initially exported the following location to
> $PYTHONPATH
> >
> > §export PYTHONPATH=$PYTHONPATH:/usr/lib/python{PYTHON VERSION}/{site or
> > dist}-packages
> >
> > ·export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.8/dist-packages/
> >
> > oI used the python3.8 folder since GNC > About showed Python 3.8
> >
> > oI then noticed I must have added the wrong PATH, because find resulted
> > in: “/usr/lib/python3/dist-packages/gnuradio”
> >
> > oI re-ran the “export” command to include what “find” returned.
> >
> > 2.Installing all “apt install” dependencies:
> >
> > osudo apt install libxml2 libxml2-dev bison flex cmake git libaio-dev
> > libboost-all-dev
> >
> > osudo apt install liborc-dev
> >
> > osudo apt install swig
> >
> > §I was under the impression this was not needed for 3.8; however I did
> > have it installed as a failsafe.
> >
> > osudo apt install bison flex cmake git libgmp-dev
> >
> > oOther stuff that I didn’t need but installed anyway
> >
> > §sudo apt install libavahi-common-dev libavahi-client-dev
> >
> > §sudo apt install libusb-1.0-0-dev
> >
> > §sudo apt install doxygen
> >
> > 3.Building from source:
> >
> >
> > olibiio
> >
> > §git clone https://github.com/analogdevicesinc/libiio.git
> >
> > §cd libiio
> >
> > §cmake ./
> >
> > §make
> >
> > §sudo make install
> >
> > §cd ../
> >
> >
> > olibad9361-iio
> >
> > §git clone https://github.com/analogdevicesinc/libad9361-iio.git
> >
> > §cd libad9361-iio
> >
> > §cmake ./
> >
> > §make
> >
> > §sudo make install
> >
> > §cd ../
> >
> >
> > ogr-iio
> >
> > §git clone -b upgrade-3.8 https://github.com/analogdevicesinc/gr-iio.git
> >
> > §cd gr-iio
> >
> > §cmake ./
> >
> > §make
> >
> > §sudo make install
> >
> > §cd ../
> >
> > §sudo ldconfig
> >
> >
> >
> > 4.Because it seems like I have a swig import issue, I copied the
> > directory to the gnuradio folder
> >
> > osudo cp -r /usr/local/lib/python3/dist-packages/iio/
> > /usr/lib/python3/dist-packages/gnuradio/
> >
> > ima
Re: gr-tempest: an implementation of TempestSDR for GNU Radio
Hi again, So I've learned some docker and prepared a couple of containers that may be useful for other people: one with the latest releases version of GNU Radio on the latest stable Ubuntu, and one with GNU Radio 3.7 on an Ubuntu 18.04. I share them in https://github.com/git-artes/docker-gnuradio. I provide there the run command that enables both sound and GUI (so as to run GNU Radio companion). Keep in mind that I'm a total newbie to docker. Feedback is always welcome. best Federico El vie., 8 may. 2020 a las 13:39, Federico 'Larroca' La Rocca (< flarr...@gmail.com>) escribió: > Thanks Marcus and Jared. Regarding the question of Jared, TEMPEST > definitely works on non-CRT monitors. However, since the signal is now > emitted only by the cable and the connectors, it will be much less > powerful. Note that the principle is the same as in osmo-fl2k [1], although > they avoid the nulls at the harmonics of the pixel rate, which complicates > TEMPEST (resulting in a sort of horizontal border detector). In my > experience, cheap cables and adapters (specially "splitters") generate > signals that are easy to spy on from some meters away. > > Regarding Docker, I'll give it a try. It's a great excuse to finally learn > how to use them. > > best > Federico > > [1] https://osmocom.org/projects/osmo-fl2k/wiki > > El vie., 8 may. 2020 a las 13:11, Marcus Müller () > escribió: > >> Hi Federico, >> >> this is pretty awesome! Thanks for sharing it. >> >> You can actually install both, if you use separate installation prefixes >> for the two and make sure that the PYTHONPATH and LD_LIBRARY_PATH and >> GRC_BLOCKS_PATH environment only include one of these. >> >> Easier, and less error-prone, definitely, is just using a Linux >> container. (You could run debian buster in a podman- or docker-run >> container, for example. Debian buster comes with 3.8.1.0 out of the box.). >> For non-graphical stuff, that's relatively easy, for graphical (like >> yours), there's more fiddling involved until your containers can access >> your X server (don't know about Wayland, honestly). >> >> Best regards, >> Marcus >> >> El vie., 8 may. 2020 a las 1:13, U L () escribió: >> >>> Federico, >>> >>> This looks very impressive and I can't wait to play with it. This works >>> with non-CRT screens too? >>> >>> Without a whole lot of hassle you can install GNURadio 3.8 in a >>> container (e.g. docker) from an ubuntu or debian base image to avoid >>> dependency conflicts between 3.7 and 3.8. >>> >>> Jared. >>> >> >> On 07.05.20 23:50, Federico 'Larroca' La Rocca wrote: >> > Hi everyone, >> > >> > The last weeks I've been working on a little project I've had in mind >> > for a long time now: an implementation of Martin Marinov's excellent >> > TempestSDR [1] in GNU Radio. Although it's still work in progress, the >> > code is available at https://github.com/git-artes/gr-tempest and I've >> > tested it on several recordings I've kept from when we were testing >> > TempestSDR (which I share on the project's webpage). >> > >> > My idea with this re-implementation was to add another cool demo into >> > GNU Radio, plus making it easier to extend and maintain by piggybacking >> > on GNU Radio's development and using the companion (for instance, I've >> > included a channel simulation example). I've made some demos and a video >> > that show them in action: https://www.youtube.com/watch?v=oTCu8HTaN3Y. >> > >> > I have not yet tested it with hardware as the university is closed now, >> > so if anyone can test it I'd be more than glad! Any kind of feedback is >> > as usual welcome. >> > >> > Please note that it is currently built around GNU Radio 3.7 as I'm >> > currently in need of this version of GNU Radio for my classes. Is there >> > a safe way to install both 3.7 and 3.8? >> > >> > best >> > Federico >> > >> > [1] https://github.com/martinmarinov/TempestSDR >> >
Re: gr-tempest: an implementation of TempestSDR for GNU Radio
Thanks Marcus and Jared. Regarding the question of Jared, TEMPEST definitely works on non-CRT monitors. However, since the signal is now emitted only by the cable and the connectors, it will be much less powerful. Note that the principle is the same as in osmo-fl2k [1], although they avoid the nulls at the harmonics of the pixel rate, which complicates TEMPEST (resulting in a sort of horizontal border detector). In my experience, cheap cables and adapters (specially "splitters") generate signals that are easy to spy on from some meters away. Regarding Docker, I'll give it a try. It's a great excuse to finally learn how to use them. best Federico [1] https://osmocom.org/projects/osmo-fl2k/wiki El vie., 8 may. 2020 a las 13:11, Marcus Müller () escribió: > Hi Federico, > > this is pretty awesome! Thanks for sharing it. > > You can actually install both, if you use separate installation prefixes > for the two and make sure that the PYTHONPATH and LD_LIBRARY_PATH and > GRC_BLOCKS_PATH environment only include one of these. > > Easier, and less error-prone, definitely, is just using a Linux > container. (You could run debian buster in a podman- or docker-run > container, for example. Debian buster comes with 3.8.1.0 out of the box.). > For non-graphical stuff, that's relatively easy, for graphical (like > yours), there's more fiddling involved until your containers can access > your X server (don't know about Wayland, honestly). > > Best regards, > Marcus > > El vie., 8 may. 2020 a las 1:13, U L () escribió: > >> Federico, >> >> This looks very impressive and I can't wait to play with it. This works >> with non-CRT screens too? >> >> Without a whole lot of hassle you can install GNURadio 3.8 in a container >> (e.g. docker) from an ubuntu or debian base image to avoid dependency >> conflicts between 3.7 and 3.8. >> >> Jared. >> > > On 07.05.20 23:50, Federico 'Larroca' La Rocca wrote: > > Hi everyone, > > > > The last weeks I've been working on a little project I've had in mind > > for a long time now: an implementation of Martin Marinov's excellent > > TempestSDR [1] in GNU Radio. Although it's still work in progress, the > > code is available at https://github.com/git-artes/gr-tempest and I've > > tested it on several recordings I've kept from when we were testing > > TempestSDR (which I share on the project's webpage). > > > > My idea with this re-implementation was to add another cool demo into > > GNU Radio, plus making it easier to extend and maintain by piggybacking > > on GNU Radio's development and using the companion (for instance, I've > > included a channel simulation example). I've made some demos and a video > > that show them in action: https://www.youtube.com/watch?v=oTCu8HTaN3Y. > > > > I have not yet tested it with hardware as the university is closed now, > > so if anyone can test it I'd be more than glad! Any kind of feedback is > > as usual welcome. > > > > Please note that it is currently built around GNU Radio 3.7 as I'm > > currently in need of this version of GNU Radio for my classes. Is there > > a safe way to install both 3.7 and 3.8? > > > > best > > Federico > > > > [1] https://github.com/martinmarinov/TempestSDR >
gr-tempest: an implementation of TempestSDR for GNU Radio
Hi everyone, The last weeks I've been working on a little project I've had in mind for a long time now: an implementation of Martin Marinov's excellent TempestSDR [1] in GNU Radio. Although it's still work in progress, the code is available at https://github.com/git-artes/gr-tempest and I've tested it on several recordings I've kept from when we were testing TempestSDR (which I share on the project's webpage). My idea with this re-implementation was to add another cool demo into GNU Radio, plus making it easier to extend and maintain by piggybacking on GNU Radio's development and using the companion (for instance, I've included a channel simulation example). I've made some demos and a video that show them in action: https://www.youtube.com/watch?v=oTCu8HTaN3Y. I have not yet tested it with hardware as the university is closed now, so if anyone can test it I'd be more than glad! Any kind of feedback is as usual welcome. Please note that it is currently built around GNU Radio 3.7 as I'm currently in need of this version of GNU Radio for my classes. Is there a safe way to install both 3.7 and 3.8? best Federico [1] https://github.com/martinmarinov/TempestSDR
Re: DVB-T receiver problem (OFDM symbol acquisition)
Hi Ralf, It should be right after the channel. It performs symbol acquisition, FFT and channel equalization (as well as sampling corrections and coarse and fine frequency corrections). Please see the examples folder in gr-isdbt (for instance rx_demo.grc which also includes the gr-dtv blocks disabled, which should help you understand where to put the block). best El mar., 3 mar. 2020 a las 4:16, Ralf Gorholt () escribió: > Dear Federico, > > unfortunately I have not been able to figure out how this block has to be > used and where it has to be positioned in the flow graph. Although I know > more about DVB-T today than three months ago I am still a beginner :-) > > Perhaps it would help me if you could give me some hints. > > Thank you very much and kind regards, > > Ralf, DL5EU > > *Gesendet:* Montag, 02. März 2020 um 13:47 Uhr > *Von:* "Federico 'Larroca' La Rocca" > *An:* "Ron Economos" > *Cc:* "GNURadio Discussion List" > *Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition) > Hi, > Although I don't have an answer to Ralf's question, if the sampling rate > seems to be a problem, gr-isdbt's OFDM Synchronization block (with > "Interpolate" set to "yes") corrects the sampling rate; see > https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of > the algorithm (although it expects different tags and parameters, so that's > probably why it won't work out of the box with the rest of the gr-dtv > blocks or a DVB-T transmission). As Ron wrote, the rest of the block is > mostly the same as in gr-dtv. > best > Federico > > El lun., 2 mar. 2020 a las 9:44, Ron Economos () > escribió: > >> Did you read the README.md of gr-dvbt? It says: >> >> *Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is >> now integrated in the mainline of gnuradio/gr-dtv.* >> >> The OFDM symbol acquisition block in gr-dtv has been upgraded with the >> fixes from the ISDBT team. See this commit: >> >> >> https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a >> >> However, there is still an issue with the block. It can't tolerate a >> sample rate difference between the transmitter and receiver. If the >> difference is large, the block will fail fairly quickly (minutes). >> >> I have a test OFDM acquisition block that prints out the drift. It can be >> found here: >> >> https://github.com/drmpeg/gr-dvbtx >> >> You may have to go back one commit to make it compile with the latest >> version of GNU Radio 3.7. >> >> Ron >> On 3/2/20 03:58, Ralf Gorholt wrote: >> >> Dear all, >> >> please apologize my long email but I cannot explain my problem and what I >> have done so far in three words. >> >> I am currently working on a DVB-T receiver project to receive >> transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and >> an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The >> transmitter is a HiDes model HV320E. Reception works, but the video stops >> after one minute or so while the constellation diagram is still active >> (dots are moving). I am no expert and have only few knowledge of DSP and >> DVB yet, but to me the problem seems to be in the OFDM symbol acquisition >> block. >> >> Conditions: >> Linux Mint 19.3 in a virtual machine (VMware) >> GNU Radio 3.7.11 if I am right (I would need to check at home) >> >> What I have done so far: >> >> I have created a flow graph for a DVB-T receiver based on the examples in >> gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 >> MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP >> server sink to which I connect with VLC media player to display the >> received video transport stream. This works, but after one minute or so the >> video stops while the constellation diagram is still active (dots are >> moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 >> but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have >> the same problem. >> >> To track down the source of the problem, I have created a file outside of >> GNU Radio that I can use in a file source instead of the RTL-SDR source of >> my flow graph. This allows me to make tests with an input signal that does >> not change between different tests. >> >> The data of this file are sent to the OFDM symbol acquisition block and >> the output of this block i
Re: DVB-T receiver problem (OFDM symbol acquisition)
Ron, Let me know if I can be of any help. I've been wanting to port the whole project and integrate it to GNU Radio for a some years by now, but I just can't find the time. Maybe it would make a GSoC project? Or it's too late by now? best Federico El lun., 2 mar. 2020 a las 10:56, Ron Economos () escribió: > Okay, just making sure since you mentioned gr-dvbt. I'll take a look at > the gr-isdbt acquisition block and see if the interpolation method can be > ported to GNU Radio. > > It doesn't take much difference in sample rate to cause the problem. In my > setup, I'm using two different Ettus B210's (without GPS locking), and it > fails pretty quickly. I can make it run longer by using the test block and > manually adjusting the sample rate of one B210. > > Ron > On 3/2/20 05:35, Ralf Gorholt wrote: > > Dear Ron, > > thank you very much for your quick answer. > > I know that Bogdan donated gr-dvbt to GNU radio and I did not install it > seperately. It has been installed with GNU Radio using the package manager. > The commit you mention seems to be from december 2015, so I suppose it is > already in the package but I will check the source code of the installed > GNU Radio version when I am back at home. > > As far as the drift is concerned, I will try your block and see what it > prints out. There might be a slight difference because some source blocks > accept only integer values as sample rates (if i remember correctly the > ADALM PLUTO does), but in my case a sample rate of 16/7 MHz is needed, > which is not an integer value. > > I suppose there is no way to correct a sample rate difference > automatically and for small differences resampling won't help either... > > Kind regards, > > Ralf (DL5EU) > > *Gesendet:* Montag, 02. März 2020 um 13:42 Uhr > *Von:* "Ron Economos" > *An:* discuss-gnuradio@gnu.org > *Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition) > > Did you read the README.md of gr-dvbt? It says: > > *Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is > now integrated in the mainline of gnuradio/gr-dtv.* > > The OFDM symbol acquisition block in gr-dtv has been upgraded with the > fixes from the ISDBT team. See this commit: > > > https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a > > However, there is still an issue with the block. It can't tolerate a > sample rate difference between the transmitter and receiver. If the > difference is large, the block will fail fairly quickly (minutes). > > I have a test OFDM acquisition block that prints out the drift. It can be > found here: > > https://github.com/drmpeg/gr-dvbtx > > You may have to go back one commit to make it compile with the latest > version of GNU Radio 3.7. > > Ron > On 3/2/20 03:58, Ralf Gorholt wrote: > > Dear all, > > please apologize my long email but I cannot explain my problem and what I > have done so far in three words. > > I am currently working on a DVB-T receiver project to receive > transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and > an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The > transmitter is a HiDes model HV320E. Reception works, but the video stops > after one minute or so while the constellation diagram is still active > (dots are moving). I am no expert and have only few knowledge of DSP and > DVB yet, but to me the problem seems to be in the OFDM symbol acquisition > block. > > Conditions: > Linux Mint 19.3 in a virtual machine (VMware) > GNU Radio 3.7.11 if I am right (I would need to check at home) > > What I have done so far: > > I have created a flow graph for a DVB-T receiver based on the examples in > gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 > MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP > server sink to which I connect with VLC media player to display the > received video transport stream. This works, but after one minute or so the > video stops while the constellation diagram is still active (dots are > moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 > but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have > the same problem. > > To track down the source of the problem, I have created a file outside of > GNU Radio that I can use in a file source instead of the RTL-SDR source of > my flow graph. This allows me to make tests with an input signal that does > not change between different tests. > > The data of this file are sent to the OFDM symbol acquisition block and > the output of this block is stored in a second file. When the input signal, > the algorithm and the parameters do not change between different tests I > expect the generated file to be always the same. However, this is not the > case. The files that are generated with the output of the OFDM symbol > acquisition block differ from each other. But when I send the content of > one of those
Re: DVB-T receiver problem (OFDM symbol acquisition)
Hi, Although I don't have an answer to Ralf's question, if the sampling rate seems to be a problem, gr-isdbt's OFDM Synchronization block (with "Interpolate" set to "yes") corrects the sampling rate; see https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of the algorithm (although it expects different tags and parameters, so that's probably why it won't work out of the box with the rest of the gr-dtv blocks or a DVB-T transmission). As Ron wrote, the rest of the block is mostly the same as in gr-dtv. best Federico El lun., 2 mar. 2020 a las 9:44, Ron Economos () escribió: > Did you read the README.md of gr-dvbt? It says: > > *Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is > now integrated in the mainline of gnuradio/gr-dtv.* > > The OFDM symbol acquisition block in gr-dtv has been upgraded with the > fixes from the ISDBT team. See this commit: > > > https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a > > However, there is still an issue with the block. It can't tolerate a > sample rate difference between the transmitter and receiver. If the > difference is large, the block will fail fairly quickly (minutes). > > I have a test OFDM acquisition block that prints out the drift. It can be > found here: > > https://github.com/drmpeg/gr-dvbtx > > You may have to go back one commit to make it compile with the latest > version of GNU Radio 3.7. > > Ron > On 3/2/20 03:58, Ralf Gorholt wrote: > > Dear all, > > please apologize my long email but I cannot explain my problem and what I > have done so far in three words. > > I am currently working on a DVB-T receiver project to receive > transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and > an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The > transmitter is a HiDes model HV320E. Reception works, but the video stops > after one minute or so while the constellation diagram is still active > (dots are moving). I am no expert and have only few knowledge of DSP and > DVB yet, but to me the problem seems to be in the OFDM symbol acquisition > block. > > Conditions: > Linux Mint 19.3 in a virtual machine (VMware) > GNU Radio 3.7.11 if I am right (I would need to check at home) > > What I have done so far: > > I have created a flow graph for a DVB-T receiver based on the examples in > gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 > MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP > server sink to which I connect with VLC media player to display the > received video transport stream. This works, but after one minute or so the > video stops while the constellation diagram is still active (dots are > moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 > but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have > the same problem. > > To track down the source of the problem, I have created a file outside of > GNU Radio that I can use in a file source instead of the RTL-SDR source of > my flow graph. This allows me to make tests with an input signal that does > not change between different tests. > > The data of this file are sent to the OFDM symbol acquisition block and > the output of this block is stored in a second file. When the input signal, > the algorithm and the parameters do not change between different tests I > expect the generated file to be always the same. However, this is not the > case. The files that are generated with the output of the OFDM symbol > acquisition block differ from each other. But when I send the content of > one of those generated files to the rest of the receiver and do this > several times, I always get the same transport stream at the output. I have > verified this by using a file sink and comparing the files. That’s why I > suspect the OFDM symbol acquisition block to be the culprit. > > When I was searching the internet for information concerning my problem, I > found an email from 2015 in the archive of this mailing list where someone > wrote that the OFDM symbol acquisition block of gr-isdbt should be used > because it worked better than the one in gr-dvbt. I have done so and > installed gr-isdbt from git and replaced the block. However, there are two > such blocks in gr-isdbt and none of them solves my problem. They perform > even worse than the original block in gr-dvbt and after some time the > program terminates without a message. > > I hope that my explanations are clear enough. > > Is there anybody who can tell me what might be wrong here or what I am > doing wrong? Why is the output of the OFDM symbol acquisition block not > always the same when the start condition of every run is the same? Am I > missing something here? > > Thank you very much for your help. > > Kind regards, > Ralf > >
[Discuss-gnuradio] ISDB-T transmitter working on commercial TVs
Hello everyone, For those interested in our ISDB-T transmitter project (see my previous mail to the list below), I wanted to share the news that we (finally) got it working with commercial TVs. So far, the transmission was correctly displayed by SDR-based receivers, but the behavior with "off-the-shelf" TVs was erratic (to be more blunt: it didn't work). This week we found out why and it's now working nicely. We are still testing it, and in particular we'll try to use it with cheap SDR transmitters (rpitx and osmo-fl2k). As usual, it would be very interesting to receive feedback (both failures and successes). best Federico ------ *From*: Federico 'Larroca' La Rocca *Subject*: [Discuss-gnuradio] ISDB-T transmitter OOT *Date*: Fri, 21 Dec 2018 14:13:03 -0300 -- Hi everyone, I'm very glad to announce that our OOT gr-isdbt now includes the transmitter and may be considered (almost) complete. The repository is at https://github.com/git-artes/gr-isdbt. For those of you who did not know it, we developed gr-isdbt some years ago now (I think 2015 was the year we considered it useful) and it was a receiver-only for ISDB-T (the TVD standard used mostly in south america and Japan). To give a little bit of context, last year two students of ours (Santiago Castro and Javier Hernández) here in the university started to work on the implementation of the transmitter. Their work is still available at their repo (https://github.com/jhernandezbaraibar/gr-isdbt-Tx), although it may be considered deprecated, since over the last few months I've integrated their work into gr-isdbt and significant changes were introduced in the process. For those interested in using it, please note that the transmitter is still WIP. In particular, I have tested it somewhat thoroughly in software and I am confident it works as it should (we have included a full transceiver example in the corresponding directory). I am now seriously testing it in over-the-air transmissions with not-so-satisfactory results. However, I'm leaving for some weeks for holidays, thus the announcement. Feedback is, as usual, more than welcome. best Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Hi,
I think it is very possible to merge them, specially in the RS decoder
which I didn't modify much. The viterbi took me quiet some thinking and
testing, but it's possible too.
If it would make sense, that's another question :-). I use it mostly as
another indicator that the flowgraph is correctly configured (sometimes the
constellation is good enough, but if you have misspecified for instance the
time interleaver length you will get garbage). Performance-wise it has
negligible impact.
If you are interested I can try to make a couple of PRs.
best
El mié., 24 jul. 2019 a las 14:21, Müller, Marcus (CEL) ()
escribió:
> Hi Federico,
>
> would it make sense to merge that extension back to mainline GNU Radio?
>
> Best regards,
> Marcus
> On Wed, 2019-07-24 at 12:41 -0300, Federico 'Larroca' La Rocca wrote:
> > Hi,
> > If you are interested in measuring the number of errors in the
> Reed-Solomon block of DTV, you may take a look at our OOT module gr-isdbt (
> https://github.com/git-artes/gr-isdbt) which includes modifications to
> the RS (and the viterbi) decoder to outputs the BER (but is easily
> modifiable to output the number of errors).
> > best
> > Federico
> >
> > El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) (<
> muel...@kit.edu>) escribió:
> > > Hi Alex!
> > > Hm, interesting. Would you happen to have the full verbatim error?
> > >
> > > As a complete aside:
> > > I know we're not doing any of that consistently in the tree, but
> > > especially when handling things like polynomials "packed" into
> > > integers, and amounts of bits, I always recommend people explicitly use
> > > "unsigned int", or directly go for an explicitly sized integer type,
> > > e.g. "uint64_t gfpoly" for their polynomial representations, so that
> > > there's no arithmetic surprises – signed integer overflow, for example,
> > > is way less well-defined than unsigned.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Wed, 2019-07-24 at 10:30 -0500, Alex Roberts wrote:
> > > > So I tried re-implementing the gr-dtv Reed Solomon decoder with an
> additional output so I could monitor/output the number of errors corrected.
> > > > I used gr-modtool, created new block with new name so it wouldn't
> conflict with the existing and made sure to update the markup language for
> the grc block.
> > > >
> > > > I get an error about Number of outputs 1 exceed max 0. I'm not sure
> why that is.
> > > >
> > > > Here is my impl declaration with io_signatures.
> > > >
> > > > custom_reed_solomon_dec_impl::custom_reed_solomon_dec_impl(int p,
> int m, int gfpoly, int n, int k, int t, int s, int blocks)
> > > > : block("custom_reed_solomon_dec",
> > > > io_signature::make(1, 1, sizeof(unsigned char) * blocks *
> (n - s)),
> > > > io_signature::make2(1, 2, sizeof(unsigned char) * blocks *
> (k - s), sizeof(int) )), // Change to make2 to support outputting
> nerrors_corrected in the general_work() function
> > > > d_n(n), d_k(k), d_s(s), d_blocks(blocks)
> > > > {
> > > > ...
> > > > }
> > > >
> > > >
> > > > On Tue, Jul 23, 2019 at 3:44 PM Alex Roberts
> wrote:
> > > > > Marcus,
> > > > >
> > > > > I think what you said makes sense. I was initially thinking I
> would have a synchronous block with a message port output, but if I can
> keep it as simple as a sync block with two outputs just with different
> sizes, then that is where I will start.
> > > > >
> > > > > Thanks,
> > > > > Alex.
> > > > >
> > > > > On Tue, Jul 23, 2019 at 9:16 AM Müller, Marcus (CEL) <
> muel...@kit.edu> wrote:
> > > > > > Hi Alex,
> > > > > >
> > > > > > to get this straight: on your monitoring output, you get one
> item of
> > > > > > output per item of input? (an input item being a vector, and a
> > > > > > monitoring output item being a number)
> > > > > >
> > > > > > Then, everything is well: The thing is still a sync block, just
> one
> > > > > > where not all output item sizes are identical, and not all are
> > > > > > identical to the input item sizes.
> > > > > >
> > > > > > Even if that's not the case, the right way here would be t
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Hi,
If you are interested in measuring the number of errors in the Reed-Solomon
block of DTV, you may take a look at our OOT module gr-isdbt (
https://github.com/git-artes/gr-isdbt) which includes modifications to the
RS (and the viterbi) decoder to outputs the BER (but is easily modifiable
to output the number of errors).
best
Federico
El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) ()
escribió:
> Hi Alex!
> Hm, interesting. Would you happen to have the full verbatim error?
>
> As a complete aside:
> I know we're not doing any of that consistently in the tree, but
> especially when handling things like polynomials "packed" into
> integers, and amounts of bits, I always recommend people explicitly use
> "unsigned int", or directly go for an explicitly sized integer type,
> e.g. "uint64_t gfpoly" for their polynomial representations, so that
> there's no arithmetic surprises – signed integer overflow, for example,
> is way less well-defined than unsigned.
>
> Best regards,
> Marcus
>
> On Wed, 2019-07-24 at 10:30 -0500, Alex Roberts wrote:
> > So I tried re-implementing the gr-dtv Reed Solomon decoder with an
> additional output so I could monitor/output the number of errors corrected.
> > I used gr-modtool, created new block with new name so it wouldn't
> conflict with the existing and made sure to update the markup language for
> the grc block.
> >
> > I get an error about Number of outputs 1 exceed max 0. I'm not sure why
> that is.
> >
> > Here is my impl declaration with io_signatures.
> >
> > custom_reed_solomon_dec_impl::custom_reed_solomon_dec_impl(int p, int m,
> int gfpoly, int n, int k, int t, int s, int blocks)
> > : block("custom_reed_solomon_dec",
> > io_signature::make(1, 1, sizeof(unsigned char) * blocks * (n -
> s)),
> > io_signature::make2(1, 2, sizeof(unsigned char) * blocks * (k
> - s), sizeof(int) )), // Change to make2 to support outputting
> nerrors_corrected in the general_work() function
> > d_n(n), d_k(k), d_s(s), d_blocks(blocks)
> > {
> > ...
> > }
> >
> >
> > On Tue, Jul 23, 2019 at 3:44 PM Alex Roberts wrote:
> > > Marcus,
> > >
> > > I think what you said makes sense. I was initially thinking I would
> have a synchronous block with a message port output, but if I can keep it
> as simple as a sync block with two outputs just with different sizes, then
> that is where I will start.
> > >
> > > Thanks,
> > > Alex.
> > >
> > > On Tue, Jul 23, 2019 at 9:16 AM Müller, Marcus (CEL)
> wrote:
> > > > Hi Alex,
> > > >
> > > > to get this straight: on your monitoring output, you get one item of
> > > > output per item of input? (an input item being a vector, and a
> > > > monitoring output item being a number)
> > > >
> > > > Then, everything is well: The thing is still a sync block, just one
> > > > where not all output item sizes are identical, and not all are
> > > > identical to the input item sizes.
> > > >
> > > > Even if that's not the case, the right way here would be to write a
> > > > general block with streams, not an asynchronous messaging block,
> since
> > > > the monitoring data is "synchronous" to the other data.
> > > >
> > > > Best regards,
> > > > Marcus
> > > >
> > > > On Tue, 2019-07-23 at 09:10 -0500, Alex Roberts wrote:
> > > > > I'd like to monitor an internal variable on a DSP block. have not
> made a custom block before but have read through some tutorials.
> > > > >
> > > > > Since the DSP inputs and outputs are vectors, and the variable is
> a single item whose value is dependent on the processing of the vector, the
> number of outputs does not match the number of inputs. The value is updated
> after each input vector is processed. Does this mean I should use the
> message port to asynchronously output the variable, or can I simply add
> another port and output the value as say a float or integer that is
> synchronously updated with the block?
> > > > >
> > > > > For example, in a Reed-Solomon implementation, how could I add an
> output to monitor the number of errors corrected?
> > > > > ___
> > > > > 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
[Discuss-gnuradio] ISDB-T transmitter OOT
Hi everyone, I'm very glad to announce that our OOT gr-isdbt now includes the transmitter and may be considered (almost) complete. The repository is at https://github.com/git-artes/gr-isdbt. For those of you who did not know it, we developed gr-isdbt some years ago now (I think 2015 was the year we considered it useful) and it was a receiver-only for ISDB-T (the TVD standard used mostly in south america and Japan). To give a little bit of context, last year two students of ours (Santiago Castro and Javier Hernández) here in the university started to work on the implementation of the transmitter. Their work is still available at their repo (https://github.com/jhernandezbaraibar/gr-isdbt-Tx), although it may be considered deprecated, since over the last few months I've integrated their work into gr-isdbt and significant changes were introduced in the process. For those interested in using it, please note that the transmitter is still WIP. In particular, I have tested it somewhat thoroughly in software and I am confident it works as it should (we have included a full transceiver example in the corresponding directory). I am now seriously testing it in over-the-air transmissions with not-so-satisfactory results. However, I'm leaving for some weeks for holidays, thus the announcement. Feedback is, as usual, more than welcome. best Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: setting parameter for multiple blocks via combo box
Hi, And using a QT GUI Chooser with type "Any" and using its entry to configure the other blocks? best 2018-06-22 6:08 GMT-03:00 Rob Heig : > Thanks for your answer Ron! > Unfortunately no, we plan to play with blocks in the GUI and so no Python > script or C++ code, at least at the beginning... :( > > On 22 June 2018 at 11:04, Ron Economos wrote: > >> I'm not sure if this fits your requirements, but you can use a stand >> alone Python script. Here's an example for the DVB-T transmitter. >> >> https://github.com/drmpeg/dtv-utils/blob/master/dvbt-blade.py >> >> Ron >> >> >> On 06/22/2018 12:55 AM, Rob Heig wrote: >> >>> Hi everybody, >>> >>> I am creating a small design (similar to the DVB-T one included in >>> gnuradio-dtv) and I wanted to set some parameters once (at design and *not* >>> at execution time) with a combo box (to limit the possible choices to valid >>> values only). For instance, if we consider the above mentioned DVB-T >>> design, one might want to set the chosen constellation just once and not >>> for every single block that needs that parameter. Is there an easy way to >>> achieve this result? >>> Thanks a lot in advance and have a nice day! >>> >>> Rob >>> >>> >> >> ___ >> 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] [GSOC 2018] Ideas please!
Hi, Just a quick comment on our status regarding the transmitter for ISDB-T. This semester (i.e. beginning last August) a group of students have started developing it as an end-of-career project (here in Uruguay, the electrical engineering degree ends with a one-year project) under my tutoring. Regarding timing, we should get something that is usable by the beginning of next year (by then, I should also have more free time and be able to get more involved in the project). I'm not sure when GSoC begins, or how to articulate it with the undergrads project, but we'll be glad to receive feedback and/or help. As with gr-isdbt, we will publish the code under GPLv3. Our long-term objective is to donate the complete project to make it part of gr-dtv. In any case, I'm really glad there are so many people interested in the project. best Federico 2017-10-16 3:20 GMT-03:00 Wunsch, Felix (CEL) : > Hi Rafael, > > nice idea! Would you be willing to mentor it? > > I just checked the Github Repo for gr-idsb (https://github.com/git-artes/ > gr-isdbt) and in their README.md it says, they are working on the > transmitter. Are you in contact with the author and can you say if this is > still actively being pursued? If it is, this might actually already be done > by the time GSoC starts. > > Cheers, > Felix > > Von: Discuss-gnuradio kit@gnu.org> im Auftrag von Rafael Diniz > Gesendet: Montag, 16. Oktober 2017 01:59 > An: discuss-gnuradio@gnu.org > Betreff: Re: [Discuss-gnuradio] [GSOC 2018] Ideas please! > > => GNU Radio ISDB-T DTV Transmitter (ARIB STD-B31). > > > > On 10/14/2017 11:56 AM, Benny Alexandar wrote: > > Hi Felix, > > > > I have couple of Ides for GSOC > > > > 1. DRM digital radio receiver on GNU Radio. We have only DRM > > transmitter but no receivers are available. > > DRM is mainly used in Europe, India and in South America. xHE-AAC codec > > has recently made license free > > this will be good to add. > > > > 2. Audio Control block: > > This is to synchronize the audio clock of digital radio receiver with > > transmitter clock. Currently there exits no blocks in GNU radio to > > fully support it. > > > > > > -ben > > > > > > > > > > ___ > > 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] Get error 3 when trying to connect to RTL-SDR
Hi,
I think you've forgotten to blacklist the dvbt driver. In Ubuntu, you have
to add the following line to /etc/modprobe.d/blacklist.conf: blacklist
dvb_usb_rtl28xxu.
best
Federico
2017-09-28 17:11 GMT-03:00 Ed Troy :
> I am trying to run a simple fm receiver example using a RTL-SDR dongle. It
> is connected. But, when I run, I get the following errors:
>
> gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.12git-269-g8aa965c6
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> rfspace airspy soapy redpitaya
> [INFO] [UHDlinux; GNU C++ version 6.3.0 20170406; Boost_106200;
> UHD_3.11.0.git-191-g1cd96dde]
> Using device #0 Generic RTL2832U OEM
> usb_open error -3
> Please fix the device permissions, e.g. by installing the udev rules file
> rtl-sdr.rules
>
> FATAL: Failed to open rtlsdr device.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
>
> So, I did a lsusb command and got the following:
>
> edtroy@ubuntu:/etc/udev/rules.d$ lsusb
> Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> Bus 001 Device 002: ID 0bda:4014 Realtek Semiconductor Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 004: ID 0e0f:0008 VMware, Inc.
> Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
> Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> I'm not sure which is the device that I should use, but I think it is
> Device 004. So, I wrote a file named rtlsdr.rules that I put in the
> directory/etc/udev/rules.d/ . That file consists of the following:
>
> SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",
> GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"
>
> But, when I try to run the example, I still get the above error. Any ideas
> what I am doing wrong and need to do to get RTLSDR dongle to work?
>
>
> Ed
>
>
> ___
> 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] [SOCIS '17] GRC C++ Output: Week 8
Hi, so your idea is to use GNU Radio Companion to design blocks that internally > has a loopback? > Actually, my idea was to use the companion to design blocks in c++. They may have loops or not. > That would kind of break the semantics of GRC being a tool for designing > GNU Raio flow graphs > You are very right on this "confusion" issue, of which I haven't thought. > , but I'd still be open to that idea, if you could explain in which way > that would differ from it simply being a unified "control loop" block that > only is parameterizable (in which case you wouldn't benefit from the > graphical representation of it being multiple blocks with feedback, because > it's not what's happening, more confusing than clarifying). > So, I don't really think that we can find a sufficiently general approach > here that would justify letting users do something that GNU Radio itself > can't. I'd much rather fix the scheduler than spend time on emulating a fix > by having restricted feedback ability that only allows a very limited set > of blocks to work in the feedback branch. > > What do you think? > I'm not sure what you mean by "unified control loop", but after some thought I agree with your last comment. So, let me know how we can contribute to making loops possible in the scheduler. Not sure how much manpower we may get though, specially in the middle of the semester, but we'll do our best. Best Federico > Best regards, > > Marcus > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8
Hi Marcus, Me and my team would be glad to help. I am aware that block interconnection depends on the scheduler, which forbids loops. However, my idea was not as ambitious as modifying the whole scheduler, but customizing the companion to generate the c++ code of a block, and thus my question (a sort of hier block, in terms of the companion, but written directly on c++, without interconnecting blocks, i.e. it would automatically generate the work() function, etc.). This would of course be much less powerful than allowing loops on a flowgraph, and only certain operations would be allowed (those for which a c++ function exists). But it would allow to program relatively simple but useful blocks, including loops, with all the simplicity of the companion. What do you think? best Federico 2017-09-18 19:52 GMT-03:00 Marcus Müller : > Hi Federico, > > Loops in the Flowgraph are currently forbidden by GNU Radio itself, not by > the GRC designer. > > So, no, this is not scope of Hakon's project. If you want to contribute to > having that feature in a generally useful manner, we can certainly chat > about how you can improve the scheduler to make that possible. > > Best regards, > > Marcus > > On 09/18/2017 03:44 PM, Federico 'Larroca' La Rocca wrote: > > Hi, > Outputting c++ from the companion would be a great addition to GNU Radio. > A small question: the possibility of having loops on the flowgraph is > contemplated on this project? We've been using GNU Radio for teaching for > some years now (highschool, undergraduate and graduate students), and such > feature would be very useful and illustrative. For instance, when using a > PLL, we have to resort to feedforward schemes or using the blocks already > part of GNU Radio, but as a black box of sorts. Coding in c++ would be > asking too much from students in a course where the focus is on > communications, whereas the companion is simply perfect in terms of > intuitiveness and ease of use. > best > Federico > > 2017-09-18 6:10 GMT-03:00 Håkon Vågsether : > >> Hi all, >> >> The focus for this week has been the QT blocks. You can read more at: >> >> https://grccpp.wordpress.com >> >> Best regards, >> Håkon Vågsether >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://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] [SOCIS '17] GRC C++ Output: Week 8
Hi, Outputting c++ from the companion would be a great addition to GNU Radio. A small question: the possibility of having loops on the flowgraph is contemplated on this project? We've been using GNU Radio for teaching for some years now (highschool, undergraduate and graduate students), and such feature would be very useful and illustrative. For instance, when using a PLL, we have to resort to feedforward schemes or using the blocks already part of GNU Radio, but as a black box of sorts. Coding in c++ would be asking too much from students in a course where the focus is on communications, whereas the companion is simply perfect in terms of intuitiveness and ease of use. best Federico 2017-09-18 6:10 GMT-03:00 Håkon Vågsether : > Hi all, > > The focus for this week has been the QT blocks. You can read more at: > > https://grccpp.wordpress.com > > Best regards, > Håkon Vågsether > > ___ > 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] [GSoC 17] DAB: Updates
Hi, As you may know, we've developed gr-isdbt a couple of years ago now. We are still maintaining it, and I'm happy to announce that we've finally found time to start working on the transmitter. My expectation is that we'll have something usable by the end of this year, beginning next. best Federico 2017-08-23 23:06 GMT-03:00 Rafael Diniz : > Hi Marcus, > > Concerning DRM here in Brazil, there is not much activity because of the > immense delay from the government to adopt any standard. Me and a bunch > of hams are carrying some trials with DRM in HF, but just this (from > Parque do Rodeador, an EBC facility). But DRM signals are always on... > in Europe you can hear quite a lot DRM signals in HF. > > But changing a bit the topic, one much more relevant piece of software > would be an ISDB-T transmitter for social / community use. There are > really a lot a community TV broadcasters in Argentina and Brazil (may be > in other LA countries also) which would love to power up a gnuradio app > with USRP and have a DTV exciter running. The Antena Negra TV[1] example > in Buenos Aires in very cool. > ; ) > > Rafael Diniz > > [1] http://antenanegratv.com.ar/ > > > On 08/18/2017 12:58 PM, Marcus Müller wrote: > > Hi Rafael, > > > > I don't really see how these are a real problem – if you'd need another > > encoder, just drop one in – shouldn't be that hard to code if you know > > which encoder you'll want to use. Of course, you'd need to adjust some > > bit flags in the flow – but that shouldn't be that hard. So, it's kind > > of hard to imagine that filling a whole GSoC project – BUT!!!: such > > ideas are a great base for GSoC projects, and we should, this time, > > COLLECT SUCH IDEAS EARLY. (I'm not one to lightly wield the power of > > capslock). So, head over to [1] and write that down - if possible with > > your name, so that in half a year we still remember who to bring > > together to make this happen. > > > > What I do read from your email is that there's an inherent demand for a > > specific, non-LC, multi-service input from a community in Brazil – and > > that's pretty awesome!!! Felix and I haven't heard from all that many > > users, and it's rare that one hears from people who seem to actively use > > it aside from testing their own DRM receivers and such. Personally, > > whoever builds receivers should probably shovel over some money to the > > authors if they need improvements to use it manufacturing, but an active > > community of people planning to use it in broadcast/communication///is > > something the gr-drm project should foster/. And: discussing this here > > will definitely enhance the chances of the people with the right skills, > > and the right amount of spare time, find the people with the right > > ideas, and the right use case. For example, you *really cannot buy* DRM > > receivers in Germany, I don't even know if any services exist in Europe. > > So it's kinda hard to guess what people use and not use in the real > world :) > > > > So, this might be a bit of a general appeal to be like Rafael: > > > > If anyone uses GNU Radio and/or some OOT Modules in any application in > > this world, and they encounter wishes, please /do/ come to the > > discuss-gnuradio maling list and — discuss GNU Radio! > > > > I personally had a lot of fun over the years reading about cool > > applications of SDR technology, discussing them, helping users and devs > > where my limited experience allows and seeing people work together. As a > > recent example of that, I remember there was a receiver for endangered > > wildlife transponders that people discussed the design of the sync and > > whatnot. Was great fun! People were helped. (wonder what has come of > > that...) > > > > So, thanks! > > > > Marcus > > > > [1] https://wiki.gnuradio.org/index.php/GSoCIdeas ; make a new heading > > "Summer of Code 2018: Project idea list"; we'll sort the current ones to > > "old ideas" later on. > > > > On 08/18/2017 04:23 PM, Rafael Diniz wrote: > >> gr-drm is working fine, but there are some limitations (one audio > >> service only - MDI input support would fix this, only faac AAC LC > >> encoder, ...), and as far as I know, there are no open source ISDB-T > >> transmitter implementation. GSoC always help. > >> > >> Rafael Diniz > >> > >> On 08/18/2017 11:03 AM, Martin Braun wrote: > >>> On 08/18/2017 08:56 AM, Rafael Diniz wrote: > I wonder when we'll have a DRM app like this one. At least the mux and > codec part are very similar could be shared with DAB. May be next > GSoC? > DRM and ISDB-T are the major wishes here from Brazil. > ; ) > >>> I'm sure Luca and Felix would happily accept patches. > >>> > >>> -- M > >>> > >>> ___ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> > >> > >> > >> ___ > >> Discuss-gnuradio mailing lis
Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI
Hi, Nice problem you got there. In any case, have you considered performing matched filtering (thus maximizing SNR), outputting more than one sample per symbol (in fact, without decimation at all), then equalize (so that the signal looks as if it was sent and received with a squared-root Nyquist pulse) and after all that use a standard clock recovery block? Since you know the shaping pulse, and as long as it does not go to zero over the range of frequencies of interest, you should be able to transform it into a Nyquist pulse. I may be wrong, but in any case Viterbi decoding for symbols will be difficult, so this may be worth trying. best Federico 2017-06-15 9:57 GMT-03:00 Phil Frost : > I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK > where the pulses are a raised cosine (impulse, not frequency domain) twice > the symbol duration[2], no error correction, at 31.25 baud. The transmitted > signal has no ISI, but after matched filtering it does: > > [image: 0SDEq.png] > > I had hoped to do matched filtering and compensate ISI with a Viterbi > equalizer, but I'm unsure how to do clock recovery. > > I hoped to use the polyphase clock recovery block, but it seems this won't > work since the derivative of the signal may not be zero at the ideal > sampling points. Is that an accurate assessment? > > [image: 2017-06-15-083544_393x230_scrot.png] > > Perhaps the clock recovery MM block? The zero crossings aren't exactly in > the middle of the ideal sampling points, but the error is probably > negligible. I can't get it to work: I think it outputs the correct bits, > but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1 > depending on the adjacent bits. I'm using the default settings. Is that the > intended behavior? > > [image: 2017-06-15-084108_1038x201_scrot.png] > [image: 2017-06-15-084340_475x253_scrot.png] > > Finally, any other algorithms I should be considering? > > [1]: http://bipt106.bi.ehu.es/psk31.html > [2]: https://ham.stackexchange.com/a/7744/218 > > ___ > 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] Clock recovery without change of phase
Hi, I'm not sure if I understood correctly your question, but clock recovery (such as MM or Polyphase clock sync) takes the incoming signal and by default outputs a sample every $T_s$ seconds (symbol time) but at the point where the eye is widest (and thus it interpolates as needed). Once it converges, the block's output phase should be stable (I mean, the phase will probably still vary but it will be due to the remaining frequency error between transmission and reception, which should be taken care of by a Costas Loop or similar, but it is not generated by the clock synchronization block). best Federico 2017-06-14 7:26 GMT-03:00 George Vardakis : > Hi all, > > I need to perform clock recovery on a signal without constantly changing > its phase. I think that the clock recovery block in Gnuradio does exactly > that in order to maximize the energy of the signal. Is there any other way > that does not tamper with the signal phase? > > Thanks! > > ___ > 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] OOT: General type block changing parameter with WX GUI slider
Hi, In any case, if you use WX or QT, you will have to create some setters methods in order to set these parameters on-line from a slider. I've personally never implemented those, but you should take a look at the code generated by any flowgraph that does. For instance, create a new flowgraph with a delay which you change from a slider, and check how it works. It should be *rather* straightforward. best Federico 2017-06-09 10:57 GMT-03:00 Marcus Müller : > Please don't use WX Gui widgets for new designs. We're deprecating them, > and they are NOT part of the oncoming GNU Radio 3.8 release. Use Qt > instead. We simply have no-one to maintain the WX GUI elements, and thus, > it'll be very hard to help you with WX issues. > > Best regards, > > Marcus > > On 09.06.2017 10:19, Ali wrote: > > Hi to all, > > I created a module and its type is general. It has 6 inputs and 2 outputs. > Also, there are 2 parameters. I noticed that I cannot change these > parameters while the GRC is running(I am using WX GUI Slider). Actually, I > can change them but my block uses the default value of WX GUI slider box. > > In .cc file under the place where we define number of input/ouput ports, I > declare them as > > parameter1(p1), > parameter2(p2) > > Then in the .h file, under the private, I declare them as > > float parameter1; > float parameter2; > > What might be the problem? > > Best regards, > Ali > > > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://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] frequency shift with multiplier.... something seems to work wrong
Hi Fernando, You are assuming that the signal you are getting at the receiver is not delayed with respect to the one being sent. You are thus using a cosine signal source with no phase correction. This is not true, since you are using filters, which always delay samples (moreover, you should make sure that both the LPF and the BPF have the same group delay, mostly by using the same transition width). You are thus getting cross-talk between both channels. You may experiment by manually correcting the phase of the signal source, or by using a PLL (see the WBFM implementation on GNU Radio or gqrx). best Federico 2017-04-23 18:47 GMT-03:00 Fernando : > I'm working on a stereo FM modulator/demodulator, buth channels get mixed, > so I'm doing some test and I have found taht this diagram (faulty.grc.png) > does not work well. The output of the adder seems fine > > > Pilot at 19Khz, lower part of the spectrum with tones at 1Khz and 12Khz, > and upper part with tones at 38K+-1K and 38K+-12K (as is a power spectrum > signs are not show) > > But signals R and L show both 1K + 12K tones insted of just 1K tone in one > of then and one 12K tone in the other. > > > I have been testing part of the diagram apart one of the other and I have > found that if I only do the add+substract part It work well > > And if I only do the add+frequency displacement It work well too so > I'm puzzled. > > Any ideas please? > > > regards > > > > > ___ > 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] Faster Viterbi decoder
Hi, For a while now (and very slowly BTW) I've been trying to optimize gr-isdbt's performance. In particular, and naturally, the most serious bottleneck is the Viterbi decoder. So far, we've used gr-dvbt's implementation (now part of gr-dtv) which runs online on a i7, but consumes 100% of a processor on an i5, and so after a while we get samples dropped from the hardware. It is my understanding that this particular implementation is based on code by Phil Karn back from 1995. I've looked around and found that Phil Karn has updated its original code until 2007, and in particular its Viterbi decoder until 2004. It may be found in http://www.ka9q.net/code/fec/. I was wondering if it was worthwhile (in terms of speed) to try to adapt the newer code to the viterbi decoder. In particular, I found the following line in viterbi27_sse2.c: /* This code is turned off because it's slower than my hand-crafted assembler in sse2bfly27.s. But it does work. */ and then a function very similar to d_viterbi_butterfly_sse2 follows. Furthermore, it also includes an MMX and AV implementations. Maybe someone has experience with this newer implementation and its performance compared to the one included in gr-dtv (or its older implementation). best Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Impulse response in DVB-T, someboby knows how to calculate?
Hi,
If you want the channel impulse response you may simply perform an IFFT on
the channel frequency response estimated by the equalizer of gr-dtv/dvbt
(don't forget to "shift" it, so that it starts at 0 and ends at 2\pi). I
think this is performed by the block "Demod Reference Signals", but it does
not output the estimated channel. However, modifications should be
relatively simple once you dig a little bit into the code and understand
what you are looking for. You may look at the corresponding blocks at
gr-isdbt ("Sync and Channel Estimation") to look for ideas on how to
achieve this.
best
Federico
2016-10-02 20:03 GMT-03:00 Tom Rondeau :
> On Sun, Oct 2, 2016 at 2:40 PM, Cinaed Simson
> wrote:
>
>> On 10/01/2016 04:46 PM, Juan Antonio wrote:
>> > Hello, someone would know how to calculate the impulse response of a
>> > COFDM, DVB-T channel with an SDR device?
>> >
>> > Thank you in advance
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>> An inverse DFT on a sinc function in the frequency domain yields a sine
>> function in the time domain. And a DFT on the sine function in the time
>> domain yields a sinc function in the frequency domain.
>>
>
>
> No, the DFT of a sine function is an impulse. More formally, a Dirac delta
> function.
>
> The sinc function is the result of a truncated sine wave where the sine
> wave is multiplied by a square wave. The DFT of a square wave is a sinc, so
> with a truncated sine wave in the time domain, you are convolving a sinc
> with a delta function in the frequency domain.
>
> Tom
>
>
>
>> I presume the "C" in COFDM means to chop up the bandwidth into carriers
>> such that the sinc function in one channel hits nulls in the other
>> channels.
>>
>> Piece of cake in theory.
>>
>> There's a gr-dvbt project on github
>>
>> https://github.com/BogdanDIA/gr-dvbt
>>
>> I don't know anything about it - I don't even know if it works.
>>
>> -- Cinaed
>>
>
> ___
> 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] Bug/Issue with "build-gnuradio" script
I send my reply again, but for the whole list this time... Hi Duane, Something like [0] does not work for you? In our university we are also behind a proxy, and this config worked fine for build-gnuradio (and everything git-related BTW). best Federico [0] http://stackoverflow.com/questions/783811/getting-git- to-work-with-a-proxy-server 2016-09-30 13:55 GMT-03:00 Ellis, Duane : > Hi, > > I'd like to report an issue with the script: build-gnuradio - and a few > of the other git sub-modules. > > Problem statement #1 > I'm behind a proxy that effectively "blocks" the GIT protocol - I > can clone via HTTP, or HTTPS - but not via git:// > > Possible work arounds: > I know about the "instead-of" feature for GIT ... but that does > not always work > Why? Because sometimes you must adjust the rest of the URL slightly > Yes, I put a very specific rule in for specifically this URL... > but ... Ugh... > Also I would suggest/think that a "noob" would trip and stumble > over this and not figure it out. > > Suggested fix: > Convert the scripts, and submodules to reference/use http or https > for cloning. > My belief is proxies work better with http requests. > > In my case, I modified the build script to use http *and* had to adjust > one of the urls to match > > Thanks. > > ___ > 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] VOLK division between complexes
Hello again,
Thank you Marcus por looking through my code (and the positive comments).
I have several things to report:
- Pulling from your repo and using volk_32fc_x2_divide_32fc worked
perfectly, and gr-isdbt kept operating as usual.
- Substituting yours with my AVX proto-kernel (plus the aligned version)
works too.
- Regarding performance, they are almost indistinguishable, at least in my
PC: running volk_profile they are roughly 10x faster than the generic
implementation, and Performance Monitor does not show any real difference
between both implementations (here I used the complete receiving chain).
- The performance gain (again, measured by using Performance Monitor with
the complete receiving chain) between using the four lines of code I sent
before, and the divide kernel is mostly null.
So, to conclude, maybe the performance gain of using a kernel instead of
four lines of code is not significant, but I believe it's both simpler to
use and easier to read (and performance should be further tested in other
setups to actually conclude the former). Regarding the implementations,
both implementations of the AVX kernel are, from my unexperienced
perspective, mostly identical (maybe mine is a little bit simpler to read,
but it was me who wrote it, so I'm no judge). I've seen you already made a
pull request to add it to gnuradio, so my opinion is to use yours (but feel
free to use/test mine if you prefer).
In any case, this was a very interesting and formative experience.
best
Federico
2016-05-15 6:06 GMT-03:00 Marcus Müller :
> Hi Federico
>
> On 15.05.2016 02:40, Federico Larroca wrote:
> > That was fast!
> Only ten times as fast as the generic, pure C implementation, but thank
> you :)
> > Thank you very much!
> You're welcome :)
> > I don't have access to my computer for the weekend, but I'll check it
> > as soon as I get back to the University on tuesday (monday's holiday
> > here).
> > In any case, I got to halfway implementing the AVX kernel, which I
> > copy below just for the record... I didn't even got to compile it, let
> > alone test it, but I surely learned a lot.
> Yeah, it was my first kernel, too :) Learned a lot!
> > static inline void
> > volk_32fc_x2_divide_32fc_u_avx(lv_32fc_t* cVector, const lv_32fc_t*
> > aVector,
> >const lv_32fc_t* bVector,
> > unsigned int num_points)
> > {
> > unsigned int number = 0;
> > const unsigned int quarterPoints = num_points / 4;
> >
> > __m256 x, y, z, sq, mag_sq, mag_sq_un, div;
> > lv_32fc_t* c = cVector;
> > const lv_32fc_t* a = aVector;
> > const lv_32fc_t* b = bVector;
> >
> > for(; number < quarterPoints; number++){
> > x = _mm256_loadu_ps((float*) a); // Load the ar + ai, br + bi ...
> > as ar,ai,br,bi ...
> > y = _mm256_loadu_ps((float*) b); // Load the cr + ci, dr + di ...
> > as cr,ci,dr,di ...
> > z = _mm256_complexconjugatemul_ps(x, y);
> > sq = _mm256_mul_ps(y, y); // Square the values
> > mag_sq_un = _mm256_hadd_ps(w,w); // obtain the actual squared
> > magnitude, although out of order
> you mean ... _hadd_ps(sq,sq), right?
> > mag_sq = _mm256_permute_ps(mag_sq_un, 0xd8) // I order it
> ah, clever move! Very clever indeed!
> What you do is get four complex values at once, then calculate a b*,
> then calculate
> |b0|² |b1|² |b2|² |b3|² |b0|² |b1|² |b2|² |b3|²
> and then reorder it in memory to be
> |b0|² |b0|² |b1|² |b1|² |b2|² |b2|² |b3|² |b3|²
> right? (still haven't gotten around being able to read the
> shuffle/permute masks, and a bit too lazy to do so, now).
>
>
> > div = _mm256_div_ps(z,mag_sq);
> >
> > _mm256_storeu_ps((float*) c, div); // Store the results back into
> > the C container
> >
> > a += 4;
> > b += 4;
> > c += 4;
> > }
> >
> > (I got this far ).
> Looks pretty solid to me!
>
> So the difference between my and your AVX kernel is that my kernel loads
> a total of eight a,b complexes at once, basically because the
> _mm256_mul/_mm256_hadd step can produce eight |b|² at once – and then I
> really struggled (but managed) to have each of these |b|² twice, so I
> can do the two _mm256_div. Your approach is so much cleverer, because it
> uses less registers, and less obscure shuffling.
>
> My AVX kernel, on my machine, is about as fast as my SSE3 kernel. So I'd
> really like to ask you to try mine, and then just replace my AVX code
> with yours, and compare the results. I think yours might be
> significantly faster!
>
> Best regards,
> Marcus
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VOLK division between complexes
That was fast! Thank you very much! I don't have access to my computer for
the weekend, but I'll check it as soon as I get back to the University on
tuesday (monday's holiday here).
In any case, I got to halfway implementing the AVX kernel, which I copy
below just for the record... I didn't even got to compile it, let alone
test it, but I surely learned a lot.
Best
Federico
static inline void
volk_32fc_x2_divide_32fc_u_avx(lv_32fc_t* cVector, const lv_32fc_t* aVector,
const lv_32fc_t* bVector,
unsigned int num_points)
{
unsigned int number = 0;
const unsigned int quarterPoints = num_points / 4;
__m256 x, y, z, sq, mag_sq, mag_sq_un, div;
lv_32fc_t* c = cVector;
const lv_32fc_t* a = aVector;
const lv_32fc_t* b = bVector;
for(; number < quarterPoints; number++){
x = _mm256_loadu_ps((float*) a); // Load the ar + ai, br + bi ... as
ar,ai,br,bi ...
y = _mm256_loadu_ps((float*) b); // Load the cr + ci, dr + di ... as
cr,ci,dr,di ...
z = _mm256_complexconjugatemul_ps(x, y);
sq = _mm256_mul_ps(y, y); // Square the values
mag_sq_un = _mm256_hadd_ps(w,w); // obtain the actual squared
magnitude, although out of order
mag_sq = _mm256_permute_ps(mag_sq_un, 0xd8) // I order it
div = _mm256_div_ps(z,mag_sq);
_mm256_storeu_ps((float*) c, div); // Store the results back into the C
container
a += 4;
b += 4;
c += 4;
}
(I got this far ).
2016-05-14 14:47 GMT-03:00 Marcus Müller :
> Hi Federico,
>
> could you have a look at this branch [1] and tell me whether it works for
> you? It's SSE3 and AVX only, so far.
> Basically, you could
>
> cd /path/to/source/gnuradio/volk
> git pull https://github.com/marcusmueller/volk complex_division
> cd ../build
> make
> make install
>
> and use volk_32fc_x2_divide_32fc in your code.
>
> Best regards,
> Marcus
>
> [1] https://github.com/marcusmueller/volk/tree/complex_division
>
>
> On 11.05.2016 23:56, Federico Larroca wrote:
>
> Thank you very much for your quick answers!
> Marcus (Leech), I found the function you mentioned minutes after I sent
> the mail. Although it apparently works, Performance Monitor is behaving
> really weird when I use it. I have to look up that.
> Marcus (Müller), a very informative answer indeed. I will see if I can get
> that endless fame you mention :-).
> In any case, I'll post what I finally did and the performance gain
> achieved.
> Best
> Federico
>
>
> 2016-05-11 17:47 GMT-03:00 Marcus Müller :
>
>> Hi Federico,
>>
>>
>> On 11.05.2016 21:09, Federico Larroca wrote:
>>
>> Hello everyone,
>> We are on the stage of optimizing our project (gr-isdbt).
>>
>> Awesome!
>>
>> One of the most consuming blocks is OFDM synchronization, and in
>> particular the equalization phase. This is simply the division between the
>> input signal and the estimated channel gains (two modestly big arrays of
>> ~5000 complexes for each OFDM symbol).
>> Until now, this was performed by a for loop, so my plan was to change it
>> for a volk function. However, there is no complex division in VOLK. So I've
>> done a rather indirect operation using the property that a/b =
>> a*conj(b)/|b|^2, resulting in six lines of code (a multiply conjugate, a
>> magnitude squared, a deinterleave, a couple of float divisions and an
>> interleave). Obviously the performance gain (measured with the Performance
>> Monitor) is marginal (to be optimistic)...
>>
>> I have to admit, I'd expect your "simple" for loop doing something like
>>
>> void yourclass::normalize(std::complex *a, std::complex *b) {
>> for(size_t idx; idx < a_len; ++idx)
>>a[idx] /= b[idx];
>> }
>>
>>
>> to be neatly optimizable by the compiler, at least if it knows that a and
>> b aren't pointing at the same memory-
>>
>> Your approach,
>> [image: $\frac ab = a \cdot \frac{b^*}{|b|^2}= a \cdot \frac{b^*}{b\,b^*}
>> = a \cdot \frac 1b$]
>> is correct; however, in C++ with std::complex<>
>>
>> a/b
>>
>> pretty much does that already (ugly std lib C++ ahead, from
>> /usr/include/c++//complex):
>>
>> // XXX: This is a grammar school implementation.
>> template
>> template
>> complex<_Tp>&
>> complex<_Tp>::operator/=(const complex<_Up>& __z)
>> {
>> const _Tp __r = _M_real * __z.real() + _M_imag * __z.imag();
>> const _Tp __n = std::norm(__z);
>> _M_imag = (_M_imag * __z.real() - _M_real * __z.imag()) / __n;
>> _M_real = __r / __n;
>> return *this;
>&
Re: [Discuss-gnuradio] VOLK division between complexes
Thank you Andy. However, I only need the division, although this is indeed a good idea if more operations were needed. So far, I've applied the following lines with some significant savings (w.r.t. a loop): volk_32fc_x2_multiply_conjugate_32fc(&c[0], &a[0], &b[0], N); // c = a*conj(b) volk_32fc_magnitude_squared_32f(&mag_sq_b[0], &b[0], N); // mag_sq_b = |b|^2 volk_32f_x2_divide_32f(&inv_mag_sq_b[0], &ones[0], &mag_sq_b[0], N); // inv_mag_sq_b = 1/|b|^2, since I've previously defined ones as an array containing N ones. volk_32fc_32f_multiply_32fc(&out[0], &c[0], &inv_mag_sq_b[0], N); // out = c*inv_mag_sq_b = a*conj(b)/|b|^2 = a/b The idea of using VOLK's pow operator is significantly slower. I've also experienced interesting performance improvements by simplifying some for loops not amenable to VOLK, as suggested by Marcus. On the other hand, I'm crazy enough to try to implement a VOLK kernel that performs the division. I've just started, don't know if I'll be successful, but guess I'll learn something anyhow. best Federico 2016-05-13 15:14 GMT-03:00 Andy Walls : > On Thu, 2016-05-12 at 16:24 -0400, discuss-gnuradio-requ...@gnu.org > wrote: > > Date: Wed, 11 May 2016 16:09:56 -0300 > > From: Federico Larroca > > To: discuss-gnuradio@gnu.org > > Subject: [Discuss-gnuradio] VOLK division between complexes > > > Hello everyone, > > We are on the stage of optimizing our project (gr-isdbt). One of the > > most consuming blocks is OFDM synchronization, and in particular the > > equalization phase. This is simply the division between the input > > signal and the estimated channel gains (two modestly big arrays of > > ~5000 complexes for each OFDM symbol). > > Until now, this was performed by a for loop, so my plan was to change > > it for a volk function. However, there is no complex division in VOLK. > > So I've done a rather indirect operation using the property that a/b = > > a*conj(b)/|b|^2, resulting in six lines of code (a multiply conjugate, > > a magnitude squared, a deinterleave, a couple of float divisions and > > an interleave). Obviously the performance gain (measured with the > > Performance Monitor) is marginal (to be optimistic)... > > Does anyone has a better idea? > > I have a different idea, but I doubt it is better. The transformation > > w = Log (z) = ln|z| + jArg(z) > > transforms multiplication, division, power and root operations into > addition, subtraction, multiplication and division operations > respectively. > > So if c = Log(a), d = Log(b), then a/b = Exp(c-d) . > > If along with your complex division, you also have a lot of additional > complex multiplcation, power, and/or (real) root operations to perform, > then the transform *might* give you a savings. A savings would also be > more likely, if you don't need to invert the transformation at the end > (i.e. no need for z = Exp(w)). > > Regards, > Andy > > > Implementing a new kernel is simply out of my knowledge scope. > > Best > > Federico > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VOLK division between complexes
Thank you very much for your quick answers!
Marcus (Leech), I found the function you mentioned minutes after I sent the
mail. Although it apparently works, Performance Monitor is behaving really
weird when I use it. I have to look up that.
Marcus (Müller), a very informative answer indeed. I will see if I can get
that endless fame you mention :-).
In any case, I'll post what I finally did and the performance gain
achieved.
Best
Federico
2016-05-11 17:47 GMT-03:00 Marcus Müller :
> Hi Federico,
>
>
> On 11.05.2016 21:09, Federico Larroca wrote:
>
> Hello everyone,
> We are on the stage of optimizing our project (gr-isdbt).
>
> Awesome!
>
> One of the most consuming blocks is OFDM synchronization, and in
> particular the equalization phase. This is simply the division between the
> input signal and the estimated channel gains (two modestly big arrays of
> ~5000 complexes for each OFDM symbol).
> Until now, this was performed by a for loop, so my plan was to change it
> for a volk function. However, there is no complex division in VOLK. So I've
> done a rather indirect operation using the property that a/b =
> a*conj(b)/|b|^2, resulting in six lines of code (a multiply conjugate, a
> magnitude squared, a deinterleave, a couple of float divisions and an
> interleave). Obviously the performance gain (measured with the Performance
> Monitor) is marginal (to be optimistic)...
>
> I have to admit, I'd expect your "simple" for loop doing something like
>
> void yourclass::normalize(std::complex *a, std::complex *b) {
> for(size_t idx; idx < a_len; ++idx)
>a[idx] /= b[idx];
> }
>
>
> to be neatly optimizable by the compiler, at least if it knows that a and
> b aren't pointing at the same memory-
>
> Your approach,
> [image: $\frac ab = a \cdot \frac{b^*}{|b|^2}= a \cdot \frac{b^*}{b\,b^*}
> = a \cdot \frac 1b$]
> is correct; however, in C++ with std::complex<>
>
> a/b
>
> pretty much does that already (ugly std lib C++ ahead, from
> /usr/include/c++//complex):
>
> // XXX: This is a grammar school implementation.
> template
> template
> complex<_Tp>&
> complex<_Tp>::operator/=(const complex<_Up>& __z)
> {
> const _Tp __r = _M_real * __z.real() + _M_imag * __z.imag();
> const _Tp __n = std::norm(__z);
> _M_imag = (_M_imag * __z.real() - _M_real * __z.imag()) / __n;
> _M_real = __r / __n;
> return *this;
> }
>
> And the problem is that while doing that for every a and b separately
> might mean you can't make full use of SIMD instructions to eg. do four
> complex divisions at once, it avoids having to load and store original /
> intermediate values from/to RAM. Basically, your CPU might not be the
> bottleneck – RAM could be, and doing everything you need for a single
> division at once, even if done without any optimization, might be faster
> than incurring additional memory transfers. That's because your memory
> controller pre-fetches whole cache lines worth of values when getting the
> first elements of a and b, and working on values from cache is
> significantly (read: factor > 50) than a single memory transfer.
>
> So, my immediate recommendation really is to keep your loop as minimal as
> possible, giving your compiler a solid chance to see the potential for
> optimization. There might not be much you can do. Even hand-written VOLK
> kernels aren't always faster than automatically generated optimized machine
> code.
>
> Does anyone has a better idea? Implementing a new kernel is simply out of
> my knowledge scope.
>
> Ha! But it would mean endless (additional) fame!
> S: look at the volk_32fc_x2_multiply_conjugate_32fc.h kernel source.
> Specifically, at the SSE3 implementation,
> volk_32fc_x2_multiply_conjugate_32fc_u_sse3(…).
> You'll notice line 134:
>
> z = _mm_complexconjugatemul_ps(x, y);
>
>
> As you can see, there's a a "VOLK intrinsic",
>
> _mm_complexconjugatemul_ps
>
> which is defined in volk_intrinsics.h. That same file contains
> _mm_magnitudesquared_ps_sse3 . Maybe you can make something clever out of
> that :)
>
> Best regards,
> Marcus
>
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html
>
> ___
> 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] VOLK division between complexes
Hello everyone, We are on the stage of optimizing our project (gr-isdbt). One of the most consuming blocks is OFDM synchronization, and in particular the equalization phase. This is simply the division between the input signal and the estimated channel gains (two modestly big arrays of ~5000 complexes for each OFDM symbol). Until now, this was performed by a for loop, so my plan was to change it for a volk function. However, there is no complex division in VOLK. So I've done a rather indirect operation using the property that a/b = a*conj(b)/|b|^2, resulting in six lines of code (a multiply conjugate, a magnitude squared, a deinterleave, a couple of float divisions and an interleave). Obviously the performance gain (measured with the Performance Monitor) is marginal (to be optimistic)... Does anyone has a better idea? Implementing a new kernel is simply out of my knowledge scope. Best Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling Documentation with an OOT
Hello Richard, Some months ago we stumbled upon the same problem (see https://lists.gnu.org/archive/html/discuss-gnuradio/2015-07/msg00227.html). Maybe our solution works for you, although a definite solution would be a good idea (ours was based on simple trial-and-error given our null knowledge on cmake). I've quickly checked the git repository of gnuradio and I believe the problem is still there. best Federico 2016-03-30 17:54 GMT-03:00 Richard Bell : > I've asked this question a few times now on the mailing list, and each > time I hope a different answer comes through. Each time though it's the > answer Ron gave, which never works for me. I can't figure it out. So I've > always resorted to the xml tags to get documentation into GRC, but for the > reasons Tom just mentioned, would rather not do that. Hoping someday I > figure this out. > > Rich > > On Wed, Mar 30, 2016 at 7:50 AM, Tom Rondeau wrote: > >> >> >> On Mon, Mar 28, 2016 at 9:25 PM, Tom McDermott >> wrote: >> >>> Hi Richard - >>> >>> When you say 'propagate through to GRC' do you mean 'How to display on >>> the GRC documentation tab in the open block properties window'? (select >>> block, double-click, or rt-click-properties). >>> >>> I do that by putting text between: >>> >>> >>> in the module's XML file (manually pasted text, with some characters not >>> allowed...). >>> >>> -- Tom, N5EG >>> >> >> >> I would recommend against using the tags in the GRC XML files. >> You're just duplicating text, so if anything is ever updated, you now need >> to remember to update it in two places. >> >> As Ron Economos showed in his response, exporting from his public .h >> files works fine. >> >> This might be a question for Sebastian, who I think has gone through a >> couple of iterations of grabbing those docs strings into GRC. >> >> Tom >> >> >> >> >>> On Mon, Mar 28, 2016 at 5:30 PM, Richard Bell >>> wrote: >>> Hi all, I would like to know how I get the comments I add to my public header function to propagate through to the GRC Block documentation tab. Is there a flag I have to add when I compile the OOT? Thanks, Rich >>> >> >> ___ >> 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] DVB-T Reception Problem
Hi, To complement Ron's answer, when working with a recording, there is no need to use the stream to vector -> vector to stream "trick" (at least in my experience). It should be used when making the recording instead. Regarding your recording in particular, how did you obtain it? Are you sure no samples were dropped by the USRP (i.e. no "O"s were displayed on the console) when it was obtained? That could explain the "restart!" messages you're getting. best Federico 2015-12-17 10:59 GMT-03:00 Ron Economos : > It looks like it's doing a little better. I would try deleting (or > bypassing) that Multiply Const block. It may actually be causing trouble > for the gr-isdbt OFDM acquisition block. > > If you do get things running, the viterbi_decoder block needs to be set to > Code rate 2/3. > > Ron > > > On 12/17/2015 05:44 AM, ahsan@studium.fau.de wrote: > >> Thank you all for reply. Ron I have now used cyclic prefix length of 2048 >> and still no progress. For you I have attached a complete picture of my >> flowgraph. I only have a dual core processor and 4GB of ram so I used >> vector to stream in my flowgraph. The samples were recorded using a usrp >> b210 so I do not need a rational resampler. There is still no >> synchronization with any of the synchronization blocks.Can you see now >> where the problem is? Or may be if you can upload somewhere a sample dvb-t >> signal file from which I can check my receiver. Thanks alot >> >> Regards >> Ahsan >> > > > ___ > 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] DVB-T Reception Problem
Hi Ahsan, The signal does look good indeed. I'm guessing the problem is that nothing is output from the OFDM sym acquisition blocks (both from gr-dvbt and gr-isdbt?). In any case, are you sure about those transmission parameters? Did you check other CP lengths? gr-isdbt includes a small grc file to check both the transmission mode and CP which works both for ISDB-T and DVB-T (examples/obtaining_parameters.grc, please refer to the README or the issues section on the git). Maybe you could test that? best Federico 2015-12-17 7:51 GMT-03:00 Ron Economos : > Marcus, > > That extremely low signal level is due to a Multiply Const block in the > flow graph set to 0.00055242272. In the gr-dtv in-tree version, I've > deleted that block. > > Ron > > On 12/17/2015 02:25 AM, Marcus Müller wrote: > > Can you crank up the USRP gain further? An average PSD value of 10^-14 > indicates there's still room for amplification, maybe. What Daughterboard > are you using? > Just out of interest, because improvised a ~760MHz monopole antenna not so > long ago: What kind of antenna are you using? > > Best regards, > Marcus > > On 17.12.2015 11:14, ahsan@studium.fau.de wrote: > > Hello all, > Here are the USRP setting for my flowgraph > USRP N210 Settings > Sampling Rate: 10M > Center Frequency :746MHz > Gain:19 > The broadcast station has these parameters > Frequency:746MHz > Code rate : 2/3 > Guard interval : 1/4 > Transmission mode : 8k > I tried the vector to stream trick but doesnt works. Also I tried using > the OFDM synchronization block from gr-isdbt it also doesnt works. The > signal capture according to me is very good I have its screenshot > attached. Any other tips to get the flowgraph running? Thanks all > Cheers > Ahsan > > > > > ___ > 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] DVBT project receiver probelm
Hi Ihab, I've just realized that the flowgraph obtaining_the_parameters is not very clear, and I will modify it shortly.Thanks for the feedback. Could you please connect the output of Sym Align OFDM that reads "Likelihood" to a Time Sink? That is the one that should show a triangle. (BTW, you may also disable the OFDM Synchronization and TMCC decoder blocks, since they only work for ISDB-T only and are causing all that text in the terminal). Regarding your constellation, I don't think you'll get a decent transport stream with it, it's too noisy. You should try to receive a better signal. Things I would try: 1 - You are still getting several O's. Delete the noise source, which was there on the first place to simulate a channel. You already have one. In my experience, random generators are a costly thing. 2 - Delete the multiplication at the input, which purpose I ignore. However, since it also multiplies noise, I don't think it will change much. 3 - Record the signal at a better spot, where the signal is better. Regarding the use of our ofdm_sym_acquisition, if I am not mistaken, gr-dvbt blocks downstream expect a certain tag which we changed. You should be careful with that too. Best Federico 2015-11-30 9:17 GMT-03:00 Ihab Zine : > Hi Frederico,Marcus and > > *Ron, * > *I have good news and bad news. * > > *Frederico I used the flow graph (obtaining parameters) **you told me to > use but i didn't get the triangle or spike, i have attached a screen shot > please see (* obtaining_parameters.grc, Screenshot from ObtainingParameter > & Screenshot_obtaining_parameters_Terminal)*. * > > Marcus I have tried the command "sysctl -w kernel.shmmax" to increase the > available shared memory but i got (bash: sysctl: command not found). > > The good news is that i'm finally able to get the DVBT signal synchronized > and it was working earlier and i got some video and audio working from the > source, please see ( Screenshot_receiving & > Screenshot_after_ISDBT_ofdm_sym_acuistion) > attached blow. i think the problem was because of samples dropped, after i > used *stream to vector & vector to stream* at the start of the flow graph > i start seeing something working then i was adjusting *SNR* and then it > was working. Now im not able to get a video don't know why at lease i'm > getting the constellation which is good. I'll keep going and trying to get > the video and audio working again. I'll let you know guys when i have > something new. > > Big Thanks :) > > Ihab > > > On 27 November 2015 at 18:20, Ihab Zine wrote: > >> >> >> -- Forwarded message -- >> From: *Federico Larroca* >> Date: Friday, November 27, 2015 >> Subject: DVBT project receiver probelm >> To: Ihab Zine >> >> >> Hi Ihab, >> You only answered to me, maybe you should forward your mail to the list. >> Regarding the grc, I would also remove the channel model (used for >> simulations), as in my experience it consumes much CPU. >> best >> Federico >> >> 2015-11-27 7:22 GMT-03:00 Ihab Zine : >> >>> -- >>> Hi Frederico,Marcus and >>> >>> *Ron* >>> >>> *I just got access to the system, ill try to follow what you have told >>> me guys and ill let you know how it goes.* >>> >>> >>> *Thanks* >>> >>> *Ihab * >>> >>> On 26 November 2015 at 17:22, Federico Larroca >>> wrote: >>> >>>> Hi Ihab, >>>> Those "restart aquisition" are generated by the ofdm_sym_acquisition >>>> block when it does not find a peak on the correlation function he uses to >>>> detect the beginning of the OFDM symbol. You should verify there is indeed >>>> a DVB signal precisely at 570 MHz. To do this you may use our "Sym Align >>>> OFDM" block (not a very nice name) available with gr-isdbt ( >>>> https://github.com/git-artes/gr-isdbt) and check that you see a >>>> "triangle" (please refer to the readme, the examples, and even the issues >>>> on our git). The symbol alignment is totally equivalent between DVB-T and >>>> ISDB-T. >>>> Moreover, I see several "O"s, meaning that somewhere samples are being >>>> dropped. That does not help either. If you do not have a very fast machine, >>>> you may use at the beginning of the flowgraph a "Stream to Vector" followed >>>> by a "Vector to Stream" with a very big "Num Items" (some millions). >>>
Re: [Discuss-gnuradio] DVBT project receiver probelm
Hi Ihab, Those "restart aquisition" are generated by the ofdm_sym_acquisition block when it does not find a peak on the correlation function he uses to detect the beginning of the OFDM symbol. You should verify there is indeed a DVB signal precisely at 570 MHz. To do this you may use our "Sym Align OFDM" block (not a very nice name) available with gr-isdbt ( https://github.com/git-artes/gr-isdbt) and check that you see a "triangle" (please refer to the readme, the examples, and even the issues on our git). The symbol alignment is totally equivalent between DVB-T and ISDB-T. Moreover, I see several "O"s, meaning that somewhere samples are being dropped. That does not help either. If you do not have a very fast machine, you may use at the beginning of the flowgraph a "Stream to Vector" followed by a "Vector to Stream" with a very big "Num Items" (some millions). best Federico 2015-11-26 12:59 GMT-03:00 Ihab Zine : > Hi, > > I’m trying to receive a live signal from an antenna on the roof through a > cable connected to my SDR (hackrf one ).The bandwidth of the DVB-T in > ireland is 8 Mhz , and the parametetrs Here in ireland as following: > > Bandwidth: 8 MHz > Stream code rate (hi prio): FEC 2/3 > Stream code rate (lo prio): FEC 2/3 > Modulation: QAM 64 > Transmission mode: 8k mode > Guard interval: 1/32 > Hierarchy: none > > net_data_rate = 24.128 Mbits/s > > I used dvbt_rx_demo_8k_QAM64_rate78.grc flow graph with the following > changes : > >- > >frequency of hackrf one = 570 Mhz, sampling rate = ((8*8e6)/7). >- > >Cyclic Prefix to (8192/32, is this right?) >- > >Code Rate HP : 2/3 >- > >Code Rate LP : 2/3 >- > >Guard Interval : 1/32 > > The problem i have is that no output data coming out after the > demod_reference_signals BLOCK(no cancellation map), and got the following: > > restart aquisition > > OOrestart aquisition > > d_freq_offset: -5 > > Od_freq_offset: -5 > > d_freq_offset: -5 > > d_freq_offset: -5 > > d_freq_offset: -5 > > d_freq_offset: -5 > > d_freq_offset: -5 > > d_freq_offset: -5 > > restart aquisition > > OOd_freq_offset: -5 > > d_freq_offset: -5 > > > > so I had to add a signal source to shift the signal. After shfting the > signal i got the following : > > restart aquisition > > restart aquisition > > restart aquisition > > restart aquisition > > Orestart aquisition > > > > I have read a lot about DVB , mapping ,ofdm and others, i have spent weeks > on this but still the same problem, if it is synchronization problem what i > should do? > > So please i need a some help with this problem . > > > > Thanks > > Ihab > > > > ___ > 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] gr-mer or a few digital modulation error measurements blocks
Hi all, Together with our ISDB-T oot, we've written some blocks which we found were missing in gnuradio, which basically measure some fairly common indicators in digital modulation (mer, ste, etc.). Since they may be useful for other things apart from DTV, we are sharing it as a separate module, which we've called gr-mer. If interested, you may check it out at https://github.com/git-artes/gr-mer. BTW, we've added both oot projects to cgran. However, although we've added a MANIFEST.md in gr-isdbt, the extra info is not shown in cgran. Maybe we missed something? best Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] possible bug in gr_modtool
Dear all,
We have been working with our gr-isdbt OOT for some months now, and we've
stumbled upon what we believe is a small bug in gr_modtool: doxygen
documentation of the OOT is not updated when doing "make && sudo make
install".
After some exploration, we believe the problem is that the CMakeLists.txt
in docs/doxygen/ has a add_custom_command without a DEPENDS declaration.
We've patched it by replacing those lines with (bold indicates the
addition):
add_custom_command(
OUTPUT ${BUILT_DIRS}
COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
*DEPENDS ${CMAKE_CURRENT_BINARY_DIR}*
COMMENT "Generating documentation with doxygen"
)
However, our expertise with cmake is null, so we're not sure this is the
right solution. Maybe someone in the developement team has the "correct"
solution.
best regards,
Federico
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] An ISDB-T receiver implementation
Hi everybody, Some months ago we started working on an ISDB-T receiver for GNU Radio. We have reached a point at which it may be useful for other people, so we decided to announce to it on the list. The sources may be found on: https://github.com/git-artes/gr-isdbt. Although this is an ongoing work, the receiver is now capable of roughly two things (examples included): - Synchronize to the OFDM symbol, equalize, and decode the TMCC signal (equivalent to the DVB's TPS). This has been tested for mode-3 transmission (i.e. 8k OFDM) and several CP lengths, which is what we have available here, but it should work with all the modes and CPs. - Display online the 1-segment video (i.e. the low definition portion that is generally sent in ISDB-T). Again, this has been tested with the transmissions available here in Uruguay. We are currently working on displaying the rest of the segments, as well as debugging and improving the rest of the blocks. Any feedback and/or help is more than welcome! Best, Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] isdb-t implementation in gnuradio
Hi everyone, Here in the lab we have been working for several months with USRPs and GNURadio, both for teaching and research, but specially the former. Students are very very motivated by the sense of reality that they bring. All in all, congratulations for all the developers involved. In any case, here in Uruguay they are starting to deploy digital TV, the ISDB standard in particular. So we figured that a good "long-term" project would be to implement an ISDB receiver. The first thing we had done is to verify if anyone has developed (or at least started to develop) such receiver with GNURadio and USRP (or any other SDR platform, such as BladeRF). After conducting a realtively thorough search on the internet, we have concluded that some work has been carried out, but no code has been made public. In particular, we found the following related works: - The work of the group of Vincenzo Pellegrini in DVB, which is not available (https://www.ruby-forum.com/topic/1440970). - Receiving only the 1seg by a group in the Nara Institute of Science and Technology, which I believe is not available either (a demo in youtube: http://www.youtube.com/watch?v=svzMwFrcNC0). - A paper by a group in the University of Campinas (Brazil), where they report of an ongoing work to implement a ISDB-T transmitter (see http://groups.winnforum.org/europe_papers_wednesday#2.3), but of which I could not find anything except the paper. Anyone knows of a project to implement such receiver in GNURadio? Or maybe someone has tried and concluded that the required computation is too much for the host PC? Thanks in advance. Best regards, Federico ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
